A SIP Event Package for Subscribing to Changes to an HTTP Resource
draft-roach-sip-http-subscribe-07

[Ballot comment]
When section 3.3 is removed, you will need to remove references 14 and 15.

(Assuming you really want to discard 3.3 and not move it to an appendix to retain the history.)

IANA comments:

Action #1:

Upon approval of this document, IANA will make the following
assignments in the FUTURE "Link Relation registry"
as defined by draft-nottingham-http-link-header-07

Relation Name: monitor
Description: Refers to a resource that can be used to monitor
changes in an HTTP resource.
Reference: [RFC-roach-sip-http-subscribe-06]

Relation Name: monitor-group
Description: Refers to a resource that can be used to monitor
changes in a specified group of HTTP resources.
Reference: [RFC-roach-sip-http-subscribe-06]


Action #2:

Upon approval of this document, IANA will make the following assignments
in the "Session Initiation Protocol (SIP) Event Types Namespace"
registry at
http://www.iana.org/assignments/sip-events

Package Name Type Contact Reference
----------------| ---------------- | ---------------------------- | ---------
http-monitor | Package | Adam Roach, adam@nostrum.com | [RFC-roach-sip-http-
subscribe-06]


Action #3:

Upon approval of this document, IANA will make the following assignments
in the "Header Field Parameters and Parameter Values"
registry at http://www.iana.org/assignments/sip-parameters

Header Field Parameter Name Values Reference
---------------- | ------------------- | ---------- | ---------
Event | body | yes | [RFC-roach-sip-http-subscribe-06]


We understand the above to be the only IANA Actions for this document.

(1.a) Who is the Document Shepherd for this document? Has the
      Document Shepherd personally reviewed this version of the
      document and, in particular, does he or she believe this
      version is ready for forwarding to the IESG for publication?

Document Shepherd: Scott Lawrence

I have personally reviewed a few versions of this document, including
the latest (06) draft.

I believe this version is ready for IESG review and publication.

(1.b) Has the document had adequate review both from key WG members
      and from key non-WG members? Does the Document Shepherd have
      any concerns about the depth or breadth of the reviews that
      have been performed?

This document is not the product of a Working Group - it began as an
individual submission from the author and got considerable attention
from experts in the HTTP and SIP communities.  Based on discussion on
the DISPATCH working group list during the summer of 2009, a consensus
was reached that it was close enough to complete that a WG was not
needed.

A mailing list for interested parties to help finalize the document
was established in early August 09, which produced a few additional
versions of the draft.

(1.c) Does the Document Shepherd have concerns that the document
      needs more review from a particular or broader perspective,
      e.g., security, operational complexity, someone familiar with
      AAA, internationalization or XML?

I believe that the draft has had sufficient review from both the SIP
and HTTP protocol perspectives, and that it adequately provides advice
to implementors regarding operational and security issues.

(1.d) Does the Document Shepherd have any specific concerns or
      issues with this document that the Responsible Area Director
      and/or the IESG should be aware of? For example, perhaps he
      or she is uncomfortable with certain parts of the document, or
      has concerns whether there really is a need for it. In any
      event, if the WG has discussed those issues and has indicated
      that it still wishes to advance the document, detail those
      concerns here. Has an IPR disclosure related to this document
      been filed? If so, please include a reference to the
      disclosure and summarize the WG discussion and conclusion on
      this issue.

I have no outstanding concerns with this document.

(1.e) How solid is the WG consensus behind this document? Does it
      represent the strong concurrence of a few individuals, with
      others being silent, or does the WG as a whole understand and
      agree with it?

There seems to be broad consensus that the document is useful.  I have
seen no objections to the concept or to the particulars of this
embodiment of that concept during the discussions (some questions, but
no opposition).  The discussions over the last few months have mostly
clarified and extended the suggested functionality to expand its
applicability.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
      discontent? If so, please summarise the areas of conflict in
      separate email messages to the Responsible Area Director. (It
      should be in a separate email because this questionnaire is
      entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
      document satisfies all ID nits? (See the Internet-Drafts Checklist
      and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
      not enough; this check needs to be thorough. Has the document
      met all formal review criteria it needs to, such as the MIB
      Doctor, media type and URI type reviews?

Yes, the document was verified using idnits 2.11.15.
Note that idnits complains about lack of the recommended RFC 2119 boilerplate. This can be fixed by the RFC Editor.

(1.h) Has the document split its references into normative and
      informative? Are there normative references to documents that
      are not ready for advancement or are otherwise in an unclear
      state? If such normative references exist, what is the
      strategy for their completion? Are there normative references
      that are downward references, as described in [RFC3967]? If
      so, list these downward references to support the Area
      Director in the Last Call procedure for them [RFC3967].

The references are split into separate normative and informative
sections appropriately.

There is one normative reference to an Internet Draft, which is also
intended to be standards track :

  [9]  Nottingham, M., "Web Linking",
        draft-nottingham-http-link-header-06 (work in progress),
        July 2009.

  at this writing, that draft is in the state:

    Waiting for AD Go-Ahead::Revised ID Needed

(1.i) Has the Document Shepherd verified that the document IANA
      consideration section exists and is consistent with the body
      of the document? If the document specifies protocol
      extensions, are reservations requested in appropriate IANA
      registries? Are the IANA registries clearly identified? If
      the document creates a new registry, does it define the
      proposed initial contents of the registry and an allocation
      procedure for future registrations? Does it suggest a
      reasonable name for the new registry? See [RFC5226]. If the
      document describes an Expert Review process has Shepherd
      conferred with the Responsible Area Director so that the IESG
      can appoint the needed Expert during the IESG Evaluation?

The document does contain an appropriate IANA considerations section,
which adds entries to registries that either already exist or are
established by the normative dependency described above.

(1.j) Has the Document Shepherd verified that sections of the
      document that are written in a formal language, such as XML
      code, BNF rules, MIB definitions, etc., validate correctly in
      an automated checker?

There is one ABNF definition in the document.  It validates correctly.

(1.k) The IESG approval announcement includes a Document
      Announcement Write-Up. Please provide such a Document
      Announcement Write-Up? Recent examples can be found in the
      "Action" announcements for approved documents. The approval
      announcement contains the following sections:

Technical Summary

  This document defines a mechanism whereby the Session Initiation
  Protocol (SIP) Event Framework can be used to provide notification
  of changes to the state of resources available through the
  Hypertext Transport Protocol (HTTP).  This facilitates the
  development of applications that provide near real time updates to
  information through HTTP without frequent polling or continuously
  open transport connections.

Working Group Summary

  This is not a Working Group document - it is an individual
  submission, but has received review from participants active in the
  SIP and HTTP communities.  Based on discussion on the DISPATCH
  working group list during the summer of 2009, a consensus was
  reached that it was close enough to complete that a Working Group
  was not needed, but a separate list [1] was created to complete the
  work.

Document Quality

  There is not yet significant implementation of this protocol, but
  it has been incorporated as a key component in the SIP Forum User
  Agent Configuration Recommendation (currently in SIP Forum Last
  Call); a number of implementations of that recommendation are
  believed to be in progress.

[1] http://www.ietf.org/mail-archive/web/sip-http-events/current/maillist.html