RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt
David Burdett <david.burdett@commerceone.com> Thu, 09 September 1999 17:58 UTC
Received: from one.eListX.com (one.elistx.com [209.116.252.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06304 for <trade-archive@lists.ietf.org>; Thu, 9 Sep 1999 13:58:05 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa22662; 9 Sep 99 13:33 EDT
Received: from mail.commerceone.com by one.eListX.com id aa22650; 9 Sep 99 13:33 EDT
Received: by ip5-19.5.20.172.in-addr.arpa with Internet Mail Service (5.5.2448.0) id <R4XGVZ1N>; Thu, 9 Sep 1999 10:31:40 -0700
Message-ID: <123B7EB05559D311B0D900A0C9EA3D7604F236@NEPTUNE>
From: David Burdett <david.burdett@commerceone.com>
To: "'rudolf@metechnology.com'" <rudolf@metechnology.com>, "IOTP Trade List (E-mail)" <ietf-trade@lists.eListX.com>
Subject: RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt
Date: Thu, 09 Sep 1999 10:31:45 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
I never completely responded to this email so see comments marked below with a ##. David -----Original Message----- From: Rudolf Hornig [mailto:rudolf@metechnology.com] Sent: Wednesday, September 01, 1999 12:22 AM To: IOTP Trade List (E-mail) Cc: =?iso-8859-1?Q?Varga_Andr=E1s?=@metechnology.com Subject: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt Here comes some comments on the lates IOTP draft: ======================================================================== 2.2.1 Offer Exchange ... C <-- M OFFER RESPONSE. Components: Organisation(s) (Consumer, DeliverTo, Merchant, Payment Handler, Customer Care); Order; Pay Amount; Delivery; Optional Offer Response Signature that signs other components RH> "Pay Amount" should be "Paymnet". RH> Status and TradingRoleData are missing, and also from the following RH> list. ##Fixed## ======================================================================== 2.2.2 Payment Exchange ... C --> M Component: Brand List Selection 4. Merchant checks Brand Selection, creates a Payment Amount information, optionally signs it to authorise payment and sends it to the Consumer C <-- M Component: Pay Amount; Organisation(s) (Merchant and Payment Handler); Optional Offer Response Signature that signs other components 5. Consumer checks the Payment Amount information and if OK requests that the payment starts by sending information to the Payment Handler C --------> P PAYMENT REQUEST. Components: Pay Amount; Organisations (Merchant and Payment Handler); Optional Offer Response Signature that signs other components; Pay Scheme 6. Payment Handler checks information including optional signature and if OK starts exchanging Pay Scheme components for selected payment brand and payment protocol C <-------> P PAYMENT EXCHANGE. Component: Pay Scheme 7. Eventually payment protocol messages finish so Payment Handler sends Pay Receipt and optional signature to the Consumer as proof of payment C <-------> P PAYMENT RESPONSE. Components: Pay Receipt; Payment Note; Optional Offer Response Signature; Optional Payment Receipt Signature that binds the payment to the Offer RH> - in general: "Payment Amount" -> "Payment" RH> "Pay Scheme" -> "PaySchemeData" RH> - in 5. There are missing components like: Status; BrandList; RH> BrandSelection; TradingRoleData RH> - in 7. Missing components: Status; PaySchemeData; TradingRoleData; RH> - These components are also missing from the list following Figure 3 ##Fixed## ======================================================================== 2.2.3 Delivery Exchange ... C --------> D DELIVERY REQUEST. Components: Delivery, Organisations: (Merchant, Delivery Handler, DelivTo); Order, Optional Offer Response Signature, Optional Payment Receipt Signature (from Payment Exchange) RH> Missing: Status; ConsumerDeliveryData; TradingRoledData 4. Delivery Handler checks information and authorisation. Starts or schedules delivery and creates and then sends a delivery not tot the Consumer which can RH> sends a delivery NOTE TO the Consumer ... C <-------- D DELIVERY RESPONSE. Components: Delivery Note, Optional Delivery Response Signature RH> Missing: Status RH> These components are also missing from the list following Figure 4 ##Fixed## ======================================================================== 2.3 Scope of Baseline IOTP RH> Because the Inquiry and Ping transactions could be initiated RH> by any trading role, in the "supported Roles/Transaction table" RH> I would mention, that a Consumer should only be able to send RH> Inquiry and Ping transaction. Serving these transactions is RH> not a requirement as the Consumer role is represented by an RH> HTTP client (according to the http supplement) ##Changed MUST to MAY for consumer role## ======================================================================== 3.3.1 Transaction Id Component ... IotpTransId Contains data which uniquely identifies the IOTP Transaction. It must conform to the rules for Message Ids in [RFC 822]. RH> I'm not sure about this, but [RFC 822] defines the message id RH> as: <some.string@shost>, however NMTOKEN doesn't allow a '@' RH> character... ##Changed NMTOKEN to CDATA## ======================================================================== 3.6.1 Extra XML Elements ... In order to ensure that documents containing "IOTP:Critical" are valid, it is declared as part of the DTD for the extra element as: IOTP:Critical (True | False ) 'True' RH> Haven't found it in the actual DTD. RH> This means it SHOULD BE DECLARED as part of the extended DTD ? ##YES!## ======================================================================== 4.5.2.3 Processing Non-Duplicate Message ... [Note] This approach to handling of duplicate input messages means, if absolutely "identical" messages are received then absolutely "identical" messages are returned. This also applies to Inquiry and Ping transactions when in reality the state of a transaction or the processing ability of the servers may have changed. If up-to-date status of transactions or servers is required, then an IOTP transaction with a new IotpTransId must be used. ^^^ [Note End] RH> However in "9.2.1 Baseline Transaction Status Inquiry IOTP Transaction:" ... TRANSACTION REFERENCE BLOCK A Trading Role making an inquiry must use the identical Transaction Id ^^^^^^^^^ Component (see section 3.3.1) that was in the original transaction. The ... RH> The two requirements are inconsistent as far as I see. RH> BTW. Is it really required for IOTP to cache all the Ping and RH> Inquery transactions ??? (They do not change anything in the server) RH> If idempotency is required, I would suggest using a new message ID RH> with the same IotpTransId, but this case every trading role have RH> to maintain it's last MessageID, which is not nice at all... RH> Or perhaps changing the TimeStamp of the MessageID comp. is enough RH> to force the server to give back fresh information ???? (ugly also) RH> Maybe a trading role wants to inquery a RH> transaction a week later, and the last used message id for RH> this transaction is not present... Any hint on this? ##Resolved with other emails## ======================================================================== 4.6.2.1 Check for Errors in Block Sequence ... o Offer Response Block. Check as follows: - if the Offer Response Block is not part of an IOTP Transaction that is recognised by the Consumer role then there is a Hard Error, otherwise RH> During brand independent purchase without authentication, RH> OfferResponse (with TPO) is the first message received by the RH> Consumer. ## Fixed by adding initial test that says ... "- if the Offer Response Block is part of a Brand Independent Offer Exchange (see section 9.1.2.2) then there is no sequence checking as it is part of the first message received, otherwise " ## ======================================================================== 7.11 Payment Receipt Component ... Note that either the *PayReceiptRefs* attribute, the PackagedContent element, or both must be present. RH> change to: PayReceiptNameRefs attribute... ##Fixed## ======================================================================== 9.1 Authentication and Payment Related IOTP Transactions ... o Brand Independent Offer. This is also an Offer Trading Exchange. However, in this instance, the content of the Offer Response does depend on the Brand selected. RH> Change to: does not depend on the Brand selected. ##Fixed## ======================================================================== 9.1.2.1 Brand Dependent Offer Document Exchange ... On receiving an Offer Response IOTP Message (see below) the Consumer may either: o generate and send the next IOTP Message in the IOTP transaction and send it to the required Trading Role. This is dependent on the IOTP Transaction, or o indicate failure to continue with the IOTP Transaction by sending a Cancel Block back to the Consumer containing a Status Component with a ^^^^^^^^ StatusType of Offer, a ProcessState of Failed and the CompletionCode (see section 7.16.4) set to either: ConsCancelled or Unspecified. RH> Change to: Merchant ##Fixed## ======================================================================== 9.1.4.3 Delivery Response IOTP Message ... The Delivery Response IOTP Message contains a Delivery Response Block and an options Signature Block. ^^^^^^^ RH> Change: optional ##Fixed## ======================================================================== 11.1.1 Definition of Payment Instrument ... All Payment Instruments have a number, typically an account number, by ^^^^^^^^^^^^^ which the Payment Instrument can be identified. RH> I'm not sure, but there are some payment protocols, which RH> enable anonym payment (GeldKarte ???). Is this applys also RH> for these instruments ??? ## Changed All to Most## ======================================================================== Hope this helps a little, polishing the final version :) Regards, Rudi -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rudolf Hornig (Rudolf@MeTechnology.com), Project Manager MeTechnology Ltd. Hungary - a Brokat Company -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ----------------------------------------------------------------------- Message addressed to: ietf-trade@lists.elistx.com Archive available at: http://www.elistx.com/archives/ietf-trade/ To (un)subscribe send a message with "subscribe" or "unsubscribe" in the body to: ietf-trade-request@lists.elistx.com
- RE: Comments on draft-ietf-trade-iotp-v1.0-protoc… David Burdett
- RE: Comments on draft-ietf-trade-iotp-v1.0-protoc… David Burdett
- RE: Comments on draft-ietf-trade-iotp-v1.0-protoc… David Burdett
- Re: Comments on draft-ietf-trade-iotp-v1.0-protoc… Yoshiaki KAWATSURA
- Re: Comments on draft-ietf-trade-iotp-v1.0-protoc… Yoshiaki KAWATSURA
- Re: Comments on draft-ietf-trade-iotp-v1.0-protoc… Donald E. Eastlake 3rd
- RE: Comments on draft-ietf-trade-iotp-v1.0-protoc… Rudolf Hornig
- RE: Comments on draft-ietf-trade-iotp-v1.0-protoc… David Burdett
- Re: Comments on draft-ietf-trade-iotp-v1.0-protoc… Yoshiaki KAWATSURA
- Comments on draft-ietf-trade-iotp-v1.0-protocol-0… Rudolf Hornig