Real-Time Streaming Protocol Version 2.0
draft-ietf-mmusic-rfc2326bis-40
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2016-12-15
|
40 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2016-03-02
|
40 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2016-02-21
|
40 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2016-02-16
|
40 | (System) | RFC Editor state changed to EDIT from AUTH |
2015-12-09
|
40 | (System) | RFC Editor state changed to AUTH from EDIT |
2015-10-14
|
40 | (System) | Notify list changed from mmusic-chairs@ietf.org, draft-ietf-mmusic-rfc2326bis@ietf.org to (None) |
2015-10-13
|
40 | (System) | RFC Editor state changed to EDIT from MISSREF |
2015-10-12
|
40 | Alissa Cooper | Ballot writeup was changed |
2015-10-12
|
40 | Alissa Cooper | Shepherding AD changed to Alissa Cooper |
2015-07-02
|
40 | (System) | RFC Editor state changed to MISSREF from EDIT |
2015-07-02
|
40 | (System) | RFC Editor state changed to EDIT from MISSREF |
2014-04-28
|
(System) | Posted related IPR disclosure: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-mmusic-rfc2326bis-40 | |
2014-03-05
|
40 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2014-03-04
|
40 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2014-03-03
|
40 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2014-03-03
|
40 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2014-02-21
|
40 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2014-02-17
|
40 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2014-02-14
|
40 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2014-02-12
|
40 | Amy Vezza | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2014-02-12
|
40 | (System) | RFC Editor state changed to MISSREF |
2014-02-12
|
40 | (System) | Announcement was received by RFC Editor |
2014-02-11
|
40 | (System) | IANA Action state changed to In Progress |
2014-02-11
|
40 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2014-02-11
|
40 | Amy Vezza | IESG has approved the document |
2014-02-11
|
40 | Amy Vezza | Closed "Approve" ballot |
2014-02-11
|
40 | Amy Vezza | Ballot approval text was generated |
2014-02-11
|
40 | Amy Vezza | IESG state changed to Approved-announcement to be sent from IESG Evaluation - Defer::AD Followup |
2014-02-11
|
40 | Gonzalo Camarillo | Ballot writeup was changed |
2014-02-10
|
40 | Magnus Westerlund | New version available: draft-ietf-mmusic-rfc2326bis-40.txt |
2014-02-03
|
39 | Brian Haberman | [Ballot comment] I managed to slog through this beast and am balloting No-Obj on the basis that I do not see any functionality that impacts … [Ballot comment] I managed to slog through this beast and am balloting No-Obj on the basis that I do not see any functionality that impacts Internet Area protocols. I fully support the comments by other ADs that: 1. it seems improbable that two independent implementations would interoperate 2. the size and complexity of the spec makes it nigh unreadable |
2014-02-03
|
39 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2014-01-28
|
39 | Stephen Farrell | [Ballot comment] -- These used to be discuss points (4) 19 - Why is there no equivalent of HTTP CONNECT for TLS? It seems like … [Ballot comment] -- These used to be discuss points (4) 19 - Why is there no equivalent of HTTP CONNECT for TLS? It seems like the choices are to either connect directly over TLS to the origin server or else to have to use a proxy that sees all the plaintext and headers. (5) 19.2 - 2nd last para: Why don't you use SNI here? Just wondering, but it'd fix a problem if it worked. The authors response was that they hadn't been considered and its too late in the day now but that they could be investigated further later if needed. I think that's a shame and means that we're consciously not doing as well at security as we might. However, I also accept that this draft has been on the go since 2002 already so its not likely to undergo any radical change now. if there's a way to add a mention of these points as possible future work that'd be niice. -- old coments - If a [HX.Y] reference to 2616 has been updated or changed by httpbis (which is on the telechat agenda after this one) then is it correct for RTSP to still refer to 2616? I could imagine that the answer might vary in each case. Has someone checked if any such discrepencies exist between this, 2616 and httpbis? (I could understand that that'd have been an unreasonable question right up until now when httpbis has completed IETF LC.) - 2.1 - is this versioning scheme really still valid? It doesn't sound like it. If its not, then it might be good to say that so folks don't write code that assumes things will work like this in future. - 4.3 - I don't believe you can confirm that something "MUST be chosen cryptographically random" since it could always be "Ri=E(k,Ri-1)" which will look but not be random. - 5.2 - Its probably defined somewhere but is there a way to make a very long header field, e.g. like a DKIM signature? - 8.2 - I don't understand how its safe to treat an unrecognised response header as a message body header. That seems hacky and likely to encourage hacks. And I don't recall that being said for request header fields. - 10.2 - what are classifiers in n/w monitoring tools? - 10.4 - typo: "taking long time" - 10.4 - the "agent SHOULD establish a new connection" as a mitigation makes no sense to me - how would a server (say) know where to connect to a proxy? (Which might be behind a CGN who knows.) - 10.5 - doesn't this assume that the RTSP and RTCP/RTP server sides can communicate, but how can a client know that? - 10.5 - is "or when using reliable protocols" still needed? - 11.1 - 1st para: I've no idea what the last sentence there is meant to mean. - 13.3.1 - if I can change my transport parameters isn't that a potential DoS vector? - 13.9 - is there any chance someone will extend SET_PARAMETER in a dangerous way? e.g. to allow: C->S: SET_PARAMETER rtsp://eg.com/../etc/passwd RTSP/2.0 ... root:x:0:0:root:/root:/bin/bash - 13.9 - pity you'd used 451 already - Tim Bray's HTTP 451 is cute! - 13.10 - is REDIRECT all ok with authentication? e.g. there's no statement that the same dictionary attackable equivalent for HTTP Basic or Digest MUST be sent if the server redirects, etc. - 13.10 - I don't get what it'd mean for a client to send a REDIRECT or does "The proxy is responsible for accepting REDIRECT responses from its clients" mean something else? - 14 - interleaved binary data, hmmm - buffer overrun thoughts, lots of lovely complexity... - 18.4.31-34 - I don't get the 466/470/471 errors, can you explain? - 18.7 - again, maybe reference httpbis? - 18.10 - You don't say whether (D)TLS application PDU padding is included or not, nor if this can be sent over TCP. - 20 - I skipped the ABNF sorry:-) - 21.2.1: I don't see how "Thus, an RTSP server MUST only allow client-specified destinations for RTSP-initiated traffic flows if the server has ensured that the specified destination address accepts receiving media through different security mechanisms" can be implemented really. - 21.2.1 - Doesn't that make [I-D.ietf-mmusic-rtsp-nat] normative as you're saying its a solution for remote DoS? |
2014-01-28
|
39 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2014-01-22
|
39 | Barry Leiba | [Ballot comment] UPDATE: Version -39 addresses my DISCUSS points, and most of my COMMENTs -- THANKS! I still don't see an RFC Editor note, so … [Ballot comment] UPDATE: Version -39 addresses my DISCUSS points, and most of my COMMENTs -- THANKS! I still don't see an RFC Editor note, so I'm leaving that comment. Also, below I'm leaving my comments that I see have not been addressed. Maybe that was intentional, but maybe, with all the comments, that was an oversight. They're all non-blocking, but I do think they're changes that should be made. I'll say no more about them, though. (I've also added comments for sections 15 and 16, which I hadn't reviewed yet when I posted my other comments.) I have not reviewed beyond Section 16, and I had hoped to do so. That said, it's not fair for me to hold anything up for that, especially as I have a lot of other things going on. That does sort of get into Pete's comment, that the document is too long to get thorough and complete review. Waddyagonnado? ======================================================== First, a comment for the responsible AD: The grammar, punctuation, and English usage in Section 2 and its subsections is at times very hard to sort through. I'm going to call out in the comments some bits that I found particularly troublesome, and will try to suggest alternatives. I also suggest that the responsible AD put in an RFC Editor note asking the editors to pay particular attention here and to give it some heavy editing for language clarity. This is a complex document, and a good overview in clear English will really help. Here's a suggestion for text for an RFC Editor note: ------------------------------ RFC Editor note: Section 2 of this document and its subsections provide "an informative overview of the different mechanisms in the RTSP 2.0 protocol, to give the reader a high level understanding". As such, it's very important that it be clear and well written. Some reviewers have found the English to be difficult. Please take an especially critical pen to this section, making sure that the grammar and usage are correct, and that the language is clear. ------------------------------ Comments that have not been addressed in -39: -- Section 4.7.2 -- The following different media retention policies are envisioned and taken into consideration where applicable: What is that meant to be saying, really? Please rephrase it (I have no idea what "and taken into consideration where applicable" might mean). Time-Duration: Each individual unit of the media will be retained for the specified duration. What does "each individual unit of the media" mean? -- Section 4.7.3 -- Dynamic: Between explicit updates the media content will not change, but the content may change due to external methods or triggers, such as playlists. This sounds like doubletalk: it won't change, but it may change. I think it needs re-wording. -- Section 4.7.5 -- It appears that you're mixing example headings (which contain colons) on the same line as header fields (which contain colons), making the whole thing unclear. I suggest putting the example title on its own line, then starting the example on a new line, like this: Example of "On-demand": Random Access: Random-Access=5.0, Content Modifications: Immutable, Retention: Unlimited or Time-Limited. -- Section 5.1 -- In the interest of robustness, agents MUST ignore any empty line(s) received where a Request-Line or Response-Line is expected. In other words, if the agent is reading the protocol stream at the beginning of a message and receives a CRLF first, it MUST ignore the CRLF. What's a "Response-Line"? I also presume the last sentence above is applicable recursively (you want to ignore any number of leading CRLF sequences), yes? Might be good to be clear about that. -- Section 9.3 -- HTTP and email have both historically had horrendous problems with inaccurate or missing Content-Type headers. It's good that you use MUST for Content-Type; that has to help. I would be happier (though not at DISCUSS level) if you should say a few more words about Content-Type here: something about how it MUST accurately specify the type and subtype of the content, that there are no defaults for type or subtype, and that attempts to use heuristics to second-guess this are Very Bad. -- Section 10.2 -- The scheme of the RTSP URI (Section 4.2) indicates the default port that the server will listen on if the port is not explicitly given. The URI is created by the client, not the server, so it doesn't specify what port the server "will listen on." It specifies the port the client will contact the server on. I would say it this way: NEW The scheme of the RTSP URI (Section 4.2) allows the client to specify the port it will contact the server on, and defines the default port to use if one is not explicitly given. END This port may provide some benefits from non-registered ports if a RTSP server is unable to use the default ports. I think you mean "some benefits over non-registered ports". "Over", not "from". authorize a client establishing a new connection as being a legitimate receiver of a request related to a particular RTSP session without the client first issuing requests related to the request. There's a lot of "request" in there, and it's confusing. Maybe this?: NEW authorize a client establishing a new connection as being a legitimate receiver of a request related to an existing RTSP session, without the client first issuing new requests related to the pending request. END To avoid this problem an RTSP agent is recommended to buffer incoming messages locally so that any response messages can be processed immediately upon reception. Thus doesn't make sense to me. If you're buffering them, you're not processing each one immediately, right? You won't process a message until it has its turn to be popped out of the buffer. What are you really trying to say here? -- Section 10.7 -- However, this can cause the situation where multiple RTSP clients again send requests to a proxy or server at roughly the same time which may again cause an overload situation, or if the "old" overload situation is not yet solved, i.e., the length indicated in the Retry- After header was too short. I can't parse this (in particular, I can't make sense of what comes after ", or if"); please try re-wording, probably splitting the too-long sentence in the process. A more complex case may arise when a load balancing RTSP proxy is in use, i.e., where an RTSP proxy is used to select amongst a set of RTSP servers to handle the requests, or when multiple server addresses are available for a given server name. Here's an example of a problem with using "i.e.": I can't tell what the scope of the "i.e." is. Is it the rest of the sentence ["X (i.e., A, or B)"], or is it just the first part ["X (i.e., A), or B"] ? Please clarify the text. It is REQUIRED to not set the same value in the timer for each scheduling, but instead to add a variation to the mean value, resulting in picking a random value within the range of 0.5 to 1.5 of the mean value. Is this meant to say "0.5 to 1.5 *times* the mean value? "Of" doesn't do that. -- Section 13.5 -- PLAY_NOTIFY requests MAY be used with a message body, depending on the value of the Notify-Reason header. It is described in the particular section for each Notify-Reason if a message body is used. However, currently there is no Notify-Reason that allows using a message body. That last sentence should be a clue that the "MAY" here is wrong. You're not describing an option for the implementor. Depending upon the value of Notify-Reason, either a body is needed or it isn't. You can make this "may", or, better, "will sometimes". -- Section 15.1 -- However, it is important to consider if this header and its function is required to be understood by the proxy or can be forwarded. If the header needs to be understood, a feature-tag representing the functionality MUST be included in the Proxy-Require header. Below are guidelines for analysis if the header needs to be understood. In the first sentence, I think you mean, "or can simply be forwarded." That sense is lost without the word "simply". In the last sentence, the guidelines aren't for application only if the header need to be understood; they're guidelines to determine that. So, "Below are guidelines for analyzing whether the header needs to be understood." The transport header and its parameters also shows that headers that are extensible and require correct interpretation in the proxy also require handling rules. I don't understand this sentence at all. Can you try re-wording it? Transport modifying: The access and the security proxy both need to understand how the transport is performed, either for opening pinholes or to translate the outer headers, e.g., IP and UDP. RTSP 2.0 isn't using UDP, right? So what's that about? -- Section 16.1.1 -- In simple terms, a cache entry is considered to be valid if the content has not been modified since the Last-Modified value. Strikes me as too simple, and wrong. It's not possible for either the streamed or the cached data to have been modified since the Last-Modified value. What I think you mean to say is, "if the cache entry was created after the Last-Modified time." |
2014-01-22
|
39 | Barry Leiba | [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss |
2014-01-17
|
39 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2014-01-17
|
39 | Magnus Westerlund | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2014-01-17
|
39 | Magnus Westerlund | New version available: draft-ietf-mmusic-rfc2326bis-39.txt |
2013-12-18
|
38 | Gunter Van de Velde | Closed request for Telechat review by OPSDIR with state 'No Response' |
2013-12-05
|
38 | Cindy Morgan | State changed to IESG Evaluation - Defer::Revised I-D Needed from IESG Evaluation - Defer |
2013-12-05
|
38 | Tero Kivinen | Request for Telechat review by SECDIR Completed: Ready. Reviewer: Chris Lonvick. |
2013-12-05
|
38 | Benoît Claise | [Ballot comment] So I went for "no record". There are three reasons for that. 1. I want to stress that having a 322 pages document … [Ballot comment] So I went for "no record". There are three reasons for that. 1. I want to stress that having a 322 pages document is not practical. (Did I say ridiculous, no? ... Maybe I'm thinking too loud...) At some point in time, the IESG might have to think about limiting the number of pages an AD has to read as preparation for the IESG telechat, and not the number of documents. For the same amount of pages (read time spent), I personally preferred to read all the other documents, and improve their quality, as opposed to review a single document. And yes, I spend 100% of my time on this AD job. 2. I did a very high level OPS check, basically doing OPS keyword searching. When I compare the time spent versus the number of pages, this is so minimal that it can't be qualified as a review. I understand that the IESG shouldn't be the bottleneck, but simply selecting "no objection" while very little review has been done is not the right way IMHO. 3. Finally, I could not find an OPS-DIR reviewer. Guess why? So I prefer to clearly express that I have not done a review for this document. This feedback is not actionable by the authors. |
2013-12-05
|
38 | Benoît Claise | Ballot comment text updated for Benoit Claise |
2013-12-05
|
38 | Benoît Claise | [Ballot comment] So I went for "no record". There are three reasons for that. 1. I want to stress that having a 322 pages document … [Ballot comment] So I went for "no record". There are three reasons for that. 1. I want to stress that having a 322 pages document is not practical. (Did I say ridiculous, no? ... Maybe I'm thinking too loud...) At some point in time, the IESG might have to think about limiting the number of pages an AD has to read as preparation for the IESG telechat, and not the number of documents. For the same amount of pages (read time spent), I personally preferred to read all the other documents, and improve their quality, as opposed to review a single document. And yes, I spend 100% of my time on this AD job. 2. I did a very high level OPS check, basically doing OPS keyword searching. When I compare the time spent versus the number of pages, this is so minimal that it can't be qualified as a review. I understand that the IESG shouldn't be the bottleneck, but simply selecting "no objection" while very little review has been done is not the right way IMHO. 3. Finally, I could not find an OPS-DIR reviewer. Guess why? This feedback is not actionable by the authors. |
2013-12-05
|
38 | Benoît Claise | Ballot comment text updated for Benoit Claise |
2013-12-05
|
38 | Stephen Farrell | [Ballot discuss] I didn't look back at 2326 since the diff wasn't really useful so feel free to ignore any comment that would equally apply … [Ballot discuss] I didn't look back at 2326 since the diff wasn't really useful so feel free to ignore any comment that would equally apply to the earlier RFC. The security considerations section for the bis draft is very thorough thanks! But I still have a few things I'd like to discuss (sorry;-). Discuss point #1 is the main thing though, if we resolve that, then the others should be easy to clear up. (1) 21.1 - "transfer of sensitive information" - I think you need to say here that RTSP *is* less sensitive than HTTP and that's why its ok to have the hop-by-hop scheme. HTTP is more sensitive because users commonly input or read much more sensitive information in HTTP exchanges, e.g. HTTP requests often contain passwords, cookies, cardholder data and responses often contain bank account details, healthcare data, none of which is transported via RTSP. If that is true, then the hop-by-hop scheme is much more reasonable and saying so is important and should help clear my discuss much more easliy. If that is not true (i.e. if really sensitive user information is commonly sent via RTSP) then we need to talk more. (2) 15 - "This proxy can also limit the client's access to certain types of content." That's not a security function but really a censorship function, at least as stated. I suggest deleting the sentence, or changing it to one that's suitable. (3) 18.8 - is this saying that a 2nd request for the same thing won't need to be authenticated even if that was required for the first request? If not, that's not clear to me. (4) 19 - Why is there no equivalent of HTTP CONNECT for TLS? It seems like the choices are to either connect directly over TLS to the origin server or else to have to use a proxy that sees all the plaintext and headers. (5) 19.2 - 2nd last para: Why don't you use SNI here? Just wondering, but it'd fix a problem if it worked. (6) 19.3 - I think you need to say here (or somewhere) that all TLS "hops" MUST have commensurate security. (7) 19.3.2 - how is a user supposed to practically "approve" a proxy with just e.g. an IP address? That seems meaningless. (8) 21.1 - Location headers and spoofing - I don't get how the "if" that preceeds the MUST here can be implemented. |
2013-12-05
|
38 | Stephen Farrell | [Ballot comment] - If a [HX.Y] reference to 2616 has been updated or changed by httpbis (which is on the telechat agenda after this one) … [Ballot comment] - If a [HX.Y] reference to 2616 has been updated or changed by httpbis (which is on the telechat agenda after this one) then is it correct for RTSP to still refer to 2616? I could imagine that the answer might vary in each case. Has someone checked if any such discrepencies exist between this, 2616 and httpbis? (I could understand that that'd have been an unreasonable question right up until now when httpbis has completed IETF LC.) - 2.1 - is this versioning scheme really still valid? It doesn't sound like it. If its not, then it might be good to say that so folks don't write code that assumes things will work like this in future. - 4.3 - I don't believe you can confirm that something "MUST be chosen cryptographically random" since it could always be "Ri=E(k,Ri-1)" which will look but not be random. - 5.2 - Its probably defined somewhere but is there a way to make a very long header field, e.g. like a DKIM signature? - 8.2 - I don't understand how its safe to treat an unrecognised response header as a message body header. That seems hacky and likely to encourage hacks. And I don't recall that being said for request header fields. - 10.2 - what are classifiers in n/w monitoring tools? - 10.4 - typo: "taking long time" - 10.4 - the "agent SHOULD establish a new connection" as a mitigation makes no sense to me - how would a server (say) know where to connect to a proxy? (Which might be behind a CGN who knows.) - 10.5 - doesn't this assume that the RTSP and RTCP/RTP server sides can communicate, but how can a client know that? - 10.5 - is "or when using reliable protocols" still needed? - 11.1 - 1st para: I've no idea what the last sentence there is meant to mean. - 13.3.1 - if I can change my transport parameters isn't that a potential DoS vector? - 13.9 - is there any chance someone will extend SET_PARAMETER in a dangerous way? e.g. to allow: C->S: SET_PARAMETER rtsp://eg.com/../etc/passwd RTSP/2.0 ... root:x:0:0:root:/root:/bin/bash - 13.9 - pity you'd used 451 already - Tim Bray's HTTP 451 is cute! - 13.10 - is REDIRECT all ok with authentication? e.g. there's no statement that the same dictionary attackable equivalent for HTTP Basic or Digest MUST be sent if the server redirects, etc. - 13.10 - I don't get what it'd mean for a client to send a REDIRECT or does "The proxy is responsible for accepting REDIRECT responses from its clients" mean something else? - 14 - interleaved binary data, hmmm - buffer overrun thoughts, lots of lovely complexity... - 18.4.31-34 - I don't get the 466/470/471 errors, can you explain? - 18.7 - again, maybe reference httpbis? - 18.10 - You don't say whether (D)TLS application PDU padding is included or not, nor if this can be sent over TCP. - 20 - I skipped the ABNF sorry:-) - 21.2.1: I don't see how "Thus, an RTSP server MUST only allow client-specified destinations for RTSP-initiated traffic flows if the server has ensured that the specified destination address accepts receiving media through different security mechanisms" can be implemented really. - 21.2.1 - Doesn't that make [I-D.ietf-mmusic-rtsp-nat] normative as you're saying its a solution for remote DoS? |
2013-12-05
|
38 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2013-12-04
|
38 | Pete Resnick | [Ballot comment] I have reviewed as much as I reasonably could. This first comment is more for the IESG than the authors; I don't think … [Ballot comment] I have reviewed as much as I reasonably could. This first comment is more for the IESG than the authors; I don't think the authors can really do anything about this now: I have a really hard time believing that a document of this size could possibly be independently implementable. There is simply no way that this document got the kind of review by enough eyeballs to be able to claim it is "generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable." And the fact that there is only one implementation of this does not give me confidence. Robert's GenArt review makes it clear that, due to the length and structure of the document, he has concerns about interoperable implementation. Elwyn did a yeoman's job in his GenArt review, and though he is satisfied that his concerns were addressed, there are still many significant issues: Barry also did a detailed review and has found several problems, and I've got more below. We know that secdir did not do a comprehensive review of this document. I have done a review of this spec at high speed, and therefore at a completely cursory level, and I know that other ADs are in the same boat. I feel that spending the time that would really be needed for a full review would be unfair to other important documents. I don't know how this thing was left to continue for 11 years, to go from an already hefty 90 page document at -00 to this 320 page monstrosity, without it being stopped earlier and at least broken into pieces. Even the document writeup indicates that later versions have not seen WG participation, that the authors have really been the only ones tracking it recently, and that the only thing that can be claimed is "no indication of lack of consensus"; that's not exactly a ringing endorsement. I don't know how, in good conscience, the IESG can move this document forward as representing the consensus of the WG, let alone the consensus of the IETF as a whole. It seems to me that the process failed long ago for this document. And I don't know what, if anything, we can do about it at this point. Substantive comments: Section 1: Strike, ", similar to the remote control for a DVD player" and ", as known from DVD players remote control or media players". They're anachronistic. In the discussion of changes from 1.0, I would mention that greenfield implementations should use 2.0 since 1.0 is incomplete. Section 2.6: "however, it is recommended to release the session context". The client or the server? I hope "it is recommended that the client release the session context". I hate when servers tear down sessions even when I am sending a keep-alive. The server may certainly tear it down if it needs the resources, but the document shouldn't recommend that it be torn down. Section 10.2: The RTSP agent SHALL NOT use more than one connection per RTSP session at any given point. The explanation given later does not justify the SHALL NOT. It certainly is useful for the server to only use a single connection, but I see no justification for the REQUIREment. A server that attempts to send a request to a client that has no connection currently to the server SHALL discard the request directly. I don't know what the word "directly" means here. Can you simply strike it, or is it meaningful? Sections 14-16: These seem more like appendices or a separate document rather than part of the main protocol. Section 16: This section uses the "we" convention from academic papers. This is distracting and a strange affectation. Please change to "This document", or in some cases simply rewrite the sentence. Section 17.1: Title should be "Continue", not "Success". Section 17.3: '3rr' is used to distinguish it from HTTP usage of '3xx'? If so, you should say that. Don't all 3rr responses require a Location? If so, put that instruction here, not in 17.3.3. Also, the generic instruction to use 302 for unknown 3rr is probably better here rather than in 17.3.1. Section 18.20: "The initial sequence number MAY be any number, however, it is RECOMMENDED to start at 0." That MAY is wrong. Change to "can". Section 18.21: You say that you are using "a full date as specified by Section 3.3 of [RFC5322]". I presume that you are *not* including the obsolete syntax. You should probably say that explicitly. However, the 5322 3.3 syntax without the obsolete forms does not allow for the alphabetic time zones like "GMT". It only permits the numeric time zones. If you really want to do that, you should change the examples in throughout the document to "+0000". Otherwise, you could explicitly allow obs-zone, but not the rest. Also, be aware that 5322 3.3 syntax is allowed to end with CFWS. Are you OK with that? (Note again: I did not scrub the ABNF. These are only the things I found from a quick review.) Section 20.1: Is there a reason for not just importing the 5234 core rules? UTF8-NONASCII = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4 UTF8-1 = That's wrong. You want to strike UTF8-1 and just say: "UTF8-NONASCII = UTF8-2 / UTF8-3 / UTF8-4" UTF8-CONT is unnecessary. You should use UTF8-tail, which is defined in 3629. The only two places it appears are in header-value (more on that below) and in Appendix F, which should be using the UTF8-NONASCII syntax from here, not re-creating it. Section 20.2.1: Do you really want header-value to have UTF8-CONT freely distributed? That seems wrong. I think UTF8-CONT probably should be struck. (If you want to allow any octet, not part of a UTF-8 sequence, and not ASCII controls, use TEXT instead.) Section 22: I find 2119 in IANA Considerations sections problematic. There shouldn't be 2119 requirements on IANA, and they are silly uses of the words when applied to registrants or expert reviewers; in all cases, they simply allow this document to avoid saying who is responsible for enforcing the rule. Please get rid of them throughout this section and its subsections, and make it clear whether "IANA needs to collect the following information" or "Section XYZ of this document requires that the entry is of such and so format" or "Registrants are asked to do blah blah blah" or "Expert Reviewers should confirm that the following information is in the registration", etc. Specific changes in the main Section 22: OLD it MUST follow the procedure NEW registrants need to follow the procedure OLD A registration request to IANA MUST contain the following information: NEW IANA needs to obtain the following information for any registration request: (This one is especially silly because some of the items are not actually required.) Section 22.1.2: - Capitalize "first come, first served", and perhaps cite 5226. - You cannot have a SHOULD on the length of the name on a FCFS registry. IANA has no way to decide exceptions to such a rule. Either make a maximum length, or don't. - The reference to "first part" of the feature-tag doesn't make sense as syntactically feature-tags don't have parts. I suggest something like this as a rewrite for the second paragraph: The registry entry for a feature-tag has the following information: - The name of the feature-tag - If the registrant indicates that the feature is proprietary, IANA should request a vendor "prefix" portion of the name. The name will then be the vendor prefix followed by a "." followed by the rest of the provided feature name. - If the feature is not proprietary, then IANA need not collect a prefix for the name. - A one paragraph description of what the feature-tag represents - The applicability (server, client, proxy, or some combination) - A reference to a specification, if applicable Feature-tag names (including the vendor prefix) may contain any non-space and non-control characters. There is no length limit on feature-tags, though registrants may want to limit their length to twenty characters because...? [Etc.] Section 22.2.2: Strike the MUSTs and the SHOULD. The first sentence should simply be "The registration policy for new RTSP methods is Standards Action [RFC5226]." Please have a go of fixing these kinds of issues throughout Section 22. Appendix F: OLD TEXT-UTF8char = %x21-7E / UTF8-NONASCII UTF8-NONASCII = %xC0-DF 1UTF8-CONT / %xE0-EF 2UTF8-CONT / %xF0-F7 3UTF8-CONT / %xF8-FB 4UTF8-CONT / %xFC-FD 5UTF8-CONT UTF8-CONT = %x80-BF NEW TEXT-UTF8char = |
2013-12-04
|
38 | Pete Resnick | [Ballot Position Update] Position for Pete Resnick has been changed to Abstain from No Record |
2013-12-04
|
38 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2013-12-04
|
38 | Pete Resnick | [Ballot comment] [I still have quite a bit to go in what I am *able* to review. I still haven't decided what ballot position I … [Ballot comment] [I still have quite a bit to go in what I am *able* to review. I still haven't decided what ballot position I will take. But here's what I have so far. Most recent addition: Comments on Section 22.] This first comment is more for the IESG than the authors; I don't think the authors can really do anything about this now: I have a really hard time believing that a document of this size could possibly be independently implementable. There is simply no way that this document got the kind of review by enough eyeballs to be able to claim it is "generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable." And the fact that there is only one implementation of this does not give me confidence. Robert's GenArt review makes it clear that, due to the length and structure of the document, he has concerns about interoperable implementation. Elwyn did a yeoman's job in his GenArt review, and though he is satisfied that his concerns were addressed, there are still many significant issues: Barry also did a detailed review and has found several problems, and I've got more below. We know that secdir did not do a comprehensive review of this document. I have done a review of this spec at high speed, and therefore at a completely cursory level, and I know that other ADs are in the same boat. I feel that spending the time that would really be needed for a full review would be unfair to other important documents. I don't know how this thing was left to continue for 11 years, to go from an already hefty 90 page document at -00 to this 320 page monstrosity, without it being stopped earlier and at least broken into pieces. Even the document writeup indicates that later versions have not seen WG participation, that the authors have really been the only ones tracking it recently, and that the only thing that can be claimed is "no indication of lack of consensus"; that's not exactly a ringing endorsement. I don't know how, in good conscience, the IESG can move this document forward as representing the consensus of the WG, let alone the consensus of the IETF as a whole. It seems to me that the process failed long ago for this document. And I don't know what, if anything, we can do about it at this point. Substantive comments: Section 1: Strike, ", similar to the remote control for a DVD player" and ", as known from DVD players remote control or media players". They're anachronistic. In the discussion of changes from 1.0, I would mention that greenfield implementations should use 2.0 since 1.0 is incomplete. Section 2.6: "however, it is recommended to release the session context". The client or the server? I hope "it is recommended that the client release the session context". I hate when servers tear down sessions even when I am sending a keep-alive. The server may certainly tear it down if it needs the resources, but the document shouldn't recommend that it be torn down. Section 10.2: The RTSP agent SHALL NOT use more than one connection per RTSP session at any given point. The explanation given later does not justify the SHALL NOT. It certainly is useful for the server to only use a single connection, but I see no justification for the REQUIREment. A server that attempts to send a request to a client that has no connection currently to the server SHALL discard the request directly. I don't know what the word "directly" means here. Can you simply strike it, or is it meaningful? Sections 14-16: These seem more like appendices or a separate document rather than part of the main protocol. Section 16: This section uses the "we" convention from academic papers. This is distracting and a strange affectation. Please change to "This document", or in some cases simply rewrite the sentence. Section 17.1: Title should be "Continue", not "Success". Section 17.3: '3rr' is used to distinguish it from HTTP usage of '3xx'? If so, you should say that. Don't all 3rr responses require a Location? If so, put that instruction here, not in 17.3.3. Also, the generic instruction to use 302 for unknown 3rr is probably better here rather than in 17.3.1. Section 18.20: "The initial sequence number MAY be any number, however, it is RECOMMENDED to start at 0." That MAY is wrong. Change to "can". Section 18.21: You say that you are using "a full date as specified by Section 3.3 of [RFC5322]". I presume that you are *not* including the obsolete syntax. You should probably say that explicitly. However, the 5322 3.3 syntax without the obsolete forms does not allow for the alphabetic time zones like "GMT". It only permits the numeric time zones. If you really want to do that, you should change the examples in throughout the document to "+0000". Otherwise, you could explicitly allow obs-zone, but not the rest. Also, be aware that 5322 3.3 syntax is allowed to end with CFWS. Are you OK with that? (Note again: I did not scrub the ABNF. These are only the things I found from a quick review.) Section 20.1: Is there a reason for not just importing the 5234 core rules? UTF8-NONASCII = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4 UTF8-1 = That's wrong. You want to strike UTF8-1 and just say: "UTF8-NONASCII = UTF8-2 / UTF8-3 / UTF8-4" UTF8-CONT is unnecessary. You should use UTF8-tail, which is defined in 3629. The only two places it appears are in header-value (more on that below) and in Appendix F, which should be using the UTF8-NONASCII syntax from here, not re-creating it. Section 20.2.1: Do you really want header-value to have UTF8-CONT freely distributed? That seems wrong. I think UTF8-CONT probably should be struck. (If you want to allow any octet, not part of a UTF-8 sequence, and not ASCII controls, use TEXT instead.) Section 22: I find 2119 in IANA Considerations sections problematic. There shouldn't be 2119 requirements on IANA, and they are silly uses of the words when applied to registrants or expert reviewers; in all cases, they simply allow this document to avoid saying who is responsible for enforcing the rule. Please get rid of them throughout this section and its subsections, and make it clear whether "IANA needs to collect the following information" or "Section XYZ of this document requires that the entry is of such and so format" or "Registrants are asked to do blah blah blah" or "Expert Reviewers should confirm that the following information is in the registration", etc. Specific changes in the main Section 22: OLD it MUST follow the procedure NEW registrants need to follow the procedure OLD A registration request to IANA MUST contain the following information: NEW IANA needs to obtain the following information for any registration request: (This one is especially silly because some of the items are not actually required.) Section 22.1.2: - Capitalize "first come, first served", and perhaps cite 5226. - You cannot have a SHOULD on the length of the name on a FCFS registry. IANA has no way to decide exceptions to such a rule. Either make a maximum length, or don't. - The reference to "first part" of the feature-tag doesn't make sense as syntactically feature-tags don't have parts. I suggest something like this as a rewrite for the second paragraph: The registry entry for a feature-tag has the following information: - The name of the feature-tag - If the registrant indicates that the feature is proprietary, IANA should request a vendor "prefix" portion of the name. The name will then be the vendor prefix followed by a "." followed by the rest of the provided feature name. - If the feature is not proprietary, then IANA need not collect a prefix for the name. - A one paragraph description of what the feature-tag represents - The applicability (server, client, proxy, or some combination) - A reference to a specification, if applicable Feature-tag names (including the vendor prefix) may contain any non-space and non-control characters. There is no length limit on feature-tags, though registrants may want to limit their length to twenty characters because...? [Etc.] Section 22.2.2: Strike the MUSTs and the SHOULD. The first sentence should simply be "The registration policy for new RTSP methods is Standards Action [RFC5226]." Please have a go of fixing these kinds of issues throughout Section 22. |
2013-12-04
|
38 | Pete Resnick | Ballot comment text updated for Pete Resnick |
2013-12-04
|
38 | Spencer Dawkins | [Ballot comment] Just a couple of questions about section 10 ... In this text: 10. Connections RFC 2326 attempted to specify an optional mechanism … [Ballot comment] Just a couple of questions about section 10 ... In this text: 10. Connections RFC 2326 attempted to specify an optional mechanism for transmitting RTSP messages in connectionless mode over a transport protocol such as UDP. However, it was not specified in sufficient detail to allow for interoperable implementations. In an attempt to reduce complexity and scope, and due to lack of interest, RTSP 2.0 does not attempt to define a mechanism for supporting RTSP over UDP or other connectionless transport protocols. A side-effect of this is that RTSP requests MUST NOT be sent to multicast groups since no connection can be established with a specific receiver in multicast environments. Is this the right way to say this? (If you try to open a multicast connection to a TCP address, do you get far enough to "send an RTSP request"?) In this text: 10.3. Closing Connections A requester SHOULD wait at least 10 seconds for a response before concluding that the responder will not be responding to its request. After receiving a 100 response, the requester SHOULD continue waiting for further responses. If more than 10 seconds elapses without receiving any response, the requester MAY assume that the responder is unresponsive and abort the connection by closing the TCP connection. Would it be helpful to say anything about not immediately opening a new connection to the same unresponsive responder? |
2013-12-04
|
38 | Spencer Dawkins | Ballot comment text updated for Spencer Dawkins |
2013-12-04
|
38 | Spencer Dawkins | [Ballot comment] Just a couple of questions about section 10 ... In this text: 10. Connections RFC 2326 attempted to specify an optional mechanism … [Ballot comment] Just a couple of questions about section 10 ... In this text: 10. Connections RFC 2326 attempted to specify an optional mechanism for transmitting RTSP messages in connectionless mode over a transport protocol such as UDP. However, it was not specified in sufficient detail to allow for interoperable implementations. In an attempt to reduce complexity and scope, and due to lack of interest, RTSP 2.0 does not attempt to define a mechanism for supporting RTSP over UDP or other connectionless transport protocols. A side-effect of this is that RTSP requests MUST NOT be sent to multicast groups since no connection can be established with a specific receiver in multicast environments. Is this the right way to say this? (If you try to open a multicast connection to a TCP address, do you get far enough to "send an RTSP request"?) In this text: 10.3. Closing Connections A requester SHOULD wait at least 10 seconds for a response before concluding that the responder will not be responding to its request. After receiving a 100 response, the requester SHOULD continue waiting for further responses. If more than 10 seconds elapses without receiving any response, the requester MAY assume that the responder is unresponsive and abort the connection by closing the TCP connection. This ship may have sailed, but would it be helpful to say anything about not immediately opening a new connection to the same unresponsive responder? |
2013-12-04
|
38 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2013-12-04
|
38 | Pete Resnick | [Ballot comment] [I still have quite a bit to go in what I am *able* to review. I still haven't decided what ballot position I … [Ballot comment] [I still have quite a bit to go in what I am *able* to review. I still haven't decided what ballot position I will take. But here's what I have so far.] This first comment is more for the IESG than the authors; I don't think the authors can really do anything about this now: I have a really hard time believing that a document of this size could possibly be independently implementable. There is simply no way that this document got the kind of review by enough eyeballs to be able to claim it is "generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable." And the fact that there is only one implementation of this does not give me confidence. Robert's GenArt review makes it clear that, due to the length and structure of the document, he has concerns about interoperable implementation. Elwyn did a yeoman's job in his GenArt review, and though he is satisfied that his concerns were addressed, there are still many significant issues: Barry also did a detailed review and has found several problems, and I've got more below. We know that secdir did not do a comprehensive review of this document. I have done a review of this spec at high speed, and therefore at a completely cursory level, and I know that other ADs are in the same boat. I feel that spending the time that would really be needed for a full review would be unfair to other important documents. I don't know how this thing was left to continue for 11 years, to go from an already hefty 90 page document at -00 to this 320 page monstrosity, without it being stopped earlier and at least broken into pieces. Even the document writeup indicates that later versions have not seen WG participation, that the authors have really been the only ones tracking it recently, and that the only thing that can be claimed is "no indication of lack of consensus"; that's not exactly a ringing endorsement. I don't know how, in good conscience, the IESG can move this document forward as representing the consensus of the WG, let alone the consensus of the IETF as a whole. It seems to me that the process failed long ago for this document. And I don't know what, if anything, we can do about it at this point. Substantive comments: Section 1: Strike, ", similar to the remote control for a DVD player" and ", as known from DVD players remote control or media players". They're anachronistic. In the discussion of changes from 1.0, I would mention that greenfield implementations should use 2.0 since 1.0 is incomplete. Section 2.6: "however, it is recommended to release the session context". The client or the server? I hope "it is recommended that the client release the session context". I hate when servers tear down sessions even when I am sending a keep-alive. The server may certainly tear it down if it needs the resources, but the document shouldn't recommend that it be torn down. Section 10.2: The RTSP agent SHALL NOT use more than one connection per RTSP session at any given point. The explanation given later does not justify the SHALL NOT. It certainly is useful for the server to only use a single connection, but I see no justification for the REQUIREment. A server that attempts to send a request to a client that has no connection currently to the server SHALL discard the request directly. I don't know what the word "directly" means here. Can you simply strike it, or is it meaningful? Sections 14-16: These seem more like appendices or a separate document rather than part of the main protocol. Section 16: This section uses the "we" convention from academic papers. This is distracting and a strange affectation. Please change to "This document", or in some cases simply rewrite the sentence. Section 17.1: Title should be "Continue", not "Success". Section 17.3: '3rr' is used to distinguish it from HTTP usage of '3xx'? If so, you should say that. Don't all 3rr responses require a Location? If so, put that instruction here, not in 17.3.3. Also, the generic instruction to use 302 for unknown 3rr is probably better here rather than in 17.3.1. Section 18.20: "The initial sequence number MAY be any number, however, it is RECOMMENDED to start at 0." That MAY is wrong. Change to "can". Section 18.21: You say that you are using "a full date as specified by Section 3.3 of [RFC5322]". I presume that you are *not* including the obsolete syntax. You should probably say that explicitly. However, the 5322 3.3 syntax without the obsolete forms does not allow for the alphabetic time zones like "GMT". It only permits the numeric time zones. If you really want to do that, you should change the examples in throughout the document to "+0000". Otherwise, you could explicitly allow obs-zone, but not the rest. Also, be aware that 5322 3.3 syntax is allowed to end with CFWS. Are you OK with that? (Note again: I did not scrub the ABNF. These are only the things I found from a quick review.) Section 20.1: Is there a reason for not just importing the 5234 core rules? UTF8-NONASCII = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4 UTF8-1 = That's wrong. You want to strike UTF8-1 and just say: "UTF8-NONASCII = UTF8-2 / UTF8-3 / UTF8-4" UTF8-CONT is unnecessary. You should use UTF8-tail, which is defined in 3629. The only two places it appears are in header-value (more on that below) and in Appendix F, which should be using the UTF8-NONASCII syntax from here, not re-creating it. Section 20.2.1: Do you really want header-value to have UTF8-CONT freely distributed? That seems wrong. I think UTF8-CONT probably should be struck. (If you want to allow any octet, not part of a UTF-8 sequence, and not ASCII controls, use TEXT instead.) |
2013-12-04
|
38 | Pete Resnick | Ballot comment text updated for Pete Resnick |
2013-12-02
|
38 | Joel Jaeggli | [Ballot comment] I have reviewed this to the extent that I think reasonable. and I have few misgivings about the text that aren't editorial. I … [Ballot comment] I have reviewed this to the extent that I think reasonable. and I have few misgivings about the text that aren't editorial. I have a serious concern about the size and structure of the document. By my count it took something like 11 years to write this. I think is is rather problematic to attempt to be comprehensive within the scope of single document. Parts of this, the IANA regististries, the security model section, the header defintions, examples, use of SDP, and so on should be separate documents. We should not be repeating this experience, either from an editing, implementation or registry management standpoint. |
2013-12-02
|
38 | Joel Jaeggli | [Ballot Position Update] Position for Joel Jaeggli has been changed to No Objection from No Record |
2013-12-02
|
38 | Adrian Farrel | [Ballot comment] Looks to me like Barry may have reviewed some of the text. I looked and found nothing threatening to routing so I will … [Ballot comment] Looks to me like Barry may have reviewed some of the text. I looked and found nothing threatening to routing so I will ballot No Objection. I did note the following... In Section 18.21 you have some ambiguity in the instruction to the RFC Editor. It reads... Note: The RTSP 2.0 date format is defined to be the RFC 5322 full date format. This format is more flexible than the RFC 1123 date format used by RTSP 1.0. Thus implementations should use single spaces as recommended by RFC 5322 as separators and support receiving the obsolete format. [[RFC Editor please remove this note: Prior to version 37 of the draft, rfc2326bis envisaged sticking with the RFC 1123 format.]] I think you only want the Editor to remove the note in double square brackets. But placed where it is, the editor will think they have to remove the whole Note, which I doubt is what you want. |
2013-12-02
|
38 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2013-12-01
|
38 | Barry Leiba | [Ballot discuss] UPDATED: I have not finished reviewing yet: I'm just about to start Section 14 as I post this. I'm sure I'll have many … [Ballot discuss] UPDATED: I have not finished reviewing yet: I'm just about to start Section 14 as I post this. I'm sure I'll have many more comments, but I want to get some of this out here now, so the authors aren't entirely blindsided at the last minute. What I have so far follows, in both the DISCUSS and COMMENT sections. ----------------------------------------------------------- 1. This point falls into the "URI/IRI follies" category: -- Section 3.2 -- IRI: Internationalized Resource Identifier, is the same as a URI, with the exception that it allows characters from the whole Oh, my; please don't say that it's "the same as a URI". It'd be reasonable to say "is similar to a URI, but allows characters [etc]." -- Section 4.2 -- The RTSP URI and IRI are case sensitive, with the exception of those parts that [RFC3986] and [RFC3987] define as case-insensitive; for example, the scheme and host part. Clumping URIs and IRIs together in such a vague way with respect to case mapping is a dangerous thing. And unless there's a particular reason to say otherwise, it's easy to avoid that by specifically saying that the scheme and host parts are the *only* case-sensitive bits (which is true of generic URIs and IRIs anyway). Is there really a reason not to be clearer, this way?: NEW The "scheme" and "host" parts of all URIs [RFC3986] and IRIs [RFC3987] are case-insensitive. All other parts of RTSP URIs and IRIs are case- sensitive, and SHOULD NOT be case-mapped. END 2. The paragraph in Section 4.4.2 that explains npt-hhmmss notation and npt-sec notation has some internal inconsistencies that have to be fixed. See my suggestions in the comments section below, which goes beyond the blocking point (the inconsistency) and tries to make the paragraph more readable as well. 3. Two bits in Section 10.5: The mechanisms for showing liveness of the client is, any RTSP request with a Session header, if RTP & RTCP is used an RTCP message, or through any other used media protocol capable of indicating liveness of the RTSP client. The grammar and punctuation in that sentence is so fractured that I haven't the first idea what it means. It needs to be re-worded, and I can't help. SET_PARAMETER: When using SET_PARAMETER for keep-alive, a body SHOULD NOT be included. This method is the RECOMMENDED RTSP method to use for a request intended only to perform keep- alive. But a short bit above, in Section 10.4, you say this: The keep-alive request will normally be a GET_PARAMETER with a session header to inform the server that this agent cares about this RTSP session. If SET_PARAMETER is what's RECOMMENDED, then why do you say that it "will normally be" GET_PARAMETER? 4. In Section 11.1: Thus following all normative parts in the main sections (the ones with numbers), but omitting the appendices (starting with letters), unless explicitly specified in a main section as being a required appendix. This is not a complete sentence, so I can't figure it out. What do you mean to say here? You appear to be making some statement about the applicability of the document as a whole, yet that statement is buried down in Section 11.1. After turning this into a proper sentence, you might (depending upon what it really is that you're saying) need to promote it to someplace where it's earlier on and more obvious. On the section as a whole, and the meaning of the play.basic feature-tag: Am I to understand that this feature-tag is basically used to say, "I support the basic spec for RTSP 2.0." ? If so, that can (and should) be said a lot more clearly, directly, and succinctly. If that's not right, then this section probably needs to be clearer anyway, because it means I'm not getting it. 5. In Section 13.3: There is also a third possible usage for the SETUP method which is not specified in this memo: adding a media to a session. Using SETUP to add media to an existing session, when the session is in Play state, is unspecified. I don't understand what this is trying to say. If there's a third legitimate use, why does this document mention it, but "not specify" it? What does it mean for it to be "unspecified"? Is using SETUP to add media to an existing session that's in Ready state specified? Where? There are other places where you say that something "is unspecified" (later in 13.3, for example, "The SETUP of media streams in an aggregate which has not been given an aggregated control URI is unspecified."): in general, what does that mean? Does it mean it's not permitted? Does it mean that it *is* permitted, but you don't specify how it works? Or what? |
2013-12-01
|
38 | Barry Leiba | [Ballot comment] First, a comment for the responsible AD: The grammar, punctuation, and English usage in Section 2 and its subsections is at times very … [Ballot comment] First, a comment for the responsible AD: The grammar, punctuation, and English usage in Section 2 and its subsections is at times very hard to sort through. I'm going to call out in the comments some bits that I found particularly troublesome, and will try to suggest alternatives. I also suggest that the responsible AD put in an RFC Editor note asking the editors to pay particular attention here and to give it some heavy editing for language clarity. This is a complex document, and a good overview in clear English will really help. Here's a suggestion for text for an RFC Editor note: ------------------------------ RFC Editor note: Section 2 of this document and its subsections provide "an informative overview of the different mechanisms in the RTSP 2.0 protocol, to give the reader a high level understanding". As such, it's very important that it be clear and well written. Some reviewers have found the English to be difficult. Please take an especially critical pen to this section, making sure that the grammar and usage are correct, and that the language is clear. ------------------------------ These are non-blocking, but many of them address readability issues and go beyond simple editorial points. Please consider them carefully, and feel free to talk with me about them. -- Abstract -- The Real Time Streaming Protocol, or RTSP, is an application-level protocol "application-layer", maybe? Also in the Introduction. -- Section 2.2 -- The RTSP client can request the establishment of an RTSP session after having used the presentation description to determine which media streams are available, and also which media delivery protocol is used and their particular resource identifiers. What is the antecedent to "their"? The only thing here that's plural is "media streams", so I guess it has to be that, but the sentence isn't clear there. I suggest rephrasing it this way: NEW The RTSP client can request the establishment of an RTSP session after having used the presentation description to determine which media streams are available, which media delivery protocol is used, and the resource identifiers of [what, "the media streams"?]. END In the SETUP request the client also includes all the transport parameters necessary to enable the media delivery protocol to function in the "Transport" header This sounds like the media delivery protocol functions in the Transport header. Maybe this?: NEW In the "Transport" header of the SETUP request, the client also includes all the transport parameters necessary to enable the media delivery protocol to function END OLD The server determines if the media resource is available upon receiving a SETUP request and if any of the transport parameter specifications are acceptable. NEW Upon receiving a SETUP request, the server determines if the media resource is available and if any of the transport parameter specifications are acceptable. END A SETUP request that references an existing RTSP session but identifies a new media resource is a request to add that media resource under common control with the already present media resources in an aggregated session. A client can expect this to work for all media resources under RTSP control within a multi-media content. However, aggregating resources from different content are likely to be refused by the server. I had a lot of trouble sorting through this. Let me suggest some rephrasing, to see if I understand; if you like the rephrasing, please take some or all of it, correcting as needed: NEW When a SETUP request references an existing RTSP session but identifies a new media resource, it is a request to add that media resource under common control with the already present media resources. This is called an "aggregated session". A client can expect this to work for all media resources under RTSP control within the same multi-media content, but attempts to aggregate resources from different content are likely to be refused by the server. END The RTSP session as aggregate is referenced by the aggregate control URI, even if the RTSP session only contains a single media. I couldn't figure this out at all; can you try rephrasing it, please? -- Section 2.3 -- The basic operations are Start by using the PLAY method (Section 13.4) and Halt by using the PAUSE method (Section 13.6). Where is the value in making up alternative things to call these operations? Why not just call them "Play" and "Pause", to match the method names? Having "Halt" and "PAUSE" mean the same thing only seems to invite confusion, no? The support for positioning/searching within a content depends on the In plain English, "content" is a collective noun, and can't really have an indefinite article with it. I suggest that changing "a content" to "media content" (or "a content stream") will work, and I suggest that you make sure the document is consistent with respect to that usage. These are expressed using one or several independent attributes. A first attribute is Random Access, which expresses if positioning can be done, and with what granularity. Using "one or several" is a bit oddly phrased, and one is likely to read it as "one OF several." Perhaps, "using one or more independent attributes," expresses what you mean? Then, how can one have random access without being able to do positioning? So is "IF positioning can be done" really correct? -- Section 2.5 -- The delivery of media to the RTSP client is done with a protocol outside of RTSP and this protocol is determined during the session establishment. This document specifies how media is delivered with RTP [RFC3550] over UDP [RFC0768], TCP [RFC0793] or the RTSP connection. The first sentence says that media delivery doesn't happen through RTSP. The second sentence seems to say that RTSP can deliver media (it appears to be a third option). Which is it? -- Section 2.5.1 -- Scale = 0 is equal to pause and is not allowed. If it's not allowed, it's not equal to anything. I suggest just saying, "Scale = 0 is not allowed." An example is fast forward where only the independently decodable intra frames are included in the media stream. What are "intra frames"? -- Section 2.7 -- o A new version of the protocol can be defined, allowing almost all aspects (except the position of the protocol version number) to change. A new version of the protocol must be registered through an IETF standards track document. Which is, clearly, what you're doing with this document. It would probably be good to stress that doing this is really a last resort and is extremely disruptive to deployed products. It should only be used when the designed extension mechanisms have failed. -- Section 3.1 -- Since a few of the definitions are identical to HTTP/1.1, this specification only points to the section where they are defined rather than copying it. For brevity, [HX.Y] is to be taken to refer to Section X.Y of the current HTTP/1.1 specification ([RFC2616]). Ah, but 2616 is about to not be the current HTTP/1.1 specification; the httpbis set is likely to be approved by the IESG before this RFC is published. It would be nice to refer to the httpbis set of updates instead, but that would be too disruptive. I guess just take out the word "current", please. -- Section 4.4.2 -- The syntax is based on ISO 8601 [ISO.8601.2000]. Two different notations are allowed. The npt-hhmmss notation are using a ISO 8601 extended complete representation of the time of the day format (Section 5.3.1.1 of [ISO.8601.2000]) using colon (":") as separators between hours, minutes and seconds (hh:mm:ss). With the exception that it expresses duration since presentation start rather than time since midnight and the hour counter is not limited to 0-24 hours, instead up to nineteen (19) digits of hours are allowed. ISO 8601 time format requires all digits to be used for each format, and all format required needs to be included, e.g. if one use a hh:mm:ss format, then that requires two digits for hours, two digits for minutes and two digits for second, a time value such as 7 minutes and 0 seconds, is expressed as 00:07:00. The npt-sec notation is expressing the duration since presentation start in seconds, using one to nineteen (19) digits. Both notations allows decimal fractions of seconds as specified in Section 5.3.1.3 of [ISO.8601.2000] with the limitation of at maximum of 9 digits and only allowing "." (full stop) as separator. Due to RTSP 1.0 and the fact that the highest values are expanded beyond two digits, all implementations MUST allow the highest value to be single digit and SHALL NOT send leading zeros for hours in the npt-hhmmss notation and leading zeros for seconds in the npt-sec notation. The hours and the seconds in the npt-hhmmss notation SHALL be sent using leading zeros, but receivers SHALL accept values without leading zeros. This is too long to have in one block, combines too many things, and has some grammatical problems that make it hard to cope with. May I, please?: NEW The syntax is based on ISO 8601 [ISO.8601.2000] and expresses the time elapsed since presentation start, with two different notations allowed: o The npt-hhmmss notation uses an ISO 8601 extended complete representation of the time of the day format (Section 5.3.1.1 of [ISO.8601.2000]) using colon (":") as separators between hours, minutes and seconds (hh:mm:ss). The hour counter is not limited to 0-24 hours; up to nineteen (19) digits of hours are allowed. In accordance with the requirements of the ISO 8601 time format, the hours, minutes, and seconds must all be present, with two digits used for minutes and for seconds, and with a least two digits for hours. An NPT of 7 minutes and 0 seconds is represented as "00:07:00", and an NPT of 392 hours, 0 minutes, and 6 seconds is represented as "392:00:06". o The npt-sec notation expresses the time in seconds, using between one and nineteen (19) digits. Both notations allow decimal fractions of seconds as specified in Section 5.3.1.3 of [ISO.8601.2000], using at most 9 digits, and allowing only "." (full stop) as the decimal separator. END OK, now that leaves this bit at the end, which conflicts with some of what's above and even with itself (you said "00:07:00" above, and now you say no leading zeroes in hours, and then you say SHALL use leading zeroes; which is it?), and which doesn't make much sense to me anyway (what does "Due to RTSP 1.0" mean, for example?): Due to RTSP 1.0 and the fact that the highest values are expanded beyond two digits, all implementations MUST allow the highest value to be single digit and SHALL NOT send leading zeros for hours in the npt-hhmmss notation and leading zeros for seconds in the npt-sec notation. The hours and the seconds in the npt-hhmmss notation SHALL be sent using leading zeros, but receivers SHALL accept values without leading zeros. I'll leave that part for you to re-word, because I can't hope to do it right. -- Section 4.7.2 -- The following different media retention policies are envisioned and taken into consideration where applicable: What is that meant to be saying, really? Please rephrase it (I have no idea what "and taken into consideation where applicable" might mean). Time-Duration: Each individual unit of the media will be retained for the specified duration. What does "each individual unit of the media" mean? -- Section 4.7.3 -- Dynamic: Between explicit updates the media content will not change, but the content may change due to external methods or triggers, such as playlists. This sounds like doubletalk: it won't change, but it may change. I think it needs re-wording. -- Section 4.7.4 -- It may be updated at any point in the content due to content consisting of spliced pieces or content being dynamically updated by out-of-band mechanisms. I'm not sure what this is trying to say, but I *think* you mean this: NEW The list may be updated at any point in the content, because the content may consist of spliced pieces or may be dynamically updated by out-of-band mechanisms. END -- Section 4.7.5 -- It appeas that you're mixing example headings (which contain colons) on the same line as header fields (which contain colons), making the whole thing unclear. If I'm right, I think this sort of presentation would work lots better: OLD On-demand: Random Access: Random-Access=5.0, Content Modifications: Immutable, Retention: Unlimited or Time-Limited. Dynamic On-demand: Random Access: Random-Access=3.0, Content Modifications: Dynamic, Retention: Unlimited or Time-Limited. Live: Random Access: No-seeking, Content Modifications: Time- Progressing, Retention: Time-Duration=0.0 Live with Recording: Random Access: Random-Access=3.0, Content Modifications: Time-Progressing, Retention: Time-Duration=7200.0 NEW Example of "On-demand": Random Access: Random-Access=5.0, Content Modifications: Immutable, Retention: Unlimited or Time-Limited. Example of "Dynamic On-demand": Random Access: Random-Access=3.0, Content Modifications: Dynamic, Retention: Unlimited or Time-Limited. Example of "Live": Random Access: No-seeking, Content Modifications: Time- Progressing, Retention: Time-Duration=0.0 Example of "Live with Recording": Random Access: Random-Access=3.0, Content Modifications: Time-Progressing, Retention: Time-Duration=7200.0 END -- Section 5 -- Requests contain methods, the object the method is operating upon and parameters to further describe the method. You switch from plural to singular after the first comma. Assuming that each request contains a single method, this is better: NEW A request contains a method, the object the method is operating upon, and parameters to further describe the method. END (Side question: This implies that every method has an object; is that correct?) -- Section 5.1 -- RTSP messages consist of requests from client to server, or server to client, and responses in the reverse direction. I would say that RTSP *sessions* consist of requests and responses. RTSP messages don't consist of requests and responses: they *are* those requests and responses: NEW An RTSP message is a request from a client to a server or from a server to a client, or a response in the reverse direction. END In the interest of robustness, agents MUST ignore any empty line(s) received where a Request-Line or Response-Line is expected. In other words, if the agent is reading the protocol stream at the beginning of a message and receives a CRLF first, it MUST ignore the CRLF. What's a "Response-Line"? I also presume the last sentence above is applicable recursively (you want to ignore any number of leading CRLF sequences), yes? Might be good to be clear about that. -- Section 8.2 -- A new or experimental header MAY be given the semantics of response-header if all parties in the communication recognize them to be a response-header. This seems an incorrect use of 2119 MAY... It is not describing an optional protocol feauture. I'd make it "can", in this context. -- Section 9 -- Request and Response messages MAY transfer a message body, if not otherwise restricted by the request method or response status code. This is a trickier one, but is really *not* a 2119 MAY: it's not a purely optional thing for a message to transfer a message body. It either does, or it doesn't, based on what the message is doing. But if a particular nessage uses a message body, that can't be omitted as an implementation option. This statement needs to be re-worded to reflect the actual requirement here. I think "Some Request and Response messages include message bodies," is sufficient. If you want, it'd be reasonable to add, ", depending upon the request method and response status code." You'll similarly need to dispose of the MAY in the first sentence of the second paragraph. The rest of the MAYs in that paragraph look correct: they truly are describing optional behaviour. -- Section 9.3 -- HTTP and email have both historically had horrendous problems with inaccurate or missing Content-Type headers. It's good that you use MUST for Content-Type; that has to help. I would be happier (though not at DISCUSS level) if you should say a few more words about Content-Type here: something about how it MUST accurately specify the type and subtype of the content, that there are no defaults for type or subtype, and that attempts to use heuristics to second-guess this are Very Bad. -- Section 10 -- This transport connection is referred to as the connection or possibly RTSP connection within this document. The "or possibly" made me think twice. As you're defining a term, I think quotation marks would help, and I suggest this: NEW This transport connection is referred to within this document as the "connection" or the "RTSP connection". END Just below that, in defining "persistent" vs "transient": is it really the point that transient is for just one req/resp? Or is the point really that each req/resp uses a new connection? Maybe it would be better to say it this way?: NEW o transient - a new transport connection is used for each single request/response transaction. END Purely nit-level and personal preference, so ignore if you prefer: whenyou say things such as "RFC 2326 attempted to specify", I think it would be better to say, "RTSP 1.0 attempted to specify". You already have a clear reference to RFC 2326 for that, and the point is really to compare 2.0 with 1.0, so don't make the reader have to think about that. (Check this throughout the document, if you agree.) -- Section 10.2 -- The scheme of the RTSP URI (Section 4.2) indicates the default port that the server will listen on if the port is not explicitly given. The URI is created by the client, not the server, so it doesn't specify what port the server "will listen on." It specifies the port the client will contact the server on. I would say it this way: NEW The scheme of the RTSP URI (Section 4.2) allows the client to specify the port it will contact the server on, and defines the default port to use if one is not explicitly given. END This port may provide some benefits from non-registered ports if a RTSP server is unable to use the default ports. I think you mean "some benefits over non-registered ports". "Over", not "from". authorize a client establishing a new connection as being a legitimate receiver of a request related to a particular RTSP session without the client first issuing requests related to the request. There's a lot of "request" in there, and it's confusing. Maybe this?: NEW authorize a client establishing a new connection as being a legitimate receiver of a request related to an existing RTSP session, without the client first issuing new requests related to the pending request. END To avoid this problem an RTSP agent is recommended to buffer incoming messages locally so that any response messages can be processed immediately upon reception. Thus doesn't make sense to me. If you're buffering them, you're not processing each one immediately, right? You won't process a message until it has its turn to be popped out of the buffer. What are you really trying to say here? -- Section 10.4 -- A responder SHOULD respond to all requests within 5 seconds. If the responder recognizes that processing of a request will take longer than 5 seconds, it SHOULD send a 100 (Continue) response as soon as possible. It SHOULD continue sending a 100 response every 5 seconds thereafter until it is ready to send the final response to the requester. After sending a 100 response, the receiver MUST send a final response indicating the success or failure of the request. After all this about the "responder"... should that "receiver" in the last sentence be "responder" also? If not, then I don't understand. To mitigate that situation the RTSP agent SHOULD establish a new connection and send any queued up and non-responded requests on this new connection. Secondly, to ensure that the RTSP server knows which connection that is valid for a particular RTSP session, the RTSP agent SHOULD send a keep-alive request, if no other request will be sent immediately for that RTSP session, for each RTSP session on the old connection. The second sentence is unclear: it seems to be saying that for each session on the old connection, the agent should send a keep-alive request on the new session. But then there's the "if no other request" modifier. And it's possible to interpret this as saying that the keep-alives should be sent on the old sessions. Can you re-word this (changing the order in which you say things and avoiding too-long sentences) to clarify what you mean? -- Section 10.5 -- The RTSP message may be lost or when using reliable protocols, such as TCP, the message may take some time to arrive safely at the receiver. But... doesn't Section 10.1 say this?: Since RTSP messages are transmitted using reliable transport protocols, they MUST NOT be retransmitted at the RTSP protocol level. So, what does the "or when using reliable protocols, such as TCP" mean here? A downside of using RTCP is that it only gives statistical guarantees of reaching the server. What are "statistical guarantees"? It seems to me that delivery is guaranteed, or it's not. If it's not, then that's what we should say, no? GET_PARAMETER: When using GET_PARAMETER for keep-alive, no body SHOULD be included. Why is this worded differently than for "SET_PARAMETER"? The "no body SHOULD" is a confusing structure, and "a body SHOULD NOT" works better. -- Section 10.7 -- Another scope for overload situation exists, which is the RTSP proxy. I find it to be very bad form to spend two paragraphs talking about how 503 signals an overload situation and saying that there are two scopes... and then to spring a third scope and a new 553 response code on the reader. I suggest that you back up and introduce this earlier, probably saying that there are three situations with three scopes, and then explaining each one separately. However, this can cause the situation where multiple RTSP clients again send requests to a proxy or server at roughly the same time which may again cause an overload situation, or if the "old" overload situation is not yet solved, i.e., the length indicated in the Retry- After header was too short. I can't parse this (in particular, I can't make sense of what comes after ", or if"); please try re-wording, probably splitting the too-long sentence in the process. A more complex case may arise when a load balancing RTSP proxy is in use, i.e., where an RTSP proxy is used to select amongst a set of RTSP servers to handle the requests, or when multiple server addresses are available for a given server name. Here's an example of a problem with using "i.e.": I can't tell what the scope of the "i.e." is. Is it the rest of the sentence ["X (i.e., A, or B)"], or is it just the first part ["X (i.e., A), or B"] ? Please clarify the text. It is REQUIRED to not set the same value in the timer for each scheduling, but instead to add a variation to the mean value, resulting in picking a random value within the range of 0.5 to 1.5 of the mean value. Is this meant to say "0.5 to 1.5 *times* the mean value? "Of" doesn't do that. -- section 12 -- Just a question here, to which I don't presume a particular answer: are there any combinations of requests that can't be pipelined, because failure of an earlier one would cause an irrecoverable problem for a subsequent one? If so, that should be discussed here... though it's quite possible that there are no such scenarios. I ask because in IMAP (email) there are such combinations, where the first command can cause the message sequence numbers to change, such that a second pilelined command that acted through message sequence numbers might then affect the wrong message(s). Is there anything similar in RTSP? Or are all combinations of methods safe to pipeline? -- Section 13 -- Method names MUST NOT start with a $ character (decimal 36) and MUST be a token as defined by the ABNF [RFC5234] in the syntax chapter Section 20. A very trivial point to take or leave: the point here is not ABNF, but the reference to Section 20, and it strikes me that the ABNF citation is a distraction from that. How about this?: NEW Method names MUST NOT start with a $ character (decimal 36) and MUST be a token as defined by the syntax chapter (see Section 20). END -- Section 13.4.1 -- General: the explanation of the pause point and the range really seems convoluted and difficult. I'll take your word if you say that it's understandable -- I haven't tried to implement from this, so I can't say. I'm just judging from what people say about other specs, where they are claimed to be "too complicated". As it is, I see this as a significant interoperability risk. The Seek-Style applied will effect the content In case the RFC Editor should miss this one: "affect", please. After playing the desired range, the presentation does NOT change to the Ready state, media delivery simply stops. A PAUSE request MUST be issued to make the stream enter the Ready state. A PLAY request while the stream is still in the Play state is legal, and can be issued without an intervening PAUSE request. The "MUST" here has the wrong sense: it is *not* required that a PAUSE request be issued. I think what you want to say is this: NEW After playing the desired range, the presentation does not change to the Ready state; media delivery simply stops. If it is necessary to put the stream into the Ready state, a PAUSE request MUST be issued to do that. A PLAY request while the stream is still in the Play state is legal, and can be issued without an intervening PAUSE request. END -- Section 13.4.3 -- Would it be worth explicitly pointing this out, with respect to the first example?: The second PLAY request is using an implicit start point in order to moify only the stop point, and that if it had been issued with a range of "10-25" instead, the effect would not be just to extend the time: the play would actually restart at 10, replaying the first four seconds that were just played. -- Section 13.5 -- PLAY_NOTIFY requests MAY be used with a message body, depending on the value of the Notify-Reason header. It is described in the particular section for each Notify-Reason if a message body is used. However, currently there is no Notify-Reason that allows using a message body. That last sentence should be a clue that the "MAY" here is wrong. You're not describing an option for the implementor. Depending upon the value of Notify-Reason, either a body is needed or it isn't. You can make this "may", or, better, "will sometimes". This is extensible and new reasons MAY be added in the future Similarly, this is not a 2119 MAY. Make it "may" or "might". -- Section 13.7.1 -- A TEARDOWN request MAY be performed on either an aggregated or a media control Another erroneous 2119 MAY: either "may" or "can" works. A TEARDOWN using the aggregated control URI or the media URI in a session under non-aggregated control (single media session) MAY be done in any state (Ready and Play). And another: either "may" or "can". A TEARDOWN using a media URI in an aggregated session MAY only be done in Ready state. And another: either "may" or "can". -- Section 13.9 -- The method MAY also be used without a message body. And another: either "may" or "can". Otherwise no body MUST be returned. The negative with the MUST is confusing. I suggest, "Otherwise, a body MUST NOT be returned." -- Section 13.10 -- If the Location header contains only a host address, the client MAY assume that the media on the new server is identical to the media on the old server, i.e., all media configuration information from the old session is still valid except for the host address. However, the usage of conditional SETUP using MTag identifiers is RECOMMENDED as a means to verify the assumption. No... MAY and RECOMMENDED do not go together in this way. If verification is RECOMMENDED, then doing it without verification is not a "MAY". |
2013-12-01
|
38 | Barry Leiba | Ballot comment and discuss text updated for Barry Leiba |
2013-11-30
|
38 | Barry Leiba | [Ballot discuss] I have not finished reviewing yet: I'm just about to start Section 10 as I post this, so I have well over 250 … [Ballot discuss] I have not finished reviewing yet: I'm just about to start Section 10 as I post this, so I have well over 250 pages yet to read, and I'm sure I'll have many more comments. But I want to get some of this out here now, so the authors aren't entirely blindsided at the last minute. I also might ask that we defer this one telechat, though I'm holding off on that for now. UPDATED: I have finished Section 10, and am starting Section 11. I'm adding the comments from Section 10 here, which include a couple of new DISCUSS points. What I have so far follows, in both the DISCUSS and COMMENT sections. ----------------------------------------------------------- 1. This point falls into the "URI/IRI follies" category: -- Section 3.2 -- IRI: Internationalized Resource Identifier, is the same as a URI, with the exception that it allows characters from the whole Oh, my; please don't say that it's "the same as a URI". It'd be reasonable to say "is similar to a URI, but allows characters [etc]." -- Section 4.2 -- The RTSP URI and IRI are case sensitive, with the exception of those parts that [RFC3986] and [RFC3987] define as case-insensitive; for example, the scheme and host part. Clumping URIs and IRIs together in such a vague way with respect to case mapping is a dangerous thing. And unless there's a particular reason to say otherwise, it's easy to avoid that by specifically saying that the scheme and host parts are the *only* case-sensitive bits (which is true of generic URIs and IRIs anyway). Is there really a reason not to be clearer, this way?: NEW The "scheme" and "host" parts of all URIs [RFC3986] and IRIs [RFC3987] are case-insensitive. All other parts of RTSP URIs and IRIs are case- sensitive, and SHOULD NOT be case-mapped. END 2. The paragraph in Section 4.4.2 that explains npt-hhmmss notation and npt-sec notation has some internal inconsistencies that have to be fixed. See my suggestions in the comments section below, which goes beyond the blocking point (the inconsistency) and tries to make the paragraph more readable as well. 3. Two bits in Section 10.5: The mechanisms for showing liveness of the client is, any RTSP request with a Session header, if RTP & RTCP is used an RTCP message, or through any other used media protocol capable of indicating liveness of the RTSP client. The grammar and punctuation in that sentence is so fractured that I haven't the first idea what it means. It needs to be re-worded, and I can't help. SET_PARAMETER: When using SET_PARAMETER for keep-alive, a body SHOULD NOT be included. This method is the RECOMMENDED RTSP method to use for a request intended only to perform keep- alive. But a short bit above, in Section 10.4, you say this: The keep-alive request will normally be a GET_PARAMETER with a session header to inform the server that this agent cares about this RTSP session. If SET_PARAMETER is what's RECOMMENDED, then why do you say that it "will normally be" GET_PARAMETER? |
2013-11-30
|
38 | Barry Leiba | Ballot discuss text updated for Barry Leiba |
2013-11-30
|
38 | Barry Leiba | [Ballot discuss] I have not finished reviewing yet: I'm just about to start Section 10 as I post this, so I have well over 250 … [Ballot discuss] I have not finished reviewing yet: I'm just about to start Section 10 as I post this, so I have well over 250 pages yet to read, and I'm sure I'll have many more comments. But I want to get some of this out here now, so the authors aren't entirely blindsided at the last minute. I also might ask that we defer this one telechat, though I'm holding off on that for now. UPDATED: I have finished Section 10, and am starting Section 11. I'm adding the comments from Section 10 here, which include a couple of new DISCUSS points. What I have so far follows, in both the DISCUSS and COMMENT sections. ----------------------------------------------------------- 1. This point falls into the "URI/IRI follies" category: -- Section 3.2 -- IRI: Internationalized Resource Identifier, is the same as a URI, with the exception that it allows characters from the whole Oh, my; please don't say that it's "the same as a URI". It'd be reasonable to say "is similar to a URI, but allows characters [etc]." -- Section 4.2 -- The RTSP URI and IRI are case sensitive, with the exception of those parts that [RFC3986] and [RFC3987] define as case-insensitive; for example, the scheme and host part. Clumping URIs and IRIs together in such a vague way with respect to case mapping is a dangerous thing. And unless there's a particular reason to say otherwise, it's easy to avoid that by specifically saying that the scheme and host parts are the *only* case-sensitive bits (which is true of generic URIs and IRIs anyway). Is there really a reason not to be clearer, this way?: NEW The "scheme" and "host" parts of all URIs [RFC3986] and IRIs [RFC3987] are case-insensitive. All other parts of RTSP URIs and IRIs are case- sensitive, and SHOULD NOT be case-mapped. END 2. The paragraph in Section 4.4.2 that explains npt-hhmmss notation and npt-sec notation has some internal inconsistencies that have to be fixed. See my suggestions in the comments section below, which goes beyond the blocking point (the inconsistency) and tries to make the paragraph more readable as well. -- Section 10.5 -- The mechanisms for showing liveness of the client is, any RTSP request with a Session header, if RTP & RTCP is used an RTCP message, or through any other used media protocol capable of indicating liveness of the RTSP client. The grammar and punctuation in that sentence is so fractured that I haven't the first idea what it means. It needs to be re-worded, and I can't help. SET_PARAMETER: When using SET_PARAMETER for keep-alive, a body SHOULD NOT be included. This method is the RECOMMENDED RTSP method to use for a request intended only to perform keep- alive. But a short bit above, in Section 10.4, you say this: The keep-alive request will normally be a GET_PARAMETER with a session header to inform the server that this agent cares about this RTSP session. If SET_PARAMETER is what's RECOMMENDED, then why do you say that it "will normally be" GET_PARAMETER? |
2013-11-30
|
38 | Barry Leiba | [Ballot comment] First, a comment for the responsible AD: The grammar, punctuation, and English usage in Section 2 and its subsections is at times very … [Ballot comment] First, a comment for the responsible AD: The grammar, punctuation, and English usage in Section 2 and its subsections is at times very hard to sort through. I'm going to call out in the comments some bits that I found particularly troublesome, and will try to suggest alternatives. I also suggest that the responsible AD put in an RFC Editor note asking the editors to pay particular attention here and to give it some heavy editing for language clarity. This is a complex document, and a good overview in clear English will really help. Here's a suggestion for text for an RFC Editor note: ------------------------------ RFC Editor note: Section 2 of this document and its subsections provide "an informative overview of the different mechanisms in the RTSP 2.0 protocol, to give the reader a high level understanding". As such, it's very important that it be clear and well written. Some reviewers have found the English to be difficult. Please take an especially critical pen to this section, making sure that the grammar and usage are correct, and that the language is clear. ------------------------------ These are non-blocking, but many of them address readability issues and go beyond simple editorial points. Please consider them carefully, and feel free to talk with me about them. -- Abstract -- The Real Time Streaming Protocol, or RTSP, is an application-level protocol "application-layer", maybe? Also in the Introduction. -- Section 2.2 -- The RTSP client can request the establishment of an RTSP session after having used the presentation description to determine which media streams are available, and also which media delivery protocol is used and their particular resource identifiers. What is the antecedent to "their"? The only thing here that's plural is "media streams", so I guess it has to be that, but the sentence isn't clear there. I suggest rephrasing it this way: NEW The RTSP client can request the establishment of an RTSP session after having used the presentation description to determine which media streams are available, which media delivery protocol is used, and the resource identifiers of [what, "the media streams"?]. END In the SETUP request the client also includes all the transport parameters necessary to enable the media delivery protocol to function in the "Transport" header This sounds like the media delivery protocol functions in the Transport header. Maybe this?: NEW In the "Transport" header of the SETUP request, the client also includes all the transport parameters necessary to enable the media delivery protocol to function END OLD The server determines if the media resource is available upon receiving a SETUP request and if any of the transport parameter specifications are acceptable. NEW Upon receiving a SETUP request, the server determines if the media resource is available and if any of the transport parameter specifications are acceptable. END A SETUP request that references an existing RTSP session but identifies a new media resource is a request to add that media resource under common control with the already present media resources in an aggregated session. A client can expect this to work for all media resources under RTSP control within a multi-media content. However, aggregating resources from different content are likely to be refused by the server. I had a lot of trouble sorting through this. Let me suggest some rephrasing, to see if I understand; if you like the rephrasing, please take some or all of it, correcting as needed: NEW When a SETUP request references an existing RTSP session but identifies a new media resource, it is a request to add that media resource under common control with the already present media resources. This is called an "aggregated session". A client can expect this to work for all media resources under RTSP control within the same multi-media content, but attempts to aggregate resources from different content are likely to be refused by the server. END The RTSP session as aggregate is referenced by the aggregate control URI, even if the RTSP session only contains a single media. I couldn't figure this out at all; can you try rephrasing it, please? -- Section 2.3 -- The basic operations are Start by using the PLAY method (Section 13.4) and Halt by using the PAUSE method (Section 13.6). Where is the value in making up alternative things to call these operations? Why not just call them "Play" and "Pause", to match the method names? Having "Halt" and "PAUSE" mean the same thing only seems to invite confusion, no? The support for positioning/searching within a content depends on the In plain English, "content" is a collective noun, and can't really have an indefinite article with it. I suggest that changing "a content" to "media content" (or "a content stream") will work, and I suggest that you make sure the document is consistent with respect to that usage. These are expressed using one or several independent attributes. A first attribute is Random Access, which expresses if positioning can be done, and with what granularity. Using "one or several" is a bit oddly phrased, and one is likely to read it as "one OF several." Perhaps, "using one or more independent attributes," expresses what you mean? Then, how can one have random access without being able to do positioning? So is "IF positioning can be done" really correct? -- Section 2.5 -- The delivery of media to the RTSP client is done with a protocol outside of RTSP and this protocol is determined during the session establishment. This document specifies how media is delivered with RTP [RFC3550] over UDP [RFC0768], TCP [RFC0793] or the RTSP connection. The first sentence says that media delivery doesn't happen through RTSP. The second sentence seems to say that RTSP can deliver media (it appears to be a third option). Which is it? -- Section 2.5.1 -- Scale = 0 is equal to pause and is not allowed. If it's not allowed, it's not equal to anything. I suggest just saying, "Scale = 0 is not allowed." An example is fast forward where only the independently decodable intra frames are included in the media stream. What are "intra frames"? -- Section 2.7 -- o A new version of the protocol can be defined, allowing almost all aspects (except the position of the protocol version number) to change. A new version of the protocol must be registered through an IETF standards track document. Which is, clearly, what you're doing with this document. It would probably be good to stress that doing this is really a last resort and is extremely disruptive to deployed products. It should only be used when the designed extension mechanisms have failed. -- Section 3.1 -- Since a few of the definitions are identical to HTTP/1.1, this specification only points to the section where they are defined rather than copying it. For brevity, [HX.Y] is to be taken to refer to Section X.Y of the current HTTP/1.1 specification ([RFC2616]). Ah, but 2616 is about to not be the current HTTP/1.1 specification; the httpbis set is likely to be approved by the IESG before this RFC is published. It would be nice to refer to the httpbis set of updates instead, but that would be too disruptive. I guess just take out the word "current", please. -- Section 4.4.2 -- The syntax is based on ISO 8601 [ISO.8601.2000]. Two different notations are allowed. The npt-hhmmss notation are using a ISO 8601 extended complete representation of the time of the day format (Section 5.3.1.1 of [ISO.8601.2000]) using colon (":") as separators between hours, minutes and seconds (hh:mm:ss). With the exception that it expresses duration since presentation start rather than time since midnight and the hour counter is not limited to 0-24 hours, instead up to nineteen (19) digits of hours are allowed. ISO 8601 time format requires all digits to be used for each format, and all format required needs to be included, e.g. if one use a hh:mm:ss format, then that requires two digits for hours, two digits for minutes and two digits for second, a time value such as 7 minutes and 0 seconds, is expressed as 00:07:00. The npt-sec notation is expressing the duration since presentation start in seconds, using one to nineteen (19) digits. Both notations allows decimal fractions of seconds as specified in Section 5.3.1.3 of [ISO.8601.2000] with the limitation of at maximum of 9 digits and only allowing "." (full stop) as separator. Due to RTSP 1.0 and the fact that the highest values are expanded beyond two digits, all implementations MUST allow the highest value to be single digit and SHALL NOT send leading zeros for hours in the npt-hhmmss notation and leading zeros for seconds in the npt-sec notation. The hours and the seconds in the npt-hhmmss notation SHALL be sent using leading zeros, but receivers SHALL accept values without leading zeros. This is too long to have in one block, combines too many things, and has some grammatical problems that make it hard to cope with. May I, please?: NEW The syntax is based on ISO 8601 [ISO.8601.2000] and expresses the time elapsed since presentation start, with two different notations allowed: o The npt-hhmmss notation uses an ISO 8601 extended complete representation of the time of the day format (Section 5.3.1.1 of [ISO.8601.2000]) using colon (":") as separators between hours, minutes and seconds (hh:mm:ss). The hour counter is not limited to 0-24 hours; up to nineteen (19) digits of hours are allowed. In accordance with the requirements of the ISO 8601 time format, the hours, minutes, and seconds must all be present, with two digits used for minutes and for seconds, and with a least two digits for hours. An NPT of 7 minutes and 0 seconds is represented as "00:07:00", and an NPT of 392 hours, 0 minutes, and 6 seconds is represented as "392:00:06". o The npt-sec notation expresses the time in seconds, using between one and nineteen (19) digits. Both notations allow decimal fractions of seconds as specified in Section 5.3.1.3 of [ISO.8601.2000], using at most 9 digits, and allowing only "." (full stop) as the decimal separator. END OK, now that leaves this bit at the end, which conflicts with some of what's above and even with itself (you said "00:07:00" above, and now you say no leading zeroes in hours, and then you say SHALL use leading zeroes; which is it?), and which doesn't make much sense to me anyway (what does "Due to RTSP 1.0" mean, for example?): Due to RTSP 1.0 and the fact that the highest values are expanded beyond two digits, all implementations MUST allow the highest value to be single digit and SHALL NOT send leading zeros for hours in the npt-hhmmss notation and leading zeros for seconds in the npt-sec notation. The hours and the seconds in the npt-hhmmss notation SHALL be sent using leading zeros, but receivers SHALL accept values without leading zeros. I'll leave that part for you to re-word, because I can't hope to do it right. -- Section 4.7.2 -- The following different media retention policies are envisioned and taken into consideration where applicable: What is that meant to be saying, really? Please rephrase it (I have no idea what "and taken into consideation where applicable" might mean). Time-Duration: Each individual unit of the media will be retained for the specified duration. What does "each individual unit of the media" mean? -- Section 4.7.3 -- Dynamic: Between explicit updates the media content will not change, but the content may change due to external methods or triggers, such as playlists. This sounds like doubletalk: it won't change, but it may change. I think it needs re-wording. -- Section 4.7.4 -- It may be updated at any point in the content due to content consisting of spliced pieces or content being dynamically updated by out-of-band mechanisms. I'm not sure what this is trying to say, but I *think* you mean this: NEW The list may be updated at any point in the content, because the content may consist of spliced pieces or may be dynamically updated by out-of-band mechanisms. END -- Section 4.7.5 -- It appeas that you're mixing example headings (which contain colons) on the same line as header fields (which contain colons), making the whole thing unclear. If I'm right, I think this sort of presentation would work lots better: OLD On-demand: Random Access: Random-Access=5.0, Content Modifications: Immutable, Retention: Unlimited or Time-Limited. Dynamic On-demand: Random Access: Random-Access=3.0, Content Modifications: Dynamic, Retention: Unlimited or Time-Limited. Live: Random Access: No-seeking, Content Modifications: Time- Progressing, Retention: Time-Duration=0.0 Live with Recording: Random Access: Random-Access=3.0, Content Modifications: Time-Progressing, Retention: Time-Duration=7200.0 NEW Example of "On-demand": Random Access: Random-Access=5.0, Content Modifications: Immutable, Retention: Unlimited or Time-Limited. Example of "Dynamic On-demand": Random Access: Random-Access=3.0, Content Modifications: Dynamic, Retention: Unlimited or Time-Limited. Example of "Live": Random Access: No-seeking, Content Modifications: Time- Progressing, Retention: Time-Duration=0.0 Example of "Live with Recording": Random Access: Random-Access=3.0, Content Modifications: Time-Progressing, Retention: Time-Duration=7200.0 END -- Section 5 -- Requests contain methods, the object the method is operating upon and parameters to further describe the method. You switch from plural to singular after the first comma. Assuming that each request contains a single method, this is better: NEW A request contains a method, the object the method is operating upon, and parameters to further describe the method. END (Side question: This implies that every method has an object; is that correct?) -- Section 5.1 -- RTSP messages consist of requests from client to server, or server to client, and responses in the reverse direction. I would say that RTSP *sessions* consist of requests and responses. RTSP messages don't consist of requests and responses: they *are* those requests and responses: NEW An RTSP message is a request from a client to a server or from a server to a client, or a response in the reverse direction. END In the interest of robustness, agents MUST ignore any empty line(s) received where a Request-Line or Response-Line is expected. In other words, if the agent is reading the protocol stream at the beginning of a message and receives a CRLF first, it MUST ignore the CRLF. What's a "Response-Line"? I also presume the last sentence above is applicable recursively (you want to ignore any number of leading CRLF sequences), yes? Might be good to be clear about that. -- Section 8.2 -- A new or experimental header MAY be given the semantics of response-header if all parties in the communication recognize them to be a response-header. This seems an incorrect use of 2119 MAY... It is not describing an optional protocol feauture. I'd make it "can", in this context. -- Section 9 -- Request and Response messages MAY transfer a message body, if not otherwise restricted by the request method or response status code. This is a trickier one, but is really *not* a 2119 MAY: it's not a purely optional thing for a message to transfer a message body. It either does, or it doesn't, based on what the message is doing. But if a particular nessage uses a message body, that can't be omitted as an implementation option. This statement needs to be re-worded to reflect the actual requirement here. I think "Some Request and Response messages include message bodies," is sufficient. If you want, it'd be reasonable to add, ", depending upon the request method and response status code." You'll similarly need to dispose of the MAY in the first sentence of the second paragraph. The rest of the MAYs in that paragraph look correct: they truly are describing optional behaviour. -- Section 9.3 -- HTTP and email have both historically had horrendous problems with inaccurate or missing Content-Type headers. It's good that you use MUST for Content-Type; that has to help. I would be happier (though not at DISCUSS level) if you should say a few more words about Content-Type here: something about how it MUST accurately specify the type and subtype of the content, that there are no defaults for type or subtype, and that attempts to use heuristics to second-guess this are Very Bad. -- Section 10 -- This transport connection is referred to as the connection or possibly RTSP connection within this document. The "or possibly" made me think twice. As you're defining a term, I think quotation marks would help, and I suggest this: NEW This transport connection is referred to within this document as the "connection" or the "RTSP connection". END Just below that, in defining "persistent" vs "transient": is it really the point that transient is for just one req/resp? Or is the point really that each req/resp uses a new connection? Maybe it would be better to say it this way?: NEW o transient - a new transport connection is used for each single request/response transaction. END Purely nit-level and personal preference, so ignore if you prefer: whenyou say things such as "RFC 2326 attempted to specify", I think it would be better to say, "RTSP 1.0 attempted to specify". You already have a clear reference to RFC 2326 for that, and the point is really to compare 2.0 with 1.0, so don't make the reader have to think about that. (Check this throughout the document, if you agree.) -- Section 10.2 -- The scheme of the RTSP URI (Section 4.2) indicates the default port that the server will listen on if the port is not explicitly given. The URI is created by the client, not the server, so it doesn't specify what port the server "will listen on." It specifies the port the client will contact the server on. I would say it this way: NEW The scheme of the RTSP URI (Section 4.2) allows the client to specify the port it will contact the server on, and defines the default port to use if one is not explicitly given. END This port may provide some benefits from non-registered ports if a RTSP server is unable to use the default ports. I think you mean "some benefits over non-registered ports". "Over", not "from". authorize a client establishing a new connection as being a legitimate receiver of a request related to a particular RTSP session without the client first issuing requests related to the request. There's a lot of "request" in there, and it's confusing. Maybe this?: NEW authorize a client establishing a new connection as being a legitimate receiver of a request related to an existing RTSP session, without the client first issuing new requests related to the pending request. END To avoid this problem an RTSP agent is recommended to buffer incoming messages locally so that any response messages can be processed immediately upon reception. Thus doesn't make sense to me. If you're buffering them, you're not processing each one immediately, right? You won't process a message until it has its turn to be popped out of the buffer. What are you really trying to say here? -- Section 10.4 -- A responder SHOULD respond to all requests within 5 seconds. If the responder recognizes that processing of a request will take longer than 5 seconds, it SHOULD send a 100 (Continue) response as soon as possible. It SHOULD continue sending a 100 response every 5 seconds thereafter until it is ready to send the final response to the requester. After sending a 100 response, the receiver MUST send a final response indicating the success or failure of the request. After all this about the "responder"... should that "receiver" in the last sentence be "responder" also? If not, then I don't understand. To mitigate that situation the RTSP agent SHOULD establish a new connection and send any queued up and non-responded requests on this new connection. Secondly, to ensure that the RTSP server knows which connection that is valid for a particular RTSP session, the RTSP agent SHOULD send a keep-alive request, if no other request will be sent immediately for that RTSP session, for each RTSP session on the old connection. The second sentence is unclear: it seems to be saying that for each session on the old connection, the agent should send a keep-alive request on the new session. But then there's the "if no other request" modifier. And it's possible to interpret this as saying that the keep-alives should be sent on the old sessions. Can you re-word this (changing the order in which you say things and avoiding too-long sentences) to clarify what you mean? -- Section 10.5 -- The RTSP message may be lost or when using reliable protocols, such as TCP, the message may take some time to arrive safely at the receiver. But... doesn't Section 10.1 say this?: Since RTSP messages are transmitted using reliable transport protocols, they MUST NOT be retransmitted at the RTSP protocol level. So, what does the "or when using reliable protocols, such as TCP" mean here? A downside of using RTCP is that it only gives statistical guarantees of reaching the server. What are "statistical guarantees"? It seems to me that delivery is guaranteed, or it's not. If it's not, then that's what we should say, no? GET_PARAMETER: When using GET_PARAMETER for keep-alive, no body SHOULD be included. Why is this worded differently than for "SET_PARAMETER"? The "no body SHOULD" is a confusing structure, and "a body SHOULD NOT" works better. -- Section 10.7 -- Another scope for overload situation exists, which is the RTSP proxy. I find it to be very bad form to spend two paragraphs talking about how 503 signals an overload situation and saying that there are two scopes... and then to spring a third scope and a new 553 response code on the reader. I suggest that you back up and introduce this earlier, probably saying that there are three situations with three scopes, and then explaining each one separately. However, this can cause the situation where multiple RTSP clients again send requests to a proxy or server at roughly the same time which may again cause an overload situation, or if the "old" overload situation is not yet solved, i.e., the length indicated in the Retry- After header was too short. I can't parse this (in particular, I can't make sense of what comes after ", or if"); please try re-wording, probably splitting the too-long sentence in the process. A more complex case may arise when a load balancing RTSP proxy is in use, i.e., where an RTSP proxy is used to select amongst a set of RTSP servers to handle the requests, or when multiple server addresses are available for a given server name. Here's an example of a problem with using "i.e.": I can't tell what the scope of the "i.e." is. Is it the rest of the sentence ["X (i.e., A, or B)"], or is it just the first part ["X (i.e., A), or B"] ? Please clarify the text. It is REQUIRED to not set the same value in the timer for each scheduling, but instead to add a variation to the mean value, resulting in picking a random value within the range of 0.5 to 1.5 of the mean value. Is this meant to say "0.5 to 1.5 *times* the mean value? "Of" doesn't do that. |
2013-11-30
|
38 | Barry Leiba | Ballot comment and discuss text updated for Barry Leiba |
2013-11-25
|
38 | Robert Sparks | Request for Last Call review by GENART Completed: Ready. Reviewer: Robert Sparks. |
2013-11-21
|
38 | Barry Leiba | [Ballot discuss] I have not finished reviewing yet: I'm just about to start Section 10 as I post this, so I have well over 250 … [Ballot discuss] I have not finished reviewing yet: I'm just about to start Section 10 as I post this, so I have well over 250 pages yet to read, and I'm sure I'll have many more comments. But I want to get some of this out here now, so the authors aren't entirely blindsided at the last minute. I also might ask that we defer this one telechat, though I'm holding off on that for now. What I have so far follows, in both the DISCUSS and COMMENT sections. ----------------------------------------------------------- 1. This point falls into the "URI/IRI follies" category: -- Section 3.2 -- IRI: Internationalized Resource Identifier, is the same as a URI, with the exception that it allows characters from the whole Oh, my; please don't say that it's "the same as a URI". It'd be reasonable to say "is similar to a URI, but allows characters [etc]." -- Section 4.2 -- The RTSP URI and IRI are case sensitive, with the exception of those parts that [RFC3986] and [RFC3987] define as case-insensitive; for example, the scheme and host part. Clumping URIs and IRIs together in such a vague way with respect to case mapping is a dangerous thing. And unless there's a particular reason to say otherwise, it's easy to avoid that by specifically saying that the scheme and host parts are the *only* case-sensitive bits (which is true of generic URIs and IRIs anyway). Is there really a reason not to be clearer, this way?: NEW The "scheme" and "host" parts of all URIs [RFC3986] and IRIs [RFC3987] are case-insensitive. All other parts of RTSP URIs and IRIs are case- sensitive, and SHOULD NOT be case-mapped. END 2. The paragraph in Section 4.4.2 that explains npt-hhmmss notation and npt-sec notation has some internal inconsistencies that have to be fixed. See my suggestions in the comments section below, which goes beyond the blocking point (the inconsistency) and tries to make the paragraph more readable as well. |
2013-11-21
|
38 | Barry Leiba | Ballot discuss text updated for Barry Leiba |
2013-11-21
|
38 | Barry Leiba | [Ballot comment] First, a comment for the responsible AD: The grammar, punctuation, and English usage in Section 2 and its subsections is at times very … [Ballot comment] First, a comment for the responsible AD: The grammar, punctuation, and English usage in Section 2 and its subsections is at times very hard to sort through. I'm going to call out in the comments some bits that I found particularly troublesome, and will try to suggest alternatives. I also suggest that the responsible AD put in an RFC Editor note asking the editors to pay particular attention here and to give it some heavy editing for language clarity. This is a complex document, and a good overview in clear English will really help. Here's a suggestion for text for an RFC Editor note: ------------------------------ RFC Editor note: Section 2 of this document and its subsections provide "an informative overview of the different mechanisms in the RTSP 2.0 protocol, to give the reader a high level understanding". As such, it's very important that it be clear and well written. Some reviewers have found the English to be difficult. Please take an especially critical pen to this section, making sure that the grammar and usage are correct, and that the language is clear. ------------------------------ These are non-blocking, but many of them address readability issues and go beyond simple editorial points. Please consider them carefully, and feel free to talk with me about them. -- Abstract -- The Real Time Streaming Protocol, or RTSP, is an application-level protocol "application-layer", maybe? Also in the Introduction. -- Section 2.2 -- The RTSP client can request the establishment of an RTSP session after having used the presentation description to determine which media streams are available, and also which media delivery protocol is used and their particular resource identifiers. What is the antecedent to "their"? The only thing here that's plural is "media streams", so I guess it has to be that, but the sentence isn't clear there. I suggest rephrasing it this way: NEW The RTSP client can request the establishment of an RTSP session after having used the presentation description to determine which media streams are available, which media delivery protocol is used, and the resource identifiers of [what, "the media streams"?]. END In the SETUP request the client also includes all the transport parameters necessary to enable the media delivery protocol to function in the "Transport" header This sounds like the media delivery protocol functions in the Transport header. Maybe this?: NEW In the "Transport" header of the SETUP request, the client also includes all the transport parameters necessary to enable the media delivery protocol to function END OLD The server determines if the media resource is available upon receiving a SETUP request and if any of the transport parameter specifications are acceptable. NEW Upon receiving a SETUP request, the server determines if the media resource is available and if any of the transport parameter specifications are acceptable. END A SETUP request that references an existing RTSP session but identifies a new media resource is a request to add that media resource under common control with the already present media resources in an aggregated session. A client can expect this to work for all media resources under RTSP control within a multi-media content. However, aggregating resources from different content are likely to be refused by the server. I had a lot of trouble sorting through this. Let me suggest some rephrasing, to see if I understand; if you like the rephrasing, please take some or all of it, correcting as needed: NEW When a SETUP request references an existing RTSP session but identifies a new media resource, it is a request to add that media resource under common control with the already present media resources. This is called an "aggregated session". A client can expect this to work for all media resources under RTSP control within the same multi-media content, but attempts to aggregate resources from different content are likely to be refused by the server. END The RTSP session as aggregate is referenced by the aggregate control URI, even if the RTSP session only contains a single media. I couldn't figure this out at all; can you try rephrasing it, please? -- Section 2.3 -- The basic operations are Start by using the PLAY method (Section 13.4) and Halt by using the PAUSE method (Section 13.6). Where is the value in making up alternative things to call these operations? Why not just call them "Play" and "Pause", to match the method names? Having "Halt" and "PAUSE" mean the same thing only seems to invite confusion, no? The support for positioning/searching within a content depends on the In plain English, "content" is a collective noun, and can't really have an indefinite article with it. I suggest that changing "a content" to "media content" (or "a content stream") will work, and I suggest that you make sure the document is consistent with respect to that usage. These are expressed using one or several independent attributes. A first attribute is Random Access, which expresses if positioning can be done, and with what granularity. Using "one or several" is a bit oddly phrased, and one is likely to read it as "one OF several." Perhaps, "using one or more independent attributes," expresses what you mean? Then, how can one have random access without being able to do positioning? So is "IF positioning can be done" really correct? -- Section 2.5 -- The delivery of media to the RTSP client is done with a protocol outside of RTSP and this protocol is determined during the session establishment. This document specifies how media is delivered with RTP [RFC3550] over UDP [RFC0768], TCP [RFC0793] or the RTSP connection. The first sentence says that media delivery doesn't happen through RTSP. The second sentence seems to say that RTSP can deliver media (it appears to be a third option). Which is it? -- Section 2.5.1 -- Scale = 0 is equal to pause and is not allowed. If it's not allowed, it's not equal to anything. I suggest just saying, "Scale = 0 is not allowed." An example is fast forward where only the independently decodable intra frames are included in the media stream. What are "intra frames"? -- Section 2.7 -- o A new version of the protocol can be defined, allowing almost all aspects (except the position of the protocol version number) to change. A new version of the protocol must be registered through an IETF standards track document. Which is, clearly, what you're doing with this document. It would probably be good to stress that doing this is really a last resort and is extremely disruptive to deployed products. It should only be used when the designed extension mechanisms have failed. -- Section 3.1 -- Since a few of the definitions are identical to HTTP/1.1, this specification only points to the section where they are defined rather than copying it. For brevity, [HX.Y] is to be taken to refer to Section X.Y of the current HTTP/1.1 specification ([RFC2616]). Ah, but 2616 is about to not be the current HTTP/1.1 specification; the httpbis set is likely to be approved by the IESG before this RFC is published. It would be nice to refer to the httpbis set of updates instead, but that would be too disruptive. I guess just take out the word "current", please. -- Section 4.4.2 -- The syntax is based on ISO 8601 [ISO.8601.2000]. Two different notations are allowed. The npt-hhmmss notation are using a ISO 8601 extended complete representation of the time of the day format (Section 5.3.1.1 of [ISO.8601.2000]) using colon (":") as separators between hours, minutes and seconds (hh:mm:ss). With the exception that it expresses duration since presentation start rather than time since midnight and the hour counter is not limited to 0-24 hours, instead up to nineteen (19) digits of hours are allowed. ISO 8601 time format requires all digits to be used for each format, and all format required needs to be included, e.g. if one use a hh:mm:ss format, then that requires two digits for hours, two digits for minutes and two digits for second, a time value such as 7 minutes and 0 seconds, is expressed as 00:07:00. The npt-sec notation is expressing the duration since presentation start in seconds, using one to nineteen (19) digits. Both notations allows decimal fractions of seconds as specified in Section 5.3.1.3 of [ISO.8601.2000] with the limitation of at maximum of 9 digits and only allowing "." (full stop) as separator. Due to RTSP 1.0 and the fact that the highest values are expanded beyond two digits, all implementations MUST allow the highest value to be single digit and SHALL NOT send leading zeros for hours in the npt-hhmmss notation and leading zeros for seconds in the npt-sec notation. The hours and the seconds in the npt-hhmmss notation SHALL be sent using leading zeros, but receivers SHALL accept values without leading zeros. This is too long to have in one block, combines too many things, and has some grammatical problems that make it hard to cope with. May I, please?: NEW The syntax is based on ISO 8601 [ISO.8601.2000] and expresses the time elapsed since presentation start, with two different notations allowed: o The npt-hhmmss notation uses an ISO 8601 extended complete representation of the time of the day format (Section 5.3.1.1 of [ISO.8601.2000]) using colon (":") as separators between hours, minutes and seconds (hh:mm:ss). The hour counter is not limited to 0-24 hours; up to nineteen (19) digits of hours are allowed. In accordance with the requirements of the ISO 8601 time format, the hours, minutes, and seconds must all be present, with two digits used for minutes and for seconds, and with a least two digits for hours. An NPT of 7 minutes and 0 seconds is represented as "00:07:00", and an NPT of 392 hours, 0 minutes, and 6 seconds is represented as "392:00:06". o The npt-sec notation expresses the time in seconds, using between one and nineteen (19) digits. Both notations allow decimal fractions of seconds as specified in Section 5.3.1.3 of [ISO.8601.2000], using at most 9 digits, and allowing only "." (full stop) as the decimal separator. END OK, now that leaves this bit at the end, which conflicts with some of what's above and even with itself (you said "00:07:00" above, and now you say no leading zeroes in hours, and then you say SHALL use leading zeroes; which is it?), and which doesn't make much sense to me anyway (what does "Due to RTSP 1.0" mean, for example?): Due to RTSP 1.0 and the fact that the highest values are expanded beyond two digits, all implementations MUST allow the highest value to be single digit and SHALL NOT send leading zeros for hours in the npt-hhmmss notation and leading zeros for seconds in the npt-sec notation. The hours and the seconds in the npt-hhmmss notation SHALL be sent using leading zeros, but receivers SHALL accept values without leading zeros. I'll leave that part for you to re-word, because I can't hope to do it right. -- Section 4.7.2 -- The following different media retention policies are envisioned and taken into consideration where applicable: What is that meant to be saying, really? Please rephrase it (I have no idea what "and taken into consideation where applicable" might mean). Time-Duration: Each individual unit of the media will be retained for the specified duration. What does "each individual unit of the media" mean? -- Section 4.7.3 -- Dynamic: Between explicit updates the media content will not change, but the content may change due to external methods or triggers, such as playlists. This sounds like doubletalk: it won't change, but it may change. I think it needs re-wording. -- Section 4.7.4 -- It may be updated at any point in the content due to content consisting of spliced pieces or content being dynamically updated by out-of-band mechanisms. I'm not sure what this is trying to say, but I *think* you mean this: NEW The list may be updated at any point in the content, because the content may consist of spliced pieces or may be dynamically updated by out-of-band mechanisms. END -- Section 4.7.5 -- It appeas that you're mixing example headings (which contain colons) on the same line as header fields (which contain colons), making the whole thing unclear. If I'm right, I think this sort of presentation would work lots better: OLD On-demand: Random Access: Random-Access=5.0, Content Modifications: Immutable, Retention: Unlimited or Time-Limited. Dynamic On-demand: Random Access: Random-Access=3.0, Content Modifications: Dynamic, Retention: Unlimited or Time-Limited. Live: Random Access: No-seeking, Content Modifications: Time- Progressing, Retention: Time-Duration=0.0 Live with Recording: Random Access: Random-Access=3.0, Content Modifications: Time-Progressing, Retention: Time-Duration=7200.0 NEW Example of "On-demand": Random Access: Random-Access=5.0, Content Modifications: Immutable, Retention: Unlimited or Time-Limited. Example of "Dynamic On-demand": Random Access: Random-Access=3.0, Content Modifications: Dynamic, Retention: Unlimited or Time-Limited. Example of "Live": Random Access: No-seeking, Content Modifications: Time- Progressing, Retention: Time-Duration=0.0 Example of "Live with Recording": Random Access: Random-Access=3.0, Content Modifications: Time-Progressing, Retention: Time-Duration=7200.0 END -- Section 5 -- Requests contain methods, the object the method is operating upon and parameters to further describe the method. You switch from plural to singular after the first comma. Assuming that each request contains a single method, this is better: NEW A request contains a method, the object the method is operating upon, and parameters to further describe the method. END (Side question: This implies that every method has an object; is that correct?) -- Section 5.1 -- RTSP messages consist of requests from client to server, or server to client, and responses in the reverse direction. I would say that RTSP *sessions* consist of requests and responses. RTSP messages don't consist of requests and responses: they *are* those requests and responses: NEW An RTSP message is a request from a client to a server or from a server to a client, or a response in the reverse direction. END In the interest of robustness, agents MUST ignore any empty line(s) received where a Request-Line or Response-Line is expected. In other words, if the agent is reading the protocol stream at the beginning of a message and receives a CRLF first, it MUST ignore the CRLF. What's a "Response-Line"? I also presume the last sentence above is applicable recursively (you want to ignore any number of leading CRLF sequences), yes? Might be good to be clear about that. -- Section 8.2 -- A new or experimental header MAY be given the semantics of response-header if all parties in the communication recognize them to be a response-header. This seems an incorrect use of 2119 MAY... It is not describing an optional protocol feauture. I'd make it "can", in this context. -- Section 9 -- Request and Response messages MAY transfer a message body, if not otherwise restricted by the request method or response status code. This is a trickier one, but is really *not* a 2119 MAY: it's not a purely optional thing for a message to transfer a message body. It either does, or it doesn't, based on what the message is doing. But if a particular nessage uses a message body, that can't be omitted as an implementation option. This statement needs to be re-worded to reflect the actual requirement here. I think "Some Request and Response messages include message bodies," is sufficient. If you want, it'd be reasonable to add, ", depending upon the request method and response status code." You'll similarly need to dispose of the MAY in the first sentence of the second paragraph. The rest of the MAYs in that paragraph look correct: they truly are describing optional behaviour. -- Section 9.3 -- HTTP and email have both historically had horrendous problems with inaccurate or missing Content-Type headers. It's good that you use MUST for Content-Type; that has to help. I would be happier (though not at DISCUSS level) if you should say a few more words about Content-Type here: something about how it MUST accurately specify the type and subtype of the content, that there are no defaults for type or subtype, and that attempts to use heuristics to second-guess this are Very Bad. |
2013-11-21
|
38 | Barry Leiba | Ballot comment text updated for Barry Leiba |
2013-11-21
|
38 | Barry Leiba | [Ballot discuss] I have not finished reviewing yet: I'm just about to start Section 10 as I post this, so I have well over 250 … [Ballot discuss] I have not finished reviewing yet: I'm just about to start Section 10 as I post this, so I have well over 250 pages yet to read, and I'm sure I'll have many more comments. But I want to get some of this out here now, so the authors aren't entirely blindsided at the last minute. I also might ask that we defer this one telechat, though I'm holding off on that for now. What I have so far follows, in both the DISCUSS and COMMENT sections. ----------------------------------------------------------- 1. This point falls into the "URI/IRI follies" category: -- Section 3.2 -- IRI: Internationalized Resource Identifier, is the same as a URI, with the exception that it allows characters from the whole Oh, my; please don't say that it's "the same as a URI". It'd be reasonable to say "is similar to a URI, but allows characters [etc]." -- Section 4.2 -- The RTSP URI and IRI are case sensitive, with the exception of those parts that [RFC3986] and [RFC3987] define as case-insensitive; for example, the scheme and host part. Clumping URIs and IRIs together in such a vague way with respect to case mapping is a dangerous thing. And unless there's a particular reason to say otherwise, it's easy to avoid that by specifically saying that the scheme and host parts are the *only* case-sensitive bits (which is true of generic URIs and IRIs anyway). Is there really a reason not to be clearer, this way?: NEW The "scheme" and "host" parts of all URIs [RFC3986] and IRIs [RFC3987] are case-insensitive. All other parts of RTSP URIs and IRIs are case- sensitive, and SHOULD NOT be case-mapped. END 2. The paragraph in Section 4.4.2 that explains npt-hhmmss notation and npt-sec notation has some internal inconsistencies that have to be fixed. See my suggestions in the comments section below, which goes beyond the blocking point (the inconsistency) and tries to make the paragraph more readable as well. 3. I'm disturbed by this combination in Section 9.2: it appears that Content-Encoding is optional (the first paragraph doesn't say it MUST be included, and the second paragraph uses lower-case-"may" to describe its inclusion), but the second paragraph says that there is no default encoding. So what does it mean to have a message body with no Content-Encoding header? |
2013-11-21
|
38 | Barry Leiba | [Ballot comment] First, a comment for the responsible AD: The grammar, punctuation, and English usage in Section 2 and its subsections is at times very … [Ballot comment] First, a comment for the responsible AD: The grammar, punctuation, and English usage in Section 2 and its subsections is at times very hard to sort through. I'm going to call out in the comments some bits that I found particularly troublesome, and will try to suggest alternatives. I also suggest that the responsible AD put in an RFC Editor note asking the editors to pay particular attention here and to give it some heavy editing for language clarity. This is a complex document, and a good overview in clear English will really help. Here's a suggestion for text for an RFC Editor note: ------------------------------ RFC Editor note: Section 2 of this document and its subsections provide "an informative overview of the different mechanisms in the RTSP 2.0 protocol, to give the reader a high level understanding". As such, it's very important that it be clear and well written. Some reviewers have found the English to be difficult. Please take an especially critical pen to this section, making sure that the grammar and usage are correct, and that the language is clear. ------------------------------ These are non-blocking, but many of them address readability issues and go beyond simple editorial points. Please consider them carefully, and feel free to talk with me about them. -- Abstract -- The Real Time Streaming Protocol, or RTSP, is an application-level protocol "application-layer", maybe? Also in the Introduction. -- Section 2.2 -- The RTSP client can request the establishment of an RTSP session after having used the presentation description to determine which media streams are available, and also which media delivery protocol is used and their particular resource identifiers. What is the antecedent to "their"? The only thing here that's plural is "media streams", so I guess it has to be that, but the sentence isn't clear there. I suggest rephrasing it this way: NEW The RTSP client can request the establishment of an RTSP session after having used the presentation description to determine which media streams are available, which media delivery protocol is used, and the resource identifiers of [what, "the media streams"?]. END In the SETUP request the client also includes all the transport parameters necessary to enable the media delivery protocol to function in the "Transport" header This sounds like the media delivery protocol functions in the Transport header. Maybe this?: NEW In the "Transport" header of the SETUP request, the client also includes all the transport parameters necessary to enable the media delivery protocol to function END OLD The server determines if the media resource is available upon receiving a SETUP request and if any of the transport parameter specifications are acceptable. NEW Upon receiving a SETUP request, the server determines if the media resource is available and if any of the transport parameter specifications are acceptable. END A SETUP request that references an existing RTSP session but identifies a new media resource is a request to add that media resource under common control with the already present media resources in an aggregated session. A client can expect this to work for all media resources under RTSP control within a multi-media content. However, aggregating resources from different content are likely to be refused by the server. I had a lot of trouble sorting through this. Let me suggest some rephrasing, to see if I understand; if you like the rephrasing, please take some or all of it, correcting as needed: NEW When a SETUP request references an existing RTSP session but identifies a new media resource, it is a request to add that media resource under common control with the already present media resources. This is called an "aggregated session". A client can expect this to work for all media resources under RTSP control within the same multi-media content, but attempts to aggregate resources from different content are likely to be refused by the server. END The RTSP session as aggregate is referenced by the aggregate control URI, even if the RTSP session only contains a single media. I couldn't figure this out at all; can you try rephrasing it, please? -- Section 2.3 -- The basic operations are Start by using the PLAY method (Section 13.4) and Halt by using the PAUSE method (Section 13.6). Where is the value in making up alternative things to call these operations? Why not just call them "Play" and "Pause", to match the method names? Having "Halt" and "PAUSE" mean the same thing only seems to invite confusion, no? The support for positioning/searching within a content depends on the In plain English, "content" is a collective noun, and can't really have an indefinite article with it. I suggest that changing "a content" to "media content" (or "a content stream") will work, and I suggest that you make sure the document is consistent with respect to that usage. These are expressed using one or several independent attributes. A first attribute is Random Access, which expresses if positioning can be done, and with what granularity. Using "one or several" is a bit oddly phrased, and one is likely to read it as "one OF several." Perhaps, "using one or more independent attributes," expresses what you mean? Then, how can one have random access without being able to do positioning? So is "IF positioning can be done" really correct? -- Section 2.5 -- The delivery of media to the RTSP client is done with a protocol outside of RTSP and this protocol is determined during the session establishment. This document specifies how media is delivered with RTP [RFC3550] over UDP [RFC0768], TCP [RFC0793] or the RTSP connection. The first sentence says that media delivery doesn't happen through RTSP. The second sentence seems to say that RTSP can deliver media (it appears to be a third option). Which is it? -- Section 2.5.1 -- Scale = 0 is equal to pause and is not allowed. If it's not allowed, it's not equal to anything. I suggest just saying, "Scale = 0 is not allowed." An example is fast forward where only the independently decodable intra frames are included in the media stream. What are "intra frames"? -- Section 2.7 -- o A new version of the protocol can be defined, allowing almost all aspects (except the position of the protocol version number) to change. A new version of the protocol must be registered through an IETF standards track document. Which is, clearly, what you're doing with this document. It would probably be good to stress that doing this is really a last resort and is extremely disruptive to deployed products. It should only be used when the designed extension mechanisms have failed. -- Section 3.1 -- Since a few of the definitions are identical to HTTP/1.1, this specification only points to the section where they are defined rather than copying it. For brevity, [HX.Y] is to be taken to refer to Section X.Y of the current HTTP/1.1 specification ([RFC2616]). Ah, but 2616 is about to not be the current HTTP/1.1 specification; the httpbis set is likely to be approved by the IESG before this RFC is published. It would be nice to refer to the httpbis set of updates instead, but that would be too disruptive. I guess just take out the word "current", please. -- Section 4.4.2 -- The syntax is based on ISO 8601 [ISO.8601.2000]. Two different notations are allowed. The npt-hhmmss notation are using a ISO 8601 extended complete representation of the time of the day format (Section 5.3.1.1 of [ISO.8601.2000]) using colon (":") as separators between hours, minutes and seconds (hh:mm:ss). With the exception that it expresses duration since presentation start rather than time since midnight and the hour counter is not limited to 0-24 hours, instead up to nineteen (19) digits of hours are allowed. ISO 8601 time format requires all digits to be used for each format, and all format required needs to be included, e.g. if one use a hh:mm:ss format, then that requires two digits for hours, two digits for minutes and two digits for second, a time value such as 7 minutes and 0 seconds, is expressed as 00:07:00. The npt-sec notation is expressing the duration since presentation start in seconds, using one to nineteen (19) digits. Both notations allows decimal fractions of seconds as specified in Section 5.3.1.3 of [ISO.8601.2000] with the limitation of at maximum of 9 digits and only allowing "." (full stop) as separator. Due to RTSP 1.0 and the fact that the highest values are expanded beyond two digits, all implementations MUST allow the highest value to be single digit and SHALL NOT send leading zeros for hours in the npt-hhmmss notation and leading zeros for seconds in the npt-sec notation. The hours and the seconds in the npt-hhmmss notation SHALL be sent using leading zeros, but receivers SHALL accept values without leading zeros. This is too long to have in one block, combines too many things, and has some grammatical problems that make it hard to cope with. May I, please?: NEW The syntax is based on ISO 8601 [ISO.8601.2000] and expresses the time elapsed since presentation start, with two different notations allowed: o The npt-hhmmss notation uses an ISO 8601 extended complete representation of the time of the day format (Section 5.3.1.1 of [ISO.8601.2000]) using colon (":") as separators between hours, minutes and seconds (hh:mm:ss). The hour counter is not limited to 0-24 hours; up to nineteen (19) digits of hours are allowed. In accordance with the requirements of the ISO 8601 time format, the hours, minutes, and seconds must all be present, with two digits used for minutes and for seconds, and with a least two digits for hours. An NPT of 7 minutes and 0 seconds is represented as "00:07:00", and an NPT of 392 hours, 0 minutes, and 6 seconds is represented as "392:00:06". o The npt-sec notation expresses the time in seconds, using between one and nineteen (19) digits. Both notations allow decimal fractions of seconds as specified in Section 5.3.1.3 of [ISO.8601.2000], using at most 9 digits, and allowing only "." (full stop) as the decimal separator. END OK, now that leaves this bit at the end, which conflicts with some of what's above and even with itself (you said "00:07:00" above, and now you say no leading zeroes in hours, and then you say SHALL use leading zeroes; which is it?), and which doesn't make much sense to me anyway (what does "Due to RTSP 1.0" mean, for example?): Due to RTSP 1.0 and the fact that the highest values are expanded beyond two digits, all implementations MUST allow the highest value to be single digit and SHALL NOT send leading zeros for hours in the npt-hhmmss notation and leading zeros for seconds in the npt-sec notation. The hours and the seconds in the npt-hhmmss notation SHALL be sent using leading zeros, but receivers SHALL accept values without leading zeros. I'll leave that part for you to re-word, because I can't hope to do it right. -- Section 4.7.2 -- The following different media retention policies are envisioned and taken into consideration where applicable: What is that meant to be saying, really? Please rephrase it (I have no idea what "and taken into consideation where applicable" might mean). Time-Duration: Each individual unit of the media will be retained for the specified duration. What does "each individual unit of the media" mean? -- Section 4.7.3 -- Dynamic: Between explicit updates the media content will not change, but the content may change due to external methods or triggers, such as playlists. This sounds like doubletalk: it won't change, but it may change. I think it needs re-wording. -- Section 4.7.4 -- It may be updated at any point in the content due to content consisting of spliced pieces or content being dynamically updated by out-of-band mechanisms. I'm not sure what this is trying to say, but I *think* you mean this: NEW The list may be updated at any point in the content, because the content may consist of spliced pieces or may be dynamically updated by out-of-band mechanisms. END -- Section 4.7.5 -- It appeas that you're mixing example headings (which contain colons) on the same line as header fields (which contain colons), making the whole thing unclear. If I'm right, I think this sort of presentation would work lots better: OLD On-demand: Random Access: Random-Access=5.0, Content Modifications: Immutable, Retention: Unlimited or Time-Limited. Dynamic On-demand: Random Access: Random-Access=3.0, Content Modifications: Dynamic, Retention: Unlimited or Time-Limited. Live: Random Access: No-seeking, Content Modifications: Time- Progressing, Retention: Time-Duration=0.0 Live with Recording: Random Access: Random-Access=3.0, Content Modifications: Time-Progressing, Retention: Time-Duration=7200.0 NEW Example of "On-demand": Random Access: Random-Access=5.0, Content Modifications: Immutable, Retention: Unlimited or Time-Limited. Example of "Dynamic On-demand": Random Access: Random-Access=3.0, Content Modifications: Dynamic, Retention: Unlimited or Time-Limited. Example of "Live": Random Access: No-seeking, Content Modifications: Time- Progressing, Retention: Time-Duration=0.0 Example of "Live with Recording": Random Access: Random-Access=3.0, Content Modifications: Time-Progressing, Retention: Time-Duration=7200.0 END -- Section 5 -- Requests contain methods, the object the method is operating upon and parameters to further describe the method. You switch from plural to singular after the first comma. Assuming that each request contains a single method, this is better: NEW A request contains a method, the object the method is operating upon, and parameters to further describe the method. END (Side question: This implies that every method has an object; is that correct?) -- Section 5.1 -- RTSP messages consist of requests from client to server, or server to client, and responses in the reverse direction. I would say that RTSP *sessions* consist of requests and responses. RTSP messages don't consist of requests and responses: they *are* those requests and responses: NEW An RTSP message is a request from a client to a server or from a server to a client, or a response in the reverse direction. END In the interest of robustness, agents MUST ignore any empty line(s) received where a Request-Line or Response-Line is expected. In other words, if the agent is reading the protocol stream at the beginning of a message and receives a CRLF first, it MUST ignore the CRLF. What's a "Response-Line"? I also presume the last sentence above is applicable recursively (you want to ignore any number of leading CRLF sequences), yes? Might be good to be clear about that. -- Section 8.2 -- A new or experimental header MAY be given the semantics of response-header if all parties in the communication recognize them to be a response-header. This seems an incorrect use of 2119 MAY... It is not describing an optional protocol feauture. I'd make it "can", in this context. -- Section 9 -- Request and Response messages MAY transfer a message body, if not otherwise restricted by the request method or response status code. This is a trickier one, but is really *not* a 2119 MAY: it's not a purely optional thing for a message to transfer a message body. It either does, or it doesn't, based on what the message is doing. But if a particular nessage uses a message body, that can't be omitted as an implementation option. This statement needs to be re-worded to reflect the actual requirement here. I think "Some Request and Response messages include message bodies," is sufficient. If you want, it'd be reasonable to add, ", depending upon the request method and response status code." You'll similarly need to dispose of the MAY in the first sentence of the second paragraph. The rest of the MAYs in that paragraph look correct: they truly are describing optional behaviour. -- Section 9.3 -- HTTP and email have both historically had horrendous problems with inaccurate or missing Content-Type headers. It's good that you use MUST for Content-Type; that has to help. I would be happier (though not at DISCUSS level) if you should say a few more words about Content-Type here: something about how it MUST accurately specify the type and subtype of the content, that there are no defaults for type or subtype, and that attempts to use heuristics to second-guess this are Very Bad. |
2013-11-21
|
38 | Barry Leiba | Ballot comment and discuss text updated for Barry Leiba |
2013-11-21
|
38 | Cindy Morgan | Telechat date has been changed to 2013-12-05 from 2013-11-21 |
2013-11-20
|
38 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to John Brzozowski |
2013-11-20
|
38 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to John Brzozowski |
2013-11-20
|
38 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2013-11-20
|
38 | Stewart Bryant | [Ballot comment] I have reviewed this text solely looking for impact on the routing system and see no such impact. |
2013-11-20
|
38 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2013-11-20
|
38 | Joel Jaeggli | [Ballot comment] I'm not going to be able review this one in time sorry |
2013-11-20
|
38 | Joel Jaeggli | Ballot comment text updated for Joel Jaeggli |
2013-11-20
|
38 | Joel Jaeggli | State changed to IESG Evaluation - Defer from IESG Evaluation |
2013-11-19
|
38 | Barry Leiba | [Ballot discuss] I have not finished reviewing yet: I'm just about to start Section 10 as I post this, so I have well over 250 … [Ballot discuss] I have not finished reviewing yet: I'm just about to start Section 10 as I post this, so I have well over 250 pages yet to read, and I'm sure I'll have many more comments. But I want to get some of this out here now, so the authors aren't entirely blindsided at the last minute. I also might ask that we defer this one telechat, though I'm holding off on that for now. What I have so far follows, in both the DISCUSS and COMMENT sections. ----------------------------------------------------------- 1. This first point is for some discussion with the responsible AD, and I'll clear it after we have that discussion: The grammar, punctuation, and English usage in Section 2 and its subsections is at times very hard to sort through. I'm going to call out in the comments some bits that I found particularly troublesome, and will try to suggest alternatives. I also suggest that the responsible AD put in an RFC Editor note asking the editors to pay particular attention here and to give it some heavy editing for language clarity. This is a complex document, and a good overview in clear English will really help. 2. This point falls into the "URI/IRI follies" category: -- Section 3.2 -- IRI: Internationalized Resource Identifier, is the same as a URI, with the exception that it allows characters from the whole Oh, my; please don't say that it's "the same as a URI". It'd be reasonable to say "is similar to a URI, but allows characters [etc]." -- Section 4.2 -- The RTSP URI and IRI are case sensitive, with the exception of those parts that [RFC3986] and [RFC3987] define as case-insensitive; for example, the scheme and host part. Clumping URIs and IRIs together in such a vague way with respect to case mapping is a dangerous thing. And unless there's a particular reason to say otherwise, it's easy to avoid that by specifically saying that the scheme and host parts are the *only* case-sensitive bits (which is true of generic URIs and IRIs anyway). Is there really a reason not to be clearer, this way?: NEW The "scheme" and "host" parts of all URIs [RFC3986] and IRIs [RFC3987] are case-insensitive. All other parts of RTSP URIs and IRIs are case- sensitive, and SHOULD NOT be case-mapped. END 3. The paragraph in Section 4.4.2 that explains npt-hhmmss notation and npt-sec notation has some internal inconsistencies that have to be fixed. See my suggestions in the comments section below, which goes beyond the blocking point (the inconsistency) and tries to make the paragraph more readable as well. 4. I'm disturbed by this combination in Section 9.2: it appears that Content-Encoding is optional (the first paragraph doesn't say it MUST be included, and the second paragraph uses lower-case-"may" to describe its inclusion), but the second paragraph says that there is no default encoding. So what does it mean to have a message body with no Content-Encoding header? |
2013-11-19
|
38 | Barry Leiba | [Ballot comment] These are non-blocking, but many of them address readability issues and go beyond simple editorial points. Please consider them carefully, and feel free … [Ballot comment] These are non-blocking, but many of them address readability issues and go beyond simple editorial points. Please consider them carefully, and feel free to talk with me about them. -- Abstract -- The Real Time Streaming Protocol, or RTSP, is an application-level protocol "application-layer", maybe? Also in the Introduction. -- Section 2.2 -- The RTSP client can request the establishment of an RTSP session after having used the presentation description to determine which media streams are available, and also which media delivery protocol is used and their particular resource identifiers. What is the antecedent to "their"? The only thing here that's plural is "media streams", so I guess it has to be that, but the sentence isn't clear there. I suggest rephrasing it this way: NEW The RTSP client can request the establishment of an RTSP session after having used the presentation description to determine which media streams are available, which media delivery protocol is used, and the resource identifiers of [what, "the media streams"?]. END In the SETUP request the client also includes all the transport parameters necessary to enable the media delivery protocol to function in the "Transport" header This sounds like the media delivery protocol functions in the Transport header. Maybe this?: NEW In the "Transport" header of the SETUP request, the client also includes all the transport parameters necessary to enable the media delivery protocol to function END OLD The server determines if the media resource is available upon receiving a SETUP request and if any of the transport parameter specifications are acceptable. NEW Upon receiving a SETUP request, the server determines if the media resource is available and if any of the transport parameter specifications are acceptable. END A SETUP request that references an existing RTSP session but identifies a new media resource is a request to add that media resource under common control with the already present media resources in an aggregated session. A client can expect this to work for all media resources under RTSP control within a multi-media content. However, aggregating resources from different content are likely to be refused by the server. I had a lot of trouble sorting through this. Let me suggest some rephrasing, to see if I understand; if you like the rephrasing, please take some or all of it, correcting as needed: NEW When a SETUP request references an existing RTSP session but identifies a new media resource, it is a request to add that media resource under common control with the already present media resources. This is called an "aggregated session". A client can expect this to work for all media resources under RTSP control within the same multi-media content, but attempts to aggregate resources from different content are likely to be refused by the server. END The RTSP session as aggregate is referenced by the aggregate control URI, even if the RTSP session only contains a single media. I couldn't figure this out at all; can you try rephrasing it, please? -- Section 2.3 -- The basic operations are Start by using the PLAY method (Section 13.4) and Halt by using the PAUSE method (Section 13.6). Where is the value in making up alternative things to call these operations? Why not just call them "Play" and "Pause", to match the method names? Having "Halt" and "PAUSE" mean the same thing only seems to invite confusion, no? The support for positioning/searching within a content depends on the In plain English, "content" is a collective noun, and can't really have an indefinite article with it. I suggest that changing "a content" to "media content" (or "a content stream") will work, and I suggest that you make sure the document is consistent with respect to that usage. These are expressed using one or several independent attributes. A first attribute is Random Access, which expresses if positioning can be done, and with what granularity. Using "one or several" is a bit oddly phrased, and one is likely to read it as "one OF several." Perhaps, "using one or more independent attributes," expresses what you mean? Then, how can one have random access without being able to do positioning? So is "IF positioning can be done" really correct? -- Section 2.5 -- The delivery of media to the RTSP client is done with a protocol outside of RTSP and this protocol is determined during the session establishment. This document specifies how media is delivered with RTP [RFC3550] over UDP [RFC0768], TCP [RFC0793] or the RTSP connection. The first sentence says that media delivery doesn't happen through RTSP. The second sentence seems to say that RTSP can deliver media (it appears to be a third option). Which is it? -- Section 2.5.1 -- Scale = 0 is equal to pause and is not allowed. If it's not allowed, it's not equal to anything. I suggest just saying, "Scale = 0 is not allowed." An example is fast forward where only the independently decodable intra frames are included in the media stream. What are "intra frames"? -- Section 2.7 -- o A new version of the protocol can be defined, allowing almost all aspects (except the position of the protocol version number) to change. A new version of the protocol must be registered through an IETF standards track document. Which is, clearly, what you're doing with this document. It would probably be good to stress that doing this is really a last resort and is extremely disruptive to deployed products. It should only be used when the designed extension mechanisms have failed. -- Section 3.1 -- Since a few of the definitions are identical to HTTP/1.1, this specification only points to the section where they are defined rather than copying it. For brevity, [HX.Y] is to be taken to refer to Section X.Y of the current HTTP/1.1 specification ([RFC2616]). Ah, but 2616 is about to not be the current HTTP/1.1 specification; the httpbis set is likely to be approved by the IESG before this RFC is published. It would be nice to refer to the httpbis set of updates instead, but that would be too disruptive. I guess just take out the word "current", please. -- Section 4.4.2 -- The syntax is based on ISO 8601 [ISO.8601.2000]. Two different notations are allowed. The npt-hhmmss notation are using a ISO 8601 extended complete representation of the time of the day format (Section 5.3.1.1 of [ISO.8601.2000]) using colon (":") as separators between hours, minutes and seconds (hh:mm:ss). With the exception that it expresses duration since presentation start rather than time since midnight and the hour counter is not limited to 0-24 hours, instead up to nineteen (19) digits of hours are allowed. ISO 8601 time format requires all digits to be used for each format, and all format required needs to be included, e.g. if one use a hh:mm:ss format, then that requires two digits for hours, two digits for minutes and two digits for second, a time value such as 7 minutes and 0 seconds, is expressed as 00:07:00. The npt-sec notation is expressing the duration since presentation start in seconds, using one to nineteen (19) digits. Both notations allows decimal fractions of seconds as specified in Section 5.3.1.3 of [ISO.8601.2000] with the limitation of at maximum of 9 digits and only allowing "." (full stop) as separator. Due to RTSP 1.0 and the fact that the highest values are expanded beyond two digits, all implementations MUST allow the highest value to be single digit and SHALL NOT send leading zeros for hours in the npt-hhmmss notation and leading zeros for seconds in the npt-sec notation. The hours and the seconds in the npt-hhmmss notation SHALL be sent using leading zeros, but receivers SHALL accept values without leading zeros. This is too long to have in one block, combines too many things, and has some grammatical problems that make it hard to cope with. May I, please?: NEW The syntax is based on ISO 8601 [ISO.8601.2000] and expresses the time elapsed since presentation start, with two different notations allowed: o The npt-hhmmss notation uses an ISO 8601 extended complete representation of the time of the day format (Section 5.3.1.1 of [ISO.8601.2000]) using colon (":") as separators between hours, minutes and seconds (hh:mm:ss). The hour counter is not limited to 0-24 hours; up to nineteen (19) digits of hours are allowed. In accordance with the requirements of the ISO 8601 time format, the hours, minutes, and seconds must all be present, with two digits used for minutes and for seconds, and with a least two digits for hours. An NPT of 7 minutes and 0 seconds is represented as "00:07:00", and an NPT of 392 hours, 0 minutes, and 6 seconds is represented as "392:00:06". o The npt-sec notation expresses the time in seconds, using between one and nineteen (19) digits. Both notations allow decimal fractions of seconds as specified in Section 5.3.1.3 of [ISO.8601.2000], using at most 9 digits, and allowing only "." (full stop) as the decimal separator. END OK, now that leaves this bit at the end, which conflicts with some of what's above and even with itself (you said "00:07:00" above, and now you say no leading zeroes in hours, and then you say SHALL use leading zeroes; which is it?), and which doesn't make much sense to me anyway (what does "Due to RTSP 1.0" mean, for example?): Due to RTSP 1.0 and the fact that the highest values are expanded beyond two digits, all implementations MUST allow the highest value to be single digit and SHALL NOT send leading zeros for hours in the npt-hhmmss notation and leading zeros for seconds in the npt-sec notation. The hours and the seconds in the npt-hhmmss notation SHALL be sent using leading zeros, but receivers SHALL accept values without leading zeros. I'll leave that part for you to re-word, because I can't hope to do it right. -- Section 4.7.2 -- The following different media retention policies are envisioned and taken into consideration where applicable: What is that meant to be saying, really? Please rephrase it (I have no idea what "and taken into consideation where applicable" might mean). Time-Duration: Each individual unit of the media will be retained for the specified duration. What does "each individual unit of the media" mean? -- Section 4.7.3 -- Dynamic: Between explicit updates the media content will not change, but the content may change due to external methods or triggers, such as playlists. This sounds like doubletalk: it won't change, but it may change. I think it needs re-wording. -- Section 4.7.4 -- It may be updated at any point in the content due to content consisting of spliced pieces or content being dynamically updated by out-of-band mechanisms. I'm not sure what this is trying to say, but I *think* you mean this: NEW The list may be updated at any point in the content, because the content may consist of spliced pieces or may be dynamically updated by out-of-band mechanisms. END -- Section 4.7.5 -- It appeas that you're mixing example headings (which contain colons) on the same line as header fields (which contain colons), making the whole thing unclear. If I'm right, I think this sort of presentation would work lots better: OLD On-demand: Random Access: Random-Access=5.0, Content Modifications: Immutable, Retention: Unlimited or Time-Limited. Dynamic On-demand: Random Access: Random-Access=3.0, Content Modifications: Dynamic, Retention: Unlimited or Time-Limited. Live: Random Access: No-seeking, Content Modifications: Time- Progressing, Retention: Time-Duration=0.0 Live with Recording: Random Access: Random-Access=3.0, Content Modifications: Time-Progressing, Retention: Time-Duration=7200.0 NEW Example of "On-demand": Random Access: Random-Access=5.0, Content Modifications: Immutable, Retention: Unlimited or Time-Limited. Example of "Dynamic On-demand": Random Access: Random-Access=3.0, Content Modifications: Dynamic, Retention: Unlimited or Time-Limited. Example of "Live": Random Access: No-seeking, Content Modifications: Time- Progressing, Retention: Time-Duration=0.0 Example of "Live with Recording": Random Access: Random-Access=3.0, Content Modifications: Time-Progressing, Retention: Time-Duration=7200.0 END -- Section 5 -- Requests contain methods, the object the method is operating upon and parameters to further describe the method. You switch from plural to singular after the first comma. Assuming that each request contains a single method, this is better: NEW A request contains a method, the object the method is operating upon, and parameters to further describe the method. END (Side question: This implies that every method has an object; is that correct?) -- Section 5.1 -- RTSP messages consist of requests from client to server, or server to client, and responses in the reverse direction. I would say that RTSP *sessions* consist of requests and responses. RTSP messages don't consist of requests and responses: they *are* those requests and responses: NEW An RTSP message is a request from a client to a server or from a server to a client, or a response in the reverse direction. END In the interest of robustness, agents MUST ignore any empty line(s) received where a Request-Line or Response-Line is expected. In other words, if the agent is reading the protocol stream at the beginning of a message and receives a CRLF first, it MUST ignore the CRLF. What's a "Response-Line"? I also presume the last sentence above is applicable recursively (you want to ignore any number of leading CRLF sequences), yes? Might be good to be clear about that. -- Section 8.2 -- A new or experimental header MAY be given the semantics of response-header if all parties in the communication recognize them to be a response-header. This seems an incorrect use of 2119 MAY... It is not describing an optional protocol feauture. I'd make it "can", in this context. -- Section 9 -- Request and Response messages MAY transfer a message body, if not otherwise restricted by the request method or response status code. This is a trickier one, but is really *not* a 2119 MAY: it's not a purely optional thing for a message to transfer a message body. It either does, or it doesn't, based on what the message is doing. But if a particular nessage uses a message body, that can't be omitted as an implementation option. This statement needs to be re-worded to reflect the actual requirement here. I think "Some Request and Response messages include message bodies," is sufficient. If you want, it'd be reasonable to add, ", depending upon the request method and response status code." You'll similarly need to dispose of the MAY in the first sentence of the second paragraph. The rest of the MAYs in that paragraph look correct: they truly are describing optional behaviour. -- Section 9.3 -- HTTP and email have both historically had horrendous problems with inaccurate or missing Content-Type headers. It's good that you use MUST for Content-Type; that has to help. I would be happier (though not at DISCUSS level) if you should say a few more words about Content-Type here: something about how it MUST accurately specify the type and subtype of the content, that there are no defaults for type or subtype, and that attempts to use heuristics to second-guess this are Very Bad. |
2013-11-19
|
38 | Barry Leiba | [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba |
2013-11-18
|
38 | Martin Stiemerling | [Ballot Position Update] New position, Recuse, has been recorded for Martin Stiemerling |
2013-11-17
|
38 | Pete Resnick | [Ballot comment] I have not completed (read: barely started) my review of this document, hence my "No Record", but I did have an overall question … [Ballot comment] I have not completed (read: barely started) my review of this document, hence my "No Record", but I did have an overall question to ask. The writeup says: Working Group Summary The document has been work in progress for an extended period of time dating back to 2002. Earlier versions saw decent WG participation however the later versions have primarily been driven by the document authors with limited overall discussion in the group, especially towards the end of the process.[...] Document Quality [...] There is one known implementation of the specification, and many of the extensions compared to RTSP 1.0 have been implemented separately as well. And the document says: RTSP 2.0 is a replacement of RTSP 1.0 [RFC2326] and obsoletes that specification. This protocol is based on RTSP 1.0 but is not backwards compatible other than in the basic version negotiation mechanism. This combination sounds worrisome to me. You are obsoleting 2326 with a non-backwards-compatible new version, there is only one known implementation, and it sounds like the WG has tuned out. Are you saying that anyone who is about to implement RTSP should ignore 2326 as obsolete and go straight to this document? And you're saying that they're going to be able to interoperate with anyone? That sounds...unlikely, at least given that combination of information given here. What am I missing? |
2013-11-17
|
38 | Pete Resnick | Ballot comment text updated for Pete Resnick |
2013-11-15
|
38 | Elwyn Davies | Request for Telechat review by GENART Completed: Ready. Reviewer: Elwyn Davies. |
2013-11-14
|
38 | Jean Mahoney | Request for Telechat review by GENART is assigned to Elwyn Davies |
2013-11-14
|
38 | Jean Mahoney | Request for Telechat review by GENART is assigned to Elwyn Davies |
2013-11-06
|
38 | Pearl Liang | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2013-10-31
|
38 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Chris Lonvick |
2013-10-31
|
38 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Chris Lonvick |
2013-10-30
|
38 | Gonzalo Camarillo | State changed to IESG Evaluation from Waiting for Writeup |
2013-10-30
|
38 | Gonzalo Camarillo | Placed on agenda for telechat - 2013-11-21 |
2013-10-30
|
38 | Gonzalo Camarillo | Changed consensus to Yes from Unknown |
2013-10-30
|
38 | Gonzalo Camarillo | Ballot has been issued |
2013-10-30
|
38 | Gonzalo Camarillo | [Ballot Position Update] New position, Yes, has been recorded for Gonzalo Camarillo |
2013-10-30
|
38 | Gonzalo Camarillo | Created "Approve" ballot |
2013-10-30
|
38 | Gonzalo Camarillo | Ballot writeup was changed |
2013-10-25
|
38 | (System) | State changed to Waiting for Writeup from In Last Call (ends 2013-10-25) |
2013-10-22
|
38 | (System) | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
2013-10-22
|
38 | (System) | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
2013-10-22
|
38 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-mmusic-rfc2326bis-38. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-mmusic-rfc2326bis-38. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. We received the following comments/questions from the IANA's reviewer: IANA has questions about some of the requests in the IANA Considerations section of this document. General questions for the authors: We note that four registries for RTSP v1.0 are located at: http://www.iana.org/assignments/rtsp-parameters/rtsp-parameters.xhtml. We understand that these registries (Headers, Methods, Option Tags and Status Codes) are to remain in place for compatibility purposes. Is this understanding correct? We also understand that the preferred approach to the new RTSP 2.0 registries is to simply create a new file/repository for the v2.0 parameters. Is this understanding correct? Upon approval of this document, we understand that there are to be four major actions completed by the IANA: 1] the creation of 17 new registries (see below) in a registry location to be determined; 2] the registration of three new, permanent URI schemes (in http://www.iana.org/assignments/uri-schemes.html); and, 3] the registration of three new SDP attributes (in http://www.iana.org/assignments/sdp-parameters) 4] the registration of a Media Type for text/parameters (in MIME Media Types registry located at: http://www.iana.org/assignments/media-types/index.html. Part 1: ===We understand that eighteen new registries are to be created. 1.1 A new registry called RTSP v2.0 feature-tags. The description of the contents of the registry is in section 22.1.1 of the draft document. We understand that future registrations are to be done on a first come, first served basis. We also understand that there are four initial values to be initially registered and that these are documented in section 22.1.3 of the draft. For each item in the RTSP v2.0 feature-tags registry, we understand that four fields will be registered: - the name of the feature tag (with rules for the creation of the name documented in section 22.1.2); - a description of the feature tag (a simple text string); - a indication of whether or not the feature tag applies to clients, servers or proxies (non-exclusively). and, - a reference for the source of the registry value (e.g. RFC, etc.) 1.2 A new registry called RTSP v2.0 Methods. The description of the meaning of RTSP Methods, the content of the registry, is in section 13 of the draft document. We understand that future registrations are to be done IETF Standards Action only. We also understand that there are ten initial values to be initially registered and that these are documented in section 22.2.3 of the draft. 1.3 A new registry called RTSP v2.0 Status Codes. We understand the description of RTSP v2.0 Status Codes to be "A status code is the three digit number used to convey information in RTSP response messages." We also understand that future registrations are to be done through IETF Review only. We also understand that there are 46 initial values to be initially registered and that these are to be extracted from the ABNF documentation for "Status-Code" in section 20.2.2 of the draft. For each item in the RTSP v2.0 Status Codes registry, we understand that three fields will be registered: - the three digit status code; - the meaning of the status code; and, - a reference for the source of the registry value. 1.4 A new registry called RTSP v2.0 Headers. We intend to use the description provided in section 22.4.1 of the document for this registry. We understand that future registrations are to be done using Expert Review. We also understand that there are 67 initial values to be initially registered and that these are to be extracted from Section 18 (56 values) and Section 22.4.3 (11 values) of the draft. We understand that the registry for RTSP 2.0 Headers will include only the header name and reference for each header. 1.5 A new registry called RTSP v2.0 Accept-Credentials policies. We also understand that future registrations are to be done through IETF Standards Action only. We also understand that there are three initial values to be initially registered and that these are "Any" "Proxy" and "User" QUESTION --> What text should be used as the description of this registry? QUESTION --> For the three initial values above, what should be used as the describing text (as required in section 22.5.1 of the current draft)? 1.6 A new registry called RTSP v2.0 Accept-Credentials hash algorithms. We understand the description of RTSP v2.0 Accept-Credentials hash algorithms to be the first sentence of text in Section 22.5.2 of the document. We also understand that future registrations are to be done through IETF Standards Action only. We understand that there is a single registration in this registry as follows: Hash Alg. Id Reference ---------------------------- sha-256 [ RFC-to-be ] 1.7 A new registry called RTSP v2.0 Cache Directive Extensions. We understand the description of RTSP v2.0 Cache Directive Extensions to be the first paragraph of the text in section 22.6 of the document. We also understand that future registrations are to be done through IETF Standards Action only. We also understand that there are 10 initial values to be registered upon approval of the document as documented in the text of section 22.6. IANA understands that the authors, with Magnus Westerlund (magnus.westerlund@ericsson.com) as primary, are to be used as the contact persons for initial entries created in this new registry. For each item in the RTSP v2.0 Cache Directive Extensions registry, We understand that three fields will be registered: - the name of the directive; - contact person; and, - a reference for the source of the registry value. 1.8 A new registry called RTSP v2.0 Media Properties. We understand the description of RTSP v2.0 Media Properties to be the text in section 22.7.1 of the document. We also understand that future registrations are to be done using Specification Required as defined in RFC 5226. We also understand that there are nine initial values to be registered upon approval of the document and that these are identified in section 16.29 of the document. IANA understands that the authors, with Magnus Westerlund (magnus.westerlund@ericsson.com) as primary, are to be used as the contact persons for initial entries created in this new registry. For each item in the RTSP v2.0 Media Properties registry, we understand that three fields will be registered: - the name of the media property; - a contact name for the property; - a reference for the source of the registry value. 1.9 A new registry called RTSP v2.0 Notify Reason Values. We understand the description of RTSP v2.0 Status Codes to be the first three sentences of the text in section 22.8.1 of the document. We also understand that future registrations are to be done using Specification Required as defined in RFC 5226. We also understand that there are three initial values to be registered upon approval of the document and that these are to be copied from the documentation provided in Section 22.8.3. IANA understands that the authors, with Magnus Westerlund (magnus.westerlund@ericsson.com) as primary, are to be used as the contact persons for initial entries created in this new registry. For each item in the RTSP v2.0 Notify Reason Values registry, we understand that four fields will be registered: - the Notify Reason Value; - the description of the value; - a contact name; and, - a reference for the source of the registry value. 1.10 A new registry called RTSP v2.0 Range Header formats. We understand the description of RTSP v2.0 Range Header formats should be: "The Range header allows for different range formats." We also understand that future registrations are to be done through Specification Required only. For each item in the RTSP v2.0 Range Header format registry, we understand that three fields will be registered: - the Range Header Format; - a contact name; and, - a reference for the source of the registry value. We also understand that there are five Range Header formats as initial entries for this registry: npt: Normal Play Time clock: UTC Clock format smpte: SMPTE Timestamps smpte-30-drop: SMPTE Timestamps smpte-25: SMPTE Timestamps IANA understands that the authors, with Magnus Westerlund (magnus.westerlund@ericsson.com) as primary, are to be used as the contact persons for initial entries created in this new registry. 1.11 A new registry called RTSP v2.0 Terminate-Reason Header Redirect Reasons. We also understand that future registrations are to be done using a designated expert. QUESTION --> What should be used as the text for the description of this registry? We also understand that there are three initial values in this new registry as follows: Session-Timeout Server-Admin Internal-Error IANA understands that the authors, with Magnus Westerlund (magnus.westerlund@ericsson.com) as primary, are to be used as the contact persons for initial entries created in this new registry. For each item in the RTSP v2.0 Terminate-Reason Header Redirect Reasons registry, we understand that three fields will be registered: - the Terminate-Reason Header Redirect Reason; - Contact Person; and, - a reference for the source of the registry value. 1.12 A new registry called RTSP v2.0 Terminate-Reason Header Parameters. We understand the description of RTSP v2.0 Terminate-Reason Header Parameters to be the first two sentences of the text in section 18.52 of the document. We also understand that future registrations are to be done through Specification Required only. We further understand that there are two initial values to be registered upon approval of the document as follows: time user-msg IANA understands that the authors, with Magnus Westerlund (magnus.westerlund@ericsson.com) as primary, are to be used as the contact persons for initial entries created in this new registry. For each item in the RTSP v2.0 Terminate-Reason Header Parameters registry, we understand that four fields will be registered: - the Terminate-Reason Header Parameter; - a contact name; and, - a reference for the source of the registry value. 1.13 A new registry called RTSP v2.0 RTP-Info header parameters. We understand the description of RTSP v2.0 RTP-Info header parameters to be extracted from section 18.45 of the document. We also understand that future registrations are to be done using Specification Required. We further understand that there are four initial values to be registered upon approval of the document as follows: url ssrc seq rtptime For each item in the RTSP v2.0 RTP-Info header parameters registry, we understand that three fields will be registered: - the RTP-Info header parameter value; - a contact name; and, - a reference for the source of the registry value. IANA understands that the authors, with Magnus Westerlund (magnus.westerlund@ericsson.com) as primary, are to be used as the contact persons for initial entries created in this new registry. 1.14 A new registry called RTSP v2.0 Seek-Style Policies. We understand the description of RTSP v2.0 Seek-Style Policies to be extracted from section 18.47 of the document. New registry values are managed through Specification Required. We further understand that there are four initial values to be registered upon approval of the document as follows: RAP CoRAP First-Prior Next IANA understands that the authors, with Magnus Westerlund (magnus.westerlund@ericsson.com) as primary, are to be used as the contact persons for initial entries created in this new registry. For each item in the RTSP v2.0 Seek-Style Policy registry, we understand that four fields will be registered: - the Seek-Style Policy value; - the short description of the value; - a contact name; and, - a reference for the source of the registry value. 1.15 A new registry called RTSP v2.0 Transport Protocol Identifier. The description of this registry will be taken as the first sentence in section 22.13.2 of the current draft. New registry values are added through Specification Required as defined in RFC 5226. For each item in the RTSP v2.0 Transport Protocol Identifier registry, we understand that three fields will be registered: - the protocol ID string; - a contact name; and, - a reference for the source of the registry value We also understand that there are 12 initial values to be registered upon approval of the document and that these are in section 22.13.1 of the document. IANA understands that the authors, with Magnus Westerlund (magnus.westerlund@ericsson.com) as primary, are to be used as the contact persons for initial entries created in this new registry. 1.16 A new registry called RTSP v2.0 Transport Modes. New registry values are added through Specification Required as defined in RFC 5226. For each item in the RTSP v2.0 Transport Modes registry, we understand that three fields will be registered: - the Transport Mode value; - a contact name; and, - a reference for the source of the registry value We also understand that there is one initial value to be registered upon approval of the document: PLAY [ RFC-to-be ] IANA understands that the authors, with Magnus Westerlund (magnus.westerlund@ericsson.com) as primary, are to be used as the contact persons for the initial entry created in this new registry. 1.17 A new registry called RTSP v2.0 Transport Parameters. IANA will use the first paragraph of section 22.13.3 as the description of this new registry. New registry values are added through Specification Required as defined in RFC 5226. For each item in the RTSP v2.0 Transport Parameters registry, we understand that three fields will be registered: - the Transport Parameter name; - a contact name; and, - a reference for the source of the registry value We also understand that there are thirteen initial values to be registered upon approval of the document: o unicast o multicast o interleaved o ttl o layers o ssrc o mode o dest_addr o src_addr o setup o connection o RTCP-mux o MIKEY IANA understands that the authors, with Magnus Westerlund (magnus.westerlund@ericsson.com) as primary, are to be used as the contact persons for the initial entry created in this new registry. Part 2: === We understand that, upon approval of this document, three new URI schemes would be registered in the Permanent URI scheme registry located at: http://www.iana.org/assignments/uri-schemes.html -- these three URIs are: 2.1 URI Scheme Name: rtsp URI Scheme Description: Real-time Streaming Protocol (RTSP) Reference: [ RFC-to-be ] 2.2 URI Scheme Name: rtsps URI Scheme Description: RTSP over TLS Reference: [ RFC-to-be ] 2.3 URI Scheme Name: rtspu URI Scheme Description: RTSP over unreliable datagram transport Reference: [ RFC-to-be ] Currently the Permanent URI Scheme registry is managed via Expert Review as defined in RFC5226. IANA Question --> We will initiate a request and send this to the designated expert for review. Part 3: === We understand that, upon approval of this document, three new SDP attributes would be registered in the Session Description Protocol (SDP) Parameters registry located at http://www.iana.org/assignments/sdp-parameters. These three entries would be placed in the "- att-field (both session and media level)" registry. The attributes are: 3.1 SDP name: range Reference: [ RFC-to-be ] 3.2 SDP name: control Reference: [ RFC-to-be ] 3.3 SDP name: mtag Reference: [ RFC-to-be ] Part 4: === We understand that, upon approval of this document, a single entry is to be added to the MIME Media Types registry located at: http://www.iana.org/assignments/media-types/index.html. This entry would be added to the "text" Media Types registry and would add a new Subtype of "parameters" The reference would be [ RFC-to-be ]. We understand that the creation of seventeen new registries and these three other major actions are all the IANA actions required upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. |
2013-10-17
|
38 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2013-10-17
|
38 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2013-10-17
|
38 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2013-10-17
|
38 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2013-10-11
|
38 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Real Time Streaming Protocol 2.0 … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Real Time Streaming Protocol 2.0 (RTSP)) to Proposed Standard The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'Real Time Streaming Protocol 2.0 (RTSP)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-10-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memorandum defines RTSP version 2.0 which obsoletes RTSP version 1.0 defined in RFC 2326. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/2028/ http://datatracker.ietf.org/ipr/1189/ |
2013-10-11
|
38 | Cindy Morgan | State changed to In Last Call (ends 2013-06-04) from Last Call Requested |
2013-10-11
|
38 | Cindy Morgan | Last call announcement was generated |
2013-10-10
|
38 | Gonzalo Camarillo | Last call was requested |
2013-10-10
|
38 | Gonzalo Camarillo | State changed to Last Call Requested from Waiting for AD Go-Ahead::External Party |
2013-10-10
|
38 | Gonzalo Camarillo | Last call announcement was generated |
2013-10-10
|
38 | Magnus Westerlund | New version available: draft-ietf-mmusic-rfc2326bis-38.txt |
2013-09-24
|
37 | Magnus Westerlund | New version available: draft-ietf-mmusic-rfc2326bis-37.txt |
2013-09-12
|
36 | Gonzalo Camarillo | State changed to Waiting for AD Go-Ahead::External Party from Waiting for AD Go-Ahead::AD Followup |
2013-09-11
|
36 | Magnus Westerlund | New version available: draft-ietf-mmusic-rfc2326bis-36.txt |
2013-09-02
|
35 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-09-02
|
35 | Magnus Westerlund | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2013-09-02
|
35 | Magnus Westerlund | New version available: draft-ietf-mmusic-rfc2326bis-35.txt |
2013-06-12
|
34 | Robert Sparks | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Robert Sparks. |
2013-06-10
|
34 | Gonzalo Camarillo | State changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2013-06-07
|
34 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Chris Lonvick. |
2013-06-04
|
34 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2013-06-03
|
34 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed version 34 of draft-ietf-mmusic-rfc2326bis. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any … IESG/Authors/WG Chairs: IANA has reviewed version 34 of draft-ietf-mmusic-rfc2326bis. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. We have questions about some of the IANA Actions requested in this document. General questions for the authors: We note that four registries for RTSP v1.0 are located at: http://www.iana.org/assignments/rtsp-parameters/rtsp-parameters.xhtml. We understand that these registries (Headers, Methods, Option Tags and Status Codes) are to remain in place for compatibility purposes. Is this understanding correct? We also understand that the preferred approach to the new RTSP 2.0 registries is to simply create a new file/repository for the v2.0 parameters. Is this understanding correct? Upon approval of this document, we understand that there are to be four major actions completed by the IANA: 1] the creation of 17 new registries (see below) in a registry location to be determined; 2] the registration of three new, permanent URI schemes (in http://www.iana.org/assignments/uri-schemes.html); and, 3] the registration of three new SDP attributes (in http://www.iana.org/assignments/sdp-parameters) 4] the registration of a Media Type for text/parameters (in MIME Media Types registry located at: http://www.iana.org/assignments/media-types/index.html. Part 1: === We understand that eighteen new registries are to be created. 1.1 A new registry called RTSP v2.0 feature-tags. The description of the contents of the registry is in section 22.1.1 of the draft document. We understand that future registrations are to be done on a first come, first served basis. We also understand that there are four initial values to be initially registered and that these are documented in section 22.1.3 of the draft. For each item in the RTSP v2.0 feature-tags registry, we understand that four fields will be registered: - the name of the feature tag (with rules for the creation of the name documented in section 22.1.2); - a description of the feature tag (a simple text string); - a indication of whether or not the feature tag applies to clients, servers or proxies (non-exclusively). and, - a reference for the source of the registry value (e.g. RFC, etc.) 1.2 A new registry called RTSP v2.0 Methods. The description of the meaning of RTSP Methods, the content of the registry, is in section 13 of the draft document. We understand that future registrations are to be done IETF Standards Action only. We also understand that there are ten initial values to be initially registered and that these are documented in section 22.2.3 of the draft. 1.3 A new registry called RTSP v2.0 Status Codes. We understand the description of RTSP v2.0 Status Codes to be "A status code is the three digit number used to convey information in RTSP response messages." We also understand that future registrations are to be done through IETF Review only. We also understand that there are 46 initial values to be initially registered and that these are to be extracted from the ABNF documentation for "Status-Code" in section 20.2.2 of the draft. For each item in the RTSP v2.0 Status Codes registry, we understand that three fields will be registered: - the three digit status code; - the meaning of the status code; and, - a reference for the source of the registry value. 1.4 A new registry called RTSP v2.0 Headers. We intend to use the description provided in section 22.4.1 of the document for this registry. We understand that future registrations are to be done using Expert Review. We also understand that there are 67 initial values to be initially registered and that these are to be extracted from Section 18 (56 values) and Section 22.4.3 (11 values) of the draft. We understand that the registry for RTSP 2.0 Headers will include only the header name and reference for each header. 1.5 A new registry called RTSP v2.0 Accept-Credentials policies. IANA understands the description of RTSP v2.0 Accept-Credentials policies to be defined in Section 22.5.1 of the document. We also understand that future registrations are to be done through IETF Standards Action only. We also understand that there are three initial values to be initially registered and that these are "Any" "Proxy" and "User" QUESTION --> Beside the name of the Accept-Credentials value and a reference to where it is defined, are there any other fields that should be in this registry based on the definitions in Section 19.3.1 of the document? 1.6 A new registry called RTSP v2.0 Accept-Credentials hash algorithms. We understand the description of RTSP v2.0 Accept-Credentials hash algorithms to be the first sentence of text in Section 22.5.2 of the document. We also understand that future registrations are to be done through IETF Standards Action only. We understand that there is a single registration in this registry as follows: Hash Alg. Id Reference ---------------------------- sha-256 [ RFC-to-be ] 1.7 A new registry called RTSP v2.0 Cache Directive Extensions. We understand the description of RTSP v2.0 Cache Directive Extensions to be the first paragraph of the text in section 22.6 of the document. We also understand that future registrations are to be done through IETF Standards Action only. We also understand that there are 10 initial values to be registered upon approval of the document as documented in the text of section 22.6. QUESTION --> For the ten initial values in this new registry what name should be used as the contact person? For each item in the RTSP v2.0 Cache Directive Extensions registry, We understand that three fields will be registered: - the name of the directive; - contact person; and, - a reference for the source of the registry value. 1.8 A new registry called RTSP v2.0 Media Properties. We understand the description of RTSP v2.0 Media Properties to be the text in section 22.7.1 of the document. We also understand that future registrations are to be done using a designated expert. We also understand that there are nine initial values to be registered upon approval of the document and that these are identified in section 16.28 of the document. For each item in the RTSP v2.0 Media Properties registry, we understand that three fields will be registered: - the name of the media property; - a contact name for the property; - a reference for the source of the registry value. QUESTION --> We understand that the property values identified in Section 16.28 are to be registered but not the property groups. Is this correct? Also, the IANA Considerations section requests that nine values be registered, but in Section 16.28 there appear to be ten values. Is one of the value in 16.28 not to be registered? 1.9 A new registry called RTSP v2.0 Notify Reason Values. We understand the description of RTSP v2.0 Status Codes to be the first three sentences of the text in section 22.8.1 of the document. We also understand that future registrations are to be done using a designated expert. We also understand that there are three initial values to be registered upon approval of the document and that these are to be copied from the documentation provided in Section 22.8.3. QUESTION --> For the three initial values in this new registry what name should be used as the contact person? For each item in the RTSP v2.0 Notify Reason Values registry, we understand that four fields will be registered: - the Notify Reason Value; - the description of the value; - a contact name; and, - a reference for the source of the registry value. 1.10 A new registry called RTSP v2.0 Range Header formats. We understands the description of RTSP v2.0 Range Header formats should be: "The Range header allows for different range formats." We also understand that future registrations are to be done through Specification Required only. We also understands that there are no initial values to be registered upon approval of the document. For each item in the RTSP v2.0 Range Header format registry, we understand that three fields will be registered: - the Range Header Format; - a contact name; and, - a reference for the source of the registry value. We also understand that there are five Range Header formats as initial entries for this registry: npt: Normal Play Time clock: UTC Clock format smpte: SMPTE Timestamps smpte-30-drop: SMPTE Timestamps smpte-25: SMPTE Timestamps QUESTION --> For the five initial values in this new registry what name should be used as the contact person? 1.11 A new registry called RTSP v2.0 Terminate-Reason Header Redirection Reasons. We understand the description of RTSP v2.0 Terminate-Reason Header Redirection Reasons to be the first two sentences of the text in section 16.50 of the document. We also understand that future registrations are to be done using a designated expert. We also understand that there are three initial values in this new registry as follows: Session-Timeout Server-Admin Internal-Error QUESTION --> For the five initial values in this new registry what name should be used as the contact person? For each item in the RTSP v2.0 Terminate-Reason Header Redirection Reasons registry, we understand that three fields will be registered: - the Terminate-Reason Header Redirection Reason; - Contact Person; and, - a reference for the source of the registry value. 1.12 A new registry called RTSP v2.0 Terminate-Reason Header Parameters. We understand the description of RTSP v2.0 Terminate-Reason Header Parameters to be the first two sentences of the text in section 18.50 of the document. We also understand that future registrations are to be done through Specification Required only. We further understand that there are two initial values to be registered upon approval of the document as follows: time user-msg QUESTION --> For the two initial values in this new registry what name should be used as the contact person? For each item in the RTSP v2.0 Terminate-Reason Header Parameters registry, we understand that four fields will be registered: - the Terminate-Reason Header Parameter; - a contact name; and, - a reference for the source of the registry value. 1.13 A new registry called RTSP v2.0 RTP-Info header parameters. We understand the description of RTSP v2.0 RTP-Info header parameters to be extracted from section 18.43 of the document. We also understand that future registrations are to be done using Specification Required. We further understands that there are four initial values to be registered upon approval of the document as follows: url ssrc seq rtptime For each item in the RTSP v2.0 RTP-Info header parameters registry, we understand that three fields will be registered: - the RTP-Info header parameter value; - a contact name; and, - a reference for the source of the registry value. 1.14 A new registry called RTSP v2.0 Seek-Style Policies. We understand the description of RTSP v2.0 Seek-Style Policies to be extracted from section 18.45 of the document. New registry values are managed through Specification Required. We further understand that there are four initial values to be registered upon approval of the document as follows: RAP CoRAP First-Prior Next QUESTION --> For the two initial values in this new registry what name should be used as the contact person? For each item in the RTSP v2.0 Seek-Style Policy registry, we understand that four fields will be registered: - the Seek-Style Policy value; - the short description of the value; - a contact name; and, - a reference for the source of the registry value. 1.15 A new registry called RTSP v2.0 Transport Protocol Specification. New registry values are added through Specification Required. We also understand that there are 12 initial values to be registered upon approval of the document and that these are in section 22.13.1 of the document. For each item in the RTSP v2.0 Transport Protocol Specification, we understand that three fields will be registered: - the protocol ID string; - a contact name; and, - a reference for the source of the registry value QUESTION --> Is there a description for the RTSP v2.0 Transport Protocol Specification available? QUESTION --> For the 12 initial values in this new registry what name should be used as the contact person? 1.16 A new registry called RTSP v2.0 Transport Modes. New registry values require IETF Standards Action. We also understand that there is a single initial value to be registered upon approval of the document as follows: PLAY [ RFC-to-be ] QUESTION --> Is there a description for the RTSP v2.0 Transport Modes available? QUESTION --> For the single initial registration in this new registry, what fields should be registered for the item (name, description, reference, etc.)? 1.17 A new registry called RTSP v2.0 Transport Parameters. New registry values are added to this registry through Specification Required. We also understand that there are thirteen initial values to be registered upon approval of the document as follows: unicast multicast interleaved ttl layers ssrc mode dest_addr src_addr setup connection RTCP-mux MIKEY QUESTION --> Is there a description for the RTSP v2.0 Transport Parameters available? QUESTION --> For the single initial registration in this new registry, what fields should be registered for the item (name, description, reference, etc.)? Part 2: === We understand that, upon approval of this document, three new URI schemes would be registered in the Permanent URI scheme registry located at: http://www.iana.org/assignments/uri-schemes.html -- these three URIs are: 2.1 URI Scheme Name: rtsp URI Scheme Description: Real-time Streaming Protocol (RTSP) Reference: [ RFC-to-be ] 2.2 URI Scheme Name: rtsps URI Scheme Description: RTSP over TLS Reference: [ RFC-to-be ] 2.3 URI Scheme Name: rtspu URI Scheme Description: RTSP over unreliable datagram transport Reference: [ RFC-to-be ] Currently the Permanent URI Scheme registry is managed via Expert Review as defined in RFC5226. IANA Question --> We will initiate a request and send this to the designated expert for review. Part 3: === We understand that, upon approval of this document, three new SDP attributes would be registered in the Session Description Protocol (SDP) Parameters registry located at http://www.iana.org/assignments/sdp-parameters. These three entries would be placed in the "- att-field (both session and media level)" registry. The attributes are: 3.1 SDP name: range Reference: [ RFC-to-be ] 3.2 SDP name: control Reference: [ RFC-to-be ] 3.3 SDP name: mtag Reference: [ RFC-to-be ] Part 4: === We understand that, upon approval of this document, a single entry is to be added to the MIME Media Types registry located at: http://www.iana.org/assignments/media-types/index.html. This entry would be added to the "text" Media Types registry and would add a new Subtype of "parameters" The reference would be [ RFC-to-be ]. We understand that the creation of seventeen new registries and these three other major actions are all the IANA actions required upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. |
2013-06-03
|
34 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2013-06-03
|
34 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2013-05-23
|
34 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2013-05-23
|
34 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2013-05-23
|
34 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Chris Lonvick |
2013-05-23
|
34 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Chris Lonvick |
2013-05-21
|
34 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2013-05-21
|
34 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Real Time Streaming Protocol 2.0 … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Real Time Streaming Protocol 2.0 (RTSP)) to Proposed Standard The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'Real Time Streaming Protocol 2.0 (RTSP)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-06-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memorandum defines RTSP version 2.0 which obsoletes RTSP version 1.0 defined in RFC 2326. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/2028/ http://datatracker.ietf.org/ipr/1189/ |
2013-05-21
|
34 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2013-05-21
|
34 | Gonzalo Camarillo | Last call was requested |
2013-05-21
|
34 | Gonzalo Camarillo | Ballot approval text was generated |
2013-05-21
|
34 | Gonzalo Camarillo | Ballot writeup was generated |
2013-05-21
|
34 | Gonzalo Camarillo | State changed to Last Call Requested from Publication Requested |
2013-05-21
|
34 | Gonzalo Camarillo | Last call announcement was generated |
2013-05-09
|
34 | Amy Vezza | /(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … /(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?// / Proposed Standard. Title page indicates "Standards Track". /(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:/ /Technical Summary:/ /Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction./ /Working Group Summary:/ /Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?/ /Document Quality:/ /Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?/ /Personnel:/ /Who is the Document Shepherd? Who is the Responsible Area Director?/ *Technical Summary* The document defines RTSP version 2.0 which obsoletes RTSP version 1.0 defined in RFC 2326. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550). *Working Group Summary* The document has been work in progress for an extended period of time dating back to 2002. Earlier versions saw decent WG participation however the later versions have primarily been driven by the document authors with limited overall discussion in the group, especially towards the end of the process. There are no known issues or major discussion points, and there has been no indication of lack of consensus in the WG. *Document Quality* The document has been reviewed in detail several times after WGLC and in preparation for the publication request and the authors have made several updates as a result of those. The document is considered to be of high quality at this point. There is one known implementation of the specification, and many of the extensions compared to RTSP 1.0 have been implemented separately as well. A Media type review was done for "text/parameters". The review thread can be found at: http://www.ietf.org/mail-archive/web/ietf-types/current/msg01656.html *Personnel *Document Shepherd: Flemming Andreasen Responsible AD: Gonzalo Camarillo /(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG./ I have performed detailed end-to-end review of the document twice. The first review resulted in a number of clarifying updates, and the second review revealed only minor issues, which have subsequently been addressed by the authors. /(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?/ Earlier versions of the document received some amount of WG attention, however the document has seen little recent active review and participation in the WG outside of the authors and the document shepherd. Detailed reviews have been performed by the authors and the document shepherd several times and the document is of high quality at this point. As noted, due to the relatively limited number of people having reviewed the latest version(s), the reviews have not been as broad as we would like. /(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place./ No such additional review is believed to be needed (nor has one been performed). /(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here./ There are no specific concerns or issued with the document at this point. /(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?/ Each author has confirmed full conformance. /(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures./ An IPR disclosure has been made on an earlier version of the document: http://datatracker.ietf.org/ipr/1189/ and an updated IPR disclosure reflecting subsequent changes in document section numbers has been made as well: http://datatracker.ietf.org/ipr/2028/ The IPR was originally disclosed at IETF 76: http://www.ietf.org/proceedings/76/minutes/mmusic.html and also posted to the MMUSIC list subsequently: http://www.ietf.org/mail-archive/web/mmusic/current/msg07815.html There has been no further comments or discussion around the IPR. Also note that an IPR disclosure was made (in 1997 ?) on an earlier version of RTSP: http://www.ietf.org/ietf-ftp/IPR/RTSP / (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?/ The document mostly represents the work of the authors and WG consensus is primarily based on that as well. There are no known concerns from anybody. /(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) / No threat of appeal or other indication of discontent/ / (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The document has been reviewed and had ID-nits run on it by two of the authors and the shepherd. The draft previously resulted in a lot of unused references in ID-nits, which appeared to be a shortcoming of ID-nits as it didn't parse the whole draft for reference, only up to the reference section. Thus all references that are only in the appendixes were marked as unused. The authors have manually checked this on the -33 version and found them to be false alarms. Henrik was going to address the issue and it appears to have been fixed as of the latest ID-nits check run. ID-nits has a couple of false FQDN warnings as well. The document has a normative reference to RFC 2818, which itself (somewhat suprisingly) is an Informative RFC and hence causes a downref issue. However, RFC 2818 is in the downref registry and hence should not be a problem: http://wiki.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. As mentioned above, the media type review (for "text/parameters") can be found at: http://www.ietf.org/mail-archive/web/ietf-types/current/msg01656.html The URI review during WG last call is here: http://www.ietf.org/mail-archive/web/uri-review/current/msg01567.html The URI review discussion resulted in the addition of explicit calling out the changes to the scheme which could potentially result in issues. /(13) Have all references within this document been identified as either normative or informative?/ Yes /(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?/ No such references. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There is a downward reference to RFC 2818 as noted above. RFC 2818 is already listed in the downref registry: http://wiki.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry /(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary./ This document obsoletes RFC 2326 (RTSP 1.0). This is shown on the title page and both listed and discussed in the abstract and introduction. /(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226)./ The document defines a number of new IANA registries and registers values in these as well as a couple of existing ones. All the IANA registries and registrations appear complete and correct. /(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries./ The document defines a number of new registries of which the following require RFC 5226 Expert Review (or Specification Required with implied Designated Expert review) as noted in the IANA considerations section of the document: - RTSP Headers (Section 22.4) - Media Properties (Section 22.7) - Notify-Reasons header (Section 22.8) - Range header formats (Section 22.9) - Terminate Reason: Redirect Reasons (Section 22.10.1) - Terminate Reason: Terminate-Reasone header Parameters (Section 22.10.2) - RTP-Info header parameters (Section 22.11) - Seek-Style Policies (Section 22.12) - Transport Header: Transport Protocol Specification (22.13.1) - Transport Header: Transport Parameters (22.13.3) The document authors are the expert reviewers with Magnus Westerlund as the primary Designated Expert reviewer. /(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc./ All ABNF has been validated by Bill Fenner's ABNF parser. |
2013-05-09
|
34 | Amy Vezza | Note added 'Document Shepherd: Flemming Andreasen (fandreas@cisco.com)' |
2013-05-09
|
34 | Amy Vezza | Intended Status changed to Proposed Standard |
2013-05-09
|
34 | Amy Vezza | IESG process started in state Publication Requested |
2013-05-08
|
34 | Flemming Andreasen | Changed document writeup |
2013-05-08
|
34 | Flemming Andreasen | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2013-04-04
|
34 | Magnus Westerlund | New version available: draft-ietf-mmusic-rfc2326bis-34.txt |
2013-03-22
|
33 | Magnus Westerlund | New version available: draft-ietf-mmusic-rfc2326bis-33.txt |
2013-03-22
|
32 | Magnus Westerlund | New version available: draft-ietf-mmusic-rfc2326bis-32.txt |
2013-03-20
|
(System) | Posted related IPR disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-mmusic-rfc2326bis-31 | |
2013-02-25
|
31 | Martin Stiemerling | New version available: draft-ietf-mmusic-rfc2326bis-31.txt |
2013-01-07
|
30 | Flemming Andreasen | Annotation tag Doc Shepherd Follow-up Underway set. |
2012-09-06
|
30 | Miguel García | Annotation tag Revised I-D Needed - Issue raised by WGLC cleared. |
2012-07-16
|
30 | Flemming Andreasen | Chair review: Minor updates needed before publication request |
2012-07-16
|
30 | Miguel García | Document is stable. Waiting for write-up |
2012-07-16
|
30 | Martin Stiemerling | New version available: draft-ietf-mmusic-rfc2326bis-30.txt |
2012-07-10
|
29 | Miguel García | IETF state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead |
2012-05-22
|
29 | Miguel García | IETF state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2012-05-22
|
29 | Miguel García | Annotation tag Revised I-D Needed - Issue raised by WGLC set. Annotation tag Doc Shepherd Follow-up Underway cleared. |
2012-04-18
|
29 | Miguel García | IETF state changed to In WG Last Call from WG Document |
2012-03-12
|
29 | Miguel García | Annotation tag Doc Shepherd Follow-up Underway set. |
2012-03-12
|
29 | Miguel García | Waiting for authors to submit a new version addressing issues raised during WGLC |
2012-03-12
|
29 | Miguel García | WGLC ended on May 21st. |
2012-03-12
|
29 | Miguel García | WGLC of version -29 started on 18-April-2012. Duration 4 weeks. Focus on changes since version -23 |
2012-03-12
|
29 | Miguel García | Version -29 implements changes due to WGLC of -27. Reviewers with comments need to give their green light. |
2012-03-12
|
29 | Magnus Westerlund | New version available: draft-ietf-mmusic-rfc2326bis-29.txt |
2011-10-28
|
28 | (System) | New version available: draft-ietf-mmusic-rfc2326bis-28.txt |
2011-09-10
|
28 | (System) | Document has expired |
2011-07-25
|
28 | Miguel García | WGLC passed, waiting for proto write-up |
2011-07-25
|
28 | Miguel García | IETF state changed to WG Consensus: Waiting for Write-Up from WG Document |
2011-03-09
|
27 | (System) | New version available: draft-ietf-mmusic-rfc2326bis-27.txt |
2010-11-17
|
26 | (System) | New version available: draft-ietf-mmusic-rfc2326bis-26.txt |
2010-10-25
|
25 | (System) | New version available: draft-ietf-mmusic-rfc2326bis-25.txt |
2010-07-02
|
24 | (System) | New version available: draft-ietf-mmusic-rfc2326bis-24.txt |
2010-03-08
|
23 | (System) | New version available: draft-ietf-mmusic-rfc2326bis-23.txt |
2009-09-09
|
(System) | Posted related IPR disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-mmusic-rfc2326bis-22 | |
2009-07-13
|
22 | (System) | New version available: draft-ietf-mmusic-rfc2326bis-22.txt |
2009-06-19
|
21 | (System) | New version available: draft-ietf-mmusic-rfc2326bis-21.txt |
2009-03-09
|
20 | (System) | New version available: draft-ietf-mmusic-rfc2326bis-20.txt |
2008-11-03
|
19 | (System) | New version available: draft-ietf-mmusic-rfc2326bis-19.txt |
2008-05-05
|
18 | (System) | New version available: draft-ietf-mmusic-rfc2326bis-18.txt |
2008-02-25
|
17 | (System) | New version available: draft-ietf-mmusic-rfc2326bis-17.txt |
2007-11-19
|
16 | (System) | New version available: draft-ietf-mmusic-rfc2326bis-16.txt |
2007-06-26
|
15 | (System) | New version available: draft-ietf-mmusic-rfc2326bis-15.txt |
2006-12-27
|
14 | (System) | New version available: draft-ietf-mmusic-rfc2326bis-14.txt |
2006-06-29
|
13 | (System) | New version available: draft-ietf-mmusic-rfc2326bis-13.txt |
2006-03-09
|
12 | (System) | New version available: draft-ietf-mmusic-rfc2326bis-12.txt |
2005-10-27
|
11 | (System) | New version available: draft-ietf-mmusic-rfc2326bis-11.txt |
2005-07-20
|
10 | (System) | New version available: draft-ietf-mmusic-rfc2326bis-10.txt |
2005-02-23
|
09 | (System) | New version available: draft-ietf-mmusic-rfc2326bis-09.txt |
2004-10-27
|
08 | (System) | New version available: draft-ietf-mmusic-rfc2326bis-08.txt |
2004-07-21
|
07 | (System) | New version available: draft-ietf-mmusic-rfc2326bis-07.txt |
2004-02-17
|
06 | (System) | New version available: draft-ietf-mmusic-rfc2326bis-06.txt |
2003-10-27
|
05 | (System) | New version available: draft-ietf-mmusic-rfc2326bis-05.txt |
2003-07-02
|
04 | (System) | New version available: draft-ietf-mmusic-rfc2326bis-04.txt |
2003-03-07
|
03 | (System) | New version available: draft-ietf-mmusic-rfc2326bis-03.txt |
2002-11-04
|
02 | (System) | New version available: draft-ietf-mmusic-rfc2326bis-02.txt |
2002-06-10
|
01 | (System) | New version available: draft-ietf-mmusic-rfc2326bis-01.txt |
2002-02-27
|
00 | (System) | New version available: draft-ietf-mmusic-rfc2326bis-00.txt |