Re: [sipcore] H-I in 100 response (was REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis)

"Elwell, John" <john.elwell@siemens-enterprise.com> Tue, 02 November 2010 20:31 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 597E328C0E0 for <sipcore@core3.amsl.com>; Tue, 2 Nov 2010 13:31:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.334
X-Spam-Level:
X-Spam-Status: No, score=-102.334 tagged_above=-999 required=5 tests=[AWL=0.265, 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 EjBcMpEJe06U for <sipcore@core3.amsl.com>; Tue, 2 Nov 2010 13:31:24 -0700 (PDT)
Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 9625728C0F0 for <sipcore@ietf.org>; Tue, 2 Nov 2010 13:31:23 -0700 (PDT)
Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2146463; Tue, 2 Nov 2010 21:31:12 +0100
Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 2D6B923F02AE; Tue, 2 Nov 2010 21:31:12 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 2 Nov 2010 21:31:12 +0100
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
To: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Tue, 2 Nov 2010 21:31:10 +0100
Thread-Topic: [sipcore] H-I in 100 response (was REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis)
Thread-Index: Act6x0KULvNi0/A9RYe7/9WE2pK6pgABNV6Q
Message-ID: <A444A0F8084434499206E78C106220CA023554681D@MCHP058A.global-ad.net>
References: <4C69ADA8.1010802@nostrum.com> <4C753AAA.3030407@nostrum.com> <A444A0F8084434499206E78C106220CA01C4874C5F@MCHP058A.global-ad.net> <AANLkTi=Sz5ddsWVmta5N_T8JHhrSytzALQDw=kzLcQAV@mail.gmail.com> <A444A0F8084434499206E78C106220CA023554638D@MCHP058A.global-ad.net> <AANLkTikxiK2S0oQ6Q7=JkwxYNjxK3O7BBrx+sWUQ5vOB@mail.gmail.com>
In-Reply-To: <AANLkTikxiK2S0oQ6Q7=JkwxYNjxK3O7BBrx+sWUQ5vOB@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: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] H-I in 100 response (was REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis)
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: Tue, 02 Nov 2010 20:31:25 -0000

So the remaining issue from this thread concerns whether to mandate History-Info in a all provisional responses or just non-100 provisional responses (subject to presence of the option tag in the request). Given that 100 tends to be generated differently from other provisional responses, and given the marginal use of H-I in 100 responses, I would prefer either to omit H-I from 100 responses or use MAY. I don't have a strong opinion, but perhaps others have a view.

John


> -----Original Message-----
> From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] 
> Sent: 02 November 2010 19:51
> To: Elwell, John
> Cc: sipcore@ietf.org
> Subject: Re: [sipcore] REMINDER: Re: WGLC: 
> draft-ietf-sipcore-rfc4244bis
> 
> John,
> 
> I've done the same. A couple responses inline below [MB2].
> 
> Thanks,
> Mary.
> 
> On Tue, Nov 2, 2010 at 4:06 AM, Elwell, John
> <john.elwell@siemens-enterprise.com> wrote:
> > Mary,
> >
> > I have responded below, stripping out the stuff where I 
> have nothing further to add.
> >
> <snip>
> >> > 2. It nearly always uses the term "header" rather than
> >> "header field", although never, as far as I know, meaning the
> >> entire SIP header.
> >> [MB] I'm not sure that I fully understand the concern. Can 
> you point
> >> out a specific sentence or section of concern?  The term 
> "header" is
> >> used when it is referring to the History-Info header 
> field, but that
> >> is done in other documents as well.  In general, I think it's
> >> understood that it's referring to the header field when it's
> >> qualified. Perhaps you're referring to places where it is not
> >> qualified?   The term hi-entry is used, as well.
> >> [/MB]
> > [JRE] I have explained in more detail in my comments on -02.
> [MB2] I've responded to that in my subsequent response to 
> your comments. [/MB2]
> >
> > <snip/>
> 
> >> >
> >> > 18. Section 4.2.2:
> >> > "the UAS MUST
> >> >   include any History-Info received in the request  in the
> >> subsequent
> >> >   response"
> >> > Does this include 100 responses?
> >> [MB] I would think so. Can you think of a reason why it 
> shouldn't?  I>> would think it could be useful for debug. [/MB]
> > [JRE] The 100 response typically only travels back a single 
> hop, so the benefit of H-I in a 100 is marginal. Also some 
> implementations might send back a 100 response quite early 
> during processing, perhaps even before they decide whether to 
> act as a proxy, a UAS or a redirect, so knowing how to 
> populate H-I in a 100 might be difficult.
> [MB2] If it has no additional hi-entries, then there is nothing
> additional to send back, so I don't think it hurts anything - I would
> agree that in most cases it's of marginal value. We can include it as
> an exception in that sentence if you would prefer, although per the
> next comment, it seems that you are okay with leaving it as is.
> [/MB2]
> >
> > <snip/>
> >> >
> 
> >> >
> >> > 26. Section 5.2:
> >> > "A proxy that receives a request with the "histinfo" option
> >> tag in the
> >> >   Supported header, SHOULD forward captured History-Info in
> >> subsequent,
> >> >   provisional , and final responses "
> >> > Does this include 100 responses?
> >> [MB] That's the implication of "provisional" per RFC 3261. [/MB]
> > [JRE] I am doubtful about the usefulness of 100. However, 
> it is probably fairly academic, since 100 will probably have 
> been sent earlier. A proxy is unlikely to send a 100 after 
> receiving a provisional response from a downstream entity.
> >
> >> >
> >> > 27. Section 5.2:
> >> > "A proxy MAY anonymize any hi-entry whose domain corresponds to a
> >> >   domain for which it is responsible (as per [RFC3323 ])."
> >> > I don't think RFC 3323 tells me how to anonymize an hi-entry.
> >> [MB]  RFC 3323 discusses anonymization and the role of an 
> anonymizer,
> >> etc. So, I'm not clear on your concern. [/MB]
> > [JRE] I guess if we talked about anonymizing the URI in the 
> hi-target-to-uri it would be clearer.
> [MB2] That's fine...I'll make it explicit that it's the
> hi-targeted-to-uri in the hi-entry that is anonymized. [/MB2]
> >
> > <snip/>
> >
> >
> > John
>