comments inline. > From: Ben Campbell [mailto:ben@xxxxxxxxxxx] > Sent: Tuesday, June 25, 2013 4:10 PM > > Thanks for the response! Comments inline: > > Thanks! > > Ben. > > On Jun 21, 2013, at 4:35 PM, Michael Thornburgh <mthornbu@xxxxxxxxx> wrote: > > > hi Ben. thanks for your review. comments/replies inline. > > > >> From: Ben Campbell [mailto:ben@xxxxxxxxxxx] > >> Sent: Thursday, June 20, 2013 4:07 PM [...] > > with regard to comments in later messages in this thread, i'd be happy to include some (IESG- > supplied) boilerplate in the document to clarify that it is not the product of an IETF WG. however, > note that both the title and first sentence of the Introduction indicate that this is "Adobe's > blahblahblah", consistent with other vendor-protocol RFCs and consistent with IESG editorial > insistence (as told to me by a former TSV AD). see RFC 4332 and RFC 6802 for two examples of vendor- > specific/supplied protocols. see also the IESG note in RFC 4332 as an example disclaimer that could > be added. > > Some additional text (whether IESG boilerplate or otherwise) that clarifies the purpose of the draft > would help a lot. the sponsoring AD has proposed an additional statement that will be inserted by the RFC Editor on publication. note that draft -08 has additional clarification that this is an Adobe protocol and is not the product of an IETF activity. > >> Along those lines: > >> > >> -- Is this document the authoritative specification? (I suspect not.) Who owns change control? I > >> assume that to be Adobe and/or the authors. What expectation do readers of this draft have that it > >> represents the current version of RTMFP at any point in time? > > > > this memo is the authoritative specification for Adobe's RTMFP. Adobe owns change control. i > believe the second and third paragraphs of the Introduction indicate to a reader that this draft > represents RTMFP as deployed in the named Adobe products at the time of writing. > > At the time of writing yes. My concern is how a future implementor can be confident that this doc > describes RTMFP as used by Adobe at points in the future. When you say this is the authoritative > specification, does that mean that Adobe does not plan to modify the protocol without timely > publication of an update to this document? this is a problem for *any* published protocol. RTMFP (as documented in this memo) hasn't changed substantially in many years. i have every expectation that, should a change be made to the protocol, we would publish an updated specification. [...] > >> -- sections 3.2 and 5 > >> > >> Do I assume correctly that endpoints need a common crypto profile to communicate? Is there a > >> repository where one might find crypto profile documentation? Is there a commonly implemented one > to > >> which this draft could refer? > > > > yes, endpoints need a common cryptography profile to interoperate. there is no repository for > crypto profile documentation at this time. currently, there is one defined cryptography profile (the > one used for Flash communication) that is not publicly documented, because i do not yet have > permission to publish it. i (meaning me personally) hope that a memo documenting the > crypto/application profile for Flash communication (as being a widely deployed and used profile for > RTMFP) would also be published someday as an I-D and hopefully an Informational RFC. > > I understand the issue about permission to publish, but does this document serve its purpose until you > are ready to publish the crypto profile? Ideally they would be published together and this document > would reference that one. Do I infer correctly that there is no way someone could create an > implementation that interops with Adobe products based on the documents available at this time? additional documentation is needed to interoperate (at the application layer) with the Adobe products that implement RTMFP. i hope that the successful publication of this memo will help me in getting the necessary approval to publish the higher layer details of Adobe's RTMFP ecosystem. the situation is analogous to having published TCP, but there's a lot more you need to know to talk to a web server with HTTPS (like TLS and HTTP). it's still useful to know how TCP works, and plenty more to do with it than talk to web servers. > >> -- section 3.2: "Multiple endpoints SHOULD NOT have the same identity." > >> > >> Why not MUST? Will things not break if two endpoints do have the same identity? > > > > this should be "It is RECOMMENDED that multiple endpoints not have the same identity." if two > endpoints have the same identity, then they will be indistinguishable. this will not break RTMFP, but > might confuse an application. that being said, there could potentially be reasons to have different > endpoints with indistinguishable identities and that potential should not be normatively prohibited. > > As Barry mentioned, RECOMMENDED is a synonym for SHOULD. Adding some text the effect of your > additional explanation would solve my concern. i changed this to RECOMMENDED (because while i agree that RECOMMENDED and SHOULD impart the same force of normative requirement for an implementer, the words' different English meanings help the reader understand the reason for the normative constraint). see draft -08 for additional explanation i added for this constraint. [...] > >> *** Nits/editorial comments: > >> > >> -- General: There's quite a bit of inconsistent use of third-person vs second-person language. > > > > i will try to clean that up. > > Okay. as i mentioned in a separate message: """i believe the "second-person" voice in this memo is used exclusively for detailing algorithms that are to be performed. i believe the imperative "do it like this" voice is appropriate to that use, so i did not change it. i also feel that the change in voice helps indicate that the implementation is being addressed/instructed.""" [...] thanks. -michael thornburgh