Subject: [drinks] update to CORInfoType

From: "Ali, Syed Wasim" <[email-masked]>
Date: Sun, 15 Aug 2010 19:33:13 -0400

Hi,

'corClaim' attribute is meant to assist the registrant in making the
carrier-of-record claim for a given TN public identity. However, 'cor'
attribute is meant to be included in the response message to help the SPPP
server confirm, or not, whether if the registrant is in fact the
carrier-of-record. My understanding is that these two elements are not to be
used together in a message. Current definition of CORInfoType in the SP
schema requires both 'corClaim' and 'cor' elements, with an unintended
effect that both of these elements are now required for the add public
identifier (TN) request.

  <complexType name="CORInfoType">
    <sequence>
      <element name="corClaim" type="boolean" default="true"/>
      <element name="cor" type="boolean" default="false"/>
      <element name="corDateTime" type="dateTime" minOccurs="0"/>
    </sequence>
  </complexType>

I am suggesting the following change to make sure that when CORInfoType is
included in a message, a choice of either 'corClaim' or 'cor', and not the
inclusion of both attributes, is enforced.

  <complexType name="CORInfoType">
    <sequence>
      <choice>
        <element name="corClaim" type="boolean" default="true"/>
        <element name="cor" type="boolean" default="false"/>
      </choice>
      <element name="corDateTime" type="dateTime" minOccurs="0"/>
    </sequence>
  </complexType>

In addition, the Registry often have the carrier-of-record data (TN block
assignee list, NP data, etc.) available to make ad hoc decisions as to
whether the registrant's claim to be a carrier-of-record can be honored. I
think it is desirable to have the option to return the carrier-of-record
claim result in the sppp response that corresponds to the request. I made
some changes in the attached schema to support this option.

Lastly, attached is the updated schema and the examples that reflect the
changes discussed above.

-Syed

---

From: "Cartwright, Ken" <[email-masked]>
Date: Mon, 16 Aug 2010 12:35:33 -0400

Hi Syed,

A few points about this:

1) The corClaim and cor elements can't be a "choice" element because when a client app queries for the properties of a PublicIdentifier they need to know whether they sumitted it with a COR claim *and* whether that claim has been approved.  I think your intended goal could instead be accomplished by combining the corClaim and the cor elements into a single element of type enumeration whose values could be "noClaimRqst" "claimRqst" "claimRqstApproved" "claimRqstRejected".
2) I think I have come to agree with you that there should be an option to allow the result of a cor claim to be returned synchronously.  The scalability concern that I have about doing this synchronously is more of an on operational and/or policy concern.  Bulk requests that perform this cor check synchronously and send the response synchronously will of course be slower and result in a lot more data sent over the wire, however, some installations may need or want to function this way and therefore are willing to pay this performance price.  However, the manner that this has been proposed in the XSD I think may not work.  See (3) below.
3) The proposed change is to add in a AddPubIdsRspnsType object that contains a set of CORINfoTypes.  However, the CORInfoType does not contain the key of the PublicIdentity to which it applies.  And it is not good practive to just assume that it is based on the order in which they are passed in.  I think if we want to accomplish this, then we should include the full PubIdType object in the response.
4) The COR claim elements should also be part of the RNTYpe.

Ken

-----Original Message-----
From: Ali, Syed Wasim [mailto:[email-masked]]
Sent: Sunday, August 15, 2010 7:33 PM
To: Cartwright, Ken; [email-masked]
Cc: [email-masked]
Subject: update to CORInfoType

Hi,

-Syed

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.

---

From: "Ali, Syed Wasim" <[email-masked]>
Date: Tue, 17 Aug 2010 14:13:34 -0400

Thanks for the quick response. Please, see comments below:

On 8/16/10 12:35 PM, "Cartwright, Ken" <[email-masked]> wrote:

> Hi Syed,
> 
> A few points about this:
> 
> 1) The corClaim and cor elements can't be a "choice" element because when a
> client app queries for the properties of a PublicIdentifier they need to know
> whether they sumitted it with a COR claim *and* whether that claim has been
> approved.  I think your intended goal could instead be accomplished by
> combining the corClaim and the cor elements into a single element of type
> enumeration whose values could be "noClaimRqst" "claimRqst"
> "claimRqstApproved" "claimRqstRejected".

This is a valid point. And while use of carrier-of-record claim is certainly
one way to request COR processing, a lot of systems today maintain this
indicator implicitly that makes an explicit claim in the request
unnecessary. While we can try to cover all possibilities using enumerated
values, I think the original proposed boolean values should be sufficient. I
will remove the 'choice'.

> 2) I think I have come to agree with you that there should be an option to
> allow the result of a cor claim to be returned synchronously.  The scalability
> concern that I have about doing this synchronously is more of an on
> operational and/or policy concern.  Bulk requests that perform this cor check
> synchronously and send the response synchronously will of course be slower and
> result in a lot more data sent over the wire, however, some installations may
> need or want to function this way and therefore are willing to pay this
> performance price.  However, the manner that this has been proposed in the XSD
> I think may not work.  See (3) below.

Your concern for performance and excess data over the wire is not without
merit. However, not including the result in the response message means
separate 'getXXX' calls for all relevant requests in the bulk request
message just to know the outcome. Also, the fact that CORInfoType is an
optional element, it allows the needed flexibility in letting the Registry
use policy knobs and return this information on a case by case basis.

> 3) The proposed change is to add in a AddPubIdsRspnsType object that contains
> a set of CORINfoTypes.  However, the CORInfoType does not contain the key of
> the PublicIdentity to which it applies.  And it is not good practive to just
> assume that it is based on the order in which they are passed in.  I think if
> we want to accomplish this, then we should include the full PubIdType object
> in the response.

I am with you on this one. I forgot about the 1-to-many association to PI.
And COR is not the only case where the current schema definition of
AddPubIdsRspnsType needs clarification. Consider the case where the request
has multiple PI instances within a <addPubIdsRqst> and the Registry could
only honor some of them while others fail processing for one reason or
another. There are a couple of ways to go about it. One, change the ordinal
value for the composite AddPubIdsRqstType-->PI from 1..unbounded to 1..1.
This way, the <clientTransId> can be used to dereference the PI in the
response. Two, add the *track_identifier* (trkId) attribute for each PI that
can be later referenced in the response to (1) convey the COR status in
cases where the messages were processed successfully; and in case of a
failure, (2) point to the particular PI instance in this message along with
the correct failure response code. The former approach is too disruptive IMO
and adds bulk to the responses. The latter approach is do-able and tackles
the failure scenarios well. I envision 'trkId' to be any arbitrary integer
value the scope of which is limited to the immediate transaction, which is
<addPubIdsRspns> for the purpose of this discussion. To elaborate on this, I
am including a few examples below:

- Activate three PIs

  <addPubIdsRqst>
    <clientTransId>txid-5555</clientTransId>
    <pi xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1"
      xsi:type="ns1:TNType" trkId="1">
      <base>
        <rantId>rantId0</rantId>
        <rarId>rarId0</rarId>
      </base>
      <dgName>DEST_GRP_1</dgName>
      <corInfo>
        <corClaim>true</corClaim>
      </corInfo>
      <tn>+12025556666</tn>
    </pi>
    <pi xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1"
      xsi:type="ns1:TNType" trkId="2">
      <base>
        <rantId>rantId0</rantId>
        <rarId>rarId0</rarId>
      </base>
      <dgName>DEST_GRP_1</dgName>
      <tn>+17035556666</tn>
    </pi>
    <pi xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1"
      xsi:type="ns1:TNType" trkId="3">
      <base>
        <rantId>rantId0</rantId>
        <rarId>rarId0</rarId>
      </base>
      <corInfo>
        <corClaim>true</corClaim>
      </corInfo>
      <tn>+12025556666</tn>
      <rteRec xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1"
        xsi:type="ns1:NAPTRType">
        <priority>100</priority>
        <order>20</order>
        <pref>40</pref>
        <flags>u</flags>
        <svcs>E2U+sip</svcs>
        <regx>
          <ere>^(.*)$</ere>
          <repl>sip:\[email-masked]</repl>
        </regx>
      </rteRec>
    </pi>
  </addPubIdsRqst>

