Subject: [drinks] A little more on spprov-11 request-response model and spppUpdateResponse

From: Dean Willis <[email-masked]>
Date: Wed, 9 Nov 2011 17:11:47 -0600

o    corInfo: corInfo is an optional parameter of type CORInfoType
        that allows the registrant organization to set forth a claim to
        be the carrier-of-record (see [RFC5067]).  This is done by
        setting the value of <corClaim> element of the CORInfoType

Previously, we assumed that a request-response model consistent with
SOAP. SOAP allows us to return a structured type that includes a lot
of information. This assumption is illustrated in section 4.2 Request
and Response Model in the spprov-11 draft:

4.2.  Request and Response Model

   Provisioning operations in SPPP follow the request-response model,
   where a client sends a request message to initiate a transaction and
   the server responds with a response.  Multiple subsequent request-
   response exchanges MAY be performed over a single persistent
   connection.

   Therefore, a transport protocol for SPPP MUST follow the request-
   response model by allowing a response to be sent to the request
   initiator.

One of the challenges in re-layering the specification is that some
potentially interesting protocol bindings (such as RESTful HTTP) use a
different response paradigm. REST, in particular, suggests that the
response code set by mapped onto the relatively small set of HTTP
responses, although some transactions (notably query or "GET"
transactions) can obviously return a large amount of structured data.
So this is particularly of concern on write/update transactions,
("PUT", "POST", "DELETE").

So this means that we can't always return a structured type like the
"spppUpdateResponse". It's just something that a non-SOAP binding is
going to have to find an appropriate way to do.

However, the current spprov-11 draft retains a few references to
"spppUpdateResponse" that still need to be cleaned out. Specifically,
I noted references in section 6.3 Route Group (right at the end) that
can probably just be deleted.

There's also some discussion in the corInfo bullet under TNType in
section 6.2 Public Identifier. I think it's okay to just delete the
last sentence that talks about  spppUpdateResponse, but this needs
some thinking about.

Specifically, I'm wondering of there's actually some sort of
authorization failure that needs to be asserted if 1) the
carrier-of-record claimed in the update is inconsistent with the
previously claimed authority information, and 2) the server policy
cares about this distinction. If we need to assert such an error, how
might we assert it?

Related question for the SOAP binding: Is just including a mismatched
corInfo in the response a strong enough assertion of this error
condition?

--
Dean