Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax
Hadriel Kaplan <HKaplan@acmepacket.com> Sat, 11 July 2009 21:11 UTC
Return-Path: <HKaplan@acmepacket.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 1F8383A6B2E for <sipcore@core3.amsl.com>; Sat, 11 Jul 2009 14:11:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level:
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599]
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 JJXYEjRdGwFr for <sipcore@core3.amsl.com>; Sat, 11 Jul 2009 14:11:36 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A001A3A68D4 for <sipcore@ietf.org>; Sat, 11 Jul 2009 14:11:36 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sat, 11 Jul 2009 17:12:05 -0400
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 11 Jul 2009 17:12:02 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>, Mary Barnes <mary.barnes@nortel.com>, Dale Worley <dworley@nortel.com>, Francois Audet <audet@nortel.com>
Date: Sat, 11 Jul 2009 17:11:48 -0400
Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax
Thread-Index: AcoBnGvHKCIaPFDpQf+/3xhnWI6IYwAAJ2rwAC99fZAABD00QA==
Message-ID: <E6C2E8958BA59A4FB960963D475F7AC3196190A715@mail>
References: <1246996560.5962.37.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EDE5C07@zrc2hxm0.corp.nortel.com> <1247077928.3712.26.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EE8A67C@zrc2hxm0.corp.nortel.com> <1247257464.3757.67.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EEDE853@zrc2hxm0.corp.nortel.com> <E6C2E8958BA59A4FB960963D475F7AC3196190A713@mail>
In-Reply-To: <E6C2E8958BA59A4FB960963D475F7AC3196190A713@mail>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: SIPCORE <sipcore@ietf.org>
Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax
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: Sat, 11 Jul 2009 21:11:38 -0000
Ignore that email - just realized it was done that way in the original RFC4424, so we're stuck with it for posterity's sake. Blech. -hadriel > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf > Of Hadriel Kaplan > Sent: Saturday, July 11, 2009 4:17 PM > To: Mary Barnes; Dale Worley; Francois Audet > Cc: SIPCORE > Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax > > > Howdy, > I have some warning bell ringing in my head against this idea of changing > the Request-URI encoded in the HI header (the hi-targeted-to-uri) to > include an embedded Reason or Privacy header. I think the bell is due to > the following concerns: > > 1) Afaict, the Reason value is not an attribute/property of the URI - it > is the History-Info mechanism's specific rerouting cause, i.e. it's a > property of what caused the HI header field to be created, so it's a > property of the header field. The Privacy header is a little less clear, > but again ISTM that it's a command for the HI mechanism itself, and thus > an attribute of the HI header field. For example, one of the potential > actions to be taken by a Proxy is to remove the HI entry entirely - not > just the URI. > > 2) If it weren't for this added escaped URI header, the hi-targeted-to-uri > would be a literal copy of the original request-URI. (right?) That would > provide a clean way of doing troubleshooting and target > determination/matching, without exception checking for special things > added by this RFC into the URI for its own purposes. > > 3) If we ever decide to create some way of securing the original URI in > HI's, for example by signing it, it adds confusion or even breaks the > signature if the original URI is not actually left alone. > > 4) While it may seem that embedded headers could not have appeared in the > received Request-URI to being with, in practice I have seen embedded > headers in received SIP Request-URI's. In particular, in INVITE's created > from REFER's, and in ENUM-routing cases. In such cases there could > theoretically be ambiguity whether the embedded header came from the HI > mechanism vs. the actual request-URI. > > 5) The hi-targeted-to-uri can be a tel-uri (right?); can tel-URI's have > embedded headers? (it's not a SIP-URI) > > -hadriel > > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf > > Of Mary Barnes > > Sent: Friday, July 10, 2009 4:44 PM > > To: Dale Worley; Francois Audet > > Cc: SIPCORE > > Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax > > > > A couple points below [MB]. > > > > Mary. > > > > -----Original Message----- > > From: Worley, Dale (BL60:9D30) > > Sent: Friday, July 10, 2009 3:24 PM > > To: Audet, Francois (SC100:3055) > > Cc: Barnes, Mary (RICH2:AR00); SIPCORE > > Subject: RE: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax > > > > On Thu, 2009-07-09 at 14:07 -0400, Audet, Francois (SC100:3055) wrote: > > > It's basically saying that the Privacy and Reason "escaped parameters" > > > > > would translate into headers if we were to created a request based on > > it. > > > > I can't see any circumstances where we would want to create a request > > that included the Privacy or Reason headers from a H-I entry. > > > > In regard to Privacy, if its value is "history", that means that the > > particular H-I URI should be restricted. But that is not the meaning of > > adding the "Privacy: history" header to a request -- in the latter case, > > History-Info should not be generated at all. (Which is what I mean when > > I say "the values of Privacy in History-Info do not have the same > > semantics as the values of the Privacy header".) > > > > In regard to Reason, as far as I can tell, it is attached to an H-I > > entry to show the response that was received to the request that was > > sent to that URI. Generating a request based on that H-I entry would > > create a request to that same URI, containing a Reason header in the > > request that *predicts* the response that the request will receive. > > > > Given that in no case would we want to generate and use (with the > > implicit headers) a request based on the H-I entry's URI-with-headers, I > > don't see why these data items are stored in headers attached to the > > URI. > > [MB] We discussed this in another thread and the motivation was the > > reuse of existing headers rather than defining parameters that had the > > same semantics and values. That was discussed at IETF-55 in Atlanta in > > the SIPPING WG meeting in November 2002: > > http://www.ietf.org/proceedings/02nov/slides/sipping-2/sld5.htm > > > > And, this makes sense in particular for Reason and perhaps lesser so for > > Privacy. And, as you say we would never use the Request URIs in these > > hi-entrys to generate a request so this does not cause any problems. > > The intent is not to add parameters to the Request URI for any reasons > > other than to take advantage of the "clever" escaping mechanism provided > > by HTTP and to avoid defining parameters with the same values as the > > headers, both of which are not bad ideas. And, the normative text is > > quite clear that this is the intent. [/MB] > > > > On Wed, 2009-07-08 at 19:25 -0400, Barnes, Mary (RICH2:AR00) wrote: > > > As far as privacy, I'm not sure what you mean with regards to " This > > > privacy value is an annotation of the URI, whereas the current syntax > > > incorporates it *into* the URI." The privacy value isn't incorporated > > > > > into the URI - it's an escaped parameter. > > > > It's an escaped parameter, but it *is* part of the URI -- see the > > production "SIP-URI" in section 25.1 of RFC 3261. And if you ask the > > grammar, "What is the URI part of an H-I entry?" you will get back the > > 'headers' as part of the URI. > > [MB] See my comment above. Since we have specified clearly in the HI > > ABNF and in the normative text, this URI needs to be appropriately > > handled to derive the parameters. And, it is not abnormal to remove the > > headers that are escaped in the URIs - basic HTTP. > > > > Similarly, any device or syntax which admits a SIP URI will allow you to > > enter a string containing 'headers'. Indeed, there is only one > > situation where a SIP URI is possible but that URI cannot contain > > 'headers', and that is as the request-URI of a request. That isn't > > specified in the syntax (which allows SIP-URI), but is a consequence of > > the processing in section 19.1.5, which removes the 'headers' from the > > supplied SIP URI and turns them into message headers. > > [MB] Exactly and that's why it's not a problem. Since we are capturing a > > Request URI, there is no conflict between the headers that we escape > > since no other headers can be escaped in the Request URI. > > [/MB] > > > > Dale > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore
- [sipcore] draft-barnes-sipcore-rfc4244bis - hi-ta… Dale Worley
- Re: [sipcore] draft-barnes-sipcore-rfc4244bis - h… Mary Barnes
- Re: [sipcore] draft-barnes-sipcore-rfc4244bis - h… Dale Worley
- [sipcore] draft-barnes-sipcore-rfc4244bis - priva… Dale Worley
- Re: [sipcore] draft-barnes-sipcore-rfc4244bis - p… Mary Barnes
- Re: [sipcore] draft-barnes-sipcore-rfc4244bis - p… Francois Audet
- Re: [sipcore] draft-barnes-sipcore-rfc4244bis - p… Dale Worley
- Re: [sipcore] draft-barnes-sipcore-rfc4244bis - p… Mary Barnes
- Re: [sipcore] draft-barnes-sipcore-rfc4244bis - p… Francois Audet
- Re: [sipcore] draft-barnes-sipcore-rfc4244bis - p… Hadriel Kaplan
- Re: [sipcore] draft-barnes-sipcore-rfc4244bis - p… Hadriel Kaplan
- Re: [sipcore] draft-barnes-sipcore-rfc4244bis - p… Hans Erik van Elburg
- Re: [sipcore] draft-barnes-sipcore-rfc4244bis - p… Paul Kyzivat
- Re: [sipcore] draft-barnes-sipcore-rfc4244bis - p… Francois Audet
- Re: [sipcore] draft-barnes-sipcore-rfc4244bis - p… OKUMURA Shinji
- Re: [sipcore] draft-barnes-sipcore-rfc4244bis - p… Dale Worley