Ok, these are the final nits.
---------------------
> > Section 10.1:
> >
> > p. 22, 2nd paragraph: delete "or Appearance Agent" at end
> of paragraph.
> >
>
> Actually, this is correct, as I am talking about
> registrations refresh
> with the Registrar and subscription refresh with the
> Appearance Agent.
> Here's the sentence:
>
> "Also note that registrations and subscriptions must all be refreshed
> by Alice at intervals determined by the expiration
> intervals returned
> by the Registrar or Appearance Agent."
>
> Maybe it should say Registrar and Appearance Agent?
Ah, I get it now. What about this:
Also note that both registrations and subscriptions must all be
refreshed by Alice at intervals determined by the expiration
intervals returned respectively by the Registrar and the
Appearance Agent.
---------------------
> > Question: Why is "202" used for responding to SUBSCRIBE
> instead of "200"? If
> > 202 is used, I think it deserves an explanation in the document.
> >
>
> Isn't 202 commonly immediately returned, and then the NOTIFY confirms
> the subscription state (i.e. active instead of pending)? I
> can change
Not exactly.
>From 3265:
A 200 response indicates that the subscription has been accepted
and that the user is authorized to subscribe to the requested
resource. A 202 response merely indicates that the subscription
has been understood, and that authorization may or may not have
been granted.
Now, in draft-roach-sipcore-rfc3265bis-00 Appendix B, I see this:
B.2. Remove 202 Response Code?
In practice, the 202 response code defined in RFC 3265 has proven to
be nearly useless, due to its redundancy with the "pending" state,
and its interaction with the HERFP problem. Given that 202 must be
treated as 200 if an implementation does not understand it: would
removing the 202 response code cause any issues for current
implementations?
I know it's not a done deal yet (this is not even a WG document), but
unless you see a really good reason why this spec would use 202 instead
of 200 in the examples, I'd rather we play it safe and use 200...
-------------
Section 10
Add note after first paragraph:
Note: All the examples in this section, except Section 10.13, show
a model where the Appearance Agent has access to dialog state
information
and therefore does not explicitly subscribe to the dialog-event package.
All these examples would be different if an explicit subscription was
used
instead. For simplicity, only one example of subscription is shown (see
Section 13): but the same idea could be applied throughout all the
examples.
Or something like that. You get the idea.
What I found is that if you are designing your implementation using the
subscription
model, then it takes a while to figure out that the spec is still applicable to
you.
And section 10.13 is burried quite deep at the end.
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
