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

From: [email-masked]
Date: Tue, 10 Jan 2006 15:02:38 +0200

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: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Jan 2006 09:29:46 -0500

>>apply to the use of these feature tags in the PIDF?

They don't.

The security considerations in 3840 really speak to the various contexts 
in which callee capability feature tags, attached to Contact headers, 
may move around in SIP messages.

There really is no meaningful discussion of the security issues of any 
particular feature tag - just a general discussion of treating all 
feature tags in the aggregate as sensitive data.

In the context of the current draft, the feature tags of 3840 become 
generalized presence elements. There are already sufficient security 
considerations regarding the sensitive nature of presence data in 
general. I don't see how adding more generalities would be helpful. IMO, 
taken as a whole, the prescaps elements cannot be said to present any 
new issues over the elements introduced in RPIDS.

This is complicated by the fact that PIDF and its extensions is simply a 
data format that may be used in many places. One can start to enumerate 
those places (e.g. PUBLISH and NOTIFY) but the list will always be partial.

I believe the security considerations regarding presence information 
should be dealt with as a whole, not piecemeal.

	Paul