comments inline.
From: Ben Campbell [mailto:ben(_at_)nostrum(_dot_)com]
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(_at_)adobe(_dot_)com> wrote:
hi Ben. thanks for your review. comments/replies inline.
From: Ben Campbell [mailto:ben(_at_)nostrum(_dot_)com]
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