Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-presence-rules-02.txt (comments)

From: [email-masked]
Date: Thu, 7 Jul 2005 11:15:32 +0300

Hi,

I'd have some (most of them just editorial) comments to the presence-rules draft (from February) as follows.

The draft is not consistent with the <provide-persons> element; both the <provide-persons> and <provide-person> have been used.

In the subsection 3.3.1.2 (person information) "<all-devices>" should be replaced by "<all-persons>". Also, "<provide-person>" should be replaced by "<provide-devices>" in the sentence "The set combination is done identically to the <provide-person> element.". The same applies also to the corresponding sentence in the 3.3.1.3.

The draft uses "the <class> of the x instance" or "the <class> element", which should rather be "the <service-class> of the x instance" or "the <service-class> element".

The default value of the component ID (3.3.2.14) has been defined to be "obfuscate" for the <device-id> and <contact>. Basically this is correct function from the authorization point of view, but it is unclear, which kind of additional functionality is required from the PS and/or core network to fulfill the "routing" requirement? (The drafts states that the service URI must still be routable.)

The Provide All Attributes (3.3.2.16) subsection lists only the <provide-x> elements, which have been defined in this draft (including the <provide-unknown-attribute>), to belong to <provide-all-attributes>, but also states in the first sentence that "all presence attributes in all of the person etc. elements". It was a bit unclear how this should be interpreted? Does this concern also possible future IETF and propriotary extensions of the authorization rules providing access to certain presence attributes or only the listed permissions?  Does the "all of person etc. elements" mean that _all_ person, device and tuple elements are granted or only the separately "identified" person, device and tuple elements (the identification being done by <provide-tuples> etc.) - I'd assume that the latter one?

About the <provide-unknown-attribute> in the example document: would it be possible to change the "foo" to be a qualified element name?

Thanks, Eva Leppanen

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext [email-masked]
> Sent: 23 February, 2005 22:59
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-rules-02.txt
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-simple-presence
> -rules-02.txt
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 19 Jul 2005 04:57:14 -0400

Thanks for the comments. More inline.

[email-masked] wrote:

> Hi,
> 
> I'd have some (most of them just editorial) comments to the
> presence-rules draft (from February) as follows.
> 
> The draft is not consistent with the <provide-persons> element; both
> the <provide-persons> and <provide-person> have been used.

Fixed. Should all be provide-persons.

> 
> In the subsection 3.3.1.2 (person information) "<all-devices>" should
> be replaced by "<all-persons>". Also, "<provide-person>" should be
> replaced by "<provide-devices>" in the sentence "The set combination
> is done identically to the <provide-person> element.". The same
> applies also to the corresponding sentence in the 3.3.1.3.

All fixed.

> 
> The draft uses "the <class> of the x instance" or "the <class>
> element", which should rather be "the <service-class> of the x
> instance" or "the <service-class> element".

I believe this is right as written. It is referring to class, not 
service-class. Both are defined in rpid.

> 
> The default value of the component ID (3.3.2.14) has been defined to
> be "obfuscate" for the <device-id> and <contact>. Basically this is
> correct function from the authorization point of view, but it is
> unclear, which kind of additional functionality is required from the
> PS and/or core network to fulfill the "routing" requirement? (The
> drafts states that the service URI must still be routable.)

I have removed component-id, largely because its non-trivial to 
accomplish this.

> 
> The Provide All Attributes (3.3.2.16) subsection lists only the
> <provide-x> elements, which have been defined in this draft
> (including the <provide-unknown-attribute>), to belong to
> <provide-all-attributes>, but also states in the first sentence that
> "all presence attributes in all of the person etc. elements". It was
> a bit unclear how this should be interpreted? Does this concern also
> possible future IETF and propriotary extensions of the authorization
> rules providing access to certain presence attributes or only the
> listed permissions? 

All future ones that might be present. I've clarified thta.

  Does the "all of person etc. elements" mean that
> _all_ person, device and tuple elements are granted or only the
> separately "identified" person, device and tuple elements (the
> identification being done by <provide-tuples> etc.) - I'd assume that
> the latter one?

The latter. Also clarified.

> 
> About the <provide-unknown-attribute> in the example document: would
> it be possible to change the "foo" to be a qualified element name?

Right - fixed.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com