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

[Ben Campbell <[e-mail]>]

Do people have thoughts on this?

Thanks!

ben.

> Begin forwarded message:
> 
> From: RFC Errata System <[e-mail]>
> Subject: [Technical Errata Reported] RFC7044 (5014)
> Date: May 10, 2017 at 2:44:49 AM CDT
> To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
> Cc: [e-mail], [e-mail], [e-mail]
> 
> 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 <[e-mail]>
> 
> 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:[e-mail]
> 	and History info :  <sip:[e-mail]>;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:[e-mail]>;index=1
>               <sip:alice@example>;index=1.1
> 			   <sip:jain@example>;index=1.1.1
> 			   <sip:dave@example>;index=1.1.2
> 			   <sip:[e-mail]>;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