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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 16 Apr 2003 01:40:11 -0400

My apologies for the incredibly long delay in responding; I missed this 
mail and just noticed it when I went to update the draft. Responses inline.

Cnaan Oded wrote:
> 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).

It does actually need to be read/write, since some of the operations 
that the client can perform involve pure reads. I updated the figure to 
show read/write.

> 
> 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.

That covers some cases, but not all.

One important use case is where I want to restric the specific event 
transitions on which I am sent a notification, but when I do get one, I 
want full information. As an example, I might want to only get 
notifications when your basic state changes, but when it does, I want to 
know about the status of your cell phone at that time, and any textual 
note associated with it.

Transformational policies also do not fit into your model, and these are 
very important, I believe.

> 
> 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.

This is a good point. I had a similar concern when writing up the seacap 
proposal. How about this requirement:

It must be possible for the presence collection to be integrated with a 
network resident address book. This means that there should be no 
duplication of data between the two, and only a single transaction 
should be needed to add or remove an entry from both.

This is sufficiently vague so as to allow a variety of implementation 
choices. I will note that it is not within our scope to actually specify 
schemas for network address books - merely that our protocols and 
schemas must allow for such a thing to occur.

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

Added this requirement:

It must be possible for a user to retrieve the list of
collections that they have created.

Note that a user may be able to subscribe to lists that they have not 
created. For example, I can create a list called tolkien-fans and set 
the permissions so that you can subscribe to it. The above requirement 
says that finding all such lists is not what we are talking about.

> 
> 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.

I agree. I added this as a requirement. Note that the schema that I 
proposed in the seacap draft allowed for both a unique handle and a 
display name in addition to the URI.

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

OK. I added this as an additional piece of requirement 5.

> 
> 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.

The fact that it can co-exist with others doesn't mean that the MUST has 
to be a SHOULD. Its just a MUST for SIMPLE.

> 
> 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.

All this requirement is saying is that it should be possible to set up 
an authorization policy which is symmetric. This does not mean that the 
policy has to be symmetric, just that it can be if thats what the user 
wants. I happen to think this will be a common case since it is easy for 
users to understand.

> 
> 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.

The scope of the draft is to cover the data manipulation requirements 
for SIMPLE-based systems. That includes both collections and 
authorization policy. These share some requirements, and it is our aim 
to use the same mechanism to solve both. Thus, having the requirements 
co-located seems natural.

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

I added a requirement for this.

I also added a requirement that the client can discovery the set of 
authorization policies that the server can support.

> 
> 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).

I am not sure what aspect of this requirement you want changed. All of 
the above is true, but doesn't change the underlyign requirement that 
you should be able to specify who sees which tuples.

> 
> 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.

This requirement is providing for an explicit way to say "this is my 
presence!".

> 
> 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.

THe answer is yes, and I think thats something that needs to be 
addressed in the collections draft, not in this requirements draft.

Thanks for your comments!

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[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