Subject: [sipcore] Draft new version: draft-ietf-sipcore-proxy-feature-01

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 Apr 2012 09:05:26 +0200

Hi,

I've submitted a new version (-01) of the proxy-feature draft.

Based on the discussions in Paris, instead of using feature tags the draft now creates a new IANA "feature cap" registry.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 Apr 2012 12:14:29 +0200

Hi,

In order to progress the proxy-feature work, I would ask those who requested a new IANA registry to take a look at the latest version of the draft, which creates such registry.

Others are of course also welcome to read/comment the draft :)

Currently there should be no documented open issues.

Thanks!

Regards,

Christer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 17. huhtikuuta 2012 10:05
To: [email-masked]
Subject: [sipcore] Draft new version: draft-ietf-sipcore-proxy-feature-01

Hi,

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Apr 2012 12:10:26 -0400

Christer,

[I'm sorry not getting this out sooner. I wrote it several days ago but 
somehow I never sent it.]

Thanks for getting this update in. In general this looks good. I have 
some comments about details:

Much of the syntax (ABNF - section 4.2.2) is a replica of what is in 
RFC3840. IMO this relationship should be acknowledged. My preference 
would be to formally reference the abnf definitions from 3840 and use 
the same names for them.

E.g.

    feature-cap       =  ["+"] fcap-name [EQUAL LDQUOT (fcap-value-list
                         / fcap-string-value ) RDQUOT]
    fcap-name         =  ftag-name
    fcap-value-list   =  tag-value-list
    fcap-string-value =  string-value
    ;; ftag-name, tag-value-list, string-value defined in RFC3840

Also, I am inclined to make the "+" mandatory, even though it really 
serves no purpose. The reason I propose this is to minimize confusion 
with the usage rules in 3840. In 3840 the "+" is mandatory except for 
the "grandfathered" tags. And we have had trouble getting people to 
follow that. If we make it optional here it will further confuse things.

OTOH, the reason for the + is so that feature tags can be distinguished 
from other contact parameters that are not feature tags. That need 
doesn't apply here, which is why the "+" is logically unnecessary. An 
alternative would be to *never* use the "+" here. But I'm inclined to 
require the "+" because there may be some tags defined for use as both 
feature tags and proxy features, and then I'd rather not use the "+" in 
place and not in the other.

I also find it some what confusing that part of the syntax is in this 
section while more of it is in section 5.4. I'd prefer to see these 
consolidated into a single syntax section.

Re Registration Trees:

There is no mention of an IETF tree, analogous to that defined in 2506 
for feature tags. Given the history, and a desire to provide a similar 
structure, I agree it makes sense that we aren't planning on defining 
anything of that sort. But I think it is confusing to anyone who has 
looked at 2506 that there is no mention of names that have only one facet.

So, I think it would be helpful to explicitly state that names 
consisting of only a single facet, as well as names with initial facets 
other than "g" and "sip" are out of scope for this draft. I'm undecided 
if it would be good to define an IETF tree without any content, or if it 
would be better not to define it.

The statements:

    The tree definitions are based on the global tree and sip tree
    defined for media feature tags, in RFC 2506 [RFC2506] and RFC 3841
    [RFC3841].
and
    The SIP feature cap global tree is based on the media feature tag
    global tree defined in RFC 2506 [RFC2506].
and
    The SIP feature cap sip tree is based on the media feature tag sip
    tree defined in RFC 3840 [RFC3840].

seem a little confusing to me, because its not clear what "based on" 
means. I suggest changing this to "similar to".

As far as defining new trees, the current text is:

    Additional feature caps trees can be created by IANA, following the
    same rules and procedures as defined for media feature tags in
    section 3.1.4 of RFC 2506 [RFC2506].

This in effect makes a normative dependency between this document and 
RFC2506. I think it would be better to sever the formal tie. Instead, 
this can be accomplished by adding something similar to section 3.1.4 of 
2506.

Regarding the IANA Registration Template:

    | The reference MUST contain the information listed in
    | section XX of XXXX (IANA: Replace XXXX with assigned
    | RFC number of this specification

I think this should say:

    | The referenced specification MUST contain the information listed
    | in section XX of XXXX (IANA: Replace XXXX with assigned
    | RFC number of this specification

In addition there may be some redundancy between the "SIP feature cap 
specification reference" and the "Related standards or documents". Do 
you think we need both?

Are there other things in there that are just baggage being carried over 
from 2506 that are not useful to us? (E.g. do we need the publication 
delay?)

Section 4.5.2 says:

    The SIP feature cap specification MUST contain an overall description
    of the SIP feature cap: how it is used to indicate support of a
    feature, a description of the feature associated with the SIP feature
    cap, and a description of any additional information (conveyed using
    one or more SIP feature cap values) that can be conveyed together
    with the SIP feature cap.

What this doesn't talk about is how the feature associated with the 
feature cap is exercised/invoked. So I would suggest something like:

    The SIP feature cap specification MUST contain an overall description
    of the SIP feature cap: how it is used to indicate support of a
    feature, a description of the feature associated with the SIP feature
    cap, a description of any additional information (conveyed using
    one or more SIP feature cap values) that can be conveyed together
    with the SIP feature cap, and a description of how the associated
    feature may be exercised/invoked.

Section 4.5.3:

The rules described here sound to me like ones suitable for the name of 
a parameter (e.g. a parameter bound to an event or a mime type, or to a 
sip header.) It doesn't seem very appropriate when discussing the 
representation of a *value* of a parameter/feature. For example, when 
values are enumerations, we might find things like "true" and "false" or 
"yes" and "no". Even if they are "red" / "green" / "blue", the same 
values might well make sense associated with other features. Can you 
please think this through further? It may indeed make sense to say 
*something* here, but I imagine something weaker.

Section 4.5.5 says:

    NOTE: Sometimes a SIP feature cap designer might choose to not reveal
    the implementation details of a SIP feature cap.  However, in order
    to allow multiple implementations to support the SIP feature cap,
    designers are strongly encouraged to provide the implementation
    details.

I recognize that people may not want to publish implementation details. 
But that is different from providing enough specification to all 
independent but interoperable implementations to be developed.

The amount that needs to be disclosed might vary based on which 
registration tree is used. I would expect that the sip tree would 
require sufficient spec to support an independent implementation. If you 
were instituting a URI tree then I can see that it might be considered 
entirely proprietary and hence might not require this. (But you have 
omitted the URI tree, which thus sidesteps this issue.) ISTM that the 
global tree should still require a definition of how to create an 
interoperable implementation. The difference between the global tree and 
the sip tree in this regard might be that in the case of the sip tree 
the referenced specification must be an IETF document, while in the case 
of the global tree it could be some external document.

Section 5.2.1 says:

    When the UA receives the SIP request or the response, the SIP feature
    caps in the topmost Feature-Caps header field will represent the
    supported features "closest" to the UA.

I don't think this is quite what you mean. I think you mean:

    When the UA receives the SIP request or the response, the SIP feature
    caps in the first fc-value will represent the supported features
    "closest" to the UA.

Section 5.2.2 says:

    The procedures in this section applies to UAs that are part of
    B2BUAs, but where the URI in the Contact header field does not
    represent the UA, because the B2BUA is also acting as a proxy and
    inserts its URI e.g. in a Record-Route header field.

IMO this covers some controversial ground, but probably only in ways 
that many will consider pedantic. We are in quite under specified 
territory when we talk about B2BUAs that act as Proxies. Does this mean 
that it was a proxy when the dialog was established, but later the same 
entity redeclares itself as a UA for some subsequent transaction within 
the dialog? Or was it acting as a UA when the dialog was established, 
but still chose to use a Contact URI that doesn't identify itself?

As much as I would like to have an extended discussion on this, doing so 
while working on this draft is probably counterproductive. Perhaps you 
can humor my sensitivities and just change this to:

    The procedures in this section applies to UAs that are part of
    B2BUAs that are referenced in the message by a Record-Route header
    field rather than by the Contact URI.

Section 5.2.2 then says:

    When a UA sends a SIP request, if the UA wants to indicate support of
    features towards its downstream SIP entities, it adds a Feature-Caps
    header field to the request, together with one or more Feature Caps
    associated with the supported features, before it forwards the
    request.

This says "adds" but doesn't say whether to be beginning or the end. 
Also, it isn't strictly necessary to add another header field, it can 
add to an existing header field. So I suggest:

    When a UA sends a SIP request, if the UA wants to indicate support of
    features towards its downstream SIP entities, before it forwards the
    request it adds a fc-value with the supported features to
    the request, after any others that may be present. This may be added
    to the last existing Feature-Caps header field or as a new
    Feature-Caps header field after any others.

Something similar applies a couple more times in this section and in 
sections 5.2.3 and 5.2.4. I realize this is a bit cumbersome - perhaps 
there is a more straightforward way to say it.

Section 5.3.3 says:

    If a SIP feature cap is inserted in a Feature-Caps header field of a
    SIP REGISTER request, or within a response of such request, it
    indicates to the receivers of the request (or response) that the
    feature associated with the SIP feature cap is supported for the
    duration of the registration, and for all SIP transactions associated
    with the registration, until the registration is re-freshed or
    terminated.

There are some cases we need to discuss here. When a UA sends a REGISTER 
request, it could have no contacts, one contact, or several. What do the 
feature caps mean in these cases?

- if there are no contacts in the register, are feature-caps irrelevant?
- if there is more than one contact in the register, do the feature-caps
   apply to all of them?

Then the response should contain all the registered contacts, not just 
those mentioned in the request. So do the feature caps mentioned in the 
reply apply until the last of those contacts expire? Or should the 
requester assume they only apply until *its* contacts expire?

    Unless a SIP feature cap is inserted in a Feature-Caps header field
    or a re-registration, or within a response of such request, it
    indicates to the receivers of the request (or response) that the
    feature is no long supported for the registration.

Suppose a UA registers with a contact and some feature caps. Then later 
it sends a register poll (register with no contacts). Can I assume that 
this will not affect the feature caps associated with the registered 
contact?

Do the enhanced registrar behaviors in outbound require any special 
treatment relative to feature caps?

Section 6:

There are a lot of missing IANA considerations - the establishment of 
the new trees as defined in 4.3 and 4.4.

That is all for now.

	Thanks,
	Paul

On 4/17/12 3:05 AM, Christer Holmberg wrote:
> Hi,
>
> Ive submitted a new version (-01) of the proxy-feature draft.
>
> Based on the discussions in Paris, instead of using feature tags the
> draft now creates a new IANA feature cap registry.
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 Apr 2012 11:06:24 +0200

Hi Paul,

> Much of the syntax (ABNF - section 4.2.2) is a replica of what is in RFC3840. IMO this relationship should be acknowledged. My preference would be to formally reference the abnf definitions from 3840 and use the same names for them.
>
> E.g.
>

I can do that.

I was actually already planning to do that, but I thought that people would not want to reference the RFC3840 ABNF :)

---------------------

> Also, I am inclined to make the "+" mandatory, even though it really serves no purpose. The reason I propose this is to minimize confusion with the usage rules in 3840. In 3840 the "+" is mandatory except for the "grandfathered" tags. And we have had
> trouble getting people to follow that. If we make it optional here it will further confuse things.
>
> OTOH, the reason for the + is so that feature tags can be distinguished from other contact parameters that are not feature tags. That need doesn't apply here, which is why the "+" is logically unnecessary. An alternative would be to *never* use the "+"
> here. But I'm inclined to require the "+" because there may be some tags defined for use as both feature tags and proxy features, and then I'd rather not use the "+" in place and not in the other.

I can make it mandatory for feature-caps, and e.g. add a note which points out the difference between feature-tags.

---------------------

> I also find it some what confusing that part of the syntax is in this section while more of it is in section 5.4. I'd prefer to see these consolidated into a single syntax section.

I think the Feature-Caps header field syntax, and the feature-caps syntax, shall be separated, but I can put them in the same section.

---------------------

> Re Registration Trees:
>
> There is no mention of an IETF tree, analogous to that defined in 2506 for feature tags. Given the history, and a desire to provide a similar structure, I agree it makes sense that we aren't planning on defining anything of that sort. But I think it is confusing
> to anyone who has looked at 2506 that there is no mention of names that have only one facet.
>
> So, I think it would be helpful to explicitly state that names consisting of only a single facet, as well as names with initial facets other than "g" and "sip" are out of scope for this draft. I'm undecided if it would be good to define an IETF tree without any
> content, or if it would be better not to define it.

I actually had some text about that, saying that the reason we only define "g" and "sip" is  those are the only ones used for SIP related feature-tags today (and, compared to feature-tags, the feature-caps mechanism is only defined for SIP).

For some reason that text didn't get into the -01 draft, but I will add it to the next version.

---------------------

> means. I suggest changing this to "similar to".

Ok.

---------------------

> This in effect makes a normative dependency between this document and RFC2506. I think it would be better to sever the formal tie. Instead, this can be accomplished by adding something similar to section 3.1.4 of 2506.

Ok.

---------------------

>    | RFC number of this specification

Correct.

---------------------

> In addition there may be some redundancy between the "SIP feature cap specification reference" and the "Related standards or documents". Do you think we need both?

Probably not, because it is recommended that the SIP feature cap specification contains references to usages and examples.

---------------------

> Are there other things in there that are just baggage being carried over from 2506 that are not useful to us? (E.g. do we need the publication
> delay?)

I don't know. Unless someone wants it, I can remove it.

---------------------

>    feature may be exercised/invoked.

Looks good.

---------------------

> Section 4.5.3:
>
> The rules described here sound to me like ones suitable for the name of a parameter (e.g. a parameter bound to an event or a mime type, or to a sip header.) It doesn't seem very appropriate when discussing the representation of a *value* of a
> parameter/feature. For example, when values are enumerations, we might find things like "true" and "false" or "yes" and "no". Even if they are "red" / "green" / "blue", the same values might well make sense associated with other features. Can you
> please think this through further? It may indeed make sense to say *something* here, but I imagine something weaker.

Maybe we should simply say that the value is only applicable for the feature-cap for which it has been defined. For other feature-caps, the value has to be defined explicitly for those, even if the name and/or semantics would be the same.

---------------------

> But that is different from providing enough specification to all independent but interoperable implementations to be developed.
>
> The amount that needs to be disclosed might vary based on which registration tree is used. I would expect that the sip tree would require sufficient spec to support an independent implementation. If you were instituting a URI tree then I can see that it > might be considered entirely proprietary and hence might not require this. (But you have omitted the URI tree, which thus sidesteps this issue.) ISTM that the global tree should still require a definition of how to create an interoperable implementation. > The difference between the global tree and the sip tree in this regard might be that in the case of the sip tree the referenced specification must be an IETF document, while in the case of the global tree it could be some external document.

I took the text from the Info-Package RFC.

To be honest, however, I have some troubles to understand what is really meant by "implementation details". As described in section 4.5.2, you DO have to describe how the feature-cap is used etc, so I am not sure what extra "implementation details" would bring.

So, maybe we could simply remove section 4.5.5?

---------------------

>    caps in the first fc-value will represent the supported features

Yes.

---------------------

Section 5.2.2 says:

> IMO this covers some controversial ground, but probably only in ways that many will consider pedantic. We are in quite under specified territory when we talk about B2BUAs that act as Proxies. Does this mean that it was a proxy when the dialog was
> established, but later the same entity redeclares itself as a UA for some subsequent transaction within the dialog? Or was it acting as a UA when the dialog was established, but still chose to use a Contact URI that doesn't identify itself?
>
> As much as I would like to have an extended discussion on this, doing so while working on this draft is probably counterproductive. Perhaps you can humor my sensitivities and just change this to:
>

Looks good.

---------------------

> Also, it isn't strictly necessary to add another header field, it can add to an existing header field. So I suggest:
>
> Something similar applies a couple more times in this section and in sections 5.2.3 and 5.2.4. I realize this is a bit cumbersome - perhaps there is a more straightforward way to say it.

I will double check, but I THINK we normally only talk about adding a value to an existing header field. The ABNF rules then shows whether multiple instances of the header field is allowed.

We just need to be sure that the text is clear on which features are "closest" to the UA, no matter whether they are indicated in a single header field, or in multiple header fields.

---------------------

> There are some cases we need to discuss here. When a UA sends a REGISTER request, it could have no contacts, one contact, or several. What do the feature caps mean in these cases?
>
> Then the response should contain all the registered contacts, not just those mentioned in the request. So do the feature caps mentioned in the reply apply until the last of those contacts expire? Or should the requester assume they only apply until *its*
> contacts expire?
>
> Suppose a UA registers with a contact and some feature caps. Then later it sends a register poll (register with no contacts). Can I assume that this will not affect the feature caps associated with the registered contact?

It's up to the entities that previously inserted the feature-caps to decide whether they will continue to indicate support when they receive a re-registration request/response - no matter whether it's a poll, addition of contacts etc.

Personally I see no reason why they should *not* insert the same feature-caps in a pure poll request/response, but we should allow for cases where the feature is no longer supported when the poll request/response is received.

---------------------

> Do the enhanced registrar behaviors in outbound require any special treatment relative to feature caps?

No, I don't think so.

However, I guess we could add a clarification note saying that features are only supported for the specific outbound registration flow where support has been explicitly indicated.

> Section 6:
>
> There are a lot of missing IANA considerations - the establishment of the new trees as defined in 4.3 and 4.4.

I used RFC 2506 as base, where the trees are defined more or less in the same way as in the draft. But, I guess it's better to do it in the same way as in RFC 3840.

---------------------

> That is all for now.

Thank You very much!

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Apr 2012 12:21:11 -0400

Hi Christer,

We are in agreement on many things. I have inserted further comments 
where I had something more to say.

> I was actually already planning to do that, but I thought that people would not want to reference the RFC3840 ABNF :)

Its a judgment call. In this case I think your intent is to keep the 
syntax the same, and the best way to ensure that is to have the syntax 
defined in only one place.

I don't see any particular reason to keep them separated,  especially if 
the syntax is simplified by reference to 3840. But I don't have a 
problem with separating it into two subsections, as long as they are 
together in the document.

Please also consider if there are any others that make no sense here and 
can be removed.

>> The amount that needs to be disclosed might vary based on which registration tree is used. I would expect that the sip tree would require sufficient spec to support an independent implementation. If you were instituting a URI tree then I can see that it>  might be considered entirely proprietary and hence might not require this. (But you have omitted the URI tree, which thus sidesteps this issue.) ISTM that the global tree should still require a definition of how to create an interoperable implementation.>  The difference between the global tree and the sip tree in this regard might be that in the case of the sip tree the referenced specification must be an IETF document, while in the case of the global tree it could be some external document.
>

I was about to suggest we consult the authors of the Info-Package RFC, 
but then I realized that you are one of the authors. :-)
So, what did you mean?

In the case of Info packages the point is that you are delivering an 
identified package of information, and so I would think that the 
implementation details would include any sort of "protocol" layered on 
top of that data - e.g. when I send certain info to you I expect that 
you will send back another info with an ack/nack. IOW, whatever is 
needed to successfully use this. (In some cases it may be very simple - 
send anything syntactically valid for the package whenever you want, 
with receiver free to do anything or nothing with it.

> So, maybe we could simply remove section 4.5.5?

Lets not give up just yet, before we understand.
Again, my point is to specify enough so that independent developers can 
create interoperable implementations.

Yes, I think we do usually do that, even though it is imprecise.
Within reason I'm ok with you following precedent of something with 
similar behavior. Record-Route comes to mind.

I think you missed my point. Its really the same point as my question of 
what it means to put feature caps into a polling register.

Since you want the registrar to consider the received feature caps to be 
stateful for the duration of the register, I want to know what that 
state is attached to. ISTM that it must be attached to particular 
contacts. Then, a polling register would presumably not update the state 
of any registered contact since it doesn't update any of them.

On the flip side of that, if the registrar returns feature caps, what 
does the recipient attach that state to? The only thing it could attach 
it to that has a lifetime is the registration of a particular contact, 
since the registered contacts can expire independently.

I'm only asking that you look at it. If nothing is needed, that is fine.
The clarification sounds good if it is true. (I don't know if it is true.)

> I used RFC 2506 as base, where the trees are defined more or less in the same way as in the draft. But, I guess it's better to do it in the same way as in RFC 3840.

Again, we are establishing a new IANA registry here.
I think it unwise to couple it to the definition of a different registry 
in a document we don't control. (Some day 2506 may be updated, and we 
wouldn't want that to affect *this* registry.)

In any case, IANA needs to be given explicit instructions to establish 
the new registry, and couple it to the template.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 Apr 2012 22:57:52 +0200

Hi Paul,

Comments, and a correction to one of my own previous comments, inline.

Ok.

---------------------

> together in the document.

I'll keep them separate for now, but move them to the same place.

---------------------

> Please also consider if there are any others that make no sense here and can be removed.

I did already remove some in -01, but I'll check whether there is something else that could also be removed.

---------------------

>>> The amount that needs to be disclosed might vary based on which registration tree is used. I would expect that the sip tree would require sufficient spec to support an 
>>> independent implementation. If you were instituting a URI tree then I can see that it might be considered entirely proprietary and hence might 
>>> not require this. (But you have omitted the URI tree, which thus sidesteps this issue.) ISTM that the global tree should still require a definition of how to create an interoperable implementation.
>>> The difference between the global tree and the sip tree in this regard might be that in the case of the sip tree the >>> referenced specification must be an IETF 
>>> document, while in the case of the global tree it could be some external document.
>>
>> To be honest, however, I have some troubles to understand what is really meant by "implementation details". As described in section 4.5.2, you DO have to describe how the feature-cap is
>> used etc, so I am not sure what extra "implementation details" would bring.
>

When looking at RFC 6086, I think the "Implementation Details" part contains stuff that we have put in the "General Description" part. The "General Description" part of 
RFC 6086 does not talk about providing details on how an Info-Package is used, only what type of information it carries, and what type of applications are using it.

---------------------

> similar behavior. Record-Route comes to mind.

Yes, and this is where I need to correct myself.

When a proxy adds Record-Route (or Via), it adds its value *before* any existing values, and the idea is the same for feature-caps. That is indicated in section 5.2.4 (see below), but 
I guess should be in a general section.

   "When a proxy adds a Feature-Caps header field to a SIP message, it
   MUST place the header field before any existing Feature-Caps header
   fields in the request."

   (s/request/message)

---------------------

>>> Then the response should contain all the registered contacts, not just those mentioned in the request. So do the feature caps mentioned in the reply apply until the last of those 
>>> contacts expire? Or should the requester assume they only apply until *its* contacts expire?
>>>

Ok, I think I understand. I need to think a little about it.

---------------------

> The clarification sounds good if it is true. (I don't know if it is true.)

I guess this is related to the issue above.

---------------------

> wouldn't want that to affect *this* registry.)

What I meant was that RFC 2506 does not define its registry in an IANA Considerations sections.

> In any case, IANA needs to be given explicit instructions to establish the new registry, and couple it to the template.

Yes.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Apr 2012 17:19:42 -0400

This all seems good to me.

	Thanks,
	Paul

On 4/25/12 4:57 PM, Christer Holmberg wrote:
>>>> The difference between the global tree and the sip tree in this regard might be that in the case of the sip tree the>>>  referenced specification must be an IETF