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

"Elwell, John" <john.elwell@siemens-enterprise.com> Mon, 08 November 2010 06:30 UTC

Return-Path: <john.elwell@siemens-enterprise.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 537AC3A699A for <sipcore@core3.amsl.com>; Sun, 7 Nov 2010 22:30:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.474
X-Spam-Level:
X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFIUn7hxhz9R for <sipcore@core3.amsl.com>; Sun, 7 Nov 2010 22:30:45 -0800 (PST)
Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id A3E8A3A684F for <sipcore@ietf.org>; Sun, 7 Nov 2010 22:30:44 -0800 (PST)
Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2205418; Mon, 8 Nov 2010 07:31:03 +0100
Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 980D023F028E; Mon, 8 Nov 2010 07:31:03 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 8 Nov 2010 07:31:03 +0100
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
To: Mary Barnes <mary.ietf.barnes@gmail.com>, Shida Schubert <shida@ntt-at.com>
Date: Mon, 8 Nov 2010 07:31:02 +0100
Thread-Topic: [sipcore] Yet more comments on rfc4244bis-02
Thread-Index: Act/BIOxgi43uUzjS8KjUp6YrSTV5gABzbFw
Message-ID: <A444A0F8084434499206E78C106220CA02357AD547@MCHP058A.global-ad.net>
References: <A444A0F8084434499206E78C106220CA0235546D2F@MCHP058A.global-ad.net> <A5DC4410-2B76-4EC6-B39A-1FFF5F04B853@ntt-at.com> <AANLkTikXeBRvTaDg8ZX+TsqG_ZL24FUiQFf2se5UAgcm@mail.gmail.com>
In-Reply-To: <AANLkTikXeBRvTaDg8ZX+TsqG_ZL24FUiQFf2se5UAgcm@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Barnes, Mary" <Mary.Barnes@polycom.com>, "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] Yet more comments on rfc4244bis-02
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Nov 2010 06:30:46 -0000

Replying to both Shida and Mary: 

> -----Original Message-----
> From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] 
> Sent: 08 November 2010 05:19
> To: Shida Schubert
> Cc: Elwell, John; Barnes, Mary; sipcore@ietf.org
> 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 
> <shida@ntt-at.com> 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.

<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