Subject: [Simple] Comments of draft-ietf-simple-event-list-01.txt

From: [email-masked]
Date: Thu, 3 Apr 2003 16:07:09 +0300

- Section 1:
* First paragraph of 3rd last could mention that the list subscription is for the same event package.

- Section 3.1
* Second paragraph says: "Any client that supports the event list extension will include an option tag ...". Should the "will" be changed to a "SHOULD/MUST"?
* In the same paragraph: "...the RLS will include "eventlist" in a "Require" header...". Should the "will" be a "MUST"?
* The same paragraph also talks about how NOTIFY messages will contain the require-header. Why is that necessary? Some justification text should be added.

- Section 3.5
* Paragraph 5 say that an instance of a resource may be terminated. How can a subscriber try again to subscribe to this resource? Especially if the subscriber has subscribed to a list with a very large expire value (weeks). The subscriber will not get the chance to resubscribe to this resource again. Should a SUBSCRIBE refresh cause the RLS to refresh its subscriptions and also try to resubscribe to the terminated ones? Or should the RLS try resubscribing to terminated subscriptions at a pre-defined interval? or is all this an implementation issue?

- Section 3.6 (and other relevant sections)
* I suggest changing the "fullstate" attribute name to something like "full-list", because that's what it really is. You also need to clarify that partial state means that a subset of the resources are present in the NOTIFY, and that it doesn't mean that the state of each resource is partially presented. Actually, I'd suggest not using the word "state" at all in this context in this section and any subsequent section. "list" is sufficient enough word.

- Section 3.9
* What is the purpose of this section? Most of the text in it is just a repeat of text in section 6.1

- Section 4
* First paragraph says: "In order to convey the state of multiple resources, the list template package uses the "multipart/related" mime type". Its not a list template package anymore, its a eventlist package :)

- Section 4.2
* 3rd paragraph talks about the version attribute increasing with every NOTIFY. Does it get reset to 0 with a SUBSCRIBE refresh?
* 4th paragraph: Should there be some text specifying error handling by the subscriber when the "fullstate" in not communicated in the first NOTIFY?

- Section 4.5
* First, the section talks about flushing the table, then it talks about how a new row in the table is created for each resource element in the fullstate NOTIFY. It says:

   The processing of the resource list notification depends on whether
   it contains full or partial state.  If it contains full state,
   indicated by the value of the <list> attribute "fullstate", the
   contents of the resource-list table are flushed.  They are
   repopulated from the document.  A new row in the table is created for
   each "resource" element.   

   First, a check is made to ensure that no list notifications have been
   lost.  The value of the local version number (the "version" attribute
   of the <list> element) is compared to the version number of the new
   document.

   o  If the value in the new document is exactly one higher than the
      local version number, the local version number is increased by
      one, and the document is processed, as described below.

   o  If the version in the document is more than one higher than the
      local version number, the local version number is set ...

So, which is first? or does the second paragraph above talk about subsequent NOTIFYs after the SUBSCRIBE or refresh? eg: the first bullet talks about comparing version numbers. How can I do that when I've already flushed the table? I got really confused reading this text.

- Section 5
* Last word in the step 1 should be "presence" instead of "a list".

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

---

From: Adam Roach <[email-masked]>
Date: Wed, 23 Apr 2003 21:28:27 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> 
> - Section 1:
> * First paragraph of 3rd last could mention that the list 
> subscription is for the same event package.

I'm not quite certain that belongs in the introduction.

> - Section 3.1
> * Second paragraph says: "Any client that supports the event 
> list extension will include an option tag ...". Should the 
> "will" be changed to a "SHOULD/MUST"?

No. This sentence is not describing normative behavior,
as indicated by the preceding paragraph. All it is doing
is providing a non-normative clarification of what it means
to apply RFC3261 option tag processing.

> * In the same paragraph: "...the RLS will include "eventlist" 
> in a "Require" header...". Should the "will" be a "MUST"?

Same response as above.

> * The same paragraph also talks about how NOTIFY messages 
> will contain the require-header. Why is that necessary? Some 
> justification text should be added.

Justification text has been added, along the lines of:

  Use of "Require: eventlist" in NOTIFY messages
  is specified to satisfy the RFC3261 requirement
  that a UAC MUST insert a Require header field into
  a request listing the option tag for an extension
  if the UAC wishes to insist that a UAS understand the
  extension in order to process the request. Because
  the NOTIFY would not be usable without applying
  the eventlist option, the notifier is obligated
  to include it.

> - Section 3.5
> * Paragraph 5 say that an instance of a resource may be 
> terminated. How can a subscriber try again to subscribe to 
> this resource? Especially if the subscriber has subscribed to 
> a list with a very large expire value (weeks). The subscriber 
> will not get the chance to resubscribe to this resource 
> again. Should a SUBSCRIBE refresh cause the RLS to refresh 
> its subscriptions and also try to resubscribe to the 
> terminated ones? Or should the RLS try resubscribing to 
> terminated subscriptions at a pre-defined interval? or is all 
> this an implementation issue?

This is all up to the implementation of the RLS.

> * I suggest changing the "fullstate" attribute name to 
> something like "full-list", because that's what it really is. 

Admittedly, it's not communicating the full state of the
universe; however, for its own domain (the contents
of the list), it *does* designate whether full state is
provided.

> is just a repeat of text in section 6.1

You are correct. This is legacy text left over from when we
used to be a template package. I have removed it.

> - Section 4
> * First paragraph says: "In order to convey the state of 
> multiple resources, the list template package uses the 
> "multipart/related" mime type". Its not a list template 
> package anymore, its a eventlist package :)

Fixed.

> - Section 4.2
> * 3rd paragraph talks about the version attribute increasing 
> with every NOTIFY. Does it get reset to 0 with a SUBSCRIBE refresh?

No, a SUBSCRIBE refresh does not create a new subscription; it
simply updates a current one. I've taken out the parenthetical
phrase at the end of that sentence, since it doesn't really clarify
much, and is probably the source of your confusion.

> * 4th paragraph: Should there be some text specifying error 
> handling by the subscriber when the "fullstate" in not 
> communicated in the first NOTIFY?

I don't think so. There are a wide variety of stupid, noncompliant
things that either party can do, and it just isn't reasonable to
enumerate each of them, let alone defining specific procedures
to handle them.

> - Section 4.5
> * First, the section talks about flushing the table, then it 
> talks about how a new row in the table is created for each 
> resource element in the fullstate NOTIFY. It says:
> 
> 
> 
> So, which is first? or does the second paragraph above talk 
> about subsequent NOTIFYs after the SUBSCRIBE or refresh? e.g.: 
> the first bullet talks about comparing version numbers. How 
> can I do that when I've already flushed the table? I got 
> really confused reading this text.

I've attempted to clarify this text by splitting it into two sections.
One covers handling of full state notifications; the other covers
handling of partial notifications.

> * Last word in the step 1 should be "presence" instead of "a list".

Good catch. Thanks.

/a