Subject: [drinks] Questions/Suggestions on draft of SPPP protocol

From: Mickael MARRACHE <[email-masked]>
Date: Tue, 1 Mar 2011 23:31:56 +0200

Hey DRINKS working group,

We are two students working on implementing the SPPP protocol, so we have
read the draft version 04 and we have some questions and suggestions for it.

   1.  (p. 7) It’s written that a registrant or a registrar is identified
(uniquely) by its name and an identifier, but the identifier (type
OrgIdType) is enough (the name is not a part of the identifier).

   2.  (p. 11) Need to add a new association (optional) from the TN public
identifier type to the Route Record type (multiplicity 0…n).

   3.  (p. 19) Does a client can send more than one transactions without
waiting the corresponding responses (Stop and wait, or no?) If yes, why the
clientTransId is optional?

   4.  (p. 19) Suggestion: BasicRqstType -> BasicUpdateRqstType (like
BasicQueryRqstType in page 22) in order to follow the same naming logic.

   5.  (p. 18-19) Suggestion: spppUpdateRequest -> spppUpdateTransRequest
(in order to differentiate in the text between the transaction and the
BasicRqstType requests).

   - (p.18) clientTransId definition: change request by transaction

   - (p.18) rqst definition: change request by transaction

   6.  (p. 19) Suggestion: spppUpdateResponse -> spppUpdateTransResponse.

   7.  (p.20) Why to send back the request object concerned by the error ?
There is a possibility to introduce an identifier at update request level
and to send it back to the client in the update response, but the client
needs to save the request objects in memory before receiving their
corresponding responses. This maybe can reduce the traffic.

   8.  (p. 22) Does a client can send more than one query requests without
waiting the corresponding responses (Stop and wait or no?) If yes, how to
associate a response with a request (there is no identifier)?

   9.  (p. 23) Does the second column correspond to the messages that a
server sends in responses (query or update)? If yes,  Suggestion: Text
(second column header) -> Message .

  10. (p.23-24) For error codes 2105 and 2106, which attribute to choose for
the message?(The error is not specific to an attribute but is specific to an
object).

  11. (p.28)The destination groups associated with a route group are
represented by the dgName attribute IN THE ROUTE GROUP TYPE so the
association direction seen in page 11 must be in the opposite direction
(from RouteGroup to DestinationGroup), or, the attribute representing the
association must be in the DestGrpType (defined in page 33). Moreover, the
attribute name is different in page 11 (destGrpRef) and page 28 (dgName).

17)

  12.  We propose to add an element representing a name in BasicObjType, so
the primary key of BasicObjType will be rant+rar+name. The problem is that
in the BasicObjType, there is no primary key (rant and rar don’t identify
uniquely an instance of BasicObjType). For example, two route groups can
have the same rant and rar but different names.

  13. (p.29-30) Correction: In the SourceIdentType definition (p.29), one of
the attribute is sourceIdentLabel. In the explanation (p.30), the same
attribute is named sourceIdentRegex.

  14. (p. 27) The element “dgName” of a route group cannot be of type
“ObjNameType” because the elements which identify a destination group are
“rant” and “dgName”. In this case, how to reference a destination group
associated with a route group using a foreign key "dgName" which is not a
primary key for a destination group. Same questions p. 39.

  15. (p. 48) Redefinition of RteRecType with error (the extension from
BasicObjType is missing – see the first definition p. 47).

  16. (p.10) In the diagram, an organization has the attributes OrgId and
OrgName. But, the organization type is not defined in the standard. Also, in
the standard, an organization is referenced (and implicitly identified) by
an OrgIdType. Why there is no OrganizationType definition like for the other
objects? We suggest to define an organization type with two elements : OrgId
of type OrgIdType and OrgName of type ObjNameType.

---

From: "Cartwright, Ken" <[email-masked]>
Date: Wed, 2 Mar 2011 17:40:48 -0500

Hello "Two students working on SPPP protocol" :-) :