NOTE_1: The TN key of the first and third PI in the sequence above is
intentionally the same.
NOTE_2: <base> element is repetitive in the XML instance and perhaps it will
suffice as the member of the root element spppb:Request for most cases, if
not all. I think David S. pointed this out earlier. I am just saying it out
loud in case someone wants to comment.

case 1: All PI are successfully provisioned and either response below from
Registry should be fine.

  <addPubIdsRspns>
    <clientTransId>txid-5555</clientTransId>
    <serverTransId>serverTransId0</serverTransId>
    <resCode>1000</resCode>
    <resMsg>success</resMsg>
    <pi trkId="1">
      <base> ... </base>
      <corInfo>
        <corClaim>true</corClaim>
        <cor>true</cor>
      </corInfo>
      <tn>+12025556666</tn>
    </pi>
    <pi trkId="3">
      <base> ... </base>
      <corInfo>
        <corClaim>true</corClaim>
        <cor>true</cor>
      </corInfo>
      <tn>+12025556666</tn>
    </pi>
  </addPubIdsRspns>

   ---  OR  ---

  <addPubIdsRspns>
    <clientTransId>txid-5555</clientTransId>
    <serverTransId>serverTransId0</serverTransId>
    <resCode>1000</resCode>
    <resMsg>success</resMsg>
  </addPubIdsRspns>

case 2: Assuming that the Registry doesn't support PI-->RteRec associations,
sample failure response including the record in error, is shown below. Also,
since the <addPubIdsRqst> is a mini-transaction (with its own
clientTransId), a failure to provision one of the three PI means that none
of the PI instances in the set get provisioned.

  <addPubIdsRspns>
    <clientTransId>txid-5555</clientTransId>
    <serverTransId>serverTransId0</serverTransId>
    <resCode>2103</resCode>
    <resMsg>Command Invalid</resMsg>
    <pi trkId="3">
      <dgName>DEST_GRP_1</dgName>
      <tn>+12025556666</tn>
    </pi>
  </addPubIdsRspns>

> 4) The COR claim elements should also be part of the RNTYpe.

Sure. 

Please, find the updated schema attached to this email.

thanks,

-Syed

---

From: "Cartwright, Ken" <[email-masked]>
Date: Tue, 17 Aug 2010 14:58:32 -0400

Cool.  It sounds like we're in sync on items 1 and 2.  But on item 3 I have the following thoughts

a) Partial Success Within a Single Rqst Object (as apposed to across multiple request objects):  You seem to be proposing that we allow partial success within a single AddPubIdRqstType object.  We had decided to not allow that (but we would allow it across multiple such objects, hence the current design of the protocol).  The current XSD as designed does not allow that at all across any operations.  So if we do want to allow that then we need to revisit this across all the responses to make the protocol self consistent.  I'm ok with making this change, but we just need to acknowledge what we are proposing. This adds in notable complexity and will probably require us to revisit the design of our response codes.  But if we need to do it to support use cases needed by some organizations then we should do it.

b) "Track Id":  Relying on the client to pass in a somewhat arbitrary integer, trkId (which one might call a "temporary synthetic key"), is I think not reliable enough a mechanism to play the role as the link between an object passed in and its success/failure/status result.  It makes the code on both the client and server more complicated and more brittle.  If we want to support this kind of thing I think we either need to echo back each object and its properties in the response (or perhaps just each object that was not fully successful) along with its specific result code, or echo back just the object key of each object along with its specific result code and consider the need to add in a new response code to indicate the result of the COR claim.

Ken

-----Original Message-----
From: Ali, Syed Wasim [mailto:[email-masked]]
Sent: Tuesday, August 17, 2010 2:14 PM
To: Cartwright, Ken; [email-masked]
Cc: [email-masked]
Subject: Re: update to CORInfoType

- Activate three PIs

  <addPubIdsRqst>

  <addPubIdsRspns>

   ---  OR  ---

  <addPubIdsRspns>

  <addPubIdsRspns>

Sure.

thanks,

-Syed

---

From: "Ali, Syed Wasim" <[email-masked]>
Date: Tue, 17 Aug 2010 15:34:58 -0400

On 8/17/10 2:58 PM, "Cartwright, Ken" <[email-masked]> wrote:

> a) Partial Success Within a Single Rqst Object (as apposed to across multiple
> request objects):  You seem to be proposing that we allow partial success
> within a single AddPubIdRqstType object.  We had decided to not allow that
> (but we would allow it across multiple such objects, hence the current design
> of the protocol).  The current XSD as designed does not allow that at all
> across any operations.  So if we do want to allow that then we need to revisit
> this across all the responses to make the protocol self consistent.  I'm ok
> with making this change, but we just need to acknowledge what we are
> proposing. This adds in notable complexity and will probably require us to
> revisit the design of our response codes.  But if we need to do it to support
> use cases needed by some organizations then we should do it.

Nope, I am not proposing Partial Success within a Single Rqst Object. Within
a single request object <addPubIdRqst>, the outcome should be the whole
request processed successfully or no parts of it, period. For the response
message in "case 2:" below, it assumes a failure in processing the third PI
of the three that were part of the request object, and while the whole
request is deemed a failure, the offending PI in the request is included in
the response message to help the provisioning client pin-point where the
error is. 

> 
> b) "Track Id":  Relying on the client to pass in a somewhat arbitrary integer,
> trkId (which one might call a "temporary synthetic key"), is I think not
> reliable enough a mechanism to play the role as the link between an object
> passed in and its success/failure/status result.  It makes the code on both
> the client and server more complicated and more brittle.  If we want to
> support this kind of thing I think we either need to echo back each object and
> its properties in the response (or perhaps just each object that was not fully
> successful) along with its specific result code, or echo back just the object
> key of each object along with its specific result code and consider the need
> to add in a new response code to indicate the result of the COR claim.

The correlation mechanics is no different then use of <clientTransId> and
the requirement that the server mirrors it in the response. And given that
the scope is clearly defined to be limited to the Rqst object, I am not sure
it is creating any issues. Further, use of 'trkId' doesn't limit the server
from including the full request object, IF it choose to do so. The two are
orthogonal and implementations can support either mechanics, or not.

> are not the intended recipient, please contact the sender by reply e-mail and
> destroy all copies of the original message.
>

---

From: "Cartwright, Ken" <[email-masked]>
Date: Tue, 17 Aug 2010 18:38:33 -0400

Ok.  We're getting closer....  :-)

1) Partial success within a request object is not what you were proposing.  Ok cool.
2) I'm still not keen on the track ID concept:
        a) Watering it down the trackId proposal say that implementers can choose to support the trackId element or not is too loose a specification imo.
        b) One of the suggested justifications for the trackId proposal is that the trackId can be used for failure/error scenarios as well.  But this does not hold be cause you indicated that you are not proposing partial success/failure, and the parameterized response codes cover the existing success/failure scenarios.
        c) TrackId is not the same thing as a clientTranssId.  The usage of clientTransId is much very simple and succinct and applies clearly across all types of transactions regardless of object type or operation.
        d) If we add this in then we would need to add it into all object types, not just PudIds.  So what does it mean if the client passes in a track ID on a dest group del operation?  Iom, it's not clear.

Ken