Subject: My Comments for IOTP DSIG.
From: Yoshiaki KAWATSURA <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Date: Fri, 30 Jul 1999 15:58:47 +0900 (JST)

Kent,
I have sent the following my comments in July 1st but it seems to me
that there is no response....

No.1:
I do not know why but it seems to me that your draft has dropped "="
in the whole your XML example
for example:
   <Digest DigestAlgorithmRef "D.1">
       <Locator href "resource locator"/>
       <Value>
            (Digest value)
       </Value>
   </Digest>  .

You should revise this for conforming to XML Specification as follows;
   <Digest DigestAlgorithmRef="D.1">
       <Locator href="resource locator"/>
       <Value>
            (Digest value)
       </Value>
   </Digest>  .

Additional,
In 4.3.8 Prameter:
   <Algorithm ID A1 type "digest" name "urn:ibm:dom-hash">
           <Parameter type 'AlgorithmRef'>A2</Parameter>
   </Algorithm>
   <Algorithm ID A2 type "digest" name "urn:fips:sha1">
   </Algorithm>
   <Algorithm ID A3 type "signature" name "urn:ibm:hmac">
           <Parameter type 'AlgorithmRef'>A1</Parameter>
   </Algorithm>

This has been dropped quotation. Please change as follows:

   <Algorithm ID="A1" type="digest" name="urn:ibm:dom-hash">
           <Parameter type='AlgorithmRef'>A2</Parameter>
   </Algorithm>
   <Algorithm ID="A2" type="digest" name="urn:fips:sha1">
   </Algorithm>
   <Algorithm ID="A3" type="signature" name="urn:ibm:hmac">
           <Parameter type='AlgorithmRef'>A1</Parameter>
   </Algorithm>

----------------------
No.2:
In 4.3.8 Parameter:

On one hand, the type attribute is defined as PCDATA in 4.3.8, on the
other hand, this attribute is defined as CDATA in Chapter7(Signature
DTD)
Which is correct?

---------------------
No.3:
In 5.1.2 SHA1:
--
5.1.2 SHA1

   Surface string digest algorithm designed by hte US government for use
                                               ^^^
   with the Digital Signature Standard. This algorithm produces a 160-
   bit hash value.
--
What does "hte" mean?

---------------------
No.4:
On one hand, the child element of Parameter is defined as ANY in
4.3.5, on the other hand, this element is defined as #PCDATA in
Chapter7(Signature DTD)

Which is correct?

-------------------
No.5:
Why did you swap between Certificate Component and Signature Component?

S.T.

Old Draft: <!ELEMENT IOTPSignatures (Signature+, Certificate*) >
->
Current Draft: <!ELEMENT IOTPSignatures (Certificate*, Signature+) > 

------------------

Yoshiaki Kawatsura : E-mail [email-masked]
 Business & Information Systems Development Division, Hitachi,Ltd.
Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: 'Ietf Trade WG' <[email-masked]>
Subject: 
Date: Thu, 29 Jul 1999 16:40:08 -0700
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I've decided to leave Mondex International after just over three years and
join Commerce One (www.commerceone.com) an e-commerce company focusing on
business to business eCommerce.

I just want to assure everyone that my and Commerce One's support for IOTP
and the IETF Trade Working Group continues.

Details of my new email address and telephone no which are effective
immediately are below, although emails sent to my old Mondex email address
will still get to me for a while.

Regards

David Burdett

Advanced Technology, CommerceOne
1600 Riviera Ave, Suite 200, Walnut Creek, CA 94596, USA
Tel: +1 (925) 941 4422; Email: [email-masked]

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
Cc: [email-masked]
Cc: [email-masked]
Subject: RE: My Comments of IOTP Spec Release4
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Thu, 29 Jul 1999 23:57:23 +0900 (JST)
Lines: 254
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David,
Sound good to me for the following issues.
Thanks,
--
Yoshiaki Kawatsura

>>>>> Wed, 28 Jul 1999 03:40:12 +0100,
	[email-masked] said:

> > ---
> > 1.6 Document Structure (Page 14 )
> > DigiCash is the company name so please change to eCash.
> ## agreed ... but Digicash was actually in section 1.5 Scope of Document##
> 
> > ---
> > 
> > 3.1.1 (Page34) 
> > Minor misspelling:
> >  |  |-Certificate Comp. < Certificate Component (0ptional) Used to chec
> >                                                  ^
> > Please change from integer "0" to Alphabet "O".
> ##Noted##
> 
> > ---
> > 
> > 3.3.2  MsgId Component
> > There is no description of LangPrefList and CharSetPrefList.
> ## Added as follows
> LangPrefList ...
> 	Optional list of Language codes that conform to [XML] Language
> Identification. It is used by the sender to indicate, in preference
> sequence, the languages that the receiver of the message ideally should use
> when generating a response. There is no obligation on the receiver to
> respond using one of the indicated languages, but using one of the languages
> is likely to provide an improved user experience.
> 
> CharSetPrefList ...
> 	Optional list of Character Set identifiers that conform to [XML]
> Characters. It is used by the sender to indicate, in preference sequence,
> the character sets that the receiver of the message ideally should use when
> generating a response. There is no obligation on the receiver to respond
> using one of the character sets indicated, but using one of the character
> sets is likely to provide an improved user experience.
> 
> Also added the following explanation to Section 3.8 Identifiying Languages
> as follows ...
> A sender of a message, typically a Consumer can indicate a preference for a
> language, and a character set by specifying a list of preferred
> languages/character sets in a Message Id Component (see section 3.3.2). Note
> that there is no obligation on the receiver of such a message to respond
> using one of the listed languages/character sets as they may not have the
> technology to be able to do it. It also means that the ability to handle
> these lists is not a requirement for conformance to this specification.
> However the ability to respond, for example using one of the stated
> languages/character sets is likely to provide a better user experience.
> 
> These attributes were added to meet and indicated requirement of SET version
> 2.0. Apologies for not discussing it on the list ... no doubt if anyone has
> any contrary views you'll let me know.
> ##
> 
> > --
> > 3.4.1 Trading Role Element
> > There is no definition the IotpMsgIdPrefix for DelivTo.
> > DelivTo Trading Role does not use this because DelivTo does not
> > send the IOTP Message. But IotpMsgIdPrefix is mandatory.
> > Should we set "C" as the Consumer?
> ##Yes ... clarified spec and suggested "C" for the DelivTo role as a
> guideline##
> 
> > ---
> > 
> > 3.6.1 Extra XML Elements
> > IOTP:Critical (True|False) #TRUE
> > should be changed to
> > IOTP:Critical (True|False) 'True' 
> ##Corrected##

> > 4.5.2.3 Processing Non-Duplicate Message
> > Please add the description of the transient error as follows:
> > Current:
> >       o if no hard errors result, then processing the message and
> >         generating an output message, if required, for return to
> >         the sender of the Input Message
> > New:
> >       o if no hard error and transient error result, 
> >         then processing the message and
> >         generating an output message, if required, for return to
> >         the sender of the Input Message
> ##Agreed. Exact new wording as follows:
> 	"o if neither hard errors nor transient errors result, then
> processing the message and generating an output message, if required, for
> return to the sender of the Input Message"
> 
> 	Also changed ServerLogic.txt and ConsumerLogic.txt files.
> ##
> 

> > 
> > 7.4 Trading Role Information Request Component
> > In 7.4,
> > 
> > -- Start
> >       o a Merchant requesting that a Consumer provides Organization
> >         Components for the Consumer and DelivTo Trading Roles
> > -- End
> > 
> > We get only one Trading Role when we use TradingRoleList because 
> > TradingRoleList defines as NMTOKEN. So I suggest to change from
> > NMTOKEN to NMTOKENS.
> ##Agreed##
> 

> > 7.10 Payment Scheme Component
> > There is no description for the PaymentRef in PatSchemeData.
> ## Added definition as follows:
> 	An Element Reference (see section 3.5) to the Payment Component (see
> section 7.9) to which this Pay Scheme Data Component relates. It is required
> unless the Pay Scheme Data is part of an Transaction Inquiry Status
> Transaction (see section 9.2.1).
> ##
> 

> > 7.10 Payment Scheme Component
> > The PaymentRef Element is not used when Inquiry transaction is
> > processed.  I suggest the PaymentRef changes from #REQUIRED to
> > #IMPLIED and we should add the note that the PaymentRef must use in
> > the Payment Transaction but does not use in the Inquiry Transaction.
> ##Agreed. For details see previous comment##
> 

> > 7.15.3 Delivery Completion Codes
> > There is no description about the recovery possibility for
> > DelivCancelled and Confirmed.
> ##They should both be "Recovery is not possible."##
> 
> > 9.2.1 Baseline Transaction Status Inquiry IOTP Transaction
> > In 6.1.3:
> > --Start
> >       o Transaction Status Inquiry. The Inquiry Response Block may
> >         be digitally signed to attest to the authenticity of the
> >         response
> > --End
> > 
> > 
> > But there is no description about the signature of Inquiry Response
> > Message
> >  in 9.2.1 (and in 7.18 also.)
> ##Agreed.
> Added definitions for Inquiry Reuest Signature and Inqiuiry Reponse
> Signature as follows:
> 	7.18.7	Inquiry Request Signature Component
> 	If the Inquiry Request is being signed (see section 9.2.1) the
> Manifest Element of the Inquiry Request Signature Component should contain
> Digest elements of Inquiry Type Component, and if present, the Payment
> Scheme Component
> 
> 	7.18.8	Inquiry Response Signature Component
> 	If the Inquiry Response is being signed (see section 9.2.1) the
> Manifest Element of the Inquiry Response Signature Component should contain
> Digest elements of the Trading Response Block and the Status Component.
> 
> ... and in section 9.2.1 ...
> SIGNATURE BLOCK (INQUIRY REQUEST)
> 	If a signature block is present on the message containing the
> Inquiry Request Block then it may be checked to determine if the Inquiry
> Request is authorised.
> 
> 	If present, the Inquiry Request Signature Block (see section 8.12)
> contains the following components:
> 	o one Signature Component (see section 7.18)
> 	o one or more Certificate Components, if required.
> 
> 	Inquiry Response Blocks should only be generated if the Transaction
> is authorised.
> 
> 	[Note] 
> 	Digital signatures on an Inquiry Request is only likely to occur if
> the recipient of the request expects the Inquiry Request to be signed. In
> this version of IOTP this will require some kind of pre-existing agreement.
> This means that:
> 	o Consumers are unlikely to generate requests with signatures,
> although it is not an error if they do
> 	o the other trading roles may agree that digital signatures are
> required. For example a Payment Handler may require that an Inquiry Request
> is digitally signed by the Merchant so that they can check that the request
> is valid.
> 
> 	On the other hand if the original transaction to which the Inquiry
> relates was carried out over a secure channel (e.g. [SSL]) then it is
> probably reasonable to presume that if the sender of the Inquiry knows the
> Transaction Id component of the original message (including for example the
> timestamp) then the inquiry is likely to be genuine.
> 
> 	 [Note End] 
> 
> ... and ...
> 	SIGNATURE BLOCK (INQUIRY RESPONSE)
> 	If a signature block is present on the message containing the
> Inquiry Response Block then it may be checked by the receiver of the block
> to determine if the Inquiry Response is valid.
> 
> 	If present, the Inquiry Response Signature Block (see section 8.13)
> contains the following components:
> 	o one Signature Component (see section 7.18)
> 	o one or more Certificate Components, if required.
> 
> 	 [Note] 
> 	Digital signatures on an Inquiry Response is only likely to occur if
> the recipient of the response expects the Inquiry Request to be signed. In
> this version of IOTP this will require some kind of pre-existing agreement.
> This means that:
> 	o Consumers are unlikely to generate responses with signatures,
> although it is not an error if they do
> 	o the other trading roles may agree that digital signatures are
> required. For example a Merchant may require that an Inquiry Response is
> digitally signed by the Payment Handler so that they can check that the
> request response is valid.
> 	 [Note End] 
> 
> ... also changed message flow for Transaction Status Inquiry to show
> optional signature on Inquiry Response.
> 

> > Additional, 
> > In 9.2.1: 
> > -- Start
> >      1 --> 2 INQUIRY REQUEST. IotpMsg: TransRef Block; Signature Block
> >              (optional); Inquiry Request Block
> > -- End
> > 
> > I could not find the description where the Consumer has to sign in 9.2.1
> > (and in 7.18 also.)
> ## It is unlikely that the consumer will have to sign. See Notes on
> Signature Block (Inquiry Response) and Signature Block (Inquiry Request).
> ##

> > 7.15.1 (Page134)
> > Minor misspelling:
> >  ConsCancelbled-> ConsCancelled
> ## Changed ##
> > --

> > Other:
> > 
> > The current IOTP Spec has not reflected the brand new IOTP-DSIG Draft
> > yet.  My thought is that we should split off the description of DSIG
> > as much as possible in order to avoid consistency
> ## In principle they need to be separate, but I don't think so for this
> version. I plan to update the IOTP spec to reflect the new dsig draft
> shortly. ##
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
Cc: [email-masked]
Cc: [email-masked]
Subject: Re: Invalid IotpTransId
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Thu, 29 Jul 1999 23:42:40 +0900 (JST)
Lines: 81
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David,
I think it is better not to include the original message in the all
Error Messages, since the Consumer's system is very hard to recognise
the original message when IotpTransId is corrupted even if the whole
original message is included in the Error Message. Therefore, this
original message included in the er ror message may be used only for
the debug.  
Additionally, we want to avoid the IOTP message getting fat.

>>>>> Mon, 26 Jul 1999 19:58:54 +0100,
	[email-masked] said:

> In Yoshiaki's other email he raised a good point. I've replied in a separate
> email to raise visibility ...
> 
> When I wrote this part of the spec (see below) I was debating whether or not
> to include the original input message since if you think about it, the data
> will probably have got through without corruption if it is well formed.
> However, it is so unlikely that the IotpTransId cannot be recognised that I
> thought it a good idea to include the original message. Your comment is
> making me think again.
> 
> What do folks think?
> 
> David
> 
> 
> > 4.5.2.1 Checking Structure and Message Identity
> > -- Start
> >   If the message is well formed but the IotpTransId cannot be identifie
> >   then generate an ErrorComponent with:
> > 
> >       o a Severity of HardError and an ErrorCode of AttMissing,
> > 
> >       o one PackagedContent containing the original Input Message,
> >         and
> > 
> >       o the second PackagedContent containing "IotpTransId" - the
> >         missing attribute.
> > 
> >   Insert the Error Component inside an Error Block with a new
> >   TransactionId component with a new IotpTransId and return it to the
> >   sender of the original message.
> > --End
> > I have two questions.
> > 
> > Question 1. If we include two PackagedContent Components in Error
> > Component, we have to decide the both Name element(s) so that Consumer
> > side OAC recognizes them and handles.
> > 
> > Question 2. This is the only case that the Original Input Message is
> > included in the Packaged Content of Error Component isn't it?
> > 
> 
> **********************************************************************************************
> 
> This Email and any attached files are confidential and may also be privileged. 
> If you are not the intended recipient, please notify the postmaster using email 
> address [email-masked] or call +44 171 557 5000 and ask for the 
> IT Helpdesk.  You should not copy this email and any attached files, use them 
> for any purpose or disclose the contents to any other person; all copies of the 
> Email and associated files in your possession should be destroyed.
> 
> Mondex International Limited
> 47-53 Cannon Street
> London EC4M 5SQ
> United Kingdom
> Registered No: 3122085, England
> 
> Phone:          +44 171 557 5000
> Fax:            +44 171 557 5200
> Email:          [email-masked]
> WebSite:        http://www.mondexinternational.com
> 
> *********************************************************************************************
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

Date: Thu, 29 Jul 1999 22:29:49 +0900
To: [email-masked], [email-masked]
From: Masaaki Hiroya <[email-masked]>
Subject: RE: Signature on a PayNote Component
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David

Thank you for adopting our proposal.

Masaaki

At 03:40 99/07/28 +0100, [email-masked] wrote:
> Masaaki
> 
> Good idea ... Payment Note added to Payment Response Signature.
> 
> David
> 
> -----Original Message-----
> From: Masaaki Hiroya [mailto:[email-masked]]
> Sent: Tuesday, July 06, 1999 12:41 AM
> To: [email-masked]; [email-masked]
> Subject: Signature on a PayNote Component
> 
> 
> 
> David
> 
> We need PayNote components to be signed together with
> PayReceipt components.
> 
> Some payment handlers need to issue receipts with 
> their own styles to display them visually using HTML or
> XML + style sheets besides the payment-scheme specific 
> receipts.
> 
> They should also be signed by the payment handlers to 
> be proved that they are issued by them.
> 
> The PayReceipt packaged contents will be passed to
> the payment bridges, so I think non-payment-scheme specific
> receipts issued by payment handlers should be contained 
> in PayNote packaged contents to avoid errors in the 
> payment bridges.
> 
> Therefore, we want the digest of the PayNote component 
> to be added to the Payment Receipt Signature component.
> 
> Masaaki
> 
> 
> -----
> Masaaki Hiroya
> Systems Development Laboratory
> Hitachi, Ltd.
> tel: +81-44-549-1531
> fax: +81-44-549-1640
> email: [email-masked]
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 
> **************************************************************************
********************
> 
> This Email and any attached files are confidential and may also be privile
ged. 
> If you are not the intended recipient, please notify the postmaster using 
email 
> address [email-masked] or call +44 171 557 5000 and ask for the 
> IT Helpdesk.  You should not copy this email and any attached files, use t
hem 
> for any purpose or disclose the contents to any other person; all copies o
f the 
> Email and associated files in your possession should be destroyed.
> 
> Mondex International Limited
> 47-53 Cannon Street
> London EC4M 5SQ
> United Kingdom
> Registered No: 3122085, England
> 
> Phone:          +44 171 557 5000
> Fax:            +44 171 557 5200
> Email:          [email-masked]
> WebSite:        http://www.mondexinternational.com
> 
> **************************************************************************
*******************
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
>  
-----
Masaaki Hiroya
Systems Development Laboratory
Hitachi, Ltd.
email: [email-masked]
tel: +81-44-549-1531
fax: +81-44-549-1640
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

Date: Thu, 29 Jul 1999 22:27:22 +0900
To: [email-masked], [email-masked],  [email-masked]
From: Masaaki Hiroya <[email-masked]>
Subject: RE: Handling Duplicate Messages
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David

I agree with you.
I think "MsgBeingProc" is better, too.
Besides, I agree to using ErrorCode="SystemBusy" when the server is busy.

Masaaki

At 03:40 99/07/28 +0100, [email-masked] wrote:
> Chris/Masaaki
>  
> Thanks for thinking this through. Propose the following changes to add a new
> type of Transient Error as Masaaki suggested. Details below.
>  
> David
>  
> Added new Error Code to indicate that "Message is being processed" called
> "MsgBeingProc". "ReqInProgress" which Masaaki thought of seems to suggest
> that it can only apply to a request when in fact it could also work with an
> exchange message such as a Payment Exchange. Its description is ...
> 
> "Message being processed. This error code is only used with a Severity of
> Transient Error. It indicates that the previous message, which may be an
> exchange message or a request message, is being processed and, if no
> response is received by the time indicated by the MinRetrySecs attribute,
> then the original message should be resent."
> 
> I also noticed that there isn't an error code to indicate that a "Server (or
> other system) Is Busy" so I've added another code called SystemBusy with a
> description of ...
> 
> "SystemBusy. This error code is only used with a Severity of Transient
> Error. It indicates that the system that received a message is currently too
> busy to handle the message. If no response is received by the time indicated
> by the MinRetrySecs attribute, then the original message should be resent.
> This code should be used when to indicate that a server (e.g. HTTP) 
> 
> [Note] If the server/system handling the Transport Mechanism (e.g. HTTP) is
> busy then a Transport Specific error message should be used instead of an
> IOTP Error message. This code should be used in association with IOTP
> servers/systems or other servers/systems to which the IOTP server is
> connected.
> [Note End]"
> 
> Added to section 4.5.2.2 Checking/Handling Duplicate Messages ...
> 
> 	"... If processing has not completed then generate an Error
> Component with a Severity of Transient Error and an Error Code of to
> indicate the message is being processed and send it back to the sender of
> the Input Message requesting that the original message be resent after an
> appropriate period of time."
> 
> ... and clarified section 4.5.2.3 Processing Non-Duplicate Message (CHECKING
> A SERVER IS AVAILABLE) to say ...
> 
> 	"... If the server is too busy, then it should generate an Error
> Component with a Severity of Transient Error and an Error Code of SystemBusy
> and send it back to the sender of the Input Message requesting that the
> original message be resent after an appropriate period of time."
> 
> 	 
> 
> ... and in PROCESS THE ERROR FREE INPUT MESSAGE changed ... 
> 
> *	if the Input message contains an Error Block with a Transient Error
> then wait for the required time then resend the previous message
> 
> ... to ...
> 
> *	if the Input message contains an Error Block with a Transient Error
> then wait for the required time then resend the previous message, if a
> response to the earlier message has not been received
> 
>  
> ... Also updated ServerLogic.txt and ConsumerLogic.txt
>  
> 
>  
> 
>   -----Original Message-----
> From: Smith, Chris [mailto:[email-masked]]
> Sent: Monday, July 26, 1999 7:08 AM
> To: 'Masaaki Hiroya'; Smith, Chris ; [email-masked];
> [email-masked]
> Subject: RE: Handling Duplicate Messages
> 
> 
> 
> > 
> > > Perhaps the preferred solution would be to indicate exactly what 
> > > condition actually exists. Can we specify that a status is sent back, 
> > > indicating that the request is still being processed? Such a status 
> > > prevents the double reply, while indicating to a client that (if they 
> > > are certain of no more replies) they should pause and then resubmit 
> > > the duplicate in order to retrieve the reply after processing is 
> > > complete (if it isn't complete, they get another status = 
> > in process). 
> > 
> > Why do you prefer to send back the status indicating request is in 
> > progress rather than to send back a transient error indicating request 
> > is in progress? 
> > 
> > In order to send back the status indicating request is in progress, 
> > it is necessary to define a new block to contain the status or 
> > change the PayExchBlk.  Furthermore, a new status type should be 
> > added such as "MsgExch" status since the payment status is always 
> > in progress during payment document exchange (until sending 
> > back PayRespBlk). 
> > 
> > If we use a transient error message, all we have to do is to add a new 
> > error code such as "ReqInProgress". 
> 
> Sorry if I wasn't clear - I wanted a status sent back, 
> not a Status. Adding the code would resolve the concern. 
> 
> I did not want the client to receive the same response 
> for two different situations. One is that there is no 
> response in progress, and there is a transient error. 
> The other (this case) is that there is a response in 
> progress. 
> 
> We should provide some indication that the previous 
> request (the abandoned one) was actually received to 
> prevent the client timing out while in a condition of 
> assuming the request was never received. 
> 
> Incidentally, this also provides a potentially valuable 
> response for transport layers that must reply, and want 
> to state something useful that will keep the client working 
> on the transaction. Under such circumstances, it would be 
> possible to reply with TransientError/ReqInProgress to the 
> original request. The client would then be aware that the 
> work is in progress, and will come back periodically to get 
> the response. 
> 
> (An example of this might be an e-mail based connection, 
> where the server side has determined that manual intervention 
> is required. The server can indicate ReqInProgress, and then 
> set MinRetrySecs to a very high number of seconds (perhaps 
> 86400 seconds) indicating that the client can come back for 
> the reply tomorrow.) 
> 
> ------------------------------------------------------------ 
>  Chris Smith                                +1.416.348.6090 
>  Royal Bank                       [email-masked] 
> 
> 
> **************************************************************************
********************
> 
> This Email and any attached files are confidential and may also be privile
ged. 
> If you are not the intended recipient, please notify the postmaster using 
email 
> address [email-masked] or call +44 171 557 5000 and ask for the 
> IT Helpdesk.  You should not copy this email and any attached files, use t
hem 
> for any purpose or disclose the contents to any other person; all copies o
f the 
> Email and associated files in your possession should be destroyed.
> 
> Mondex International Limited
> 47-53 Cannon Street
> London EC4M 5SQ
> United Kingdom
> Registered No: 3122085, England
> 
> Phone:          +44 171 557 5000
> Fax:            +44 171 557 5200
> Email:          [email-masked]
> WebSite:        http://www.mondexinternational.com
> 
> **************************************************************************
*******************
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
>  
-----
Masaaki Hiroya
Systems Development Laboratory
Hitachi, Ltd.
email: [email-masked]
tel: +81-44-549-1531
fax: +81-44-549-1640
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
Cc: [email-masked]
Cc: [email-masked]
Subject: Re: Numeric currency codes
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Thu, 29 Jul 1999 22:03:58 +0900 (JST)
Lines: 63
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David,
Ok, we will only use "ISO4217-A" in the IOTP Message.
Thanks,

--
Yoshiaki Kawatsura    Hitachi, Ltd.

>>>>> Wed, 28 Jul 1999 03:40:08 +0100,
	[email-masked] said:

> Yoshiaki asks ...
> 
> > 7.7.4 Currency Amount Element
> > Could you register "ISO4217-N" on IANA also because this is used in
> > the SMILE Project?
> > 
> I'm wondering why since:
> *	we debated at some length earlier this year whether to go for alpha
> or numeric and concluded that alpha was to be preferred
> *	having just one type of code makes it easier to develop clients
> since there is no need to support (and keep up to date) both types
> *	since there is a one-to-one correspondence between the alpha and the
> numeric you can always map between the two
> 
> ... but on the other hand if there's a good reason ... Yoshiaki, can  you
> explain?
> 
> Thanks
> 
> David
> 
> Mondex International
> Email: [email-masked]
> 
> 
> **********************************************************************************************
> 
> This Email and any attached files are confidential and may also be privileged. 
> If you are not the intended recipient, please notify the postmaster using email 
> address [email-masked] or call +44 171 557 5000 and ask for the 
> IT Helpdesk.  You should not copy this email and any attached files, use them 
> for any purpose or disclose the contents to any other person; all copies of the 
> Email and associated files in your possession should be destroyed.
> 
> Mondex International Limited
> 47-53 Cannon Street
> London EC4M 5SQ
> United Kingdom
> Registered No: 3122085, England
> 
> Phone:          +44 171 557 5000
> Fax:            +44 171 557 5200
> Email:          [email-masked]
> WebSite:        http://www.mondexinternational.com
> 
> *********************************************************************************************
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

Date: Thu, 29 Jul 1999 21:10:45 +0900
From: Ko Fujimura <[email-masked]>
To: [email-masked], [email-masked]
Subject: Digital-rights discussion
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Hi all,

At Wed, 28 Jul 1999 10:12:34 -0400,
Smith, Chris  <[email-masked]> wrote:
=2E..
> > Ko Fujimura of NTT gave a presentation on "What's Next in Internet
> > Commerce" which concentrated on Digital Right, such as sale of
> > memberships, use of coupons, sale of subscriptions, loyalty systems,
> > etc.=A0 There appeared to be a consensus at the meeting to have a BoF=

> > like meeting on this topic at the next IETF meeting assuming at a
> > minimum, that a draft requirements document can be prepared in time.
> > This needs discussion on the mailing list.
> >
> Will Mr. Fujimara be starting this discussion?

Thank you, Chris,

As I presented at the Oslo meeting, I think that it is important to
develop an infrastructure for circulating diverse digital-rights in =

Internet Commerce.

I think digital-right is a digital representation of the right to
claim the services or good specified.  It includes membership,
subscription, discount coupon, loyalty point, and any tickets.

The topics which might be addressed in the draft requirement document
to be discussed at the next meeting includes:

- Language for describing diverse rights

- Integration with payment protocols
    Global transaction control for payment and digital-rights delivery
    Payment with discount coupon redemption
    Payment with loyalty points accumulation
    Payment with award ticket issuance

- Integration with wallet-related specifications
    ECML
    "digital-rights wallet" API

- Protocol for circulating diverse digital rights
    Generalized copy-protection protocol or
    Generalized duplicate-redemption prevention protocol

- Trust model for digital-rights
    How do users judge whether digital-rights can be trusted or not?

Note that these are only examples of the topics. I don't think all of
the above should be addressed in the draft. Instead, I think that many
other topics which we should be addressed exist. Any way, I believe
that we have some important topics that should be discussed in this
WG. I would like to discuss/explore requirements on this area in detail. =

By the way, my concern is that many people in this mailing list does
not interested in drafting the requirements document, although the number=
 =

of people interested in this area are also many, hopefully. Therefore,
I set up a new mailing list for discussing this topic: =

  Address: [email-masked]
  To (un)subscribe: [email-masked]
  In body: (un)subscribe digital-rights <email address>
  Archive: (To be supported)

Any comments are wellcome, including on starting the new mailing list.

Regards,

Ko
o---------------------------------------------------------o
o      Ko Fujimura         Email: [email-masked]  o
o---------------------------------------------------------o
o NTT Information Sharing Platform Labs, Security Project o
o 1-1 Hikarinooka, Yokosuka-shi, Kanagawa 239-0847, JAPAN o
o Tel: +81-(0)468-59-3814         Fax: +81-(0)468-59-8329 o
o---------------------------------------------------------o
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: ConsumerDeliveryId
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Thu, 29 Jul 1999 20:05:46 +0900 (JST)
Lines: 138
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David,
Sounds good to us.
Thank you.

----
Yoshiaki Kawatsura : E-mail [email-masked]
 Business & Information Systems Development Division, Hitachi,Ltd.
Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721

>>>>> Wed, 28 Jul 1999 03:40:32 +0100,
	[email-masked] said:

