Re: [sipcore] Feature-tags in the Path header field

Paul Kyzivat <pkyzivat@cisco.com> Fri, 17 September 2010 21:59 UTC

Return-Path: <pkyzivat@cisco.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 BBD023A6924 for <sipcore@core3.amsl.com>; Fri, 17 Sep 2010 14:59:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.504
X-Spam-Level:
X-Spam-Status: No, score=-110.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 hWpcdvweN+z9 for <sipcore@core3.amsl.com>; Fri, 17 Sep 2010 14:59:34 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 691053A68E6 for <sipcore@ietf.org>; Fri, 17 Sep 2010 14:59:34 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAIOBk0xAZnwM/2dsb2JhbACiK3GnMZwzhUAEijOCfg
X-IronPort-AV: E=Sophos;i="4.56,384,1280707200"; d="scan'208";a="160803821"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 17 Sep 2010 21:59:58 +0000
Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o8HLxwH5029208; Fri, 17 Sep 2010 21:59:58 GMT
Message-ID: <4C93E4DE.9070802@cisco.com>
Date: Fri, 17 Sep 2010 17:59:58 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
References: <7F2072F1E0DE894DA4B517B93C6A058501703422@ESESSCMS0356.eemea.ericsson.se> <4C936714.2040808@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058501703523@ESESSCMS0356.eemea.ericsson.se>, <4C936E79.3070906@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA8B@ESESSCMS0356.eemea.ericsson.se>, <4C938ED5.10507@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA8E@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585015BCA8E@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] Feature-tags in the Path header field
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, 17 Sep 2010 21:59:35 -0000

On 9/17/2010 2:07 PM, Christer Holmberg wrote:
> Hi,
>
>>> So, if the idea of carrying feature tags in Path is ok as such, I guess one option would be an RFC which defines feature-param for Path (similar to what 4508 does for Refer-To).
>>>
>>> So, the extended Path ABNF may look something like:
>>>
>>> Path = "Path" HCOLON path-value *( COMMA path-value )
>>>
>>> path-value = name-addr *( SEMI rr-param / feature-param )
>>>
>>> (Assuming feature-param fits within the syntax for rr-param)
>>>
>>>> The fact that a parameter is defined for use on one header does not automatically usable with any other header. (Unless the two headers
>>>> share some common definition. For instance, if the definition of rr-param was extended for Route then I believe Path would automatically
>>>> pick that up as well.)
>>>
>>> I agree, and that's why I sent the e-mail to the list :)
>>
>> OK. That is something that can be discussed.
>>
>> ISTM that Path is very similar to Route, and defined to work the same.
>> So either you define what these things mean for Route, or else you have
>> to break the linkage and explain why these are appropriate for Path and
>> not Route. Also, if they are appropriate for Path, then perhaps
>> Service-Route too.
>
> I am not sure about Route, because the value is normally either pre-defined/configured or built based on Record-Route, Path or Serivce-Route. But, I guess we would need to decide whether we allow it also for Record-Route and Service-Route. There is currently no need for it (at least not what I know about), but it would probably be wise to cover all headers if we decide to do something.

Well, IIUC, the point is to encode some features of a particular 
middlebox, for the benefit of its neighbors. Route (from R-R or 
otherwise) and Path both are used in similar ways. ISTM there is at 
least a reasonable chance that the functionality might apply to either.

In any case, right now the semantics of the values in the Path header 
are linked in the spec to those of the Route header. If you propose to 
make a change so that is no longer true, then you need to be very clear 
about that - its a bigger change to Path. (And Path isn't just for 3gpp, 
I think others use it too.)

Also, there is a need to specify what it *means* for a feature tag to be 
on a Path header field (or a Route header field). I know you have a 
particular use case in mind, but you can't just specify that. So far, 
features are properties of UAs, and have some relation to what might 
happen if you address a request to that for processing. What would it 
mean for a middle box? (E.g. What is the significance if some Path 
header has an "is_focus" feature tag?)

	Thanks,
	Paul