Re: [sipcore] Yet more comments on rfc4244bis-02
<R.Jesske@telekom.de> Mon, 08 November 2010 07:55 UTC
Return-Path: <R.Jesske@telekom.de>
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 7D1DD3A6897 for <sipcore@core3.amsl.com>; Sun, 7 Nov 2010 23:55:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQuqxPFekyPc for <sipcore@core3.amsl.com>; Sun, 7 Nov 2010 23:55:22 -0800 (PST)
Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id D5E633A6892 for <sipcore@ietf.org>; Sun, 7 Nov 2010 23:55:21 -0800 (PST)
Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail81.telekom.de with ESMTP; 08 Nov 2010 08:55:37 +0100
Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de 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: <9886E5FCA6D76549A3011068483A4BD406D5CF89@S4DE8PSAAQB.mitte.t-com.de>
In-Reply-To: <E920C682-46EF-4D81-836F-7D23AAB6EA1B@ntt-at.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [sipcore] Yet more comments on rfc4244bis-02
Thread-Index: Act/ET+h06LyiiFUQcCqjFEXp/cbKAAAZ/Ng
References: <A444A0F8084434499206E78C106220CA0235546D2F@MCHP058A.global-ad.net><A5DC4410-2B76-4EC6-B39A-1FFF5F04B853@ntt-at.com><AANLkTikXeBRvTaDg8ZX+TsqG_ZL24FUiQFf2se5UAgcm@mail.gmail.com><A444A0F8084434499206E78C106220CA02357AD547@MCHP058A.global-ad.net> <E920C682-46EF-4D81-836F-7D23AAB6EA1B@ntt-at.com>
From: R.Jesske@telekom.de
To: shida@ntt-at.com, john.elwell@siemens-enterprise.com
X-OriginalArrivalTime: 08 Nov 2010 07:55:36.0880 (UTC) FILETIME=[54349300:01CB7F1A]
Cc: Mary.Barnes@polycom.com, 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 07:55:23 -0000
Shida, 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 Roland -----Ursprüngliche Nachricht----- Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im Auftrag von Shida Schubert Gesendet: Montag, 8. November 2010 07:50 An: Elwell, John Cc: Barnes, Mary; sipcore@ietf.org 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 [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. 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 here. > > <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.). Regards Shida > > <snip/> > > John _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore
- [sipcore] Yet more comments on rfc4244bis-02 Elwell, John
- Re: [sipcore] Yet more comments on rfc4244bis-02 Shida Schubert
- Re: [sipcore] Yet more comments on rfc4244bis-02 Mary Barnes
- Re: [sipcore] Yet more comments on rfc4244bis-02 Elwell, John
- Re: [sipcore] Yet more comments on rfc4244bis-02 Shida Schubert
- Re: [sipcore] Yet more comments on rfc4244bis-02 Mary Barnes
- Re: [sipcore] Yet more comments on rfc4244bis-02 R.Jesske
- Re: [sipcore] Yet more comments on rfc4244bis-02 Shida Schubert
- Re: [sipcore] Yet more comments on rfc4244bis-02 Paul Kyzivat
- Re: [sipcore] Yet more comments on rfc4244bis-02 Shida Schubert
- Re: [sipcore] Yet more comments on rfc4244bis-02 Hadriel Kaplan
- Re: [sipcore] Yet more comments on rfc4244bis-02 R.Jesske
- Re: [sipcore] Yet more comments on rfc4244bis-02 Ian Elz
- Re: [sipcore] Yet more comments on rfc4244bis-02 Ian Elz
- Re: [sipcore] Yet more comments on rfc4244bis-02 Hadriel Kaplan
- Re: [sipcore] Yet more comments on rfc4244bis-02 Hadriel Kaplan
- Re: [sipcore] Yet more comments on rfc4244bis-02 Paul Kyzivat
- Re: [sipcore] Yet more comments on rfc4244bis-02 Paul Kyzivat
- Re: [sipcore] Yet more comments on rfc4244bis-02 R.Jesske
- Re: [sipcore] Yet more comments on rfc4244bis-02 Paul Kyzivat
- Re: [sipcore] Yet more comments on rfc4244bis-02 Hadriel Kaplan
- Re: [sipcore] Yet more comments on rfc4244bis-02 Ian Elz
- Re: [sipcore] Yet more comments on rfc4244bis-02 Ian Elz