The SPIRITS (Services in PSTN requesting Internet Services) Protocol
draft-ietf-spirits-protocol-08

No further objctions.

Some Comments/Nits:

I see several times ".myprovider.com", which should probably
be something aka ".myprovider.example.com"

This is much improved, it seems.

From John Loughney, Gen-ART:
It seems that they addressed some, not all the points raised.  I wouldn't
put a discuss on the draft, though. These things could be handled via
the RFC Editor.

NITS:

1) Formatting still off, but that is a minor point.
2) Status of this Memo should be updated wrt new
   text (RFCs 3667, 3668).
3) Abstract should still expand PSTN - I asked that
   SPIRITS be expanding, I should have explicitly asked
   for the PSTN to be expanded.
4) Still no IPR section.

  Section 2: s/a a "SPIRITS client"/a "SPIRITS client"/

  Section 3: s/This assures that/This ensures that/

  Section 3: s/The base schema assures/Use of the base schema ensures/
  
  I find the formatting in Section 4 difficult.  Indenting would really help.
  I suggest something like:
  
    The <spirits-event> element

       The root of a SPIRITS XML document (characterized by a Content-Type
       header of "application/spirits-event+xml">) is the ...

The introduction says:

"PSTN is used here to include all manner
   of access; i.e. wireline circuit-switched network as well as the
   wireless circuit-switched network."

There are wireless networks which are not circuit switched, and it is not clear
whether this is meant to imply that they would use these mechanisms.
PSTN has a pretty standard definition in any case, and I'm not sure what
*technical* reason it servers to expand it here.  This is repeated several
other places (overview, eg.).

The use of the URN namespace registered seems to miss the point; they
register the namespace, but then use the top level namespace for
the xml scheme.  As Scott's DISCUSS points out, that makes versioning difficult,
and using urn:ietf:params:xml:ns:spirits:event-package:1 might
resovle that.

This language also is imprecise enough that I would like to see it cleaned up:

  A SPIRITS notifier MAY use an extended schema to generate an XML
   document; however, such an XML document MUST contain the mandatory
   elements defined by the base notification schema.  This assures that
   a vanilla SPIRITS subscriber is, at the bare minimum, able to parse
   and interpret the mandatory elements from an XML document.  The base
   schema assures interoperability across vendor implementations, and
   the extensions allow for customization.

The spirits subscriber must somehow know that the extended schema's
elements are those from the base notification schema.  If I read this 
correctly, they intend for these extensions to occur by the base schema
being reused by all vendors and the extensions occurring in other schemas;
that's fine.  But the language above could be read by our embrace-and-extend
friends as "reuse these elements in your own schema and you'll be fine", which
breaks interoperability (essentially saying "these element names are always
subject to the same rules, despite the namespace declaration"--which means
the standard XML view isn't followed).

I'm a no-ob on this only because I think Scott would be better as the token
holder for fixing this.

In 5.3.1, does this:


   A subscriber will issue a SUBSCRIBE request which identifies a set of
   events (DPs) it is interested in getting the notification of.  This
   set MAY contain exactly one DP, or it may contain multiple DPs.  The
   SUBSCRIBE request is routed to the notifier, where it is accepted,
   pending a successful authentication.

mean that it MUST contain at least one DP?