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

<> Mon, 08 November 2010 07:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D1DD3A6897 for <>; Sun, 7 Nov 2010 23:55:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pQuqxPFekyPc for <>; Sun, 7 Nov 2010 23:55:22 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D5E633A6892 for <>; Sun, 7 Nov 2010 23:55:21 -0800 (PST)
Received: from (HELO ([]) by with ESMTP; 08 Nov 2010 08:55:37 +0100
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Nov 2010 08:55:36 +0100
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 08 Nov 2010 08:55:36 +0100
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [sipcore] Yet more comments on rfc4244bis-02
Thread-Index: Act/ET+h06LyiiFUQcCqjFEXp/cbKAAAZ/Ng
References: <><><><> <>
X-OriginalArrivalTime: 08 Nov 2010 07:55:36.0880 (UTC) FILETIME=[54349300:01CB7F1A]
Subject: Re: [sipcore] Yet more comments on rfc4244bis-02
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Nov 2010 07:55:23 -0000

Do I understand you correct that you woulf like to mandate the uri format e.g. anonymus@anonymus,invalid? 
Why you would like it to be stronger than in RFC3323 mandated?

Best Regards



-----Urspr√ľngliche Nachricht-----
Von: [] Im Auftrag von Shida Schubert
Gesendet: Montag, 8. November 2010 07:50
An: Elwell, John
Cc: Barnes, Mary;
Betreff: Re: [sipcore] Yet more comments on rfc4244bis-02

Hi John;

 My comments inline.

On Nov 8, 2010, at 3:31 PM, Elwell, John wrote:

> Replying to both Shida and Mary: 
>> -----Original Message-----
>> From: Mary Barnes [] 
>> Sent: 08 November 2010 05:19
>> To: Shida Schubert
>> Cc: Elwell, John; Barnes, Mary;
>> 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 
>> <> 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 anonymous@anonymous.invalid. 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.

 To avoid redundant anonymization in case there are numerous 
proxy acting as a privacy services, it would be good to mandate 
how hi-targeted-uri is anonymized, so I am happy to say MUST 

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

 Sounds good to me. 

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

 I think we can definitely add a text saying the hi-entries 
an entity receives may not represent the whole picture 
of where request was sent (other branches etc.). 


> <snip/>
> John

sipcore mailing list