Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02 - Shida's comments

From: Christer Holmberg <[email-masked]>
Date: Wed, 30 May 2012 12:41:13 +0200

Hi Shida,

Thanks for your review! Comments inline.

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

> 0. Spec name
>
> I think as it is no longer about proxy-feature, may be the draft name or spec name should change to reflect what the draft is doing.. "Registration of feature-cap tree and guideline"

This has been mentioned before, and if there aren't any administrative issues regarding that I am happy to change the name.

I suggest the following new title (it's quite long, but should be aligned with terminology we've used for other specs):

	"Mechanism to indicate support of features and capabilities using feature caps for the Session Initiation Protocol (SIP)"

Unless people want to do it, I guess we don't need to change the spec name, as it will go away anyway.

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

> 1. General
>
> Please be consistent with the terms used. It is confusing when so many of similar terms are used for what this draft tries to define. 
>
> e.g. 
>
> SIP feature cap
> SIP feature caps
> SIP Feature Cap
> Feature-caps
> Feature-Caps
> Feature-Cap header field

My suggestion is to use "feature cap(s)" when we talk about the feature caps, and "Feature-Caps header field" when we talk about the header field.

> Also 
>
> "features" alone and "features and capabilities" are used, I would stick with one when you are trying to say the same things. 

I suggest to use "features and capabilities".

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

> 2. Abstract
>
> Abstract is slightly confusing..
>
> Why aren't we using the term SIP intermediary, there was probably a discussion taken place in the ML but SIP entity is rather 
> confusing(I am assuming it is because it includes B2BUA??).. If you insist on using SIP entity then I would rephrase the abstract to say something along the line of...
>
> "This specification creates a new IANA registry, "SIP Feature Cap Registry" for registering "SIP feature caps" which is used by SIP entities not represented in the contact header to indicate support of features and capabilities.
>
> This specification also defines a new SIP header field, Feature-Caps header field, to convey SIP feature caps."

I suggest the following:

	"This specification creates a new IANA registry, "SIP Feature Cap
	Registry", for registering "feature caps", which are used by SIP entities 
	not represented by the URI of the Contact header field to indicate 
	support of features and capabilities.

	This specification also defines a new SIP header field, Feature-Caps,
	to convey feature caps in SIP messages."

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

> 3. Introduction (Section 1)
>
> I would fix the introduction in a similar fashion to that of abstract. 

I suggest the following:

	"This specification creates a new IANA registry, "SIP Feature Cap
	Registry", for registering "feature caps", which are used by SIP entities 
	not represented by the URI of the Contact header field to indicate 
	support of features and capabilities, and media feature tags cannot be
   	used to indicate the support.  Such cases are:

	o  - The SIP entity acts as a SIP proxy.
	o  - The SIP entity acts as a SIP registrar.
	o  - The SIP entity acts as a B2BUA, where the Contact header field
	URI represents another SIP entity.

	This specification also defines a new SIP header field, Feature-Caps,
	to convey feature caps in SIP messages."

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

> 4. Section 4.2.1 
>
> The sentence about "other registration tree being out of scope, I think is unnecessary here.. unless you want to explicitly state this.."

I am ok to remove the sentence.

However, I think it was suggested by Paul, so I want to verify that he is ok with removing it.

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

> 5. Section 4.2.3 
>
> Last paragraph, last sentence, should the must be published be MUST be published?

Yes.

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

> 6. Section 4.4.1 second paragraph
>
> What procedure defined in this spec is this talking about? Can you elaborate? 

The general procedures on how the header field is used etc.

I based the text on similar text in RFC 6086 (Info-Package), which says:

	"It is bad practice for Info Package specifications to repeat procedures 
	defined in this document, unless needed for purposes of clarification 
	or emphasis."

But, if it's unclear, maybe I could say something like:
	
	"...to repeat procedures (e.g. general procedures on the usage of
	the Feature-Caps header field and feature caps) defined..."

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

> 7. Section 4.4.5 second paragraph
>
> Add "message" in front of the flows to make it "example message flow" to make it consistent with the first paragraph. 

Ok.

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

> 8. Section 5.1 first paragraph
>
> Old " to convey support of features and capabilities, using SIP feature caps."
>
> New "to convey support of features and capabilities, by setting SIP feature caps."

Ok.

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

> 9. Section 5.1 NOTE:
>
> Old "It is not possible to convey the address of the SIP entity as a Feature-Caps header field parameter."
>
> New "It is not possible to convey the address of the SIP entity as part of a Feature-Caps header field parameter." 

Ok.

> What does the following sentence to above mean? Are you saying that you could in fact define a way to convey the address of the 
> entity which indicated support of feature/capabilities by defining a method to do so in the sip feature-cap spec?

It means that the Feature-Caps header field itself does not contain a header field parameter for conveying the address, but that an individual feature cap can have an address value if needed.

Example:

myFeatureCaps="address=x.y.z.w"

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

> 10. Section 5.1 last paragraph
>
> foo;bar and bar;foo having the same semantics seems to conflict with the following paragraph where it is indicated that the order of the feature-cap header field indicates the closeness of the entity supporting the features. 

foo and bar are feature caps within a SINGLE header field, where the order does not matter.

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

> 11. Section 5.2.1 last paragraph
>
> I am assuming that the text is trying to mandate entity adding SIP Feature-Caps header to add a "new" header on top of the existing one if there is and 
> prohibit SIP entity wanting to indicate features and capabilities from adding only the value.. Am I correct? If so this I think should be explicitly stated.

The ABNF allows for having multiple header fields, or a single header field with comma separated values, and the semantics are identical in both cases. 
However, we normally don't explicitly talk about both options, but instead talk about adding new header fields.

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

> 12.  Section 5.2.1 last paragraph, last sentence.
>
> OLD : "the SIP feature caps in the top-most Feature-Caps header field will represent the supported features "closest" to the entity."
>
> NEW: "the SIP feature caps in the top-most Feature-Caps header field will represent the features supported by the "closest" entity.

Ok. I will use "features and capabilities", though (as per comment 1).

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

> 13. Section 5.2.2 B2BUA behavior
>
> Isn't it clearer to just say B2BUA where UA is being used?

I am not sure what part of the text I would modify.

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

> 14. Section 5.2.4 Proxy behavior
>
> 5.2.1 is about UA and Proxy behavior, if 5.2.1 is a general behavior of a SIP entity, may be the title should change to general behavior or something.

So, your suggestion is that 5.2.1 would be "General SIP entity behavior"?

I am ok with that.

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

> 15. Section 5.3.2 SIP Dialog Paragraph 3
>
> Change "or a target" to "in a target"

"or" was supposed to be "of", but I'm ok with "in".

> Change "long supported" to "longer supported"

Ok.

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

> 16. IANA section
>
> - It is a little confusing how in the registration policy, "+" is not used but it is mandatory when it is set. I have no problem with it but may be it
>should be noted in the registration policy that although it is not registered with "+", it is prepended to the fcap-name when used.

I suggest the following mdofication:

	OLD: "No leading "+" is used in the registrations in any of the media feature tag trees."

	NEW: "No leading "+" is used in the registrations in any of the media feature tag trees. However, "+" is prepended to the fcap-name when added to a Feature-Caps header field."

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

Thank You!

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 30 May 2012 11:52:21 -0400

Some followon comments. I've stripped it down to the points I'm 
commenting on.

	Thanks,
	Paul

> Thanks for your review! Comments inline.

There is no problem changing the name.

> 	"Mechanism to indicate support of features and capabilities using feature caps for the Session Initiation Protocol (SIP)"

The inclusion of both "features and capabilities" and "feature caps" in 
the title seems quite redundant.

How about:

"Mechanism to indicate support of features and capabilities of Session 
Initiation Protocol (SIP) intermediaries" ?

Or maybe that doesn't work because it applies to registrars, which 
aren't intermediaries?

Or maybe just:

"Mechanism to indicate support of features and capabilities in the 
Session Initiation Protocol (SIP)"

The latter could be construed to encompass what 3840 does, but that one 
has a name that mentions User Agent, so I think its ok.

> Unless people want to do it, I guess we don't need to change the spec name, as it will go away anyway.

Agreed.

>     	used to indicate the support.  Such cases are:

I think s/and media feature tags/where media feature tags/

> 	to convey feature caps in SIP messages."

Yes, I said the following back on 24-may:

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

But I think this sentence and the following note say essentially the 
same thing. So I'm ok with dropping this sentence and retaining the 
note. But I think the note needs a bit of touch up. It currently says:

    NOTE: Compared to RFC 2506, this specification only defines a global
    tree and a sip tree, as they are the only tree defined in RFC 2506
    that have been used for defining media feature tags for SIP.

That's mostly true, but 3840 does call out some existing feature tags 
from the ietf tree for use with sip. So how about:

    NOTE: In contrast to RFC 2506, this specification only defines a
    global tree and a sip tree, as they are the only trees defined in
    RFC 2506 that have been used for defining SIP-specific media feature
    tags.

> myFeatureCaps="address=x.y.z.w"

The paragraph is still a bit confusing. How about:

    NOTE: It is not possible to convey the address of the SIP entity as a
    Feature-Caps header field parameter.  Each feature that requires
    address information to be conveyed need to define a way to convey
    that information as part of the associated SIP feature cap value.

    NOTE: If data is needed about a feature, such as the address of the
    sip entity, then the feature definition must define a way to convey
    that information as part of the associated SIP feature cap value.

> However, we normally don't explicitly talk about both options, but instead talk about adding new header fields.

Christer and I discussed this. I had proposed some wording that covered 
both ways. But it was cumbersome, and I'm not aware of any other draft 
that deals with it. So I decided I was ok with this. But if Shida has an 
idea of how to make this clear without being cumbersome then I'm all for it.

---

From: Shida Schubert <[email-masked]>
Date: Thu, 31 May 2012 09:48:09 +0900

Hi Christer;

 My comments inline..

> Thanks for your review! Comments inline.

 Sounds good.

 Looks good to me.

> 	to convey feature caps in SIP messages."

 Looks good to me.

> However, I think it was suggested by Paul, so I want to verify that he is ok with removing it.

 OK.

>> Last paragraph, last sentence, should the must be published be MUST be published?

 That I think is better..

 Ok.

> foo and bar are feature caps within a SINGLE header field, where the order does not matter.

 Right.. Fair enough.. 

 Regards
  Shida

---

From: Shida Schubert <[email-masked]>
Date: Thu, 31 May 2012 09:52:08 +0900

Hi Paul;

 my comments inline on relevant point..

On May 31, 2012, at 12:52 AM, Paul Kyzivat wrote:

> Christer and I discussed this. I had proposed some wording that covered both ways. But it was cumbersome, and I'm not aware of any other draft that deals with it. So I decided I was ok with this. But if Shida has an idea of how to make this clear without being cumbersome then I'm all for it.
> 

 I am okay with it too. I was just wanting to clarify it... 

 It may help for those implementors that have read the draft once and 
end up implementing based on ABNF, to add a note in ABNF repeating 
what is stated at the end of 5.2.1.. To encourage implementors to 
follow what is suggested.. To take it even further you can add a text 
with "MUST NOT add value to an existing SIP Feature-Caps header" but 
that may be too much..

 Regards
  Shida

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 31 May 2012 00:40:25 -0400

> with "MUST NOT add value to an existing SIP Feature-Caps header" but

I don't want to take a stand that way. I think either way is equally 
acceptable. And adding to an existing header saves bytes, which can 
sometimes matter. So I don't want to discourage doing so.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 31 May 2012 09:03:29 +0200

Hi Paul,

> The inclusion of both "features and capabilities" and "feature caps" in the title seems quite redundant.
>
> How about:
>
> "Mechanism to indicate support of features and capabilities of Session Initiation Protocol (SIP) intermediaries" ?
>
> Or maybe that doesn't work because it applies to registrars, which aren't intermediaries?
>
> Or maybe just:
>
> "Mechanism to indicate support of features and capabilities in the Session Initiation Protocol (SIP)"
>
> The latter could be construed to encompass what 3840 does, but that one has a name that mentions User Agent, so I think its ok.

I'm fine with that.

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

Yes.

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

Yes.

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

> "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 
>But I think this sentence and the following note say essentially the same thing. So I'm ok with dropping this sentence and retaining the note. But I think the note needs a bit of touch up. It currently says:
>
> That's mostly true, but 3840 does call out some existing feature tags from the ietf tree for use with sip. So how about:
>

The sip tree isn't defined in RFC 2506, so I think both the old and new note text is missleading.

What about:

	"NOTE: In contrast to RFC 2506, this specification only defines a
	global tree, as it is the only tree defined in RFC 2506 that has been 
	used for defining SIP-specific media feature tags."

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

>>> What does the following sentence to above mean? Are you saying that 
>>> you could in fact define a way to convey the address of the entity which indicated support of feature/capabilities by defining a method to do so in the sip feature-cap spec?
>>

Looks good.

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

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 31 May 2012 12:15:56 +0200

Hi,

>>>>> I am assuming that the text is trying to mandate entity adding SIP 
>>>>> Feature-Caps header to add a "new" header on top of the existing one if there is and prohibit SIP entity wanting to indicate features and capabilities from adding only the value.. Am I correct? If so this I think should be explicitly stated.
>>>>
>>> Christer and I discussed this. I had proposed some wording that covered both ways. But it was cumbersome, and I'm not aware 
>>> of any other draft that deals with it. So I decided I was ok with this. But if Shida has an idea of how to make this clear without being cumbersome then I'm all for it.
>>>
>>
> I don't want to take a stand that way. I think either way is equally acceptable. And adding to an existing header saves bytes, which can sometimes matter. So I don't want to discourage doing so.

I don't think anyone should implement anything simply based on the ABNF, because there are things which cannot be indicated in ABNF :)

However, in this case, the ABNF does show that it is allowed to have a single header field, with multiple values, and there is a normative reference to the ABNF spec.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 31 May 2012 10:37:16 -0400

Christer,

One thing:

> The sip tree isn't defined in RFC 2506, so I think both the old and new note text is missleading.

Good point.

> 	used for defining SIP-specific media feature tags."

This is correct. But maybe it isn't quite the point that needs to be 
made. How about:

     NOTE: In contrast to RFCs 2506 and 3840, this specification only
     defines a global tree and a sip tree, as they are the only trees
     defined in those RFCs that have been used for defining SIP-specific
     media feature tags.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 31 May 2012 17:30:46 +0200

Hi,

Looks good.

Regards,

Christer