Subject: [Simple] Updated presence-rules draft

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 22 Oct 2006 21:42:10 -0400

I've updated the presence-rules draft based on AD feedback, and also 
including the fix we discussed at the last meeting to address our 
decision to abandon the presence-policy-caps documents. Until the draft 
appears in the archives, you can pick it up at:

http://www.jdrosen.net/papers/draft-ietf-simple-presence-rules-08.txt

The changes are:

* clarified the reasoning why anonymous digest doesn't count as
   authenticated, but anonymous RFC 4474 does. Text says:

<t>
An anonymous From header field with RFC 4474 <xref target="RFC4474"/>
is considered authenticated, while anonymous digest is not considered
authenticated, because the former still involves the usage of an
actual username and credential as part of an authentication operation
in the originating domain.
</t>

* a bug was identified in extensibility for the sub-handling
   element. The text says you an extend it with new values, but this is
   contradited by the schema (which doesnt allow that) and the
   guidelines on extensibility. Consequently, I removed the offending
   text which says that the values for sub-handling are extensible. THe
   text says instead:

<t>
Future specifications that wish to define new types of actions MUST
define an entirely new action (separate from &lt;sub-handling&gt;),
and define their own set of values for that action. A document could
contain both &lt;sub-handling&gt; and a subscription handling action
defined by a future specification; in that case, since each action is
always a positive grant of information, the resulting action is the
least restrictive one across both elements.
</t>

* mention in section 4 that a user can have multiple authorization
   documents and that the rules for their composition are in the
   geopriv common policy spec

* mention in security considerations section the privacy properties of
   authorization documents:

<t>
Authorization documents themselves exist for the purposes of providing
a security function - privacy. The SIP presence specifications <xref
target="RFC3856"/> require
the usage of an authorization function prior to the granting of
presence information, and this specification meets that
need. Presence authorization documents inherit the privacy properties
of the common policy format on which they are based. This format has
been designed to be privacy-safe, which means that failure of the
presence server to obtain or understand an authorization document can
never reveal more information than is desired about the user, only
less. This is a consequence of the fact that all permissions are
positive grants of information, and not negative grants.
</t>

* based on the discussions last IETF, with the decision to drop
   xcap-policy-caps, we had a need for an alternate way for the client
   to know the capabilities of the server. It was decided to handle
   this by including the namespaces for the permission extensions known
   by the presence server, in the list of supported capabilities in the
   xcap-caps document. I've added a paragraph in the schema
   extensibility section which describes this:

<t>
When extensions are made to the set of permissions, it becomes
necessary for the agent constructing the permission document
(typically a SIP user agent, though not necessarily) to know which
permissions are supported by the server. This allows the agent to know
how to build a document which results in the desired behavior, since
unknown permissions would be ignored by the server. To handle this,
when presence authorization documents are transported using XCAP, the
XCAP capabilities document stored at the server SHOULD contain the
namespaces for the permissions supported by the presence server. This
way, an agent can query for this list prior to constructing a
document.
</t>

* updated references with published RFC, removed reference to
   xcap-policy-caps

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