Subject: Re: [sipcore] New diff for rfc4244bis

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 24 Apr 2012 15:44:41 -0400

Trying to get all the issues cleaned up...

Comments relative to draft-ietf-sipcore-rfc4244bis-08-04-ss.txt:

Of course, "Comments on draft-ietf-sipcore-rfc4244bis-07 -
substantival questions" remains to be discussed.

In 10.2 is the sentence "That allows Tel-URIs to be handled correctly,
i.e., not receiving a Reason header."  But I wrote that sentence as a
comment on the text I was providing, I don't think it helps the draft
itself!  It probably got copied into the draft by mistake.

> > NOTE:  In my comments on sections 1-5, I was unaware of the (somewhat
> > new) use of "0" to indicate a gap, so I incorrectly referred to
> > "positive integer" instead of "nonnegative integer".
> >
> > NOTE:  Should we add somewhere prominent toward the beginning:
> >
> >   The hi-entries in the History-Info header field are always given in
> >   the preorder of their logical tree structure, which is the
> >   lexicographic ordering of their hi-indexes.
> >
> > This makes it clear that the ordering is always the same and avoids
> > specifying the ordering in multiple places (as if it was somehow a
> > special feature of certain steps of processing).
> 
>  I thought the description of hi-index was sufficient but if you don't
> think so, we can add this. Where do you recommend we add this?
> In the Introduction??

I might be having some sort of conceptual confusion here.  My
understanding is that the hi-entries are intrinsically organized into
a tree by their hi-indexes, and as a consequence, whenever they are
written as one or more History-Info headers, the hi-entries are in
tree preorder by their hi-indexes.

So the first question is whether everybody agrees with my
understanding.

Within that understanding, there are various places in processing
where any implementation will have to go to the effort of correctly
ordering the hi-entries.  The proper understanding of that effort is
not "sort the hi-entries because that is what you do at this point"
but rather "sort the hi-entries because that is what you do at any
point where you express them as History-Info".  So there should be a
statement of this global principle (contstraint, invariant)
somewhere.  It might be that it should be expressed in section 10.3,
which seems to be the location for all the general or global
principles for hi-entries.

> >   6.  Missing entity: If the request clearly has a gap in the hi-entry
> >       (e.g. by evaluating via header to the existing request history to
> >       see if it traversed a domain which doesn't exist in History-Info
> >       header field.), the entity adding an hi-entry MUST add an index a
> >       digit of "0" to the current index prior to adding appropriate
> >       index for the action to be taken.  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.
> >
> > This rule doesn't really belong here.  Properly, it describes an
> > additional condition that triggers the adding of an hi-entry described
> > in section 9.1.
> 
>  Section 9.1 already describes the condition as to when it
> adds hi-entry.
> 
>  " 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 a hi-entry to end of the cache, on behalf of
>    the previous SIP entity"
> 
>  Above is strictly talking about condition when "0" is to be used for
> index.
> 
>  The fact that last hi-entry and R-URI doesn't match is a rule for
> adding an hi-entry there is no additional rule for adding an
> hi-entry on behalf of the previous hop.

Are you saying that these two processes are not essentially the same?
If so, I have some misunderstanding as to what the difference is.  Can
you clarify what the difference between the two is?

Dale

---

From: Shida Schubert <[email-masked]>
Date: Wed, 25 Apr 2012 14:26:51 +0900

Dale;

 My comments inline..

> itself!  It probably got copied into the draft by mistake.

 Will remove it.. Thanks.

> tree preorder by their hi-indexes.

 Correct.

> So the first question is whether everybody agrees with my

 Yes.

> principles for hi-entries.

 I am still having a difficult time understanding what type of 
description you are desiring in section 10.3. I agree that if we are 
to add something that it will be in section 10.3, but I am still 
unclear what you want to see added.

 Are you referring to mentioning the potential gap(s) (restriction) ?

> you clarify what the difference between the two is?

 I will comment on this in the other e-mail you sent out. 

 Anyway, I agree that the behavior described in the (e.g. ...) can be 
moved or copied to section 9.1. 

 Regards
  Shida