Subject: [Gen-art] Gen-ART review of draft-roach-sip-http-subscribe-06.txt

From: Suresh Krishnan <[email-masked]>
Date: Tue, 2 Feb 2010 00:21:27 -0500

I am the assigned Gen-ART reviewer for
draft-roach-sip-http-subscribe-06.txt

For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

Please resolve these comments along with any other Last Call comments
you may receive.

Summary: This draft is almost ready for publication as Proposed Standard 
but I have a few comments.

Meta
====
* How does the mechanism in the draft relate to say an atom or an RSS 
feed? When would one use the sip subscribe mechanism instead of atom and 
vice versa? Perhaps it is out of scope of this document, but I was just 
curious.

Minor
=====

* Section 3.2

The example using two URLs each in www.example.com and www.example.org 
is too complex. I do not see the value in adding the www.example.org 
URLs. Are these necessary Can you simplify this to

For example: consider the case in which a client wishes to monitor
the resources http://www.example.com/goat,and 
http://www.example.com/sheep. It would use HTTP to perform HEAD 
and/or GET operations on these resources.  The responses to these 
operations will contain link relations for both monitor and 
monitor-type for each of the four resources.  Assume the monitor 
link for http://www.example.com/goat is sip:[email-masked];
for http://www.example.com/sheep, sip:[email-masked]. Further, 
assume the monitor-group link for http://www.example.com/goat and 
http://www.example.com/sheep are both sip:[email-masked],

Because they share a common monitor-group link, the client would 
group together http://www.example.com/goat and 
http://www.example.com/sheep in a single subscription.  It sends 
this subscription to the monitor-group URI 
(sip:[email-masked]), with a resource-list containing the 
relevant monitor URIs (sip:[email-masked] and 
sip:[email-masked]).

* Section 3.3

This section is very interesting and useful. Why does it need to be removed?

Typo
====

* Section 4.7

s/supress/suppress/

Thanks
Suresh

---

From: Adam Roach <[email-masked]>
Date: Tue, 02 Feb 2010 10:28:06 -0600

On 2/1/10 23:21, Feb 1, Suresh Krishnan wrote:
> feed? When would one use the sip subscribe mechanism instead of atom 
> and vice versa? Perhaps it is out of scope of this document, but I was 
> just curious.

My understanding is that Atom is pretty much a syndication syntax, and 
that Atom clients perform periodic HTTP polling to determine when the 
state of the Atom feed has changed. At least, this model is consistent 
with my experience as a user of Atom syndication readers.

This mechanism would actually dovetail into such a system by allowing 
readers to re-poll the Atom resource only when it has changed, instead 
of on a time-based periodic basis.

But, then again, I'm not well versed in Atom, and may have missed some 
mechanism that makes periodic polling unnecessary (such as long-polling 
techniques).

> URLs. Are these necessary?

The goal of the example was to show that a user can be interested in a 
set of URLs that resolve to two different monitor-groups, and show how 
the client would respond (by forming two different subscriptions). I 
admit that RFC formatting makes the resulting text a bit unsightly, but 
I think it provides significant value beyond a simple one-domain example.

> This section is very interesting and useful. Why does it need to be 

I'm happy to leave it in. It was mostly there because of the broad range 
of audience I anticipated reviewing the draft -- in most other cases, 
the rationale would go on the mailing list and not the i-d itself.  But 
there's no harm in including it; it's just not something that one 
typically sees in RFCs (although I do know that exceptions exist).

I'll remove the RFC editor note.

> s/supress/suppress/

Argh. That was one of the small changes I made after the most recent 
round of spell-checking. Thanks for catching it.

/a