Subject: new (and hopefully last version!) of the CNRP document

From: Michael Mealling <[email-masked]>
Date: Thu, 3 Jan 2002 13:29:50 -0500

Hi everyone,
  I just submitted the latest version of the CNRP document to the repository.
The changes were due to a discussion with the IESG over CNRP's transport
independent nature. In the author's opinion, this is slightly significant
enough to warrant the working group's review. I suggest we give this a quick
review and if no comments are received by January 7th (Monday) then we let the
IESG know we're fine with this change.  Thanks!

The old document said this:

3.3 Transport independence

   Since CNRP is completely encapsulated within its XML definition it
   can be considered transport-independent.  However, because there
   should be a standardized way for a client to contact and negotiate
   with a server, CNRP servers are SHOULD support the HTTP (Section 7.1)
   transport on the default CNRP port of 1096.

   A particular service may choose to change to a different transport or
   port (via statements within the XML DTD), but minimally, all initial
   contacts between a client and a server can be assumed to at least
   function over HTTP on port 1096.  For a short explanation of how CNRP
   employs HTTP, see Section 7.1 of this document.  If other transports
   are used they MUST be handled over a port other than the default CNRP
   port.

The new version says this:

3.3 Transport Independence

   CNRP is completely encapsulated within its XML definition, and is
   therefore transport-independent in its specification.  However,
   clients need to have a clearly defined means of bootstrapping a
   connection with a server.

   It is possible to define special-purpose applications that use CNRP;
   those applications MUST define how to find the appropriate
   server/port/protocol.  CNRP servers dedicated to those applications
   may provide service only on the ports/transport protocols defined by
   the application.

   All other (generic) CNRP servers MUST support the HTTP (Section 7.1)
   transport on the default CNRP port of 1096.

   Note that a particular service may choose to change to a different
   transport or port (via statements within the XML DTD), with initial
   contacts between a client and a server can be over HTTP on port 1096.
   For a short explanation of how CNRP employs HTTP, see Section 7.1 of
   this document.  If other transports are used they MUST be handled
   over a port other than the default CNRP port.

-MM

--
--------------------------------------------------------------------------------
Michael Mealling        |      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net

---

From: "Marshall L. Moseley" <[email-masked]>
Date: Fri, 4 Jan 2002 11:57:18 -0800

the application.>>

Why would we want to preclude special-purpose applications from using the
general-purposes method for CNRP interraction?  I don't get it.  It says
special-purposes servers MUST define  their protocol.  Why do we want to
stop them from doing HTTP 'handshaking' and then protocol switching via the
DTD?

Why are we removing the statement that protocol-switching is
allowed/encouraged via the DTD?

---

From: Michael Mealling <[email-masked]>
Date: Fri, 4 Jan 2002 18:30:35 -0500

> stop them from doing HTTP 'handshaking' and then protocol switching via the

It doesn't say that have to define a _different_ handshake method.
Its attempting to say that if it chooses to do something besides the
defined HTTP method then it has to document how that's done.

> allowed/encouraged via the DTD?

We didn't. Its further down in that section. The issue was that the
IESG has trouble understanding protocol independence. Their concern
is that if you don't define some transport to be mandatory to implement
then you won't have interoperability. What we're trying to say is that
if you are building a client or server that is meant to be _generic_
then you MUST support the HTTP handshake method. But if you are building
a server or client that knows it will never have to do that then there's
no reason to put it in there just to make it 'compliant'.

-MM

---

From: Martin Duerst <[email-masked]>
Date: Sat, 5 Jan 2002 15:21:22 +0900

>    transport or port (via statements within the XML DTD),

There is only one single DTD in CNRP, given in Section 5.
I have no idea how 'statements within the XML DTD' could
influence transport/port. Probably, 'statements within the XML DTD'
should be replaced with something like 'statements within
a CNRP service description request'.

Regards,  Martin.

>with initial

---

From: Michael Mealling <[email-masked]>
Date: Tue, 8 Jan 2002 11:51:29 -0500

> a CNRP service description request'.

that sounds better. I'll make that change...

-MM