Subject: [Simple] WGLC: User Agent Capability Extension to PIDF (prescaps)

From: Hisham Khartabil <[email-masked]>
Date: Fri, 2 Dec 2005 12:27:56 +0100

The WG chairs would like to start a Working Group Last Call on the  
following drafts:

http://www.ietf.org/internet-drafts/draft-ietf-simple-prescaps-ext 
-05.txt

This WGLC will end on December 16th, 2005.

Please send your comments to this mailing list and to the authors.

Thanks,
Hisham

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: "Mary Barnes" <[email-masked]>
Date: Sat, 17 Dec 2005 09:21:40 -0600

I've reviewed the document and believe it is about ready to forward to
IESG for review, after correction of editorial nits and some discussion
on the security section.  I will add the caveat that I'm not an XML guru
and I'm assuming some sort of tool has been used to validate the schema.

Potential issues:
----------------

- Section 8.  How do the security considerations discussed in RFC 3840
apply to the use of these feature tags in the PIDF?  You have one
general statement in the 2nd sentence of the first paragraph and this
would seem a good place to discuss this.  

- Section 8.  You have as a SHOULD stength the use of a transport
protocol that provides some level of protection, however, what's the
impact if such a protocol is not used?  

Editorial nits:
---------------

- Title: Although the title is already quite long, I would think it
would be useful to have SIP in there (i.e. Session Initiation Protocol
(SIP) User Agent Capability Extension to Presence Information Data
Format (PIDF)) 

- Abstract: again, I think SIP should be mentioned somewhere in the
abstract.  Actually, I think you can replace the use of "RFC3840" in the
abstract with "SIP user agent".   This is consistent with not using
references to the IMPP RFCs in the abstract, as well. 

- Introduction, 1st para, 6th sentence: insert "a" between "taken" and
"very", i.e. the sentence should read:
   "It has taken a very minimalistic approach to support such
operations."

- Introduction, 1st para, last sentence.  I would suggest to replace the
reference to "RFC3863" to "PIDF", as you did earlier in the paragraph
for reference [4]. It's confusing to have a combination of ways for
referring to the same document in this document.  For readers that
aren't as familiar with this area, it could be confusing. 

- Section 1.1, page 4, 4th sentence.  "represent" should be "represents"

- Section 1.1, page 5, last para of that section: "would contained"
should be either "would contain" or "contained".

- Section 3.2.1, page 6, 3rd sentence: "This element can contain
following..." should be changed to normative language "This element MAY
contain any of the following..." (I'm assuming this rewording keeps the
same intent?)

- Section 3.2.9, 2nd para, page 8: the reference to the MIME spec [19]
seems normative to this document, but it's listed as an informative
reference.  Shouldn't it be a normative dependency?  

- Section 3.2.11, last para, page 9: The sentence on IANA registration
is a bit awkward.  I would suggest rewording FROM: 
"  Any value that is register to IANA to SIP Media Feature Tag
   Registration Tree as sip.class media feature tag can be used as a
   value of an extension element.  If appropriate value is not
   registered it SHOULD be registed as defined in RFC3840 [6]."
TO:
  "Any value that is registered with IANA for the SIP Media Feature Tag
   Registration Tree as a sip.class media feature tag can be used as a
   value of an extension element.  If the appropriate value is not
   registered it SHOULD be registed as defined in RFC3840 [6].

- General comment: the previous comment also applies to sections 3.2.12
and 3.2.19

- section 3.2.12, page 9, 1st para: "can only receive..." should be
"only receive" for consistency with the rest of the parts of that
sentence.

- Sections 3.2.14 and 3.2.16, last paragraph.  The sentence on IANA
registration should change from: 
"  Any value that is register to IANA to SIP Event types namespace
   registry can be used as a value of an extension element."
to:
"  Any value that is registered with IANA for the SIP Event types
namespace
   registry can be used as a value of an extension element."

- Section 3.2.15.3: I would remove the "Value of" from the following
sentence (or preface the sentence with "The"):
   "Value of the "value" attribute is
   used to indicate the exact supported priority value.

- Section 3.2.17, 3rd paragraph, page 10: add "<histinfo>" to thie list
of elements. 

- Section 3.3, 1st paragraph, 1st sentence: add "the" before "dynamic"
and "PIDF" 

- Section 3.3, 2nd paragraph: there seems to be a formatting problem
with the namespace identifier (i.e. shouldn't the "urn:" be part of the
element?)

- Section 3.3.2, 1st paragraph, 1st sentence: "point or contact" should
be "point of contact" (2nd occurrence).

- Section 3.3.2, 1ast paragraph, last sentence: "If appropriate..."
should be "If the appropriate..."

- Section 8.  How do the security considerations discussed in RFC 3840
apply to this 

Mary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hisham Khartabil
Sent: Friday, December 02, 2005 5:28 AM
To: Simple WG
Subject: [Simple] WGLC: User Agent Capability Extension to PIDF
(prescaps)

Thanks,
Hisham