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. 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. Nits/editorial comments: General: s/i.e./i.e.,/; s/e.g./e.g.,/ General: Consistent usage of octet vs. byte (octet preferred). General: Consistent use of '(session) keep alive' vs. '(session) keep-alive' General: Consistent use of Base64 vs BASE64. s1, para 2, last sentence: s/delivered as a time-synchronized streams/delivered as time-synchronized streams/ s1. last para: s/used terms/terms used/ s1, last para: Need to expand SDP acronym. s2, para 1: s/considered use cases/use cases considered/ s2.1, para 1: s/completely out of bands/completely out of band/ s2.1, next to last para: It would be useful to provide a pointer to where the two URI schemes are defined (s4.2?) so it is clear these are internally defined and one needn't go looking for another doc. s2.2, para 5: s/uses client-selected identifier/uses a client-selected identifier/ s2.2, para 5: For consistency there should be a reference for s18.32 with Pipelined-Requests. s2.2, last para: For consistency there should be a reference for s18.29 with Media-Range. s2.3, para 1: Expand SMPTE acronym. s2.3, para 3: Reference s13.5 for PLAY_NOTIFY s2.3, para 5: > The server should also regularly send every 5 > minutes the current media range in a PLAY_NOTIFY request. Shouldn't this be configurable? s2.3, last para: > If the client waits too long > before resuming the pause point, the content may no longer be > available. In this case the pause point will be adjusted to the end > of the available media. I know this is a subjective choice, but I would have thought adjusting to the beginning of the available media would be what the user expects. Later: Having read s13.4.1, I think this conflicts with (or is unclear) compared with s13.4.1, para 2 which states that the pause point will be the oldest retained time - that is what I would have expected. s2.4, para 1: For consistency there should be a references for s22.11/s22.9 with RTP-Info and Range. s2.4, para 2: s/that can be used/can be used/ s2.5.1, paras 2/3: Should have references to ss18.48/18.44 for Scale/Speed. s2.5.1, para 6: OLD: These media manipulation and when they are needed are highly media-type dependent. NEW: The nature of these media manipulations and when they are needed is highly media-type dependent. --or-- The nature of this media manipulation and when it is needed is highly media-type dependent. s2.5.1, para 9: s/and the currently used scale factor exist./and the scale factor currently in use, exists./ OLD: a mechanism for updating the media properties and the currently used scale factor exist. NEW: a mechanism exists for updating the media properties and the scale factor currently in use. s2.6, bullet 1: Need to expand RTCP acronym (RTP is 'well-known' but not so RTCP apparently). s2.6, para 5: Reference s13.7 for TEARDOWN. s2.6, para 7: s/10*times/ten times/ s2.6, last para: Reference s13.10 for REDIRECT s2.6, last para: Reference s22.10 for Terminate-Reason s2.7, para 2: Reference s18.41 for Require s2.7, para 2: The reference for s18.35 for Proxy-Require should be moved from bullet 2. s2.7, para 3: s/in order of the magnitude/in increasing order of the magnitude/ s2.7, bullet 3: s/standard/standards/ s3.1, para 3: Clearly there won't be any smaller type paras in the ASCII version.. is there a PDF version that actually has smaller type? The one I get from the repository doesn't seem to have any smaller type paras. s4.2, para 2, last sentence: OLD: This way RTSP 2.0 URIs for request can be produced from an RTSP IRI. NEW: This allows a URI that matches the RTSP 2.0 specification, and so is suitable for use in a request, to be created from an RTSP IRI. s4.4: An external reference to the relevant Society of Motion Picture and Television Engineers standard (probably SMPTE 12M) ought to be included to define things like "SMPTE 30 drop". [Aside: 29.97 frames per second?? Must be something to do with Never Twice the Same Color. Oh, well, a little research job for whan I am really bored.] s4.5: The NTP reference is interesting but gratuitous. s4.6: It would be useful to add the "clock=19961108T143720.25Z-" form for consistency with s4.4 and s4.5 as well as the 'free-standing' absolute time which is used in Media-Properties etc. s4.8, para 1: A more precise reference for HTTP ETag would be helpful. s4.9, para 1: s/the below listed media properties/the media properties listed below/ s4.9.1: There seems to be some confusion in this section between the values from the Seek-Style header and the values from the Media-Properties random access property. The section says the values are from Seek-Style but they are actually from the random access property. Presumably there was some intention to interelate the media capabilities and the play event policies? Further this section has Random Access, Conditional Random Access, Return to Start and No Seeking. This doesn't match exactly with either Seek-Style (RAP, CoRAP, First-Prior and Next) or Media-Properties (Random-Access, Beginning-Only and No-Seeking). s4.9.2, "Time Limited": s/before given wallclock time/before the given wallclock time/ s4.9.3, para 1: s/during time/over time/ s4.9.x: It would be desirable to use the parameter names in the same form as they appear in s18 (e.g., Random-Access instead of Random Access, No-Seeking instead of No seeking) both in the definitions (s4.9.1 - s4.9.4) and the mapping (s4.9.5). ss4.4/4.5/4.6: If I read the ABNF in s20.2.1 correctly, the unqualified values "smpte", "npt" and "clock" are valid in the Range parameter. What is the meaning of such an unqualified value? s5: It would be sensible to note that the ABNF fragments in s5 and the following sections match with the full syntax productions in s20. Table 3: Proxy-Authorization (Section 18.34) doesn't appear in any of the various header categorization tables [I must have better things to do than checking they were all there :-( ]. I think it belongs here. s5.3: For consistency with s9.2, this section should also say that a message with a body MUST contain a Content-Type header also. s5.3, para 1: > An example of a message body is the Session Description > Protocol (SDP). Er, perhaps not the *whole* protocol? Maybe an SDP message?? s7.2, para 1 and Table 3: Perhaps the headers that can also be in Response messages could be marked? I believe these are Range, Scale, Session, Supported and Transport. s8.1.1: Should clarify that a separate registry is being defined so the story about importing HTTP codes doesn't have any impact on the HTTP registry. I initially read this as if it did. s8.1.1, para 5: Is there some deep reason for labelling this 3rr rather than 3xx? (and throughout the document). Sort of understandable but a bit odd. s8.1.1, code 505: HTTP code 505 is explicitly '*HTTP* version not supported' - should there really be a separate code for 'RTSP version not supported'? s8.1.1, code 551: s/Support/Supported/ Table 5: Alphabetic sort on Server and Session is incorrect. s8.2, last para: s/recognize them to be response-header/recognize them to be a response-header/ s9, para 1: Should the cross-reference be to s5.3 (message body) rather than 5.2? s9: Is it deliberately left vague as to whether other message types might have message bodies? s10.2, para 6 and following note: I can't see that the note following para 6 can be justified: since the restriction on multiple connections from a client to a server is only a SHOULD, an interoperable server MUST be capable of handling multiple connections from a client unless the server can explicitly send back a TOO MANY CONNECTIONS status. s10.2, para 10: s/due to the response is caught in the queue behind a number of request that/due to the response being caught in the queue behind a number of requests that/ s10.3, para 4, "on the flip side": Slang. Maybe "Contrariwise" or something less archaic. s10.4, para 4: Expand RTT acronym (its apparently not well-known). s10.5, para 1: s/ To show liveness between RTSP request issued/ To show liveness between RTSP requests being issued/ s10.5, RTCP para: s/it MUST also work as keep alive/it will necessarily also function as a keep alive/; s/statistical guarantees to reach the server/statistical guarantees of reaching the server/ s10.5, RTCP para: OLD: That client has, for a network with 5 % packet loss, the probability to fail showing liveness sign in that session within the timeout interval of 2.4*E-16. Sessions with shorter timeouts, or much higher packet loss, or small RTCP bandwidths SHOULD also use any of the mechanisms below. NEW: That client has, for a network with 5% packet loss, a probability of failing to confirm liveness within the timeout interval for that session of 2.4*E-16. Sessions with shorter timeouts, or much higher packet loss, or small RTCP bandwidths SHOULD also implement one or more of the mechanisms below. s10.5, RTCP para: expand SSRC acronym. s10.5, SET PARAMETER para: s/keep-alive/keep alive/ s10.5, last para: Should clarify that the 'timeout parameter' is a qualifier on the Session parameter - 'timeout parameter' appeared to indicate that it was a separate protocol parameter and sent me searching. s10.6: RFC 3986 has capability for dealing with IP versions beyond 6... should these be carried over into RTSP? The IANA registry says they are. s10.7, para 3: s/and in dependency of its current load situation/and bearing in mind its current load situation/; s/to increase the length proportional with the load of the server/to increase the timeout period in proportion to the current load on the server/ s10.7, para 3: Anti-synchronization measures such as are RECOMMENDED here are usually MANDATORY. (Also applies to wait timer in last para of this section). s10.7, para 4: s/Another issue are load balancing RTSP proxies/A more complex case may arise when a load balancing RTSP proxy is in use/ s10.7, last para: Should the doubling of the wait timer have an upper limit? s11, para 4: s/Feature-Tag/Feature-tag/ s11, para 4: According to s22.1.3, play.basic, play.scale and play.speed are 'defined' in this draft. The nearest thing to a definition of play.basic that I can find is the last sentence of para 4 in this section. I am not convinced that I could produce an interoperable implementation of a server with this feature-tag with the one sentence 'definition'. References to where play.xxx are defined would be useful (play.scale in s18.44, play.speed in s18.48). s11, Supported (and Proxy-Supported) bullets: OLD: This results in the receiver is learning the requester's feature support. NEW: This results in the receiver learning the requester's feature support relevant to the specified resource. [Note: I added 'specified resource' here and then thought about whether this made any sense. It probably needs to be clearer what set of features are included in the Supported list for both requester and responder. Are they restricted to those relevant to the specified resource that might of course be the whole server, proxy - or client?? - in which case there isn't an issue, but it might be a specific presentation - what happens then? Affects s13.1, para 3 also.] s11, Proxy-Supported bullet: To emphasise the 'intersection of features' mechanism used for Proxy-Supported (s18.36), it might be good to s/a view of what functionality the proxy chain/a view of the common functionality supported by all members of the proxy chain/ s12, para 2: Might be better with: s/allow all requests to setup and initiate media delivery/allow all requests involved in setting up and initiating media delivery/ s12, para 2, last sentence: s/with at least one RTT/by at least one RTT/ Table 7: The 'Server req' and 'Client req' columns are not described. s13.1, para 1: s/a client request it to a server/a client can send the request to a server/ s13.1, para 1: OLD: The client, server or proxy MAY also implement the converse of their required capability, but still retain the prior mentioned about what is a "MUST implement". NEW: In addition to this "MUST implement" functionality, clients, servers and proxies MAY provide support both for sending OPTIONS requests and generating responses to the requests. s13.1, para 3: s/Regardless of scope of the request/Regardless of the scope of the request/ s13.1, para 4: s/ID/identity/ s13.1, last para: s/fictional/fictitious/ s13.2, example S->C: Is Mark Handley cool with using his name? Might be better to use the traditional 'another' (A.N.Other). s13.3, para 1: It would be helpful to copy the list of (3) states from Appendix B somewhere around here and mention that the protocol drives a state machine. s13.4.1, para 2: > Upon receipt of the PLAY request, the server MUST position the normal > play time to the beginning of the range specified in the received > Range header Should this mention the caveat that (if I understood earlier statements correctly) the server may not be able to deliver exactly on this MUST and then sets it the nearest it can manage? This is borne out by the example later in this section where the server sets the start point back 10ms (and says so), etc. Seek-Style affects the interpreation of MUST! s13.4.1, page 72: OLD: i.e. being handled the same as the request was received in Ready state. In the case the range in Range header has an implicit start time (-endtime), NEW: i.e. being handled in the same way as if as the request was received in Ready state. In the case that the range in Range header has an implicit start time ("-endtime"), s13.4.3, para 2: s/will take action/will take effect/ s13.4.3, page 76: s/entering or leaving from fast forward or fast rewind./entering or leaving fast forward or fast rewind mode./ s13.4.4/.5/.7/.8: In these sections the Media-Property random access property is stated as being required to be Random-Access. Is Conditional Random Access a possible value for this property? The confusion in s4.9.1 does not allow me to conclude that this shouldn't be a value for the property (sorry for the double negative but this looks a bit confused). s13.5.1: Apologies if this question is stupid - I am not a media stream wxpert. Suppose we have an aggregated stream with (say) a number of recorded media items making up the aggregate. The client sets it on to play to the end. What happens if not all the streams end at the same time? Do we get PLAY_NOTIFY End-of-Stream notifications for each individual stream as it ends or just one when the complete aggregate ends? s13.5.2, para 2: > that changes the basis for making > estimates on how the media range progress. I can't parse the last part of this and I am not sure what it should be. s13.5.3, first sentence: 'change the rate' of what? media delivery presumably. s13.5.3, para 2: s/adjust the used Scale value/adjust the Scale value used/ s13.5.3, para 2: s/where the change took effect/when the change took effect/; s/ID/identity/ s13.6, para after 1st example:s/ resume from the pause/resumes from the pause/ s13.7.1, para 3: OLD: This may result in that a session returns to non-aggregated control, due to that it only contains a single media after the requests completion. NEW: This may result in a session returning to non-aggregated control, because it only contains a single media after the request's completion. s13.8, para after bullets: s/request parameters/requests parameters/; s/Due to this reason/For this reason/ s13.9, para 2: s/In the case a parameter/When a parameter/ s13.10, 3rd para after numbered bullets, page 93: s/"time" parameter are included/"time" parameter is included/ s13.10, page 94, para next but 1 before example: OLD: However, the usage of conditional SETUP using MTag identifiers are RECOMMENDED to verify the assumption. NEW: However, the usage of conditional SETUP using MTag identifiers is RECOMMENDED as a means to verify the assumption. s14, para 2: s/integer/unsigned integer/ (I assume) s14: What happens if the upper layer PDU is longer than (2^16 - 1)? s14, figure: Binary header should have a figure number and title. s14, figure: 'Length number of bytes of binary data' is confusing. Maybe 'Binary data (length as in Length field)' s17.3: Uses 3xx in the title and 3rr in the body. See previous comment about 3rr. s17.4.32: s/next hops/next hop's/ (I think). s17.5.6: See previous comment about overloading the 505 error code. s18, Table 8 caption: OLD: Note: It is allowed for all error messages 4xx and 5xx to have a body NEW: Note: All error messages for statuses 4xx and 5xx are allowed to carry a body. s18, para after Table 8: s/[HX.Y] to informational refer to Section X.Y/[HX.Y] to reference Section X.Y/ s18.2, para 2: s/This as/This is because/ s18.2, para 2: Expand DER avronym. s18.2, para 3: s/replacement algorithm exist./replacement algorithm exists./ s18.5, para 1: s/formats it support to receive/formats are acceptable when received/ s18.6 para 1: s/to strictly inform the recipient of valid methods/to inform the receipient of the complete set of valid methods/ s18.6, para 2: s/Allow/Allow message-header/; s/is different than/is different from/ s18.8, para 2: s/due to that/because the/; s/what is reasonable/what is a reasonable/ s18.10, para 3: s/govern only/govern just/; s/Below is the description/Below are the descriptions/ s18.10: The various descriptions talk about 'media stream'. Presumably this should include media streams and RTSP responses. s18.10, no-cache para: OLD: Note, there is no security function enforcing that the content can't be cached. NEW: Note, there is no security function preventing the caching of content. s18.10, private para: Is there any way in RTSP for the cache to know whether this is a private cache for the user that should cache this content? s18.10, last para: I am not absolutely certain, but I think this para is specific to the max-age cache type rather than being generic as implied by the indentation. [If so use the <vspace blankLines=1/> trick to provide a pseudo-paragraph break] s18.11, para 5: s/therefore see/therefore sees/ s18.12, para 1: s/of any next hop that need to be approved/for any next hop that needs to be approved s18.12: Figure needs a number and a caption. s18.14: Consider adding the 'identity' value explicitly to the ABNF. s18.17, para 6: s/relative URI/relative URI(s)/ s18.10, last para: Should have a reference to RFC 1123 for the date format. s18.28, para 1: s/properties take effect/properties taking effect/ s18.29, para 2: Are (or should there be) constraints on the ordering of media ranges for a non-continuous media stream? It would probably make the client's job easier if they were in incresing order. s18.32, para 3: s/or request of any type/or requests of any type/ s18.32, para 4: s/to a session context exist/to a session context exists/ s18.39, para 2: Strictly 'fragment' should be 'fragment identifier'. s18.40, para 1: s/that takes time/that take time/; s/such a/such as/ s18.41, para 1: s/the Supported/the Supported message-header/ s18.41: It appears from a literal interpretation (the third sentence is an unqualified MUST) that the responder has to respond with error code 551 and an (empty?) list of Unsupported features if it actually does support all the features. I suspect this is not what is wanted. s18.43, para 2: s/result in that a client needs/result in a client needing/; s/Also functionality as informing/Also functionality that informs/ s18.43, para 3: s/also the Range header MUST be included/the Range header MUST also be included/ s18.43, para 9: It might be wise to explicitly expand the NTP acronym even though it is well-known - its a long distance since the doc told us not to confuse NPT and NTP. s18.45, para 4: Harummph! Political Correctness strikes again. Every protocol should (and probably does) have a CRAP policy. ;-) s18.50, Session-Timeout para: s/is kept alive/has been kept alive/ s18.50, time para: s/will stop provide/will stop providing/ s18.52, 1st 'No dest_addr' para: s/send media to same address for which/send media to the same address from which/ s18.52, 2nd dest_addr para: Expand DoS acronym. s18.52, 'unicast/multicast' para: s/transmission needs/transmission need/ s18.52, bottom of page 168: OLD: The host address part of the tuple MAY be empty, for example ":58044", in cases when only destination port is desired to be specified. NEW: The host address part of the tuple MAY be empty, for example ":58044", in cases when it is desired to specify only the destination port. s18.52, 2nd para of src_addr section on page 169: s/media streams data packets/media stream's data packets/ (I think there is only one implied - could be "data streams'" if many). s18.52, 'setup' section: There seems to be some inconsistency in the spcification of the 'active/passive/actpass' values. a) Is there some reason for specifying them in square brackets? b) should they say ["active:"] or ["active":] - both formats are used? The ABNF has the plain words with no brackets or quotes. 18.52, 'connection' section, 1st line: s/Clients use the setup parameter/Clients use the connection parameter/ (I assume). s19.2, para 1: s/both on URI level and port level/both on the URI level and the port level/ s19.3, para 2: s/the client and server also needs to be aware/the client and server also need to be aware/ s19.3.1, 'Any' para: s/accept whatever certificate presented/accept whatever certificate is presented/ s19.3.1, 'Proxy' para: s/;/:/ s20: Proxy-Authorization seems to be missing from the ABNF altogether. s20.2.1, 'smpte-range' production: The reference should be to Section 4.4 I think - there is no Section 3.4 and s4.4 talks about SMPTE. The next four comments are inconsistencies that need sorting out: s20.2.2: Accept-Ranges and RTP-Info are classified as general headers in Table 1 but appears in response-header here. s20.2.2: User-Agent is classified as a request header in Table 3 but appears in general-header here. s20.2.2: Server is classified as a response header in Table 5 but appears in general-header here. s20.2.2: Accept-Credentials is classified as a request header in Table 3 but appears in response-header here. s20.2.2, response-header production: Alphabetic sort fails at MTag/Location. :-( s21, para 2: s/appendix/an appendix/; s/the media security/media security/ s21.1, Abuse of Server Logs: [H15.1.1] doesn't really give much advice beyond what is said here already. One could copy the one sentence of 'mind out for the lawyers' advice here and save the indirection. s21.1, transfer of sensitive info: Is there an equivalent of the Referer header in RTSP? Not sure there is but it would be good to explain one way or the other (either there isn't one so it's less of a problem or this is the equivalent...) s21.1, Attacks based on file names etc: The reference should be to [H15.2]. s21.1, DNS Spoofing: Presumably RTSP will interact significantly with content delivery networks. Some of these work by DNS 'spoofing' that was in its infancy when RFC 2616 was published. Are there any other issues that come out of the greater prevalence of CDNs since 1999? s21.1, Session Hijacking: The last part of this is written so that it appears to mandate authentication in all cases. As far as I understand it is up to the client to decide if it needs authentication etc and some content will be offered on unsecured URIs. I think this needs to be clearer that authentication will mitigate the problem but whether it is done is up to the client if the server doesn't care. s21.1, Persistently suspicious behaviour: There seems to be a mismatch between the title (persistently..) and the first sentence (a single instance). Do we have examples of the sort of security risk which is supposed to be met with a 403 response the first time? s21.1, last para: s/will be present by following the specification as written,/will be instantiated if the specification is implemented as written,/; s/prevent session hijacking/minimize the risk of session hijacking/; s/strongly improved/greatly improved/ s21.1, last sentence: > Some of the above threats are such that > the implementation of the RTSP functionality itself needs to consider > which policy and strategy it uses to mitigate them. It strikes me that this is not very helpful to a prospective implementer. The point of this section is at least in part to provide that policy and strategy. I am not quite sure how to rewrite this (or if indeed other people think it does need rewriting). s21.2, para 1: s/like RTP/such as RTP,/; s/that exist/exist/ s21.2, Media Confidentiality: s/Thus also the signaling protocol must/Thus the signaling protocol must also/ s21.2, Media Integity amd Auth: s/will have interest to substitute/will be interested in substituting/ s21.2, Scope of Multicast: s/it is needed to consider the scope that delivery has./the scope of the delivery must be considered./ s21.2.1, para 1: s/ascertaining the attackers/ascertaining the attacker's/ s21.2.1, para 1: > Security mechanisms > that are acceptable in an increased generality are: ^^^^^^^^^^^^^^^^^^^^^^^^^^ Does this mean 'in order of increasing generality'? s21.2.1, 2nd bullet: s/that accept to be/that have consented to be/ s21.2.1, last para on p204: Expand ICE acronym. (NAT is well-known). s21.2.1, first para on p205: s/username/a username/; Expand STUN acronym s21.2.2, RTP/RTCP Extensions: s/and disrupt video/and disruption of video/ s21.2.2, next to last para: OLD: it is clear that strong security mechanism to protect RTP is necessary to support. NEW: it is clear that it is necessary that a strong security mechanism is supported to protect RTP. s21.2.2, last para: s/beyond the mandatory to implement/beyond those mandatory to implement/ s22: Ought to have the standard note about replacing RFCXXXX with the number of the document when approved... s22, para 2: s/follow the below defined procedure/follow the procedure defined below/ s22, para 3: s/some of the requirements level/some of the registration policies/ s22.1.3: References back to the sections which define the play.xx feature tags should be added. As previously stated, I am not entirely sure what the required features are to meet the play.basic requirements. s22.2.1: s/Methods are described in Section Section/RTSP Methods are described in Section/ s22.3: The rules about allocating in the sections above x50 should be explained here (see s8.1.1). The numbers below x50 in each section should be marked as a special category of reserved so they are only allocated to HTTP analogues. Is an experimental/private segment in each category desirable? s22.9: Being allowed to register new Range header formats will currently be restricted to times specified by NPT, SMPTE or UTC because no registry is defined for Accept-Ranges. Is this what is intended?