Real-Time Streaming Protocol Version 2.0
draft-ietf-mmusic-rfc2326bis-40

[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

[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?

[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."

[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.

[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.

[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.

[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?

[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    = 

[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.

[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?

[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?

[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.)

[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.

[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.

[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?

[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".

[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?

[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?

[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.

[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.

[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.

[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?

[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.

[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?

[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.

[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?

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.

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/

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.

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/

/(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.