Subject: [sipcore] [Technical Errata Reported] RFC7044 (5014)

From: RFC Errata System <[email-masked]>
Date: Wed, 10 May 2017 00:44:49 -0700 (PDT)

The following errata report has been submitted for RFC7044,
"An Extension to the Session Initiation Protocol (SIP) for Request History Information".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5014

--------------------------------------
Type: Technical
Reported by: Dinoop Paloli <[email-masked]>

Section: 9.1 and 10.3

Original Text
-------------

Corrected Text
--------------

Notes
-----
Ambiguity exists regarding the handling of missing history info entry

Section 9.1 says,
	If the Request-URI of the incoming request does not match the hi
   -targeted-to-uri in the last hi-entry (i.e., the previous SIP entity
   that sent the request did not include a History-Info header field),
   the SIP entity MUST add an hi-entry to the end of the cache on
   behalf of the previous SIP entity
  
	According to that, for example, if request is received with,
	Request URI : sip:[email-masked]
	and History info :  <sip:[email-masked]>;index=1
						<sip:alice@example>;index=1.1
						<sip:jain@example>;index=1.1.1
						<sip:dave@example>;index=1.1.2

	Then processing entity has to add an history info in to cache on behalf of previous entity as,
	History info : <sip:[email-masked]>;index=1
               <sip:alice@example>;index=1.1
			   <sip:jain@example>;index=1.1.1
			   <sip:dave@example>;index=1.1.2
			   <sip:[email-masked]>;index=1.1.2.1
			   
But in section 10.3 basic rules 6 states,
		If the request clearly has a gap in the hi-entry
       (i.e., the last hi-entry and Request-URI differ), the entity
       adding an hi-entry MUST add a single index with a value of "0"
       (i.e., the non negative integer zero) prior to adding the
       appropriate index for the action to be taken. For example, if
       the index of the last hi-entry in the request received was 1.1.2
       and there was a missing hi-entry and the request was being
       forwarded to the next hop, the resulting index will be 1.1.2.0.1.
	   
	   But as per 9.1 stated above, once an entity receive a request with missing history info
		it has to add an entry to cache on behalf of previous one.
		So referring the previous example the added index would be 1.1.2.1
		And by applying the rule in 10.3, the index for the new request created by this entity would be 1.1.2.1.0.1 not 1.1.2.0.1

Instructions:
-------------
This erratum 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  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7044 (draft-ietf-sipcore-rfc4244bis-12)
--------------------------------------
Title               : An Extension to the Session Initiation Protocol (SIP) for Request History Information
Publication Date    : February 2014
Author(s)           : M. Barnes, F. Audet, S. Schubert, J. van Elburg, C. Holmberg
Category            : PROPOSED STANDARD
Source              : Session Initiation Protocol Core RAI
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG

---

From: Ben Campbell <[email-masked]>
Date: Wed, 10 May 2017 09:47:34 -0500

Do people have thoughts on this?

Thanks!

ben.

> Begin forwarded message:
> 
> From: RFC Errata System <[email-masked]>
> Subject: [Technical Errata Reported] RFC7044 (5014)
> Date: May 10, 2017 at 2:44:49 AM CDT
> To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
> Cc: [email-masked], [email-masked], [email-masked]
>

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 10 May 2017 12:34:08 -0400

> Do people have thoughts on this?

I haven't dug into this erratum, but there are a number of places in
7044 where the language isn't as exact as we'd like.

Dale

---

From: Ben Campbell <[email-masked]>
Date: Mon, 15 May 2017 09:31:00 -0500

Thanks, but does anyone have thoughts on this particular erratum? :-)

Ben.

> On May 10, 2017, at 11:34 AM, Dale R. Worley <[email-masked]> wrote:
>

---

From: <[email-masked]>
Date: Mon, 15 May 2017 14:39:01 +0000

Hi,

I'm going to have a look and give a feedback today.

BR,
Marianne

> -----Message d'origine-----
> De : sipcore [mailto:[email-masked]] De la part de Ben Campbell
> Envoyé : lundi 15 mai 2017 16:31
> À : Dale R. Worley
> Cc : [email-masked]; [email-masked]
> Objet : Re: [sipcore] Fwd: [Technical Errata Reported] RFC7044 (5014)
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Mary Barnes <[email-masked]>
Date: Mon, 15 May 2017 10:03:19 -0500

I'm looking into it.  At first glance it might have been an oversight, but
we were pretty careful and thorough with this revision, so I'm going to dig
back through some emails, etc. before I have a clear position.

Regards,
Mary.

---

From: <[email-masked]>
Date: Mon, 15 May 2017 21:41:04 +0000

Hi,

