Subject: [sipcore] AD review: draft-ietf-sipcore-subnot-etags-02

From: Robert Sparks <[email-masked]>
Date: Tue, 9 Jun 2009 13:51:20 -0500

This document is ready for IETF LC - watch for the announcement of  
such shortly.

Some comments that we can address as part of that last call:

1) Page 14: "subscriber can clear handle" isn't clear to me. Should  
this say
"subscriber can release state"?

2) Page 15: The second paragraph of section 5.3 might need  
clarification.
It says:
  "The subscriber MUST NOT infer any meaning from the value of an  
entity-tag;
specifically, the subscriber MUST NOT assume identical entities (i.e.  
event state)
for NOTIFYs with identical entity-tag values."
That could be read to mean that a given notifier might assign tag E1  
to state "foo"
at one point in time, and assign tag E2 to it at some other point in  
time.
I suspect this was intended to capture the warning that different  
notifiers might
generate different tags for the same state, and that after receiving  
E1->"foo" from notifier 1,
the subscriber MUST NOT assume E1 from notifier 2 means "foo".

3) Page 21, section 6.3, 3rd paragraph. I suggest adding "following  
the procedures in
     RFC3265" to the end of  "A successful conditional SUBSCRIBE  
request MUST extend
    the subscription expiry time." to avoid implementer arguments  
about whether honoring
    an Expires header field value that actually makes the remaining  
subscription time
    _shorter_ (such as Expires: 0), "extends" the subscription expiry  
time.

RjS