> Andrew, I've been putting this one off since to handle it properly it
> requires a new component which is generated by the Consumer that contains
> only this item. But on the other hand, it could be important, particularly
> if the sender of the Delivery Request is a system (e.g. a B2B system) rather
> than real person to be able to identify the message that is being returned.
> 
> Detailed changes below.
> 
> David
> 
> 1. Define new Consumer Delivery Data Component ...
> 
> <!-- CONSUMER DELIVERY DATA COMPONENT -->
> <!ELEMENT ConsumerDeliveryData EMPTY >
> <!ATTLIST ConsumerDeliveryData
>  ID                 ID      #REQUIRED
>  ConsumerDeliveryId CDATA   #REQUIRED >
> 
> 2. Remove ConsumerDeliveryId from the Delivery Component. Now defined as ...
> 
> <!-- DELIVERY COMPONENT -->
> <!ELEMENT Delivery (DeliveryData?, PackagedContent*) >
> <!ATTLIST Delivery
>  ID                 ID      #REQUIRED
>  xml:lang           NMTOKEN #REQUIRED
>  DelivExch          (True | False) #REQUIRED
>  DelivAndPayResp    (True | False) #REQUIRED
>  ActionOrgRef       NMTOKEN #IMPLIED >
> 
> 3. Add optional ConsumerDeliveryData component to Delivery Request Block as
> follows ...
> 
> <!-- DELIVERY REQUEST BLOCK -->
> <!ELEMENT DeliveryReqBlk (Status+, Order, Org*, Delivery,
>      ConsumerDeliveryData?, TradingRoleData*) >
> <!ATTLIST DeliveryReqBlk
>  ID                 ID      #REQUIRED >
> 
> 4. Changed spec as follows:
> 
> - removed description of ConsumerDeliveryId from the Delivery Component
> - added section to describe ConsumerDeliveryData Component with defintion as
> above
> - added description of use of ConsumerDeliveryData Component in a Delivery
> Request Block
> - included signing of the ConsumerDeliveryData Component by the Delivery
> Response Signature if present.
> 
> 
> 
> -----Original Message-----
> From: Andrew Drapp [mailto:[email-masked]]
> Sent: Wednesday, June 16, 1999 8:00 PM
> To: 'Ietf Trade WG'
> Subject: ConsumerDeliveryId
> 
> 
> 
> 
> In section 6.2, the ConsumerDeliveryId is 
> described as follows:
> 
> ---
> An identifier specified by the Consumer which, 
> if returned by the Delivery Handler in another
> Delivery Component, or by other means, will
> enable the Consumer to identify which Delivery
> is being referred to. 
> ---
> 
> This is a bit confusing.  The first time the
> ConsumerDeliveryId is used is in the Offer Response
> Block, so I assume that it is defined by the
> Merchant.  What exactly is meant by "specified"?
> Would replacing "specified" with "used" clarify
> or change the meaning?
> 
> Furthermore, should this Id be unique within
> the IOTP transaction, or globally unique?
> 
> Regards,
> 
> Andrew
> 
> --
> Andrew Drapp
> [email-masked]
> Systems Development Laboratory, Hitachi Ltd.
> Ozenji 1099, Asao, Kawasaki, 215-0013 JAPAN
> TEL:+81-44-966-9111   FAX:+81-44-966-1796
> PGP Fingerprint: 84D8 3D19 018E 9385 6581  0081 C89C D2AD F06A 565F
> 
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 
> **********************************************************************************************
> 
> This Email and any attached files are confidential and may also be privileged. 
> If you are not the intended recipient, please notify the postmaster using email 
> address [email-masked] or call +44 171 557 5000 and ask for the 
> IT Helpdesk.  You should not copy this email and any attached files, use them 
> for any purpose or disclose the contents to any other person; all copies of the 
> Email and associated files in your possession should be destroyed.
> 
> Mondex International Limited
> 47-53 Cannon Street
> London EC4M 5SQ
> United Kingdom
> Registered No: 3122085, England
> 
> Phone:          +44 171 557 5000
> Fax:            +44 171 557 5200
> Email:          [email-masked]
> WebSite:        http://www.mondexinternational.com
> 
> *********************************************************************************************
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: "Smith, Chris " <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  [email-masked], [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
Subject: RE: ConsumerDeliveryId
Date: Wed, 28 Jul 1999 09:52:57 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BED900.7F99BFC4
Content-Type: text/plain; 
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit

I had some problems understanding the original request from
Andrew. Was this info actually in 6.12, not 6.2?

Either way, now I think I see what we're after here...

Isn't ConsumerDeliveryId the same in concept as the ConsumerPaymentId?

As such, the error would appear to be that the ConsumerDeliveryId must
appear on all items that contain and delivery Packaged Content. This
means that it should be added as an attribute to DeliveryData.

In use, the Consumer role can create a unique-to-themselves ID for each
expected delivery. This ID is attached to the ConsumerDeliveryId on
the Delivery element inside the DeliveryReqBlk.

The only error is that the DeliveryNote inside the DeliveryRespBlk should
ALSO have ConsumerDeliveryId, so that the Consumer Role can link the inbound
DeliveryNote to the original outbound Delivery.

...chris

------------------------------------------------------------
 Chris Smith                                +1.416.348.6090
 Royal Bank                       [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: July 27, 1999 10:41 PM
> To: [email-masked]; [email-masked]
> Subject: RE: ConsumerDeliveryId
> 
> 
> Andrew, I've been putting this one off since to handle it properly it
> requires a new component which is generated by the Consumer 
> that contains
> only this item. But on the other hand, it could be important, 
> particularly
> if the sender of the Delivery Request is a system (e.g. a B2B 
> system) rather
> than real person to be able to identify the message that is 
> being returned.
> 
> Detailed changes below.
> 
> David
> 
> 1. Define new Consumer Delivery Data Component ...
> 
> <!-- CONSUMER DELIVERY DATA COMPONENT -->
> <!ELEMENT ConsumerDeliveryData EMPTY >
> <!ATTLIST ConsumerDeliveryData
>  ID                 ID      #REQUIRED
>  ConsumerDeliveryId CDATA   #REQUIRED >
> 
> 2. Remove ConsumerDeliveryId from the Delivery Component. Now 
> defined as ...
> 
> <!-- DELIVERY COMPONENT -->
> <!ELEMENT Delivery (DeliveryData?, PackagedContent*) >
> <!ATTLIST Delivery
>  ID                 ID      #REQUIRED
>  xml:lang           NMTOKEN #REQUIRED
>  DelivExch          (True | False) #REQUIRED
>  DelivAndPayResp    (True | False) #REQUIRED
>  ActionOrgRef       NMTOKEN #IMPLIED >
> 
> 3. Add optional ConsumerDeliveryData component to Delivery 
> Request Block as
> follows ...
> 
> <!-- DELIVERY REQUEST BLOCK -->
> <!ELEMENT DeliveryReqBlk (Status+, Order, Org*, Delivery,
>      ConsumerDeliveryData?, TradingRoleData*) >
> <!ATTLIST DeliveryReqBlk
>  ID                 ID      #REQUIRED >
> 
> 4. Changed spec as follows:
> 
> - removed description of ConsumerDeliveryId from the Delivery 
> Component
> - added section to describe ConsumerDeliveryData Component 
> with defintion as
> above
> - added description of use of ConsumerDeliveryData Component 
> in a Delivery
> Request Block
> - included signing of the ConsumerDeliveryData Component by 
> the Delivery
> Response Signature if present.
> 
> 
> 
> -----Original Message-----
> From: Andrew Drapp [mailto:[email-masked]]
> Sent: Wednesday, June 16, 1999 8:00 PM
> To: 'Ietf Trade WG'
> Subject: ConsumerDeliveryId
> 
> 
> 
> 
> In section 6.2, the ConsumerDeliveryId is 
> described as follows:
> 
> ---
> An identifier specified by the Consumer which, 
> if returned by the Delivery Handler in another
> Delivery Component, or by other means, will
> enable the Consumer to identify which Delivery
> is being referred to. 
> ---
> 
> This is a bit confusing.  The first time the
> ConsumerDeliveryId is used is in the Offer Response
> Block, so I assume that it is defined by the
> Merchant.  What exactly is meant by "specified"?
> Would replacing "specified" with "used" clarify
> or change the meaning?
> 
> Furthermore, should this Id be unique within
> the IOTP transaction, or globally unique?
> 
> Regards,
> 
> Andrew
> 
> --
> Andrew Drapp
> [email-masked]
> Systems Development Laboratory, Hitachi Ltd.
> Ozenji 1099, Asao, Kawasaki, 215-0013 JAPAN
> TEL:+81-44-966-9111   FAX:+81-44-966-1796
> PGP Fingerprint: 84D8 3D19 018E 9385 6581  0081 C89C D2AD F06A 565F
> 
> --------------------------------------------------------------
> ---------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or 
> "unsubscribe" in the
> body to: [email-masked]
> 
> **************************************************************
> ********************************
> 
> This Email and any attached files are confidential and may 
> also be privileged. 
> If you are not the intended recipient, please notify the 
> postmaster using email 
> address [email-masked] or call +44 171 557 5000 and 
> ask for the 
> IT Helpdesk.  You should not copy this email and any attached 
> files, use them 
> for any purpose or disclose the contents to any other person; 
> all copies of the 
> Email and associated files in your possession should be destroyed.
> 
> Mondex International Limited
> 47-53 Cannon Street
> London EC4M 5SQ
> United Kingdom
> Registered No: 3122085, England
> 
> Phone:          +44 171 557 5000
> Fax:            +44 171 557 5200
> Email:          [email-masked]
> WebSite:        http://www.mondexinternational.com
> 
> **************************************************************
> *******************************
> --------------------------------------------------------------
> ---------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or 
> "unsubscribe" in the
> body to: [email-masked]
> 

------_=_NextPart_001_01BED900.7F99BFC4
Content-Type: text/html; 
 charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>RE: ConsumerDeliveryId</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I had some problems understanding the original =
request from</FONT>
<BR><FONT SIZE=3D2>Andrew. Was this info actually in 6.12, not =
6.2?</FONT>
</P>

<P><FONT SIZE=3D2>Either way, now I think I see what we're after =
here...</FONT>
</P>

<P><FONT SIZE=3D2>Isn't ConsumerDeliveryId the same in concept as the =
ConsumerPaymentId?</FONT>
</P>

<P><FONT SIZE=3D2>As such, the error would appear to be that the =
ConsumerDeliveryId must</FONT>
<BR><FONT SIZE=3D2>appear on all items that contain and delivery =
Packaged Content. This</FONT>
<BR><FONT SIZE=3D2>means that it should be added as an attribute to =
DeliveryData.</FONT>
</P>

<P><FONT SIZE=3D2>In use, the Consumer role can create a =
unique-to-themselves ID for each</FONT>
<BR><FONT SIZE=3D2>expected delivery. This ID is attached to the =
ConsumerDeliveryId on</FONT>
<BR><FONT SIZE=3D2>the Delivery element inside the =
DeliveryReqBlk.</FONT>
</P>

<P><FONT SIZE=3D2>The only error is that the DeliveryNote inside the =
DeliveryRespBlk should</FONT>
<BR><FONT SIZE=3D2>ALSO have ConsumerDeliveryId, so that the Consumer =
Role can link the inbound</FONT>
<BR><FONT SIZE=3D2>DeliveryNote to the original outbound =
Delivery.</FONT>
</P>

<P><FONT SIZE=3D2>...chris</FONT>
</P>

<P><FONT =
SIZE=3D2>------------------------------------------------------------</F=
ONT>
<BR><FONT SIZE=3D2>&nbsp;Chris =
Smith&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +1.416.348.6090</FONT>
<BR><FONT SIZE=3D2>&nbsp;Royal =
Bank&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]=
</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: July 27, 1999 10:41 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [email-masked]; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: ConsumerDeliveryId</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Andrew, I've been putting this one off since to =
handle it properly it</FONT>
<BR><FONT SIZE=3D2>&gt; requires a new component which is generated by =
the Consumer </FONT>
<BR><FONT SIZE=3D2>&gt; that contains</FONT>
<BR><FONT SIZE=3D2>&gt; only this item. But on the other hand, it could =
be important, </FONT>
<BR><FONT SIZE=3D2>&gt; particularly</FONT>
<BR><FONT SIZE=3D2>&gt; if the sender of the Delivery Request is a =
system (e.g. a B2B </FONT>
<BR><FONT SIZE=3D2>&gt; system) rather</FONT>
<BR><FONT SIZE=3D2>&gt; than real person to be able to identify the =
message that is </FONT>
<BR><FONT SIZE=3D2>&gt; being returned.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Detailed changes below.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; David</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 1. Define new Consumer Delivery Data Component =
...</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &lt;!-- CONSUMER DELIVERY DATA COMPONENT =
--&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &lt;!ELEMENT ConsumerDeliveryData EMPTY =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &lt;!ATTLIST ConsumerDeliveryData</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; =
ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
#REQUIRED</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; ConsumerDeliveryId CDATA&nbsp;&nbsp; =
#REQUIRED &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 2. Remove ConsumerDeliveryId from the Delivery =
Component. Now </FONT>
<BR><FONT SIZE=3D2>&gt; defined as ...</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &lt;!-- DELIVERY COMPONENT --&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &lt;!ELEMENT Delivery (DeliveryData?, =
PackagedContent*) &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &lt;!ATTLIST Delivery</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; =
ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
#REQUIRED</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; =
xml:lang&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
NMTOKEN #REQUIRED</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; =
DelivExch&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (True | =
False) #REQUIRED</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; DelivAndPayResp&nbsp;&nbsp;&nbsp; (True | =
False) #REQUIRED</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; =
ActionOrgRef&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NMTOKEN #IMPLIED =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 3. Add optional ConsumerDeliveryData component =
to Delivery </FONT>
<BR><FONT SIZE=3D2>&gt; Request Block as</FONT>
<BR><FONT SIZE=3D2>&gt; follows ...</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &lt;!-- DELIVERY REQUEST BLOCK --&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &lt;!ELEMENT DeliveryReqBlk (Status+, Order, =
Org*, Delivery,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
ConsumerDeliveryData?, TradingRoleData*) &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &lt;!ATTLIST DeliveryReqBlk</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; =
ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #REQUIRED =
&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 4. Changed spec as follows:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; - removed description of ConsumerDeliveryId =
from the Delivery </FONT>
<BR><FONT SIZE=3D2>&gt; Component</FONT>
<BR><FONT SIZE=3D2>&gt; - added section to describe =
ConsumerDeliveryData Component </FONT>
<BR><FONT SIZE=3D2>&gt; with defintion as</FONT>
<BR><FONT SIZE=3D2>&gt; above</FONT>
<BR><FONT SIZE=3D2>&gt; - added description of use of =
ConsumerDeliveryData Component </FONT>
<BR><FONT SIZE=3D2>&gt; in a Delivery</FONT>
<BR><FONT SIZE=3D2>&gt; Request Block</FONT>
<BR><FONT SIZE=3D2>&gt; - included signing of the ConsumerDeliveryData =
Component by </FONT>
<BR><FONT SIZE=3D2>&gt; the Delivery</FONT>
<BR><FONT SIZE=3D2>&gt; Response Signature if present.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Andrew Drapp [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]=
</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, June 16, 1999 8:00 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'Ietf Trade WG'</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: ConsumerDeliveryId</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In section 6.2, the ConsumerDeliveryId is =
</FONT>
<BR><FONT SIZE=3D2>&gt; described as follows:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; ---</FONT>
<BR><FONT SIZE=3D2>&gt; An identifier specified by the Consumer which, =
</FONT>
<BR><FONT SIZE=3D2>&gt; if returned by the Delivery Handler in =
another</FONT>
<BR><FONT SIZE=3D2>&gt; Delivery Component, or by other means, =
will</FONT>
<BR><FONT SIZE=3D2>&gt; enable the Consumer to identify which =
Delivery</FONT>
<BR><FONT SIZE=3D2>&gt; is being referred to. </FONT>
<BR><FONT SIZE=3D2>&gt; ---</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This is a bit confusing.&nbsp; The first time =
the</FONT>
<BR><FONT SIZE=3D2>&gt; ConsumerDeliveryId is used is in the Offer =
Response</FONT>
<BR><FONT SIZE=3D2>&gt; Block, so I assume that it is defined by =
the</FONT>
<BR><FONT SIZE=3D2>&gt; Merchant.&nbsp; What exactly is meant by =
&quot;specified&quot;?</FONT>
<BR><FONT SIZE=3D2>&gt; Would replacing &quot;specified&quot; with =
&quot;used&quot; clarify</FONT>
<BR><FONT SIZE=3D2>&gt; or change the meaning?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Furthermore, should this Id be unique =
within</FONT>
<BR><FONT SIZE=3D2>&gt; the IOTP transaction, or globally =
unique?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Andrew</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; Andrew Drapp</FONT>
<BR><FONT SIZE=3D2>&gt; [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Systems Development Laboratory, Hitachi =
Ltd.</FONT>
<BR><FONT SIZE=3D2>&gt; Ozenji 1099, Asao, Kawasaki, 215-0013 =
JAPAN</FONT>
<BR><FONT SIZE=3D2>&gt; TEL:+81-44-966-9111&nbsp;&nbsp; =
FAX:+81-44-966-1796</FONT>
<BR><FONT SIZE=3D2>&gt; PGP Fingerprint: 84D8 3D19 018E 9385 6581&nbsp; =
0081 C89C D2AD F06A 565F</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
--------------------------------------------------------------</FONT>
<BR><FONT SIZE=3D2>&gt; ---------</FONT>
<BR><FONT SIZE=3D2>&gt; Message addressed to: =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Archive available at: <A =
HREF=3D"http://www.elistx.com/archives/ietf-trade/" =
TARGET=3D"_blank">http://www.elistx.com/archives/ietf-trade/</A></FONT>
<BR><FONT SIZE=3D2>&gt; To (un)subscribe send a message with =
&quot;subscribe&quot; or </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;unsubscribe&quot; in the</FONT>
<BR><FONT SIZE=3D2>&gt; body to: =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
**************************************************************</FONT>
<BR><FONT SIZE=3D2>&gt; ********************************</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This Email and any attached files are =
confidential and may </FONT>
<BR><FONT SIZE=3D2>&gt; also be privileged. </FONT>
<BR><FONT SIZE=3D2>&gt; If you are not the intended recipient, please =
notify the </FONT>
<BR><FONT SIZE=3D2>&gt; postmaster using email </FONT>
<BR><FONT SIZE=3D2>&gt; address [email-masked] or call +44 171 =
557 5000 and </FONT>
<BR><FONT SIZE=3D2>&gt; ask for the </FONT>
<BR><FONT SIZE=3D2>&gt; IT Helpdesk.&nbsp; You should not copy this =
email and any attached </FONT>
<BR><FONT SIZE=3D2>&gt; files, use them </FONT>
<BR><FONT SIZE=3D2>&gt; for any purpose or disclose the contents to any =
other person; </FONT>
<BR><FONT SIZE=3D2>&gt; all copies of the </FONT>
<BR><FONT SIZE=3D2>&gt; Email and associated files in your possession =
should be destroyed.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Mondex International Limited</FONT>
<BR><FONT SIZE=3D2>&gt; 47-53 Cannon Street</FONT>
<BR><FONT SIZE=3D2>&gt; London EC4M 5SQ</FONT>
<BR><FONT SIZE=3D2>&gt; United Kingdom</FONT>
<BR><FONT SIZE=3D2>&gt; Registered No: 3122085, England</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
Phone:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +44 171 =
557 5000</FONT>
<BR><FONT SIZE=3D2>&gt; =
Fax:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
+44 171 557 5200</FONT>
<BR><FONT SIZE=3D2>&gt; =
Email:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; =
WebSite:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A =
HREF=3D"http://www.mondexinternational.com" =
TARGET=3D"_blank">http://www.mondexinternational.com</A></FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
**************************************************************</FONT>
<BR><FONT SIZE=3D2>&gt; *******************************</FONT>
<BR><FONT SIZE=3D2>&gt; =
--------------------------------------------------------------</FONT>
<BR><FONT SIZE=3D2>&gt; ---------</FONT>
<BR><FONT SIZE=3D2>&gt; Message addressed to: =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Archive available at: <A =
HREF=3D"http://www.elistx.com/archives/ietf-trade/" =
TARGET=3D"_blank">http://www.elistx.com/archives/ietf-trade/</A></FONT>
<BR><FONT SIZE=3D2>&gt; To (un)subscribe send a message with =
&quot;subscribe&quot; or </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;unsubscribe&quot; in the</FONT>
<BR><FONT SIZE=3D2>&gt; body to: =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BED900.7F99BFC4--

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: "Smith, Chris " <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  [email-masked], [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
Subject: RE: Numeric currency codes (again?)
Date: Wed, 28 Jul 1999 09:27:56 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BED8FD.01406338
Content-Type: text/plain; 
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit

I concur with David on this.

I realize that this was (supposedly) resolved, but if it's
going to come up again, then I'll reiterate some of the
earlier points again.

This is a key interoperability issue for IOTP. Having both
numeric and alpha requires all roles to understand both AND
to understand how to convert from one to the other. I believe
this would also require that all roles and their supporting
implementations deal with currency updates, if only so that
client side wallets can report a currency to the local user.
This is a needless burden - go with alpha.

Alpha is, in my opinion, highly preferred. It can be used 
as-is to display to the client the currency in question.
The inclusion of the country code means that the user has
a better chance of understanding a currency code the software
doesn't recognize. If you use numerics and the user doesn't
know the EXACT number, they will not have any idea of the
actual value of a transaction.

Alpha is in much wider use from the consumer perspective - 
the 3 digit alpha codes are used on money exchange boards
everywhere to indicate exchange rates, while the numerics
are always hidden from view.

------------------------------------------------------------
 Chris Smith                                +1.416.348.6090
 Royal Bank                       [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: July 27, 1999 10:40 PM
> To: [email-masked]; [email-masked]
> Subject: Numeric currency codes
> 
> 
> Yoshiaki asks ...
> 
> > 7.7.4 Currency Amount Element
> > Could you register "ISO4217-N" on IANA also because this is used in
> > the SMILE Project?
> > 
> I'm wondering why since:
> *	we debated at some length earlier this year whether to 
> go for alpha
> or numeric and concluded that alpha was to be preferred
> *	having just one type of code makes it easier to develop clients
> since there is no need to support (and keep up to date) both types
> *	since there is a one-to-one correspondence between the 
> alpha and the
> numeric you can always map between the two
> 
> ... but on the other hand if there's a good reason ... 
> Yoshiaki, can  you
> explain?
> 
> Thanks
> 
> David
> 
> Mondex International
> Email: [email-masked]
> 
> 
> **************************************************************
> ********************************
> 
> This Email and any attached files are confidential and may 
> also be privileged. 
> If you are not the intended recipient, please notify the 
> postmaster using email 
> address [email-masked] or call +44 171 557 5000 and 
> ask for the 
> IT Helpdesk.  You should not copy this email and any attached 
> files, use them 
> for any purpose or disclose the contents to any other person; 
> all copies of the 
> Email and associated files in your possession should be destroyed.
> 
> Mondex International Limited
> 47-53 Cannon Street
> London EC4M 5SQ
> United Kingdom
> Registered No: 3122085, England
> 
> Phone:          +44 171 557 5000
> Fax:            +44 171 557 5200
> Email:          [email-masked]
> WebSite:        http://www.mondexinternational.com
> 
> **************************************************************
> *******************************
> --------------------------------------------------------------
> ---------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or 
> "unsubscribe" in the
> body to: [email-masked]
> 

------_=_NextPart_001_01BED8FD.01406338
Content-Type: text/html; 
 charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>RE: Numeric currency codes (again?)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I concur with David on this.</FONT>
</P>

<P><FONT SIZE=3D2>I realize that this was (supposedly) resolved, but if =
it's</FONT>
<BR><FONT SIZE=3D2>going to come up again, then I'll reiterate some of =
the</FONT>
<BR><FONT SIZE=3D2>earlier points again.</FONT>
</P>

<P><FONT SIZE=3D2>This is a key interoperability issue for IOTP. Having =
both</FONT>
<BR><FONT SIZE=3D2>numeric and alpha requires all roles to understand =
both AND</FONT>
<BR><FONT SIZE=3D2>to understand how to convert from one to the other. =
I believe</FONT>
<BR><FONT SIZE=3D2>this would also require that all roles and their =
supporting</FONT>
<BR><FONT SIZE=3D2>implementations deal with currency updates, if only =
so that</FONT>
<BR><FONT SIZE=3D2>client side wallets can report a currency to the =
local user.</FONT>
<BR><FONT SIZE=3D2>This is a needless burden - go with alpha.</FONT>
</P>

<P><FONT SIZE=3D2>Alpha is, in my opinion, highly preferred. It can be =
used </FONT>
<BR><FONT SIZE=3D2>as-is to display to the client the currency in =
question.</FONT>
<BR><FONT SIZE=3D2>The inclusion of the country code means that the =
user has</FONT>
<BR><FONT SIZE=3D2>a better chance of understanding a currency code the =
software</FONT>
<BR><FONT SIZE=3D2>doesn't recognize. If you use numerics and the user =
doesn't</FONT>
<BR><FONT SIZE=3D2>know the EXACT number, they will not have any idea =
of the</FONT>
<BR><FONT SIZE=3D2>actual value of a transaction.</FONT>
</P>

<P><FONT SIZE=3D2>Alpha is in much wider use from the consumer =
perspective - </FONT>
<BR><FONT SIZE=3D2>the 3 digit alpha codes are used on money exchange =
boards</FONT>
<BR><FONT SIZE=3D2>everywhere to indicate exchange rates, while the =
numerics</FONT>
<BR><FONT SIZE=3D2>are always hidden from view.</FONT>
</P>

<P><FONT =
SIZE=3D2>------------------------------------------------------------</F=
ONT>
<BR><FONT SIZE=3D2>&nbsp;Chris =
Smith&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +1.416.348.6090</FONT>
<BR><FONT SIZE=3D2>&nbsp;Royal =
Bank&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]=
</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: July 27, 1999 10:40 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [email-masked]; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Numeric currency codes</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Yoshiaki asks ...</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 7.7.4 Currency Amount Element</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Could you register &quot;ISO4217-N&quot; =
on IANA also because this is used in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the SMILE Project?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I'm wondering why since:</FONT>
<BR><FONT SIZE=3D2>&gt; *&nbsp;&nbsp;&nbsp;&nbsp; we debated at some =
length earlier this year whether to </FONT>
<BR><FONT SIZE=3D2>&gt; go for alpha</FONT>
<BR><FONT SIZE=3D2>&gt; or numeric and concluded that alpha was to be =
preferred</FONT>
<BR><FONT SIZE=3D2>&gt; *&nbsp;&nbsp;&nbsp;&nbsp; having just one type =
of code makes it easier to develop clients</FONT>
<BR><FONT SIZE=3D2>&gt; since there is no need to support (and keep up =
to date) both types</FONT>
<BR><FONT SIZE=3D2>&gt; *&nbsp;&nbsp;&nbsp;&nbsp; since there is a =
one-to-one correspondence between the </FONT>
<BR><FONT SIZE=3D2>&gt; alpha and the</FONT>
<BR><FONT SIZE=3D2>&gt; numeric you can always map between the =
two</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; ... but on the other hand if there's a good =
reason ... </FONT>
<BR><FONT SIZE=3D2>&gt; Yoshiaki, can&nbsp; you</FONT>
<BR><FONT SIZE=3D2>&gt; explain?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; David</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Mondex International</FONT>
<BR><FONT SIZE=3D2>&gt; Email: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
**************************************************************</FONT>
<BR><FONT SIZE=3D2>&gt; ********************************</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This Email and any attached files are =
confidential and may </FONT>
<BR><FONT SIZE=3D2>&gt; also be privileged. </FONT>
<BR><FONT SIZE=3D2>&gt; If you are not the intended recipient, please =
notify the </FONT>
<BR><FONT SIZE=3D2>&gt; postmaster using email </FONT>
<BR><FONT SIZE=3D2>&gt; address [email-masked] or call +44 171 =
557 5000 and </FONT>
<BR><FONT SIZE=3D2>&gt; ask for the </FONT>
<BR><FONT SIZE=3D2>&gt; IT Helpdesk.&nbsp; You should not copy this =
email and any attached </FONT>
<BR><FONT SIZE=3D2>&gt; files, use them </FONT>
<BR><FONT SIZE=3D2>&gt; for any purpose or disclose the contents to any =
other person; </FONT>
<BR><FONT SIZE=3D2>&gt; all copies of the </FONT>
<BR><FONT SIZE=3D2>&gt; Email and associated files in your possession =
should be destroyed.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Mondex International Limited</FONT>
<BR><FONT SIZE=3D2>&gt; 47-53 Cannon Street</FONT>
<BR><FONT SIZE=3D2>&gt; London EC4M 5SQ</FONT>
<BR><FONT SIZE=3D2>&gt; United Kingdom</FONT>
<BR><FONT SIZE=3D2>&gt; Registered No: 3122085, England</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
Phone:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +44 171 =
557 5000</FONT>
<BR><FONT SIZE=3D2>&gt; =
Fax:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
+44 171 557 5200</FONT>
<BR><FONT SIZE=3D2>&gt; =
Email:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; =
WebSite:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A =
HREF=3D"http://www.mondexinternational.com" =
TARGET=3D"_blank">http://www.mondexinternational.com</A></FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
**************************************************************</FONT>
<BR><FONT SIZE=3D2>&gt; *******************************</FONT>
<BR><FONT SIZE=3D2>&gt; =
--------------------------------------------------------------</FONT>
<BR><FONT SIZE=3D2>&gt; ---------</FONT>
<BR><FONT SIZE=3D2>&gt; Message addressed to: =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Archive available at: <A =
HREF=3D"http://www.elistx.com/archives/ietf-trade/" =
TARGET=3D"_blank">http://www.elistx.com/archives/ietf-trade/</A></FONT>
<BR><FONT SIZE=3D2>&gt; To (un)subscribe send a message with =
&quot;subscribe&quot; or </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;unsubscribe&quot; in the</FONT>
<BR><FONT SIZE=3D2>&gt; body to: =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BED8FD.01406338--

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: "Smith, Chris " <[email-masked]>
To: "'Donald E. Eastlake 3rd'" <[email-masked]>,  [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
Subject: RE: Minutes for Oslo TRADE WG Meeting
Date: Wed, 28 Jul 1999 10:12:34 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BED903.3D1F314A
Content-Type: text/plain; 
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Comments below - I've stripped out items I have no comments
on. Overall, it sounds like it was a good meeting.

------------------------------------------------------------
 Chris Smith                                +1.416.348.6090
 Royal Bank                       [email-masked]

> -----Original Message-----
> From: Donald E. Eastlake 3rd [mailto:[email-masked]]
> Sent: July 27, 1999 09:35 AM
> To: [email-masked]
> Subject: Minutes for Oslo TRADE WG Meeting

> Yoshiaki Kawatsura of Hitachi presented an update on the status of the
> SMILE project.  (see separate slides)
>
Are these coming to the list as well? Please? Perhaps a URL?

> David Burdett mentioned that there was an IOTP 1.0 implementation by
> the Royal Bank of Canada and that one was planned this year by SIZ.
>
Yes - for those that wish more detail, a starting point is the press
release at http://www.newse

> ... There was some discussion of the change which permitted optional
> authentication at the beginning of most transactions.
> 
Sorry I couldn't be in on this - we used this feature in our 
implementation. Completely authenticating the client (using a payment-
specific auth mechanism) allowed us to report useful client-specific 
information if problems arose during the creation of the OfferResponse.

In the past, with payment-based authentication buried in the Payment 
exchange, we had to provide generic responses (such as "Failed.") when a 
more useful response was desired. It was not permissable to send 
potentially detailed error information to a customer who was not 
authenticated.

More particularly, it ensured that we only generated an OfferResponse 
when the customer actually had the payment instrument in question. From 
both a security and a usability point of view, this was a definite 
improvement.

> A straw poll was taken and indicated overwhelming support by those in
> the room to advance these two IOTP v1.0 protocol specification
> documents to the IESG for Informational RFC within a few weeks.  (The
> IESG may choose to do an IETF wide last call on them.)  It was
> suggested that the XML DTD in these two documents be tried with
> various XML processing tools to be sure it will work with them,
>
Would this be draft-04, or (based on a final few items
on the list) draft-05?

> Hitachi presented some slides on the SET supplement.  (see separate
> slides)
>
Are these coming to the list as well? Please? Perhaps a URL?

> Jason Easton spoke briefly on the SCCD supplement which Tom Arnold is
> authoring.  Tom had planned to be present but got called away from the
> IETF meeting due to business considerations.  SCCD (Secure Channel
> Credit Debit) is a payment protocol intended to be used via an SSL or
> similar secure channel and provide the equivalent of SSL secured plain
> text forms for credit card charges.  This should be out as an I-D
> within three weeks.
>
Good! Congrats to Tom - this is long overdue. Looking forward
to reviewing this.

> Possible additional payment system supplements covering eCheck and ACH
> we listed by Donald Eastlake.  Tony Lewis questioned the presence of
> ACH as it normally requires prior written authorization but Steve
> Crocker thought it should be there.
>
We should soon see the outlines of legal acceptance of digital 
signatures. When that heppens, an online digital signature on the 
relevant request may become equivalent to the prior written 
authorization.

> Ko Fujimura of NTT gave a presentation on "What's Next in Internet
> Commerce" which concentrated on Digital Right, such as sale of
> memberships, use of coupons, sale of subscriptions, loyalty systems,
> etc.  There appeared to be a consensus at the meeting to have a BoF
> like meeting on this topic at the next IETF meeting assuming at a
> minimum, that a draft requirements document can be prepared in time.
> This needs discussion on the mailing list.
>
Will Mr. Fujimara be starting this discussion? 

> Finally, David Burdett gave an informational presentation on the OECD
> and Taxation.  (See separate slides.)
>
Are these coming to the list as well? Please? Perhaps a URL?

------_=_NextPart_001_01BED903.3D1F314A
Content-Type: text/html; 
 charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>RE: Minutes for Oslo TRADE WG Meeting</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Comments below - I've stripped out items I have no =
comments</FONT>
<BR><FONT SIZE=3D2>on. Overall, it sounds like it was a good =
meeting.</FONT>
</P>

<P><FONT =
SIZE=3D2>------------------------------------------------------------</F=
ONT>
<BR><FONT SIZE=3D2>&nbsp;Chris =
Smith&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +1.416.348.6090</FONT>
<BR><FONT SIZE=3D2>&nbsp;Royal =
Bank&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Donald E. Eastlake 3rd [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: July 27, 1999 09:35 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Minutes for Oslo TRADE WG =
Meeting</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Yoshiaki Kawatsura of Hitachi presented an =
update on the status of the</FONT>
<BR><FONT SIZE=3D2>&gt; SMILE project.&nbsp; (see separate =
slides)</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>Are these coming to the list as well? Please? =
Perhaps a URL?</FONT>
</P>

<P><FONT SIZE=3D2>&gt; David Burdett mentioned that there was an IOTP =
1.0 implementation by</FONT>
<BR><FONT SIZE=3D2>&gt; the Royal Bank of Canada and that one was =
planned this year by SIZ.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>Yes - for those that wish more detail, a starting =
point is the press</FONT>
<BR><FONT SIZE=3D2>release at <A HREF=3D"http://www.newse" =
TARGET=3D"_blank">http://www.newse</A></FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; ... There was some discussion of the change =
which permitted optional</FONT>
<BR><FONT SIZE=3D2>&gt; authentication at the beginning of most =
transactions.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>Sorry I couldn't be in on this - we used this =
feature in our </FONT>
<BR><FONT SIZE=3D2>implementation. Completely authenticating the client =
(using a payment-</FONT>
<BR><FONT SIZE=3D2>specific auth mechanism) allowed us to report useful =
client-specific </FONT>
<BR><FONT SIZE=3D2>information if problems arose during the creation of =
the OfferResponse.</FONT>
</P>

<P><FONT SIZE=3D2>In the past, with payment-based authentication buried =
in the Payment </FONT>
<BR><FONT SIZE=3D2>exchange, we had to provide generic responses (such =
as &quot;Failed.&quot;) when a </FONT>
<BR><FONT SIZE=3D2>more useful response was desired. It was not =
permissable to send </FONT>
<BR><FONT SIZE=3D2>potentially detailed error information to a customer =
who was not </FONT>
<BR><FONT SIZE=3D2>authenticated.</FONT>
</P>

<P><FONT SIZE=3D2>More particularly, it ensured that we only generated =
an OfferResponse </FONT>
<BR><FONT SIZE=3D2>when the customer actually had the payment =
instrument in question. From </FONT>
<BR><FONT SIZE=3D2>both a security and a usability point of view, this =
was a definite </FONT>
<BR><FONT SIZE=3D2>improvement.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; A straw poll was taken and indicated =
overwhelming support by those in</FONT>
<BR><FONT SIZE=3D2>&gt; the room to advance these two IOTP v1.0 =
protocol specification</FONT>
<BR><FONT SIZE=3D2>&gt; documents to the IESG for Informational RFC =
within a few weeks.&nbsp; (The</FONT>
<BR><FONT SIZE=3D2>&gt; IESG may choose to do an IETF wide last call on =
them.)&nbsp; It was</FONT>
<BR><FONT SIZE=3D2>&gt; suggested that the XML DTD in these two =
documents be tried with</FONT>
<BR><FONT SIZE=3D2>&gt; various XML processing tools to be sure it will =
work with them,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>Would this be draft-04, or (based on a final few =
items</FONT>
<BR><FONT SIZE=3D2>on the list) draft-05?</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Hitachi presented some slides on the SET =
supplement.&nbsp; (see separate</FONT>
<BR><FONT SIZE=3D2>&gt; slides)</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>Are these coming to the list as well? Please? =
Perhaps a URL?</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Jason Easton spoke briefly on the SCCD =
supplement which Tom Arnold is</FONT>
<BR><FONT SIZE=3D2>&gt; authoring.&nbsp; Tom had planned to be present =
but got called away from the</FONT>
<BR><FONT SIZE=3D2>&gt; IETF meeting due to business =
considerations.&nbsp; SCCD (Secure Channel</FONT>
<BR><FONT SIZE=3D2>&gt; Credit Debit) is a payment protocol intended to =
be used via an SSL or</FONT>
<BR><FONT SIZE=3D2>&gt; similar secure channel and provide the =
equivalent of SSL secured plain</FONT>
<BR><FONT SIZE=3D2>&gt; text forms for credit card charges.&nbsp; This =
should be out as an I-D</FONT>
<BR><FONT SIZE=3D2>&gt; within three weeks.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>Good! Congrats to Tom - this is long overdue. =
Looking forward</FONT>
<BR><FONT SIZE=3D2>to reviewing this.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Possible additional payment system supplements =
covering eCheck and ACH</FONT>
<BR><FONT SIZE=3D2>&gt; we listed by Donald Eastlake.&nbsp; Tony Lewis =
questioned the presence of</FONT>
<BR><FONT SIZE=3D2>&gt; ACH as it normally requires prior written =
authorization but Steve</FONT>
<BR><FONT SIZE=3D2>&gt; Crocker thought it should be there.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>We should soon see the outlines of legal acceptance =
of digital </FONT>
<BR><FONT SIZE=3D2>signatures. When that heppens, an online digital =
signature on the </FONT>
<BR><FONT SIZE=3D2>relevant request may become equivalent to the prior =
written </FONT>
<BR><FONT SIZE=3D2>authorization.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Ko Fujimura of NTT gave a presentation on =
&quot;What's Next in Internet</FONT>
<BR><FONT SIZE=3D2>&gt; Commerce&quot; which concentrated on Digital =
Right, such as sale of</FONT>
<BR><FONT SIZE=3D2>&gt; memberships, use of coupons, sale of =
subscriptions, loyalty systems,</FONT>
<BR><FONT SIZE=3D2>&gt; etc.&nbsp; There appeared to be a consensus at =
the meeting to have a BoF</FONT>
<BR><FONT SIZE=3D2>&gt; like meeting on this topic at the next IETF =
meeting assuming at a</FONT>
<BR><FONT SIZE=3D2>&gt; minimum, that a draft requirements document can =
be prepared in time.</FONT>
<BR><FONT SIZE=3D2>&gt; This needs discussion on the mailing =
list.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>Will Mr. Fujimara be starting this discussion? =
</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Finally, David Burdett gave an informational =
presentation on the OECD</FONT>
<BR><FONT SIZE=3D2>&gt; and Taxation.&nbsp; (See separate =
slides.)</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>Are these coming to the list as well? Please? =
Perhaps a URL?</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BED903.3D1F314A--

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
Cc: [email-masked]
Cc: [email-masked]
Subject: RE: My Comments of IOTP Spec Release4
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Wed, 28 Jul 1999 16:54:17 +0900 (JST)
Lines: 71
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David,
I will send some comments for your mails in this week because I have to
discuss with my coleagues except for Cancelling a Transaction.

--
For 4.5.3
> *	if the IotpTransId of the transaction to be cancelled is not
> recognised, or complete then fail the request, otherwise
> *	if the IotpTransId refers to an Inquiry Transaction or a Ping
I wanna make sure.
Do the descriptions of "the request" above mean "external request from
another system"?

If so, I do not understand why you disagreed.
In the current IOTP, the Consumer generates new IotpTransId 
whenever the Consumer generates the Ping Message. 
But the Consumer uses the IotpTransId corresponding with the Purchase
Transaction which Consumer wants to inquire, so the Consumer does not
create new IotpTransId.

After all, the IotpTransId also refers to an Purchase Transaction if
IotpTransId refers to an Inquiry Transaction.

--
Yoshiaki Kawatsura Hitachi, Ltd.

>>>>> Wed, 28 Jul 1999 03:40:12 +0100,
	[email-masked] said:

> > 4.5.3 Cancelling a Transaction
> > In 4.5.3,
> > --Start
> >       o if the IotpTransId refers to Inquiry Transaction or a Ping
> >         Transaction then fail the request, otherwise
> > --End
> > 
> > We use the same IotpTransId, which is used in the Payment
> > Transaction, whenever the Inquiry Transaction is processed. So we
> > should revise the above description as follows:
> > 
> >       o if the IotpTransId refers to a Ping
> >         Transaction then fail the request, otherwise
> ##Disagree. What I intended, but perhaps didn't make clear, was that that
> this process is used to generate a cancel block to be sent to the other
> party. For example, if a Payment Handler decides to cancel a transaction for
> some business reason, then there needs to be a way for the cancellation to
> be communicated to the IOTP Server for the Payment Handler so that it can
> generate the Cancel Block. So if clarified this section as follows.
> 
> This process is used to cancel a transaction running on an IOTP server. It
> is initiated by some other process as a result of an external request from
> another system or server that is being run by the same Trading Role. The
> processing required is as follows:
> *	if the IotpTransId of the transaction to be cancelled is not
> recognised, or complete then fail the request, otherwise
> *	if the IotpTransId refers to an Inquiry Transaction or a Ping
> Transaction then fail the request, otherwise
> *	determine which Document Exchange to cancel and generate a Cancel
> Block and send it to the other party
> 	[Note]	Cancelling a transaction on an IOTP server typically arises
> for a business reason. For example a merchant may have attempted
> authentication several times without success and as a result decides to
> cancel the transaction. Therefore the process that decides to take this
> action needs to send a message from the process/server that made the
> business decision to the IOTP server with the instruction that the IOTP
> transaction should be cancelled.
> 	[Note End]	 
> ##

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: My Comments of IOTP Spec Release4
Date: Wed, 28 Jul 1999 03:40:12 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Yoshiaki

Appologies for the delay in responding but since my return from the IETF in
Oslo I've had no time to look at this. Anyway here goes ... comments marked
with ##

David
PS Having worked through all these you have been very thorough. Thanks.
> ----------
> From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
> Sent: 	05 July 1999 01:43
> To: 	[email-masked]
> Cc: 	[email-masked]; [email-masked]
> Subject: 	My Comments of IOTP Spec Release4
> 
> David,
> My comments of the IOTP Specification Release4 as follows:
> 
> ---
> 1.6 Document Structure (Page 14 )
> DigiCash is the company name so please change to eCash.
## agreed ... but Digicash was actually in section 1.5 Scope of Document##

> ---
> 
> 3.1.1 (Page34) 
> Minor misspelling:
>  |  |-Certificate Comp. < Certificate Component (0ptional) Used to chec
>                                                  ^
> Please change from integer "0" to Alphabet "O".
##Noted##

> ---
> 
> 3.3.2  MsgId Component
> There is no description of LangPrefList and CharSetPrefList.
## Added as follows
LangPrefList ...
	Optional list of Language codes that conform to [XML] Language
Identification. It is used by the sender to indicate, in preference
sequence, the languages that the receiver of the message ideally should use
when generating a response. There is no obligation on the receiver to
respond using one of the indicated languages, but using one of the languages
is likely to provide an improved user experience.

CharSetPrefList ...
	Optional list of Character Set identifiers that conform to [XML]
Characters. It is used by the sender to indicate, in preference sequence,
the character sets that the receiver of the message ideally should use when
generating a response. There is no obligation on the receiver to respond
using one of the character sets indicated, but using one of the character
sets is likely to provide an improved user experience.

Also added the following explanation to Section 3.8 Identifiying Languages
as follows ...
A sender of a message, typically a Consumer can indicate a preference for a
language, and a character set by specifying a list of preferred
languages/character sets in a Message Id Component (see section 3.3.2). Note
that there is no obligation on the receiver of such a message to respond
using one of the listed languages/character sets as they may not have the
technology to be able to do it. It also means that the ability to handle
these lists is not a requirement for conformance to this specification.
However the ability to respond, for example using one of the stated
languages/character sets is likely to provide a better user experience.

These attributes were added to meet and indicated requirement of SET version
2.0. Apologies for not discussing it on the list ... no doubt if anyone has
any contrary views you'll let me know.
##

> --
> 3.4.1 Trading Role Element
> There is no definition the IotpMsgIdPrefix for DelivTo.
> DelivTo Trading Role does not use this because DelivTo does not
> send the IOTP Message. But IotpMsgIdPrefix is mandatory.
> Should we set "C" as the Consumer?
##Yes ... clarified spec and suggested "C" for the DelivTo role as a
guideline##

> ---
> 
> 3.6.1 Extra XML Elements
> IOTP:Critical (True|False) #TRUE
> should be changed to
> IOTP:Critical (True|False) 'True' 
##Corrected##

> --
> 
> 4.5.2.1 Checking Structure and Message Identity
> -- Start
>   If the message is well formed but the IotpTransId cannot be identifie
>   then generate an ErrorComponent with:
> 
>       o a Severity of HardError and an ErrorCode of AttMissing,
> 
>       o one PackagedContent containing the original Input Message,
>         and
> 
>       o the second PackagedContent containing "IotpTransId" - the
>         missing attribute.
> 
>   Insert the Error Component inside an Error Block with a new
>   TransactionId component with a new IotpTransId and return it to the
>   sender of the original message.
> --End
> I have two questions.
> 
> Question 1. If we include two PackagedContent Components in Error
> Component, we have to decide the both Name element(s) so that Consumer
> side OAC recognizes them and handles.
> 
> Question 2. This is the only case that the Original Input Message is
> included in the Packaged Content of Error Component isn't it?
	## See other email##
> --
> 
> 4.5.2.3 Processing Non-Duplicate Message
> Please add the description of the transient error as follows:
> Current:
>       o if no hard errors result, then processing the message and
>         generating an output message, if required, for return to
>         the sender of the Input Message
> New:
>       o if no hard error and transient error result, 
>         then processing the message and
>         generating an output message, if required, for return to
>         the sender of the Input Message
##Agreed. Exact new wording as follows:
	"o if neither hard errors nor transient errors result, then
processing the message and generating an output message, if required, for
return to the sender of the Input Message"

	Also changed ServerLogic.txt and ConsumerLogic.txt files.
##

> --
> 
> 4.5.3 Cancelling a Transaction
> In 4.5.3,
> --Start
>       o if the IotpTransId refers to Inquiry Transaction or a Ping
>         Transaction then fail the request, otherwise
> --End
> 
> We use the same IotpTransId, which is used in the Payment
> Transaction, whenever the Inquiry Transaction is processed. So we
> should revise the above description as follows:
> 
>       o if the IotpTransId refers to a Ping
>         Transaction then fail the request, otherwise
##Disagree. What I intended, but perhaps didn't make clear, was that that
this process is used to generate a cancel block to be sent to the other
party. For example, if a Payment Handler decides to cancel a transaction for
some business reason, then there needs to be a way for the cancellation to
be communicated to the IOTP Server for the Payment Handler so that it can
generate the Cancel Block. So if clarified this section as follows.

This process is used to cancel a transaction running on an IOTP server. It
is initiated by some other process as a result of an external request from
another system or server that is being run by the same Trading Role. The
processing required is as follows:
*	if the IotpTransId of the transaction to be cancelled is not
recognised, or complete then fail the request, otherwise
*	if the IotpTransId refers to an Inquiry Transaction or a Ping
Transaction then fail the request, otherwise
*	determine which Document Exchange to cancel and generate a Cancel
Block and send it to the other party
	[Note]	Cancelling a transaction on an IOTP server typically arises
for a business reason. For example a merchant may have attempted
authentication several times without success and as a result decides to
cancel the transaction. Therefore the process that decides to take this
action needs to send a message from the process/server that made the
business decision to the IOTP server with the instruction that the IOTP
transaction should be cancelled.
	[Note End]	 
##

> --
> 
> 7.4 Trading Role Information Request Component
> In 7.4,
> 
> -- Start
>       o a Merchant requesting that a Consumer provides Organization
>         Components for the Consumer and DelivTo Trading Roles
> -- End
> 
> We get only one Trading Role when we use TradingRoleList because 
> TradingRoleList defines as NMTOKEN. So I suggest to change from
> NMTOKEN to NMTOKENS.
##Agreed##

> --
> 
> 7.7.4 Currency Amount Element
> Could you register "ISO4217-N" on IANA also because this is used in
> the SMILE Project?
##See separate email.##

> --
> 
> 7.10 Payment Scheme Component
> There is no description for the PaymentRef in PatSchemeData.
## Added definition as follows:
	An Element Reference (see section 3.5) to the Payment Component (see
section 7.9) to which this Pay Scheme Data Component relates. It is required
unless the Pay Scheme Data is part of an Transaction Inquiry Status
Transaction (see section 9.2.1).
##

> --
> 
> 7.10 Payment Scheme Component
> The PaymentRef Element is not used when Inquiry transaction is
> processed.  I suggest the PaymentRef changes from #REQUIRED to
> #IMPLIED and we should add the note that the PaymentRef must use in
> the Payment Transaction but does not use in the Inquiry Transaction.
##Agreed. For details see previous comment##

> --
> 
> 7.15.3 Delivery Completion Codes
> There is no description about the recovery possibility for
> DelivCancelled and Confirmed.
##They should both be "Recovery is not possible."##

> --
> 
> 9.2.1 Baseline Transaction Status Inquiry IOTP Transaction
> In 6.1.3:
> --Start
>       o Transaction Status Inquiry. The Inquiry Response Block may
>         be digitally signed to attest to the authenticity of the
>         response
> --End
> 
> 
> But there is no description about the signature of Inquiry Response
> Message
>  in 9.2.1 (and in 7.18 also.)
##Agreed.
Added definitions for Inquiry Reuest Signature and Inqiuiry Reponse
Signature as follows:
	7.18.7	Inquiry Request Signature Component
	If the Inquiry Request is being signed (see section 9.2.1) the
Manifest Element of the Inquiry Request Signature Component should contain
Digest elements of Inquiry Type Component, and if present, the Payment
Scheme Component

	7.18.8	Inquiry Response Signature Component
	If the Inquiry Response is being signed (see section 9.2.1) the
Manifest Element of the Inquiry Response Signature Component should contain
Digest elements of the Trading Response Block and the Status Component.

... and in section 9.2.1 ...
SIGNATURE BLOCK (INQUIRY REQUEST)
	If a signature block is present on the message containing the
Inquiry Request Block then it may be checked to determine if the Inquiry
Request is authorised.

	If present, the Inquiry Request Signature Block (see section 8.12)
contains the following components:
	o one Signature Component (see section 7.18)
	o one or more Certificate Components, if required.

	Inquiry Response Blocks should only be generated if the Transaction
is authorised.

	[Note] 
	Digital signatures on an Inquiry Request is only likely to occur if
the recipient of the request expects the Inquiry Request to be signed. In
this version of IOTP this will require some kind of pre-existing agreement.
This means that:
	o Consumers are unlikely to generate requests with signatures,
although it is not an error if they do
	o the other trading roles may agree that digital signatures are
required. For example a Payment Handler may require that an Inquiry Request
is digitally signed by the Merchant so that they can check that the request
is valid.

	On the other hand if the original transaction to which the Inquiry
relates was carried out over a secure channel (e.g. [SSL]) then it is
probably reasonable to presume that if the sender of the Inquiry knows the
Transaction Id component of the original message (including for example the
timestamp) then the inquiry is likely to be genuine.

	 [Note End] 

... and ...
	SIGNATURE BLOCK (INQUIRY RESPONSE)
	If a signature block is present on the message containing the
Inquiry Response Block then it may be checked by the receiver of the block
to determine if the Inquiry Response is valid.

	If present, the Inquiry Response Signature Block (see section 8.13)
contains the following components:
	o one Signature Component (see section 7.18)
	o one or more Certificate Components, if required.

	 [Note] 
	Digital signatures on an Inquiry Response is only likely to occur if
the recipient of the response expects the Inquiry Request to be signed. In
this version of IOTP this will require some kind of pre-existing agreement.
This means that:
	o Consumers are unlikely to generate responses with signatures,
although it is not an error if they do
	o the other trading roles may agree that digital signatures are
required. For example a Merchant may require that an Inquiry Response is
digitally signed by the Payment Handler so that they can check that the
request response is valid.
	 [Note End] 

... also changed message flow for Transaction Status Inquiry to show
optional signature on Inquiry Response.

##

> Additional, 
> In 9.2.1: 
> -- Start
>      1 --> 2 INQUIRY REQUEST. IotpMsg: TransRef Block; Signature Block
>              (optional); Inquiry Request Block
> -- End
> 
> I could not find the description where the Consumer has to sign in 9.2.1
> (and in 7.18 also.)
## It is unlikely that the consumer will have to sign. See Notes on
Signature Block (Inquiry Response) and Signature Block (Inquiry Request).
##

> --
> 
> 7.15.1 (Page134)
> Minor misspelling:
>  ConsCancelbled-> ConsCancelled
## Changed ##
> --
> 
> Other:
> 
> The current IOTP Spec has not reflected the brand new IOTP-DSIG Draft
> yet.  My thought is that we should split off the description of DSIG
> as much as possible in order to avoid consistency
## In principle they need to be separate, but I don't think so for this
version. I plan to update the IOTP spec to reflect the new dsig draft
shortly. ##

> Regards,
> --
> Yoshiaki Kawatsura    Hitachi, Ltd.
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 

**********************************************************************************************

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: [email-masked]
To: [email-masked], [email-masked]
Subject: RE: Signature on a PayNote Component
Date: Wed, 28 Jul 1999 03:40:26 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Masaaki

Good idea ... Payment Note added to Payment Response Signature.

David

-----Original Message-----
From: Masaaki Hiroya [mailto:[email-masked]]
Sent: Tuesday, July 06, 1999 12:41 AM
To: [email-masked]; [email-masked]
Subject: Signature on a PayNote Component

David

We need PayNote components to be signed together with
PayReceipt components.

Some payment handlers need to issue receipts with 
their own styles to display them visually using HTML or
XML + style sheets besides the payment-scheme specific 
receipts.

They should also be signed by the payment handlers to 
be proved that they are issued by them.

The PayReceipt packaged contents will be passed to
the payment bridges, so I think non-payment-scheme specific
receipts issued by payment handlers should be contained 
in PayNote packaged contents to avoid errors in the 
payment bridges.

Therefore, we want the digest of the PayNote component 
to be added to the Payment Receipt Signature component.

Masaaki

-----
Masaaki Hiroya
Systems Development Laboratory
Hitachi, Ltd.
tel: +81-44-549-1531
fax: +81-44-549-1640
email: [email-masked]
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

**********************************************************************************************

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: [email-masked]
To: [email-masked], [email-masked],  [email-masked]
Subject: RE: Handling Duplicate Messages
Date: Wed, 28 Jul 1999 03:40:21 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Chris/Masaaki
 
Thanks for thinking this through. Propose the following changes to add a new
type of Transient Error as Masaaki suggested. Details below.
 
David
 
Added new Error Code to indicate that "Message is being processed" called
"MsgBeingProc". "ReqInProgress" which Masaaki thought of seems to suggest
that it can only apply to a request when in fact it could also work with an
exchange message such as a Payment Exchange. Its description is ...

"Message being processed. This error code is only used with a Severity of
Transient Error. It indicates that the previous message, which may be an
exchange message or a request message, is being processed and, if no
response is received by the time indicated by the MinRetrySecs attribute,
then the original message should be resent."

I also noticed that there isn't an error code to indicate that a "Server (or
other system) Is Busy" so I've added another code called SystemBusy with a
description of ...

"SystemBusy. This error code is only used with a Severity of Transient
Error. It indicates that the system that received a message is currently too
busy to handle the message. If no response is received by the time indicated
by the MinRetrySecs attribute, then the original message should be resent.
This code should be used when to indicate that a server (e.g. HTTP) 

[Note] If the server/system handling the Transport Mechanism (e.g. HTTP) is
busy then a Transport Specific error message should be used instead of an
IOTP Error message. This code should be used in association with IOTP
servers/systems or other servers/systems to which the IOTP server is
connected.
[Note End]"

Added to section 4.5.2.2 Checking/Handling Duplicate Messages ...

	"... If processing has not completed then generate an Error
Component with a Severity of Transient Error and an Error Code of to
indicate the message is being processed and send it back to the sender of
the Input Message requesting that the original message be resent after an
appropriate period of time."

... and clarified section 4.5.2.3 Processing Non-Duplicate Message (CHECKING
A SERVER IS AVAILABLE) to say ...

	"... If the server is too busy, then it should generate an Error
Component with a Severity of Transient Error and an Error Code of SystemBusy
and send it back to the sender of the Input Message requesting that the
original message be resent after an appropriate period of time."

... and in PROCESS THE ERROR FREE INPUT MESSAGE changed ... 

*	if the Input message contains an Error Block with a Transient Error
then wait for the required time then resend the previous message

... to ...

*	if the Input message contains an Error Block with a Transient Error
then wait for the required time then resend the previous message, if a
response to the earlier message has not been received

... Also updated ServerLogic.txt and ConsumerLogic.txt

 

  -----Original Message-----
From: Smith, Chris [mailto:[email-masked]]
Sent: Monday, July 26, 1999 7:08 AM
To: 'Masaaki Hiroya'; Smith, Chris ; [email-masked];
[email-masked]
Subject: RE: Handling Duplicate Messages

> 
> > Perhaps the preferred solution would be to indicate exactly what 
> > condition actually exists. Can we specify that a status is sent back, 
> > indicating that the request is still being processed? Such a status 
> > prevents the double reply, while indicating to a client that (if they 
> > are certain of no more replies) they should pause and then resubmit 
> > the duplicate in order to retrieve the reply after processing is 
> > complete (if it isn't complete, they get another status = 
> in process). 
> 
> Why do you prefer to send back the status indicating request is in 
> progress rather than to send back a transient error indicating request 
> is in progress? 
> 
> In order to send back the status indicating request is in progress, 
> it is necessary to define a new block to contain the status or 
> change the PayExchBlk.  Furthermore, a new status type should be 
> added such as "MsgExch" status since the payment status is always 
> in progress during payment document exchange (until sending 
> back PayRespBlk). 
> 
> If we use a transient error message, all we have to do is to add a new 
> error code such as "ReqInProgress". 

Sorry if I wasn't clear - I wanted a status sent back, 
not a Status. Adding the code would resolve the concern. 

I did not want the client to receive the same response 
for two different situations. One is that there is no 
response in progress, and there is a transient error. 
The other (this case) is that there is a response in 
progress. 

We should provide some indication that the previous 
request (the abandoned one) was actually received to 
prevent the client timing out while in a condition of 
assuming the request was never received. 

Incidentally, this also provides a potentially valuable 
response for transport layers that must reply, and want 
to state something useful that will keep the client working 
on the transaction. Under such circumstances, it would be 
possible to reply with TransientError/ReqInProgress to the 
original request. The client would then be aware that the 
work is in progress, and will come back periodically to get 
the response. 

(An example of this might be an e-mail based connection, 
where the server side has determined that manual intervention 
is required. The server can indicate ReqInProgress, and then 
set MinRetrySecs to a very high number of seconds (perhaps 
86400 seconds) indicating that the client can come back for 
the reply tomorrow.) 

------------------------------------------------------------ 
 Chris Smith                                +1.416.348.6090 
 Royal Bank                       [email-masked] 

**********************************************************************************************

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: [email-masked]
To: [email-masked], [email-masked]
Subject: RE: ErrorLocation Component
Date: Wed, 28 Jul 1999 03:40:15 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Masaaki

See comments below.

David

-----Original Message-----
From: Masaaki Hiroya [mailto:[email-masked]]
Sent: Monday, July 26, 1999 5:34 AM
To: [email-masked]; [email-masked]
Subject: ErrorLocation Component

David,

The current spec in 7.20.3 says as follows:

<!ELEMENT ErrorLocation EMPTY >
<!ATTLIST ErrorLocation
 ElementType        NMTOKEN #REQUIRED
 IotpMsgRef          NMTOKEN #REQUIRED
 BlkRef             NMTOKEN #IMPLIED
 CompRef            NMTOKEN #IMPLIED
 ElementRef         NMTOKEN #IMPLIED
 AttName            NMTOKEN #IMPLIED >

ElementType         This is the "type" (see [XML]) of the Element in
                    the message in error where the error is located.

I could find the definition of the type of Element in XML spec.
What kind of values will be set to ElementType?
## If you had an element with a declaration of, say ...

<!ELEMENT Org ...

then its element type would be "Org", so really its just the name of the
element.

I've clarified the defintion as follows ...

This is the name of the type of the element where the error is located. For
example if the element was declared as <!ELEMENT Org ... then its name is
"Org".

##

Furthermore, the DTD of ErrorLocation in Chapter 13 is different from
the one in 7.20.3.  Is IotpMsgRef #IMPLIED or #REQUIRED?
## Its IMPLIED as if your can't find the Message Id Component then you can't
specify a value. ##
Masaaki

-----
Masaaki Hiroya
Systems Development Laboratory
Hitachi, Ltd.
email: [email-masked]
tel: +81-44-549-1531
fax: +81-44-549-1640

**********************************************************************************************

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: [email-masked]
To: [email-masked], [email-masked]
Subject: RE: ConsumerDeliveryId
Date: Wed, 28 Jul 1999 03:40:32 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Andrew, I've been putting this one off since to handle it properly it
requires a new component which is generated by the Consumer that contains
only this item. But on the other hand, it could be important, particularly
if the sender of the Delivery Request is a system (e.g. a B2B system) rather
than real person to be able to identify the message that is being returned.

Detailed changes below.

David

1. Define new Consumer Delivery Data Component ...

<!-- CONSUMER DELIVERY DATA COMPONENT -->
<!ELEMENT ConsumerDeliveryData EMPTY >
<!ATTLIST ConsumerDeliveryData
 ID                 ID      #REQUIRED
 ConsumerDeliveryId CDATA   #REQUIRED >

2. Remove ConsumerDeliveryId from the Delivery Component. Now defined as ...

<!-- DELIVERY COMPONENT -->
<!ELEMENT Delivery (DeliveryData?, PackagedContent*) >
<!ATTLIST Delivery
 ID                 ID      #REQUIRED
 xml:lang           NMTOKEN #REQUIRED
 DelivExch          (True | False) #REQUIRED
 DelivAndPayResp    (True | False) #REQUIRED
 ActionOrgRef       NMTOKEN #IMPLIED >

3. Add optional ConsumerDeliveryData component to Delivery Request Block as
follows ...

<!-- DELIVERY REQUEST BLOCK -->
<!ELEMENT DeliveryReqBlk (Status+, Order, Org*, Delivery,
     ConsumerDeliveryData?, TradingRoleData*) >
<!ATTLIST DeliveryReqBlk
 ID                 ID      #REQUIRED >

4. Changed spec as follows:

- removed description of ConsumerDeliveryId from the Delivery Component
- added section to describe ConsumerDeliveryData Component with defintion as
above
- added description of use of ConsumerDeliveryData Component in a Delivery
Request Block
- included signing of the ConsumerDeliveryData Component by the Delivery
Response Signature if present.

-----Original Message-----
From: Andrew Drapp [mailto:[email-masked]]
Sent: Wednesday, June 16, 1999 8:00 PM
To: 'Ietf Trade WG'
Subject: ConsumerDeliveryId

In section 6.2, the ConsumerDeliveryId is 
described as follows:

---
An identifier specified by the Consumer which, 
if returned by the Delivery Handler in another
Delivery Component, or by other means, will
enable the Consumer to identify which Delivery
is being referred to. 
---

This is a bit confusing.  The first time the
ConsumerDeliveryId is used is in the Offer Response
Block, so I assume that it is defined by the
Merchant.  What exactly is meant by "specified"?
Would replacing "specified" with "used" clarify
or change the meaning?

Furthermore, should this Id be unique within
the IOTP transaction, or globally unique?

Regards,

Andrew

--
Andrew Drapp
[email-masked]
Systems Development Laboratory, Hitachi Ltd.
Ozenji 1099, Asao, Kawasaki, 215-0013 JAPAN
TEL:+81-44-966-9111   FAX:+81-44-966-1796
PGP Fingerprint: 84D8 3D19 018E 9385 6581  0081 C89C D2AD F06A 565F

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

**********************************************************************************************

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: [email-masked]
To: [email-masked], [email-masked]
Subject: Numeric currency codes
Date: Wed, 28 Jul 1999 03:40:08 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Yoshiaki asks ...

> 7.7.4 Currency Amount Element
> Could you register "ISO4217-N" on IANA also because this is used in
> the SMILE Project?
> 
I'm wondering why since:
*	we debated at some length earlier this year whether to go for alpha
or numeric and concluded that alpha was to be preferred
*	having just one type of code makes it easier to develop clients
since there is no need to support (and keep up to date) both types
*	since there is a one-to-one correspondence between the alpha and the
numeric you can always map between the two

... but on the other hand if there's a good reason ... Yoshiaki, can  you
explain?

Thanks

David

Mondex International
Email: [email-masked]

**********************************************************************************************

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: "Smith, Chris " <[email-masked]>
To: 'Masaaki Hiroya' <[email-masked]>,  "Smith, Chris " <[email-masked]>, [email-masked],  [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
Subject: RE: Handling Duplicate Messages
Date: Mon, 26 Jul 1999 10:07:38 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BED770.372E0768
Content-Type: text/plain; 
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit

> 
> > Perhaps the preferred solution would be to indicate exactly what 
> > condition actually exists. Can we specify that a status is sent back, 
> > indicating that the request is still being processed? Such a status 
> > prevents the double reply, while indicating to a client that (if they
> > are certain of no more replies) they should pause and then resubmit
> > the duplicate in order to retrieve the reply after processing is 
> > complete (if it isn't complete, they get another status = 
> in process).
> 
> Why do you prefer to send back the status indicating request is in 
> progress rather than to send back a transient error indicating request
> is in progress?
> 
> In order to send back the status indicating request is in progress, 
> it is necessary to define a new block to contain the status or 
> change the PayExchBlk.  Furthermore, a new status type should be
> added such as "MsgExch" status since the payment status is always 
> in progress during payment document exchange (until sending 
> back PayRespBlk).
> 
> If we use a transient error message, all we have to do is to add a new
> error code such as "ReqInProgress".

Sorry if I wasn't clear - I wanted a status sent back,
not a Status. Adding the code would resolve the concern.

I did not want the client to receive the same response
for two different situations. One is that there is no
response in progress, and there is a transient error.
The other (this case) is that there is a response in
progress.

We should provide some indication that the previous
request (the abandoned one) was actually received to
prevent the client timing out while in a condition of
assuming the request was never received.

Incidentally, this also provides a potentially valuable 
response for transport layers that must reply, and want 
to state something useful that will keep the client working
on the transaction. Under such circumstances, it would be 
possible to reply with TransientError/ReqInProgress to the
original request. The client would then be aware that the 
work is in progress, and will come back periodically to get 
the response.

(An example of this might be an e-mail based connection, 
where the server side has determined that manual intervention 
is required. The server can indicate ReqInProgress, and then 
set MinRetrySecs to a very high number of seconds (perhaps 
86400 seconds) indicating that the client can come back for 
the reply tomorrow.)

------------------------------------------------------------
 Chris Smith                                +1.416.348.6090
 Royal Bank                       [email-masked]

------_=_NextPart_001_01BED770.372E0768
Content-Type: text/html; 
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2448.0">
<TITLE>RE: Handling Duplicate Messages</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Perhaps the preferred solution would be to indicate exactly what </FONT>
<BR><FONT SIZE=2>&gt; &gt; condition actually exists. Can we specify that a status is sent back, </FONT>
<BR><FONT SIZE=2>&gt; &gt; indicating that the request is still being processed? Such a status </FONT>
<BR><FONT SIZE=2>&gt; &gt; prevents the double reply, while indicating to a client that (if they</FONT>
<BR><FONT SIZE=2>&gt; &gt; are certain of no more replies) they should pause and then resubmit</FONT>
<BR><FONT SIZE=2>&gt; &gt; the duplicate in order to retrieve the reply after processing is </FONT>
<BR><FONT SIZE=2>&gt; &gt; complete (if it isn't complete, they get another status = </FONT>
<BR><FONT SIZE=2>&gt; in process).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Why do you prefer to send back the status indicating request is in </FONT>
<BR><FONT SIZE=2>&gt; progress rather than to send back a transient error indicating request</FONT>
<BR><FONT SIZE=2>&gt; is in progress?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; In order to send back the status indicating request is in progress, </FONT>
<BR><FONT SIZE=2>&gt; it is necessary to define a new block to contain the status or </FONT>
<BR><FONT SIZE=2>&gt; change the PayExchBlk.&nbsp; Furthermore, a new status type should be</FONT>
<BR><FONT SIZE=2>&gt; added such as &quot;MsgExch&quot; status since the payment status is always </FONT>
<BR><FONT SIZE=2>&gt; in progress during payment document exchange (until sending </FONT>
<BR><FONT SIZE=2>&gt; back PayRespBlk).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; If we use a transient error message, all we have to do is to add a new</FONT>
<BR><FONT SIZE=2>&gt; error code such as &quot;ReqInProgress&quot;.</FONT>
</P>

<P><FONT SIZE=2>Sorry if I wasn't clear - I wanted a status sent back,</FONT>
<BR><FONT SIZE=2>not a Status. Adding the code would resolve the concern.</FONT>
</P>

<P><FONT SIZE=2>I did not want the client to receive the same response</FONT>
<BR><FONT SIZE=2>for two different situations. One is that there is no</FONT>
<BR><FONT SIZE=2>response in progress, and there is a transient error.</FONT>
<BR><FONT SIZE=2>The other (this case) is that there is a response in</FONT>
<BR><FONT SIZE=2>progress.</FONT>
</P>

<P><FONT SIZE=2>We should provide some indication that the previous</FONT>
<BR><FONT SIZE=2>request (the abandoned one) was actually received to</FONT>
<BR><FONT SIZE=2>prevent the client timing out while in a condition of</FONT>
<BR><FONT SIZE=2>assuming the request was never received.</FONT>
</P>

<P><FONT SIZE=2>Incidentally, this also provides a potentially valuable </FONT>
<BR><FONT SIZE=2>response for transport layers that must reply, and want </FONT>
<BR><FONT SIZE=2>to state something useful that will keep the client working</FONT>
<BR><FONT SIZE=2>on the transaction. Under such circumstances, it would be </FONT>
<BR><FONT SIZE=2>possible to reply with TransientError/ReqInProgress to the</FONT>
<BR><FONT SIZE=2>original request. The client would then be aware that the </FONT>
<BR><FONT SIZE=2>work is in progress, and will come back periodically to get </FONT>
<BR><FONT SIZE=2>the response.</FONT>
</P>

<P><FONT SIZE=2>(An example of this might be an e-mail based connection, </FONT>
<BR><FONT SIZE=2>where the server side has determined that manual intervention </FONT>
<BR><FONT SIZE=2>is required. The server can indicate ReqInProgress, and then </FONT>
<BR><FONT SIZE=2>set MinRetrySecs to a very high number of seconds (perhaps </FONT>
<BR><FONT SIZE=2>86400 seconds) indicating that the client can come back for </FONT>
<BR><FONT SIZE=2>the reply tomorrow.)</FONT>
</P>

<P><FONT SIZE=2>------------------------------------------------------------</FONT>
<BR><FONT SIZE=2>&nbsp;Chris Smith&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +1.416.348.6090</FONT>
<BR><FONT SIZE=2>&nbsp;Royal Bank&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [email-masked]</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BED770.372E0768--

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
Subject: Minutes for Oslo TRADE WG Meeting
Date: Tue, 27 Jul 1999 09:34:56 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

[Recorded by Donald Eastlake and corrected by Dave Burdett.  Please
send me any further corrections.  Slides will be made available and/or
sent out separately.  Donald]

*   Agenda Bashing 5 min
*   Implementation Reports
*   SMILE - Hitachi 15 min
*   Royal Bank of Canada, SIZ, ...
*   IOTP specifications
     *   IOTP version 1.0 - David Burdett 20 min
*   Digital Signatures for IOTP - Kent Davidson 5 min
    *   Supplements:
    *   Arch & API supplement - Hans Werner 5 min
    *   SET supplement - Hitahci 5 min
    *   SCCD supplement - Tom Arnold (Jason Eaton) 5 min
    *   HTTP supplement - Don Eastlake 5 min
    *   eCheck, ACH, ...
*   XML Messaging - David Burdett 30 min
*   Related topic reports
*   ECML - Donald Eastlake 5 min
*   What's Next for Internet Commerce - Ko Fujimura 15 min
*   OECD and Taxation on the Internet - David Burdett 10 min
*   Possible Charter revisions... 5 min

Minutes, taken by Donald Eastlake

There were no suggested changes to the agenda.

Yoshiaki Kawatsura of Hitachi presented an update on the status of the
SMILE project.  (see separate slides)

David Burdett mentioned that there was an IOTP 1.0 implementation by
the Royal Bank of Canada and that one was planned this year by SIZ.

Donald Eastlake and David Burdett mentioned that a company is
advertising that they are developing an IOTP toolkit in Java.  Info on
this was on the mailing list but will be reposted.

Dave Burdett presented the changes in the main IOTP v1.0 Protocol
document made in version 3 to produce version 4 of the protocol draft.
There was some discussion of the change which permitted optional
authentication at the beginning of most transactions.

Steve Crocker wanted to know why that was needed, whether
authentication would be manually or automatically initiated, and if
manual how the user could tell if they should do so.  Dave Burdett
indicated he primarily thought of it as user initiated.  Tony Lewis
gave some business to business examples where it could reasonably be
automatic.

Kent Davidson, author of the companion IOTP v1.0 Digital Signature
document could not be here.  Donald Eastlake indicated that the
digital signature document needed a little more polishing.  The main
protocol document and the digital signature document together are
needed to implement IOTP.

A straw poll was taken and indicated overwhelming support by those in
the room to advance these two IOTP v1.0 protocol specification
documents to the IESG for Informational RFC within a few weeks.  (The
IESG may choose to do an IETF wide last call on them.)  It was
suggested that the XML DTD in these two documents be tried with
various XML processing tools to be sure it will work with them,

The existing supplemental documents were discussed briefly.

The plan is to finalize the Architecture and API supplement shortly
after the main protocol documents are final and publish it as an
informational RFC.

Hitachi presented some slides on the SET supplement.  (see separate
slides)

Jason Easton spoke briefly on the SCCD supplement which Tom Arnold is
authoring.  Tom had planned to be present but got called away from the
IETF meeting due to business considerations.  SCCD (Secure Channel
Credit Debit) is a payment protocol intended to be used via an SSL or
similar secure channel and provide the equivalent of SSL secured plain
text forms for credit card charges.  This should be out as an I-D
within three weeks.

Donald Eastlake spoke briefly on the HTTP supplement.  He feels it
needs more input from the WG and requests comments.

Possible additional payment system supplements covering eCheck and ACH
we listed by Donald Eastlake.  Tony Lewis questioned the presence of
ACH as it normally requires prior written authorization but Steve
Crocker thought it should be there.

David Burdett gave a presentation on the messaging layer of IOTP.
Because commerce examples were used in the presentation there was also
some discussion of future additions to IOTP such as split payments.

There was strong consensus to split off the XML Messaging layer of
IOTP as a separate specification to be developed in the TRADE WG.
Comments on this will be sought on the mailing list.

Donald Eastlake gave a presentation on ECML (www.ecml.org).  David
Burdett said that it was largely complementary to IOTP and could be
used to detect the presence of an IOTP wallet.

Ko Fujimura of NTT gave a presentation on "What's Next in Internet
Commerce" which concentrated on Digital Right, such as sale of
memberships, use of coupons, sale of subscriptions, loyalty systems,
etc.  There appeared to be a consensus at the meeting to have a BoF
like meeting on this topic at the next IETF meeting assuming at a
minimum, that a draft requirements document can be prepared in time.
This needs discussion on the mailing list.

Finally, David Burdett gave an informational presentation on the OECD
and Taxation.  (See separate slides.)

Due to lack of time, charter revision was not discussed at the WG
meeting but will be persuaded on the list.

Donald E. Eastlake, 3rd
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: Invalid IotpTransId
Date: Mon, 26 Jul 1999 19:58:54 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

In Yoshiaki's other email he raised a good point. I've replied in a separate
email to raise visibility ...

When I wrote this part of the spec (see below) I was debating whether or not
to include the original input message since if you think about it, the data
will probably have got through without corruption if it is well formed.
However, it is so unlikely that the IotpTransId cannot be recognised that I
thought it a good idea to include the original message. Your comment is
making me think again.

What do folks think?

David

> 4.5.2.1 Checking Structure and Message Identity
> -- Start
>   If the message is well formed but the IotpTransId cannot be identifie
>   then generate an ErrorComponent with:
> 
>       o a Severity of HardError and an ErrorCode of AttMissing,
> 
>       o one PackagedContent containing the original Input Message,
>         and
> 
>       o the second PackagedContent containing "IotpTransId" - the
>         missing attribute.
> 
>   Insert the Error Component inside an Error Block with a new
>   TransactionId component with a new IotpTransId and return it to the
>   sender of the original message.
> --End
> I have two questions.
> 
> Question 1. If we include two PackagedContent Components in Error
> Component, we have to decide the both Name element(s) so that Consumer
> side OAC recognizes them and handles.
> 
> Question 2. This is the only case that the Original Input Message is
> included in the Packaged Content of Error Component isn't it?
> 

**********************************************************************************************

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

Date: Mon, 26 Jul 1999 21:33:47 +0900
To: [email-masked], [email-masked]
From: Masaaki Hiroya <[email-masked]>
Subject: ErrorLocation Component
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David,

The current spec in 7.20.3 says as follows:

<!ELEMENT ErrorLocation EMPTY >
<!ATTLIST ErrorLocation
 ElementType        NMTOKEN #REQUIRED
 IotpMsgRef          NMTOKEN #REQUIRED
 BlkRef             NMTOKEN #IMPLIED
 CompRef            NMTOKEN #IMPLIED
 ElementRef         NMTOKEN #IMPLIED
 AttName            NMTOKEN #IMPLIED >

ElementType         This is the "type" (see [XML]) of the Element in
                    the message in error where the error is located.

I could find the definition of the type of Element in XML spec.
What kind of values will be set to ElementType?

Furthermore, the DTD of ErrorLocation in Chapter 13 is different from
the one in 7.20.3.  Is IotpMsgRef #IMPLIED or #REQUIRED?

Masaaki

-----
Masaaki Hiroya
Systems Development Laboratory
Hitachi, Ltd.
email: [email-masked]
tel: +81-44-549-1531
fax: +81-44-549-1640
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

Date: Mon, 26 Jul 1999 20:42:23 +0900
To: "Smith, Chris " <[email-masked]>, [email-masked],  [email-masked]
From: Masaaki Hiroya <[email-masked]>
Subject: RE: Handling Duplicate Messages
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

> Perhaps the preferred solution would be to indicate exactly what 
> condition actually exists. Can we specify that a status is sent back, 
> indicating that the request is still being processed? Such a status 
> prevents the double reply, while indicating to a client that (if they
> are certain of no more replies) they should pause and then resubmit
> the duplicate in order to retrieve the reply after processing is 
> complete (if it isn't complete, they get another status = in process).

Why do you prefer to send back the status indicating request is in 
progress rather than to send back a transient error indicating request
is in progress?

In order to send back the status indicating request is in progress, 
it is necessary to define a new block to contain the status or 
change the PayExchBlk.  Furthermore, a new status type should be
added such as "MsgExch" status since the payment status is always 
in progress during payment document exchange (until sending back PayRespBlk).

If we use a transient error message, all we have to do is to add a new
error code such as "ReqInProgress".

Is there any problem if the server sends back a transient error message
when request is in progress?

Masaaki

> ------------------------------------------------------------ 
>  Chris Smith                                +1.416.348.6090 
>  Royal Bank                       [email-masked] 
> 
> > -----Original Message----- 
> > From: Masaaki Hiroya [mailto:[email-masked]] 
> > Sent: July 22, 1999 12:50 AM 
> > To: [email-masked]; [email-masked] 
> > Subject: Handling Duplicate Messages 
> > 
> > 
> > 
> > David 
> > 
> > The IOTP spec V1.0-04 says as follows: 
> > 
> > >   4.5.2.2 Checking/Handling Duplicate Messages 
> > > 
> > >   If the input message can be identified as potentially a 
> > valid input 
> > >   message then check to see if an "identical" input message has been 
> > >   received before. Identical means that all blocks, components, 
> > >   elements, attribute values and element content in the 
> > input message 
> > >   are the same. 
> > > 
> > >   If an identical message has been received before then 
> > check to see if 
> > >   the processing of the previous message has completed. 
> > > 
> > >   If processing has not completed then do nothing as the 
> > processing of 
> > >   the previous message will result in a response if required. 
> > 
> > I think "If processing has not completed then do nothing" might cause 
> > some problems. 
> > 
> > If timemout occurs in the IOTP client while it is waiting for 
> > a response 
> > messege from the server, the session (connnection) is usually 
> > disconnected. 
> > In this case, the client cannot receive the response message for the 
> > original request message. 
> > 
> > It the server takes much time to handle the original request message, 
> > the IOTP client will receive an empty http message from the server 
> > when it retransmits the request message due to the timeout event 
> > since the server does nothing during processing the original message. 
> > 
> > I think it's better to send a transient error message from the server 
> > to the client for retry after an appropriate period of time 
> > if processing the original request message has not completed. 
> > 
> > Besides, it should also clearly be defined that the IOTP client 
> > should disconnect the previous session before retransmission. 
> > in order to avoid the duplicate messages received by the client. 
> > 
> > Any comment? 
> > 
> > Masaaki 
> > 
> > ----- 
> > Masaaki Hiroya 
> > Systems Development Laboratory 
> > Hitachi, Ltd. 
> > email: [email-masked] 
> > tel: +81-44-549-1531 
> > fax: +81-44-549-1640 
> > -------------------------------------------------------------- 
> > --------- 
> > Message addressed to: [email-masked] 
> > Archive available at: http://www.elistx.com/archives/ietf-trade/ 
> > To (un)subscribe send a message with "subscribe" or 
> > "unsubscribe" in the 
> > body to: [email-masked] 
> > 
> 
-----
Masaaki Hiroya
Systems Development Laboratory
Hitachi, Ltd.
email: [email-masked]
tel: +81-44-549-1531
fax: +81-44-549-1640
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: "Smith, Chris " <[email-masked]>
To: 'Masaaki Hiroya' <[email-masked]>, [email-masked],  [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
Subject: RE: Handling Duplicate Messages
Date: Thu, 22 Jul 1999 14:33:42 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BED471.0C4760F0
Content-Type: text/plain; 
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit

The difficulty with this approach is that it assumes that a session exists.

If IOTP is using HTTP or HTTPS as a transport layer, then this is certainly
true. However, it is quite possible that a different transport layer may not
have sessions. In such a case, the client cannot ensure that the first reply
will not be received.

Initially, it would seem that the more sensible (but difficult) approach
would be to have the duplicate message wait on the completion of the
original and then pick up the results and return them. However, if the
transport is sessionless, the client will get both replies, and they should
be identical replies. However, these two identical replies should both be
processed (one as an original, one as a duplicate), perhaps resulting in two
continuing threads of control in some clients. Clearly this approach is not
wise, although it should not cause problems if clients retain a tight
context around transactions in progress.

In fact, this problem is always possible if the sessionless reply and the
duplicate request pass each other in transit.

The above solution also has the annoying difficulty that the system stores
up all the duplicates received, and then releases all the replies at once to
a client who has sent in multiple requests. Remember, the client does not
know the request is in progress - they only know that no reply has been
received.

Perhaps the preferred solution would be to indicate exactly what condition
actually exists. Can we specify that a status is sent back, indicating that
the request is still being processed? Such a status prevents the double
reply, while indicating to a client that (if they are certain of no more
replies) they should pause and then resubmit the duplicate in order to
retrieve the reply after processing is complete (if it isn't complete, they
get another status = in process).

...chris

------------------------------------------------------------
 Chris Smith                                +1.416.348.6090
 Royal Bank                       [email-masked]

> -----Original Message-----
> From: Masaaki Hiroya [mailto:[email-masked]]
> Sent: July 22, 1999 12:50 AM
> To: [email-masked]; [email-masked]
> Subject: Handling Duplicate Messages
> 
> 
> 
> David
> 
> The IOTP spec V1.0-04 says as follows:
> 
> >   4.5.2.2 Checking/Handling Duplicate Messages
> > 
> >   If the input message can be identified as potentially a 
> valid input
> >   message then check to see if an "identical" input message has been
> >   received before. Identical means that all blocks, components,
> >   elements, attribute values and element content in the 
> input message
> >   are the same.
> > 
> >   If an identical message has been received before then 
> check to see if
> >   the processing of the previous message has completed.
> > 
> >   If processing has not completed then do nothing as the 
> processing of
> >   the previous message will result in a response if required.
> 
> I think "If processing has not completed then do nothing" might cause 
> some problems.
> 
> If timemout occurs in the IOTP client while it is waiting for 
> a response
> messege from the server, the session (connnection) is usually 
> disconnected.
> In this case, the client cannot receive the response message for the 
> original request message.
> 
> It the server takes much time to handle the original request message,
> the IOTP client will receive an empty http message from the server
> when it retransmits the request message due to the timeout event
> since the server does nothing during processing the original message.
> 
> I think it's better to send a transient error message from the server
> to the client for retry after an appropriate period of time
> if processing the original request message has not completed.
> 
> Besides, it should also clearly be defined that the IOTP client 
> should disconnect the previous session before retransmission.
> in order to avoid the duplicate messages received by the client.
> 
> Any comment?
> 
> Masaaki
> 
> -----
> Masaaki Hiroya
> Systems Development Laboratory
> Hitachi, Ltd.
> email: [email-masked]
> tel: +81-44-549-1531
> fax: +81-44-549-1640
> --------------------------------------------------------------
> ---------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or 
> "unsubscribe" in the
> body to: [email-masked]
> 

------_=_NextPart_001_01BED471.0C4760F0
Content-Type: text/html; 
 charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>RE: Handling Duplicate Messages</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>The difficulty with this approach is that it assumes =
that a session exists.</FONT>
</P>

<P><FONT SIZE=3D2>If IOTP is using HTTP or HTTPS as a transport layer, =
then this is certainly true. However, it is quite possible that a =
different transport layer may not have sessions. In such a case, the =
client cannot ensure that the first reply will not be =
received.</FONT></P>

<P><FONT SIZE=3D2>Initially, it would seem that the more sensible (but =
difficult) approach would be to have the duplicate message wait on the =
completion of the original and then pick up the results and return =
them. However, if the transport is sessionless, the client will get =
both replies, and they should be identical replies. However, these two =
identical replies should both be processed (one as an original, one as =
a duplicate), perhaps resulting in two continuing threads of control in =
some clients. Clearly this approach is not wise, although it should not =
cause problems if clients retain a tight context around transactions in =
progress.</FONT></P>

<P><FONT SIZE=3D2>In fact, this problem is always possible if the =
sessionless reply and the duplicate request pass each other in =
transit.</FONT>
</P>

<P><FONT SIZE=3D2>The above solution also has the annoying difficulty =
that the system stores up all the duplicates received, and then =
releases all the replies at once to a client who has sent in multiple =
requests. Remember, the client does not know the request is in progress =
- they only know that no reply has been received.</FONT></P>

<P><FONT SIZE=3D2>Perhaps the preferred solution would be to indicate =
exactly what condition actually exists. Can we specify that a status is =
sent back, indicating that the request is still being processed? Such a =
status prevents the double reply, while indicating to a client that (if =
they are certain of no more replies) they should pause and then =
resubmit the duplicate in order to retrieve the reply after processing =
is complete (if it isn't complete, they get another status =3D in =
process).</FONT></P>

<P><FONT SIZE=3D2>...chris</FONT>
</P>

<P><FONT =
SIZE=3D2>------------------------------------------------------------</F=
ONT>
<BR><FONT SIZE=3D2>&nbsp;Chris =
Smith&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +1.416.348.6090</FONT>
<BR><FONT SIZE=3D2>&nbsp;Royal =
Bank&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Masaaki Hiroya [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]=
</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: July 22, 1999 12:50 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [email-masked]; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Handling Duplicate Messages</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; David</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The IOTP spec V1.0-04 says as follows:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; 4.5.2.2 Checking/Handling =
Duplicate Messages</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; If the input message can be =
identified as potentially a </FONT>
<BR><FONT SIZE=3D2>&gt; valid input</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; message then check to see if =
an &quot;identical&quot; input message has been</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; received before. Identical =
means that all blocks, components,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; elements, attribute values and =
element content in the </FONT>
<BR><FONT SIZE=3D2>&gt; input message</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; are the same.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; If an identical message has =
been received before then </FONT>
<BR><FONT SIZE=3D2>&gt; check to see if</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; the processing of the previous =
message has completed.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; If processing has not =
completed then do nothing as the </FONT>
<BR><FONT SIZE=3D2>&gt; processing of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; the previous message will =
result in a response if required.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I think &quot;If processing has not completed =
then do nothing&quot; might cause </FONT>
<BR><FONT SIZE=3D2>&gt; some problems.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If timemout occurs in the IOTP client while it =
is waiting for </FONT>
<BR><FONT SIZE=3D2>&gt; a response</FONT>
<BR><FONT SIZE=3D2>&gt; messege from the server, the session =
(connnection) is usually </FONT>
<BR><FONT SIZE=3D2>&gt; disconnected.</FONT>
<BR><FONT SIZE=3D2>&gt; In this case, the client cannot receive the =
response message for the </FONT>
<BR><FONT SIZE=3D2>&gt; original request message.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; It the server takes much time to handle the =
original request message,</FONT>
<BR><FONT SIZE=3D2>&gt; the IOTP client will receive an empty http =
message from the server</FONT>
<BR><FONT SIZE=3D2>&gt; when it retransmits the request message due to =
the timeout event</FONT>
<BR><FONT SIZE=3D2>&gt; since the server does nothing during processing =
the original message.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I think it's better to send a transient error =
message from the server</FONT>
<BR><FONT SIZE=3D2>&gt; to the client for retry after an appropriate =
period of time</FONT>
<BR><FONT SIZE=3D2>&gt; if processing the original request message has =
not completed.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Besides, it should also clearly be defined that =
the IOTP client </FONT>
<BR><FONT SIZE=3D2>&gt; should disconnect the previous session before =
retransmission.</FONT>
<BR><FONT SIZE=3D2>&gt; in order to avoid the duplicate messages =
received by the client.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Any comment?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Masaaki</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----</FONT>
<BR><FONT SIZE=3D2>&gt; Masaaki Hiroya</FONT>
<BR><FONT SIZE=3D2>&gt; Systems Development Laboratory</FONT>
<BR><FONT SIZE=3D2>&gt; Hitachi, Ltd.</FONT>
<BR><FONT SIZE=3D2>&gt; email: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; tel: +81-44-549-1531</FONT>
<BR><FONT SIZE=3D2>&gt; fax: +81-44-549-1640</FONT>
<BR><FONT SIZE=3D2>&gt; =
--------------------------------------------------------------</FONT>
<BR><FONT SIZE=3D2>&gt; ---------</FONT>
<BR><FONT SIZE=3D2>&gt; Message addressed to: =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Archive available at: <A =
HREF=3D"http://www.elistx.com/archives/ietf-trade/" =
TARGET=3D"_blank">http://www.elistx.com/archives/ietf-trade/</A></FONT>
<BR><FONT SIZE=3D2>&gt; To (un)subscribe send a message with =
&quot;subscribe&quot; or </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;unsubscribe&quot; in the</FONT>
<BR><FONT SIZE=3D2>&gt; body to: =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BED471.0C4760F0--

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

Date: Thu, 22 Jul 1999 13:50:27 +0900
To: [email-masked], [email-masked]
From: Masaaki Hiroya <[email-masked]>
Subject: Handling Duplicate Messages
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David

The IOTP spec V1.0-04 says as follows:

>   4.5.2.2 Checking/Handling Duplicate Messages
> 
>   If the input message can be identified as potentially a valid input
>   message then check to see if an "identical" input message has been
>   received before. Identical means that all blocks, components,
>   elements, attribute values and element content in the input message
>   are the same.
> 
>   If an identical message has been received before then check to see if
>   the processing of the previous message has completed.
> 
>   If processing has not completed then do nothing as the processing of
>   the previous message will result in a response if required.

I think "If processing has not completed then do nothing" might cause 
some problems.

If timemout occurs in the IOTP client while it is waiting for a response
messege from the server, the session (connnection) is usually disconnected.
In this case, the client cannot receive the response message for the 
original request message.

It the server takes much time to handle the original request message,
the IOTP client will receive an empty http message from the server
when it retransmits the request message due to the timeout event
since the server does nothing during processing the original message.

I think it's better to send a transient error message from the server
to the client for retry after an appropriate period of time
if processing the original request message has not completed.

Besides, it should also clearly be defined that the IOTP client 
should disconnect the previous session before retransmission.
in order to avoid the duplicate messages received by the client.

Any comment?

Masaaki

-----
Masaaki Hiroya
Systems Development Laboratory
Hitachi, Ltd.
email: [email-masked]
tel: +81-44-549-1531
fax: +81-44-549-1640
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
Subject: Open Trading Protocol Toolkit
Date: Tue, 20 Jul 1999 10:04:50 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

At the TRADE WG meeting in Olso I promised to repost the information about
the company that say s it is developing an IOPT toolkit in Java.  It
is the Xenosys Corporation.  See <http://www.livebiz/jotp/body.html>.

Thanks,
Donald

=====================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668     [email-masked]
 65 Shindegan Hill Road, RR#1  +1 914-784-7913(work)  [email-masked]
 Carmel, NY 10512 USA
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
Cc: [email-masked]
Cc: [email-masked]
Subject: Comments for the IOTP current draft 
Date: Thu, 15 Jul 1999 16:03:48 +0900 (JST)
From: Yoshiaki Kawatsura <[email-masked]>
Lines: 8
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David,
I sent my comments for the current draft of IOTP to you 2 weeks ago.
Please let me know your comment.

Thanks,
-
Yoshiaki Kawatsura   Hitachi, Ltd. in Oslo :-)

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From:   
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
Bcc:  
Reply-To:   
Subject: E E mail @adp.ccom
Date: Wed, 14 Jul 1999 13:58:10 -0400 (EDT)
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

                             BULK E - MAIL WITHOUT LOSING YOUR ISP

                                                   Do you have an idea? 
                                           Are you trying to sell a product? 
                                      Would you like to promote a web page?
                             Do you have an MLM you would like to advertise?

     	                  WE CAN HELP!!!
_________________________________________

BULK E-MAIL WORKS

We provide individuals & businesses alike with a way to reach millions. 
 High response at a low cost rate. Don't rely on newspapers or billboards.
 People MUST SEE YOUR AD!!!

    New addresses, fresh names are what make the difference!!!
______________________________________

Keep the Net alive with your ad. Remember, a lot of business is through word of mouth, but in the computer age, the computer is where most word of mouth is carried.

     SO GET YOUR AD OUT NOW!!!!!
______________________________________

Start with 100 thousand for only  $200.00
Call us about our rates.  The more you send, the more you save, 
and the better your response rate!!!

Call us now!   1-888-219-2310

ask about our discounts for large orders!!!

_______________________________

If you would like to be removed, send your list and include yourself in it to:
[email-masked]
*******************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: [email-masked]
To: [email-masked], [email-masked]
Subject: RE: Error Handling 
Date: Tue, 6 Jul 1999 17:40:43 +0100 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Masaaki

Now I see my mistake. I've changed the relevent text in Server Logic as
you've suggested.

David

> ----------
> From: 	Masaaki Hiroya[SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	27 June 1999 10:56
> To: 	[email-masked]; [email-masked]
> Subject: 	RE: Error Handling 
> 
> 
> David
> 
> At 03:04 99/6/26 +0100, [email-masked] wrote:
> > Masaaki
> > 
> > There was one question I didn't answer earlier so here it is now.
> > 
> > Your question was:
> > 
> > 	" (1) According to IOTP v1.0-03, ProcessState="ProcessError" for
> > technical errors and ProcessState="Failed" for business errors, but in
> the
> > example logic ProcessState="Failed" and CompletionCode="ProcessError"
> for
> > technical errors.  Which is correct?"
> > 
> > Currently the spec says:
> > 
> > 	*	"ProcessError. This value is only used when the Status
> > Component is being used in connection with an Inquiry Request Trading
> Block
> > (see section 8.12). It indicates there was a Technical Error (see
> section
> > 4.1) in the Request Block which is being processed or some internal
> > processing error."
> > 
		> Process Errors are *only* used in a Status Component
inside a Inquiry
> > Response Block. It indicates that the transaction being inquired upon
> had
> > resulted in an Error Block being generated either by the Consumer or the
> > IOTP server roles. You can't send the Original Error Block back as it
> would
> > indicate that there was an error in the Inquiry Request Block when in
> fact
> > it was OK.
> > 
> > Hope this helps.
> > 
> > David
> 
> I think my question wasn't appropriated, and I should have asked you more
> specifically.
> 
> I think the above sentences in the current spec. say that a Status
> Component 
> with ProcessState="ProcessError" should be generated when the transaction 
> being inquired upon had resulted in an Error Block being generated either 
> by the Consumer or the IOTP server roles.
> 
> However, the following sentences in the ProcessInquiryRequestBlock of the
> "ServerLogic.txt" you sent before say that a Status Component with 
> ProcessState="Failed" and CompletionCode="ProcessError"should be generated
> 
> when the same cases as above occur.
> 
> ----- beginning of quote -----
> ProcessInquiryRequestBlock
> ==========================
> /* This responds to an Inquiry from another party on the current state of
> a Document Exchange. */
> If the Inquiry Refers to a Ping Transaction then
>       .......
>       .......
>   If Inquiry is OK, then
>     Retrieve Status information for original Document Exchange
>       If original Document Exchange had technical errors then
>         Generate Status component with 
>           ProcessState of Failed and CompletionCode of ProcessError
>           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>         Generate an ErrorBlock describing the errors in the original
> Document Exchange
>         Include generated Status Component in Inquiry Response block
>         Save Inquiry Response Block and Error Block for inclusion in
> output message
> ----- end of quote -----
> 
> This is why I asked the question.
> I think the answer is that the former one (ProcessState="ProcessError") is
> correct
> according to your reply.
> 
> Regards
> Masaaki
> 
> 
> 
> > 
> > > ----------
> > > From: 	[email-masked][SMTP:[email-masked]]
> > > Sent: 	20 June 1999 21:29
> > > To: 	[email-masked]; [email-masked]
> > > Subject: 	RE: Error Handling 
> > > 
> > > Masaaki
> > > 
> > >  I don't have time to look into all your questions right now but there
> are
> > > some answers below ...
> > > 
> > > David
> > > 
> > > > ----------
> > > > From: 	Masaaki Hiroya[SMTP:[email-masked]]
> > > > Reply To: 	[email-masked]
> > > > Sent: 	19 June 1999 19:28
> > > > To: 	[email-masked]; [email-masked]
> > > > Subject: 	RE: Error Handling 
> > > > 
> > > > 
> > > > David,
> > > > 
> > > > The example logic for the processing required at an IOTP server and
> > > > the new specification derived from it are really helpful to design
> > > > IOTP servers.
> > > > 
> > > > I have several questions about it.
> > > > 
> > > > (1)
> > > > According to IOTP v1.0-03, ProcessState="ProcessError" for technical
> > > > errors
> > > > and ProcessState="Failed" for business errors, but in the example
> logic
> > > > ProcessState="Failed" and CompletionCode="ProcessError" for
> technical
> > > > errors.  Which is correct?
> > > ## Not sure. Will check ##
> > > 
> > > > (2)
> > > > It is not explicitly described in the following sentences that the 
> > > > Payment Handler can accept a new PayReq message when transient
> > > > a business error occurs after receiving PayExch messages, 
> > > > but the following sentences indicate that it can accept 
> > > > the new PayReq message in such a case, don't they?
> > > > 
> > > > >   . Payment Request Block (Payment Handler only). Check as
> follows:
> > > > >     - if the Payment  Request Block refers  to an IOTP
> Transaction
> > > > >       that is not recognised then its OK, otherwise
> > > > >     - if the Payment Request Block refers to IOTP Transaction
> that
> > > > >       was not for a Payment then it is a Hard Error, otherwise
> > > > >     - if the  previous payment CompletedOk  OR failed  with a
> non-
> > > > >       recoverable  Completion  Code  then  it  is  a  Hard
> Error,
> > > > >       otherwise
> > > > >     - if the  previous payment is  still in progress  then it is
> a
> > > > >       Hard Error
> > > ## The Payment Handler should be able to accept a new PayReq message
> after
> > > either:
> > > *	a transient error (i.e. the Payment Handler was too busy to process
> > > the first PayReq, or
> > > *	after a "recoverable" business error. Some Completion Codes are
> > > recoverable some are not see my earlier email with revised completion
> > > codes##
> > > 
> > > > (3)
> > > > Will it be described in the client role processing which message
> > > > the client should send to the server depending on the completion
> code
> > > > when business errors occur?
> > > ## Not completely as it is dependent on the problem and what the
> options
> > > are. For example, if a Mondex Card doesn't have sufficient value then
> the
> > > options available to the Consumer include (there may be more):
> > > *	using a different card - this means you just send a new Payment
> > > Request
> > > *	loading the card with more value and then trying again - this would
> > > also need a new Payment Request
> > > *	using a different brand - this would involve a brand selection -
> > > currently this only possible if the payment is brand independent. 
> > > 
> > > Similarly if an authentication fails then the consumer can just
> re-enter a
> > > new password, for example, or use a different authentication method.##
> > > 
> > > > (4)
> > > > Are there any cases that IOTP servers receive transient errors
> > > > from IOTP clients?
> > > > As far as I think, there are no such cases, but I want to confirm it
> > > > since I couldn't find sentences which describe it explicitly.
> > > > 
> > > > If there are such cases, how do the IOTP servers behave?
> > > ## Yes, as the Consumer role might be implemented on a server which
> might
> > > be
> > > busy. In this case, the behavious will be exactly the same as for the
> > > consumer, i.e. you wait for the required time then you send the *same*
> > > message again. I've been working on the Consumer logic - nearly
> finished -
> > > and this highlighted the need. I'll be sending out an updated
> > > "serverlogic.txt" file when I send out the Consumer Logic one which
> should
> > > (I hope) be this week, although this week is very busy for me. ##
> > > 
> > > > Thank you in advance
> > > > Masaaki
> > > > 
> > > > 
> > > > At 04:10 99/6/15 +0100, David Burdett wrote:
> > > > > 
> > > > > Apologies for the delays folks but this took longer than
> anticipated.
> > > > > Particularly I found I could only really get my mind round how to
> > > handle
> > > > > idempotency by going down a level of detail and start thinking
> about
> > > the
> > > > > logic required at a server. Anyway the result is in the attached
> two
> > > > files
> > > > > which describe:
> > > > > - example logic for the procecssing required at an IOTP server
> (i.e. a
> > > > > merchant, a payment handler or a delivery handler), and
> > > > > - a replacement set of text for the IOTP specification which was
> > > > actually
> > > > > derived from the logic, but is at a higher level.
> > > > > 
> > > > > 
> > > > > I haven't started the consumer logic yet, but I think that having
> done
> > > > the
> > > > > IOTP server, it should be easier.
> > > > > 
> > > > > 
> > > > > I *really* would like peoples views on whether or not the level of
> > > > detail
> > > > > provided in the example logic is useful and if the Server Role
> > > > Processing
> > > > > description is an improvement. Also please note that it has not
> yet
> > > been
> > > > > reviewed by *anyone* so no doubt you'll find bugs ;) . Anyway I've
> > > tried
> > > > to
> > > > > make the logic reasonably complete, so please let me know what you
> > > > think.
> > > > > 
> > > > > 
> > > > > David
> > > > >  <<ServerLogic.txt>>  <<Server Role Procecssing.txt>> 
> > > > > 
> > > > 
> > > > 
> > > > 
> > > > -----
> > > > Masaaki Hiroya
> > > > Systems Development Laboratory
> > > > Hitachi, Ltd.
> > > > tel: +81-44-549-1531
> > > > fax: +81-44-549-1640
> > > > email: [email-masked]
> > > >
> -----------------------------------------------------------------------
> > > > Message addressed to: [email-masked]
> > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> > > > body to: [email-masked]
> > > > 
> > > 
> > >
> **************************************************************************
> > > ********************
> > > 
> > > This Email and any attached files are confidential and may also be
> > > privileged. 
> > > If you are not the intended recipient, please notify the postmaster
> using
> > > email 
> > > address [email-masked] or call +44 171 557 5000 and ask for the
> 
> > > IT Helpdesk.  You should not copy this email and any attached files,
> use
> > > them 
> > > for any purpose or disclose the contents to any other person; all
> copies
> > > of the 
> > > Email and associated files in your possession should be destroyed.
> > > 
> > > Mondex International Limited
> > > 47-53 Cannon Street
> > > London EC4M 5SQ
> > > United Kingdom
> > > Registered No: 3122085, England
> > > 
> > > Phone:          +44 171 557 5000
> > > Fax:            +44 171 557 5200
> > > Email:          [email-masked]
> > > WebSite:        http://www.mondexinternational.com
> > > 
> > >
> **************************************************************************
> > > *******************
> > >
> -----------------------------------------------------------------------
> > > Message addressed to: [email-masked]
> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> > > body to: [email-masked]
> > > 
> > 
> >
> **************************************************************************
> **
> > ******************
> > 
> > This Email and any attached files are confidential and may also be 
> > privileged. 
> > If you are not the intended recipient, please notify the postmaster
> using email 
> > address [email-masked] or call +44 171 557 5000 and ask for the 
> > IT Helpdesk.  You should not copy this email and any attached files, use
> them 
> > for any purpose or disclose the contents to any other person; all copies
> of the 
> > Email and associated files in your possession should be destroyed.
> > 
> > Mondex International Limited
> > 47-53 Cannon Street
> > London EC4M 5SQ
> > United Kingdom
> > Registered No: 3122085, England
> > 
> > Phone:          +44 171 557 5000
> > Fax:            +44 171 557 5200
> > Email:          [email-masked]
> > WebSite:        http://www.mondexinternational.com
> > 
> >
> **************************************************************************
> **
> > *****************
> > 
> 
> -----
> Masaaki Hiroya
> Systems Development Laboratory
> Hitachi, Ltd.
> tel: +81-44-549-1531
> fax: +81-44-549-1640
> email: [email-masked]
> 

**********************************************************************************************

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: [email-masked]
To: [email-masked]
Subject: IOTP specification changes 03-> 04
Date: Tue, 6 Jul 1999 17:40:44 +0100 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

The following is a list of the major changes to the latest version of the
IOTP specification in approximately the order they were raised and applied:
1) Added Merchant authentication by a Consumer as part of the early stages
of an IOTP Purchase Transaction 
2) Allow any party to use an Authentication Transaction with any other party
at any point in time.
3) Created a new section on IANA Considerations
4) Used a better approach to describing message flows which makes diagrams
easier to understand especially over page boundaries 
5) Moved information about Brands and Brand Selection into its own Section
and combined with examples of Brand selection 
6) Introduced the ProtocolBrandId attribute to contain protocol specific
brand names
7) Amended Packaged Content to:
   a) allow one HTML document to refer to another HTML document 
   b) define how XML is encapsulated within Packaged Content
8) Split the section on Security Considerations into two parts covering:
   a) a section discussing how IOTP uses security, and
   b) a section on how IOTP uses Digital Signatures
9) Provided more detail on how IOTP can use Symmetric Key Cryptography 
10) Agreed that Currency Codes should always be alphabetic
11) Clarified the definition of BrandId to support cobrands and promotional
brands. This involved breaking the link between IOTP brand ids and SET brand
Ids and using IANA to register new brands.
12)  Used the Name rather than the ID Attribute to identify the Packaged
Contents that form a Payment Receipt
13) Allowed any party to inquire of any other party to a trade about the
current status of a transaction
14) Changed all usage of OTP to IOTP
15) Added the Authentication ID attribute to the Authentication Response
component
16) Reworked the Auth Data component so that it is now split into two parts:
   a) an Authentication Request component that just requests an
authentication, and
   b) Trading Role Information request component that requests the return of
Organisation information about one more Trading Roles
17) Reworked the IOTP Error Handling section to be more explicit on handling
errors. Also included the creation of two sets of "logic" that describe the
processing required by the Consumer and the Server Trading Roles. This
included allowing re-submission of messages after failure depending on the
Completion Code.

David

**********************************************************************************************

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
Subject: Preliminary Draft Trade WG Meeting Agenda for Olso
Date: Tue, 06 Jul 1999 12:40:15 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Sorry this is getting out a bit late.

*	Agenda Bashing
*	Implementation Reports...
*	IOTP specifications
	*	Internet Open Trading Protocol version 1.0 - David Burdett
	*	Supplements:
		*	Digital Signatures for IOTP - Kent Davidson
		*	Architecture Supplement - ?
		*	HTTP supplement - Don Eastlake
		*	SET supplement - ?
		*	SCCD supplement - Tom Arnold
*	OECD and Taxation on the Internet - David Burdett
*	XML Messaging - David Burdett
*	Any related topic reports (ECML, Micropayments, ...)
*	Discussion of possible Charter revisions...
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
cc: [email-masked]
Subject: -04 version of protocol draft and related documents on ftp site
Date: Tue, 06 Jul 1999 10:14:03 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

The -iotp-v1.0-protocol-04.txt draft and related documents are now
available at <ftp://ftp.pothole.com/pub/ietf-trade/v1.0-protocol-04/>.
This includes an MS Word version of the document, the DTD as a
separate file, and consumer and server logic documents.  The -03
version documents have been moved down one level to a parallel
directory at <ftp://ftp.pothole.com/ietf-trade/v1.0-protocol-03/>.

Thanks,
Donald

=====================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668     [email-masked]
 65 Shindegan Hill Road, RR#1  +1 914-784-7913(work)  [email-masked]
 Carmel, NY 10512 USA
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

Reply-To: [email-masked]
Date: Tue, 06 Jul 1999 16:40:53 +0900
To: [email-masked], [email-masked]
From: Masaaki Hiroya <[email-masked]>
Subject: Signature on a PayNote Component
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David

We need PayNote components to be signed together with
PayReceipt components.

Some payment handlers need to issue receipts with 
their own styles to display them visually using HTML or
XML + style sheets besides the payment-scheme specific 
receipts.

They should also be signed by the payment handlers to 
be proved that they are issued by them.

The PayReceipt packaged contents will be passed to
the payment bridges, so I think non-payment-scheme specific
receipts issued by payment handlers should be contained 
in PayNote packaged contents to avoid errors in the 
payment bridges.

Therefore, we want the digest of the PayNote component 
to be added to the Payment Receipt Signature component.

Masaaki

-----
Masaaki Hiroya
Systems Development Laboratory
Hitachi, Ltd.
tel: +81-44-549-1531
fax: +81-44-549-1640
email: [email-masked]
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
Cc: [email-masked]
Cc: [email-masked]
Subject: My Comments of IOTP Spec Release4
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Mon, 05 Jul 1999 17:43:36 +0900 (JST)
Lines: 170
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David,
My comments of the IOTP Specification Release4 as follows:

---
1.6 Document Structure (Page 14 )
DigiCash is the company name so please change to eCash.

---

3.1.1 (Page34) 
Minor misspelling:
 |  |-Certificate Comp. < Certificate Component (0ptional) Used to chec
                                                 ^
Please change from integer "0" to Alphabet "O".

---

3.3.2  MsgId Component
There is no description of LangPrefList and CharSetPrefList.

--
3.4.1 Trading Role Element
There is no definition the IotpMsgIdPrefix for DelivTo.
DelivTo Trading Role does not use this because DelivTo does not
send the IOTP Message. But IotpMsgIdPrefix is mandatory.
Should we set "C" as the Consumer?

---

3.6.1 Extra XML Elements
IOTP:Critical (True|False) #TRUE
should be changed to
IOTP:Critical (True|False) 'True' 

--

4.5.2.1 Checking Structure and Message Identity
-- Start
  If the message is well formed but the IotpTransId cannot be identifie
  then generate an ErrorComponent with:

      o a Severity of HardError and an ErrorCode of AttMissing,

      o one PackagedContent containing the original Input Message,
        and

      o the second PackagedContent containing "IotpTransId" - the
        missing attribute.

  Insert the Error Component inside an Error Block with a new
  TransactionId component with a new IotpTransId and return it to the
  sender of the original message.
--End
I have two questions.

Question 1. If we include two PackagedContent Components in Error
Component, we have to decide the both Name element(s) so that Consumer
side OAC recognizes them and handles.

Question 2. This is the only case that the Original Input Message is
included in the Packaged Content of Error Component isn't it?

--

4.5.2.3 Processing Non-Duplicate Message
Please add the description of the transient error as follows:
Current:
      o if no hard errors result, then processing the message and
        generating an output message, if required, for return to
        the sender of the Input Message
New:
      o if no hard error and transient error result, 
        then processing the message and
        generating an output message, if required, for return to
        the sender of the Input Message

--

4.5.3 Cancelling a Transaction
In 4.5.3,
--Start
      o if the IotpTransId refers to Inquiry Transaction or a Ping
        Transaction then fail the request, otherwise
--End

We use the same IotpTransId, which is used in the Payment
Transaction, whenever the Inquiry Transaction is processed. So we
should revise the above description as follows:

      o if the IotpTransId refers to a Ping
        Transaction then fail the request, otherwise

--

7.4 Trading Role Information Request Component
In 7.4,

-- Start
      o a Merchant requesting that a Consumer provides Organization
        Components for the Consumer and DelivTo Trading Roles
-- End

We get only one Trading Role when we use TradingRoleList because 
TradingRoleList defines as NMTOKEN. So I suggest to change from
NMTOKEN to NMTOKENS.

--

7.7.4 Currency Amount Element
Could you register "ISO4217-N" on IANA also because this is used in
the SMILE Project?

--

7.10 Payment Scheme Component
There is no description for the PaymentRef in PatSchemeData.

--

7.10 Payment Scheme Component
The PaymentRef Element is not used when Inquiry transaction is
processed.  I suggest the PaymentRef changes from #REQUIRED to
#IMPLIED and we should add the note that the PaymentRef must use in
the Payment Transaction but does not use in the Inquiry Transaction.

--

7.15.3 Delivery Completion Codes
There is no description about the recovery possibility for
DelivCancelled and Confirmed.

--

9.2.1 Baseline Transaction Status Inquiry IOTP Transaction
In 6.1.3:
--Start
      o Transaction Status Inquiry. The Inquiry Response Block may
        be digitally signed to attest to the authenticity of the
        response
--End

But there is no description about the signature of Inquiry Response Message
 in 9.2.1 (and in 7.18 also.)

Additional, 
In 9.2.1: 
-- Start
     1 --> 2 INQUIRY REQUEST. IotpMsg: TransRef Block; Signature Block
             (optional); Inquiry Request Block
-- End

I could not find the description where the Consumer has to sign in 9.2.1
(and in 7.18 also.)

--

7.15.1 (Page134)
Minor misspelling:
 ConsCancelbled-> ConsCancelled
--

Other:

The current IOTP Spec has not reflected the brand new IOTP-DSIG Draft
yet.  My thought is that we should split off the description of DSIG
as much as possible in order to avoid consistency.

Regards,
--
Yoshiaki Kawatsura    Hitachi, Ltd.
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
Cc: [email-masked]
Cc: [email-masked]
Subject: Re: draft-ietf-trade-iotp-v1.0-dsig-01.txt
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Thu, 01 Jul 1999 12:33:37 +0900 (JST)
Lines: 75
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Kent,
I have a quick comment and question for your draft.

1. Comment
I do not know why but it seems to me that your draft has dropped "="
in the whole your XML example
for example:
   <Digest DigestAlgorithmRef "D.1">
       <Locator href "resource locator"/>
       <Value>
            (Digest value)
       </Value>
   </Digest>  .

You should revise this for conforming to XML Specification as follows;
   <Digest DigestAlgorithmRef="D.1">
       <Locator href="resource locator"/>
       <Value>
            (Digest value)
       </Value>
   </Digest>  .

Additional,
In 4.3.8 Prameter:
   <Algorithm ID A1 type "digest" name "urn:ibm:dom-hash">
           <Parameter type 'AlgorithmRef'>A2</Parameter>
   </Algorithm>
   <Algorithm ID A2 type "digest" name "urn:fips:sha1">
   </Algorithm>
   <Algorithm ID A3 type "signature" name "urn:ibm:hmac">
           <Parameter type 'AlgorithmRef'>A1</Parameter>
   </Algorithm>

This has been dropped quotation. Please change as follows:

   <Algorithm ID="A1" type="digest" name="urn:ibm:dom-hash">
           <Parameter type='AlgorithmRef'>A2</Parameter>
   </Algorithm>
   <Algorithm ID="A2" type="digest" name="urn:fips:sha1">
   </Algorithm>
   <Algorithm ID="A3" type="signature" name="urn:ibm:hmac">
           <Parameter type='AlgorithmRef'>A1</Parameter>
   </Algorithm>

2. Question(1)
In 4.3.8 Parameter:

On one hand, the type attribute is defined as PCDATA in 4.3.8, on the
other hand, this attribute is defined as CDATA in Chapter7(Signature
DTD)
Which is correct?

3. Question(2)
In 5.1.2 SHA1:
--
5.1.2 SHA1

   Surface string digest algorithm designed by hte US government for use
                                               ^^^
   with the Digital Signature Standard. This algorithm produces a 160-
   bit hash value.
--
What does "hte" mean?

Thanks,
--
Yoshiaki Kawatsura, Hitachi, Ltd.

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
Cc: [email-masked]
Cc: [email-masked]
Subject: Re: draft-ietf-trade-iotp-v1.0-dsig-01.txt
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Fri, 02 Jul 1999 20:45:05 +0900 (JST)
Lines: 91
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Kent,
I have one more quick question.

On one hand, the child element of Parameter is defined as ANY in 4.3.5, on the
other hand, this element  is defined as #PCDATA in Chapter7(Signature
DTD)
Which is correct?

Thanks,
--
Yoshiaki Kawatsura   Hitachi, Ltd.

>>>>> Thu, 01 Jul 1999 12:33:37 +0900 (JST),
	Yoshiaki KAWATSURA <[email-masked]> said:

> Kent,
> I have a quick comment and question for your draft.
> 
> 1. Comment
> I do not know why but it seems to me that your draft has dropped "="
> in the whole your XML example
> for example:
>    <Digest DigestAlgorithmRef "D.1">
>        <Locator href "resource locator"/>
>        <Value>
>             (Digest value)
>        </Value>
>    </Digest>  .
> 
> You should revise this for conforming to XML Specification as follows;
>    <Digest DigestAlgorithmRef="D.1">
>        <Locator href="resource locator"/>
>        <Value>
>             (Digest value)
>        </Value>
>    </Digest>  .
> 
> Additional,
> In 4.3.8 Prameter:
>    <Algorithm ID A1 type "digest" name "urn:ibm:dom-hash">
>            <Parameter type 'AlgorithmRef'>A2</Parameter>
>    </Algorithm>
>    <Algorithm ID A2 type "digest" name "urn:fips:sha1">
>    </Algorithm>
>    <Algorithm ID A3 type "signature" name "urn:ibm:hmac">
>            <Parameter type 'AlgorithmRef'>A1</Parameter>
>    </Algorithm>
> 
> This has been dropped quotation. Please change as follows:
> 
> 
>    <Algorithm ID="A1" type="digest" name="urn:ibm:dom-hash">
>            <Parameter type='AlgorithmRef'>A2</Parameter>
>    </Algorithm>
>    <Algorithm ID="A2" type="digest" name="urn:fips:sha1">
>    </Algorithm>
>    <Algorithm ID="A3" type="signature" name="urn:ibm:hmac">
>            <Parameter type='AlgorithmRef'>A1</Parameter>
>    </Algorithm>
> 
> 
> 2. Question(1)
> In 4.3.8 Parameter:
> 
> On one hand, the type attribute is defined as PCDATA in 4.3.8, on the
> other hand, this attribute is defined as CDATA in Chapter7(Signature
> DTD)
> Which is correct?
> 
> 
> 3. Question(2)
> In 5.1.2 SHA1:
> --
> 5.1.2 SHA1
> 
>    Surface string digest algorithm designed by hte US government for use
>                                                ^^^
>    with the Digital Signature Standard. This algorithm produces a 160-
>    bit hash value.
> --
> What does "hte" mean?
> 
> 
> Thanks,
> --
> Yoshiaki Kawatsura, Hitachi, Ltd.
> 
> 
> 
> 
p> 
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]