Subject: [Simple] Review of draft-ietf-simple-event-list-01

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Apr 2003 18:11:37 -0400

I just did a review of draft-ietf-simple-event-list-01. In general this 
looks pretty clean. I found some minor typos and wording problems, plus 
a couple of slightly larger issues. I've listed all of these below. I 
scanned the xml schema but claim no expertise with xml, and I admit I 
only checked that the example seemed consistent with the text - I didn't 
check all the sip details.

	Paul

 > 1. Introduction

 > "The notifier for the collection is called a "resource list server",
or RLS. In order to determine the state of the entire list, the RLS
will act as if it has typically generated a subscription to each
resource in the list."

Last sentence seems awkward. Suggestion:

s/act as if it has typically/typically act as if it has/

In the following paragraph a typo:

s/contstrained/constrained/

 > 2. Overview of Operation

 > "When a user wishes to subscribe to the resource of a list of
resources, they create ..."

s:they create:he/she creates:

 > "Typically, the user who creates the list (and subsequently 
subscribes to it) will have a trust relationship with the domain that 
hosts the list."

This implies that the users creating the list and subscribing are the 
same, which need not be true. I suppose both uers have trust 
relationships with the server, but for different things. The creator 
trusts that the list will be maintained, and perhaps that its access be 
limited. The subscriber trusts that the RLS will return notifications 
consistent with the list content.

I'm not sure how to convey all this concisely. I'm not sure it is 
necessary to say anything here about a trust relationship.

 > "This document uses the term "back-end subscription" to
refer to such a subscription, regardless of whether SIP is used to
establish and service them."

In the rest of the doc the term "virtual subscription" seems to be used 
rather than "back-end". Either would do as long as used consistently.

Same paragraph, last word should be "it" rather than "them".

 > 3. Operation of List Subscriptions

 > "A list subscription acts, in many ways, like an event template
package. In particular, ..."

I found this confusing. How can a subscription act like an event 
template package? Subscriptions result in NOTIFYs. Package templates 
just sit there and wait to be instantiated. And you can't even subscribe 
to an event template package, so that isn't what you mean. I think you 
can just leave this out.

 > "In particular, any single list subscription MUST be
homogenous with respect to the underlying event package. In other
words, a single list subscription cannot contain subscriptions to
different kinds of event packages."

The MUST is moot, because there is no way to violate it.

However, in principle, the same list could be the target of 
subscriptions for different event packages. I think this is worth 
pointing out.

I don't know if it is expected that an RLS should be able to 
transparently handle subscriptions to lists regardless of the requested 
event type. Superficially it seems that this should be possible. But 
there are little things, like how to handle forking, that differ by 
event type and which might require the RLS to be aware of the semantics 
of specific event types in order to support them properly.

How about the following as a replacement for the whole paragraph:

"Event lists are not specific to a particular event package. A 
particular subscription to an event list is always to a single 
underlying event package specified by the subscriber. A particular RLS 
MUST support subscriptions to at least one event type, and MAY support 
subscriptions to multiple event types."

 > "The key difference between a list subscription and templates in
general is that support for list subscriptions indicates support for
arbitrary nesting of list subscriptions. In other words, elements
within the list may be atomic elements, or they may be lists themselves."

This seems to be a reference to prior failed attempts to define event 
lists. It is now just water over the dam and seems irrelevant to this 
document. I suggest dropping the paragraph.

 > "It is important to keep in mind that these virtual subscriptions are
not literal SIP subscriptions (although they may result in SIP
subscriptions, depending on the RLS implementation)."

This is a little too strong because they *could* be literal 
subscriptions. I suggest

s/not literal/not necessarily literal/

 > 3.2 Subscription Duration

 > "Since the primary benefit of the resource list server is to reduce
the overall messaging volume to a handset,"

I realize that cell phones provide a significant use case for this 
feature, but they aren't the only beneficiaries. I suggest replacing 
"handset" with "subscriber".

 > 3.6 Subscriber Processing of NOTIFY Requests

 > "The XML document present in the root of the multipart/related
document contains a <resource> element for each resource in the list."

This isn't true when "fullState" is false, as explained later in this 
paragraph. So I think this sentence must be relaxed to something like:

"The XML document present in the root of the multipart/related
document contains <resource> elements for some or all resources in the 
list."

 > 4.1 XML Syntax

 > "The root document of the multipart/related body is always a Resource
List Meta-Information (RLMI) document. It is of type "application/
rlmi+xml".

This is slightly limiting. It doesn't permit the possibility that there 
might be other formats for this information in the future, e.g. an RLMI_ng.

The use of "is" sounds normative, though it presumably is not. To go 
with the informal but almost normative style, how about:

"The root document of the multipart/related body should be a Resource
List Meta-Information (RLMI) document. It is of type "application/
rlmi+xml".

 > 5. Example

 > "1. We initate the subscription by sending a SUBSCRIBE message to
our local RLS. (There is no reason that the RLS we contact has
to be in our domain, of course). Note that we must advertise
support for application/rlmi+xml and multipart/related because
we support the eventlist extension, and we must advertise
application/cpim-pidf+xml because we are requesting a
subscription to a list."

The reference to "subscription to a list" at the end of this paragraph 
seems wrong. I think you mean "subscription to presence".

 > "6. The Presence Server in example.net completes the SUBSCRIBE
transaction. Note that authentication and would normally take
place ..."

The "and" is inappropriate.

Other than these relatively minor things I think this is ready to ship.

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