Subject: [Simple] Comments on draft-ietf-simple-event-list-00

From: "Sean Olson" <[email-masked]>
Date: Mon, 24 Mar 2003 23:29:54 -0800

Comments on draft-ietf-simple-event-list-00:

1) Here is a slightly cleaned up XML schema:

<?xml version="1.0" encoding="utf-8" ?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:rlmi" 
           elementFormDefault="qualified" 
           xmlns="urn:ietf:params:xml:ns:rlmi" 
           xmlns:xs="http://www.w3.org/2001/XMLSchema">
   <xs:element name="list">
      <xs:complexType>
         <xs:sequence>
            <xs:element ref="resource" minOccurs="0" maxOccurs="unbounded"
/>
         </xs:sequence>
         <xs:attribute name="uri" type="xs:anyURI" use="required" />
         <xs:attribute name="version" type="xs:unsignedInt" use="required"
/>
         <xs:attribute name="fullState" type="xs:boolean" use="required" />
         <xs:attribute name="name" type="xs:string" use="optional" />
         <xs:anyAttribute />
      </xs:complexType>
   </xs:element>
   <xs:element name="resource">
      <xs:complexType>
         <xs:sequence>
            <xs:element ref="instance" minOccurs="0" maxOccurs="unbounded"
/>
         </xs:sequence>
         <xs:attribute name="uri" type="xs:anyURI" use="required" />
         <xs:attribute name="name" type="xs:string" use="optional" />
         <xs:anyAttribute />
      </xs:complexType>
   </xs:element>
   <xs:element name="instance">
      <xs:complexType>
         <xs:sequence>
            <xs:any minOccurs="0" maxOccurs="unbounded" />
         </xs:sequence>
         <xs:attribute name="id" type="xs:string" use="required" />
         <xs:attribute name="state" type="xs:string" use="required" />
         <xs:attribute name="reason" type="xs:string" use="optional" />
         <xs:attribute name="cid" type="xs:string" use="optional" />
         <xs:anyAttribute />
      </xs:complexType>
   </xs:element>
</xs:schema>

NOTE: You will probably want to add an IANA registration for the XML
namespace
(urn:ietf:params:xml:ns:rlmi) similar to the one found in the CPIM-PIDF
draft

I've thrown in anyAttribute in a couple of spots as well as the any element
for the <instance>
element definition.

2) Why do you allow a list with 0 resource elements? I could not think of a
use case for this.
   (If there is no reason, the schema should be changed to have a minOccurs
of 1)

3) It would be nice to pass along a preference to disable forking of event
packages that
   support it. I'm assuming a Request-Disposition: header ala caller prefs
would be sufficient. This 
   seems more critical for the RLS than for the subscriber. Is it reasonable
for the RLS to request
   non-forking of the resource SUBSCRIBEs even if the initial subscriber did
not?

4) In the event that one of the resource subscriptions from the RLS gets
terminated, the subscriber
   does not seem to have any option but to un-SUBSCRIBE and re-SUBSCRIBE in
the hope of refreshing the
   resource subscription. Is there another way?

5) One of the problems that was given as motivation for the draft in the
Introduction:

   o  If a subscriber has only intermittent connectivity, and generally
      polls for state rather than simply subscribing, the latency to
      obtain the state of the entire resource can be large.  The
      messaging required for each poll can also be substantial.

   does not seem to be solved by this mechanism. If connectivity is
intermittent, how would an RLS help?
   How would an RLS reduce the state of the resource notification (other
than through the use of partial
   notifications and filtering that can be applied for a non-list
subcription as well)?

6) The specification of a charset parameter in the Content-Type seems
redundant for the XML payload. 
   For example:

   Content-Type: application/rlmi+xml;charset="UTF-8"

   <?xml version="1.0" encoding="UTF-8">

   (Just a small nit)

cheers,
sean

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

---

From: Ben Campbell <[email-masked]>
Date: 25 Mar 2003 15:57:24 -0600

On Tue, 2003-03-25 at 01:29, Sean Olson wrote:

[...]

>    (If there is no reason, the schema should be changed to have a minOccurs

I can imagine an empty list existing. For example, a provisioned list
that has not yet had entries added, or one where all the entries have
been deleted. For example, I might get a brand new account from a
service provider, and subscribe to my contact list that is initially
empty. As I add contacts to the list, possibly through some other
interface, my client gets NOTIFY requests telling it about the new
entries.