Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-04.txt - Keith's comments

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Jul 2012 22:44:12 +0200

Hi Keith,

>1) Both the abstract and introduction give the viewpoint that the prime function of this document is to create a registry. The protocol creation part is just an afterthought. To me both the abstract 
>and introduction should reflect the SIP extension that is defined in the document, i.e. that a new header field is defined to indicate support of capabilities. I would certainly omit the IANA registry 
>part from the abstract, and only put it right at the end of the introduction. 

As your comments were given very late (after the WGLC deadline), I would not like to remove anything from the abstract at this point.

Having said that, I am ok to "switch" the order in which the header field and IANA registry are introduced:

OLD

    This specification creates a new IANA registry, "Proxy-Feature
    Feature Caps Trees", 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, where media
    feature tags cannot be used to indicate the support.

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

NEW

    This specification defines a new SIP header field, Feature-Caps,
    to convey "feature caps" in SIP messages. This is used
    by SIP entities not represented by the URI of the Contact header
    field to indicate support of features and capabilities, where media
    feature tags cannot be used to indicate the support.

    This specification also creates a new IANA registry, "Proxy-Feature
    Feature Caps Trees", for registering feature caps.

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

>2) In the respect of the above comment, I would also put section 5 before section 4.

I can do that. But, as I think section 6 shall follow section 5, I would put section 5 AND section 6 before section 4.

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

>3) Can we use "feature capabilities" rather than "feature caps" except when we are referring to the header field or tag coding. 

We've been talking about "feature caps" since they day we decided not to use feature tags, so I would not like to change it at this point.

In addition, we do talk about "using feature caps to indicate support of features and capabilities".

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

>4) I would propose pulling section 4.3 and 4.4 out to become a main section. It's scope is different from the remainder of 
>the document, i.e. this is what specifiers of a new feature capability have to document, rather than the protocol which they 
>need to implement.

Maybe we could keep section 4.4 where it is, and move section 4.3 to section 7?

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

>5) Section 5.1, 3rd paragraph. 
>
>   The feature cap specification MUST specify for which SIP methods and
>   message types, and the associated semantics, the feature cap is
>   applicable.  See Section 4 for more information.  No semantics is
>   defined for feature caps present in SIP methods and message types not
>   covered by the associated feature cap specification.
>
>As written, this belongs in section 4.4 rather than section 5. 
>
>It also needs a reference to section 5.3.2 (1st paragraph), to section 5.3.3 (1st paragraph) and to section 5.3.4 (1st paragraph) which provides the general constraints.

I suggest to remove the paragraph from section 5.1.

Them I could add the following paragraph to section 4.4.1:

NEW

 A feature cap specification MUST NOT modify the Feature-Caps header field rules and semantics defined in section 5.

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

>6) Section 5.1, last paragraph:
>
>   Within a given Feature-Caps header field, feature caps are listed in
>   a non-priority order, and for a given header field any order of
>   listed SIP feature caps have the same meaning.  For example,
>   "foo;bar" and "bar;foo" have the same meaning (i.e. that the SIP
>   entity that inserted the feature caps supports the features and
>  capabilities associated with the "foo" and "bar" feature caps.
>
> What is the meaning of the words "for a given header field". Surely they all appear in the same header field? Is this some hangover text from a previous solution?

The syntax allows multiple Feature-Caps header fields.

But, maybe it would be clearer to say "For a given fc-value, as defined in Section 6.3.1, feature caps are listed..." instead.

NEW

 For a given fc-value, as defined in section 6.3.1, feature caps 
 are listed in a non-priority order, and any order of the listed SIP 
 feature caps have the same meaning.  For example, "foo;bar" and 
 "bar;foo" have the same meaning (i.e. that the SIP entity that 
 inserted the feature caps supports the features and capabilities 
 associated with the "foo" and "bar" feature caps.

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

>7) Section 5.2.1, 2nd paragraph:
>
>   When a SIP entity receives a SIP request, or response, that contains
>   one or more Feature-Caps header fields, the feature caps in the
>   header field inform the entity about the features and capabilities
>   supported by the entities that inserted the header fields.
>   Procedures how features and capabilities are invoked are outside the
>   scope of this specification, and MUST be described by individual
>   feature cap specifications.

There is a note in section 5.1, saying that F-C header fields as such do not contain any address information. I could move that note to section 5.2.1.

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

>I find this paragraph a little misleading, as it implies that the receiver of the header field understands from the contents which entities in the message path inserted the particular feature capability. >This is untrue, all the receiver knows is the order they were included, which may give some form of indication of nearness, but nothing beyond that.
>
>8) Section 5.2.3. This section covers registrar behaviour for a REGISTER method, but is the registrar not also the endpoint for SUBSCRIBE/NOTIFY when the reg event package is used.

