Subject: [Simple] Comments on draft-rosenberg-simple-rules-00.txt

From: [email-masked]
Date: Thu, 19 Feb 2004 17:23:55 +0200

- Section 3.3.3 talks about Show elements and the "el" element. It says that an el element contains a string that identifies an XML element:

   o What if there are 2 elements with the same name under the same namespace? Something like:
     </ns1:element1>
        <ns1:element2>
           <ns1:element1/>
        </ns1:element2>
     </ns1:element1>

   How can a presentity set which one to he wants the transformation to apply to?

- Can an el element include any of the basic elements? That's not clear from the text. If so, then the question above applies to the note element since it can appear more than once.

- Section 3.3.3 also mandates that "show-element" transformation contains elements that make the resulting presence document valid. I'm not sure what that means. Why rely on the client to do that. The server should be smart enough to include those mandatory elements. eg:

If a presentity put this as a transformation rule

   <show-element>
      <rpid:placetype/>
   </show-element>

Then I think the server should be smart enough to know that it has to include the basic-elements in order to make the resulting document valid. Better interoperability.

- Section 5 also has a similar thing where it states that the show-namespace element defining rpid needs to be there? Why? why isn't <rpid:placetype/> enough?

Also, doesn't show-namespace defining the rpid ns mean show everything in that namespace making <rpid:placetype/> redundant if you use the union of the rules?

- Section 4: The schema seems to mandate the all-ns, ns, all-tuples and others by not defining them with minOccurs="0". Was that intentional? I think they all are optional.

- Section 6.5 says it does not modify the default xcap authorization policy, which is that only user can read, write or modify their own documents. Now, I have not read the new base xcap document, but I read from your post on the mailing list that the read right is global therefore requiring this document to modify the default authorisation policies if the read right is only to the creator.

Some nits:

- Introduction says: 

"Typically, the authorization decision will be a combination of the
   authorization policies of the provider, combined with the
   authorization policies of the presentity."

Maybe it should say service provider (I originally thought you meant the provider of the rules).

- Section 3.3.2 says:

"If a tuple does not contain a
   class element, it is not subject to filtration by the "show-tuple"
   transformation."

Does that mean it is not shown? What does "not subject to filtration" means?

Also, how can a presntity select tuples to show if they don't have the class element?

/Hisham

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