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

[Paul Kyzivat <[e-mail]>]

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