Subject: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-07.txt, sections 6-9, 10.2, 10.3

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 18 Apr 2012 23:43:17 -0400

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).

5.  History-Info Header Field Protocol Structure

   index-val =  1*DIGIT *("." 1*DIGIT)

Have we ever settled whether we allow leading zeros?  Perhaps we
should forbid leading zeros (except for "0"):

   index-val =  number *("." number)

   number =  [ %31-39 *DIGIT ] DIGIT

And there probably should be a reference to

    5234 Augmented BNF for Syntax Specifications: ABNF. D. Crocker, Ed.,
	 P. Overell. January 2008. (Format: TXT=26359 bytes) (Obsoletes
	 RFC4234) (Also STD0068) (Status: STANDARD)

6.1.  User Agent Client (UAC) Behavior

   In the case of an initial request, except
   where the UAC is part of a B2BUA, there is no cache of hi- entries
   with which to populate the History-info header field and the hi-index
   is set to 1 per Section 10.3.

I don't know if it needs to be stated or not, but there are a couple
of cases where a UAC can generate requests with hi-entries whose
hi-indexes start with 2 or a higher number:

- the UAC acts on a 3xx response it has received, thus generating a
  request that is a sibling of the initial request

- the UAC for some reason is generating a set of requests that are
  intended to be "forks" of an implicit original request 
  (This happens in draft-ietf-bliss-call-completion.)
  (An alternative would be for the UAC to use internal retargeting and
  label the forks 1.1, 1.2, etc.  But that is more verbose.)

I think that the first point is implicit in the description of 3xx
response processing, but that the second point is probably not
implied.

This could be handled by adding the sentence:

   If the UAC generates further forks of the initial request (either
   due to acting on a 3xx response or internally-directed forking to
   multiple destinations), the successive requests will add hi-entries
   with hi-indexes of 2, 3, etc.

6.2.  User Agent Server (UAS) Behavior

   When receiving a request, a UAS MUST follow the procedures defined in
   Section 9.2.

Do you mean "Section 9.1", which is the one titled "Receiving a
Request"?

   UAS MUST follows the procedures as defined in Section 9.4.  When

should be

   UAS MUST >>>follow<<< the >>>procedures in<<< Section 9.4.  When

7.  Proxy/Intermediary Handling of History-Info Header Fields

   Figure 1 provides an example of internal retargeting.

I think this statement is incorrect -- the only figure 1 is in section
5.1, and does not show internal retargeting.  I suspect this statement
is left over from an earlier version.

9.2.  Sending a Request with History-Info

   In addition, the SIP entity MUST add a new
   hi-entry to the outgoing request, but the SIP entity MUST NOT add the
   hi-entry to the outgoing request(but not the cache) populating the
   new hi-entry to the cache at this time.

This sentence clearly has been damaged during editing.  I think it
should be

   In addition, the SIP entity MUST add a new hi-entry to the outgoing
   request, but the SIP entity MUST NOT add the hi-entry to the cache
   at this time.

At this point, we need to specify the ordering of the hi-entries in
the outgoing History-Info, since the ordering of the hi-entries in the
cache isn't specified:

   The hi-entries in the outgoing request's History-Info header field
   is the preorder of the tree of hi-entries, that is, by the
   lexicographic ordering of the hi-indexes.

This needs to be updated to add "np":

   rc/mp>>>/np<<<:  The SIP entity MUST include an "rc", "mp" or "np" header
      field parameter in the hi-entry, if applicable, per the procedures
      in Section 10.4.

9.4.  Sending History-Info in Responses

   When sending a response other than a 100, a SIP entity MUST include
   all the cached hi-entries in the response, subject to the privacy
   consideration in Section 10.1.2 with the following exception: If the
   received request contained no hi-entries and there is no "histinfo"
   option tag in the Supported header field, the SIP entity MUST NOT
   include hi-entries in the response.

I think this can be clarified by

   When sending a response other than a 100, a SIP entity MUST include
   all the cached hi-entries in the response, subject to the privacy
   consideration in Section 10.1.2>>>, and<<< with the following
   exception: If the
   received request contained no hi-entries and there is no "histinfo"
   option tag in the Supported header field, the SIP entity MUST NOT
   include >>>History-Info<<< in the response.

10.2.  Reason in the History-info Header Field

   If a request has timed out (instead of being explicitly rejected),
   the SIP entity MUST include a Reason header field, containing a SIP
   error response code of 408 "Request Timeout".

More exact would be to say

   If a request has timed out (instead of being explicitly rejected),
   the SIP entity MUST update the cache as if the request received a 
   SIP error response code of 408 "Request Timeout".

That allows tel: URIs to be handled correctly, i.e., not receiving a
Reason header.

There needs to be some discussion of the fact that a request can
receive multiple "non-100 non-2xx" responses, and that their Reason
headers can have duplicate or non-duplicate reason-values.  That could
be done by adding at this point in 10.2 this paragraph:

   A request can receive multiple non-100 non-2xx responses which
   carry or imply (for responses without Reason headers, and for
   timeouts) multiple, possibly duplicated, reason-values to be
   applied to a non-tel hi-targeted-to-uri.  In these situations, the
   SIP entity must accumulate without duplications all the distinct
   reason-values in the received or implied Reason header fields.

