[Sip] Comments on draft-roach-sip-list-template-00.txt

[hbhondwe@hss.hns.com]

Hi,

Some comments on this draft, assuming that this draft is open for comments.
Not sure if this should go to Simple or Sip mailing list.

1)Section 4.3 Constructing Coherent Resource State, states
"The resource list subscriber maintains a table for each resource
   list.  The table contains a row for each resource in the resource
   list."
and then it states that a version number is associated with each row of the
resource list table.
Why should a version be associated with each resource of a resource list?
Should it not be associated with the resource list table instead?

RFC 3265  states in section 4.3.2 State Deltas,
"Any event package that supports delta changes to states MUST include
   a version number that increases by exactly one for each NOTIFY
   transaction in a subscription. ".

2)Section 4.3 (of the draft) states that when the version number jumps, the
document received should be
processed. I presume that  "processing" implies what is elaborated in the
same section later on.
Extract from sec 4.3 of the draft:
"If the value in the document is more
   than one higher than the local version number, the local version
   number is set to the value in the new document, the document is
   processed, and the .list subscriber SHOULD generate a refresh request
   to trigger a full state notification."

whereas RFC 3265 in sec 4.3.2 says that when version number jumps , the
Notify message can be ignored.

Extract from RFC 3265, sec 4.3.2:
"If a NOTIFY arrives that has a version number that is incremented by
   more than one, the subscriber knows that a state delta has been
   missed; it ignores the NOTIFY message containing the state delta
   (except for the version number, which it retains to detect message
   loss), and re-sends a SUBSCRIBE to force a NOTIFY containing a
   complete state snapshot.

3)Should the .list subscriber generate a refresh request even when the
version is not consecutive AND
"State" header indicates full state? The .list subcriber may have lost some
 intermediate notifications, but has now
received full state. It can very well update its local version to the new
version  without doing any refresh.
If the "State" indicates partial, however,  then a refresh request is
called for.


thanks
Harsh Bhondwe






This message is proprietary to Hughes Software Systems Limited (HSS) and is
intended solely for the use of the individual to whom it is addressed.  It
may contain privileged or confidential information and should not be
circulated or used for any purpose other than for what it is intended.  If
you have received this message in error, please notify the originator
immediately.  If you are not the intended recipient, you are notified that
you are strictly prohibited from using, copying, altering, or disclosing
the contents of this message.  HSS accepts no responsibility for loss or
damage arising from the use of the information transmitted by this email
including damage from virus.


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip