Subject: RE: [Simple] Comments on draft-ietf-simple-data-req-02.txt

From: [email-masked]
Date: Fri, 2 May 2003 20:51:00 +0300

Jonathan et al,

Please find below some comments on draft-ietf-simple-data-req-02:

- REQ PC-9 defines that a user could query for a "set of URIs" of a collection. I believe this kind of query should return all information available for the presentity collection in addition to the set of URIs. Additionally, the REQ should also define those users who are authorized to make this query. According to PC-10 and PC-11, there are already two kind of authorized lists defined, one list is for the users who are allowed to subscribe to the list, another list is for the users who are allowed to manipulate the attributes of the list. Probably the group of the users allowed to query equals to the group who are allowed to subscribe. One re-wording of the sentence could be as follows: "It MUST be possible for the authorized users allowed to subscribe to the list also to query for information of the particular presentity collection by providing the URI for the presentity collection."

-REQ PC-24: I am wondering about the justification for this REQ. It sounds rather an implementation issue instead of a requirement that would have effects on the final solution. It might cause unnecessary and additional complexity for the solution. To tell the truth, I am confused why the network resident address book has some special role here, if this is the case, we could also have REQs for other type of "collection kind of resources", e.g. presence access list, etc. Anyway, it'd good to have a more generic REQ instead, with a strength SHOULD instead of MUST.

-REQ AP-7: I believe there is no need for this requirement. In the requirement phase, the best would be to keep distinct roles for the different lists, the buddy list is for the presentity's own subscription purposes, the allowed and blocked lists are for authorization purposes.

-REQ AP-8: would be good to have more exact wording in the last sentence of the requirement. I guess the assumption here is that the meaning behind the "add, remove, modify, read, clear and create and delete" operations must be clear for the reader based on the PC requirements, however here we are talking about multiple lists, therefore it is unclear whether the remove, delete and clear operations are meant for the individual entries of a list, the list itself, or all the lists handled by the authorization policy. 

-REQ N1-5: all the notification requirements listed in chapter 5.2 are somehow "less important". If we can set "when" type of requirements (criteria when notifications are delivered to watchers) also to authorization, additionally to filtering, throttling and local server policies, we may end up having too complex rules about generating notifications.

-REQ C1-3: These requirements seem too specific and rather unclear. The first issue is why only the contact address and status are chosen as presence attributes that the user can set by authorization. Maybe a generic requirement would be enough saying that the authorized content could be specified by using any presence attribute. The second issue, which is rather important, if these requirements mean that after authorization the whole tuple including the attribute is omitted, or only the chosen attribute from the tuple. More clearly, is the aim to allow for the user to define which presence attributes to authorize within a tuple or rather to authorize tuples (i.e. what is the atomic element handled by the content policy)?

-REQ C-4: I guess it would be better to place this before C1-3. Assuming that the previous requirements were meant for selecting attributes within a tuple, this REQ seem to allow to select a whole tuple. Does this requirement allow any presence  attribute (e.g. one RPIDS extensions, tuple-id) to be used as a criteria for selecting the tuples?

-REQ C-6: this REQ sounds like one covering the delivery of default presence documents. I would prefer to mention here explicitly that DM is used for publication of the default presence document. Also, a strength of MUST would be better instead of the SHOULD. A rewording could be: It MUST be possible for the user to publish a presence document with default presence attributes. 

Additional requirements:

-REQ-PC-x: 
A requirement about storing an XML document including filtering information by using the data manipulation mechanism. This could be useful for presentity collections where different URIs of the collection could have either common or individual filter definitions pre-defined, and the watcher(s) would not need to include any filter information within the subscription.

-REQ AP-x: 
A requirement might be justified for the expected behavior of the acceptance policy when a watcher is part of several lists, e.g. multiple allowed lists. The policy could define, for example, an evaluation order for the lists, and the policy would stop evaluating the lists when the particular watcher is found. An alternative could be that the watcher cannot belong to several lists, however this does not sound feasible, especially if it is possible to use wildcards for defining URIs.

-REQ C-x:
A requirement, when the presentity authorizes different values of the otherwise same "data segment" to different watchers. One motivation here is the ability to give different level of details of information (e.g. w.r.t. location) to different watchers. Perhaps this is hidden behind some of the requirements, but it would be rather good to explicitly state it.
REQ C-5 covers this partly, however it makes a hint that new values of attributes are to be modified from existing values. By taking the geographical location information example, the difference between the information to be delivered to different watchers is only in the level of details. Therefore, there could be another approach that tuples would be assigned for the different level of details and authorization would be done based on some kind of "level of detail" attribute.

-REQ ?-x: 
Relation between the content requirements and the acceptance policy requirements are somehow undefined. When the acceptance policy results in accepting a watcher, then which content/notification requirements shall be applied, how and where this relation would be defined.

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