Re: [sipcore] #34: Semantics of History-Info values need to be documented explicitly

[Mary Barnes <[e-mail]>]

Dale,

This text seems redundant for the most part and past criticisms of
4244 were that there was too much redundant text.  This sounds
something similar to Hadriel's issue 1 about there not really being an
overview of operations - I am adding text to address that concern.

However, if you an point me to another RFC that follows the model you
are suggesting, then I can try to craft the appropriate text. ISTM
though that to be completely accurate, you have to rewrite all the
normative text in a different manner.

Thanks,
Mary.

On Fri, Sep 3, 2010 at 1:16 PM, Worley, Dale R (Dale) <[e-mail]> wrote:
> ________________________________________
> From: [e-mail] [[e-mail]] On Behalf Of Mary Barnes [[e-mail]]
>
> You'll have to send text on this one - it's not clear to me at all
> what you are talking about.
> _______________________________________________
>
> Here's a start:
>
> The History-Info header field(s) of a request contain a sequence of
> hi-entrys.
>
> Each hi-entry contains an 'index' parameter.  The values of the 'index'
> parameters organize the hi-entrys into a tree, with each hi-entry
> being a child of the hi-entry whose index is the same except for the
> final ("." 1*DIGIT) being removed.  The hi-entrys whose 'index' value
> is just 1*DIGIT are the children of an implicit root hi-entry.
>
> The child hi-entrys of an hi-entry have as their final 1*DIGIT
> distinct consecutive integers starting with 1. [Question:  Are the
> values required to be consecutive?]
>
> The hi-entrys appear in preorder, the lexicographic ordering of their
> 'index' values.  [Question: Are the hi-entrys constrained to appear in
> this order?]
>
> The hi-entrys correspond to requests that are derived from one initial
> out-of-dialog request, that is requests that share their Call-Id and
> CSeq values, and have no to-tag.  An hi-entry's parent hi-entry
> corresponds to its immediate predecessor request, that is, the one
> which contains all of its Vias except the topmost.  An hi-entry with
> only one 1*DIGIT in its 'index' value corresponds to a request with
> one Via, that is, one sent by the UAC.
>
> The last hi-entry corresponds to the request containing this
> History-Info header field.  [Question:  Is this true?  Or is the
> hi-entry that corresponds to the containing request marked in some
> other way?]
>
> An hi-entry's name-addr contains as its URI either the request-URI of
> the corresponding request, or "sip:[e-mail]" (to
> indicate that the request-URI is being hidden).  [Note that the actual
> anonymous value is not specified in 4244bis.]
>
> If an hi-entry contains a *** or *** parameter, then the request-URI
> of the corresponding request was derived by the proxy from the
> request-URI of its parent by the corresponding process.
>
> If an hi-entry contains a *** or *** parameter, then the request-URI
> of the corresponding request was obtained from a 3xx response to the
> request corresponding to the hi-entry whose 'index' value is the value
> of the parameter.  The parameter was obtained from the corresponding
> header parameter of the Contact header field of the 3xx response, and
> indicates that the generator of the 3xx response indicated that the
> Contact URI was derived by the corresponding process.
>
> Dale
>