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

From: Adam Roach <[email-masked]>
Date: Tue, 25 Mar 2003 17:05:01 -0600

Sean Olson [mailto:[email-masked]] writes:

> Comments on draft-ietf-simple-event-list-00:
> 
> 1) Here is a slightly cleaned up XML schema:

Excellent. Thank you.

> 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

Added.

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

I don't know offhand what these mean, but assume they afford some
degree of extensibility. That seems good.

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

You get notifications when a resource is added to or removed
from a list. If the last member is removed from a list, the
way to express that is to send meta-information which contains
no resources.

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

Instructing forking proxies not to fork is a more general SIP
problem that we can't solve here.

> Is it reasonable
> for the RLS to request
>    non-forking of the resource SUBSCRIBEs even if the initial 
> subscriber did
> not?

The way that RLSes handle back-end subscriptions is completely
their own business. If they want to shut down multiple legs
just because they feel like it, that's fine (as long as it
doesn't contravene any normative language in the corresponding
event package).

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

Once again, the way that an RLS handles any back-end
subscriptions is its own business, but I would argue that
any implementation that didn't keep such subscriptions
alive for as long as possible (e.g. performing appropriate
recovery when they terminated) is poorly designed.

I would certainly *not* recommend having a client re-subscribe
to try to clear such a case.

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

You can poll. This works exceptionally well if the RLS also hosts
the resources (as will often be the case in networks exhibiting
this behavior).

Because you're only having to poll the list instead of each
individual resource, you do end up having a savings in
overhead that can be considerable for a large list.

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

RFC 3023 recommends inclusion of the charset parameter on
Content-Type headers for XML body types:

      Although listed as an optional parameter, the use of the charset
      parameter is STRONGLY RECOMMENDED, since this information can be
      used by XML processors to determine authoritatively the character
      encoding of the XML MIME entity.
...
      Conformant with [RFC2046], if a text/xml entity is received with
      the charset parameter omitted, MIME processors and XML processors
      MUST use the default charset value of "us-ascii".

As I read it, omission of a "charset" parameter on the "Content-Type"
header would *override* any internally-contained "encoding" attribute
with "us-ascii". Certainly not what we want.

Should I include a discussion of this topic in the lists draft?

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

---

From: Sean Olson <[email-masked]>
Date: Tue, 25 Mar 2003 15:38:16 -0800 (PST)

> overhead that can be considerable for a large list.

I guess I was confused because it seems like polling
with an RLS can (depending on the implementation of
the RLS) be somewhat useless. The draft alludes to 
this at one point.

[snip]
> Should I include a discussion of this topic in the

Nope. Your answer makes it clear why this is needed
and desirable. Thanks!

> /a

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple