Subject: [MMUSIC] Consensus call on Auth48 changes to RTSP 2.0 (draft-ietf-mmusic-rfc2326bis-40)

From: Flemming Andreasen <[email-masked]>
Date: Wed, 12 Oct 2016 18:39:06 -0400

Greetings

This email is to initiate a consensus call on the changes the authors 
propose in Auth48 for RTSP 2.0 
(https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/). The 
consensus call is only on the proposed changes. The deadline for 
feedback is October 26, 2016. If you have objections to the changes 
please raise them on the MMUSIC mailing list.

Below is a list (courtesy of Magnus) of the significant changes since 
the last draft version that was approved by IESG. There are many more 
editorial changes. For that purpose you are provided with two diffs.

The first diff is containing all the changes significant and editorial 
that the authors have proposed. This base version for this diff is the 
version of RFC7826-to-be that the RFC-editor provided at the start of 
the AUTH48:

https://www.rfc-editor.org/authors/rfc7826-lastdiff.html

The second diff is to enable you two see all changes in RFC7826-to-be 
compared to the last draft version. This is thus both the RFC-editor's 
changes and the authors' changes combined compared to -40 draft version. 
This version is even more cluttered, but can provide the full context of 
the changes when RFC-editor editing and the authors changes interact.

https://www.rfc-editor.org/authors/rfc7826-diff.html

The following are seen as significant changes, i.e. changes in RFC 2119 
terms, changes of normative references, changes potentially affecting 
behavior, are the following:

- Section 3.2: Definition of Live (significantly reformulated even if 
intention is the same)

- General: Updated the previous RFC 2616 HTTP/1.1 references to 
RFC7230-7235.

- Section 8: New MAY: "Responses using the response code class 1xx is 
the only class for which there MAY be sent one or more responses prior 
to the final response message."

- Section 10.5: New MUST: "RTSP servers MUST support the SET_PARAMETER 
method, so that clients can always use this mechanism."

- Section 13.5.1: New MAY: The sender of a
    PLAY_NOTIFY MAY issue an updated PLAY_NOTIFY, in the case of a
    PLAY_NOTIFY sent with wrong information.

- Section 13.9: New MUST: If
    the Session header is present in a request, the value of a parameter
    MUST be retrieved in the specified session context.

- Section 13.9: New MUST: The responder to a SET_PARAMETER request MUST 
use the media type of the request for the response.  For additional 
considerations regarding message body negotiation, see Section 9.3.

- Section 17.3.3: New MUST: The Location header MUST be included in the
    response.

- Section 17.3.6: New MUST: The requested resource MUST be accessed 
through the proxy given by the Location header that MUST be included.

- Section 17.4.2, 17.4.8, 18.7, 18.8, 18.34, 18.35, 18.36, 18.58, 19.1, 
19.1.1: Changed the normative definition of the HTTP authentication 
mechanism from RFC 2617 to RFC 7235, RFC 7615, RFC 7616, RFC 7617. 
Resulting in reformulation in a number of places.

- Section 18.42: A new recommendation about CSeq numbers to avoid 
ambigouties in the Request-Status header.

- Section 18.44: New MAY: A response using 413 (Request
    Message Body Too Large) when the restriction is temporary MAY also
    include the Retry-After header.

- Section 18.57: Significant clarification on how Via in RTSP works, 
which is like HTTP, not like the via header in SIP.

- Section 19.1: New MUST NOT: The WWW-Authenticate
    (Section 18.58), Authorization (Section 18.8), and Authentication-
    Info (Section 18.7) headers are end-to-end and MUST NOT be modified
    by proxies.

- Section 20.2.3: Referencing ABNF for content of Authorization related 
headers information from RFC 7615 and 7235. See auth-param-list, 
challenge-list and credentials constructs.

Regards (and special thanks to Magnus)

     -- Flemming (as MMUSIC co-chair)