Subject: Re: [Sipping] I-D ACTION:draft-barnes-sipping-history-info-01.txt

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Jan 2003 18:00:46 -0500

A comment about the recording of indices...

The syntax
              hi-index = "index" EQUAL 1*(DIGIT DOT )

permits indices of "...", "1..3", ".2" etc. These seem to be incorrect. 
A better syntax would be

              hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT)

The only specification I could find for how this is maintained is in 
Section 2.2.3, which says:

     In order to maintain ordering and accurately reflect forking and
     nesting, the index should also be included, with the last digit
     being incremented as the request is retargeted.
     ...
     If the index is captured at
     each occurrence of retargeting, a proxy can more accurately capture
     the logical order and nesting involved.

This doesn't seem like enough to specify the maintenance of the index. 
Although doing this is straightforward, there ought to be some normative 
language about it. For instance the following are some issues about 
responsibility:

- if a proxy receives a request with a History-Info that has an index 
paramter, and adds another entry as it forwards the request on, MUST it 
place an index param on the new entry? If so, MUST it follow the 
intuitive rule for deriving the new index? (I think the answer should be 
YES to both of these.)

- if a proxy receives a request with a History-Info that has no index 
parameter, and it adds another entry as it forwards the request on, MAY 
it place an index param on the new entry? (I think it MUST NOT, because 
it has no way to determine a correct value.)

- if a proxy receives a request with no History-Info, and creates one 
with an initial entry, MAY it place an index param on the new entry? (I 
think it MUST NOT, because again it has no way to determine a correct 
value.)

If you buy my answers to the above, then it is the UAC that determines 
whether indices are used.

In any case, for the indices to be useful for anything there ought to be 
more normative text that specifies how they are managed.

	Paul

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 8 Jan 2003 09:01:18 -0600

Paul,

Thanks so much for your constructive comments.  My specific responses are
embedded below [MB] and I welcome further discussion on these points. 

In general, as you mention, the normative text around the index is quite
lacking and I will definitely work to improve that including your concerns
in the next version. 

Regards,
Mary. 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Tuesday, January 07, 2003 5:01 PM
To: [email-masked]
Subject: Re: [Sipping] I-D
ACTION:draft-barnes-sipping-history-info-01.txt

The syntax

permits indices of "...", "1..3", ".2" etc. These seem to be incorrect. 
[MB] Yes, you are correct.  This is wrong and your proposed syntax is what
was intended.

A better syntax would be

[MB] I think I also agree that these both should be yes.  Although, I think
that we may have to specify it as SHOULD (or RECOMMENDED) due to the
optionality aspects of HI (subject to local policy, etc.)  

[MB] Another good question.  I agree it would be much simpler to suggest
that the proxy SHOULD NOT add an index if there was HI entries without an
index.  The MUST NOT I think definitely needs to be documented is that the
proxy MUST NOT add an index to a previous index (i.e. MUST NOT attempt to
correct the previous lack of an index). It should be up to an end
application that receives HI entries that might require an index to use
whatever algorithm might be appropriate to add the indices.  

If you buy my answers to the above, then it is the UAC that determines 
whether indices are used.
[MB] I agree, this is the way that it SHOULD work and with the approach that
the UAC does add the initial entry prior to sending the request, this would
work quite well.  The only problem arises in the case of a proxy that
perhaps only needs the information within its domain, but local policy
requires the indices, then it's perhaps not unreasonable to just start with
the entries that it adds itself. So, my answer to this 3rd point is that it
would be a MAY, but I'm open to further discussion on this. 

	Paul