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

From: "Bhatia, Vikas" <[email-masked]>
Date: Fri, 30 Dec 2011 14:20:42 -0500

Please see comments inline below.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Dean Willis
> Sent: Wednesday, November 09, 2011 6:12 PM
> To: [email-masked]
> Subject: [drinks] A little more on spprov-11 request-response model and
> spppUpdateResponse
>
>    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.
[VB:] References to "spppUpdateResponse" were cleaned out in version 12 of the spprov document. Version 11 was an intermediate version of the document while the documents were being restructured to accommodate ReSTFul mapping of the protocol/framework.
>
> 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?
[VB:] If carrier-of-record claim in an update request is different from the previously claimed information then this could be a valid scenario as the registrant is no more a carrier-of-record for that pub Id. So from that perspective, validating carrier-of-record claim in an update request with previously claimed information does not seem a valid scenario. However, as also mentioned in the protocol document (section 6.2), if the registry does have access to authority data and can cross-verify the corClaim in the request (add or update), and if there is a mismatch with the authority data, then whether Pub Id add/update fails is a matter of server policy. If the server policy decides to fail it then they can respond with the appropriate Response Type ("Response Types" section in the version 12 of the spprov document).
I hope this answers. Design Team, if I am missing some historical perspective on this please comment.
>
>
> --
> Dean
> _______________________________________________
> drinks mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/drinks

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.