[BLISS] draft-ietf-bliss-shared-appearances: Final Nits

["Francois Audet" <[e-mail]>]

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.