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

[Mary Barnes <[e-mail]>]

A few more comments below [MB2].

Thanks,
Mary.

On Mon, Nov 8, 2010 at 12:31 AM, Elwell, John
<[e-mail]> wrote:
> 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.

[MB2] My opinion is that we should mandate the anonymization in the
same form as in RFC 3323.   I can't think of a reason why it shouldn't
be mandated.  [MB2]
>
> <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?
[MB] It can't be an integer since it can't have negative values.  But,
you are correct, we do need to allow multi-digit indices, so the ABNF
needs to be fixed. [/MB]
>
>> >> 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