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

[Christer Holmberg <[e-mail]>]

Hi Paul,

>>>> 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.

Yes, but my point was that a middlebox would probably insert the feature tag in R-R, rather than Route. But, those are details that would have to be sorted out, if we choose to work on this.

>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.

Well, the "ob" parameter has different semantics depending on whether it's in Path or Route.

>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.)

Yes, we for sure would need to sort those things out.

>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.

In general I think we can only talk about "indicating support of feature", but the meaning of a specific feature tag would have to be specified in the associated feature specification. That is the case even for UAs, I believe.

>So far, features are properties of UAs, and have some relation to what might
>happen if you address a request to that for processing. 

I am not sure I agree that a feature is only a property of a UA. Where is that defined?

I DO agree, though, that within the SIP community we have so far only looked at functions related to UA features, so my question is whether there is interest to go beyond UAs.

>What would it mean for a middle box? (E.g. What is the significance if some Path header has an "is_focus" feature tag?)

The feature specification would need to define in which headers the feature tag has any meaning, and what the meaning is. Many features are probably only valid for a UAs.

But, again, there will for sure be details that have to be sorted out. I guess what we first need to decide is whether this is something we would be interested in working with in the first place.

Regards,

Christer