... or whatever rule we want to adopt.

10.3.  Indexing in the History-Info Header Field

   Per the syntax in Section 5, the hi-index consists of a series of
   digits separated by dots (e.g., 1.1.2).

As far as I can tell, "digit" should be replaced with "nonnegative
integer" (or perhaps just "integer", since the BNF enforces
nonnegativeness) everywhere in the document.

   The highest digit at each
   hop reflects the number of entities to which the request has been
   retargeted at the specific hop (i.e., the number of branches).

This should be expanded by adding "at the time that the request
represented by this hi-entry was generated", since the "number of
entities to which..." changes over time, but of course, the integer in
the sent request cannot.

   Thus,
   the indexing results in a logical tree representation for the history
   of the request.

I think it would be useful to add "and the hi-entries are given in the
preorder of the tree".

   In the case that a SIP entity (intermediary or UAS) adds an hi-entry
   on behalf of the previous hop, the hi-index MUST be set to 1.

I'm not certain of the meaning of this, but I think it's incorrect as
written.  At the least, if the intermediary adds an additional
hi-entry to an existing History-Info, then it has to follow the "0.1"
rule.

If a first-hop proxy adds History-Info on behalf of a UAC, then it can
use index 1 for the initial hi-entry.

If a non-first-hop proxy adds History-Info on behalf of the upstream
entities, the situation is messier.  In principle, it should probably
apply the "0.1" rule, so the first hi-entry does not have index "1".

However, in that case, the intermediary probably won't be sending
History-Info upstream in the response, so there is no way that the
upstream entities can get confused by receiving multiple replies with
different History-Info trees that use the same root index (1).

(Actually, a UAC that acts on 3xx or initially forks can cause the
first-hop proxy to be in the same situation as a non-first-hop proxy.
But the same analysis shows that always using an initial index of 1
won't confuse the UAC.)

So I think the statement should be

   In the case that a SIP entity (intermediary or UAS) adds >>>a
   first<<< hi-entry on behalf of the previous hop, the hi-index MUST
   be set to 1.

   For
   each forward hop (i.e., each new level of indexing), the hi-index
   MUST start at 1.  An increment of 1 MUST be used for advancing to a
   new branch.

Actually, that should be "the last integers of the hi-indexes of the
new requests MUST be generated starting at 1 and incrementing by 1 for
each additional request".  The hi-indexes *themselves* don't start at
1.

       Note, that in the case of parallel forking,
       only the hi-entry corresponding to the fork is included in the
       request.

It might be useful to add "because no response can yet have been
received for any of the parallel forked requests" -- that may not be
obvious to the first-time reader.

   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.

It's also not clear to me that this trigger condition can be specified
sufficiently accurately to allow this to become a MUST.  If we are
relaxed about this, the revision would be to delete this item 6 and
update section 9.1:

   The entity MUST attempt, in the following manner, to determine if the
   previous SIP entity that sent the request did not add a hi-entry to
   the History-Info header field:

   1. It MUST detect if the Request-URI of the incoming request does
   not match the hi-targeted-to-uri in the last hi-entry.

   2. It MAY detect the condition via other means, for example, 
   if the topmost Via header shows traversing a domain which is
   different from the last hi-entry, or if the request was received
   from an address to which the last hi-targeted-to-uri could not have
   addressed the request.

(I expect that border devices may often be able to apply the latter condition.)

   When this condition is detected, the SIP entity MUST add a hi-entry
   to end of the cache, on behalf of the previous SIP entity, as
   follows:

Dale

---

From: Shida Schubert <[email-masked]>
Date: Thu, 19 Apr 2012 19:44:21 +0900

Hi Dale;

 Thanks again for your extensive review.

 My comments inline.

> 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?? 

> 	 RFC4234) (Also STD0068) (Status: STANDARD)

 DONE.

>   with hi-indexes of 2, 3, etc.

DONE.

> Do you mean "Section 9.1", which is the one titled "Receiving a

That is the intent.

>   UAS MUST >>>follow<<< the >>>procedures in<<< Section 9.4.  When

DONE.

> is left over from an earlier version.

REMOVED.

>   request, but the SIP entity MUST NOT add the hi-entry to the cache

 FIXED.

>   lexicographic ordering of the hi-indexes.

 DONE.

>      field parameter in the hi-entry, if applicable, per the procedures

 DONE.

>   include >>>History-Info<<< in the response.

 FIXED.

>   SIP error response code of 408 "Request Timeout".

 FIXED.

> ... or whatever rule we want to adopt.

 Added this with some modified text. 

> nonnegativeness) everywhere in the document.

 FIXED.

> I think it would be useful to add "and the hi-entries are given in the

 FIXED.

>   first<<< hi-entry on behalf of the previous hop, the hi-index MUST

FIXED.

> each additional request".  The hi-indexes *themselves* don't start at

FIXED.

> obvious to the first-time reader.

FIXED.

> additional condition that triggers the adding of an hi-entry described

 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. 

> relaxed about this, the revision would be to delete this item 6 and

 We can change it to SHOULD.  

 Regards
  Shida

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore