On Fri, 2013-06-07 at 11:35 +0200, Magnus Westerlund wrote: > Hi Elwyn, > > Many thanks for the detailed review. We will address the nits you have > raised, but I cut them out of this reply to focus on the more > substantial issues you have brought up. .. and thanks for the quick response. > > See inline below. OK. I think the responses clear those issues. I have done a little bit more on the Appendices and liaised a bit with Robert Sparks. 'Highlights': Appendix F: I missed that the text/parameter format appeared in the examples for GET_PARAMETER and SET_PARAMETER. It isn't stated in the definitions of these methods what encodings are acceptable for the message bodies that may go with these methods and their responses. Clearly the new text/parameter MIME format is one. Is it the only one? I guess you could use a application/json or an XML format but I guess these would also either have to be called out explicitly in the method descriptions or put in as feature extensions. This needs to be clarified in the method descriptions (s13). The upshot of all this is that I think Appendix F needs to be pulled back into Section 20 as currently it is the only way to encode the message bodies. Appendix B: I appreciate that the state machine is illustrative and to an extent 'abstract'. However, the tables are really written to describe the state machine in the server: the action column mostly describes the events that come into the server (apart from the notify actions) - sending these 'events' are actions in the client. The 'real' state machine in the both the server and the client has a somewhat more complex form: I'd think that there was a STOPPED state in the server when the media has reached an end point and not been explictly paused and STARTING/PAUSING states in the client while the client waits for response to PLAY/PAUSE respectively. I think a little bit more explanation about the dual nature of the columns would solve the problem. Appendix C: Pending. Regards, Elwyn > > On 2013-06-06 02:11, Elwyn Davies wrote: > > I am an additional Gen-ART reviewer for this draft. For background on > > Gen-ART, please see the FAQ at > > > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > > > Please resolve these comments along with any other Last Call comments > > you may receive. > > > > Document: draft-ietf-mmusic-rfc2326bis > > Reviewer: Elwyn Davies > > Review Date: 5 June 2013 > > IETF LC End Date: 5 JUne 2013 > > IESG Telechat date: (if known) - > > > > Summary: > > Almost ready. Generally this is an excellent and well written document, > > particularly given its size. There are a few minor issues to sort out > > mainly at the nit level and some consistency issues to fix up. The two > > issues that I have brought out below are really at what the IESG would > > call 'DISCUSS-DISCUSS' level. The issue of URI scheme redefinition may > > well have already been cleared by the URI expert - the draft does not do > > itself any favours here by failing to explain what the syntax changes > > are in s4.2; this raises immediate red flags that only start to fade a > > couple of hundred pages later. The rudimentary nature of the pipeline > > mechanism is carried over from RTSP 1.0. I'd like to be sure that this > > has been properly discussed in the WG as it looks pretty flaky to an > > outsider. There are several inconsistencies between various lists of > > headers that need sorting out and there is no definition of > > Proxy-Authorization in the ABNF. > > > > There are also a fairly large number of editorial nits but these are all > > localized and trivial to fix. Finally I have't had time to review the > > appendices (maybe there will be a follow up). > > > > Robert Sparks is the main gen-art reviewer for the document; he asked > > for additional eyes on the document given the size and his RAI > > background. Having (just) seen his review, I think we have both picked > > up on the URI scheme and pipeline issues. I am not sure that I concur > > with his view that there is significant normative material in the > > appendices - AFAICS the main protocol definition *is* in the main body > > of the document and the bits especiially in Appendices B and C are not > > the core of the protocol. However this is based on a very cursory > > glance through something like 75 pages of the document. However, I do > > concur with Robert's view that it needs a security expert to check the > > security stories. > > > > Major(ish) issues: > > s4.2: This section (re-)defines the URI schemes "rtsp" and "rtsps". The > > last sentence of para 1 states that the 'details of the syntax' of the > > URIs 'have been changed'. Is this a reasonable thing to do? Has this > > been cleared with the URI expert reviewer? I am not entirely clear what > > the change involves and the draft doesn't explain exactly how the syntax > > has been altered and its consequences (if any) in s4.2. Some details > > are finally given in s22.14. > > These syntax changes where discussed in the reviews I got on the URI > list. That resulted in the explicitness in the template, but I forgot > about adding anything into Section 4.2. I see no issue with adding the > following clarification to Section 4.2: > > The details of the syntax of "rtsp" and "rtsps" URIs has been changed > from RTSP 1.0. These changes are: > > o Support for IPV6 literal in host part and future IP literals > through RFC 3986 defined mechanism. > > o A new relative format to use in the RTSP protocol elements that is > not required to start with "/". > > Neither should have any significant impact on interoperability. If > one is required to use IPv6 literals to reach an RTSP server, then > that RTSP server must be IPv6 capable, and RTSP 1.0 is not a fully > IPv6 capable protocol. Thus, RTSP 2.0 support will be needed anyway. > The second change will only occur in RTSP messages, that are > explicitly identified as being RTSP 2.0 messages, thus a RTSP 1.0 > only agent will not be required to parse this variant. > > I hope this makes it clear that these syntax changes is unlikely to hurt > the interoperability. > > > > > > > Minor issues: > > s11, para 3: I guess that the WG decided that sticking with the RTSP 1.0 > > model of sending requests and worrying about success of prior prior > > pipelined requests was the right answer. I would have thought that it > > might have been helpful to provide qualifiers on the Pipelined-Requests > > header that allowed subsequent requests to be suppressed unless the > > previous command resulted in one of a given set of status codes with a > > 'reset' option to 'restart' the pipeline. It strikes me that this would > > avoid some irritating need to work out how to recover from arbitrary > > failures in a command chain in a client. > > > > I assume you mean this Section 12 paragraph: > > If a pipelined request builds on the successful completion of one or > more prior requests the requester must verify that all requests were > executed as expected. A common example will be two SETUP requests > and a PLAY request. In case one of the SETUP fails unexpectedly, the > PLAY request can still be successfully executed. However, the > resulting presentation will not be as expected by the requesting > client, as only a single media instead of two will be played. In > this case the client can send a PAUSE request, correct the failing > SETUP request and then request it to be played. > > I think I agree with your assessment, that it would have been nice. > However, we should have thought of that when we introduced this type of > pipelining 7 years ago. Making any changes to this at this stage is > counter productive. The reality is that all the "nice" features and > necessary clarifications has been retrofitted into RTSP 1.0 by the ones > that have been using RTSP 1.0. So changing anything will separate the > RTSP 1.0 and RTSP 2.0 implementations. The good thing is that I can't > remember any substantial complaints about this issue. > > I hope this resolves your comments. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@xxxxxxxxxxxx > ---------------------------------------------------------------------- > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art