Subject: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-04.txt

From: [email-masked]
Date: Thu, 14 Jun 2012 03:29:09 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF.

	Title           : Mechanism to indicate support of features and capabilities in the Session Initiation Protocol (SIP)
	Author(s)       : Christer Holmberg
                          Ivo Sedlacek
                          Hadriel Kaplan
	Filename        : draft-ietf-sipcore-proxy-feature-04.txt
	Pages           : 19
	Date            : 2012-06-14

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

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-proxy-feature

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-sipcore-proxy-feature-04

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-sipcore-proxy-feature-04

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 21 Jun 2012 16:23:50 +0200

Some comments on this version:

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. 

2)	In the respect of the above comment, I would also put section 5 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. 

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.

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.

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?

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.

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.

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.

Regards

Keith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 14 June 2012 11:29
To: [email-masked]
Cc: [email-masked]
Subject: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-04.txt

Abstract:

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

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 21 Jun 2012 17:42:14 +0200

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

Keith

-----Original Message-----
From: DRAGE, Keith (Keith) 
Sent: 21 June 2012 15:24
To: [email-masked]
Subject: RE: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-04.txt

Regards

Keith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 14 June 2012 11:29
To: [email-masked]
Cc: [email-masked]
Subject: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-04.txt

Abstract: