Subject: [Simple] updated presence-rules draft

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 09 Mar 2006 00:26:43 -0500

I've submitted an updated to the presence-rules draft. Until it appears 
in the archives, you can pick it up at:

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

The main changes are to align with the latest common policy and to fix 
bugs. I did a really thorough comb through the draft, doing detailed 
comparisons with rpid and common-policy to make sure everything was 
aligned. This review did pop out some bugs. The full set of changes is 
below.

One change I did NOT make, was to define a new MIME type for presence 
authorization documents. This had been suggested in some mail 
discussions over the last month or so, without clear consensus. I 
believe it is a mistake to try to define a new MIME type for presence 
rules separate from that of common policy. The reason is that I envision 
policy documents that contain rules from pres-rules, but also from other 
extensions to common policy. Indeed, consider geolocation. We have a 
mechanism for representing geolocatio in presence (pidf-lo), so one can 
imagine a presence document that contains BOTH geo-location and all 
kinds of RPID data, and one would want a SINGLE authorization document 
that provides rules covering both types of data. Its trivial to 
incorporate the policies in draft-ietf-geopriv-policy-08.txt into a 
pres-rules document. But, if each of these defines its own MIME type, it 
draws harder lines between them, and I think thats a mistake.

Another reason I didnt make the change is, we have discussed this in the 
past. Pres-rules has effectively been done for a while, and I'm loathe 
to change anything at this point unless its just broken. Changing MIME 
types to a pres-rules specific one is not fixing a bug, and thus I think 
we should avoid these kinds of design changes.

I believe this document is quite ready for WGLC (I dont think its had 
one?), and it makes sense to do that along with common policy which is 
going through its own WGLC now.

Here are the full set of changes:

* fixed bug reported on the list, which had the wrong repitition
values for provide-devices and provide-persons

* updated section on defining the XCAP usage; was missing some
required sections from xcap, and in particular, the default namespace
when used with xcap. THis default is
urn:ietf:params:xml:ns:pres-rules.

* aligned with XCAP on usage of the filename 'index' when there is a
single authorization document

* added back component-id and sub-handling to schema; somehow these
got accidentally deleted many versions back, though they were in my
version of the schema edited with xml-spy, they somehow didnt get into
the document. How this happened is a complete mystery to me.

* changed integral values of sub-handling to 0,10,20,30 instead of
0,1,2,3, to allow for new values to be inserted inbetween downstream.

* changed integral values of provide-user-input from 0,1,2,3 to
0,10,20,30 for the same reason

* changed <device-id> and <provide-device-id> to <deviceID> and
<provide-deviceID>, to sync up with the final conclusion on this in
the data model and rpid

* clarified that the provide-note permission applies only to the
top-level notes in person, device and tuple, NOT the notes embedded
within attributes themselves (such as <activities>).

* fixed broken example that wasnt compiling

* cleaned up some remnants of references to substitution groups in the
text; we eliminated those from the schema some time back

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

---

From: "Arjun Roychowdhury" <[email-masked]>
Date: Thu, 9 Mar 2006 11:35:08 -0500

The <sub-handling> part of this authorization I-D is very useful for
authorization of 'any state sharing' - not just presence.

My question, therefore, is that should the common-policy draft include, at
the least, some of the <sub-handling> clauses in its schema definition
instead of leaving it open for others to extend ? Or, the
presence-authorization draft makes its scope more general by saying the
draft applies to a wide variety of state sharing, not limited to presence
authorization.

Specifically, irrespective of what we choose to share, we need a mechanism
to specify authorization. Allow, Block, Confirm are fundamental actions. If
I choose to implement common-policy, it leaves an open area for 'action' -
and the only other draft I found which realizes 'action' is
'presence-authorization' which then says it is related to presence, whereas
I feel this should apply to a wider scope.
This only leaves the option of creating a new extension (which is not
necessary), or using 'presence-authorization's <sub-handling> ' spec which
is again, primarily motivated for 'presence sharing' .

regds
arjun

--
Arjun Roychowdhury