Re: [sipcore] [Editorial Errata Reported] RFC3261 (3237)

[Robert Sparks <[e-mail]>]

(adding the sipcore list)

Kevin -

The important part of "new transaction" is the branch identifier. Are 
the issues you're having
really with transaction identification? (I could only see that being the 
case if you had 2543 elements
involved.) Or is the real pain with policy on what a response to a 
digest challenge has to look like?

What current IETF discussions are you pointing to below?

RjS

On 5/31/12 7:57 AM, RFC Errata System wrote:
> The following errata report has been submitted for RFC3261,
> "SIP: Session Initiation Protocol".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3261&eid=3237
>
> --------------------------------------
> Type: Editorial
> Reported by: Kevin P. Fleming<[e-mail]>
>
> Section: 8.1.3.5
>
> Original Text
> -------------
> In all of the above cases, the request is retried by creating a new request with the appropriate modifications.  This new request constitutes a new transaction and SHOULD have the same value of the Call-ID, To, and From of the previous request, but the CSeq should contain a new sequence number that is one higher than the previous.
>
> Corrected Text
> --------------
> In all of the above cases, the request is retried by creating a new request with the appropriate modifications.  This new request constitutes a new transaction and SHOULD have the same value of the Call-ID, To, and From of the previous request, but the CSeq SHOULD contain a new sequence number that is one higher than the previous.
>
> Notes
> -----
> We have had one implementor claim that they are not required to increment CSeq when retrying the request because the RFC says 'should' and not 'SHOULD'. Based on current IETF discussions, though, these should probably be changed to MUST anyway, but that's a much more substantive change throughout the whole RFC.
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC3261 (draft-ietf-sip-rfc2543bis-09)
> --------------------------------------
> Title               : SIP: Session Initiation Protocol
> Publication Date    : June 2002
> Author(s)           : J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler
> Category            : PROPOSED STANDARD
> Source              : Session Initiation Protocol
> Area                : Real-time Applications and Infrastructure
> Stream              : IETF
> Verifying Party     : IESG