Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-04

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Jan 2012 12:46:06 -0500

Christer,

I reviewed the new version, and have a number of comments/questions, below.

	Thanks,
	Paul

4.2 B2BUA Behavior

    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.

What about a b2bua that does not R-R? It can't be used in that case?

8. Feature Tag Usage With Feature-Caps
    ...
    Within a given Feature-Caps header field, Feature Tags are listed in
    a non-priority order, and for a given header field any order of
    listed Feature Tags have the same meaning.  For example, "foo;bar"
    and "bar;foo" have the same meaning (i.e. that the entity that
    inserted the Feature Tags supports the features associated with the
    "foo" and "bar" Feature Tags.

ISTM that this isn't really true, though I know what you mean.
A given feature-caps header field can contain multiple fc-values, and 
the order of those *is* important.

I think you mean:

    Within a single fc-value, Feature Tags are listed in
    a non-priority order, and for a given fc-value any order of
    listed Feature Tags have the same meaning.  For example, "foo;bar"
    and "bar;foo" have the same meaning (i.e. that the entity that
    inserted the Feature Tags supports the features associated with the
    "foo" and "bar" Feature Tags.

9. Feature Tag Requirements

The registration mechanism for feature tags is specified by RFC 2506. 
Sip is just a consumer of this preexisting mechanism.
I don't understand how all of the points in this section relate to that 
registration mechanism. Do you intend to amend the feature tag 
registration template? Or where do you expect the information called out 
in this section to go?

RFC 2506 identifies three registration trees, with differing 
requirements for publication and pre-approval. Do you intend that 
feature tags for use with Feature-Caps be allowed to be in any of these 
trees, or do you assume that any tree be usable?

9.6 SIP Option Tags

This seems inappropriate. An RFC is not required to make a feature tag 
specification. But an RFC *is* required to define an option tag.

You could simply omit this section. Or you could say that the 
description of a feature-tag might make reference to the relevance of 
certain sip option tags.

But the general relevance of option tags deserves more discussion. I see 
the following issues:

- is the option intended to the behavior of the element when involved in 
the registration or dialog where the feature-tag is mentioned in 
Feature-Caps? Or in some future dialog that might be established to/from 
that element as a UA?

- if it applies to the current dialog, how would the option be used:

- would the element inserting the feature-tag also be adding a
   Require for some option? That seems suspect.

- would the element inserting the feature-tag also be adding a
   Supported for some option? That seems *really* suspect if the
   element is a proxy. Maybe its ok if the element is a b2bua.

- would some other element in the dialog, after noting the presence
   of this feature-tag, be expected to insert Require for some options
   in subsequent requests? This also seems suspect.

- would some other element in the dialog, after noting the presence
   of this feature-tag, be expected to insert Proxy-Require for some
   options in subsequent requests? That would only work if the
   element indicating the feature is a proxy. A b2bua ought not be
   responding to Proxy-Require requests.

In general this needs more explanation.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 23 Jan 2012 21:53:22 +0100

Hi Paul,

> What about a b2bua that does not R-R? It can't be used in that case?

Do you refer to a b2bua that would not be part of the route set? 

The draft (section 6.2) says that, when associated with a dialog, the feature associated with the Feature Tag
must be supported for the dialog, until the next time the dialog target is refreshed, or the dialog is terminated.

So, unless the entity (no matter whether it's a proxy or a b2bua) is part of the route set, I am not sure how it would be aware of dialog target refreshes and/or dialog terminations.

I am happy to add some text about that, if needed.

-----------

>    "foo" and "bar" Feature Tags.

Correct. Looks good :)

-----------

> trees, or do you assume that any tree be usable?

This issue was raised and discussed in Taipei, and is something we need to make a decision upon.

My assumption is that, if we can't use any of the existing trees, we may have to define a new one.

I hope that we can make a decision whether to adopt the draft or not before that is sorted out however, because it shouldn't prevent us from moving ahead with the technical part.

-----------

> But the general relevance of option tags deserves more discussion. I see the following issues:
>

I think the best thing is to simply remove the option tag section. The intention of the proxy-feature mechanism is not to define a new usage of, a new semantic of, nor a new procedure for definition of, option tags. 

If someone wants to define a new option tag, no matter whether it's somehow related to a feature tag or not, he/she needs to follow the appropriate procedures for doing so.

Thanks for Your comments!

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Jan 2012 17:07:26 -0500

> I am happy to add some text about that, if needed.

I'm just searching for clarity and precision here. I don't like language 
that I can't decipher.

I notice that the reference to R-R is just an example.
So maybe that is not a constraint on the applicability of this section.
But I'm not clear what *is* normative for applicability of this section.

AFAIK a B2BUA may replace the contact address with its own. You seem to 
be excluding those. But then you seem to attempt to be more restrictive 
than that. Is "acting as a proxy" also a limitation? If so, exactly when 
is a B2BUA acting as a proxy? Or is it not replacing the contact what it 
is that means it is "acting as a proxy"?

If the b2bua doesn't r-r in a dialog establishing request then it won't 
be guaranteed to be in the route for subsequent in-dialog messages. But 
this section isn't just about dialog behavior, which is covered in 
section 6.2. It also applies to registrations and stand-alone 
transactions where r-r is not relevant.

>> registration template? Or where do you expect the information called out

You didn't respond to this. Its important.

> I hope that we can make a decision whether to adopt the draft or not before that is sorted out however, because it shouldn't prevent us from moving ahead with the technical part.

I'm not too concerned with this one (though it does need to be resolved 
eventually) unless its coupled to the answer to the prior question about 
where all this extra info goes.

> If someone wants to define a new option tag, no matter whether it's somehow related to a feature tag or not, he/she needs to follow the appropriate procedures for doing so.

I certainly agree about *defining* option tags.
I'm ok to drop all mention of option tags unless you want to do 
something special in the definition of feature tags about the *use* of 
option tags.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 Jan 2012 15:04:27 +0100

Hi,
 
>> The draft (section 6.2) says that, when associated with a dialog, the 
>> feature associated with the Feature Tag must be supported for the dialog, until the next time the dialog target is refreshed, or the dialog is terminated.
>>
>> So, unless the entity (no matter whether it's a proxy or a b2bua) is part of the route set, I am not 
>> sure how it would be aware of dialog target refreshes and/or dialog terminations.
>>
> I'm just searching for clarity and precision here. I don't like language that I can't decipher.
>
> AFAIK a B2BUA may replace the contact address with its own. You seem to be excluding those.

Correct. Because, in such cases the B2BUA can indicate its capabilities in the Contact header field.

> But then you seem to attempt to be more restrictive than that. Is "acting as a proxy" also a 
> limitation? If so, exactly when is a B2BUA acting as a proxy? Or is it not replacing the 
> contact what it is that means it is "acting as a proxy"?

One of my intention of -04 was to focus more on the fact that the B2BUA is not represented by the Contact URI, and that it therefor needs another mechanism to indicate its capabilities, rather than talking about "acting as a proxy". I realize that the "acting as proxy" wording is still used, and I will think about how it could be changed/clarified.

But, again in short: it's about an entity which is not represented by the Contact URI, and therefor needs another mechanism to indicate its capabilities.

> If the b2bua doesn't r-r in a dialog establishing request then it won't be guaranteed to be in the 
> route for subsequent in-dialog messages. But this section isn't just about dialog behavior, which is 
> covered in section 6.2. It also applies to registrations and stand-alone transactions where r-r is not relevant.

That is described in sections 6.3 and 6.4.

>>> I don't understand how all of the points in this section relate to 
>>> that registration mechanism. Do you intend to amend the feature tag 
>>> registration template? Or where do you expect the information called 
>>> out in this section to go?
>

One comment in Taipei was that we may need to provide additinoal information about these kind of feature tags, compared to what information is required for feature tag registration today, and I was asked to provide some text on that.

The Info-Package mechanism was given as an example, and I tried to put some text together based on that.

But, at the what/where information is provided of course depends on how the registration mechanism will look like.

For example, one way would be to simply use an existing tree, but make sure there is always a reference to a feature tag specification (afaik, for all 3GPP defined feature tags such references already exist today, eventhough not mandated), which contains additional information about the feature tag. Personally I think that probably would be enough, the the proxy-feature spec could then provide guidance to the expert reviewer to ask for such information.

>>> feature tags for use with Feature-Caps be allowed to be in any of 
>>> these trees, or do you assume that any tree be usable?
>>
>> I hope that we can make a decision whether to adopt the draft or not before that is sorted out 
>> however, because it shouldn't prevent us from moving ahead with the technical part.
>
> eventually) unless its coupled to the answer to the prior question about where all this extra info goes.

I don't think it's coupled. We DO need to decide what/if information needs to be provided, and where it's located, but I don't think it affects the technical mechanism itself.

Thanks!

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Jan 2012 09:40:30 -0500

> But, again in short: it's about an entity which is not represented by the Contact URI, and therefor needs another mechanism to indicate its capabilities.

OK. Then lets find a way to sharpen the language so this is clear and 
not confusing. I'm thinking it may help to define a new term for the 
kind of device you are talking about - a B2BUA that doesn't identify 
itself in the Contact (and whatever constraints apply). Define it once, 
and then use that term everywhere else.

> That is described in sections 6.3 and 6.4.

My point is that in *this* section you are defining this thing 
generically. Its behavior in the different contexts will be defined in 
section 6. So you shouldn't be defining it in a way that assumes just 
one of those contexts.

> For example, one way would be to simply use an existing tree, but make sure there is always a reference to a feature tag specification (afaik, for all 3GPP defined feature tags such references alre…

Well, the template for registering new feature tags with IANA is defined 
in 2506 and is the same for all the trees. Its only where the data comes 
from and how it is approved that vary.

ISTM that you only have two choices:

- revise the template to include additional information
- include the information in one of the fields already
   present in the existing template.

I think it could be quite a hassle to change the template, so the path 
of least resistance would be to fit it into the existing template.
The only likely places I can see in the existing template are:

- related standards or documents [optional]
- Additional information [optional]

These are both optional. But perhaps you can find a way to phrase 
requirements so that one or both are required to be present and contain 
certain information as a condition for use in Feature-Caps.

Its going to take some work to find a way to specify this. But its 
important to get it right so that proper use of Feature-Caps is defined.

> I don't think it's coupled. We DO need to decide what/if information needs to be provided, and where it's located, but I don't think it affects the technical mechanism itself.

It doesn't affect they syntax of the inclusion of the capability in the 
message. But its equally important to the draft.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 Jan 2012 16:21:18 +0100

Hi, 

>>>> The draft (section 6.2) says that, when associated with a dialog, 
>>>> the feature associated with the Feature Tag must be supported for the dialog, until 
>>>> the next time the dialog target is refreshed, or the dialog is terminated.
>>>>
>>>> So, unless the entity (no matter whether it's a proxy or a b2bua) is 
>>>> part of the route set, I am not sure how it would be aware of dialog target refreshes and/or dialog terminations.
>>>>
>>> But then you seem to attempt to be more restrictive than that. Is 
>>> "acting as a proxy" also a limitation? If so, exactly when is a B2BUA 
>>> acting as a proxy? Or is it not replacing the contact what it is that means it is "acting as a proxy"?
>>
>> One of my intention of -04 was to focus more on the fact that the B2BUA is not represented by the 
>> Contact URI, and that it therefor needs another mechanism to indicate its capabilities, rather than 
>> talking about "acting as a proxy". I realize that the "acting as proxy" wording is still used, and 
>> I will think about how it could be changed/clarified.
>>
>> But, again in short: it's about an entity which is not represented by the Contact URI, and therefor 
>> needs another mechanism to indicate its capabilities.
>
> OK. Then lets find a way to sharpen the language so this is clear and not confusing. I'm thinking 
> it may help to define a new term for the kind of device you are talking about - a B2BUA that doesn't 
> identify itself in the Contact (and whatever constraints apply). Define it once, and then use that 
> term everywhere else.

Yes.

(Keep in mind that it doesn't necessarily have to be a B2BUA (eventhough it may be the 
case in the current use-cases), but also a normal proxy.)

-------

>>> If the b2bua doesn't r-r in a dialog establishing request then it 
>>> won't be guaranteed to be in the route for subsequent in-dialog 
>>> messages. But this section isn't just about dialog behavior, which is covered in 
>>> section 6.2. It also applies to registrations and stand-alone transactions where r-r is not relevant.
>>
> My point is that in *this* section you are defining this thing generically. Its behavior 
> in the different contexts will be defined in section 6. So you shouldn't be defining it 
> in a way that assumes just one of those contexts.

Ok, I'll look at that.

-------

>>>>> registration template? Or where do you expect the information 
>>>>> called out in this section to go?
>>>
>> One comment in Taipei was that we may need to provide additinoal information 
>> about these kind of feature tags, compared to what information is required for 
>> feature tag registration today, and I was asked to provide some text on that.
>>
>> For example, one way would be to simply use an existing tree, but make sure 
>> there is always a reference to a feature tag specification (afaik, for all 
>> 3GPP defined feature tags such references already exist today, eventhough not 
>> mandated), which contains additional information about the feature tag. Personally 
>> I think that probably would be enough, the the proxy-feature spec could then 
>> provide guidance to the expert reviewer to ask for such information.
>
> Well, the template for registering new feature tags with IANA is defined in 2506 
> and is the same for all the trees. Its only where the data comes from and how it 
> is approved that vary.

Correct.

> I think it could be quite a hassle to change the template, so the path of least 
> resistance would be to fit it into the existing template.
> These are both optional. But perhaps you can find a way to phrase requirements 
> so that one or both are required to be present and contain certain information 
> as a condition for use in Feature-Caps.

Yes.

So, eventhough IANA does not mandate the additional information, maybe the proxy-feature spec could mandate it to be provided.

> Its going to take some work to find a way to specify this. But its important to get it right so that proper use of Feature-Caps is defined.

Yes. 

And, I would need some guidance and opinions on how we should move forward with that.

-------

>>>> I hope that we can make a decision whether to adopt the draft or not 
>>>> before that is sorted out however, because it shouldn't prevent us from moving ahead with the technical part.
>>>
>> I don't think it's coupled. We DO need to decide what/if information needs to be provided, 
>> and where it's located, but I don't think it affects the technical mechanism itself.
>
> It doesn't affect they syntax of the inclusion of the capability in the message. But its equally important to the draft.

Absolutely :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Jan 2012 12:24:06 -0500

trimming

> case in the current use-cases), but also a normal proxy.)

fine. Then perhaps you should aim to define a new term that encompasses 
both a proxy and B2BUAs with certain properties.

> And, I would need some guidance and opinions on how we should move forward with that.

Right.

But, if you look at the iana registry, there currently isn't any 
provision to contain many of the optional fields, including "additional 
information". There *is* provision to contain the reference to "related 
standards or documents", which is called "Reference" in the registry.

Perhaps iana would revise the registry to contain "additional 
information" if they got a registration containing it. But it might be 
simpler to specify that any feature tag that is to be used in 
Feature-Cap MUST have a related standard or document referenced in its 
registration, and that that document MUST contain specific information.

Whether that will be an acceptable solution is something that we will 
have to discuss more widely. We should include iana in this discussion.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 Jan 2012 12:22:35 +0100

Hi, 

>>>> One of my intention of -04 was to focus more on the fact that the 
>>>> B2BUA is not represented by the Contact URI, and that it therefor 
>>>> needs another mechanism to indicate its capabilities, rather than 
>>>> talking about "acting as a proxy". I realize that the "acting as proxy" wording is still used, and I will think about how it could be changed/clarified.
>>>>
>>>> But, again in short: it's about an entity which is not represented 
>>>> by the Contact URI, and therefor needs another mechanism to indicate its capabilities.
>>>
>>> itself in the Contact (and whatever constraints apply). Define it once, and then use that term everywhere else.
>>
>> Yes.
>>
>> (Keep in mind that it doesn't necessarily have to be a B2BUA 
>> (eventhough it may be the case in the current use-cases), but also a 
>> normal proxy.)
>
> fine. Then perhaps you should aim to define a new term that encompasses both a proxy and B2BUAs with certain properties.

Suggestions are welcome, but "feature node/entity" is one thing that came to my mind :)

>>> I think it could be quite a hassle to change the template, so the 
>>> path of least resistance would be to fit it into the existing template.
>>> requirements so that one or both are required to be present and 
>>> contain certain information as a condition for use in Feature-Caps.
>>
>> Yes.
>>
> But, if you look at the iana registry, there currently isn't any provision to contain many of the optional fields, including "additional information". There *is* 
> provision to contain the reference to "related standards or documents", which is called "Reference" in the registry.
>
> Perhaps iana would revise the registry to contain "additional information" if they got a registration containing it. But it might be simpler to specify that any 
> feature tag that is to be used in Feature-Cap MUST have a related standard or document referenced in its registration, and that that document MUST contain specific
> information.

Yes. That's what we have for Info Packages also (the IANA registry only contains the reference, which then contains the additional information).

> Whether that will be an acceptable solution is something that we will have to discuss more widely. We should include iana in this discussion.

Sure. But, if we as a WG can agree on a working assumption on how to move forward, we can then discuss with IANA how/if it's possible to implement.

So, my question is whether someone would object to approach where we SOMEHOW try to make the reference mandatory. 

(The details of what the reference then contains we can discuss in SIPCORE, as we did for Info Packages.)

Regards,

Christer