Subject: Re: [sipcore] RSeq and forking - Text for new errata - New version

From: Christer Holmberg <[email-masked]>
Date: Thu, 17 Dec 2015 13:56:47 +0000

Hi,

New version, based on Dale's last comment:

Hi,

Based on the e-mail discussion, the new errata would contain the following change suggestions:

------------

Section 3:

OLD:
   The provisional response to be sent reliably is constructed by the
   UAS core according to the procedures of Section 8.2.6 of RFC 3261.
   In addition, it MUST contain a Require header field containing the
   option tag 100rel, and MUST include an RSeq header field.  The value
   of the header field for the first reliable provisional response in a
   transaction MUST be between 1 and 2**31 - 1.  It is RECOMMENDED that
   it be chosen uniformly in this range.  The RSeq numbering space is
   within a single transaction.  This means that provisional responses
   for different requests MAY use the same values for the RSeq number.

NEW:
   The provisional response to be sent reliably is constructed by the
   UAS core according to the procedures of Section 8.2.6 of RFC 3261.
   In addition, it MUST contain a Require header field containing the
   option tag 100rel, and MUST include an RSeq header field.  The
   value of the header field for the first reliable provisional
   response in a transaction MUST be between 1 and 2**31 - 1.  It is
   RECOMMENDED that it be chosen uniformly in this range. 
   The RSeq numbering space is within a single transaction.
   This means that RSeq value of a provisional response within
   a fork of a request is independent of the RSeq value of a
   provisional response within any other fork of that request, or for
   the responses for any other request.  It thus may be higher, lower,
   or the same as any other such RSeq value

Section 4:

OLD:
   If a provisional response is received for an initial request, and
   that response contains a Require header field containing the option
   tag 100rel, the response is to be sent reliably.  If the response is
   a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be
   ignored, and the procedures below MUST NOT be used.

NEW:
   If a provisional response is received for an initial request, and
   that response contains a Require header field containing the option
   tag 100rel, the response was sent by the UAS reliably.  If the
   response is a 100 (Trying) (as opposed to 101 to 199), this option
   tag MUST be ignored, and the procedures below MUST NOT be used.

OLD:
   Assuming the response is to be transmitted reliably, the UAC MUST
   create a new request with method PRACK.  This request is sent within
   the dialog associated with the provisional response (indeed, the
   provisional response may have created the dialog).  PRACK requests
   MAY contain bodies, which are interpreted according to their type and
   disposition.

NEW:
   Assuming the response was transmitted reliably by the UAS, the UAC MUST
   create a new request with method PRACK.  This request is sent within
   the dialog associated with the provisional response (indeed, the
   provisional response may have created the dialog).  PRACK requests
   MAY contain bodies, which are interpreted according to their type and
   disposition.

OLD:
   Once a reliable provisional response is received, retransmissions of
   that response MUST be discarded.  A response is a retransmission when
   its dialog ID, CSeq, and RSeq match the original response.  The UAC
   MUST maintain a sequence number that indicates the most recently
   received in-order reliable provisional response for the initial
   request.  This sequence number MUST be maintained until a final
   response is received for the initial request.  Its value MUST be
   initialized to the RSeq header field in the first reliable
   provisional response received for the initial request.

NEW:

   Once a reliable provisional response is received, retransmissions of
   that response MUST be discarded.  A response is a retransmission when
   its dialog ID, CSeq, and RSeq match the original response.  The UAC
   MUST maintain, independently for each dialog ID, a sequence
   number that indicates the most recently received in-order reliable
   provisional response for the initial request.  This sequence number
   MUST be maintained until a final response is received for the initial
   request. Its value MUST, for each dialog (or early dialog), be initialized
   to the RSeq header field in the first reliable provisional response, 
   associated with the dialog, received for the initial request. 

