[MEDIACTRL] Fw: AD review: draft-ietf-mediactrl-sip-control-framework-10

["Spencer Dawkins" <[e-mail]>]

Just to let the working group know ...

Robert has provided AD review comments for the Control Framework. In a 
private note this morning, Chris said he would be able to provide a revised 
ID next week. Eric and I do not consider the comments to be major, but want 
to keep the working group informed.

I will include time in our telechat agenda next Tuesday for any of these 
comments that you feel should be discussed within the working group.

See you on the interim meeting call!

Spencer


>I have a few questions to discuss and points that should be addressed  with 
>an updated version of the document
> before moving it to the next step.
>
> Let me know if I need to clarify anything below.
>
> Thanks,
>
> RjS
> -----------------
>
> -  Questions
>   -  Has the use of the m-line in section 4.1 had mmusic (or other
>         expert) review?
>   -  I expect discussion of the profiling of comedia on page 12.
>         How strongly does the group feel about keeping this text?
>   -  The protocol has no version field inside it, and there
>         doesn't appear to be a way to version it in the SDP that's
>         setting up its use. Am I missing something?
>   -  Did the group consider an absolute upperbound on the
>         Keep-Alive header field value? The syntax right now allows
>         the number to be without-bound large.
>   -  The spec doesn't seem to cover comparison of the header field
>         names and values it defines - is it case-sensitive or
>         case-insensitive?
> -  Comments
>   -  The To: and Subject: lines in the template at 12.1.1 should
>         be removed.
>   -  The K-ALIVE Method is not listed in section 12.2
>   -  The Keep-Alive header appears as K-Alive in at least one
>         example (msg 4 page 34)
>   -  Page 7:  "NOT NECESSARILY" would probably should not
>         be capitalized.
>   -  SIP Examples need scrubbing
>       -  Missing Max-Forwards across all requests
>       -  Non-3261 branch ids in Message 1 in the example
>       -  Some simple typos ("Cotent-Length")
>       -  mandatory received= parameter missing in responses
>       -  Incorrect reuse of o= line between an offer
>            and an answer in examples 1 and 2
>       -  missing To: tag in message 14
>   -  This sentence fails to parse:
>       -  This attribute MUST be globally unique over space and
>             time (using an appropriate algorithm) and will not clash
>             with other offer/answer exchanges that will take place.
>   -  Why does the 2nd paragraph on page 13 leave out 3xx class
>         responses?
>   -  Why does the list in the first paragraph on Page 14 not
>         mention UPDATE?
>   -  Page 18: "and all associated state and resources MUST be
>         terminated" is ambiguous. I think the intent is things scoped
>         to the transaction, but it could be read as things associated
>         with the session.
>   -  The way the first paragraph of 6.3.2.1 is worded, it is
>         forcing it to be likely that the 202 will arrive too late at
>         the client side of the transaction. We either need different
>         timers at each end, or we need to send that 202 enough
>         earlier that it can get back before the client gives up. This
>         isn't as bad as SIP non-INVITE, but it has similar properties
>         to that across one SIP hop.
>   -  The first paragraph of page 20 has a structural issue. It
>         reduces to "A Control Server MUST contain a Timeout message
>         header" which was not the intent.
>   -  It would be nice to add a statement that for consistency of
>         syntax, the _last_ REPORT message (Status: terminate) in an
>         extended transaction is required to contain a Timeout header,
>         but it has no meaning in that message and MUST be ignored.
>   -  Small nit - in 6.3.3 the document says"apply explicitly" when
>         I think the intent is "apply only"
>   -  Figure 3 has "Dialog-ID"  instead of  "Dialog-id".
>   -   "~" is allowed in SIP to and from tags (token in 3261). But
>         this document relies on using ~ as a separator in the
>         connectionid attribute it defines in 16.1 - doesn't this
>         make parsing the connectionid ambiguous? (example where
>         are the tags in 124~fwe~92235?)
>
>