Subject: Re: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 - Robert's comments - minor issues and nits

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Aug 2012 11:18:54 +0200

Hi Robert,

(I will address the major issue in a separate reply)

Minor Issues:
------------------------------------------------

> Section 4.3.4: A SIP Stand-Alone Transaction is by definition a non-INVITE transaction. RFC4320 made 18x to non-INVITES a MUST NOT. I suggest s/18x or 2xx/2xx/ in this section.

Ok. I will change as suggested.

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

> The two places where you talk about overriding registration policy in section 5.2 isn't quite right. We should be specific that 
> we're only talking about SIP header field parameters. In the first case, we're using IETF Consensus (this document) to delegate 
> parameters starting with a 'g.' for _this_ header field to a policy of Expert Review. In the second case, there's no overriding at 
> all - registrations use IETF Consensus there.  Here's a stab at something more accurate. Maybe others can come up with 
> something better. I suggest replacing the first instance with "Note that the general policy for registering SIP header field 
> parameters is 'IETF Consensus' as specified in [RFC3968]. This document delegates the registration of parameters to the
> Feature-Caps header field starting with 'g.' to a policy of 'Expert Review'", and deleting the second instance.

> The NOTE in section 6.2.1 is not useful unless you know the history of that led to the syntax in 3840 and 3841. I suggest replacing it with
> 'NOTE: The "*" value is present in order to follow the guidelines for syntac in [RFC4485] and to maintain a consistent format with [RFC3840] and [RFC3841].'

Ok. I will change as suggested.

Nits:
------------------------------------------------

> There is a mix of "xxx" "XXX" and "XXXX" to indicate to the RFC Editor that the number assigned to this RFC should appear here. Please choose one format and make the instructions to the RFC Editor for making the substitution clear.

Ok. I'll fix that.

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

> Section 4.1: I suggest s/in a non-priority order, and any/as an unordered set. Any/

Ok. I will change as suggested.

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

> Why is the second paragraph of 4.1 in the introduction to this section? 
> It's getting pretty deep into specification detail. It would fit better at the end of 4.2.1.

Ok. I will move it there.

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

> Section 4.2.2: The beginning of paragraphs 2 an 4 start "When a UA", but don't mean any UA. They 
> rely on the context of the previous paragraphs to scope it to a UA that is part of a B2BUA. To help
> avoid confusion I suggest changing both of these this way: s/When a UA/When such a UA/

Ok. I will change as suggested.

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

> The NOTE in section 4.3.1 is confusing. What's the distinction between a SIP method and a request type 
> that's important here? What methods does this specification leave the behavior undefined for. I don't think
> there are any except perhaps CANCEL. Is the note important to keep?

The content of the note is quite obvious, so I can remove it.

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

> Section 4.3.2: s/is no long supported/is no longer supported/

Ok. I will change as suggested.

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

>Section 4.3.3: The NOTE says support applies to a Contact. It doesn't really - it applies to messages sent with that Contact as the target perhaps.

I suggest the new modified note text:

  	"NOTE: While a REGISTER response can contain contacts that have been
   	registered as part of other registration transactions, support of any
   	indicated feature only applies to requests sent to the contact(s) that 
	were explicitly conveyed in the associated REGISTER request."

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

> Section 5.1 has some edititis. Parts of it look like a "structure of this document" description, which should be in the 
> Introduction to the document. It's especially odd that it points to earlier in the document. 
> I suggest either deleting the last 3 1-sentence paragraphs, or moving them to section 1, and making the document 
> roadmap more complete.

I suggest to remove them. Adding them to section 1 (where I do agree that they belong if we would keep them) makes little sense, as the table of contents comes just before section 1.

So, section 5.1 would look like:

"5.1.  Introduction

   Feature capability indicators 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.

   A value, or a list of values, that provides additional information
   about the supported feature or capability, can be associated with a
   feature capability indicator."

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

> Section 5.2.2: I suggest s/ensure that the feature capability indicator meets/ensure that the definition of the feature capability indicator meets/

Ok. I will change as suggested.

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

> Section 5.3.3: STRONGLY RECOMMENDED isn't 2119. I suspect some 2119 purists will object that this sentence doesn't need 2119 at all. I suggest at least changing STRONGLY to lower-case, and consider changing both words.

Ok. I will change as suggested.

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

>Section 7.3.2: s/through the Expert Review policies/through the Expert Review policy/

Ok. I will change as suggested.

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

Thanks!

Regards,

Christer