Re: VS: [Sip] Escaping rules of SIP-URI userpart

Jonathan Rosenberg <jdrosen@cisco.com> Thu, 28 September 2006 21:50 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT3m1-0000hT-Bt; Thu, 28 Sep 2006 17:50:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT3m0-0000hN-42 for sip@ietf.org; Thu, 28 Sep 2006 17:50:28 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT3ly-0006yT-GE for sip@ietf.org; Thu, 28 Sep 2006 17:50:28 -0400
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 28 Sep 2006 14:50:26 -0700
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8SLoP7g025163; Thu, 28 Sep 2006 14:50:25 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8SLoOQX002704; Thu, 28 Sep 2006 14:50:25 -0700 (PDT)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Sep 2006 14:50:25 -0700
Received: from [10.32.241.149] ([10.32.241.149]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Sep 2006 14:50:24 -0700
Message-ID: <451C439F.9020508@cisco.com>
Date: Thu, 28 Sep 2006 17:50:23 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Bob Penfield <BPenfield@acmepacket.com>
Subject: Re: VS: [Sip] Escaping rules of SIP-URI userpart
References: <5EB80D22825EEE42872083AD5BFFB59403BF96E1@esealmw113.eemea.ericsson.se> <011701c6e336$e5e8b490$800101df@acmepacket.com>
In-Reply-To: <011701c6e336$e5e8b490$800101df@acmepacket.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 Sep 2006 21:50:24.0653 (UTC) FILETIME=[1A63B3D0:01C6E348]
DKIM-Signature: a=rsa-sha1; q=dns; l=4673; t=1159480225; x=1160344225; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20<jdrosen@cisco.com> |Subject:Re=3A=20VS=3A=20[Sip]=20Escaping=20rules=20of=20SIP-URI=20userpart; X=v=3Dcisco.com=3B=20h=3DEJqpxq1xsMB8tulbWqgO55/X9yQ=3D; b=S0hNsj3xcu+R5gr7jDjBr50Nh/Ow1Ge5K5aLMgSrNNF49Dz//XNlEHoGWqteAeNnou5sEhsx GsZg9qZW3hH3USXAPKqwvujeTJ89Mug6p2XBiteSZjUcri5qYb7N2VSv;
Authentication-Results: sj-dkim-3.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93e7fb8fef2e780414389440f367c879
Cc: sip@ietf.org, Juha Heinanen <jh@tutpro.com>, "Christer Holmberg (JO/LMF)" <christer.holmberg@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I agree here with Bob, Dale and others. The SIP URI is derived from RFC 
2396 and inherits its constraints. That is part of the cost of being a 
URI as opposed to a SIP-specific type of identifier. Just because some 
implementations have not followed the spec on this point does not change 
what the spec says or why its there.

-Jonathan R.

Bob Penfield wrote:

> True, but if the SIP-URI is held in a place where a URI-reference is 
> allowed, everything after the # would be interpreted as a fragment. That 
> is why 2396 indicates it needs to be escaped.
> 
> cheers,
> (-:bob
> 
> Robert F. Penfield
> Chief Software Architect
> Acme Packet, Inc.
> 71 Third Avenue
> Burlington, MA 01803
> bpenfield@acmepacket.com
> 
> ----- Original Message ----- From: "Christer Holmberg (JO/LMF)" 
> <christer.holmberg@ericsson.com>
> To: "Bob Penfield" <BPenfield@acmepacket.com>; "Juha Heinanen" 
> <jh@tutpro.com>; <Dale.Worley@comcast.net>
> Cc: <sip@ietf.org>
> Sent: Thursday, September 28, 2006 3:28 PM
> Subject: RE: VS: [Sip] Escaping rules of SIP-URI userpart
> 
> 
> 
> Hi,
> 
> Again, when I read the SIP ABNF the only URIs that can be used are
> absoluteURI, and of course SIP-URI, and none of these contain the
> optional fragment part.
> 
> So, instead of:
> 
> Request-URI    =  SIP-URI / SIPS-URI / absoluteURI
> 
> ...the ABNF should have said something like:
> 
> Request-URI   = ((SIP-URI / SIPS-URI)["#" fragment]) / URI-reference)
> 
> ...or something like that.
> 
> 
> Regards,
> 
> Christer
> 
> 
>> -----Original Message-----
>> From: Bob Penfield [mailto:BPenfield@acmepacket.com]
>> Sent: 28. syyskuuta 2006 22:10
>> To: Juha Heinanen; Dale.Worley@comcast.net
>> Cc: sip@ietf.org
>> Subject: Re: VS: [Sip] Escaping rules of SIP-URI userpart
>>
>> I suspect it might be because a SIP-URI could be placed
>> elsewhere, like on some web page or in some other application
>> that parses all URIs according to RFC 2396. Such a generic
>> URI parser would interpret everything after the '#'
>> as a fragment. This would result in a mis-interpretation of the URI.
>>
>> cheers,
>> (-:bob
>>
>> Robert F. Penfield
>> Chief Software Architect
>> Acme Packet, Inc.
>> 71 Third Avenue
>> Burlington, MA 01803
>> bpenfield@acmepacket.com
>>
>>
>> ----- Original Message -----
>> From: "Juha Heinanen" <jh@tutpro.com>
>> To: <Dale.Worley@comcast.net>
>> Cc: <sip@ietf.org>
>> Sent: Thursday, September 28, 2006 2:08 PM
>> Subject: Re: VS: [Sip] Escaping rules of SIP-URI userpart
>>
>>
>> > Dale.Worley@comcast.net writes:
>> >
>> > > Whether it has any use in a SIP URI is not particularly
>> important --
>> > > as a URI it has to follow the generic syntax of URIs, RFC
>> 2396.  And
>> > > RFC 2396 reserves the use of '#' for fragment identifiers.
>> >
>> > there are various exceptions in rfc3261 regarding other
>> standards that
>> > rfc3261 uses.  why can't there be an exception on # too?
>> >
>> > -- juha
>> >
>> > _______________________________________________
>> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> > This list is for NEW development of the core SIP Protocol
>> > Use sip-implementors@cs.columbia.edu for questions on current sip
>> > Use sipping@ietf.org for new developments on the application of sip
>> >
>>
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use sip-implementors@cs.columbia.edu for questions on current sip
>> Use sipping@ietf.org for new developments on the application of sip
>>
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip