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

[Dinoop <[e-mail]>]

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:[e-mail]>;index=1
   History-Info: <sip:bob@192.0.2.4?Reason=SIP%3Bcause%3D302>;index=1.1;rc=1
   History-Info: <sip:[e-mail]>;index=1.2;mp=1
   History-Info: <sip:office@192.0.2.5>;index=1.2.1;rc=1.2


My doubts are ,

1) As per the example , request is targeted to office@192.0.2.5 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, <[e-mail]> 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).
>
> 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:[e-mail]:
>
>
>
> 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 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:[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.0
>
> Step 2:
>
>             Request URI : sip:[e-mail]
>             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.0
>
> <sip:[e-mail]>;index=1.1.2.0.1
>
>
>
>
>
> However, I agree that wording 10.3 bullet 6 could have been more clear J
>
>
>
> Best regards,
>
> Marianne
>
>
>
> *De :* sipcore [mailto:[e-mail]] *De la part de* Ben
> Campbell
> *Envoyé :* mercredi 10 mai 2017 16:48
> *À :* SIPCORE
> *Cc :* [e-mail]
> *Objet :* [sipcore] Fwd: [Technical Errata Reported] RFC7044 (5014)
>
>
>
> 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
>
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>


-- 
Thanks & Regards
Dinoop p