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

From: "Mary Barnes" <[email-masked]>
Date: Thu, 12 Jan 2006 12:18:24 -0600

Your proposed changes look fine to me. 

Mary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, January 10, 2006 7:03 AM
To: Barnes, Mary [RICH2:B601:EXCH]
Cc: [email-masked]; [email-masked]
Subject: RE: [Simple] WGLC: User Agent Capability Extension to PIDF
(prescaps)

Hi,

Thanks Mary for very detailed review. 
Comments inline:

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

Regarding the considerations for media feature tags ID only references
existing media feature tags and so I don't think that discussion should
be repeated.
I think we could add a sentence saying that if PUA is going to reveal
sensitive information about the presentity it should obtain permission
from the user.

Proposal:
"
If the PUA is publishing sensitive information using this extension, it
   SHOULD obtain a permission from a user.  
"

>- 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?

Ok, how about adding follow text:
"
 If such
   security measures are not used, eavesdroppers can learn sensitive
   information about the user.  It may be possible for a third party to
   modify the user's presence information.  This can lead to a situation
   that users receiving presentity's presence information can take
   incorrect actions based on false information.
"

>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))

Yes, makes it bit long but I am fine in adding it.

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

Ok, will do

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

ok

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

ok

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

Ok

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

ok

>- 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?)

If I remember correctly there was some time ago a discussion that we
should not use duplicate normative statements. This is already normative
in XML schema. Using MAY here would only duplicate that.

>- 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?  

Right, will be fixed

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

ok

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

ok

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

ok

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

ok

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

ok

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

ok

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

ok

>- 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?)

Yes, it should

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

ok

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

ok

- Mikko

>Mary

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

---

From: [email-masked]
Date: Fri, 20 Jan 2006 18:22:41 -0800

Hi All,

I just submitted the post-WGLC version. Until it appears in the
repository you can fetch a copy from...
HTML: http://free.x3.hu/krkiss/draft-ietf-simple-prescaps-ext-06.html
TXT: http://free.x3.hu/krkiss/draft-ietf-simple-prescaps-ext-06.txt
Hopefully we can start IETF Last Call with this version.

Cheers,
Krisztian 

>From: ext Mary Barnes [mailto:[email-masked]] 
>Sent: Thursday, January 12, 2006 10:18 AM
>To: Lonnfors Mikko (Nokia-TP-MSW/Helsinki)
>Cc: [email-masked]; Kiss Krisztian (Nokia-TP/SanDiego)
>Subject: RE: [Simple] WGLC: User Agent Capability Extension to 
>PIDF (prescaps)
>