Thanks so much for your very thorough review of the SPPP protocol document.  Please see my responses to your comments below.  We will incorporate your feedback in the next rev of the document.

Ken

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mickael MARRACHE
Sent: Tuesday, March 01, 2011 4:32 PM
To: [email-masked]
Subject: [drinks] Questions/Suggestions on draft of SPPP protocol

We are two students working on implementing the SPPP protocol, so we have read the draft version 04 and we have some questions and suggestions for it.
   1.  (p. 7) It's written that a registrant or a registrar is identified (uniquely) by its name and an identifier, but the identifier (type OrgIdType) is enough (the name is not a part of the identifier).

KJC:  Registrant and Registrars are uniquely identified by their identifier, and the OrgIdType holds such an identifier.  The textual description that says something about an registrant name or registrant name is not accurate.  We will fix that text.

   2.  (p. 11) Need to add a new association (optional) from the TN public identifier type to the Route Record type (multiplicity 0...n).

KJC:  I'm not sure what is meant by this comment.  The XSD shows the optional relationship between PubIdType and Route Records.  Maybe you could clarify the comment.

   3.  (p. 19) Does a client can send more than one transactions without waiting the corresponding responses (Stop and wait, or no?) If yes, why the clientTransId is optional?

KJC:  Yes.  Any SPPP server worth it's salt would be multi-threaded.  It is up to the client to decide if it wants to open more then one HTTPS connection and submit requests concurrently.  However, it would ultimately be a matter of policy as to how many concurrent HTTPS connections an SPPP server would allow to be open by each registrar.  But if you are talking about "pipelining" then this is really a question that would relate to the SPPP transport document (the SPPP over SOAP and HTTPs document, the one that contains the WSDL) rather than one relating to this document.  Whether an SPPP server would support pipelining I think would be a policy decision.  In any case the protocol requires a standard request-reply model so requests on a given HTTP connection must be replied to in the same order that they were sent.  If the SPPP Protocol document and the SPPP over SOAP and HTTPs documents do not together make this clear please let me know where you feel that the working should be changed.

   4.  (p. 19) Suggestion: BasicRqstType -> BasicUpdateRqstType (like BasicQueryRqstType in page 22) in order to follow the same naming logic.

KJC:  Yes.  That would be a better name.

   5.  (p. 18-19) Suggestion: spppUpdateRequest -> spppUpdateTransRequest (in order to differentiate in the text between the transaction and the BasicRqstType requests).

KJC:  Are you referring to the fact that the message element name in the WSDL is "rqst" and the element name in the XSD is "rqst"?  If that is your point then it would probably be best to rename the element in the WSDL to "rqstMsg".  I'd prefer not to add in the word "Trans" here.

    *   (p.18) clientTransId definition: change request by transaction

    *   (p.18) rqst definition: change request by transaction
   6.  (p. 19) Suggestion: spppUpdateResponse -> spppUpdateTransResponse.

KJC:  Same comment as above.

   7.  (p.20) Why to send back the request object concerned by the error ? There is a possibility to introduce an identifier at update request level and to send it back to the client in the update response, but the client needs to save the request objects in memory before receiving their corresponding responses. This maybe can reduce the traffic.

KJC:  Object level errors will be the rare exception, so traffic is not a practical concern.  Introducing a separate identifier that the client must generate and then adding into the XSD an element to optionally house that identifier on the way in and then echoing it back out is un-necessary.  It is safer and clearer to just echo back the erroneous object.

   8.  (p. 22) Does a client can send more than one query requests without waiting the corresponding responses (Stop and wait or no?) If yes, how to associate a response with a request (there is no identifier)?

KJC:  Similar response as the one provided above for requests.  Requests and replies over a single HTTP connection must be responded to in the order that they are received.  But that's not to say that multiple concurrent HTTP connections cannot be open from a single registrar.

   9.  (p. 23) Does the second column correspond to the messages that a server sends in responses (query or update)? If yes,  Suggestion: Text (second column header) -> Message .

KJC:  The first column is the "Result Code" the second column is the result code text.  I think you suggestion to rename that column to "Result Message" is a good one.

  10. (p.23-24) For error codes 2105 and 2106, which attribute to choose for the message?(The error is not specific to an attribute but is specific to an object).

KJC:  For 2105 consider what would happen if the user asked to create a PubIdType and the destination group indicated in the PubIdType did not exist.  The "AttributeName" parameter would be "dgName" and the "AttributeValue" parameter would be the value that the user passed in the "dgName" field.  Same type of thing could, theoretically, happen for 2106.  In general, these two response codes are parameterized with AttrName and AttrValue to cover the fact that the protocol data structures allow for the creation of objects that have _object relationships_, and the object relationships that the requestor might be asking to establish may not be there (2105) or may not allow for the relationship to be established (2106).

  11. (p.28)The destination groups associated with a route group are represented by the dgName attribute IN THE ROUTE GROUP TYPE so the association direction seen in page 11 must be in the opposite direction (from RouteGroup to DestinationGroup), or, the attribute representing the association must be in the DestGrpType (defined in page 33). Moreover, the attribute name is different in page 11 (destGrpRef) and page 28 (dgName).

17)    KJC:  The XSD is authoritative and correct.  The dgNames are in the Route Group and are of type "ObjNameType".  You are correct that the "dgName" element description in the text refers to a "DestGrpType" but should refer to the ObjNameType.

  12.  We propose to add an element representing a name in BasicObjType, so the primary key of BasicObjType will be rant+rar+name. The problem is that in the BasicObjType, there is no primary key (rant and rar don't identify uniquely an instance of BasicObjType). For example, two route groups can have the same rant and rar but different names.

KJC:  The rarId should not be in the primary key.  The rarId is simply meta-data to indicate the "creator".  But with respect to the question of having the "name" in the BasicObjType.... It was originally intended that the BasicObjType would contain the "name" element as well.  However, that was moved out due to the couple object types where an object did not have a "name" (e.g. a Route Offer Request Type or a Pub Id Type).  If we can work out a clean way to move the "name" back into the BasicObType and still account for the other object types that do not have "names" then I'm all for it.  An alternative approach would be to make the "ObjKeyType" an abstract base type, and have each object type define its concrete version of that abstract base type.  Then the BasicObjType would just contain an instance of the abstract ObjKeyType.  But that seemed to get un-necessarily fancy to just solve an issue of elegance rather than an issue of practicality.  Hence the current approach.

  13. (p.29-30) Correction: In the SourceIdentType definition (p.29), one of the attribute is sourceIdentLabel. In the explanation (p.30), the same attribute is named sourceIdentRegex.

KJC:  You are correct.  The text needs to be fixed.

  14. (p. 27) The element "dgName" of a route group cannot be of type "ObjNameType" because the elements which identify a destination group are "rant" and "dgName". In this case, how to reference a destination group associated with a route group using a foreign key "dgName" which is not a primary key for a destination group. Same questions p. 39.

KJC:  The document is correct that it is the dgName element and it is of type "ObjNameType".    The following text from the document hopefully make clear the answer to your point:

dgName: Set of zero or more names of DestGrpType object
        instances.  Each dgName name, in association with this Route
        Group's registrant ID, uniquely identifies a DestGrpType object
        instance whose public identifiers are reachable using the
        routing information housed in this Route Group.  An intended
        side affect of this is that a Route Group cannot provide routing
        information for a Destination Group belonging to another
        registrant.

  15. (p. 48) Redefinition of RteRecType with error (the extension from BasicObjType is missing - see the first definition p. 47).

KJC:  You are correct.  That second XSD snippet for RteRecType should be deleted form the text.

16. (p.10) In the diagram, an organization has the attributes OrgId and OrgName. But, the organization type is not defined in the standard. Also, in the standard, an organization is referenced (and implicitly identified) by an OrgIdType. Why there is no OrganizationType definition like for the other objects? We suggest to define an organization type with two elements : OrgId of type OrgIdType and OrgName of type ObjNameType.

KJC:  The Organization object in the picture is really just there a a notional concept.  The SPPP protocol does not manage the registrar or the registrant objects.  Those are to be managed outside of the protocol.  From the protocol perspective there is no need for an OrgObjType or an OrgName element

________________________________
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: Mickael MARRACHE <[email-masked]>
Date: Thu, 3 Mar 2011 14:41:13 +0200

Hey,

Thank you for your answers.

2 . It's just a suggestion to add in page 11 an arrow from TN to RouteRecord
in order to represent the optionnal association specified in the XSD.

3.  Sorry but we did not understand your response. The problem is that we
did not understand how the client and server will work. We understand that
there are two possibilities. The first is that a client will send many
requests (without waiting the corresponding responses) using a single
logical connection (at transport level, for example TCP) to the server. In
this case, the server will answer for all requests to the same client port
(because the client use a single logical connection). How you can be sure
that the responses will arrive in order to the client ? We need to force the
server to treat the requests in order, but how it can be done with a
multi-threaded server? Or the clientTransId has to be mandatory?
The second possibility is that a client will always send only one request by
logical connection. In this case, the server will send the response for each
request using the corresponding logical connection. Then, in this case, the
clientTransId is not needed.

5. Yes, the "problem" is that the term "request" is used for the general
request (the spppUpdateRequest type) and is used for the specific requests
elements in the general request (the BasicRqstType type). If you don't want
to use the term "transaction", maybe it's better to change the name
"clientTransId" to "clientRqstId".
In the paragraph defining the "rqst" element (page 18), the term "actions"
is used to represent the specific requests(BasicRqstType) and in the bottom
of the page (the last sentence), the expression "All update request objects"
is used.

8.  Same question as 3 but with query requests.

11. In page 28, we see that the route group type includes an element dgName
representing the destination groups associated with the route group. Because
the association is represented by an element in the route group (dgName),
the direction of the association from destination group to route group (in
page 11) must be in the opposite direction. It's the same logic that for the
dgName element in PubIdType (page 39), because the element representing the
association is in PubIdType, the direction of the association (in page 11)
is from Public identifier to destination group.
Another thing, in page 11, the element which represents a destination group
in the public identifier is destGrpRef. But, in page 39, the same element is
named dgName.

12. We are working on it.

Thanks

On Thu, Mar 3, 2011 at 12:40 AM, Cartwright, Ken <[email-masked]>wrote:

>  Hello “Two students working on SPPP protocol” :-) :
>
>
>
> Thanks so much for your very thorough review of the SPPP protocol
> document.  Please see my responses to your comments below.  We will
> incorporate your feedback in the next rev of the document.
>
>
>
> Ken
>
>
>  ------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Mickael MARRACHE
> *Sent:* Tuesday, March 01, 2011 4:32 PM
> *To:* [email-masked]
> *Subject:* [drinks] Questions/Suggestions on draft of SPPP protocol
>
>
>
> KJC:  Registrant and Registrars are uniquely identified by their
> identifier, and the OrgIdType holds such an identifier.  The textual
> description that says something about an registrant name or registrant name
> is not accurate.  We will fix that text.
>
>
> KJC:  I’m not sure what is meant by this comment.  The XSD shows the
> optional relationship between PubIdType and Route Records.  Maybe you could
> clarify the comment.
>
>
> KJC:  Yes.  Any SPPP server worth it’s salt would be multi-threaded.  It is
> up to the client to decide if it wants to open more then one HTTPS
> connection and submit requests concurrently.  However, it would ultimately
> be a matter of policy as to how many concurrent HTTPS connections an SPPP
> server would allow to be open by each registrar.  But if you are talking
> about “pipelining” then this is really a question that would relate to the
> SPPP transport document (the SPPP over SOAP and HTTPs document, the one that
> contains the WSDL) rather than one relating to this document.  Whether an
> SPPP server would support pipelining I think would be a policy decision.  In
> any case the protocol requires a standard request-reply model so requests on
> a given HTTP connection must be replied to in the same order that they were
> sent.  If the SPPP Protocol document and the SPPP over SOAP and HTTPs
> documents do not together make this clear please let me know where you feel
> that the working should be changed.
>
>
> KJC:  Are you referring to the fact that the message element name in the
> WSDL is “rqst” and the element name in the XSD is “rqst”?  If that is your
> point then it would probably be best to rename the element in the WSDL to
> “rqstMsg”.  I’d prefer not to add in the word “Trans” here.
>
> KJC:  Object level errors will be the rare exception, so traffic is not a
> practical concern.  Introducing a separate identifier that the client must
> generate and then adding into the XSD an element to optionally house that
> identifier on the way in and then echoing it back out is un-necessary.  It
> is safer and clearer to just echo back the erroneous object.
>
>
> KJC:  Similar response as the one provided above for requests.  Requests
> and replies over a single HTTP connection must be responded to in the order
> that they are received.  But that’s not to say that multiple concurrent HTTP
> connections cannot be open from a single registrar.
>
>
> KJC:  The first column is the “Result Code” the second column is the result
> code text.  I think you suggestion to rename that column to “Result Message”
> is a good one.
>
>
>   10. (p.23-24) For error codes 2105 and 2106, which attribute to choose
> for the message?(The error is not specific to an attribute but is specific
> to an object).
>
>
>
> KJC:  For 2105 consider what would happen if the user asked to create a
> PubIdType and the destination group indicated in the PubIdType did not
> exist.  The “AttributeName” parameter would be “dgName” and the
> “AttributeValue” parameter would be the value that the user passed in the
> “dgName” field.  Same type of thing could, theoretically, happen for 2106.
> In general, these two response codes are parameterized with AttrName and
> AttrValue to cover the fact that the protocol data structures allow for the
> creation of objects that have _*object relationships*_, and the object
> relationships that the requestor might be asking to establish may not be
> there (2105) or may not allow for the relationship to be established (2106).
>
>
> 17)    KJC:  The XSD is authoritative and correct.  The dgNames are in the
> Route Group and are of type “ObjNameType”.  You are correct that the
> “dgName” element description in the text refers to a “DestGrpType” but
> should refer to the ObjNameType.
>
>
> KJC:  The rarId should not be in the primary key.  The rarId is simply
> meta-data to indicate the “creator”.  But with respect to the question of
> having the “name” in the BasicObjType…. It was originally intended that the
> BasicObjType would contain the “name” element as well.  However, that was
> moved out due to the couple object types where an object did not have a
> “name” (e.g. a Route Offer Request Type or a Pub Id Type).  If we can work
> out a clean way to move the “name” back into the BasicObType and still
> account for the other object types that do not have “names” then I’m all for
> it.  An alternative approach would be to make the “ObjKeyType” an abstract
> base type, and have each object type define its concrete version of that
> abstract base type.  Then the BasicObjType would just contain an instance of
> the abstract ObjKeyType.  But that seemed to get un-necessarily fancy to
> just solve an issue of elegance rather than an issue of practicality.  Hence
> the current approach.
>
>
>   13. (p.29-30) Correction: In the SourceIdentType definition (p.29), one
> of the attribute is sourceIdentLabel. In the explanation (p.30), the same
> KJC:  The document is correct that it is the dgName element and it is of
> type “ObjNameType”.    The following text from the document hopefully make
> clear the answer to your point:
>
>
>
>         instances.  *Each dgName name, in association with this Route
> *
> objects? We suggest to define an organization type with two elements :
> OrgId of type OrgIdType and OrgName of type ObjNameType.
>
>
>
> KJC:  The Organization object in the picture is really just there a a
> notional concept.  The SPPP protocol does not manage the registrar or the
> registrant objects.  Those are to be managed outside of the protocol.  From
> the protocol perspective there is no need for an OrgObjType or an OrgName
> element
>
> ------------------------------
> 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: Thu, 3 Mar 2011 10:02:13 -0500

Thanks for your comments.  See my thoughts below.

Ken
________________________________
From: Mickael MARRACHE [mailto:[email-masked]]
Sent: Thursday, March 03, 2011 7:41 AM
To: Cartwright, Ken; [email-masked]
Subject: Re: [drinks] Questions/Suggestions on draft of SPPP protocol

Hey,

2 . It's just a suggestion to add in page 11 an arrow from TN to RouteRecord in order to represent the optionnal association specified in the XSD.

KJC:  Ok.

3.  Sorry but we did not understand your response. The problem is that we did not understand how the client and server will work. We understand that there are two possibilities. The first is that a client will send many requests (without waiting the corresponding responses) using a single logical connection (at transport level, for example TCP) to the server. In this case, the server will answer for all requests to the same client port (because the client use a single logical connection). How you can be sure that the responses will arrive in order to the client ? We need to force the server to treat the requests in order, but how it can be done with a multi-threaded server? Or the clientTransId has to be mandatory?
The second possibility is that a client will always send only one request by logical connection. In this case, the server will send the response for each request using the corresponding logical connection. Then, in this case, the clientTransId is not needed.

KJC:  The transport (SPPP over SOAP and HTTPs) document describes a standard request-reply model over SOAP and HTTPs.  Within a given thread in the client the client will issue a soap request, the server will receive it, the server will respond to it, the client will read the response, the client will then send its next request, etc.  However, the server, and almost certainly the clients as well, will be multi-threaded.  This means that a given client can have more than one thread that is generating requests and reading replies, and the server will have more than one thread that is handling requests and sending replies.  clientTransId is not required to correlate requests and replies.

5. Yes, the "problem" is that the term "request" is used for the general request (the spppUpdateRequest type) and is used for the specific requests elements in the general request (the BasicRqstType type). If you don't want to use the term "transaction", maybe it's better to change the name "clientTransId" to "clientRqstId".
In the paragraph defining the "rqst" element (page 18), the term "actions" is used to represent the specific requests(BasicRqstType) and in the bottom of the page (the last sentence), the expression "All update request objects" is used.

KJC:  Ok.  We'll find a way to get these locations in the text and these couple element names precisely aligned in the next rev of the document.

KJC:  Same reply as above.

11. In page 28, we see that the route group type includes an element dgName representing the destination groups associated with the route group. Because the association is represented by an element in the route group (dgName), the direction of the association from destination group to route group (in page 11) must be in the opposite direction. It's the same logic that for the dgName element in PubIdType (page 39), because the element representing the association is in PubIdType, the direction of the association (in page 11) is from Public identifier to destination group.
Another thing, in page 11, the element which represents a destination group in the public identifier is destGrpRef. But, in page 39, the same element is named dgName.

KJC:  You're saying that you feel that the arrows in the diagram point in the other direction.  Ok, we can change that but it really depends on how you interpret the diagram.  Te diagram is of course notional.

Thanks

On Thu, Mar 3, 2011 at 12:40 AM, Cartwright, Ken <[email-masked]<mailto:[email-masked]>> wrote:
Hello "Two students working on SPPP protocol" :-) :

Ken

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mickael MARRACHE
Sent: Tuesday, March 01, 2011 4:32 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [drinks] Questions/Suggestions on draft of SPPP protocol

---

From: Mickael MARRACHE <[email-masked]>
Date: Thu, 3 Mar 2011 17:53:14 +0200

---------- Forwarded message ----------
From: Mickael MARRACHE <[email-masked]>
Date: Thu, Mar 3, 2011 at 5:52 PM
Subject: Re: [drinks] Questions/Suggestions on draft of SPPP protocol
To: "Cartwright, Ken" <[email-masked]>

3. Okay, understood. So, if clientTransId is not required, in which case to
use it?

11. Okay, so we take it as a general overview of the data model. Another
thing, why not to use a rteGrp element in DestGrpType to represent the
association between destination group and route group? We say this because
the key of the lookup is a public identifier. From the asked public
identifier, we get the corresponding destination group using the dgName
element. From the destination group, we get the corresponding route group
using the rteGrp element. Finally, from the route group, we get the route
records associated to it.

Thanks

On Thu, Mar 3, 2011 at 5:02 PM, Cartwright, Ken <[email-masked]>wrote:

> *From:* Mickael MARRACHE [mailto:[email-masked]]
> *Sent:* Thursday, March 03, 2011 7:41 AM
> *To:* Cartwright, Ken; [email-masked]
> *Subject:* Re: [drinks] Questions/Suggestions on draft of SPPP protocol
>
>
>
> Hey,
>
> 2 . It's just a suggestion to add in page 11 an arrow from TN to
> RouteRecord in order to represent the optionnal association specified in the
> XSD.
>
>  KJC:  Ok.
>
>
> The second possibility is that a client will always send only one request
> by logical connection. In this case, the server will send the response for
> each request using the corresponding logical connection. Then, in this case,
> the clientTransId is not needed.
>
>  KJC:  The transport (SPPP over SOAP and HTTPs) document describes a
> standard request-reply model over SOAP and HTTPs.  Within a given thread in
> the client the client will issue a soap request, the server will receive it,
> the server will respond to it, the client will read the response, the client
> will then send its next request, etc.  However, the server, and almost
> certainly the clients as well, will be multi-threaded.  This means that a
> given client can have more than one thread that is generating requests and
> reading replies, and the server will have more than one thread that is
> handling requests and sending replies.  clientTransId is not required to
> correlate requests and replies.
>
>
>  KJC:  Ok.  We’ll find a way to get these locations in the text and these
> couple element names precisely aligned in the next rev of the document.
>
>
>  KJC:  You’re saying that you feel that the arrows in the diagram point in
> the other direction.  Ok, we can change that but it really depends on how
> you interpret the diagram.  Te diagram is of course notional.
>
>
>
>

---

From: "Cartwright, Ken" <[email-masked]>
Date: Fri, 4 Mar 2011 15:05:16 -0500

Here is the next updated version of the document that incorporates the following changes, which resulted from comments on the list.  There are no other outstanding comments that I am aware of.

1)       Text:  Altered the data model diagram so that it does not imply that there is a first class object type in the XSD that represents an organization.
2)       XSD Tweak:  Renamed BasicRqstType to BasicUpdateRqstType.
3)       XSD Tweak:  Syed made the change to remove the "prefix" flag from TNRType.
4)       Text:  Changed the direction that the arrow points from Destination Group to Route Group in the data model diagram.
5)       Text:  Fixed the text description of the terms "Registrant" and "Registrar" that defines their unique identifiers.
6)       XSD Tweak:  Renamed "rqst" to "rqstObj" to give it a clearer distinction from its parent spppUpdateRequest and spppQueryRequest elements.  This also has the added benefit of aligning its name with the existing "element within the RqstObjResultCodeType.
7)       Text:  Renamed column two of the result code table to Result Message.
8)       Text:  Removed the second definition of RteRecType in the text on page 48, and corrected missing optional priority field in XSD.
9)       Text:  Added in the statements to the Add Public Identifier section that defines the elements that comprise the unique key of each type of Public Identifier.  Also slightly word-smithed these sections.
10)   XSD Tweak:  Changed the multiplicity of the pi element in getPubIdsRqstType.  Allowing it to be zero is not a good idea because there could be a lot of them.
11)   Text:  Added Mickael Marrache and Samuel Melloul to the acknowledgements.

I will also submit this update today as draft-ietf-drinks-spprov-05.

Ken

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cartwright, Ken
Sent: Thursday, March 03, 2011 10:02 AM
To: Mickael MARRACHE; [email-masked]
Subject: Re: [drinks] Questions/Suggestions on draft of SPPP protocol

Ken

Hey,

Thanks

Ken