Subject: [Simple] new I-Ds on data manipulation

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 23 Feb 2003 12:33:54 -0500

Folks,

I've submitted an update to the data manipulation requirements spec. 
Until it appears, you can find it at:

http://www.jdrosen.net/papers/draft-ietf-simple-data-req-01.txt

There are a bunch of changes, most significantly is the removal of this 
whole script concept that was there before.

I've also worked on a protocol mechanism to meet these requirements. 
ACAP is a pretty good fit 
(ftp://ftp.rfc-editor.org/in-notes/rfc2244.txt), so I worked through how 
to do this with ACAP. The result is a spec which documents an ACAP 
"dataset class", as its called, which is really a schema for data. 
Besides meeting the requirements, it has some useful extension and 
capability discovery mechanisms that are valuable. I am pretty happy 
with it, and the acap data model was a pretty natural fit for this kind 
of thing.

As it turns out, ACAP as a protocol doesnt quite meet the requirements. 
So, the document propose to pursue a SOAP encoding of ACAP (which I've 
dubbed SEACAP), along with a new event package, to meet the 
requirements. The same dataset class would be used, and most of the 
semantics of acap too.

Until it appears in the archives, you can pick up a copy at:
http://www.jdrosen.net/papers/draft-rosenberg-simple-acap-data-00.txt
http://www.jdrosen.net/papers/draft-rosenberg-simple-acap-data-00.html

We need to determine if this is the direction we want the data 
manipulation work to go. If so, I will begin drafting the SEACAP details 
and the corresponding event package.

Time is pressing, since 3gpp deadlines are beginning to loom large...

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: Cnaan Oded <[email-masked]>
Date: Mon, 24 Feb 2003 10:33:32 +0200

Some comments on the new draft:

1. In the model depicted in figure 1, the "server" has only write access to
the DB which is of course a limiting approach (although it was probably set
only for the sake of the clarity).

2. The distinction between the 3 authorization policy types seems redundant,
as they can all be derived from a single piece of information. The client
should be allowed to choose which presence attributes are authorized for
each subscriber. In this case, the binary decision of whether subscription
is allowed is a direct derivation of whether there are authorized
attributes. Taking this one step further, the second piece of information
can also be expressed in terms of the specific attributes authorized for the
subscriber.

3. The draft assumes that all the items in the user's buddy list
(collection) are presentities, meaning, they have a designated ID (URI) that
can be used to subscribe to their presence. However, a more general approach
would be to treat this collection as an address book which MAY contain also
non-presentity items (e.g., someone with only a street address). Note that
this approach is supported by most handsets today.

Following this approach, items in the collection should be associated with
meta data, maybe in the form of a vCard.

If we look ahead to the point where there would be a NAB (Network address
book), Presence server and a PAC in the network, this draft doubles the
information and transactions as all manipulations should be performed on
both the NAB and PAC. The generalized approach would create a single entity
that handles collections from all aspects.

This generalization should not affect subscriptions made on these
collections, as only those who are associated with an ID (URI) will be
treated by the presence server.

4. I suggest adding a req. to allow clients to retrieve the list of
collections (their URIs).

5. It seems that associating a display name with a collection (as well as
with any other item) would be very beneficial for users to handle them. Note
that in real implementations, users will probably not be required to even
know the SIP URI of these collections.

6. It must be possible to distinguish between a collection and an
non-collection item.

7. REQ 17 (section 4) seems too harsh. I suggest changing MUST to SHOULD as
this mechanism may co-exist with non-SIMPLE platforms as well.

8. REQ 9 (section 5.1) implies that having someone in my buddy list (meaning
that I see his presence) means that he should also be granted access to my
presence. Fortunately, Presence authorization is not symmetric and this
requirement should be deleted.

9. The draft seems to mix between block lists (which are presence server
entities) and collections. I believe that requirements associated with block
list should be removed from this draft and be specified in a separate draft.
Another approach would be to add block list requirements to this draft.

10. It MUST be possible to extend the information associated with each item
and/or collection.

11. REQ 4 (section 5.3): tuples may represent different 'views' (or schemes)
of the presence information and this draft does not relate to the question
of tuple types. Moreover, users have no idea what tuples are. Users should
be able to manipulate information and it's up to the server to compose their
presence document using tuples. Note that users (and clients) may not be
aware of the way their tuples are composed and published to other watchers.
Note also that the composition into tuples may be influenced by the
SUBSCRIBE request (e.g., SUBSCRIBE to get all service / devices etc. that
follow a certain filter).

12. REQ 7 (section 5.3): there are cases where users may not be aware of the
document generated for them by the presence server. They may influence the
attributes and values but not the way they are composed into a presence
document.

13. The draft specifies that subscriptions may be based on collection URIs
but it does not define whether these subscriptions are persistent. In other
words, when I subscribe to a collection and then add another item to it,
should it be automatically subscribed as well? The same applies to deleting
items and un-subscribing.

Oded Cnaan

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Sunday, February 23, 2003 7:34 PM
> To: [email-masked]
> Subject: [Simple] new I-Ds on data manipulation
> 
> 
> Folks,
>

---

From: [email-masked]
Date: Thu, 27 Feb 2003 18:44:26 +0200

Hi,

Thanks for the SEACAP draft, Jonathan.

First, some general comments:

ACAP seems to be a reasonable fit to the data manipulation problem. If it is chosen as a baseline, I support doing the SOAP encoding + SIP event package for notifications for the purposes listed in the draft. Having to maintain a long lived TCP connection is not a preferable solution. Ability to run through intermediaries may be important in some cases. While agreeing on one protocol is important, I would still like to analyse SyncML as an alternative solution. Data manipulation will mostly be needed in wireless terminals, and there SyncML is getting widely deployed. SyncML also seems to be applicaple in this problem space. Of course it is not an IETF protocol, it is currently developed within the Open Mobile Alliance (OMA). But I think it would be sad to leave it out based on this kind of argument - anyway, SOAP is not IETF either.

My proposal would be to do as has been done in some cases already. Assign a deadline for proposals (I'm not expecting there would be too many), and based on them do the selection. If no other proposals appear by the deadline, let's do SEACAP (assuming there are no major technical problems with it). We are planning to evaluate SyncML based on SEACAP, and can submit a draft for the agreed deadline, whether its use is really feasible, and if yes, how the solution would look like. A deadline sometime in April would still not delay this work considerably. (A similar approach was taken for messaging sessions last year. Basically that resulted IMHO in a somewhat messy situation, so I hope this time it would be more clear.) 

Then some technical comments:

* Authorizations based on filters (Section 3.2.2.2.1 and 3.2.2.2.2)
I have to say I don't really understand the need for some of the attributes. As I understand it ReqStatus, ReqTuples and OnEvent.Filter are related to filters in SUBSCRIBE body. I don't see it necessary to use filters as a requirement for accepting/rejecting a subscription. As I see it a filter always somehow reduces either the number or content of notifications. If I approved a subscription without a filter, I should thus always approve it with a filter. If I only wanted to give part of my tuples, I could use Content Attributes instead of approving it with a correct filter only. This way I could easier hide from a particular watcher that I have some extra information not shown to him.
=> My proposal would be simply to leave them out.

* Notification & Content Attributes vs. Filtering
The draft defines these attributes on the ACAP dataset level, and basically restricts the decisions on a limited set of PIDF attibutes, such as contact, tuple label, status type and status value. A more flexible way would perhaps be just to have a single attribute on ACAP level, which contains similar type of XPath expressions as defined in http://www.ietf.org/internet-drafts/draft-khartabil-simple-presence-filter-00.txt. In this way the ACAP structure would be very simple and would need no updates based on new reqs on attributes that authorization would like to use.
=> My proposal is to pursue this latter way (as speculated in the draft), obviously this requires that the solution is chosen for filtering in the first place. Also I think the relation between notifiation and content attributes shuould be clarified, as proposed in the  editor's note in Chapter 3.2.2.2.2. This comment applies to filters in SUBSCRIBE as well.

* Transformational attributes vs. the real needs
There is a requirement (at least in 3GPP), that the presentity should be able to authorize different values of the otherwise same "data segment" to different watchers. One motivation is the ability to give different level of detail (e.g. w.r.t. location), the other simply to allow the possibility to - well, mislead. I think the current transformational attributes help in this, but don't solve it well enough. The solution I have in mind is that there would really be separate tuples, out of which only one is given to a particular watcher based on authentication rules. Maybe using different labels and authorizing them separately would be sufficient. In this case I'm not sure whether there are other specific needs for the transformational attributes. BTW, are we going to allow transform requests in the SUBSCRIBE filters? I don't see this necessary.    

I like the derived permissions and authorization capabilities dataset classes.

One question: Would it be possible to use somehow the same list of "entities" for both presence list and for authorization. OnList attribute seems to point to this direction, but perhaps the better way would be to inherit from some commonly usable dataset ("generic list"). I don't know whether this could be done in ACAP. From users point of view it would make sense. Sharing groups among apps is quite valuable.

Regards,
	Markus

> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 23 February, 2003 19:34
> To: [email-masked]