Re: [sipcore] draft-barnes-sipcore-rfc4244bis - hi-targeted-to-uri

"Francois Audet" <audet@nortel.com> Fri, 10 July 2009 17:19 UTC

Return-Path: <AUDET@nortel.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 9B9863A6E6F for <sipcore@core3.amsl.com>; Fri, 10 Jul 2009 10:19:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.336
X-Spam-Level:
X-Spam-Status: No, score=-7.336 tagged_above=-999 required=5 tests=[AWL=1.263, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
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 xmsEWYDgHUdU for <sipcore@core3.amsl.com>; Fri, 10 Jul 2009 10:19:45 -0700 (PDT)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 856DE3A6E81 for <sipcore@ietf.org>; Fri, 10 Jul 2009 10:19:33 -0700 (PDT)
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6AHIJj23282; Fri, 10 Jul 2009 17:18:19 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 10 Jul 2009 12:19:53 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF1EEDE3C8@zrc2hxm0.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EEDE21D@zrc2hxm0.corp.nortel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis - hi-targeted-to-uri
thread-index: AcoBKYpcz2kxjeifS+K4RZGCZCI9LgATh7FgAAIT7gA=
References: <6CA0129806DD4shin@softfront.co.jp> <1ECE0EB50388174790F9694F77522CCF1EEDE21D@zrc2hxm0.corp.nortel.com>
From: Francois Audet <audet@nortel.com>
To: Mary Barnes <mary.barnes@nortel.com>, OKUMURA Shinji <shin@softfront.co.jp>, sipcore@ietf.org
Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - hi-targeted-to-uri
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: Fri, 10 Jul 2009 17:19:46 -0000

The reason is so that the URI is enclosed in <> which then allows us
to separate the URI parameters from the History-Info parameters.

For example, if we allowed addr-spec, there would be no
clean way to know if a parameter (say "index") was a
URI parameter, or a History-Info parameter.

Now, if you look at the definition of the Contact header,
it has the same problem. Contact can be either
name-addr / addr-spec however. So what we did in 3261 is
include text in 20.10 that says "If no "<" and ">" are 
present, all parameters after the URI are header parameters,
not URI parameters.".

I guess we could have done something similar here, but as you
can see, it it very nasty logic. Furthermore, since H-I very
often includes header parameters, the value of allowing 
addr-spec ends up being very low (i.e., you only same a couple
of letters "<" and ">" in only simple circumstances.

Therefore, using always the "<" ">" makes it much cleaner and
simpler, and easier to parse.

> -----Original Message-----
> From: Barnes, Mary (RICH2:AR00) 
> Sent: Friday, July 10, 2009 09:15
> To: OKUMURA Shinji; sipcore@ietf.org
> Cc: Audet, Francois (SC100:3055)
> Subject: RE: [sipcore] draft-barnes-sipcore-rfc4244bis - 
> hi-targeted-to-uri
> 
> Hi Shinji,
> 
> I honestly can't remember if there was a specific reason why 
> we used just name-addr, other than it also encompasses the 
> addr-spec so you get consistency in the format for the field. 
> I'd welcome other opinions on this. 
> 
> Thanks,
> Mary. 
> 
> -----Original Message-----
> From: sipcore-bounces@ietf.org 
> [mailto:sipcore-bounces@ietf.org] On Behalf Of OKUMURA Shinji
> Sent: Friday, July 10, 2009 1:42 AM
> To: sipcore@ietf.org
> Subject: [sipcore] draft-barnes-sipcore-rfc4244bis - 
> hi-targeted-to-uri
> 
> Hi,
> 
> I have one suggestion.
> 
> In the draft hi-targeted-to-uri is defined as follows
> 
> hi-targeted-to-uri = name-addr
> 
> If there is no special reason for the restriction, I think 
> addr-spec should be added as follows
> 
> hi-targeted-to-uri = name-addr/addr-spec
> 
> Regards,
> Shinji
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>