Re: [sipcore] Yet more comments on rfc4244bis-02

["Elwell, John" <[e-mail]>]

Replying to both Shida and Mary: 

> -----Original Message-----
> From: Mary Barnes [mailto:[e-mail]] 
> Sent: 08 November 2010 05:19
> To: Shida Schubert
> Cc: Elwell, John; Barnes, Mary; [e-mail]
> Subject: Re: [sipcore] Yet more comments on rfc4244bis-02
> 
> A few additional comments inline below [MB].
> 
> Mary.
> 
> On Sun, Nov 7, 2010 at 12:28 AM, Shida Schubert 
> <[e-mail]> wrote:
> >
> > Hi John;
> >
> >  My responses on some of the comments, I think
> > Mary may be responding on the same issues but here are mine.
> >
> > On Nov 4, 2010, at 12:29 AM, Elwell, John wrote:
> >
> >> 1. Section 7.3.1.
> >> "If there is a Privacy header in the request with a priv-
> >>   value of "header" or "history", then the initial hi-entry MUST be
> >>   anonymized and the header removed when the request 
> leaves a domain
> >>   for which the SIP entity is responsible."
> >> I think it should say "...and the Privacy header removed" 
> - there is no point in removing the H-I header field if we 
> have anonymized it.
> >
> >  You are right. The intention was to say "remove the 
> priv-value and remove the privacy
> > header itself if there are no other priv-value left (id may 
> exists which needs
> > to remain in the request until it reaches the egress point)".
> >
> >>
> >> 2. What is meant by anonymizing a hi-entry (in this 
> paragraph and elsewhere)? Is it only the hi-targeted-to-uri 
> that needs to be anonymized, or also its parameters? The 
> examples in annex B show just the URI anonymized and with the 
> value [e-mail]. Is this how it MUST be done?
> 
> [MB] It is only the hi-targeted-to-uri that needs to be anonymized -
> it is a MUST. The other parameters MUST not be changed. [/MB]
[JRE] You didn't express any opinion whether we should mandate the way in which hi-targeted-uri is to be anonymized.

<snip/>

> >> 8. "MUST be calculated by incrementing the last/lowest digit
> >>       at the current level"
> >> and
> >> "That is, the lowest/last digit of the index MUST be
> >>       incremented "
> >> What if an index is a double-digit integer?
> >
> >  How about we remove the "lowest/last" and simply
> > say incrementing the digit at the current level by 1 or
> > something like that.
[JRE] Why can't we specify the field as an integer, and then we can say we increment the integer?

> >> 9. Section 8:
> >> "an
> >>   application might need to provide special handling in some cases
> >>   where there are gaps."
> >> Should there be a note discussing the fact that some gaps 
> are not detectable, e.g., if I receive 1, 1.1 and 1.1.1, I 
> cannot detect if 1.2 or 1.1.2, say, is missing.
> >
> >  This would happen, say for example if request was
> > parallel forked, each branch would have the hi-entry
> > that only the forked request traversed but missing
> > the information of the other forks. I don't know if I would
> > consider what you describe as a gap. You may be
> > missing the other branches but you should be able to
> > identify the gap in index for the branch that request
> > traversed. (You may be missing the actual hop in the
> > logical tree of History-Info that does not support
> > 4244/4244bis but as they won't add the hi-entry
> > there won't be a gap in index itself).
[JRE] Yes, I understand that, and that is why I just asked the question - I don't have a strong opinion as to whether this is good enough or not.

<snip/>

John