Subject: [Simple] Re: Few more comments to presence-rules-06

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 09 Jun 2006 11:25:15 -0400

inline.

[email-masked] wrote:
> Hi,
> 
> I traversed the presence rules draft 06 once again and I found few
> issues there.
> 
> - In section 3.1.1.2 there is last paragraph noticing usage of TEL URI
> and SIP URI for one user. There is bug in first combination of URIs
> starting "A WR identity .."
>   SIP with phone to SIP but should be SIP with phone to TEL
>   in the reverse direction I would prefer to mention SIP URI with the
> phone number instead of pure SIP URI

fixed.

> 
> - In section 3.3.2.14 third paragraph first sentence. 
> "Another consequence of this definition is that the interpretation of
>  the <provide-unknown-attribute> element can change should the
>  presence server be upgraded with a new schema that defines
>  authorization rules for elements included in a <provide-unknown-
>  attribute>."
> This sentence makes me really confused and I can't catch the idea.

OK, I tried to clarify. The document now says:

<t> Another consequence of this definition is that the interpretation
of the &lt;provide-unknown-attribute&gt; element can change should the
presence server be upgraded. For example, consider a server which,
prior to the upgrade, had an authorization document that used
&lt;provide-unknown-attribute&gt; for some attribute, say foo. This
attribute was from a namespace and schema unknown to the server, and
so the attribute was provided to watchers. However, after upgrade, the
server is now aware of a new namespace and schema for a permission
that grants access to the foo attribute. Now, the
&lt;provide-unknown-attribute&gt; permission for the foo attribute
will be ignored, resulting in a removal of those elements from
presence documents sent to watchers. The system remains privacy safe,
but behavior might not be as expected. Developers of systems which
allow clients to set policies are advised to check the capabilities of
the server, (using mechanisms like those defined in <xref
target="I-D.ietf-simple-pres-policy-caps"/>, for example) before
uploading a new authorization document, to make sure that the behavior
will be as expected.  </t>

> 
> Other issues are moreless cosmetic
> - First paragraph of 3.1.1.2 contains "can can" sequence

fixed

> - Last paragraph of 3.2.1 contains "is is" sequence

fixed

> - In section 3.3.2 there is used <timestampt> element

fixed

> - Permission definitions are in form: there is permission XXX realized
> by element <XXX>. But provide unknown attribute permission violates this
> convention. Similar deviation is in 3.3.2.15.

I don't follow; all permissions are of the form <provide-XXX> for 
various XXX.

> 
> 
> In addition, what was the reason to change <provide-device-id> to
> <provide-deviceID>? It somehow breaks the conventions of provide-xxx
> elements.

No - because in the data model draft the attribute is <deviceID> so its 
permission is <provide-deviceID>.

Thanks,
Jonathan R.

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

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