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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 25 Feb 2004 11:48:13 -0500

Thanks for the comments, Hisham. Responses inline.

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

In this case, it cannot. Either both would be seen, or neither.

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

Yes, it can include basic elements. In that case, you are right, it 
would either allow or exclude all notes, not notes based on specific 
position.

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

OK, I think that makes more sense; see my answers to your next question 
though.

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

Its because of the underlying processing model implied by the 
transformation section. The model is that each element defines a filter. 
That filter removes content from the presence document. The filters, for 
privacy reasons, tend to remove everything unless you tell it not to. By 
defining it this way, its possible for an implementation to operate on 
each of the transformation elements one at a time; the filtering 
behavior of one does not depend on whats in another. With what you 
propose, it would not be so. Even though the <rpid:placetype> is allowed 
in a show-element, show-namespace could not filter out elements by 
namespace without knowing that an element was still permitted by another 
transformation.

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

The rules don't union in this way; per the above model its more like 
intersection because of the filtering operations.

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

They are wrapped in a "choice", so they won't necessarily be there.

> - 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,…

No; the default xcap policy depends on whether the document is in the 
user tree or the global tree. For documents in the user tree, the policy 
is r/w only by owner. For documents in the global tree, its read all. I 
believe this policy makes sense for rules, which I think will generally 
be in the user tree.

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

OK, will change to service provider.

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

Meaning, it wouldnt be filtered, so it would remain in the document.

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

It cannot.

Based on some of your comments, it almost sounds like you would find a 
semantic-based match approach to be better. I'll send a separate note to 
the list about that.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 25 Feb 2004 11:48:13 -0500

?

It cannot.

-Jonathan R.