Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax
Hans Erik van Elburg <ietf.hanserik@gmail.com> Sun, 12 July 2009 09:54 UTC
Return-Path: <ietf.hanserik@gmail.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 583C93A68AB for <sipcore@core3.amsl.com>; Sun, 12 Jul 2009 02:54:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.19
X-Spam-Level:
X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.409, 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 VdQ3cIo62fBz for <sipcore@core3.amsl.com>; Sun, 12 Jul 2009 02:54:28 -0700 (PDT)
Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 859653A67B3 for <sipcore@ietf.org>; Sun, 12 Jul 2009 02:54:27 -0700 (PDT)
Received: by ewy26 with SMTP id 26so1975934ewy.37 for <sipcore@ietf.org>; Sun, 12 Jul 2009 02:54:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=utok1XrVFDUlVGS6pR2NAwAKQv/v+eW3Rs1RYz1/CdA=; b=L0jwrZo0s6X/6hxvfzXYtYE0qzW/8L2eUHTUCrBIEjV7fPEygPu2xu2SUW2vYgmcVe eS082SqVomHWmhMJyftMulMMo4LvEsXGbW6Izn8L9lvNmR5EQoCsNliNr6ByBbzgXcB1 rfwPEeNU8o0CvBVX88GWu1lHCbFx1K7fy109g=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=WkfspHiIwrtZo8JEhgp+qLBmv2RaE9ByhE0SamFoHttqcoss7UDvp0gX+uGvxsRQZ3 smdSM9K6wA9nAg3lMrv8ViUviocFL2wXqVbrCKqF5KkXKlsk7eJzAbTIFFTimeDiiOz9 IKOcFy6Qi5US5KVcxZA/ZlThjVm7743uO3xVQ=
Received: by 10.210.42.20 with SMTP id p20mr3515883ebp.60.1247392494545; Sun, 12 Jul 2009 02:54:54 -0700 (PDT)
Received: from ?192.168.2.100? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 7sm3361001eyg.28.2009.07.12.02.54.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 12 Jul 2009 02:54:53 -0700 (PDT)
Message-ID: <4A59B2EC.8000609@gmail.com>
Date: Sun, 12 Jul 2009 11:54:52 +0200
From: Hans Erik van Elburg <ietf.hanserik@gmail.com>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Hadriel Kaplan <HKaplan@acmepacket.com>
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> <E6C2E8958BA59A4FB960963D475F7AC3196190A715@mail>
In-Reply-To: <E6C2E8958BA59A4FB960963D475F7AC3196190A715@mail>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: SIPCORE <sipcore@ietf.org>, Dale Worley <dworley@nortel.com>
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: Sun, 12 Jul 2009 09:54:29 -0000
Yes, I agreed with most points you raised below. Question is if this can be fixed in a backward compatible way, seems hard unfortunately /Hans Erik Hadriel Kaplan wrote: > 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 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