The SPIRITS (Services in PSTN requesting Internet Services) Protocol
RFC 3910

Note: This ballot was opened for revision 08 and is now closed.

(Allison Mankin) Yes

Comment (2004-03-17 for -)
No email
send info
I've given a careful (though I'm sure additional) review to the event package and MIME registrations.  They look fine.

Typo:
  This request eventually arrives at the SIPRITS notifier

It's nice to know the wg maintained constantly solidarity :)

(Jon Peterson) Yes

(Harald Alvestrand) No Objection

Comment (2004-05-13)
No email
send info
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.

(Margaret Cullen) No Objection

(Bill Fenner) (was Discuss) No Objection

(Ted Hardie) No Objection

Comment (2004-03-17 for -)
No email
send info
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?

(Scott Hollenbeck) (was Discuss) No Objection

(Russ Housley) (was Discuss) No Objection

Comment (2004-03-15)
No email
send info
  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 ...

(David Kessens) No Objection

(Thomas Narten) No Objection

(Bert Wijnen) No Objection

Comment (2004-03-18 for -)
No email
send info
No further objctions.

Some Comments/Nits:

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

(Alex Zinin) No Objection

(Steven Bellovin) Recuse