In case of SUB/NOT the registrar is "represented" by the Contact URI in the request/response sent by the registrar.

In addition, it isn't necessarily the registrar that handles the reg event package.

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

>9) Section 5.3.1, 1st paragraph:
>
>   This Section describes the general usage and semantics of the
>   Feature-Caps header field for different SIP message types and
>  response codes.  The usage and semantics of a specific feature cap
>   MUST be described in the associated feature cap specification.
>
> As a normative requirement this belongs in section 4.4.

I guess your issue is the last sentence? It is already covered in section 4.4.1, and 4.4.2, so I suggest to simply remove the last sentence.

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

>10) Is " feature-cap" in the ABNF formally a header field parameter in the manner it is defined? As such should it have some representation in the header field parameters table? 
>
>I agree this is presumably covered in full detail by the other IANA registrations, but surely there should be at least a pointer in the header field parameters table.

If we wanted to do that, we would need something saying "anything beginning with "+". But, we did not do that for RFC 3840 either, so my suggestion would be not to do it for feature caps either.

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

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Jul 2012 10:48:29 -0400

Keith,

Can you please indicate whether you think Christer's proposed changes 
will meet your concerns?

	Thanks,
	Paul

On 7/13/12 4:44 PM, Christer Holmberg wrote:
>> I find this paragraph a little misleading, as it implies that the receiver of the header field understands from the contents which entities in the message path inserted the particular feature capability.>This is untrue, all the receiver knows is the order they were included, which may give some form of indication of nearness, but nothing beyond that.
>>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 Jul 2012 17:08:37 +0200

Hi Keith,

Just to clarify, that I do intend to discuss issue #10 during SIPCORE in Vancouver. But, for the other issues, which are mainly editorial, I would appretiate if you could indicate whether you are ok with the suggestd changes.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 25. heinäkuuta 2012 17:48
To: Keith Drage
Cc: [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-04.txt - Keith's comments

Keith,

Can you please indicate whether you think Christer's proposed changes will meet your concerns?

	Thanks,
	Paul

On 7/13/12 4:44 PM, Christer Holmberg wrote:
>
> Hi Keith,
>
>> 1) Both the abstract and introduction give the viewpoint that the 
>> prime function of this document is to create a registry. The protocol 
>> creation part is just an afterthought. To me both the abstract and introduction should reflect the SIP extension that is defined in the document, i.e. that a new header field is defined to indicate support of capabilities. I would certainly omit the IANA registry part from the abstract, and only put it right at the end of the introduction.
>
>> 4) I would propose pulling section 4.3 and 4.4 out to become a main 
>> section. It's scope is different from the remainder of the document, 
>> i.e. this is what specifiers of a new feature capability have to document, rather than the protocol which they need to implement.
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 Jul 2012 21:56:48 +0200

Hi,

I am suggesting to address Keith's issue #10, regarding the IANA SIP header field parameter table (see below), by adding the Feature-Caps header field to the table in the following way:

Header Field      Parameter Name    Predefined Values  Reference
----------------------------------------------------------------

Feature-Caps      <feature-cap>*    No                 [xxx]

       *<feature-cap> denotes parameter names conforming to the
       syntax<feature-cap> defined in [xxx]. Valid feature-cap
       are registered in [reference to the new feature-cap registries].

Keith has indicated off-line that he is ok with this addition, but if anyone has an issue with this proposal, please let me know asap.

Thanks!

Regards,

Christer

Keith's original comment:

   "10) Is " feature-cap" in the ABNF formally a header field parameter in the manner it is defined? As such should it have some representation in the header field parameters table?

   I agree this is presumably covered in full detail by the other IANA registrations, but surely there should be at least a pointer in the header field parameters table."

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 31 Jul 2012 20:13:36 +0200

Hi,

Based on discussions with Keith, I suggest to change the naming of the capability indcators in the draft, so that we use full naming and talk about "feature capabilities" instead of "feature caps".

The header field name will still remain the same, amd the change will not change the ABNF, or what is sent "on the wire".

If anyone has an issue with this proposal, please let me know asap.

Regards,

Christer

	"3)	Can we use "feature capabilities" rather than "feature caps" except when we are referring to the header field or tag coding."