OLD:
   Handling of subsequent reliable provisional responses for the same
   initial request follows the same rules as above, with the following
   difference: reliable provisional responses are guaranteed to be in
   order.  As a result, if the UAC receives another reliable provisional
   response to the same request, and its RSeq value is not one higher
   than the value of the sequence number, that response MUST NOT be
   acknowledged with a PRACK, and MUST NOT be processed further by the
   UAC.  An implementation MAY discard the response, or MAY cache the
   response in the hopes of receiving the missing responses.

NEW:
   Subsequent reliable provisional responses for the same initial
   request are guaranteed  to have been generated by the UAS in the
   order of their RSeq values and must be acknowledged in that order.
   As a result, if the UAC receives another
   reliable provisional response to the same request, and its RSeq
   value is one higher than the value of the previously received RSeq
   value in the dialog (or early dialog), then the new RSeq value is saved and the
   response is handled as described above. If the RSeq value is not one
   higher than the value of the sequence number, that response MUST NOT
   be acknowledged with a PRACK, and MUST NOT be processed further by
   the UAC.  An implementation MAY discard the response, or MAY cache
   the response to be processed (and acknowledged) after receiving
   the missing responses.

-------------

Can I go ahead and create a new errata? :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Dec 2015 09:58:19 -0500

This all seems good to me.

	Thanks,
	Paul

---

From: "A. Jean Mahoney" <[email-masked]>
Date: Thu, 17 Dec 2015 09:56:46 -0600

Hi Christer,

Just two small nits highlighted below, otherwise I (as an individual) am 
ok with it -

> Based on the e-mail discussion, the new errata would contain the following change suggestions:

                     ^^^^ Insert "the" in front of "RSeq value"

>     or the same as any other such RSeq value

Last sentence above is missing a period.

Thanks,

Jean

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 17 Dec 2015 19:26:37 +0000

Hi Jean,

I'll include your fixes when creating the errata :)

Thanks!

Regards,

Christer

-----Original Message-----
From: A. Jean Mahoney [mailto:[email-masked]] 
Sent: 17 December 2015 17:57
To: Christer Holmberg <[email-masked]>; Paul Kyzivat <[email-masked]>; Gonzalo Salgueiro (gsalguei) <[email-masked]>
Cc: [email-masked]; Dale R. Worley <[email-masked]>; [email-masked]
Subject: Re: [sipcore] RSeq and forking - Text for new errata - New version

Hi Christer,

Just two small nits highlighted below, otherwise I (as an individual) am ok with it -

Thanks,

Jean

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 17 Dec 2015 17:04:01 -0500

Looks good to me.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 18 Dec 2015 08:47:58 +0000

Do I need to create separate erratas for each updated section?

Regards,

Christer

-----Original Message-----
From: Dale R. Worley [mailto:[email-masked]] 
Sent: 18. joulukuuta 2015 0:04
To: Christer Holmberg
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sipcore] RSeq and forking - Text for new errata - New version

Looks good to me.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 18 Dec 2015 09:38:26 -0500

> Do I need to create separate erratas for each updated section?

I don't think it's necessary, but other people probably have a better
understanding of how the errata process should work.

Dale

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 23 Dec 2015 15:47:12 -0600

> understanding of how the errata process should work.

If the changes are of the same type, should be be accepted or rejected 
as a group, and need to be understood as a group by the reader, it makes 
sense to do them in a single erratum.

A couple of questions along those lines: Do the "is to be sent"/"was 
sent" changes need to be considered along wth the rest of the changes? 
Do people consider those to be technical or editorial?

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 28 Dec 2015 13:34:40 +0000

Hi,

> If the changes are of the same type, should be be accepted or rejected as a group, and need to be understood as a group by the reader, it makes sense to do them in a single erratum.

Ok.

> A couple of questions along those lines: Do the "is to be sent"/"was sent" changes need to be considered along wth the rest of the changes? 

The change is done in one place only, and my understanding is that it is technical, as it describes a case where the response has been sent.

Regards,

Christer