IMO, I don't think the errata is justified for the following reasons:
In 9.1 it is stated that if there is a missing entry (identified because the R-URI doesn't match the last hi-entry received), an extra hi-entry with the received R-URI content and including an index set to '0' (as described in 10.3 bullet ) must be added (as described in 10.3) before proceeding section 9.2 (i.e. before adding the normal entry with the "next" R-URI value as a last entry).
So 9.1 refers to 10.3 for the index setting:
If the Request-URI of the incoming request does not match the hi
-targeted-to-uri in the last hi-entry (i.e., the previous SIP entity
that sent the request did not include a History-Info header field),
the SIP entity MUST add an hi-entry to the end of the cache, on
behalf of the previous SIP entity. This is done as follows, before
proceeding to Section 9.2.
[...]
-The SIP entity MUST set the hi-index parameter as described in
Section 10.3.

In the given example, let's assume that the processing entity wants to forward the request to sip:[email-masked]:

if request is received with,

Then processing entity identifies that peter is not in the last hi-entry received. So before modifying the R-URI and adding a new hi-entry with marianne's address, it will reflect the gap by adding a hi-entry for peter's address incrementing the index with ".0":
Step 1:
            History info : <sip:[email-masked]>;index=1
                                   <sip:alice@example>;index=1.1
                                      <sip:jain@example>;index=1.1.1
                                     <sip:dave@example>;index=1.1.2
                                     <sip:[email-masked]>;index=1.1.2.0
Step 2:
            Request URI : sip:[email-masked]
            History info : <sip:[email-masked]>;index=1
                                   <sip:alice@example>;index=1.1
                                      <sip:jain@example>;index=1.1.1
                                     <sip:dave@example>;index=1.1.2
                                     <sip:[email-masked]>;index=1.1.2.0
<sip:[email-masked]>;index=1.1.2.0.1

However, I agree that wording 10.3 bullet 6 could have been more clear :)

Best regards,
Marianne

De : sipcore [mailto:[email-masked]] De la part de Ben Campbell
Envoyé : mercredi 10 mai 2017 16:48
À : SIPCORE
Cc : [email-masked]
Objet : [sipcore] Fwd: [Technical Errata Reported] RFC7044 (5014)

Thanks!

ben.

Begin forwarded message:

From: RFC Errata System <[email-masked]<mailto:[email-masked]>>
Subject: [Technical Errata Reported] RFC7044 (5014)
Date: May 10, 2017 at 2:44:49 AM CDT
To: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

--------------------------------------
Type: Technical
Reported by: Dinoop Paloli <[email-masked]<mailto:[email-masked]>>

Section: 9.1 and 10.3

Original Text
-------------

Corrected Text
--------------

Notes
-----

Section 9.1 says,

Instructions:
-------------

---

From: Dinoop <[email-masked]>
Date: Tue, 16 May 2017 14:32:58 +0530

Hi Marianne,

Thanks for the crystal clear explanation. Now I understood the matter.

Also as you said , The  section 10.3 - part 6 , can be interpreted wrongly
as "the gap has to be filled with R-URI and index 1.1.2.0.1". Because it is
not specifically mentioning that the index of hi-entry uri should be
1.1.2.0.

I don't know  whether discussing about the RFC  7131 (History-info call
flows)  is appropriate over here, but since it is very  much related to
above query , I am including those.

In section   3.1. Sequentially Forking , the history info header in message
contains 4 history-info headers such as,

   History-Info: <sip:[email-masked]>;index=1
   History-Info: <sip:[email-masked]?Reason=SIP%3Bcause%3D302>;index=1.1;rc=1
   History-Info: <sip:[email-masked]>;index=1.2;mp=1
   History-Info: <sip:[email-masked]>;index=1.2.1;rc=1.2

My doubts are ,

1) As per the example , request is targeted to [email-masked] directly,

   in this case why 3rd history info entry is added?. As per the RFC,

   History info is added based on the request URI of new request. If
it is as per standards,

   Can you please mention the RFC, where it is mentioned.

2) The last history-entry is having index 1.2.1, but as the "dot"
represents the new hop, it should be 1.3 right?

why additional "dot" has been added? Can you please point the RFC
describes this behavior?

On Tue, May 16, 2017 at 3:11 AM, <[email-masked]> wrote:

> Hi,
>
>
>
> IMO, I don’t think the errata is justified for the following reasons:
>
> In 9.1 it is stated that if there is a missing entry (identified because
> the R-URI doesn’t match the last hi-entry received), an extra hi-entry with
> the received R-URI content and including an index set to ‘0’ (as described
> in 10.3 bullet ) must be added (as described in 10.3) before proceeding
> section 9.2 (i.e. before adding the normal entry with the “next” R-URI
> value as a last entry).
>
> […]
> In the given example, let’s assume that the processing entity wants to
> forward the request to sip:[email-masked]:
>
>
>
> Then processing entity identifies that peter is not in the last hi-entry
> received. So before modifying the R-URI and adding a new hi-entry with
> marianne’s address, it will reflect the gap by adding a hi-entry for
> peter’s address incrementing the index with ".0":
>
> Step 1:
> However, I agree that wording 10.3 bullet 6 could have been more clear J
>
>
>
> Best regards,
>
> Marianne
>
>
>
> *De :* sipcore [mailto:[email-masked]] *De la part de* Ben
> Campbell
> *Envoyé :* mercredi 10 mai 2017 16:48
> *À :* SIPCORE
> *Cc :* [email-masked]
> *Objet :* [sipcore] Fwd: [Technical Errata Reported] RFC7044 (5014)
>
>
>
> *From: *RFC Errata System <[email-masked]>
>
> *Subject: [Technical Errata Reported] RFC7044 (5014)*
>
> *Date: *May 10, 2017 at 2:44:49 AM CDT
>
> *To: [email-masked], [email-masked],
> [email-masked], [email-masked], [email-masked],
> [email-masked], [email-masked], [email-masked],
> [email-masked], [email-masked]
>
> *Cc: [email-masked], [email-masked], [email-masked]
>
>
>
>                       And by applying the rule in 10.3, the index for the
> new request created by this entity would be 1.1.2.1.0.1 not 1.1.2.0.1
>
> Instructions:
> -------------

-- 
Thanks & Regards
Dinoop p