Subject: Server role processing sequence
From: Jordán László <[email-masked]>
To: [email-masked]
Date: Thu, 30 Sep 1999 11:43:40 +0200

Here are some lines from the latest IETF draft:

4.5.2.4 Check for Errors in Block Sequence

 Errors in the sequence that blocks arrive depends on the block. Blocks
 where checking for sequence is required are:
...
 o 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
...

JL> I cannot understand, how can refer a Payment Request Block to an IOTP
Transaction. If this means that a Payment Request IOTP message has the same
IotpTransId as a previous message, then I have the following problem with
the third paragraph[*]: If an IOTP Transaction involves more than one
payments the second payment never will be processed at the Payment Handler.

Regards: Laszlo

-----------------------------------------------------------------------
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: XML Style of the (Current) SMILE specific Payment API.
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Thu, 30 Sep 1999 19:36:40 +0900 (JST)
Lines: 24
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

The followings are the (current) SMILE specific Payment API.
All API functions have empty response functions.

<!ELEMENT QuitPaymentInstrument EMPTY>
<!ATTLIST QuitPaymentInstrument
     PaymentInstrumentId	CDATA	#REQUIRED>

<!ELEMENT CancelPayment EMPTY>
<!ATTLIST CancelPayment
          MerchantPayId   CDATA   #REQUIRED
          ProcessState    (Failed |
			   ProcessError)	#REQUIRED >
         CompletionCode  NMTOKEN #IMPLIED>

<!ELEMENT RemovePaymentLog EMPTY>
<!ATTLIST RemovePaymentLog
          PayId  CDATA  #REQUIRED>

Thanks,
----
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]

To: [email-masked]
Cc: [email-masked]
Cc: [email-masked]
Subject: Re: AW: Payment API
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Wed, 29 Sep 1999 17:07:15 +0900 (JST)
Lines: 814
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Werner,
My comments are embedded between  **YK** and **YK END**.

(No.1)
---------------------------
FindAcceptedPayBrand Function:
-> MerchantOrgId
 Comment:This needs when more than one Merchants exist in the IOTP
 Merchant Server (and Mall).
***Deferred. Do we really need this item? Separation between merchants is
possible by different wallet identifiers. At the client side, multiple
consumers might use the same SET wallet. They as well as their data are
distinguished by different wallet identifiers.
MerchantOrgds might be encoded in these identifiers.***

-> MerchantData
 Comment: This element is used to be set the Mall access keys which use
 to get information in the Mall.

***Deferred. Does the IOTP Payment Bridge resp. Existing Payment Software
directly access the mall system? I believe, that this has to be done by the
IOTP Application Core.***
FindAcceptedPayBrandResponse Function:

**YK**
Some Payment Specific Systems need the Merchant Related Data in the
Initiation (and this data is included in the ProtocolPackagedContent
Component).  We separate the MerchantOrgId from MerchantData because
this is common attribute.  As to the MerchantPayId which is in
StartPaymentPaymnetHandler, the WalletId may be able to use instead.
**YK END**
----------------------------

(2)
----------------------------
FindPaymentInstrument and FindPaymentProtocol Function:
 Comment:We merged FindPaymentInstrument and FindPaymentProtocol into
 FindPaymentInstrument and dropped the FindPaymentProtocol API because
 ProtocolBrandId depends on both Payment Brand and Payment Protocol and
 it may invite unnecessary processes.

***Design decision: The serialization by two calls was intended to decrease
the possible huge complexity of finding the valid payment instruments at the
client side. The first function should filter out IOTP Payment Bridges that
do not support a brand for any payment protocol. E.g., having three Payment
Bridges each for Mondex(-Mondex), Mastercard-SET, and Mastercard-SCCD. With
your proposal, you have to issue three calls to each of the three Payment
Bridges but only six calls to infer the supported brands and one further
call for Mondex or two for the other schemes with the previous scheme. The
situation might get even worse with more payment alternatives and more
registered payment bridges. However, in situations with few Payment Bridges
your design performs better.
Note that the internal complexity of the first call is at the implementer's
choice.
Another design decision deals with your input parameter ProtocolId. By
providing this as an input parameter, the API function must be called for
each accepted payment protocol. E.g., one Payment Bridge supporting both
Mastercard-SET and Mastercard-SCCD must be requested twice while one call
suffices in the previous approach.
The time of presentment of the ProtocolBrandId seems to be a pure design
decision, due to the one to one relationship with the ProtocolId, if
present. I deferred the presentment to GetPaymentInitializationData because
such this ID might be stored in a chip card whose insertion should be
deferred as long as possible for user friendliness.
Other opinions?***

**YK**
The PaymentBrandId depends on both Protocol and Brand.  In SET, this
ID needs for getting the Instrument ID so this has to be passed it in
FindPaymentInstrument. so The time of presentment of the
ProtocolBrandId is not a pure design decision evenif these have the
one to one relationship with the ProtocolId. So I strongly suggest
these API should merge.
**YK END**

 Our FindPaymentInstrument function is as follows:
 <!ELEMENT FindPaymentInstrument (BrandPackagedContent*,
       ProtocolBrandPackagedContent*,ProtocolPackagedContent*,
       ProtocolAmountPackagedContent*) >
 <!ATTLIST FindPaymentInstrument
  BrandId       CDATA   #REQUIRED
  ProtocolId    CDATA   #REQUIRED
  ProtocolBrandId       CDATA   #IMPLIED
  PayDirection  (Debit|Credit)  #REQUIRED
  CurrCodeType  NMTOKEN 'ISO4217-A'
  CurrCode      CDATA   #REQUIRED
  Amount        CDATA   #REQUIRED
  WalletID      CDATA   #IMPLIED>

FindPaymentInstrumentResponse Function is same both APIs.
---------------------------

(3)
--------------------------
StartPaymentConsumer Function:
->objectNameTobeCalledBack
<-CallBackFunction
<-CallBackLanguageList
 Comment:Call Back function depends on implementation. For example, The
 interfaces between COM and CORBA(IDL) are different because COM needs
 to set two parameters, class ID and interface ID, on the other hand,
 CORBA(IDL) needs to set single parameter, object name. I suggest
 we add the new element, CallBack in this element and the attributes
 (parameters) of CallBack element should be set in the implementation
  specific API such as COM and CORBA(IDL).

***How do you manage/encode the CallBackLanguageList? This (logical)
attribute does not depend on the actual implementation technique. Do you
have something like a InterfaceSchemePackagedContent in mind?***

**YK**
Yes. I think CallBackLanguageList is one of the method of the callback 
object.
**YK END**
--------------------------

(4)
-------------------------
ContinueProcess Function:
->ProcessType
 Comment:We need to distinct between "Inquiry" and "Payment", because
 we can not distinguish both transaction if the Inquiry Transaction has
  processed while the Payment Transaction, which has the same
 transaction id with the Inquiry Transaction, is in progress.  There is
 a problem when the Inquiry Transaction is occurred error for any
 reasons.

***Although I believe, that the Payment Bridge will be able to distinguish
between both cases by the analyse of the packaged scheme specific data -
e.g., in SET, I will apply your proposal, i.e. ProcessType (Payment|Inquiry)
'Payment'.***

--
<!ATTLIST ContinueProcess
...
ProcessType     NMTOKEN   #REQUIRED
... >

ProcessType can select "Inquiry" or "Payment".
--
**YK**
The Payment Bridge may be not able to analysis of the packaged data
when payment protocol message are encripted by the payment system.
**YK END**

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

(5)
-----------------------
RemovePaymentLog API:
(*This API exist in the SMILE document ONLY.*)
 Comment: This API needs to remove the payment related logs in the
 Payment Bridges.

***This function is subsumed by the AcessDataBase function.***

**YK**
Yes, but the AccessDataBase function should be dropped.
**YK END**

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

(6)
-------------------------
QuitPaymentInstrument API:
(*This API exist in the SMILE document ONLY.*)
 Comment:This API needs to quit the Payment Instrument(Existing
 Software), especially when the Existing Software is implement
as execution module(such that *.exe style).

CancelPayment API:
(*This API exist in the SMILE document ONLY.*)
 Comment:In some payment scheme, the Merchant server needs to notify
 the Payment server before sending an OfferResp message in order to
 make the Payment server ready for payment.
 If the Client cancels the transaction when the invoice(Content of
 Order Component) is displayed, the Merchant server needs to notify
 the Payment server that the payment is cancelled.  This is why the
 CancelPayment function is necessary in the Merchant payment bridge.

***Both functions seem to be subsumable by the ChangeProcessState function
because they define a final process state. I assume that
QuitPaymentInstrument is used to close a successful or successless
payment/inquiry. ChangeProcessState might even be used by the merchant to
cancel a transaction. The subsequent behaviour seems to be payment scheme
specific. I added possible support of this function by the Merchant to Table
2.***

**YK**
No. 
For QuitPaymentInstrument API,
we assume that the Consumer want to cancel or Error is occurred before
the IOTP Application Core calls the StartPaymentConsumer function to the
Payment Bridge.  Then, then the IOTP Application Core can not call the
ChangeProcessState to the Payment Bridge because IOTP Application Core
has not created the ConsumerPayId yet. So, this API is used by the
Consumer ONLY before the IOTP Application Core send the
StartPaymentConsumer message to the Payment Bridge.

For CancelPayment API,
this API is used by Merchant ONLY. The Merchant cannot use 
the ChangeProcessState API because there is no MerchantPayId element in 
the ChangeProcessState Function. 
On the other aspect, if the Payment Bridge receives the
ChangeProcessState function which is not included the ConsumerPayId or
is included new ConsumerPayId, the Payment Bridge return error message
to OAC.
**YK END**

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

(7)
----------------------
SetParentWindow API:
(*This API exist in the SMILE document ONLY.*)
 Comment:This function is passed the handle of the window of an IOTP
 Core Application to Payment Bridges. All windows of the Payment
 Bridges will be the children of the IOTP window.

***This seems to be very OS specific, although it enables seamless
integration of the Payment Bridge's user interface.***

**YK**
Yes, it's very OS specific, but some APIs have to be OS
dependent. Such APIs should be defined for each OS.
**YK END**
------------------------

(8)
-----------------------
ManagePaymentSoftware API: We dropped this.

***Deferred: How do you support the registration of new payment instruments
or their management - even in the absence of any payment. Does the user have
to access the native Existing Payment Software or can they use some kind of
invocation mechanism of the IOTP Application Core?***

**YK**
In fact, we cannot understand how to use this function because it
seems to make the IOTP core registers ProtocolId and BrandId, etc. to
Payment Bridges, but Payment Bridges must know which Brands and
Protocol can be handled.  Therefore, we use the Windows registry to
register payment bridge information such as object names or object
identifier especially to create payment bridge objects before calling
them.
**YK END**
------------------------

**
I applied all the agreed changes but will await your comments on error
reporting and failure processing. You will recognize that I scaled down the
discussion and rely extremely on the discussion of the function
specification. 
**
**YK**
O.K.
**YK END**

**
Another open topic from my point is the detailed processing
of resumption, particular synchronisation of both parties' points of view.
Maybe, I will drop this topic, completely
**
**YK**
Agreed.
**YK END**

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

>>>>> Tue, 28 Sep 1999 17:13:44 +0200,
	Werner Hans <[email-masked]> said:

> Hi Yoshiaki,
> 
> thanks for your remarks. You find my comments below.
> Further discussion is needed on the topics marked with "deferred".
> 
> Werner
> 
> -----Ursprüngliche Nachricht-----
> Von: Yoshiaki KAWATSURA [mailto:[email-masked]]Im Auftrag
> von Yoshiaki KAWATSURA
> Gesendet: Dienstag, 28. September 1999 07:54
> An: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Betreff: Re: iotpar101c.zip
> 
> Werner and Don,
> 
> This is a research document of the differences of the Payment APIs
> between Hans' and SMILE's.  We will send the document which describes
> the other topics, such as the Error Handling.
> 
> ----------------------
> Generic(1):
> Why have you drop the ContentSoftwareId throughout your document?  I
> think this ID should be set in the Payment Bridge because
> PackagedContents are generated behind the Payment Bridge.
> ***This attribute is returned by the Payment Bridge in the top level wrapper
> "IotpPaymentAPIResponse" (cf. Chapter 9).***
> 
> Generic(2):
> We should change from AmountPackagedContents to
> ProtocolAmountPackagedContents because this packaged contents is
> included in ProtocolAmount Component, not in Amount Component.
> 
> -> : There ONLY exists the Element in SMILE's API.
> <- : There ONLY exists the Element in Hans' API.
> ***Agreed. In the past I thought this name would be too long.***
> 
> FindAcceptedPayBrand Function:
> -> MerchantPayId
>  Comment:This ID should be set in this function.
> ***Agreed.***
> 
> -> MerchantOrgId
>  Comment:This needs when more than one Merchants exist in the IOTP
>  Merchant Server (and Mall).
> ***Deferred. Do we really need this item? Separation between merchants is
> possible by different wallet identifiers. At the client side, multiple
> consumers might use the same SET wallet. They as well as their data are
> distinguished by different wallet identifiers.
> MerchantOrgds might be encoded in these identifiers.***
> 
> -> MerchantData
>  Comment: This element is used to be set the Mall access keys which use
>  to get information in the Mall.
> 
> ***Deferred. Does the IOTP Payment Bridge resp. Existing Payment Software
> directly access the mall system? I believe, that this has to be done by the
> IOTP Application Core.***
> FindAcceptedPayBrandResponse Function:
> -> ContentSoftwareId
>  Comment: See above(Generic(2)).
> 
> FindAcceptedPaymentProtocol Function:
> ->MerchantData
>  Comment: See above description of MerchantData.
> 
> FindAcceptedPaymentProtocolResponse Function:
> ->ContentSoftwareId
>  Comment: See above(Generic(2)).
> 
> GetPaymentInitializationData Function:
> ->MerchantOrgId
>  Comment:This needs when some Merchants exist in the IOTP Merchant Server
>  (and Mall).
> 
> ->MerchantData
> Comment: See above description of MerchantData.
> 
> GetPaymentInitializationDataResponse Function:
> ->ContentSoftwareId
>  Comment: See above(Generic(2)).
> 
> FindPaymentInstrument and FindPaymentProtocol Function:
>  Comment:We merged FindPaymentInstrument and FindPaymentProtocol into
>  FindPaymentInstrument and dropped the FindPaymentProtocol API because
>  ProtocolBrandId depends on both Payment Brand and Payment Protocol and
>  it may invite unnecessary processes.
> 
> ***Design decision: The serialization by two calls was intended to decrease
> the possible huge complexity of finding the valid payment instruments at the
> client side. The first function should filter out IOTP Payment Bridges that
> do not support a brand for any payment protocol. E.g., having three Payment
> Bridges each for Mondex(-Mondex), Mastercard-SET, and Mastercard-SCCD. With
> your proposal, you have to issue three calls to each of the three Payment
> Bridges but only six calls to infer the supported brands and one further
> call for Mondex or two for the other schemes with the previous scheme. The
> situation might get even worse with more payment alternatives and more
> registered payment bridges. However, in situations with few Payment Bridges
> your design performs better.
> Note that the internal complexity of the first call is at the implementer's
> choice.
> Another design decision deals with your input parameter ProtocolId. By
> providing this as an input parameter, the API function must be called for
> each accepted payment protocol. E.g., one Payment Bridge supporting both
> Mastercard-SET and Mastercard-SCCD must be requested twice while one call
> suffices in the previous approach.
> The time of presentment of the ProtocolBrandId seems to be a pure design
> decision, due to the one to one relationship with the ProtocolId, if
> present. I deferred the presentment to GetPaymentInitializationData because
> such this ID might be stored in a chip card whose insertion should be
> deferred as long as possible for user friendliness.
> Other opinions?***
> 
>  Our FindPaymentInstrument function is as follows:
>  <!ELEMENT FindPaymentInstrument (BrandPackagedContent*,
>        ProtocolBrandPackagedContent*,ProtocolPackagedContent*,
>        ProtocolAmountPackagedContent*) >
>  <!ATTLIST FindPaymentInstrument
>   BrandId       CDATA   #REQUIRED
>   ProtocolId    CDATA   #REQUIRED
>   ProtocolBrandId       CDATA   #IMPLIED
>   PayDirection  (Debit|Credit)  #REQUIRED
>   CurrCodeType  NMTOKEN 'ISO4217-A'
>   CurrCode      CDATA   #REQUIRED
>   Amount        CDATA   #REQUIRED
>   WalletID      CDATA   #IMPLIED>
> 
> FindPaymentInstrumentResponse Function is same both APIs.
> 
> CheckPaymentPossibilityResponse Function:
> ->ProtocolAmountPackagedContent
> <-AmountPackagedContent
>  Comment: See above comment(Generic(2))
> 
> StartPaymentConsumer Function:
> ->objectNameTobeCalledBack
> <-CallBackFunction
> <-CallBackLanguageList
>  Comment:Call Back function depends on implementation. For example, The
>  interfaces between COM and CORBA(IDL) are different because COM needs
>  to set two parameters, class ID and interface ID, on the other hand,
>  CORBA(IDL) needs to set single parameter, object name. I suggest
>  we add the new element, CallBack in this element and the attributes
>  (parameters) of CallBack element should be set in the implementation
>   specific API such as COM and CORBA(IDL).
> 
> ***How do you manage/encode the CallBackLanguageList? This (logical)
> attribute does not depend on the actual implementation technique. Do you
> have something like a InterfaceSchemePackagedContent in mind?***
> 
> 
> <-DatabaseFunction
>  Comment:To unify and manage the database of Payment Bridge is actually
>  impossible though this is ideal, because we can not foresee the all
>  elements to use in the every payment bridges. I suggest this should be
>  dropped.
> 
> ***Maybe, I am not sure about this.***
> 
> StartPaymentConsumerResponse Function:
> ->ContentSoftwareId
>  Comment: See above(Generic(1)).
> 
> StartPaymentPaymentHandler Function:
> ->MerchantOrgId
>  Comment: This needs when we want to manage the payment fee for
>  each account of Merchant by Scheme Specific Payment Servers.
> 
> ->ObjectTobeCalledBack
> <-CallBackFunction
> <-CallBackLanguageList
> <-DatabaseFunction
>  Comment:See above comment in StartPaymentConsumer.
> 
> StartPAymentPaymentHandlerResponse Function:
> ->ContentSoftwareId
>  Comment: See above(Generic(2)).
> 
> ContinueProcess Function:
> ->ProcessType
>  Comment:We need to distinct between "Inquiry" and "Payment", because
>  we can not distinguish both transaction if the Inquiry Transaction has
>   processed while the Payment Transaction, which has the same
>  transaction id with the Inquiry Transaction, is in progress.  There is
>  a problem when the Inquiry Transaction is occurred error for any
>  reasons.
> 
> ***Although I believe, that the Payment Bridge will be able to distinguish
> between both cases by the analysis of the packaged scheme specific data -
> e.g., in SET, I will apply your proposal, i.e. ProcessType (Payment|Inquiry)
> 'Payment'.***
> 
> --
> <!ATTLIST ContinueProcess
> ...
> ProcessType     NMTOKEN   #REQUIRED
> ... >
> 
> ProcessType can select "Inquiry" or "Payment".
> --
> 
> ->ContentSoftwareId
>  Comment: See above(Generic(2)).
> 
> ResumePaymentConsumer Function:
> <-DatabaseFunction
>  Comment:See above comment in StartPaymentConsumer.
> 
> ResumePaymentConsumerResponse Function:
> ->ContentSoftwareId
>  Comment: See above(Generic(2)).
> 
> ResumePaymentPaymentHandler Function:
> <-DatabaseFunction
>  Comment:See above comment in StartPaymentConsumer.
> 
> 
> ExpandPaymentReceiptResponse Function:
> ->protocolBrandId
> ->ProtocolTransId
> 
>  Comment: ProtrocolBrandId, and ProtocolTransId which is the scheme
>  specific transaction ID such as SET LID_M, should be added because
>  these may be used to display. ProtocolTrandId may be used the
>  content of Payment Receipt Component.
> 
> -- See IOTP Spec 7.11(PayReceipt Component):
>   Typically the content of a Payment Receipt Component will contain data
>   which describes:
>       o internal reference numbers which identify the payment to
>         the payment system
> --
> 
> ***Agreed. When adding protocol related items, I suggest to add ProtocolId,
> too.***
> 
> InquireProcessStateResponse Function:
> ->ContentsSoftwareId
>  Comment: See above(Generic(2)).
> 
> ChangeProcessState Function:
> ->ProcessType
>  Comment: See above description in ContinueProcess.
> 
> RemovePaymentLog API:
> (*This API exist in the SMILE document ONLY.*)
>  Comment: This API needs to remove the payment related logs in the
>  Payment Bridges.
> 
> ***This function is subsumed by the AcessDataBase function.***
> 
> 
> PaymentInstrumentInquiry Function:
> ->xml:lang
>  Comment:This needs to apply the language code to Value of
>  unavailablePropertyList or/and the Property Description in
>  payInstProperties.
> 
> ***Agreed.***
> 
> QuitPaymentInstrument API:
> (*This API exist in the SMILE document ONLY.*)
>  Comment:This API needs to quit the Payment Instrument(Existing
>  Software), especially when the Existing Software is implement
> as execution module(such that *.exe style).
> 
> CancelPayment API:
> (*This API exist in the SMILE document ONLY.*)
>  Comment:In some payment scheme, the Merchant server needs to notify
>  the Payment server before sending an OfferResp message in order to
>  make the Payment server ready for payment.
>  If the Client cancels the transaction when the invoice(Content of
>  Order Component) is displayed, the Merchant server needs to notify
>  the Payment server that the payment is cancelled.  This is why the
>  CancelPayment function is necessary in the Merchant payment bridge.
> 
> ***Both functions seem to be subsumable by the ChangeProcessState function
> because they define a final process state. I assume that
> QuitPaymentInstrument is used to close a successful or successless
> payment/inquiry. ChangeProcessState might even be used by the merchant to
> cancel a transaction. The subsequent behaviour seems to be payment scheme
> specific. I added possible support of this function by the Merchant to Table
> 2.***
> 
> SetParentWindow API:
> (*This API exist in the SMILE document ONLY.*)
>  Comment:This function is passed the handle of the window of an IOTP
>  Core Application to Payment Bridges. All windows of the Payment
>  Bridges will be the children of the IOTP window.
> 
> ***This seems to be very OS specific, although it enables seamless
> integration of the Payment Bridge's user interface.***
> 
> ManagePaymentSoftware API: We dropped this.
> 
> ***Deferred: How do you support the registration of new payment instruments
> or their management - even in the absence of any payment. Does the user have
> to access the native Existing Payment Software or can they use some kind of
> invocation mechanism of the IOTP Application Core?***
> 
> CallBack API: We dropped this.
> ***Maybe. Progress indication has to be visualized by the Payment Bridge
> with the risk that each Payment Bridge uses its own mechanisms for
> visualization with the worst result the visual appearance differs with each
> payment scheme (brand).***
> 
> AccessDataBase API: We dropped this.
> ***Maybe.
> I applied all the agreed changes but will await your comments on error
> reporting and failure processing. You will recognize that I scaled down the
> discussion and rely extremely on the discussion of the function
> specification. Another open topic from my point is the detailed processing
> of resumption, particular synchronisation of both parties' points of view.
> Maybe, I will drop this topic, completely.***
> 
> 
> >>>>> Tue, 21 Sep 1999 18:29:11 -0400,
>         "Donald E. Eastlake 3rd" <[email-masked]> said:
> 
> >
> > OK.  It would be great if we could resolve any differences and get
> > this into Internet-Draft form so it can be posted by mid-October,
> > before the cutoff for the November IETF meeting.
> >
> > Thanks,
> > Donald
> >
> > From:  Yoshiaki KAWATSURA <[email-masked]>
> > Message-Id:  <[email-masked]>
> > To:  [email-masked], [email-masked]
> > Cc:  [email-masked]
> > Cc:  [email-masked]
> > In-Reply-To:  Your message of "Mon, 20 Sep 1999 23:35:10 -0400"
> >               <[email-masked]>
> > References:  <[email-masked]>
> > Date:  Tue, 21 Sep 1999 13:58:38 +0900 (JST)
> > Sender:  Yoshiaki KAWATSURA <[email-masked]>
> >
> > >Hans and Don,
> > >We are now developing the IOTP Payment API Specification to use the
> > >SMILE project.
> > >This is based on the Hans' (and my) IOTP Payment API version 1.01a, but
> > >several(many?) points of our specification has been changed or updated
> > >for fitting the current specification, efficiency and problem
> > >resolutions.
> > >
> > >We want to feedback our considerations to your draft and fit them.
> > >
> > >We will check the current IOTP Payment API and send the differences
> > >between them ASAP.
> > >
> > >Regards,
> > >----
> > >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]
> >
> 
> 
> -----------------------------------------------------------------------
> 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: Werner Hans <[email-masked]>
To: Yoshiaki KAWATSURA <[email-masked]>, [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
Cc: [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
Subject: AW: Payment API
Date: Tue, 28 Sep 1999 17:13:44 +0200
Importance: Normal
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Hi Yoshiaki,

thanks for your remarks. You find my comments below.
Further discussion is needed on the topics marked with "deferred".

Werner

-----Ursprüngliche Nachricht-----
Von: Yoshiaki KAWATSURA [mailto:[email-masked]]Im Auftrag
von Yoshiaki KAWATSURA
Gesendet: Dienstag, 28. September 1999 07:54
An: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Betreff: Re: iotpar101c.zip

Werner and Don,

This is a research document of the differences of the Payment APIs
between Hans' and SMILE's.  We will send the document which describes
the other topics, such as the Error Handling.

----------------------
Generic(1):
Why have you drop the ContentSoftwareId throughout your document?  I
think this ID should be set in the Payment Bridge because
PackagedContents are generated behind the Payment Bridge.
***This attribute is returned by the Payment Bridge in the top level wrapper
"IotpPaymentAPIResponse" (cf. Chapter 9).***

Generic(2):
We should change from AmountPackagedContents to
ProtocolAmountPackagedContents because this packaged contents is
included in ProtocolAmount Component, not in Amount Component.

-> : There ONLY exists the Element in SMILE's API.
<- : There ONLY exists the Element in Hans' API.
***Agreed. In the past I thought this name would be too long.***

FindAcceptedPayBrand Function:
-> MerchantPayId
 Comment:This ID should be set in this function.
***Agreed.***

-> MerchantOrgId
 Comment:This needs when more than one Merchants exist in the IOTP
 Merchant Server (and Mall).
***Deferred. Do we really need this item? Separation between merchants is
possible by different wallet identifiers. At the client side, multiple
consumers might use the same SET wallet. They as well as their data are
distinguished by different wallet identifiers.
MerchantOrgds might be encoded in these identifiers.***

-> MerchantData
 Comment: This element is used to be set the Mall access keys which use
 to get information in the Mall.

***Deferred. Does the IOTP Payment Bridge resp. Existing Payment Software
directly access the mall system? I believe, that this has to be done by the
IOTP Application Core.***
FindAcceptedPayBrandResponse Function:
-> ContentSoftwareId
 Comment: See above(Generic(2)).

FindAcceptedPaymentProtocol Function:
->MerchantData
 Comment: See above description of MerchantData.

FindAcceptedPaymentProtocolResponse Function:
->ContentSoftwareId
 Comment: See above(Generic(2)).

GetPaymentInitializationData Function:
->MerchantOrgId
 Comment:This needs when some Merchants exist in the IOTP Merchant Server
 (and Mall).

->MerchantData
Comment: See above description of MerchantData.

GetPaymentInitializationDataResponse Function:
->ContentSoftwareId
 Comment: See above(Generic(2)).

FindPaymentInstrument and FindPaymentProtocol Function:
 Comment:We merged FindPaymentInstrument and FindPaymentProtocol into
 FindPaymentInstrument and dropped the FindPaymentProtocol API because
 ProtocolBrandId depends on both Payment Brand and Payment Protocol and
 it may invite unnecessary processes.

***Design decision: The serialization by two calls was intended to decrease
the possible huge complexity of finding the valid payment instruments at the
client side. The first function should filter out IOTP Payment Bridges that
do not support a brand for any payment protocol. E.g., having three Payment
Bridges each for Mondex(-Mondex), Mastercard-SET, and Mastercard-SCCD. With
your proposal, you have to issue three calls to each of the three Payment
Bridges but only six calls to infer the supported brands and one further
call for Mondex or two for the other schemes with the previous scheme. The
situation might get even worse with more payment alternatives and more
registered payment bridges. However, in situations with few Payment Bridges
your design performs better.
Note that the internal complexity of the first call is at the implementer's
choice.
Another design decision deals with your input parameter ProtocolId. By
providing this as an input parameter, the API function must be called for
each accepted payment protocol. E.g., one Payment Bridge supporting both
Mastercard-SET and Mastercard-SCCD must be requested twice while one call
suffices in the previous approach.
The time of presentment of the ProtocolBrandId seems to be a pure design
decision, due to the one to one relationship with the ProtocolId, if
present. I deferred the presentment to GetPaymentInitializationData because
such this ID might be stored in a chip card whose insertion should be
deferred as long as possible for user friendliness.
Other opinions?***

 Our FindPaymentInstrument function is as follows:
 <!ELEMENT FindPaymentInstrument (BrandPackagedContent*,
       ProtocolBrandPackagedContent*,ProtocolPackagedContent*,
       ProtocolAmountPackagedContent*) >
 <!ATTLIST FindPaymentInstrument
  BrandId       CDATA   #REQUIRED
  ProtocolId    CDATA   #REQUIRED
  ProtocolBrandId       CDATA   #IMPLIED
  PayDirection  (Debit|Credit)  #REQUIRED
  CurrCodeType  NMTOKEN 'ISO4217-A'
  CurrCode      CDATA   #REQUIRED
  Amount        CDATA   #REQUIRED
  WalletID      CDATA   #IMPLIED>

FindPaymentInstrumentResponse Function is same both APIs.

CheckPaymentPossibilityResponse Function:
->ProtocolAmountPackagedContent
<-AmountPackagedContent
 Comment: See above comment(Generic(2))

StartPaymentConsumer Function:
->objectNameTobeCalledBack
<-CallBackFunction
<-CallBackLanguageList
 Comment:Call Back function depends on implementation. For example, The
 interfaces between COM and CORBA(IDL) are different because COM needs
 to set two parameters, class ID and interface ID, on the other hand,
 CORBA(IDL) needs to set single parameter, object name. I suggest
 we add the new element, CallBack in this element and the attributes
 (parameters) of CallBack element should be set in the implementation
  specific API such as COM and CORBA(IDL).

***How do you manage/encode the CallBackLanguageList? This (logical)
attribute does not depend on the actual implementation technique. Do you
have something like a InterfaceSchemePackagedContent in mind?***

<-DatabaseFunction
 Comment:To unify and manage the database of Payment Bridge is actually
 impossible though this is ideal, because we can not foresee the all
 elements to use in the every payment bridges. I suggest this should be
 dropped.

***Maybe, I am not sure about this.***

StartPaymentConsumerResponse Function:
->ContentSoftwareId
 Comment: See above(Generic(1)).

StartPaymentPaymentHandler Function:
->MerchantOrgId
 Comment: This needs when we want to manage the payment fee for
 each account of Merchant by Scheme Specific Payment Servers.

->ObjectTobeCalledBack
<-CallBackFunction
<-CallBackLanguageList
<-DatabaseFunction
 Comment:See above comment in StartPaymentConsumer.

StartPAymentPaymentHandlerResponse Function:
->ContentSoftwareId
 Comment: See above(Generic(2)).

ContinueProcess Function:
->ProcessType
 Comment:We need to distinct between "Inquiry" and "Payment", because
 we can not distinguish both transaction if the Inquiry Transaction has
  processed while the Payment Transaction, which has the same
 transaction id with the Inquiry Transaction, is in progress.  There is
 a problem when the Inquiry Transaction is occurred error for any
 reasons.

***Although I believe, that the Payment Bridge will be able to distinguish
between both cases by the analysis of the packaged scheme specific data -
e.g., in SET, I will apply your proposal, i.e. ProcessType (Payment|Inquiry)
'Payment'.***

--
<!ATTLIST ContinueProcess
...
ProcessType     NMTOKEN   #REQUIRED
... >

ProcessType can select "Inquiry" or "Payment".
--

->ContentSoftwareId
 Comment: See above(Generic(2)).

ResumePaymentConsumer Function:
<-DatabaseFunction
 Comment:See above comment in StartPaymentConsumer.

ResumePaymentConsumerResponse Function:
->ContentSoftwareId
 Comment: See above(Generic(2)).

ResumePaymentPaymentHandler Function:
<-DatabaseFunction
 Comment:See above comment in StartPaymentConsumer.

ExpandPaymentReceiptResponse Function:
->protocolBrandId
->ProtocolTransId

 Comment: ProtrocolBrandId, and ProtocolTransId which is the scheme
 specific transaction ID such as SET LID_M, should be added because
 these may be used to display. ProtocolTrandId may be used the
 content of Payment Receipt Component.

-- See IOTP Spec 7.11(PayReceipt Component):
  Typically the content of a Payment Receipt Component will contain data
  which describes:
      o internal reference numbers which identify the payment to
        the payment system
--

***Agreed. When adding protocol related items, I suggest to add ProtocolId,
too.***

InquireProcessStateResponse Function:
->ContentsSoftwareId
 Comment: See above(Generic(2)).

ChangeProcessState Function:
->ProcessType
 Comment: See above description in ContinueProcess.

RemovePaymentLog API:
(*This API exist in the SMILE document ONLY.*)
 Comment: This API needs to remove the payment related logs in the
 Payment Bridges.

***This function is subsumed by the AcessDataBase function.***

PaymentInstrumentInquiry Function:
->xml:lang
 Comment:This needs to apply the language code to Value of
 unavailablePropertyList or/and the Property Description in
 payInstProperties.

***Agreed.***

QuitPaymentInstrument API:
(*This API exist in the SMILE document ONLY.*)
 Comment:This API needs to quit the Payment Instrument(Existing
 Software), especially when the Existing Software is implement
as execution module(such that *.exe style).

CancelPayment API:
(*This API exist in the SMILE document ONLY.*)
 Comment:In some payment scheme, the Merchant server needs to notify
 the Payment server before sending an OfferResp message in order to
 make the Payment server ready for payment.
 If the Client cancels the transaction when the invoice(Content of
 Order Component) is displayed, the Merchant server needs to notify
 the Payment server that the payment is cancelled.  This is why the
 CancelPayment function is necessary in the Merchant payment bridge.

***Both functions seem to be subsumable by the ChangeProcessState function
because they define a final process state. I assume that
QuitPaymentInstrument is used to close a successful or successless
payment/inquiry. ChangeProcessState might even be used by the merchant to
cancel a transaction. The subsequent behaviour seems to be payment scheme
specific. I added possible support of this function by the Merchant to Table
2.***

SetParentWindow API:
(*This API exist in the SMILE document ONLY.*)
 Comment:This function is passed the handle of the window of an IOTP
 Core Application to Payment Bridges. All windows of the Payment
 Bridges will be the children of the IOTP window.

***This seems to be very OS specific, although it enables seamless
integration of the Payment Bridge's user interface.***

ManagePaymentSoftware API: We dropped this.

***Deferred: How do you support the registration of new payment instruments
or their management - even in the absence of any payment. Does the user have
to access the native Existing Payment Software or can they use some kind of
invocation mechanism of the IOTP Application Core?***

CallBack API: We dropped this.
***Maybe. Progress indication has to be visualized by the Payment Bridge
with the risk that each Payment Bridge uses its own mechanisms for
visualization with the worst result the visual appearance differs with each
payment scheme (brand).***

AccessDataBase API: We dropped this.
***Maybe.
I applied all the agreed changes but will await your comments on error
reporting and failure processing. You will recognize that I scaled down the
discussion and rely extremely on the discussion of the function
specification. Another open topic from my point is the detailed processing
of resumption, particular synchronisation of both parties' points of view.
Maybe, I will drop this topic, completely.***

>>>>> Tue, 21 Sep 1999 18:29:11 -0400,
        "Donald E. Eastlake 3rd" <[email-masked]> said:

>
> OK.  It would be great if we could resolve any differences and get
> this into Internet-Draft form so it can be posted by mid-October,
> before the cutoff for the November IETF meeting.
>
> Thanks,
> Donald
>
> From:  Yoshiaki KAWATSURA <[email-masked]>
> Message-Id:  <[email-masked]>
> To:  [email-masked], [email-masked]
> Cc:  [email-masked]
> Cc:  [email-masked]
> In-Reply-To:  Your message of "Mon, 20 Sep 1999 23:35:10 -0400"
>               <[email-masked]>
> References:  <[email-masked]>
> Date:  Tue, 21 Sep 1999 13:58:38 +0900 (JST)
> Sender:  Yoshiaki KAWATSURA <[email-masked]>
>
> >Hans and Don,
> >We are now developing the IOTP Payment API Specification to use the
> >SMILE project.
> >This is based on the Hans' (and my) IOTP Payment API version 1.01a, but
> >several(many?) points of our specification has been changed or updated
> >for fitting the current specification, efficiency and problem
> >resolutions.
> >
> >We want to feedback our considerations to your draft and fit them.
> >
> >We will check the current IOTP Payment API and send the differences
> >between them ASAP.
> >
> >Regards,
> >----
> >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]
>

-----------------------------------------------------------------------
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]
Cc: [email-masked]
Subject: Re: iotpar101c.zip 
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Tue, 28 Sep 1999 14:53:42 +0900 (JST)
Lines: 268
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Werner and Don,

This is a research document of the differences of the Payment APIs
between Hans' and SMILE's.  We will send the document which describes
the other topics, such as the Error Handling.

----------------------
Generic(1):
Why have you drop the ContentSoftwareId throughout your document?  I
think this ID should be set in the Payment Bridge because
PackagedContents are generated behind the Payment Bridge.

Generic(2):
We should change from AmountPackagedContents to
ProtocolAmountPackagedContents because this packaged contents is
included in ProtocolAmount Component, not in Amount Component.

-> : There ONLY exists the Element in SMILE's API.
<- : There ONLY exists the Element in Hans' API.

FindAcceptedPayBrand Function:
-> MerchantPayId
 Comment:This ID should be set in this function.

-> MerchantOrgId
 Comment:This needs when more than one Merchants exist in the IOTP
 Merchant Server (and Mall).

-> MerchantData
 Comment: This element is used to be set the Mall access keys which use 
 to get information in the Mall.

FindAcceptedPayBrandResponse Function:
-> ContentSoftwareId
 Comment: See above(Generic(2)).

FindAcceptedPaymentProtocol Function:
->MerchantData
 Comment: See above description of MerchantData.

FindAcceptedPaymentProtocolResponse Function:
->ContentSoftwareId
 Comment: See above(Generic(2)).

GetPaymentInitializationData Function:
->MerchantOrgId
 Comment:This needs when some Merchants exist in the IOTP Merchant Server
 (and Mall).

->MerchantData
Comment: See above description of MerchantData.

GetPaymentInitializationDataResponse Function:
->ContentSoftwareId
 Comment: See above(Generic(2)).

FindPaymentInstrument and FindPaymentProtocol Function:
 Comment:We merged FindPaymentInstrument and FindPaymentProtocol into
 FindPaymentInstrument and dropped the FindPaymentProtocol API because
 ProtocolBrandId depends on both Payment Brand and Payment Protocol and
 it may invite unnecessary processes.

 Our FindPaymentInstrument function is as follows:
 <!ELEMENT FindPaymentInstrument (BrandPackagedContent*,
       ProtocolBrandPackagedContent*,ProtocolPackagedContent*,
       ProtocolAmountPackagedContent*) >
 <!ATTLIST FindPaymentInstrument
  BrandId	CDATA	#REQUIRED
  ProtocolId	CDATA	#REQUIRED
  ProtocolBrandId	CDATA	#IMPLIED
  PayDirection	(Debit|Credit)	#REQUIRED
  CurrCodeType	NMTOKEN	'ISO4217-A'
  CurrCode	CDATA	#REQUIRED
  Amount	CDATA	#REQUIRED
  WalletID	CDATA	#IMPLIED>

FindPaymentInstrumentResponse Function is same both APIs.

CheckPaymentPossibilityResponse Function:
->ProtocolAmountPackagedContent
<-AmountPackagedContent
 Comment: See above comment(Generic(2))

StartPaymentConsumer Function:
->objectNameTobeCalledBack
<-CallBackFunction
<-CallBackLanguageList
 Comment:Call Back function depends on implementation. For example, The
 interfaces between COM and CORBA(IDL) are different because COM needs
 to set two parameters, class ID and interface ID, on the other hand,
 CORBA(IDL) needs to set single parameter, object name. I suggest
 we add the new element, CallBack in this element and the attributes
 (parameters) of CallBack element should be set in the implementation
  specific API such as COM and CORBA(IDL).

<-DatabaseFunction
 Comment:To unify and manage the database of Payment Bridge is actually
 impossible though this is ideal, because we can not foresee the all
 elements to use in the every payment bridges. I suggest this should be
 dropped.

StartPaymentConsumerResponse Function:
->ContentSoftwareId
 Comment: See above(Generic(1)).

StartPaymentPaymentHandler Function:
->MerchantOrgId
 Comment: This needs when we want to manage the payment fee for
 each account of Merchant by Scheme Specific Payment Servers.

->ObjectTobeCalledBack
<-CallBackFunction
<-CallBackLanguageList
<-DatabaseFunction
 Comment:See above comment in StartPaymentConsumer.

StartPAymentPaymentHandlerResponse Function:
->ContentSoftwareId
 Comment: See above(Generic(2)).

ContinueProcess Function:
->ProcessType
 Comment:We need to distinct between "Inquiry" and "Payment", because
 we can not distinguish both transaction if the Inquiry Transaction has
  processed while the Payment Transaction, which has the same
 transaction id with the Inquiry Transaction, is in progress.  There is
 a problem when the Inquiry Transaction is occurred error for any
 reasons.

--
<!ATTLIST ContinueProcess
...
ProcessType	NMTOKEN   #REQUIRED
... >

ProcessType can select "Inquiry" or "Payment".
--

->ContentSoftwareId
 Comment: See above(Generic(2)).

ResumePaymentConsumer Function:
<-DatabaseFunction
 Comment:See above comment in StartPaymentConsumer.

ResumePaymentConsumerResponse Function:
->ContentSoftwareId
 Comment: See above(Generic(2)).

ResumePaymentPaymentHandler Function:
<-DatabaseFunction
 Comment:See above comment in StartPaymentConsumer.

ExpandPaymentReceiptResponse Function:
->protocolBrandId
->ProtocolTransId

 Comment: ProtrocolBrandId, and ProtocolTransId which is the scheme
 specific transaction ID such as SET LID_M, should be added because
 these may be used to display. ProtocolTrandId may be used the
 content of Payment Receipt Component.

-- See IOTP Spec 7.11(PayReceipt Component):
  Typically the content of a Payment Receipt Component will contain data
  which describes:
      o internal reference numbers which identify the payment to
        the payment system
--

InquireProcessStateResponse Function:
->ContentsSoftwareId
 Comment: See above(Generic(2)).

ChangeProcessState Function:
->ProcessType
 Comment: See above description in ContinueProcess.

RemovePaymentLog API:
(*This API exist in the SMILE document ONLY.*)
 Comment: This API needs to remove the payment related logs in the
 Payment Bridges.

PaymentInstrumentInquiry Function:
->xml:lang
 Comment:This needs to apply the language code to Value of
 unavailablePropertyList or/and the Property Description in
 payInstProperties.

QuitPaymentInstrument API:
(*This API exist in the SMILE document ONLY.*)
 Comment:This API needs to quit the Payment Instrument(Existing
 Software), especially when the Existing Software is implement 
as execution module(such that *.exe style).

CancelPayment API:
(*This API exist in the SMILE document ONLY.*)
 Comment:In some payment scheme, the Merchant server needs to notify
 the Payment server before sending an OfferResp message in order to
 make the Payment server ready for payment.
 If the Client cancels the transaction when the invoice(Content of
 Order Component) is displayed, the Merchant server needs to notify
 the Payment server that the payment is cancelled.  This is why the
 CancelPayment function is necessary in the Merchant payment bridge.

SetParentWindow API:
(*This API exist in the SMILE document ONLY.*)
 Comment:This function is passed the handle of the window of an IOTP
 Core Application to Payment Bridges. All windows of the Payment
 Bridges will be the children of the IOTP window.

ManagePaymentSoftware API: We dropped this.
CallBack API: We dropped this.
AccessDataBase API: We dropped this.

>>>>> Tue, 21 Sep 1999 18:29:11 -0400,
	"Donald E. Eastlake 3rd" <[email-masked]> said:

> 
> OK.  It would be great if we could resolve any differences and get
> this into Internet-Draft form so it can be posted by mid-October,
> before the cutoff for the November IETF meeting.
> 
> Thanks,
> Donald
> 
> From:  Yoshiaki KAWATSURA <[email-masked]>
> Message-Id:  <[email-masked]>
> To:  [email-masked], [email-masked]
> Cc:  [email-masked]
> Cc:  [email-masked]
> In-Reply-To:  Your message of "Mon, 20 Sep 1999 23:35:10 -0400"
> 	     	<[email-masked]>
> References:  <[email-masked]>
> Date:  Tue, 21 Sep 1999 13:58:38 +0900 (JST)
> Sender:  Yoshiaki KAWATSURA <[email-masked]>
> 
> >Hans and Don,
> >We are now developing the IOTP Payment API Specification to use the
> >SMILE project.
> >This is based on the Hans' (and my) IOTP Payment API version 1.01a, but
> >several(many?) points of our specification has been changed or updated
> >for fitting the current specification, efficiency and problem
> >resolutions.
> >
> >We want to feedback our considerations to your draft and fit them.
> >
> >We will check the current IOTP Payment API and send the differences 
> >between them ASAP.
> >
> >Regards,
> >----
> >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]
> 
-----------------------------------------------------------------------
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: IETF-Announce: ;
Cc: [email-masked]
From: The IESG <[email-masked]>
SUBJECT: Last Call: Internet Open Trading Protocol - IOTP Version 1.0 to Informational
Reply-to: [email-masked]
Date: Mon, 27 Sep 1999 16:01:45 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

The IESG has received a request from the Internet Open Trading Protocol
Working Group to consider the following documents for publication as
Informational RFCs:

o Internet Open Trading Protocol - IOTP Version 1.0
	<draft-ietf-trade-iotp-v1.0-protocol-06.txt>

o Digital Signatures for the Internet Open Trading Protocol 
	<draft-ietf-trade-iotp-v1.0-dsig-03.txt>

o Digest Values for DOM (DOMHASH)
	<draft-ietf-trade-hiroshi-dom-hash-03.txt> 

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by October 11, 1999.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-protocol-06.txt
http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-dsig-03.txt
http://www.ietf.org/internet-drafts/draft-ietf-trade-hiroshi-dom-hash-03.txt
-----------------------------------------------------------------------
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: "'Wong Ka Cheong'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: question about iotp-v1.0-DTD
Date: Mon, 27 Sep 1999 07:57:01 -0700
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

You ask ...

"In the "Payment" u say "BrandListRef" is required. If there is
no BrandList component, then how can we refer it?"

The TPO Block can occur in the first message of several transactions, for
example the Authentication Transaction. In this case the Brandlist is not
required.

However the BrandList is *always* required if the transaction involves a
payment as if there is no Brand List you can't decide which brand to use.

If a payment is involved and there is no BrandList, then there is an error
which should be reported. This is why it says that BrandListRef is
"required" in a payment.

David

-----Original Message-----
From: Wong Ka Cheong [mailto:[email-masked]]
Sent: Monday, September 27, 1999 5:00 AM
To: [email-masked]
Cc: [email-masked]
Subject: question about iotp-v1.0-DTD

Hi,
I have a question about DTD. In the internet-draft u say BrandList is
zero or more:
<!-- TRADING PROTOCOL OPTIONS BLOCK -->
<!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, Org* ) >
<!ATTLIST TpoBlk
 ID                 ID      #REQUIRED >

However, in the "Payment" u say "BrandListRef" is required. If there is
no BrandList component, then how can we refer it?

Thanks

-----------------------------------------------------------------------
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: Mon, 27 Sep 1999 20:00:06 +0800 (HKT)
From: Wong Ka Cheong <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: question about iotp-v1.0-DTD
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Hi,
I have a question about DTD. In the internet-draft u say BrandList is
zero or more:
<!-- TRADING PROTOCOL OPTIONS BLOCK -->
<!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, Org* ) >
<!ATTLIST TpoBlk
 ID                 ID      #REQUIRED >

However, in the "Payment" u say "BrandListRef" is required. If there is
no BrandList component, then how can we refer it?

Thanks

-----------------------------------------------------------------------
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: DJ <[email-masked]>, "Winchel 'Todd' Vincent, III" <[email-masked]>, Andreas Siglreithmayr <[email-masked]>, "W3c-Ietf-Xmldsig (E-mail)" <[email-masked]>
Cc: "IETF Trade (E-mail)" <[email-masked]>
Subject: RE: How to sign several resources (XML and XSL)?
Date: Thu, 23 Sep 1999 20:53:14 -0700
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

... and even perhaps a digitally signed copy of the PC and operating system
on which it was run ?

Seriously though, if it comes to a court case I believe it's all a question
of being able to demonstrate, beyond a reasonable doubt, that the facts are
true which is a subjective opinion. I therefore thing that you probably
don't need signed copies of:
- the PC
- the operating system
- the browser and, I would content
- the style sheet ...

... as long as the style sheet was widely and publically available from
several sources and it was generally accepted as being a reasonable
presentation of the information in the XML document.

... but then I'm not a lawyer.

David

-----Original Message-----
From: DJ [mailto:[email-masked]]
Sent: Thursday, September 23, 1999 9:21 AM
To: David Burdett; Winchel 'Todd' Vincent, III; Andreas Siglreithmayr;
W3c-Ietf-Xmldsig (E-mail)
Cc: IETF Trade (E-mail)
Subject: RE: How to sign several resources (XML and XSL)?

But to present legally binding evidence at a future date you may need to
present the signed XML, the presentation (signed XSL) and perhaps even
the application that displayed it (a signed copy of Netscape??? or perhaps
the UWI.com forms browser?)

DJ

At 08:36 PM 9/22/99 -0700, David Burdett wrote:
>... otherwise how do you know the context for the XML data?
>
>You know the context because interpretation of the XML data is being done
by
>software from a presumably reliable source to do the interpretation that is
>built according to a specification that describes the semantics of data 
>
>... I now feel that we're getting very close to the topic of "trusted"
>applications  and I'm not sure we want to go there ...
>
>David
>
>-----Original Message-----
>From: DJ [mailto:[email-masked]]
>Sent: Wednesday, September 22, 1999 3:49 PM
>To: David Burdett; Winchel 'Todd' Vincent, III; Andreas Siglreithmayr;
>W3c-Ietf-Xmldsig (E-mail)
>Cc: IETF Trade (E-mail)
>Subject: RE: How to sign several resources (XML and XSL)?
>
>
>
>UWI.com has an XML implementation that signs the "presentation" (eg. the
>XSL)
>as well as the XML.  In their view, it is critically important to sign
>both, otherwise
>how do you know the context for the XML data?  
>
>dj
>
>At 02:45 PM 9/22/99 -0700, David Burdett wrote:
>>Following on from this I'm wondering what people's views are on signing an
>>XML document that is primarily an XML representation of a data structure
>>that is defined in a specification that is widely and publically
available.
>>
>>The XML document, in it's native form is readable but not easily
>>understandable. A style sheet would make the document easier to understand
>>but is not required since the semantics of the document are defined in the
>>specification. However could use of a stylesheet then be construed as
>>altering the meaning of the XML document as far as a recipient is
>concerned.
>>
>>I ask since this is what IOTP effectively does, it signs several parts of
a
>>data structure (represented in XML) and then creates new data structures
>>from the orginal that are also digitally signed and, using additional
>>"endorsing" signatures, "binds" the new document back to the original.
>>
>>David
>>
>>-----Original Message-----
>>From: Winchel 'Todd' Vincent, III [mailto:[email-masked]]
>>Sent: Wednesday, September 22, 1999 1:43 AM
>>To: Andreas Siglreithmayr; W3c-Ietf-Xmldsig (E-mail)
>>Subject: Re: How to sign several resources (XML and XSL)?
>>
>>
>>>
>>> I think that if someone signs an XML-document, s/he would also have
>>>to sign the corresponding XSL file.
>>
>>Andreas:
>>
>>Other people on this list hold the very same opinion.  Indeed, as an
>>American lawyer, I believe there are very good legal reasons why *not*
>>signing the stylesheet might just get and XML document thrown out of court
>>if/when it were introduced into evidence.  Such a result would, of course,
>>make the technology much less valuable.
>>
>>Thank you for your input.  I think having someone with a new and fresh
>>perspective helps to shed light on the simplicity and logic of the notion.
>>I wish others would see it so clearly.
>>
>>Todd
>>
>-----------------------------------------------------------------------
>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]

To: [email-masked]
Cc: [email-masked]
Subject: Re: digital signature comments
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Fri, 24 Sep 1999 12:56:13 +0900 (JST)
Lines: 87
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Hello Greg,
Thank you for your feedback.
My comments below.

>>>>> Tue, 21 Sep 1999 13:56:07 -0700,
	Greg Whitehead <[email-masked]> said:

>4.3.1 Signature
>---------------
>
>>From the text:
>
>>  The process for generating the signed value is a multi-step process,
>>  involving a canonicalization algorithm, a digest algorithm, and a
>>  signature algorithm.
>>
>>  First, the Manifest is canonicalized with an algorithm specified
>>  within the Algorithm element of the Manifest. The canonicalized form
>>  removes any inconsistencies in white space introduced by XML parsing
>>  engines.
>>
>>  This canonicalized form is then converted into a digest form which
>>  uniquely identifies the canonicalized document. Any slight
>>  modification in the original document will result in a very different
>>  digest value.
>
>This suggests that a canonicalization algorithm must be specified in the
>Manifiest (section 4.3.2), yet the Algorithm type (section 4.3.3) provides
>no way to do that. 
>
>It appears that canonicalization has been folded into the digest algorithm,
>which makes sense since the two are sometimes inseparable (DOMHASH), but
>this should be clarified.
>
>If DOMHASH is, in fact, meant to include canonicalization, it would be good
>if its spec [2] provided specific details (along with test cases and their
>respective digest values).

I understand.
If we want to use the canonicalization algorithm, which can not be hashed
 by itself, we need to use Parameter element as follows:

<Algorithm name='urn:fips:sha1' type='digest' ID='P.3'>
</Algorithm>
<Algorithm name='urn:w3c:C14N' type='digest' ID='P.4'>
 <Parameter type="AlgorithmRef">P.3</Parameter>
</Algorithm>

Of course, I know C14N is not digest algorithm, but if we revise that
'canonicalization' is added as the type parameter, we have to revise
the IOTP Specification also(though this is minor change...).
As results, I do not change until other people appeals to want to do it.

>4.4.2 IssuerAndSerialNumber
>---------------------------
>
>As used in CMS, IssuerAndSerialNumber is a binary structure lifted directly
>from the certificate.  In IOTP-DSIG, the issuer name (X.500 DN) and serial
>number (ASN.1 Integer) are each represented as strings.  Unfortunately,
>converting DNs to strings is non-trivial (internally, DNs are binary
>structures that use ASN.1 OIDs to identify attributes and determine the
>encoding of their values).
>
>If IssuerNameAndSerialNumber is simply meant to serve as an opaque
>identifier, to name Certificate elements included in IOTPSignatures, then
>there is no problem: any scheme that produces unique identifiers will work
>(why not just use an IDREF in that case?)

>If, however, it is meant to serve as a key for locating certificates in an
>external repository, such as an LDAP directory, then the format needs to be
>more precisely specified.  I would suggest rfc2253 (LDAPv3: UTF-8 String
>Representation of Distinguished Names) as a starting point:
>
>	http://www.ietf.org/rfc/rfc2253.txt
>

I assume the first case but the second case is very interested for me.
I suggest this issue should be discussed in the xml-dsig WG.

Thanks,
----
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: Roger Collins <[email-masked]>
To: "W3c-Ietf-Xmldsig (E-mail)" <[email-masked]>
Cc: "IETF Trade (E-mail)" <[email-masked]>
Subject: RE: How to sign several resources (XML and XSL)?
Date: Thu, 23 Sep 1999 13:16:30 -0400
Importance: Normal
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Following that line of reasoning would have us include a signed copy of the
whole operating environment including the operating system and all running
processes.  A reasonable boundary for the things that should be signed by a
party are the things that the party has control over (the XML and XSL) under
normal circumstances (i.e., when you are not being "hacked" by the party).

Roger

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of DJ
Sent: Thursday, September 23, 1999 12:21 PM
To: David Burdett; Winchel 'Todd' Vincent, III; Andreas Siglreithmayr;
W3c-Ietf-Xmldsig (E-mail)
Cc: IETF Trade (E-mail)
Subject: RE: How to sign several resources (XML and XSL)?

But to present legally binding evidence at a future date you may need to
present the signed XML, the presentation (signed XSL) and perhaps even
the application that displayed it (a signed copy of Netscape??? or perhaps
the UWI.com forms browser?)

DJ

At 08:36 PM 9/22/99 -0700, David Burdett wrote:
>... otherwise how do you know the context for the XML data?
>
>You know the context because interpretation of the XML data is being done
by
>software from a presumably reliable source to do the interpretation that is
>built according to a specification that describes the semantics of data
>
>... I now feel that we're getting very close to the topic of "trusted"
>applications  and I'm not sure we want to go there ...
>
>David
>
>-----Original Message-----
>From: DJ [mailto:[email-masked]]
>Sent: Wednesday, September 22, 1999 3:49 PM
>To: David Burdett; Winchel 'Todd' Vincent, III; Andreas Siglreithmayr;
>W3c-Ietf-Xmldsig (E-mail)
>Cc: IETF Trade (E-mail)
>Subject: RE: How to sign several resources (XML and XSL)?
>
>
>
>UWI.com has an XML implementation that signs the "presentation" (eg. the
>XSL)
>as well as the XML.  In their view, it is critically important to sign
>both, otherwise
>how do you know the context for the XML data?
>
>dj
>
>At 02:45 PM 9/22/99 -0700, David Burdett wrote:
>>Following on from this I'm wondering what people's views are on signing an
>>XML document that is primarily an XML representation of a data structure
>>that is defined in a specification that is widely and publically
available.
>>
>>The XML document, in it's native form is readable but not easily
>>understandable. A style sheet would make the document easier to understand
>>but is not required since the semantics of the document are defined in the
>>specification. However could use of a stylesheet then be construed as
>>altering the meaning of the XML document as far as a recipient is
>concerned.
>>
>>I ask since this is what IOTP effectively does, it signs several parts of
a
>>data structure (represented in XML) and then creates new data structures
>>from the orginal that are also digitally signed and, using additional
>>"endorsing" signatures, "binds" the new document back to the original.
>>
>>David
>>
>>-----Original Message-----
>>From: Winchel 'Todd' Vincent, III [mailto:[email-masked]]
>>Sent: Wednesday, September 22, 1999 1:43 AM
>>To: Andreas Siglreithmayr; W3c-Ietf-Xmldsig (E-mail)
>>Subject: Re: How to sign several resources (XML and XSL)?
>>
>>
>>>
>>> I think that if someone signs an XML-document, s/he would also have
>>>to sign the corresponding XSL file.
>>
>>Andreas:
>>
>>Other people on this list hold the very same opinion.  Indeed, as an
>>American lawyer, I believe there are very good legal reasons why *not*
>>signing the stylesheet might just get and XML document thrown out of court
>>if/when it were introduced into evidence.  Such a result would, of course,
>>make the technology much less valuable.
>>
>>Thank you for your input.  I think having someone with a new and fresh
>>perspective helps to shed light on the simplicity and logic of the notion.
>>I wish others would see it so clearly.
>>
>>Todd
>>
>-----------------------------------------------------------------------
>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: Ed Simon <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: Re[2]: How to sign several resources (XML and XSL)? 
Date: Thu, 23 Sep 1999 13:37:50 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Just as signing an entity like "&bank;" may not be sufficient
when the user actually sees "Bank of Bells Corners", signing
a link to stylesheet may also be insufficient.

Though an XML instance can specify one or more stylesheets
(using the Recommendation Rich links to), that does not
mean applications will actually
use one of those stylesheets when formatting the
data for a user.  For example, it is predicted that PCs will
make up less than half of the devices connect to the Internet
by 2002 (others would include handheld devices like PalmPilots
and cell-phones (with mini screens like those on modern
video cameras).  To accomodate the wide range of output devices,
vendors are looking at dynamically selecting the stylesheet
based on the output device.  So, if you want to trade stocks
using a cell-phone's mini screen, the stock-trade-to-cell-phone
stylsheet would be used.  An application may then want to sign
that stylesheet used for that transaction rather than one of the
ones specified in the XML instance.

Anyway, I like the way Rich makes the point about the
"level of trust" being up to the application.  The XML
Signature spec may make it possible to sign things beyond
the core data but doesn't require one do so.  Applications
should sign whatever they believe is necessary.  For
legally-binding signatures, guiding principles might be
"beyond a reasonable doubt" or
"on the balance of probabilities".

Ed
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: September 23, 1999 12:42 PM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re[2]: How to sign several resources (XML and XSL)? 

XSL is an XML format, so we haven't excluded signature of XSL, have we?
Also,
I'm aware of the W3C recommendation at

http://www.w3.org/TR/xml-stylesheet/

that ties a stylesheet to an XML document.  However, a processing
instruction is
used for this purpose, and we have proposed elimination of PI from our c14n.
I
believe this needs to be revisited.  Applications will definitely want the
option to locate and sign an associated stylesheet.  IMO, It is not for us
to
judge whether or not this makes sense to the application just because our
committee(s) can't guarantee a trusted browser.  The level of trust required
is
up to the application (they may restrict their application to specific
signed
and trusted browsers, they may certify their application for specific common
browsers, etc.)

Rich

____________________Reply Separator____________________
Subject:    Re: How to sign several resources (XML and XSL)? 
Author: "Milton M. Anderson" <[email-masked]>
Date:       9/23/99 7:44 AM

-----Original Message-----
From: David Burdett <[email-masked]>
Date: Wednesday, September 22, 1999 11:39 PM
Subject: RE: How to sign several resources (XML and XSL)?

>... otherwise how do you know the context for the XML data?
>
>You know the context because interpretation of the XML data is being done
by
>software from a presumably reliable source to do the interpretation that is
>built according to a specification that describes the semantics of data
>
>... I now feel that we're getting very close to the topic of "trusted"
>applications  and I'm not sure we want to go there ...

Even if XSL is signed, you still have to assume a "trusted" browser.
It's impossible not to go there...

Milt

 

-----------------------------------------------------------------------
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]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
Date: Thu, 23 Sep 1999 10:42:01 -0600
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
Cc: [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
Subject: Re[2]: How to sign several resources (XML and XSL)? 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

--simple boundary
Content-Type: text/plain; charset=US-ASCII
Content-Description: "cc:Mail Note Part"
Content-Transfer-Encoding: 7bit

XSL is an XML format, so we haven't excluded signature of XSL, have we? Also,
I'm aware of the W3C recommendation at

http://www.w3.org/TR/xml-stylesheet/

that ties a stylesheet to an XML document.  However, a processing instruction is
used for this purpose, and we have proposed elimination of PI from our c14n.  I
believe this needs to be revisited.  Applications will definitely want the
option to locate and sign an associated stylesheet.  IMO, It is not for us to
judge whether or not this makes sense to the application just because our
committee(s) can't guarantee a trusted browser.  The level of trust required is
up to the application (they may restrict their application to specific signed
and trusted browsers, they may certify their application for specific common
browsers, etc.)

Rich

____________________Reply Separator____________________
Subject:    Re: How to sign several resources (XML and XSL)? 
Author: "Milton M. Anderson" <[email-masked]>
Date:       9/23/99 7:44 AM

-----Original Message-----
From: David Burdett <[email-masked]>
Date: Wednesday, September 22, 1999 11:39 PM
Subject: RE: How to sign several resources (XML and XSL)?

>... otherwise how do you know the context for the XML data?
>
>You know the context because interpretation of the XML data is being done
by
>software from a presumably reliable source to do the interpretation that is
>built according to a specification that describes the semantics of data
>
>... I now feel that we're getting very close to the topic of "trusted"
>applications  and I'm not sure we want to go there ...

Even if XSL is signed, you still have to assume a "trusted" browser.
It's impossible not to go there...

Milt

 

--simple boundary
Content-Type: text/plain; charset=US-ASCII; name="RFC822.TXT"
Content-Disposition: attachment; filename="RFC822.TXT"
Content-Transfer-Encoding: 7bit

Resent-Date: Thu, 23 Sep 1999 00:31:55 -0400 (EDT)
Resent-Message-Id: <[email-masked]>
Reply-To: "Milton M. Anderson" <[email-masked]>
From: "Milton M. Anderson" <[email-masked]>
To: "David Burdett" <[email-masked]>,
        "DJ" <[email-masked]>,
        "Winchel 'Todd' Vincent, III" <[email-masked]>,
        "Andreas Siglreithmayr" <[email-masked]>,
        "W3c-Ietf-Xmldsig (E-mail)" <[email-masked]>
Cc: "IETF Trade (E-mail)" <[email-masked]>
Date: Thu, 23 Sep 1999 00:35:18 -0400
Subject: Re: How to sign several resources (XML and XSL)?
Resent-From: [email-masked]
Sender: [email-masked]
Resent-Sender: [email-masked]

--simple boundary--
-----------------------------------------------------------------------
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: DJ <[email-masked]>
cc: "W3c-Ietf-Xmldsig (E-mail)" <[email-masked]>, "IETF Trade (E-mail)" <[email-masked]>
Date: Thu, 23 Sep 1999 13:44:54 -0400
Subject: RE: How to sign several resources (XML and XSL)?
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Proof in court depends on all kind of factors, many of which never appear in any
computer readable form.   As long as we provide ways for people to sign digital
objects, they can include under the signatre, directly or indirectly, anything
they want including anything they think might be helpful for later proofs.  If
someone wants to write a draft in the XMLDSIG group on the topic of what you
might want to sign in conjuction with a document for such legal purposes, they
are welcome to do so, but I don't see this as having a lot to do with our task
of defining XML digital signature syntax and processing.  Nor do I see these
questions as having much to do with IOTP where most signatures having nothing to
do with human sensible documents but rather with highly stylized protocol
messages.

Donald

Donald E. Eastlake, 3rd
17 Skyline Drive, Hawthorne, NY 10532 USA
[email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833

home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
[email-masked]   tel: 1-914-276-2668

DJ <[email-masked]> on 09/23/99 12:21:06 PM

To:   David Burdett <[email-masked]>, "Winchel 'Todd' Vincent,
      III" <[email-masked]>, Andreas Siglreithmayr
      <[email-masked]>, "W3c-Ietf-Xmldsig (E-mail)"
      <[email-masked]>
cc:   "IETF Trade (E-mail)" <[email-masked]>
Subject:  RE: How to sign several resources (XML and XSL)?

But to present legally binding evidence at a future date you may need to
present the signed XML, the presentation (signed XSL) and perhaps even
the application that displayed it (a signed copy of Netscape??? or perhaps
the UWI.com forms browser?)

DJ

At 08:36 PM 9/22/99 -0700, David Burdett wrote:
>... otherwise how do you know the context for the XML data?
>
>You know the context because interpretation of the XML data is being done by
>software from a presumably reliable source to do the interpretation that is
>built according to a specification that describes the semantics of data
>
>... I now feel that we're getting very close to the topic of "trusted"
>applications  and I'm not sure we want to go there ...
>
>David
>
>-----Original Message-----
>From: DJ [mailto:[email-masked]]
>Sent: Wednesday, September 22, 1999 3:49 PM
>To: David Burdett; Winchel 'Todd' Vincent, III; Andreas Siglreithmayr;
>W3c-Ietf-Xmldsig (E-mail)
>Cc: IETF Trade (E-mail)
>Subject: RE: How to sign several resources (XML and XSL)?
>
>
>
>UWI.com has an XML implementation that signs the "presentation" (eg. the
>XSL)
>as well as the XML.  In their view, it is critically important to sign
>both, otherwise
>how do you know the context for the XML data?
>
>dj
>
>At 02:45 PM 9/22/99 -0700, David Burdett wrote:
>>Following on from this I'm wondering what people's views are on signing an
>>XML document that is primarily an XML representation of a data structure
>>that is defined in a specification that is widely and publically available.
>>
>>The XML document, in it's native form is readable but not easily
>>understandable. A style sheet would make the document easier to understand
>>but is not required since the semantics of the document are defined in the
>>specification. However could use of a stylesheet then be construed as
>>altering the meaning of the XML document as far as a recipient is
>concerned.
>>
>>I ask since this is what IOTP effectively does, it signs several parts of a
>>data structure (represented in XML) and then creates new data structures
>>from the orginal that are also digitally signed and, using additional
>>"endorsing" signatures, "binds" the new document back to the original.
>>
>>David
>>
>>-----Original Message-----
>>From: Winchel 'Todd' Vincent, III [mailto:[email-masked]]
>>Sent: Wednesday, September 22, 1999 1:43 AM
>>To: Andreas Siglreithmayr; W3c-Ietf-Xmldsig (E-mail)
>>Subject: Re: How to sign several resources (XML and XSL)?
>>
>>
>>>
>>> I think that if someone signs an XML-document, s/he would also have
>>>to sign the corresponding XSL file.
>>
>>Andreas:
>>
>>Other people on this list hold the very same opinion.  Indeed, as an
>>American lawyer, I believe there are very good legal reasons why *not*
>>signing the stylesheet might just get and XML document thrown out of court
>>if/when it were introduced into evidence.  Such a result would, of course,
>>make the technology much less valuable.
>>
>>Thank you for your input.  I think having someone with a new and fresh
>>perspective helps to shed light on the simplicity and logic of the notion.
>>I wish others would see it so clearly.
>>
>>Todd
>>
>-----------------------------------------------------------------------
>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]

-----------------------------------------------------------------------
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, 23 Sep 1999 09:21:06 -0700
To: David Burdett <[email-masked]>, "Winchel 'Todd' Vincent, III" <[email-masked]>, Andreas Siglreithmayr <[email-masked]>, "W3c-Ietf-Xmldsig (E-mail)" <[email-masked]>
From: DJ <[email-masked]>
Subject: RE: How to sign several resources (XML and XSL)?
Cc: "IETF Trade (E-mail)" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

But to present legally binding evidence at a future date you may need to
present the signed XML, the presentation (signed XSL) and perhaps even
the application that displayed it (a signed copy of Netscape??? or perhaps
the UWI.com forms browser?)

DJ

At 08:36 PM 9/22/99 -0700, David Burdett wrote:
>... otherwise how do you know the context for the XML data?
>
>You know the context because interpretation of the XML data is being done by
>software from a presumably reliable source to do the interpretation that is
>built according to a specification that describes the semantics of data 
>
>... I now feel that we're getting very close to the topic of "trusted"
>applications  and I'm not sure we want to go there ...
>
>David
>
>-----Original Message-----
>From: DJ [mailto:[email-masked]]
>Sent: Wednesday, September 22, 1999 3:49 PM
>To: David Burdett; Winchel 'Todd' Vincent, III; Andreas Siglreithmayr;
>W3c-Ietf-Xmldsig (E-mail)
>Cc: IETF Trade (E-mail)
>Subject: RE: How to sign several resources (XML and XSL)?
>
>
>
>UWI.com has an XML implementation that signs the "presentation" (eg. the
>XSL)
>as well as the XML.  In their view, it is critically important to sign
>both, otherwise
>how do you know the context for the XML data?  
>
>dj
>
>At 02:45 PM 9/22/99 -0700, David Burdett wrote:
>>Following on from this I'm wondering what people's views are on signing an
>>XML document that is primarily an XML representation of a data structure
>>that is defined in a specification that is widely and publically available.
>>
>>The XML document, in it's native form is readable but not easily
>>understandable. A style sheet would make the document easier to understand
>>but is not required since the semantics of the document are defined in the
>>specification. However could use of a stylesheet then be construed as
>>altering the meaning of the XML document as far as a recipient is
>concerned.
>>
>>I ask since this is what IOTP effectively does, it signs several parts of a
>>data structure (represented in XML) and then creates new data structures
>>from the orginal that are also digitally signed and, using additional
>>"endorsing" signatures, "binds" the new document back to the original.
>>
>>David
>>
>>-----Original Message-----
>>From: Winchel 'Todd' Vincent, III [mailto:[email-masked]]
>>Sent: Wednesday, September 22, 1999 1:43 AM
>>To: Andreas Siglreithmayr; W3c-Ietf-Xmldsig (E-mail)
>>Subject: Re: How to sign several resources (XML and XSL)?
>>
>>
>>>
>>> I think that if someone signs an XML-document, s/he would also have
>>>to sign the corresponding XSL file.
>>
>>Andreas:
>>
>>Other people on this list hold the very same opinion.  Indeed, as an
>>American lawyer, I believe there are very good legal reasons why *not*
>>signing the stylesheet might just get and XML document thrown out of court
>>if/when it were introduced into evidence.  Such a result would, of course,
>>make the technology much less valuable.
>>
>>Thank you for your input.  I think having someone with a new and fresh
>>perspective helps to shed light on the simplicity and logic of the notion.
>>I wish others would see it so clearly.
>>
>>Todd
>>
>-----------------------------------------------------------------------
>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: Ed Simon <[email-masked]>
To: "'David Burdett'" <[email-masked]>, "W3c-Ietf-Xmldsig (E-mail)" <[email-masked]>
Cc: "IETF Trade (E-mail)" <[email-masked]>
Subject: RE: How to sign several resources (XML and XSL)?
Date: Wed, 22 Sep 1999 19:26:56 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

When someone signs something, I would imagine that he/she would
be looking at some sort of visual contract at the time.  Ideally,
one would want to sign enough of the "presentation mechanism" to
be able to re-create as closely as possible the appearance of
that contract later (perhaps for legal purposes).

Stylesheets provides an excellent way of capturing the presentation
of XML-encoded data.  It would seem to me that many applications
might want to consider using XSL for this purpose and would then
sign the XSL use to present the XML data also being signed.

Of course, the visual appearance may be affected by other factors
such as the limitations of the browser (did that version process
the stylesheet properly?) and the physical device.
One would also have to make sure there could be no unresolved
external entities that could be disputed later
(eg. don't sign "&bank;", sign the value of
the entity, eg. "Bank of Bells Corners").

I don't recall if it has been mentioned yet on this archive
but our own Joseph Reagle has a recent paper entitled
"Eskimo Snow and Scottish Rain*:
Legal Considerations of Schema Design"
(see "http://www.w3.org/TR/md-policy-design").

Regards, Ed

-----Original Message-----
From: David Burdett [mailto:[email-masked]]
Sent: September 22, 1999 5:46 PM
To: Winchel 'Todd' Vincent, III; Andreas Siglreithmayr; W3c-Ietf-Xmldsig
(E-mail)
Cc: IETF Trade (E-mail)
Subject: RE: How to sign several resources (XML and XSL)?

Following on from this I'm wondering what people's views are on signing an
XML document that is primarily an XML representation of a data structure
that is defined in a specification that is widely and publically available.

The XML document, in it's native form is readable but not easily
understandable. A style sheet would make the document easier to understand
but is not required since the semantics of the document are defined in the
specification. However could use of a stylesheet then be construed as
altering the meaning of the XML document as far as a recipient is concerned.

I ask since this is what IOTP effectively does, it signs several parts of a
data structure (represented in XML) and then creates new data structures
from the orginal that are also digitally signed and, using additional
"endorsing" signatures, "binds" the new document back to the original.

David

-----Original Message-----
From: Winchel 'Todd' Vincent, III [mailto:[email-masked]]
Sent: Wednesday, September 22, 1999 1:43 AM
To: Andreas Siglreithmayr; W3c-Ietf-Xmldsig (E-mail)
Subject: Re: How to sign several resources (XML and XSL)?

>
> I think that if someone signs an XML-document, s/he would also have
>to sign the corresponding XSL file.

Andreas:

Other people on this list hold the very same opinion.  Indeed, as an
American lawyer, I believe there are very good legal reasons why *not*
signing the stylesheet might just get and XML document thrown out of court
if/when it were introduced into evidence.  Such a result would, of course,
make the technology much less valuable.

Thank you for your input.  I think having someone with a new and fresh
perspective helps to shed light on the simplicity and logic of the notion.
I wish others would see it so clearly.

Todd
-----------------------------------------------------------------------
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: "Milton M. Anderson" <[email-masked]>
From: "Milton M. Anderson" <[email-masked]>
To: David Burdett <[email-masked]>, DJ <[email-masked]>, "Winchel 'Todd' Vincent, III" <[email-masked]>, Andreas Siglreithmayr <[email-masked]>, "W3c-Ietf-Xmldsig (E-mail)" <[email-masked]>
Cc: "IETF Trade (E-mail)" <[email-masked]>
Subject: Re: How to sign several resources (XML and XSL)?
Date: Thu, 23 Sep 1999 00:35:18 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

-----Original Message-----
From: David Burdett <[email-masked]>
Date: Wednesday, September 22, 1999 11:39 PM
Subject: RE: How to sign several resources (XML and XSL)?

>... otherwise how do you know the context for the XML data?
>
>You know the context because interpretation of the XML data is being done
by
>software from a presumably reliable source to do the interpretation that is
>built according to a specification that describes the semantics of data
>
>... I now feel that we're getting very close to the topic of "trusted"
>applications  and I'm not sure we want to go there ...

Even if XSL is signed, you still have to assume a "trusted" browser.
It's impossible not to go there...

Milt

-----------------------------------------------------------------------
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: Greg Whitehead <[email-masked]>, "'DJ'" <[email-masked]>, "Winchel 'Todd' Vincent, III" <[email-masked]>, Andreas Siglreithmayr <[email-masked]>, "W3c-Ietf-Xmldsig (E-mail)" <[email-masked]>
Cc: "IETF Trade (E-mail)" <[email-masked]>
Subject: RE: How to sign several resources (XML and XSL)?
Date: Wed, 22 Sep 1999 20:36:52 -0700
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I agree ... but in IOTP the XML data can include an offer that says, for
example, "purchase a widget for $10". This offer can be expressed in XML
(with a style sheet if required), HTML or plain text. However the buyer
needs to be "presented" with the offer to decide whether or not to accept
it. The offer can also be signed for the usual reasons such as:
- tamper resistance
- to authenticate the creator

So really there's a mixture of wire protocol and human intepretation ...

David

-----Original Message-----
From: Greg Whitehead [mailto:[email-masked]]
Sent: Wednesday, September 22, 1999 4:13 PM
To: 'DJ'; David Burdett; Winchel 'Todd' Vincent, III; Andreas
Siglreithmayr; W3c-Ietf-Xmldsig (E-mail)
Cc: IETF Trade (E-mail)
Subject: RE: How to sign several resources (XML and XSL)?

Where XML is being used in the context of a wire protocol, and there is no
XSL style sheet used in the interpretation of the messages by the protocol
engine, it shouldn't be necessary to include any XSL in the signature.

In general, you need to look at the context in which signed data is being
interpreted and be sure that all of the elements critical to the
interpretation can be trusted (were signed or obtained securely from some
trusted source).

-Greg

-----Original Message-----
From: DJ [mailto:[email-masked]]
Sent: Wednesday, September 22, 1999 3:49 PM
To: David Burdett; Winchel 'Todd' Vincent, III; Andreas Siglreithmayr;
W3c-Ietf-Xmldsig (E-mail)
Cc: IETF Trade (E-mail)
Subject: RE: How to sign several resources (XML and XSL)?

UWI.com has an XML implementation that signs the "presentation" (eg. the
XSL)
as well as the XML.  In their view, it is critically important to sign
both, otherwise
how do you know the context for the XML data?  

dj

At 02:45 PM 9/22/99 -0700, David Burdett wrote:
>Following on from this I'm wondering what people's views are on signing an
>XML document that is primarily an XML representation of a data structure
>that is defined in a specification that is widely and publically available.
>
>The XML document, in it's native form is readable but not easily
>understandable. A style sheet would make the document easier to understand
>but is not required since the semantics of the document are defined in the
>specification. However could use of a stylesheet then be construed as
>altering the meaning of the XML document as far as a recipient is
concerned.
>
>I ask since this is what IOTP effectively does, it signs several parts of a
>data structure (represented in XML) and then creates new data structures
>from the orginal that are also digitally signed and, using additional
>"endorsing" signatures, "binds" the new document back to the original.
>
>David
>
>-----Original Message-----
>From: Winchel 'Todd' Vincent, III [mailto:[email-masked]]
>Sent: Wednesday, September 22, 1999 1:43 AM
>To: Andreas Siglreithmayr; W3c-Ietf-Xmldsig (E-mail)
>Subject: Re: How to sign several resources (XML and XSL)?
>
>
>>
>> I think that if someone signs an XML-document, s/he would also have
>>to sign the corresponding XSL file.
>
>Andreas:
>
>Other people on this list hold the very same opinion.  Indeed, as an
>American lawyer, I believe there are very good legal reasons why *not*
>signing the stylesheet might just get and XML document thrown out of court
>if/when it were introduced into evidence.  Such a result would, of course,
>make the technology much less valuable.
>
>Thank you for your input.  I think having someone with a new and fresh
>perspective helps to shed light on the simplicity and logic of the notion.
>I wish others would see it so clearly.
>
>Todd
>

-----------------------------------------------------------------------
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: David Burdett <[email-masked]>
To: DJ <[email-masked]>, "Winchel 'Todd' Vincent, III" <[email-masked]>, Andreas Siglreithmayr <[email-masked]>, "W3c-Ietf-Xmldsig (E-mail)" <[email-masked]>
Cc: "IETF Trade (E-mail)" <[email-masked]>
Subject: RE: How to sign several resources (XML and XSL)?
Date: Wed, 22 Sep 1999 20:36:50 -0700
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

... otherwise how do you know the context for the XML data?

You know the context because interpretation of the XML data is being done by
software from a presumably reliable source to do the interpretation that is
built according to a specification that describes the semantics of data 

... I now feel that we're getting very close to the topic of "trusted"
applications  and I'm not sure we want to go there ...

David

-----Original Message-----
From: DJ [mailto:[email-masked]]
Sent: Wednesday, September 22, 1999 3:49 PM
To: David Burdett; Winchel 'Todd' Vincent, III; Andreas Siglreithmayr;
W3c-Ietf-Xmldsig (E-mail)
Cc: IETF Trade (E-mail)
Subject: RE: How to sign several resources (XML and XSL)?

UWI.com has an XML implementation that signs the "presentation" (eg. the
XSL)
as well as the XML.  In their view, it is critically important to sign
both, otherwise
how do you know the context for the XML data?  

dj

At 02:45 PM 9/22/99 -0700, David Burdett wrote:
>Following on from this I'm wondering what people's views are on signing an
>XML document that is primarily an XML representation of a data structure
>that is defined in a specification that is widely and publically available.
>
>The XML document, in it's native form is readable but not easily
>understandable. A style sheet would make the document easier to understand
>but is not required since the semantics of the document are defined in the
>specification. However could use of a stylesheet then be construed as
>altering the meaning of the XML document as far as a recipient is
concerned.
>
>I ask since this is what IOTP effectively does, it signs several parts of a
>data structure (represented in XML) and then creates new data structures
>from the orginal that are also digitally signed and, using additional
>"endorsing" signatures, "binds" the new document back to the original.
>
>David
>
>-----Original Message-----
>From: Winchel 'Todd' Vincent, III [mailto:[email-masked]]
>Sent: Wednesday, September 22, 1999 1:43 AM
>To: Andreas Siglreithmayr; W3c-Ietf-Xmldsig (E-mail)
>Subject: Re: How to sign several resources (XML and XSL)?
>
>
>>
>> I think that if someone signs an XML-document, s/he would also have
>>to sign the corresponding XSL file.
>
>Andreas:
>
>Other people on this list hold the very same opinion.  Indeed, as an
>American lawyer, I believe there are very good legal reasons why *not*
>signing the stylesheet might just get and XML document thrown out of court
>if/when it were introduced into evidence.  Such a result would, of course,
>make the technology much less valuable.
>
>Thank you for your input.  I think having someone with a new and fresh
>perspective helps to shed light on the simplicity and logic of the notion.
>I wish others would see it so clearly.
>
>Todd
>
-----------------------------------------------------------------------
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: Greg Whitehead <[email-masked]>
To: "'DJ'" <[email-masked]>, David Burdett <[email-masked]>, "Winchel 'Todd' Vincent, III" <[email-masked]>, Andreas Siglreithmayr <[email-masked]>, "W3c-Ietf-Xmldsig (E-mail)" <[email-masked]>
Cc: "IETF Trade (E-mail)" <[email-masked]>
Subject: RE: How to sign several resources (XML and XSL)?
Date: Wed, 22 Sep 1999 16:12:57 -0700
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Where XML is being used in the context of a wire protocol, and there is no
XSL style sheet used in the interpretation of the messages by the protocol
engine, it shouldn't be necessary to include any XSL in the signature.

In general, you need to look at the context in which signed data is being
interpreted and be sure that all of the elements critical to the
interpretation can be trusted (were signed or obtained securely from some
trusted source).

-Greg

-----Original Message-----
From: DJ [mailto:[email-masked]]
Sent: Wednesday, September 22, 1999 3:49 PM
To: David Burdett; Winchel 'Todd' Vincent, III; Andreas Siglreithmayr;
W3c-Ietf-Xmldsig (E-mail)
Cc: IETF Trade (E-mail)
Subject: RE: How to sign several resources (XML and XSL)?

UWI.com has an XML implementation that signs the "presentation" (eg. the
XSL)
as well as the XML.  In their view, it is critically important to sign
both, otherwise
how do you know the context for the XML data?  

dj

At 02:45 PM 9/22/99 -0700, David Burdett wrote:
>Following on from this I'm wondering what people's views are on signing an
>XML document that is primarily an XML representation of a data structure
>that is defined in a specification that is widely and publically available.
>
>The XML document, in it's native form is readable but not easily
>understandable. A style sheet would make the document easier to understand
>but is not required since the semantics of the document are defined in the
>specification. However could use of a stylesheet then be construed as
>altering the meaning of the XML document as far as a recipient is
concerned.
>
>I ask since this is what IOTP effectively does, it signs several parts of a
>data structure (represented in XML) and then creates new data structures
>from the orginal that are also digitally signed and, using additional
>"endorsing" signatures, "binds" the new document back to the original.
>
>David
>
>-----Original Message-----
>From: Winchel 'Todd' Vincent, III [mailto:[email-masked]]
>Sent: Wednesday, September 22, 1999 1:43 AM
>To: Andreas Siglreithmayr; W3c-Ietf-Xmldsig (E-mail)
>Subject: Re: How to sign several resources (XML and XSL)?
>
>
>>
>> I think that if someone signs an XML-document, s/he would also have
>>to sign the corresponding XSL file.
>
>Andreas:
>
>Other people on this list hold the very same opinion.  Indeed, as an
>American lawyer, I believe there are very good legal reasons why *not*
>signing the stylesheet might just get and XML document thrown out of court
>if/when it were introduced into evidence.  Such a result would, of course,
>make the technology much less valuable.
>
>Thank you for your input.  I think having someone with a new and fresh
>perspective helps to shed light on the simplicity and logic of the notion.
>I wish others would see it so clearly.
>
>Todd
>

-----------------------------------------------------------------------
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: Wed, 22 Sep 1999 15:49:14 -0700
To: David Burdett <[email-masked]>, "Winchel 'Todd' Vincent, III" <[email-masked]>, Andreas Siglreithmayr <[email-masked]>, "W3c-Ietf-Xmldsig (E-mail)" <[email-masked]>
From: DJ <[email-masked]>
Subject: RE: How to sign several resources (XML and XSL)?
Cc: "IETF Trade (E-mail)" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

UWI.com has an XML implementation that signs the "presentation" (eg. the XSL)
as well as the XML.  In their view, it is critically important to sign
both, otherwise
how do you know the context for the XML data?  

dj

At 02:45 PM 9/22/99 -0700, David Burdett wrote:
>Following on from this I'm wondering what people's views are on signing an
>XML document that is primarily an XML representation of a data structure
>that is defined in a specification that is widely and publically available.
>
>The XML document, in it's native form is readable but not easily
>understandable. A style sheet would make the document easier to understand
>but is not required since the semantics of the document are defined in the
>specification. However could use of a stylesheet then be construed as
>altering the meaning of the XML document as far as a recipient is concerned.
>
>I ask since this is what IOTP effectively does, it signs several parts of a
>data structure (represented in XML) and then creates new data structures
>from the orginal that are also digitally signed and, using additional
>"endorsing" signatures, "binds" the new document back to the original.
>
>David
>
>-----Original Message-----
>From: Winchel 'Todd' Vincent, III [mailto:[email-masked]]
>Sent: Wednesday, September 22, 1999 1:43 AM
>To: Andreas Siglreithmayr; W3c-Ietf-Xmldsig (E-mail)
>Subject: Re: How to sign several resources (XML and XSL)?
>
>
>>
>> I think that if someone signs an XML-document, s/he would also have
>>to sign the corresponding XSL file.
>
>Andreas:
>
>Other people on this list hold the very same opinion.  Indeed, as an
>American lawyer, I believe there are very good legal reasons why *not*
>signing the stylesheet might just get and XML document thrown out of court
>if/when it were introduced into evidence.  Such a result would, of course,
>make the technology much less valuable.
>
>Thank you for your input.  I think having someone with a new and fresh
>perspective helps to shed light on the simplicity and logic of the notion.
>I wish others would see it so clearly.
>
>Todd
>

-----------------------------------------------------------------------
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: "Winchel 'Todd' Vincent, III" <[email-masked]>, Andreas Siglreithmayr <[email-masked]>, "W3c-Ietf-Xmldsig (E-mail)" <[email-masked]>
Cc: "IETF Trade (E-mail)" <[email-masked]>
Subject: RE: How to sign several resources (XML and XSL)?
Date: Wed, 22 Sep 1999 14:45:34 -0700
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_000_01BF0543.DC36499A
Content-Type: text/plain;
	charset="ISO-8859-1"

Following on from this I'm wondering what people's views are on signing an
XML document that is primarily an XML representation of a data structure
that is defined in a specification that is widely and publically available.

The XML document, in it's native form is readable but not easily
understandable. A style sheet would make the document easier to understand
but is not required since the semantics of the document are defined in the
specification. However could use of a stylesheet then be construed as
altering the meaning of the XML document as far as a recipient is concerned.

I ask since this is what IOTP effectively does, it signs several parts of a
data structure (represented in XML) and then creates new data structures
from the orginal that are also digitally signed and, using additional
"endorsing" signatures, "binds" the new document back to the original.

David

-----Original Message-----
From: Winchel 'Todd' Vincent, III [mailto:[email-masked]]
Sent: Wednesday, September 22, 1999 1:43 AM
To: Andreas Siglreithmayr; W3c-Ietf-Xmldsig (E-mail)
Subject: Re: How to sign several resources (XML and XSL)?

>
> I think that if someone signs an XML-document, s/he would also have
>to sign the corresponding XSL file.

Andreas:

Other people on this list hold the very same opinion.  Indeed, as an
American lawyer, I believe there are very good legal reasons why *not*
signing the stylesheet might just get and XML document thrown out of court
if/when it were introduced into evidence.  Such a result would, of course,
make the technology much less valuable.

Thank you for your input.  I think having someone with a new and fresh
perspective helps to shed light on the simplicity and logic of the notion.
I wish others would see it so clearly.

Todd

------_=_NextPart_000_01BF0543.DC36499A
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

------_=_NextPart_000_01BF0543.DC36499A--
-----------------------------------------------------------------------
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: Yoshiaki KAWATSURA <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: iotpar101c.zip 
Date: Tue, 21 Sep 1999 18:29:11 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

OK.  It would be great if we could resolve any differences and get
this into Internet-Draft form so it can be posted by mid-October,
before the cutoff for the November IETF meeting.

Thanks,
Donald

From:  Yoshiaki KAWATSURA <[email-masked]>
Message-Id:  <[email-masked]>
To:  [email-masked], [email-masked]
Cc:  [email-masked]
Cc:  [email-masked]
In-Reply-To:  Your message of "Mon, 20 Sep 1999 23:35:10 -0400"
	     	<[email-masked]>
References:  <[email-masked]>
Date:  Tue, 21 Sep 1999 13:58:38 +0900 (JST)
Sender:  Yoshiaki KAWATSURA <[email-masked]>

>Hans and Don,
>We are now developing the IOTP Payment API Specification to use the
>SMILE project.
>This is based on the Hans' (and my) IOTP Payment API version 1.01a, but
>several(many?) points of our specification has been changed or updated
>for fitting the current specification, efficiency and problem
>resolutions.
>
>We want to feedback our considerations to your draft and fit them.
>
>We will check the current IOTP Payment API and send the differences 
>between them ASAP.
>
>Regards,
>----
>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: Greg Whitehead <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: digital signature comments
Date: Tue, 21 Sep 1999 13:56:07 -0700
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I'm new to the mailing list, so forgive me if these points have been
discussed before.  I'm looking forward to meeting everyone at the upcoming
meeting in DC.

First, I come from the PKIX world, so my attention was immediately drawn to
the digital signature aspects of the proposal:
	[1] draft-ietf-trade-iotp-v1.0-dsig-03.txt
	[2] draft-ietf-trade-hiroshi-dom-hash-03.txt

I understand that v2 of the IOTP protocol may use a completely different
signature syntax, based on the XMLDSIG WG output, but I offer the following
comments on the v1 syntax [1] in the interest of producing interoperable
implementations:

3.3 OriginatorInfo and RecipientInfo
------------------------------------

These are both familiar terms from S/MIME CMS, but I was initially confused
by the inclusion of RecipientInfo in a signature.

In CMS, a RecipientInfo is used to exchange a symmetric cipher key with a
recipient (using either RSA or DH) when encrypting data for that recipient.

OriginatorInfo was expected, as it is used in CMS when signing with DSA (but
not with RSA). It's role has been expanded in IOTP-DSIG to identify the
signer, which is fine (that info appears elsewhere in CMS).

I eventually figured out that the intent of including RecipientInfo was to
enable "signature" algorithms based on shared secrets.  I suppose that's
fine as long as the properties of these algorithms are well understood: the
proposed HMAC signature, for example, couldn't be used for non-repudiation
since the recipient could trivially forge the signature.

4.3.1 Signature
---------------

>From the text:

>  The process for generating the signed value is a multi-step process,
>  involving a canonicalization algorithm, a digest algorithm, and a
>  signature algorithm.
>
>  First, the Manifest is canonicalized with an algorithm specified
>  within the Algorithm element of the Manifest. The canonicalized form
>  removes any inconsistencies in white space introduced by XML parsing
>  engines.
>
>  This canonicalized form is then converted into a digest form which
>  uniquely identifies the canonicalized document. Any slight
>  modification in the original document will result in a very different
>  digest value.

This suggests that a canonicalization algorithm must be specified in the
Manifiest (section 4.3.2), yet the Algorithm type (section 4.3.3) provides
no way to do that. 

It appears that canonicalization has been folded into the digest algorithm,
which makes sense since the two are sometimes inseparable (DOMHASH), but
this should be clarified.

If DOMHASH is, in fact, meant to include canonicalization, it would be good
if its spec [2] provided specific details (along with test cases and their
respective digest values).

4.4.2 IssuerAndSerialNumber
---------------------------

As used in CMS, IssuerAndSerialNumber is a binary structure lifted directly
from the certificate.  In IOTP-DSIG, the issuer name (X.500 DN) and serial
number (ASN.1 Integer) are each represented as strings.  Unfortunately,
converting DNs to strings is non-trivial (internally, DNs are binary
structures that use ASN.1 OIDs to identify attributes and determine the
encoding of their values).

If IssuerNameAndSerialNumber is simply meant to serve as an opaque
identifier, to name Certificate elements included in IOTPSignatures, then
there is no problem: any scheme that produces unique identifiers will work
(why not just use an IDREF in that case?)

If, however, it is meant to serve as a key for locating certificates in an
external repository, such as an LDAP directory, then the format needs to be
more precisely specified.  I would suggest rfc2253 (LDAPv3: UTF-8 String
Representation of Distinguished Names) as a starting point:

	http://www.ietf.org/rfc/rfc2253.txt

-Greg

--
Greg Whitehead
Chief Scientist
Signio, Inc.
1600 Bridge Parkway, Suite 201
Redwood City, CA  94065
650-622-2250
650-622-2201 (fax)
[email-masked]
http://www.signio.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], [email-masked]
Cc: [email-masked]
Cc: [email-masked]
Subject: Re: iotpar101c.zip
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Tue, 21 Sep 1999 13:58:38 +0900 (JST)
Lines: 18
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Hans and Don,
We are now developing the IOTP Payment API Specification to use the
SMILE project.
This is based on the Hans' (and my) IOTP Payment API version 1.01a, but
several(many?) points of our specification has been changed or updated
for fitting the current specification, efficiency and problem
resolutions.

We want to feedback our considerations to your draft and fit them.

We will check the current IOTP Payment API and send the differences 
between them ASAP.

Regards,
----
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]

To: [email-masked]
Subject: iotpar101c.zip
Date: Mon, 20 Sep 1999 23:35:10 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

An updated version of the IOTP Architecture and Payment API draft is
available at <ftp://ftp.pothole.com/pub/ietf-trade/iotpar101c.zip>.
This is a zipped MS Word document but has been changed greatly
from previous formats to be much closer to Internet-Draft format
including ASCII figures.

Thanks to Wernver Hans for producing the update.

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]
Subject: MS word version of -06 protocol doc
Date: Thu, 16 Sep 1999 00:49:18 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

There is now a MS World version of the -06 protocol document with changes
highlighted available in
<ftp://ftp.pothole.com/ftp/ietf-trade/v1.0-protocol-06/>

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]
Subject: Advancing IOTP Protocol, DSIG, and DOM HASH (2nd try)
Date: Tue, 14 Sep 1999 14:02:57 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Based on feedback from our Area Director, the documents have been
revised and reposted with the latest minor improvements and I
am requesting that they be advanced to Informational.

The documents are
draft-ietf-trade-iotp-v1.0-protocol-06.txt
draft-ietf-trade-iotp-v1.0-dsig-03.txt
draft-ietf-trade-hiroshi-dom-hash-03.txt

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: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-trade-iotp-v1.0-dsig-03.txt
Date: Tue, 14 Sep 1999 07:30:10 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF.

	Title		: Digital Signatures for the Internet Open Trading 
                          Protocol
	Author(s)	: K. Davidson, Y. Kawatsura
	Filename	: draft-ietf-trade-iotp-v1.0-dsig-03.txt
	Pages		: 31
	Date		: 13-Sep-99
	
A syntax and procedures are described for the computation and
verification of digital signatures for use within Version 1.0 of the
Internet Open Trading Protocol (IOTP).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-dsig-03.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-trade-iotp-v1.0-dsig-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-dsig-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-dsig-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-trade-iotp-v1.0-dsig-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

-----------------------------------------------------------------------
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: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-trade-hiroshi-dom-hash-03.txt
Date: Tue, 14 Sep 1999 07:30:04 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF.

	Title		: Digest Values for DOM (DOMHASH)
	Author(s)	: H. Maruyama, K. Tamura, N. Uramoto
 	Filename	: draft-ietf-trade-hiroshi-dom-hash-03.txt
	Pages		: 11
	Date		: 13-Sep-99
	
This internet draft defines a clear and unambiguous definition of
digest (hash) values of the XML objects regardless of the surface
string variation of XML. This definition can be used for XML digital
signature as well efficient replication of XML objects.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trade-hiroshi-dom-hash-03.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-trade-hiroshi-dom-hash-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-trade-hiroshi-dom-hash-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-trade-hiroshi-dom-hash-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-trade-hiroshi-dom-hash-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

-----------------------------------------------------------------------
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: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-trade-iotp-v1.0-protocol-06.txt
Date: Tue, 14 Sep 1999 07:30:34 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF.

	Title		: Internet Open Trading Protocol - IOTP Version 1.0
	Author(s)	: D. Burdett
	Filename	: draft-ietf-trade-iotp-v1.0-protocol-06.txt
	Pages		: 253
	Date		: 13-Sep-99
	
The Internet Open Trading Protocol (IOTP) provides an interoperable
framework for Internet commerce. It is payment system independent and
encapsulates payment systems such as SET, Secure Channel Credit/Debit,
Mondex, CyberCoin, GeldKarte, etc. IOTP is able to handle cases where
such merchant roles as the shopping site, the Payment Handler, the
Delivery Handler of goods or services, and the provider of customer
support are performed by different parties or by one party.
This document obsoletes the previous version of the IOTP specification
(draft-ietf-trade-iotp-v1.0-protocol-04.txt.)

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-protocol-06.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-trade-iotp-v1.0-protocol-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-protocol-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-protocol-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-trade-iotp-v1.0-protocol-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

-----------------------------------------------------------------------
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: protocol-06 DTD and 05->06 changes
Date: Tue, 14 Sep 1999 00:12:57 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

These two files are available in
<ftp://ftp.pothole.com/pub/ietf-trade/v1.0-protocol-06/>.

The rest should be there soon.

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]

From: David Burdett <[email-masked]>
To: "IETF Trade (E-mail)" <[email-masked]>
Subject: Revision 06 of the IOTP specification
Date: Mon, 13 Sep 1999 08:47:31 -0700
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_000_01BEFDFF.485EFCA8
Content-Type: text/plain;
	charset="ISO-8859-1"

I've just sent revision 06 of the IOTP specification to the internet drafts
editor. I've also copied the file, and a MS Word version with changes
highlighted, and a list of changes, and the updated DTD to Donald who'll
post them to his ftp web site soon.

Regards

David

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

------_=_NextPart_000_01BEFDFF.485EFCA8
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

ABJQ

------_=_NextPart_000_01BEFDFF.485EFCA8--
-----------------------------------------------------------------------
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]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
From: Andras Varga <[email-masked]>
To: "'David Burdett'" <[email-masked]>, [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
Subject: changing the shipping address (was RE: more comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt)
Date: Mon, 13 Sep 1999 13:11:43 +0200
Importance: Normal
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David,
Thanks for your comments. I added some more details and problems we see...

> > Comment:
> > Authentication Exchange can be used to communicate trading 
> > role info between trading roles. For example, the Delivery 
> > Handler can authenticate the Consumer to obtain the shipping 
> > address. A potential problem is that Authentication is initiated 
> > by the Delivery Handler not the Consumer, so I believe 
> > currently there is no way for the 
> > Consumer to tell a changed shipping address to the Delivery Handler 
> > unless the Delivery Handler explicitly asks for it in an 
> > Authentication Reqeuest. Opinions?
> > ## This has been already discussed. See
> > http://www.elistx.com/archives/ietf-trade/199908/msg00035.html##
> 
> FYI, we figured out another way to request shipping to a 
> different address from the Delivery Handler (by means of a new critial 
> element). If someone is interested please write.
>
> && Yes. But changing the shipping address MUST be treated 
> with care as it can mean that the wrong tax is being collected. 
> For example in the US goods bought and shipped within the same 
> state must include sales tax. Goods that are shipped out of state 
> do not (although technically the purchases should report and 
> pay the tax due). So, if the Delivery Handler changes the address
> then it could result in the Merchant being liable for additional 
> tax that he has not received payment for.@@

Good point. According to our idea, the Delivery Hander would examine 
if the address change can be carried out without violating the original 
offer (i.e. the taxing and the shipping cost is the same, etc.). 
If the address change cannot be carried out (or the Delivery Handler
does not support/is not authorized to change the address), 
the Delivery Handler would send back a status with business error 
and an appropriate status description. The Consumer could then retry
the Delivery Request with another address or with keeping the original
address.

There are minor problems with this however. All Delivery Competion 
Codes [7.16.3] say that "Recovery is not possible.", so with the 
current IOTP implementation the Consumer could not retry.

Another problem is if the Delivery Handler does not recognize
the extension to the Delivery Request. Because the element is critical,
this is a technical [4.1] error and the Consumer cannot retry with
another, "plain" Delivery Request. 
OTOH if the extension is non-critical, the Consumer won't know
where the goods are going to be shipped eventually.

[I feel this a sign of a more general problem with extensions.
If the extension is critical it causes technical error and the 
transaction must fail, ie. the trading role sending the message
in error has no possibility to fix the problem by sending a
revised message. OTOH if the extension is non-critical, the 
sender trading role won't know whether the info carried in the
extensions was taken into account. But maybe I'm missing some
point. 
Probably this has been discussed before, so I apologize
for consuming the bandwidth.]

David, do you think this whole issue is important enough?

I apologize for consuming the bandwidth to those who are not 
interested...

Andras

-----------------------------------------------------------------------
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: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: more comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt
Date: Fri, 10 Sep 1999 08:23:53 -0700
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Andras

See a few minor comments below marked with @@

David

-----Original Message-----
From: Andras Varga [mailto:[email-masked]]
Sent: Friday, September 10, 1999 4:10 AM
To: [email-masked]
Subject: RE: more comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt

Please see comments inlined...

>  PaymtPending    Payment Pending. The payment is a longer process and
cannot
>                  be completed while the Consumer is online. (For example,
>                  Direct Debit or Bank Transfer is used for the payment
which
>                  takes several hours or days to complete.) 
>                  This is only valid if ProcessState is CompletedOk.
>                  No recovery possible.
> 
>  Paid            Payment finished successfully (as opposed to being
pending).
>                  This is only valid if ProcessState is CompletedOk.
>                  No recovery possible.
> ##IMOH I think this distinction, whilst technically correct, could be
> confusing to a Consumer. Once they've completed a Payment 
> Exchange, they will think, for all intents and purposes, that they've 
> "paid". A message that says "payment pending" could cause confusion 
> and they might think that something has gone wrong and the payment 
> perhaps won't work. I prefer to leave it as it is. OTOH, if the developer
> of a payment supplement wants to make the distinction then they can 
> include text in the StatusDesc attribute to distinguish between the two 
> states. Propose no change.## 

I accept.

----
> If the payment completion code is PaymtPending, it might be 
> useful NOT to return the PayReceipt component immediately in the 
> Payment Response Block. In this case, the Consumer could retrieve 
> the PayReceipt later with an Inquiry when the payment finished. I believe 
> this is not possible in the current version of IOTP. Opinions?
> ##Correct. It's not possible to do what you suggest in the 
> current version of IOTP. The behaviour you suggest also does not 
> represent what happens in the real world. For example, if you pay 
> by check you get a receipt at the time you hand over the check. 
> The fact the check might "bounce" is handled separately. I think it 
> is a good idea, at least initially, to mirror real world behaviour. 
> Propose no change.##

I accept this. Practice will show if any change is needed in IOTP.

> Again 7.16.2 Payment Completion Codes:
> IOTP> BadInstrument      Bad instrument. There is a problem with the
> IOTP>                    Payment Instrument being used which 
> IOTP>                    means that it is unable to be used for the
payment.
> 
> A potential error situation is that the payment amount is too small 
> (or too big) for the given brand/protocol. For example, credit cards 
> cannot be used for micropayments. Since this is not a problem with the
> Payment Instrument itself, I recommend the error description 
> be changed to: 
>   "The Payment Instrument cannot be used for the payment for 
>   some reason (e.g. the credit card is invalid, or payment amount is too 
>   small/too big for the Payment Instrument)."
> An alternative would be to introduce AmountTooLarge and AmountTooSmall
> error codes.
> ## You can use the ValueTooSmall and ValueTooLarge error 
> codes for this. The Error Description can be used to fine tune the 
> meaning.##

I accept that no change is required, with the comment that this is
rather a business error (recovery is possible) and it can be covered
by one of BadInstrument, InstNotValid or Unspecified.
@@ ... except that what *sane* Merchant would include credit cards in a
Brand List when the goods being purchased are for only a few pence. The
Merchant should know in advance that it wouldn't work. IMOH I think if this
problem occurs then it is an error in the way the Merchant has set up his
IOTP system.@@
----
> Comment:
> Authentication Exchange can be used to communicate trading role info 
> between trading roles. For example, the Delivery Handler can 
> authenticate the Consumer to obtain the shipping address. A potential 
> problem is that Authentication is initiated by the Delivery Handler 
> not the Consumer, so I believe currently there is no way for the 
> Consumer to tell a changed shipping address to the Delivery Handler 
> unless the Delivery Handler explicitly asks for it in an Authentication 
> Reqeuest. Opinions?
> ## This has been already discussed. See
> http://www.elistx.com/archives/ietf-trade/199908/msg00035.html##

FYI, we figured out another way to request shipping to a different address 
from the Delivery Handler (by means of a new critial element). If someone
is interested please write.
&& Yes. But changing the shipping address MUST be treated with care as it
can mean that the wrong tax is being collected. For example in the US goods
bought and shipped within the same state must include sales tax. Goods that
are shipped out of state do not (although technically the purchases should
report and pay the tax due). So, if the Delivery Handler changes the address
then it could result in the Merchant being liable for additional tax that he
has not received payment for.@@
Andras

------------------------------
Andras Varga

-----------------------------------------------------------------------
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]

Reply-To: [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
From: Andras Varga <[email-masked]>
To: [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
Subject: RE: more comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt
Date: Fri, 10 Sep 1999 13:10:17 +0200
Importance: Normal
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Please see comments inlined...

>  PaymtPending    Payment Pending. The payment is a longer process and cannot
>                  be completed while the Consumer is online. (For example,
>                  Direct Debit or Bank Transfer is used for the payment which
>                  takes several hours or days to complete.) 
>                  This is only valid if ProcessState is CompletedOk.
>                  No recovery possible.
> 
>  Paid            Payment finished successfully (as opposed to being pending).
>                  This is only valid if ProcessState is CompletedOk.
>                  No recovery possible.
> ##IMOH I think this distinction, whilst technically correct, could be
> confusing to a Consumer. Once they've completed a Payment 
> Exchange, they will think, for all intents and purposes, that they've 
> "paid". A message that says "payment pending" could cause confusion 
> and they might think that something has gone wrong and the payment 
> perhaps won't work. I prefer to leave it as it is. OTOH, if the developer
> of a payment supplement wants to make the distinction then they can 
> include text in the StatusDesc attribute to distinguish between the two 
> states. Propose no change.## 

I accept.

----
> If the payment completion code is PaymtPending, it might be 
> useful NOT to return the PayReceipt component immediately in the 
> Payment Response Block. In this case, the Consumer could retrieve 
> the PayReceipt later with an Inquiry when the payment finished. I believe 
> this is not possible in the current version of IOTP. Opinions?
> ##Correct. It's not possible to do what you suggest in the 
> current version of IOTP. The behaviour you suggest also does not 
> represent what happens in the real world. For example, if you pay 
> by check you get a receipt at the time you hand over the check. 
> The fact the check might "bounce" is handled separately. I think it 
> is a good idea, at least initially, to mirror real world behaviour. 
> Propose no change.##

I accept this. Practice will show if any change is needed in IOTP.

> Again 7.16.2 Payment Completion Codes:
> IOTP> BadInstrument      Bad instrument. There is a problem with the
> IOTP>                    Payment Instrument being used which 
> IOTP>                    means that it is unable to be used for the payment.
> 
> A potential error situation is that the payment amount is too small 
> (or too big) for the given brand/protocol. For example, credit cards 
> cannot be used for micropayments. Since this is not a problem with the
> Payment Instrument itself, I recommend the error description 
> be changed to: 
>   "The Payment Instrument cannot be used for the payment for 
>   some reason (e.g. the credit card is invalid, or payment amount is too 
>   small/too big for the Payment Instrument)."
> An alternative would be to introduce AmountTooLarge and AmountTooSmall
> error codes.
> ## You can use the ValueTooSmall and ValueTooLarge error 
> codes for this. The Error Description can be used to fine tune the 
> meaning.##

I accept that no change is required, with the comment that this is
rather a business error (recovery is possible) and it can be covered
by one of BadInstrument, InstNotValid or Unspecified.

----
> Comment:
> Authentication Exchange can be used to communicate trading role info 
> between trading roles. For example, the Delivery Handler can 
> authenticate the Consumer to obtain the shipping address. A potential 
> problem is that Authentication is initiated by the Delivery Handler 
> not the Consumer, so I believe currently there is no way for the 
> Consumer to tell a changed shipping address to the Delivery Handler 
> unless the Delivery Handler explicitly asks for it in an Authentication 
> Reqeuest. Opinions?
> ## This has been already discussed. See
> http://www.elistx.com/archives/ietf-trade/199908/msg00035.html##

FYI, we figured out another way to request shipping to a different address 
from the Delivery Handler (by means of a new critial element). If someone
is interested please write.

Andras

------------------------------
Andras Varga

-----------------------------------------------------------------------
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: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: more comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt
Date: Thu, 9 Sep 1999 11:27:29 -0700 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Andras

See comments marked with ##

David

-----Original Message-----
From: Andras Varga [mailto:[email-masked]]
Sent: Thursday, September 09, 1999 8:24 AM
To: [email-masked]
Subject: more comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt

Some comments to draft-ietf-trade-iotp-v1.0-protocol-05.txt:

----
>From 7.6.1.1 Organisation IDs:
IOTP> NonConsumerOrgId   If the Role is not Consumer then this contains the
IOTP>                    Canonical Name for the non-consumer organisation
IOTP>                    being described by the Organisation Component. See
IOTP>                    [DNS].
IOTP>
IOTP>                    Note that a NonConsumerOrgId may not start with
IOTP>                    the ConsumerOrgIdPrefix.
IOTP>
IOTP>                    Use of upper and lower case is not significant.

Occasionally it may happen that a Merchant does not have its own
domain name. For example, www.passage.hu offers e-commerce services
to merchants, so the URLs of the individual shops (merchants) are 
www.passage.hu/Caori, www.passage.hu/TicketExpress, etc. How should 
the NonConsumerOrgId be produced in such a case?
## Good point changed definition of NonConsumerOrgId as follows ...
"If the Role is not Consumer then this contains the Canonical Name for the
non-consumer Organisation being described by the Organisation Component. See
[DNS] optionally followed by additional characters, if required, to make the
NonConsumerOrgId unique"
##
----
Section 2.2.4 Authentication Exchange say that an Authentication Exchange
uses:
IOTP>  o A Trading Role Information Request Component that requests
information
IOTP>    about an Organisation, for example a ship to or billing address.

This is the only place where the words "billing address" occur in the
document.
I recommend it to be made more explicit that the billing address is the
Consumer role's postal address.
##Removed reference to "billing address"##
----
I suggest adding the following codes to 7.16.2 Payment Completion Codes:
 MerchNotSupp    The Merchant is not served by the Payment Handler.
                 No recovery possible.
##This is really an error caused by the merchant trying to use a Payment
handler that they should not or the Consumer sending the payment request to
the wrong URL. Therefore suggest handled by generating an error with an
error code of AttValNotRecog. The error description can say "The merchant is
not server by the Payment Handler". However this requires a minor change to
the defintion of AttValNotRecog by deleting the text ..." even though it
should have been able to. since the information had been provided in an
earlier IOTP message."##
 PaymtPending    Payment Pending. The payment is a longer process and cannot
                 be completed while the Consumer is online. (For example,
                 Direct Debit or Bank Transfer is used for the payment which

                 takes several hours or days to complete.) This is only
valid 
                 if ProcessState is CompletedOk.
                 No recovery possible.

 Paid            Payment finished successfully (as opposed to being
pending).
                 This is only valid if ProcessState is CompletedOk.
                 No recovery possible.
##IMOH I think this distinction, whilst technically correct, could be
confusing to a Consumer. Once they've completed a Payment Exchange, they
will think, for all intents and purposes, that they've "paid". A message
that says "payment pending" could cause confusion and they might think that
something has gone wrong and the payment perhaps won't work. I prefer to
leave it as it is. OTOH, if the developer of a payment supplement wants to
make the distinction then they can include text in the StatusDesc attribute
to distinguish between the two states. Propose no change.## 
----
If the payment completion code is PaymtPending, it might be useful NOT to
return the PayReceipt component immediately in the Payment Response Block.
In this case, the Consumer could retrieve the PayReceipt later with an
Inquiry 
when the payment finished. I believe this is not possible in the current
version of IOTP. Opinions?
##Correct. It's not possible to do what you suggest in the current version
of IOTP. The behaviour you suggest also does not represent what happens in
the real world. For example, if you pay by check you get a receipt at the
time you hand over the check. The fact the check might "bounce" is handled
separately. I think it is a good idea, at least initially, to mirror real
world behaviour. Propose no change.##
----
Again 7.16.2 Payment Completion Codes:
IOTP> BadInstrument      Bad instrument. There is a problem with the
IOTP>                    Payment Instrument being used which means that it
IOTP>                    is unable to be used for the payment.

A potential error situation is that the payment amount is too small 
(or too big) for the given brand/protocol. For example, credit cards 
cannot be used for micropayments. Since this is not a problem with the
Payment Instrument itself, I recommend the error description be changed to: 
  "The Payment Instrument cannot be used for the payment for some reason
  (e.g. the credit card is invalid, or payment amount is too small/too big 
  for the Payment Instrument)."
An alternative would be to introduce AmountTooLarge and AmountTooSmall
error codes.
## You can use the ValueTooSmall and ValueTooLarge error codes for this. The
Error Description can be used to fine tune the meaning.##
----
Comment:
Authentication Exchange can be used to communicate trading role info 
between trading roles. For example, the Delivery Handler can authenticate 
the Consumer to obtain the shipping address. A potential problem is that 
Authentication is initiated by the Delivery Handler not the Consumer, 
so I believe currently there is no way for the Consumer to tell a changed 
shipping address to the Delivery Handler unless the Delivery Handler 
explicitly asks for it in an Authentication Reqeuest. Opinions?
## This has been already discussed. See
http://www.elistx.com/archives/ietf-trade/199908/msg00035.html##
Regards,
Andras

-----------------------------------------------------------------------
Andras Varga [[email-masked]], Project Manager
MeTechnology Ltd. Hungary - a Brokat Company
-----------------------------------------------------------------------

-----------------------------------------------------------------------
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: David Burdett <[email-masked]>
To: "'Steve Schear'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: RE: Numeric currency codes
Date: Thu, 9 Sep 1999 10:41:50 -0700 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Steve

You ask ...

"How about the likelyhood that should digital cash systems become
operational that there will be multiple issuers of governmental units, with
a need to descriminate between them due to risks. There is also the
possibility that digital cash in non-governmental units might be issued."

If value in governmental units (e.g. dollars) are directly convertable from
one form to another, e.g. check, to notes to digital cash, then they should
have the same currency code since all you are altering is *how* you pay.

On the other hand if they are not directly convertible, e.g. loyalty points,
then you need to use a different currency code. IOTP already supports this
by specifying a CurrCodeType other than ISO4217-A as illustrated in the
defintion of the CurrencyAmount element below.

<!ELEMENT CurrencyAmount EMPTY >
<!ATTLIST CurrencyAmount
 ID                 ID      #REQUIRED
 Amount             CDATA   #REQUIRED
 CurrCodeType       NMTOKEN 'ISO4217-A'
 CurrCode           CDATA   #REQUIRED >

So, if a digital cash system wants to define their own currency they need to
define a CurrCodeType and register it with IANA.

Hope this helps.

David
PS Note new email address below ... I've moved from Mondex.

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

-----Original Message-----
From: Steve Schear [mailto:[email-masked]]
Sent: Thursday, September 09, 1999 9:14 AM
To: [email-masked]; [email-masked];
[email-masked]
Subject: Re: Numeric currency codes

At 03:40 AM 7/28/99 +0100, [email-masked] wrote:
>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?

How about the likelyhood that should digital cash systems become
operational that there will be multiple issuers of governmental units, with
a need to descriminate between them due to risks. There is also the
possibility that digital cash in non-governmental units might be issued.

--Steve
-----------------------------------------------------------------------
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: David Burdett <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "IOTP Trade List (E-mail)" <[email-masked]>
Subject: RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt
Date: Thu, 9 Sep 1999 10:31:45 -0700 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I never completely responded to this email so see comments marked below with
a ##.

David

-----Original Message-----
From: Rudolf Hornig [mailto:[email-masked]]
Sent: Wednesday, September 01, 1999 12:22 AM
To: IOTP Trade List (E-mail)
Cc: =?iso-8859-1?Q?Varga_Andr=E1s?=@metechnology.com
Subject: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt

Here comes some comments on the lates IOTP draft:

========================================================================
2.2.1 Offer Exchange
...
     C <-- M OFFER RESPONSE. Components: Organisation(s) (Consumer,
             DeliverTo, Merchant, Payment Handler, Customer Care); Order;
             Pay Amount; Delivery; Optional Offer Response Signature that
             signs other components

RH> "Pay Amount" should be "Paymnet".
RH> Status and TradingRoleData are missing, and also from the following
RH> list.
##Fixed##
========================================================================
2.2.2 Payment Exchange
...
     C --> M        Component: Brand List Selection

 4.                 Merchant checks Brand Selection, creates a Payment
                    Amount information, optionally signs it to authorise
                    payment and sends it to the Consumer

     C <-- M        Component: Pay Amount; Organisation(s) (Merchant and
                    Payment Handler); Optional Offer Response Signature
                    that signs other components

 5.                 Consumer checks the Payment Amount information and if
                    OK requests that the payment starts by sending
                    information to the Payment Handler

     C --------> P  PAYMENT REQUEST. Components: Pay Amount; Organisations
                    (Merchant and Payment Handler); Optional Offer
                    Response Signature that signs other components; Pay
                    Scheme

 6.                 Payment Handler checks information including optional
                    signature and if OK starts exchanging Pay Scheme
                    components for selected payment brand and payment
                    protocol

     C <-------> P  PAYMENT EXCHANGE. Component: Pay Scheme

 7.                 Eventually payment protocol messages finish so Payment
                    Handler sends Pay Receipt and optional signature to
                    the Consumer as proof of payment

     C <-------> P  PAYMENT RESPONSE. Components: Pay Receipt; Payment
                    Note; Optional Offer Response Signature; Optional
                    Payment Receipt Signature that binds the payment to
                    the Offer
RH> - in general: "Payment Amount" -> "Payment"
RH>               "Pay Scheme" -> "PaySchemeData"
RH> - in 5. There are missing components like: Status; BrandList;
RH>   BrandSelection; TradingRoleData
RH> - in 7. Missing components: Status; PaySchemeData; TradingRoleData;
RH> - These components are also missing from the list following Figure 3
##Fixed##
========================================================================
2.2.3 Delivery Exchange
...
     C --------> D  DELIVERY REQUEST. Components: Delivery, Organisations:
                    (Merchant, Delivery Handler, DelivTo); Order, Optional
                    Offer Response Signature, Optional Payment Receipt
                    Signature (from Payment Exchange)
RH> Missing: Status; ConsumerDeliveryData; TradingRoledData

 4.                 Delivery Handler checks information and authorisation.
                    Starts or schedules delivery and creates and then
                    sends a delivery not tot the Consumer which can
RH> sends a delivery NOTE TO the Consumer
...
     C <-------- D  DELIVERY RESPONSE. Components: Delivery Note, Optional
                    Delivery Response Signature
RH> Missing: Status
RH> These components are also missing from the list following Figure 4
##Fixed##
========================================================================
2.3 Scope of Baseline IOTP
RH> Because the Inquiry and Ping transactions could be initiated
RH> by any trading role, in the "supported Roles/Transaction table" 
RH> I would mention, that a Consumer should only be able to send
RH> Inquiry and Ping transaction. Serving these transactions is 
RH> not a requirement as the Consumer role is represented by an
RH> HTTP client (according to the http supplement)
##Changed MUST to MAY for consumer role##
========================================================================
3.3.1 Transaction Id Component
...
 IotpTransId        Contains data which uniquely identifies the IOTP
                    Transaction. It must conform to the rules for
                    Message Ids in [RFC 822].

RH> I'm not sure about this, but [RFC 822] defines the message id
RH> as: <some.string@shost>, however NMTOKEN doesn't allow a '@'
RH> character...
##Changed NMTOKEN to CDATA##
========================================================================
3.6.1 Extra XML Elements
...
 In order to ensure that documents containing "IOTP:Critical" are valid,
 it is declared as part of the DTD for the extra element as:

 IOTP:Critical     (True | False ) 'True'

RH> Haven't found it in the actual DTD.
RH> This means it SHOULD BE DECLARED as part of the extended DTD ?
##YES!##
========================================================================
4.5.2.3 Processing Non-Duplicate Message
...
 [Note]     This approach to handling of duplicate input messages means,
            if absolutely "identical" messages are received then
            absolutely "identical" messages are returned. This also
            applies to Inquiry and Ping transactions when in reality the
            state of a transaction or the processing ability of the
            servers may have changed. If up-to-date status of transactions
            or servers is required, then an IOTP transaction with a new
            IotpTransId must be used.                               ^^^ 
 [Note End]                  
RH> However in "9.2.1 Baseline Transaction Status Inquiry IOTP Transaction:"
...
 TRANSACTION REFERENCE BLOCK

 A Trading Role making an inquiry must use the identical Transaction Id
                                               ^^^^^^^^^
 Component (see section 3.3.1) that was in the original transaction. The
...

RH> The two requirements are inconsistent as far as I see.
RH> BTW. Is it really required for IOTP to cache all the Ping and
RH> Inquery transactions ??? (They do not change anything in the server)
RH> If idempotency is required, I would suggest using a new message ID
RH> with the same IotpTransId, but this case every trading role have
RH> to maintain it's last MessageID, which is not nice at all...
RH> Or perhaps changing the TimeStamp of the MessageID comp. is enough
RH> to force the server to give back fresh information ???? (ugly also)
RH> Maybe a trading role wants to inquery a 
RH> transaction a week later, and the last used message id for
RH> this transaction is not present... Any hint on this? 
##Resolved with other emails##
========================================================================
4.6.2.1 Check for Errors in Block Sequence
...
 o Offer Response Block. Check as follows:
   - if the Offer Response Block is not part of an IOTP Transaction that
     is recognised by the Consumer role then there is a Hard Error,
     otherwise
RH> During brand independent purchase without authentication,
RH> OfferResponse (with TPO) is the first message received by the 
RH> Consumer.
## Fixed by adding initial test that says ...
"- if the Offer Response Block is part of a Brand Independent Offer Exchange
(see section 9.1.2.2) then there is no sequence checking as it is part of
the first message received, otherwise "
##
========================================================================
7.11 Payment Receipt Component
...
 Note that either the *PayReceiptRefs* attribute, the PackagedContent
 element, or both must be present.
RH> change to: PayReceiptNameRefs attribute...
##Fixed##
========================================================================
9.1 Authentication and Payment Related IOTP Transactions
...
 o Brand Independent Offer. This is also an Offer Trading Exchange.
   However, in this instance, the content of the Offer Response does
   depend on the Brand selected.
RH> Change to: does not depend on the Brand selected.
##Fixed##
========================================================================
9.1.2.1 Brand Dependent Offer Document Exchange
...
 On receiving an Offer Response IOTP Message (see below) the Consumer may
 either:

 o generate and send the next IOTP Message in the IOTP transaction and
   send it to the required Trading Role. This is dependent on the IOTP
   Transaction, or
 o indicate failure to continue with the IOTP Transaction by sending a
   Cancel Block back to the Consumer containing a Status Component with a
                            ^^^^^^^^
   StatusType of Offer, a ProcessState of Failed and the CompletionCode
   (see section 7.16.4) set to either: ConsCancelled or Unspecified.
RH> Change to: Merchant
##Fixed##
========================================================================
9.1.4.3 Delivery Response IOTP Message
...
 The Delivery Response IOTP Message contains a Delivery Response Block
 and an options Signature Block.
        ^^^^^^^
RH> Change: optional
##Fixed##
========================================================================
11.1.1 Definition of Payment Instrument
...
 All Payment Instruments have a number, typically an account number, by
                         ^^^^^^^^^^^^^ 
 which the Payment Instrument can be identified.
RH> I'm not sure, but there are some payment protocols, which
RH> enable anonym payment (GeldKarte ???). Is this applys also
RH> for these instruments ???
## Changed All to Most##
========================================================================
Hope this helps a little, polishing the final version :)
Regards, Rudi

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rudolf Hornig ([email-masked]), Project Manager 
MeTechnology Ltd. Hungary - a Brokat Company
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-----------------------------------------------------------------------
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: "'Donald E. Eastlake 3rd'" <[email-masked]>, [email-masked]
Subject: RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt 
Date: Thu, 9 Sep 1999 09:33:46 -0700 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

See comments marked with &&

David

-----Original Message-----
From: Donald E. Eastlake 3rd [mailto:[email-masked]]
Sent: Tuesday, September 07, 1999 5:09 AM
To: [email-masked]
Subject: Re: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt 

From:  Rudolf Hornig <[email-masked]>
To:  "'David Burdett'" <[email-masked]>,
            "'Yoshiaki KAWATSURA'" <[email-masked]>
Cc:  [email-masked]
Date:  Mon, 6 Sep 1999 13:41:32 +0200
Message-ID:  <000101bef85c$c4be7b50$0a00000a@rudolf>
In-Reply-To:  <123B7EB05559D311B0D900A0C9EA3D7604F205@NEPTUNE>

>David and Yoshiakia,
>
>> ========================================================================
>> 4.5.2.3 Processing Non-Duplicate Message
>> ...
>... [Content deleted] ...
>
>I believe that idempotency is not required for Ping and Inquiry
>transaction. Additionaly I believe we do not need to use new
>IotpTransId , we use the same as the IotpTransId of a Purchase
>Transaction whenever Inquiry transaction is used.
>
>##The part of the spec that says in the Note ...
>>             ... then an IOTP transaction with a new IotpTransId must be
>used.
>... is wrong. It should read ...
>>             ... then an IOTP transaction with a new value for the ID
>attribute of the MsgId component must be used.
>
>I also agree that idempotency is not really required for inquiry and ping
>transactions. To my mind the question is, what is going to be simpler to
>implement? I think we have three possible approaches:
>1. Cache every transaction and have have the same approach to every
>transaction (this is what the spec says now), or
>2. Cache the messages we want to and not the others (i.e. don't cache ping
&
>inquiry), or
>3. Leave to an implementation decision, i.e. if you do send the identical
>message you might get the identical response back but then you might get an
>updated one.
>
>Option 1 could be simpler to implement in that you have a standard message
>content unware process that says "Have I received this before ... yes ...
so
>I'll resend the last message if its available". As long as inquiries and
>pings are relatively infrequent then the overhead in storage and processing
>should be relatively small.
>
>Option 2 would allow people to re-use inquiry requests (but why would you
>want to?) and would save on what you had to cache but would require that
the
>content of the message would have to be understood before idempotency
>processing could occu. FOr example it would require processing along the
>lines of "What kind of message is it? If it's a Ping or an Inquiry then
I'll
>process it afresh otherwise I'll resend the last message I sent if one is
>available."
>
>Option 3 would mean that if you really always wanted to be sure of getting
>up-to-date information then you would have to adopt approach 1 since
>behaviour of systems/servers in this area would not be predictable.
>
>Which approach do people prefer (or is there another one!) ?
>##
><RH>
>I would opt on #3, because:

I think consistency of behaviour is quite important.  Messages may get
duplicated not just because they are questions being asked again but
also because of tranmission path quirks.  Packets get duplicated,
messages that were queues can get re-sent, etc.  Even for long
messages where they won't fit into a packet, consider the SMTP
transport and email getting duplicated.  It is even possible for the
message to be duplicated and then the two responses, which could be
different due to a change in state, could be re-ordered...
	Since we need indempotency sometimes, I think #1 is simplest
behaviour by providing it all the time.

&& Agreed see other email&&

>- The resource requirement on doing inquiry and ping transactions
>  higly depends on the implementation and the actual usage of
>  the server. I can imagine scenarios where serving these transactions
>  cost a lot of resources: Using low quality network service (lots of 
>  retransmissions) with Pings requesting signature checking and Inquiries
>  not served locally rather routed to other Existing Payment Systems.
>  In this case Ping/Inquiry idempotency would be a benefit....
>  On the other hand if these transactions doesn't cost too much, but there
>  is a lot of them without too much retransmission, avoiding message 
>  idempotency on these transactions, could spare some computing time and a 
>  lot of database space.
>
>  I would let the implementor decide wheter or not to support msg 
>  idempotency, on this two transaction type. The role, which is sending the
>  ping/inquiry request should generate new msg id, if she wants up to date
>  information...
>
>  An additional question about the meaning of "identical":
><IOTP-DRAFT>
>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.
></IOTP-DRAFT>
>
>  I could imagine 3 definitions for the term "identical"
>  1. The message's IotpTransId and MsgId is the same as the previous.
>  2. The message's content is exactly the same (doing a hash on it
>     produces the same hash value as for the previous message)
>  3. As stated above, all blocks, components, elements, etc are the same...

There should be no difference between 2 and 3.

>  It is quite hard to implement the #3 case as we have to parse the whole
>  message and also the previous msg from the idempotency and compare
>  them on an element/element base. The problem is that not all the elements
>  have an ID attribute, which means that the two message cannot be 
>  compared easyly. For example the two messages are the same except
>  two PackagedContenet element in the same Component where their order
>  has changed... Ok, this is not a real life example I admit...:)
>  So doing an element/element comparation is not easyly implementable
>  and also quite resource consuming, because you have to parse both the
>  original and the newly received message before comparing...

DOM HASH is explicitly designed to make comparison easy.

>  Doing a hash or full comparation on the messages is OK, however I would
>  suggest that a message, with the same IotpTransId and MsgIg should be
>  treated as the same message regardless of their content. It is the
>  senders responsibility, not to alter anything in the message if she
>  uses the same Trans and Msg ID...
>  
></RH>

While I think that is reasonable, doing a hash is a pretty cheap operation
and enables you to compare the entire message quite easily.

&& This one is a close call to my mind. Firstly I'm not really comfortable
with the idea of just checking the IotpTransId and the MsgId as it could be
too easy for someone to guess just these items and therefore get a message
they were not authorised to get. On the other hand checking the whole
message without doing a DOM-hash or giving some hint on how to do it could
lead to inconsistent results. A compromise alternative might be to require
that the Trans Ref Block was the same since it includes additional
information (e.g. timestamp) that would be hard for someone to guess, but
then there could still be problems because of the way the comparison is
made. So as a compromise I will include the following as a note in section
4.5.2.2 Checking/Handling Duplicate Messages ...

 [Note] The recommended way of checking for identical messages is to check
for equal values of their [DOM-HASH]
 [Note End] 

Thanks,
Donald

>Regards, Rudolf
>
>PS: David, could you check also my original
>"Comments on draft-ietf-trade-iotp-v1.0-protocol-05" mail
>as you acknoledged only some of the comments...
>(They are mostly tipos however:)
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Rudolf Hornig ([email-masked]), Project Manager 
>MeTechnology Ltd. Hungary - a Brokat Company
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-----------------------------------------------------------------------
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: David Burdett <[email-masked]>
To: "'Yoshiaki KAWATSURA'" <[email-masked]>, [email-masked]
Subject: RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt 
Date: Thu, 9 Sep 1999 09:15:55 -0700 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Yoshiaki/Don/Rudolf.

See comments below marked with &&

David

-----Original Message-----
From: Yoshiaki KAWATSURA [mailto:[email-masked]]
Sent: Thursday, September 09, 1999 4:56 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt 

David,Don and Rudolf:
> >>
========================================================================
> >> 4.5.2.3 Processing Non-Duplicate Message
> >> ...
> >... [Content deleted] ...
> >
> >I believe that idempotency is not required for Ping and Inquiry
> >transaction. Additionaly I believe we do not need to use new
> >IotpTransId , we use the same as the IotpTransId of a Purchase
> >Transaction whenever Inquiry transaction is used.
> >
> >##The part of the spec that says in the Note ...
> >>             ... then an IOTP transaction with a new IotpTransId must be
> >used.
> >... is wrong. It should read ...
> >>             ... then an IOTP transaction with a new value for the ID
> >attribute of the MsgId component must be used.
> >
> >I also agree that idempotency is not really required for inquiry and ping
> >transactions. To my mind the question is, what is going to be simpler to
> >implement? I think we have three possible approaches:
> >1. Cache every transaction and have have the same approach to every
> >transaction (this is what the spec says now), or
> >2. Cache the messages we want to and not the others (i.e. don't cache
ping &
> >inquiry), or
> >3. Leave to an implementation decision, i.e. if you do send the identical
> >message you might get the identical response back but then you might get
an
> >updated one.
> >
> >Option 1 could be simpler to implement in that you have a standard
message
> >content unware process that says "Have I received this before ... yes ...
so
> >I'll resend the last message if its available". As long as inquiries and
> >pings are relatively infrequent then the overhead in storage and
processing
> >should be relatively small.
> >
> >Option 2 would allow people to re-use inquiry requests (but why would you
> >want to?) and would save on what you had to cache but would require that
the
> >content of the message would have to be understood before idempotency
> >processing could occu. FOr example it would require processing along the
> >lines of "What kind of message is it? If it's a Ping or an Inquiry then
I'll
> >process it afresh otherwise I'll resend the last message I sent if one is
> >available."
> >
> >Option 3 would mean that if you really always wanted to be sure of
getting
> >up-to-date information then you would have to adopt approach 1 since
> >behaviour of systems/servers in this area would not be predictable.
> >
> >Which approach do people prefer (or is there another one!) ?
> >##
> ><RH>
> >I would opt on #3, because:
> 
> I think consistency of behaviour is quite important.  Messages may get
> duplicated not just because they are questions being asked again but
> also because of tranmission path quirks.  Packets get duplicated,
> messages that were queues can get re-sent, etc.  Even for long
> messages where they won't fit into a packet, consider the SMTP
> transport and email getting duplicated.  It is even possible for the
> message to be duplicated and then the two responses, which could be
> different due to a change in state, could be re-ordered...
> 	Since we need indempotency sometimes, I think #1 is simplest
> behaviour by providing it all the time.
> 

I think #2 is best because the Consumer always should be able to 
get the current status in the ping and inquiry transaction.
I think there is no meaning if the consumer did not get the current
status.

&&On this point I agree with Don. I think option one is best because it's
consistent and completely independent of the content of the message. This
means that idempotency can be handled at the message "envelope" rather than
the message "content" level. I agree that it is pretty meaningless to get an
old status but there is a simple answer just use a different Message Id and
you will get the up-to-date picture. If the spec says that this is what you
need to do to get an up-to-date picture then it is simple to implement, I
would have thought, at application design time.

So I've added further clarification to the "Transaction Reference Block"
section within section 9.2.1 Baseline Transaction Status Inquiry IOTP
Transaction ...

If up-to-date status information is required then the MsgId Component, and
in particular the ID attribute for the MsgId Component must be different
from any other IOTP Message that has been sent by the Trading Role. This is
required because of the way that Idempotency is handled by IOTP (see section
4.5.2.2 Checking/Handling Duplicate Messages).
@@
----
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]
-----------------------------------------------------------------------
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, 09 Sep 1999 09:13:31 -0700
To: [email-masked], [email-masked], [email-masked]
From: Steve Schear <[email-masked]>
Subject: Re: Numeric currency codes
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

At 03:40 AM 7/28/99 +0100, [email-masked] wrote:
>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?

How about the likelyhood that should digital cash systems become
operational that there will be multiple issuers of governmental units, with
a need to descriminate between them due to risks. There is also the
possibility that digital cash in non-governmental units might be issued.

--Steve
-----------------------------------------------------------------------
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: "'Yoshiaki KAWATSURA'" <[email-masked]>, [email-masked]
Subject: RE: IOTP default namespace(Minor change request of IOTP DTD)
Date: Thu, 9 Sep 1999 08:53:34 -0700 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Agreed. Change made.

David

-----Original Message-----
From: Yoshiaki KAWATSURA [mailto:[email-masked]]
Sent: Tuesday, September 07, 1999 9:54 PM
To: [email-masked]
Cc: [email-masked]
Subject: IOTP default namespace(Minor change request of IOTP DTD)

David,

We should change the IOTP DTD of namespace attributes on IotpMesage 
from
<!ATTLIST IotpMessage
  xmlns:iotp     CDATA
   'ietf.org/draft-ietf-trade-iotp-v1.0-protocol-05' >

to
<!ATTLIST IotpMessage
  xmlns     CDATA
   'ietf.org/draft-ietf-trade-iotp-v1.0-protocol-05' > .

The xmlns:iotp is not default namespace.

----
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]
-----------------------------------------------------------------------
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]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
From: Andras Varga <[email-masked]>
To: [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
Subject: more comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt
Date: Thu, 9 Sep 1999 17:24:13 +0200
Importance: Normal
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Some comments to draft-ietf-trade-iotp-v1.0-protocol-05.txt:

----
>From 7.6.1.1 Organisation IDs:
IOTP> NonConsumerOrgId   If the Role is not Consumer then this contains the
IOTP>                    Canonical Name for the non-consumer organisation
IOTP>                    being described by the Organisation Component. See
IOTP>                    [DNS].
IOTP>
IOTP>                    Note that a NonConsumerOrgId may not start with
IOTP>                    the ConsumerOrgIdPrefix.
IOTP>
IOTP>                    Use of upper and lower case is not significant.

Occasionally it may happen that a Merchant does not have its own
domain name. For example, www.passage.hu offers e-commerce services
to merchants, so the URLs of the individual shops (merchants) are 
www.passage.hu/Caori, www.passage.hu/TicketExpress, etc. How should 
the NonConsumerOrgId be produced in such a case?
----
Section 2.2.4 Authentication Exchange say that an Authentication Exchange uses:
IOTP>  o A Trading Role Information Request Component that requests information
IOTP>    about an Organisation, for example a ship to or billing address.

This is the only place where the words "billing address" occur in the document.
I recommend it to be made more explicit that the billing address is the
Consumer role's postal address.
----
I suggest adding the following codes to 7.16.2 Payment Completion Codes:
 MerchNotSupp    The Merchant is not served by the Payment Handler.
                 No recovery possible.

 PaymtPending    Payment Pending. The payment is a longer process and cannot
                 be completed while the Consumer is online. (For example,
                 Direct Debit or Bank Transfer is used for the payment which 
                 takes several hours or days to complete.) This is only valid 
                 if ProcessState is CompletedOk.
                 No recovery possible.

 Paid            Payment finished successfully (as opposed to being pending).
                 This is only valid if ProcessState is CompletedOk.
                 No recovery possible.
----
If the payment completion code is PaymtPending, it might be useful NOT to
return the PayReceipt component immediately in the Payment Response Block.
In this case, the Consumer could retrieve the PayReceipt later with an Inquiry 
when the payment finished. I believe this is not possible in the current
version of IOTP. Opinions?
----
Again 7.16.2 Payment Completion Codes:
IOTP> BadInstrument      Bad instrument. There is a problem with the
IOTP>                    Payment Instrument being used which means that it
IOTP>                    is unable to be used for the payment.

A potential error situation is that the payment amount is too small 
(or too big) for the given brand/protocol. For example, credit cards 
cannot be used for micropayments. Since this is not a problem with the
Payment Instrument itself, I recommend the error description be changed to: 
  "The Payment Instrument cannot be used for the payment for some reason
  (e.g. the credit card is invalid, or payment amount is too small/too big 
  for the Payment Instrument)."
An alternative would be to introduce AmountTooLarge and AmountTooSmall
error codes.
----
Comment:
Authentication Exchange can be used to communicate trading role info 
between trading roles. For example, the Delivery Handler can authenticate 
the Consumer to obtain the shipping address. A potential problem is that 
Authentication is initiated by the Delivery Handler not the Consumer, 
so I believe currently there is no way for the Consumer to tell a changed 
shipping address to the Delivery Handler unless the Delivery Handler 
explicitly asks for it in an Authentication Reqeuest. Opinions?

Regards,
Andras

-----------------------------------------------------------------------
Andras Varga [[email-masked]], Project Manager
MeTechnology Ltd. Hungary - a Brokat Company
-----------------------------------------------------------------------

-----------------------------------------------------------------------
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: Re: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt 
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Thu, 09 Sep 1999 21:06:48 +0900 (JST)
Lines: 13
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Additionally, I think better the default is #1 but we should allow
 the request receiver sends the new(current) status for inquiry and ping
and this is a implementation dependent. The response does not guarantee 
its status is current one.

What do you think?
----
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]

To: [email-masked]
Cc: [email-masked]
Subject: Re: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt 
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Thu, 09 Sep 1999 20:55:38 +0900 (JST)
Lines: 73
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David,Don and Rudolf:
> >> ========================================================================
> >> 4.5.2.3 Processing Non-Duplicate Message
> >> ...
> >... [Content deleted] ...
> >
> >I believe that idempotency is not required for Ping and Inquiry
> >transaction. Additionaly I believe we do not need to use new
> >IotpTransId , we use the same as the IotpTransId of a Purchase
> >Transaction whenever Inquiry transaction is used.
> >
> >##The part of the spec that says in the Note ...
> >>             ... then an IOTP transaction with a new IotpTransId must be
> >used.
> >... is wrong. It should read ...
> >>             ... then an IOTP transaction with a new value for the ID
> >attribute of the MsgId component must be used.
> >
> >I also agree that idempotency is not really required for inquiry and ping
> >transactions. To my mind the question is, what is going to be simpler to
> >implement? I think we have three possible approaches:
> >1. Cache every transaction and have have the same approach to every
> >transaction (this is what the spec says now), or
> >2. Cache the messages we want to and not the others (i.e. don't cache ping &
> >inquiry), or
> >3. Leave to an implementation decision, i.e. if you do send the identical
> >message you might get the identical response back but then you might get an
> >updated one.
> >
> >Option 1 could be simpler to implement in that you have a standard message
> >content unware process that says "Have I received this before ... yes ... so
> >I'll resend the last message if its available". As long as inquiries and
> >pings are relatively infrequent then the overhead in storage and processing
> >should be relatively small.
> >
> >Option 2 would allow people to re-use inquiry requests (but why would you
> >want to?) and would save on what you had to cache but would require that the
> >content of the message would have to be understood before idempotency
> >processing could occu. FOr example it would require processing along the
> >lines of "What kind of message is it? If it's a Ping or an Inquiry then I'll
> >process it afresh otherwise I'll resend the last message I sent if one is
> >available."
> >
> >Option 3 would mean that if you really always wanted to be sure of getting
> >up-to-date information then you would have to adopt approach 1 since
> >behaviour of systems/servers in this area would not be predictable.
> >
> >Which approach do people prefer (or is there another one!) ?
> >##
> ><RH>
> >I would opt on #3, because:
> 
> I think consistency of behaviour is quite important.  Messages may get
> duplicated not just because they are questions being asked again but
> also because of tranmission path quirks.  Packets get duplicated,
> messages that were queues can get re-sent, etc.  Even for long
> messages where they won't fit into a packet, consider the SMTP
> transport and email getting duplicated.  It is even possible for the
> message to be duplicated and then the two responses, which could be
> different due to a change in state, could be re-ordered...
> 	Since we need indempotency sometimes, I think #1 is simplest
> behaviour by providing it all the time.
> 

I think #2 is best because the Consumer always should be able to 
get the current status in the ping and inquiry transaction.
I think there is no meaning if the consumer did not get the current
status.

----
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]

Date: Thu, 09 Sep 1999 10:05:05 +0200
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: Yoshiaki KAWATSURA <[email-masked]>, [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: Advancing IOTP-protocol, DSIG, and DOMHASH to Informational
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

--On tor 9 sep 1999 14.38 +0900 Yoshiaki KAWATSURA
<[email-masked]> wrote:

> All of my comment is requests for clarification of the
> draft, there is no technical change request and he mentioned some
> points will be clarified sooner.

If _any_ character in the draft is to be changed, I urge you to do so now,
before the last call.

Donald, this is your call. Do you still want a last call?

   Patrik Faltstrom
   Area Director, Application Area

-----------------------------------------------------------------------
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: Advancing IOTP-protocol, DSIG, and DOMHASH to Informational
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Thu, 09 Sep 1999 14:38:58 +0900 (JST)
Lines: 32
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

> Although there is still some discussion of minor details in the
> iotp-v1.0-protocol-05 draft, there is a consensus to submit the IOTP
> v1 protocol to the IESG for Informational along with the companion
> IOTP DSIG draft.  Since DSIG uses DOM HASH, that will need to be
> advanced as well.  There have been no recent comments on the DOM HASH
> draft.  I think that the level of changes being suggested for the
> protocol draft can be handled in parallel with IESG consideration
> (including IETF last call if the IESG thinks that is called for)
> although, of course, the our AD might have a different .  So, I have
> requested their advancement.
> 
> The exact drafts in question are
> 
> draft-ietf-trade-iotp-v1.0-protocol-05.txt
> draft-ietf-trade-iotp-v1.0-dsig-02.txt
> draft-ietf-trade-hiroshi-dom-hash-02.txt

Sounds good.

I have some comment for DOMHASH to Kent Tamura-san, one of the author
of DOMHASH. All of my comment is requests for clarification of the
draft, there is no technical change request and he mentioned some
points will be clarified sooner.

----
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]

To: [email-masked]
Subject: Advancing IOTP-protocol, DSIG, and DOMHASH to Informational
Date: Thu, 09 Sep 1999 00:45:52 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Although there is still some discussion of minor details in the
iotp-v1.0-protocol-05 draft, there is a consensus to submit the IOTP
v1 protocol to the IESG for Informational along with the companion
IOTP DSIG draft.  Since DSIG uses DOM HASH, that will need to be
advanced as well.  There have been no recent comments on the DOM HASH
draft.  I think that the level of changes being suggested for the
protocol draft can be handled in parallel with IESG consideration
(including IETF last call if the IESG thinks that is called for)
although, of course, the our AD might have a different .  So, I have
requested their advancement.

The exact drafts in question are

draft-ietf-trade-iotp-v1.0-protocol-05.txt
draft-ietf-trade-iotp-v1.0-dsig-02.txt
draft-ietf-trade-hiroshi-dom-hash-02.txt

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]
Subject: IOTP default namespace(Minor change request of IOTP DTD)
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Wed, 08 Sep 1999 13:53:47 +0900 (JST)
Lines: 21
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David,

We should change the IOTP DTD of namespace attributes on IotpMesage 
from
<!ATTLIST IotpMessage
  xmlns:iotp     CDATA
   'ietf.org/draft-ietf-trade-iotp-v1.0-protocol-05' >

to
<!ATTLIST IotpMessage
  xmlns     CDATA
   'ietf.org/draft-ietf-trade-iotp-v1.0-protocol-05' > .

The xmlns:iotp is not default namespace.

----
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]

To: [email-masked]
Subject: Re: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt 
Date: Tue, 07 Sep 1999 08:09:12 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

From:  Rudolf Hornig <[email-masked]>
To:  "'David Burdett'" <[email-masked]>,
            "'Yoshiaki KAWATSURA'" <[email-masked]>
Cc:  [email-masked]
Date:  Mon, 6 Sep 1999 13:41:32 +0200
Message-ID:  <000101bef85c$c4be7b50$0a00000a@rudolf>
In-Reply-To:  <123B7EB05559D311B0D900A0C9EA3D7604F205@NEPTUNE>

>David and Yoshiakia,
>
>> ========================================================================
>> 4.5.2.3 Processing Non-Duplicate Message
>> ...
>... [Content deleted] ...
>
>I believe that idempotency is not required for Ping and Inquiry
>transaction. Additionaly I believe we do not need to use new
>IotpTransId , we use the same as the IotpTransId of a Purchase
>Transaction whenever Inquiry transaction is used.
>
>##The part of the spec that says in the Note ...
>>             ... then an IOTP transaction with a new IotpTransId must be
>used.
>... is wrong. It should read ...
>>             ... then an IOTP transaction with a new value for the ID
>attribute of the MsgId component must be used.
>
>I also agree that idempotency is not really required for inquiry and ping
>transactions. To my mind the question is, what is going to be simpler to
>implement? I think we have three possible approaches:
>1. Cache every transaction and have have the same approach to every
>transaction (this is what the spec says now), or
>2. Cache the messages we want to and not the others (i.e. don't cache ping &
>inquiry), or
>3. Leave to an implementation decision, i.e. if you do send the identical
>message you might get the identical response back but then you might get an
>updated one.
>
>Option 1 could be simpler to implement in that you have a standard message
>content unware process that says "Have I received this before ... yes ... so
>I'll resend the last message if its available". As long as inquiries and
>pings are relatively infrequent then the overhead in storage and processing
>should be relatively small.
>
>Option 2 would allow people to re-use inquiry requests (but why would you
>want to?) and would save on what you had to cache but would require that the
>content of the message would have to be understood before idempotency
>processing could occu. FOr example it would require processing along the
>lines of "What kind of message is it? If it's a Ping or an Inquiry then I'll
>process it afresh otherwise I'll resend the last message I sent if one is
>available."
>
>Option 3 would mean that if you really always wanted to be sure of getting
>up-to-date information then you would have to adopt approach 1 since
>behaviour of systems/servers in this area would not be predictable.
>
>Which approach do people prefer (or is there another one!) ?
>##
><RH>
>I would opt on #3, because:

I think consistency of behaviour is quite important.  Messages may get
duplicated not just because they are questions being asked again but
also because of tranmission path quirks.  Packets get duplicated,
messages that were queues can get re-sent, etc.  Even for long
messages where they won't fit into a packet, consider the SMTP
transport and email getting duplicated.  It is even possible for the
message to be duplicated and then the two responses, which could be
different due to a change in state, could be re-ordered...
	Since we need indempotency sometimes, I think #1 is simplest
behaviour by providing it all the time.

>- The resource requirement on doing inquiry and ping transactions
>  higly depends on the implementation and the actual usage of
>  the server. I can imagine scenarios where serving these transactions
>  cost a lot of resources: Using low quality network service (lots of 
>  retransmissions) with Pings requesting signature checking and Inquiries
>  not served locally rather routed to other Existing Payment Systems.
>  In this case Ping/Inquiry idempotency would be a benefit....
>  On the other hand if these transactions doesn't cost too much, but there
>  is a lot of them without too much retransmission, avoiding message 
>  idempotency on these transactions, could spare some computing time and a 
>  lot of database space.
>
>  I would let the implementor decide wheter or not to support msg 
>  idempotency, on this two transaction type. The role, which is sending the
>  ping/inquiry request should generate new msg id, if she wants up to date
>  information...
>
>  An additional question about the meaning of "identical":
><IOTP-DRAFT>
>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.
></IOTP-DRAFT>
>
>  I could imagine 3 definitions for the term "identical"
>  1. The message's IotpTransId and MsgId is the same as the previous.
>  2. The message's content is exactly the same (doing a hash on it
>     produces the same hash value as for the previous message)
>  3. As stated above, all blocks, components, elements, etc are the same...

There should be no difference between 2 and 3.

>  It is quite hard to implement the #3 case as we have to parse the whole
>  message and also the previous msg from the idempotency and compare
>  them on an element/element base. The problem is that not all the elements
>  have an ID attribute, which means that the two message cannot be 
>  compared easyly. For example the two messages are the same except
>  two PackagedContenet element in the same Component where their order
>  has changed... Ok, this is not a real life example I admit...:)
>  So doing an element/element comparation is not easyly implementable
>  and also quite resource consuming, because you have to parse both the
>  original and the newly received message before comparing...

DOM HASH is explicitly designed to make comparison easy.

>  Doing a hash or full comparation on the messages is OK, however I would
>  suggest that a message, with the same IotpTransId and MsgIg should be
>  treated as the same message regardless of their content. It is the
>  senders responsibility, not to alter anything in the message if she
>  uses the same Trans and Msg ID...
>  
></RH>

While I think that is reasonable, doing a hash is a pretty cheap operation
and enables you to compare the entire message quite easily.

Thanks,
Donald

>Regards, Rudolf
>
>PS: David, could you check also my original
>"Comments on draft-ietf-trade-iotp-v1.0-protocol-05" mail
>as you acknoledged only some of the comments...
>(They are mostly tipos however:)
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Rudolf Hornig ([email-masked]), Project Manager 
>MeTechnology Ltd. Hungary - a Brokat Company
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-----------------------------------------------------------------------
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: "'IOTP Trade List (E-mail)'" <[email-masked]>
Subject: Re: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt Part 2 
Date: Tue, 07 Sep 1999 07:53:43 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

From:  Rudolf Hornig <[email-masked]>
To:  "'David Burdett'" <[email-masked]>,
            "'IOTP Trade List (E-mail)'" <[email-masked]>
Date:  Mon, 6 Sep 1999 10:50:59 +0200
Message-ID:  <000001bef844$f1ba1000$0a00000a@rudolf>
In-Reply-To:  <123B7EB05559D311B0D900A0C9EA3D7604F206@NEPTUNE>

>Hello David,
>
>> ====================================================================
>> 7.6.1.1 Organisation IDs
>> RH> ComsumerOrgId is case sensitive however NonConsumerOrgId is
>> RH> case insensitive. This may cause confusion... and in this 
>> RH> case the third example should be:
>> RH> "Consumer:1000247ABH/newjerseybooks.com"
>> RH> starting with a capital letter...
>> ##Propose making ConsumerOrgId case insensitive. Do you agree?##
>RH> That's the best solution...  I agree 100%.
>
>> ====================================================================
>> RH> ErrorLogNetLocn is mandatory for non consumer roles.
>> RH> Because there are no mechanisms defined for authenication
>> RH> on this channel and it is not secured, this type
>> RH> of logging may introduce security holes. (maybe the
>> RH> error component, the Consumer is sending, contains also
>> RH> some previous XML message, which contains sensitive information)
>> ## There shouldn't be a security hole of this type since the 
>> content of
>> earlier messages is never included when reporting an error. 
>> At most you
>> might include just the element or attribute value that was in error.##
>RH> Ok I agree, but even the TransID component could contain sensitive
>RH> information. For example to authorise and inquiry transaction.
>RH> (IotpTransId and TransTimeStamp)

Suggest including a comment about this where ErrorNetLogLocn is
defined or in the Security Considerations section.  The
ErrorNetLogLocn can be an "https:" URL for more security.

>> RH> Because all the error components should be sent back to the
>> RH> counterparty, I would suggest to let the server roles implement
>> RH> their own logging facility. Or I would make the ErrorLogNetLocn
>> RH> optional... Hints on this ???
>> ##Disagree. When we discussed this we thought it would be 
>> simpler to always
>> include it and leave it to each implementation to decide what 
>> they do with
>> error messages when they receive them. They could just ignore them.##
>This solution is OK.
>
>> ====================================================================
>> RH> About DTD in general:
>> RH> PackagedContent, ContactInfo, PersonName, PostalAddress,
>> RH> ProtocolBrand, DeliveryData, ErrorLocation, Manifest,
>> RH> Digest, Attribute, OriginatorInfo, RecipientInfo,
>> RH> Parameter, IssuerAndSerialNumber and Locator Elements
>> RH> doesn't have ID attribute. As even for IOTP extensions
>> RH> it is a requirement to have ID attribute, it would be nice
>> RH> to have also on all element in IOTP DTD.
>> ## I don't have a really stron view on this. Putting in ID's 
>> could make
>> error reporting simpler since you can specifically identify 
>> the instance of
>> an element that was on error. On the other hand this is a fairly major
>> change at this stage and I'm not sure it would be worth it. 
>> What do others
>> thing?##

>RH> The idea behind my suggestion was to have some common way to
>RH> identify an element/component/block etc. which could be used
>RH> the same way during error reporting, signing the elements and
>RH> would make, for example an IOTP Message Parser/Generator's 
>RH> implementation much more clear. In this case we could have
>RH> a common way to identify all elements in an IotpMessage.
>RH> On the other hand I 100% agree with you not to diturb the
>RH> draft if it doesn't worth...

I tend to favor allowing optional IDs...

>> ...
>> RH> The digital signature part is not consistent regarding
>> RH> capitalisation in attribuite naming.
>> ## This is because its following the conventions in the IOTP 
>> dsig spec. One
>> thought going through my mind is whether or not to include 
>> (by copying) the
>> dsig DTD into the IOTP DTD. You could just leave it separate and use
>> namespaces to identify which each belonged to. But then do we want to
>> introduce the requirement that namespaces are used at this 
>> late stage when
>> you don't really need them. Thoughts everyone?##
>RH> I think copying the DTD is ok. I wouldn't introduce namespaces
>RH> if it could be avoided...

Agree.

Donald

>Rudi
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Rudolf Hornig ([email-masked]), Project Manager 
>MeTechnology Ltd. Hungary - a Brokat Company
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

-----------------------------------------------------------------------
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: IETF-Announce: ;
Cc: [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-trade-hiroshi-dom-hash-02.txt
Date: Tue, 07 Sep 1999 07:13:01 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF.

	Title		: Digest Values for DOM (DOMHASH)
	Author(s)	: H. Maruyama, K. Tamura, N. Uramoto
	Filename	: draft-ietf-trade-hiroshi-dom-hash-02.txt
	Pages		: 11
	Date		: 03-Sep-99
	
This internet draft defines a clear and unambiguous definition of
digest (hash) values of the XML objects regardless of the surface
string variation of XML. This definition can be used for XML digital
signature as well efficient replication of XML objects.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trade-hiroshi-dom-hash-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-trade-hiroshi-dom-hash-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-trade-hiroshi-dom-hash-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-trade-hiroshi-dom-hash-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-trade-hiroshi-dom-hash-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

-----------------------------------------------------------------------
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]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
From: Rudolf Hornig <[email-masked]>
To: "'David Burdett'" <[email-masked]>, "'Yoshiaki KAWATSURA'" <[email-masked]>
Cc: [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
Subject: RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt
Date: Mon, 6 Sep 1999 13:41:32 +0200
Importance: Normal
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David and Yoshiakia,

> ========================================================================
> 4.5.2.3 Processing Non-Duplicate Message
> ...
... [Content deleted] ...

I believe that idempotency is not required for Ping and Inquiry
transaction. Additionaly I believe we do not need to use new
IotpTransId , we use the same as the IotpTransId of a Purchase
Transaction whenever Inquiry transaction is used.

##The part of the spec that says in the Note ...
>             ... then an IOTP transaction with a new IotpTransId must be
used.
... is wrong. It should read ...
>             ... then an IOTP transaction with a new value for the ID
attribute of the MsgId component must be used.

I also agree that idempotency is not really required for inquiry and ping
transactions. To my mind the question is, what is going to be simpler to
implement? I think we have three possible approaches:
1. Cache every transaction and have have the same approach to every
transaction (this is what the spec says now), or
2. Cache the messages we want to and not the others (i.e. don't cache ping &
inquiry), or
3. Leave to an implementation decision, i.e. if you do send the identical
message you might get the identical response back but then you might get an
updated one.

Option 1 could be simpler to implement in that you have a standard message
content unware process that says "Have I received this before ... yes ... so
I'll resend the last message if its available". As long as inquiries and
pings are relatively infrequent then the overhead in storage and processing
should be relatively small.

Option 2 would allow people to re-use inquiry requests (but why would you
want to?) and would save on what you had to cache but would require that the
content of the message would have to be understood before idempotency
processing could occu. FOr example it would require processing along the
lines of "What kind of message is it? If it's a Ping or an Inquiry then I'll
process it afresh otherwise I'll resend the last message I sent if one is
available."

Option 3 would mean that if you really always wanted to be sure of getting
up-to-date information then you would have to adopt approach 1 since
behaviour of systems/servers in this area would not be predictable.

Which approach do people prefer (or is there another one!) ?
##
<RH>
I would opt on #3, because:
- The resource requirement on doing inquiry and ping transactions
  higly depends on the implementation and the actual usage of
  the server. I can imagine scenarios where serving these transactions
  cost a lot of resources: Using low quality network service (lots of 
  retransmissions) with Pings requesting signature checking and Inquiries
  not served locally rather routed to other Existing Payment Systems.
  In this case Ping/Inquiry idempotency would be a benefit....
  On the other hand if these transactions doesn't cost too much, but there
  is a lot of them without too much retransmission, avoiding message 
  idempotency on these transactions, could spare some computing time and a 
  lot of database space.

  I would let the implementor decide wheter or not to support msg 
  idempotency, on this two transaction type. The role, which is sending the
  ping/inquiry request should generate new msg id, if she wants up to date
  information...

  An additional question about the meaning of "identical":
<IOTP-DRAFT>
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.
</IOTP-DRAFT>

  I could imagine 3 definitions for the term "identical"
  1. The message's IotpTransId and MsgId is the same as the previous.
  2. The message's content is exactly the same (doing a hash on it
     produces the same hash value as for the previous message)
  3. As stated above, all blocks, components, elements, etc are the same...

  It is quite hard to implement the #3 case as we have to parse the whole
  message and also the previous msg from the idempotency and compare
  them on an element/element base. The problem is that not all the elements
  have an ID attribute, which means that the two message cannot be 
  compared easyly. For example the two messages are the same except
  two PackagedContenet element in the same Component where their order
  has changed... Ok, this is not a real life example I admit...:)
  So doing an element/element comparation is not easyly implementable
  and also quite resource consuming, because you have to parse both the
  original and the newly received message before comparing...

  Doing a hash or full comparation on the messages is OK, however I would
  suggest that a message, with the same IotpTransId and MsgIg should be
  treated as the same message regardless of their content. It is the
  senders responsibility, not to alter anything in the message if she
  uses the same Trans and Msg ID...
  
</RH>

Regards, Rudolf

PS: David, could you check also my original
"Comments on draft-ietf-trade-iotp-v1.0-protocol-05" mail
as you acknoledged only some of the comments...
(They are mostly tipos however:)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rudolf Hornig ([email-masked]), Project Manager 
MeTechnology Ltd. Hungary - a Brokat Company
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

-----------------------------------------------------------------------
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]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
From: Rudolf Hornig <[email-masked]>
To: "'David Burdett'" <[email-masked]>, "'IOTP Trade List (E-mail)'" <[email-masked]>
Subject: RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt Part 2
Date: Mon, 6 Sep 1999 10:50:59 +0200
Importance: Normal
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Hello David,

> ====================================================================
> 7.6.1.1 Organisation IDs
> RH> ComsumerOrgId is case sensitive however NonConsumerOrgId is
> RH> case insensitive. This may cause confusion... and in this 
> RH> case the third example should be:
> RH> "Consumer:1000247ABH/newjerseybooks.com"
> RH> starting with a capital letter...
> ##Propose making ConsumerOrgId case insensitive. Do you agree?##
RH> That's the best solution...  I agree 100%.

> ====================================================================
> RH> ErrorLogNetLocn is mandatory for non consumer roles.
> RH> Because there are no mechanisms defined for authenication
> RH> on this channel and it is not secured, this type
> RH> of logging may introduce security holes. (maybe the
> RH> error component, the Consumer is sending, contains also
> RH> some previous XML message, which contains sensitive information)
> ## There shouldn't be a security hole of this type since the 
> content of
> earlier messages is never included when reporting an error. 
> At most you
> might include just the element or attribute value that was in error.##
RH> Ok I agree, but even the TransID component could contain sensitive
RH> information. For example to authorise and inquiry transaction.
RH> (IotpTransId and TransTimeStamp)

> RH> Because all the error components should be sent back to the
> RH> counterparty, I would suggest to let the server roles implement
> RH> their own logging facility. Or I would make the ErrorLogNetLocn
> RH> optional... Hints on this ???
> ##Disagree. When we discussed this we thought it would be 
> simpler to always
> include it and leave it to each implementation to decide what 
> they do with
> error messages when they receive them. They could just ignore them.##
This solution is OK.

> ====================================================================
> RH> About DTD in general:
> RH> PackagedContent, ContactInfo, PersonName, PostalAddress,
> RH> ProtocolBrand, DeliveryData, ErrorLocation, Manifest,
> RH> Digest, Attribute, OriginatorInfo, RecipientInfo,
> RH> Parameter, IssuerAndSerialNumber and Locator Elements
> RH> doesn't have ID attribute. As even for IOTP extensions
> RH> it is a requirement to have ID attribute, it would be nice
> RH> to have also on all element in IOTP DTD.
> ## I don't have a really stron view on this. Putting in ID's 
> could make
> error reporting simpler since you can specifically identify 
> the instance of
> an element that was on error. On the other hand this is a fairly major
> change at this stage and I'm not sure it would be worth it. 
> What do others
> thing?##

RH> The idea behind my suggestion was to have some common way to
RH> identify an element/component/block etc. which could be used
RH> the same way during error reporting, signing the elements and
RH> would make, for example an IOTP Message Parser/Generator's 
RH> implementation much more clear. In this case we could have
RH> a common way to identify all elements in an IotpMessage.
RH> On the other hand I 100% agree with you not to diturb the
RH> draft if it doesn't worth...

> ...
> RH> The digital signature part is not consistent regarding
> RH> capitalisation in attribuite naming.
> ## This is because its following the conventions in the IOTP 
> dsig spec. One
> thought going through my mind is whether or not to include 
> (by copying) the
> dsig DTD into the IOTP DTD. You could just leave it separate and use
> namespaces to identify which each belonged to. But then do we want to
> introduce the requirement that namespaces are used at this 
> late stage when
> you don't really need them. Thoughts everyone?##
RH> I think copying the DTD is ok. I wouldn't introduce namespaces
RH> if it could be avoided...

Rudi
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rudolf Hornig ([email-masked]), Project Manager 
MeTechnology Ltd. Hungary - a Brokat Company
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

-----------------------------------------------------------------------
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: -hiroshi-dom-hash-02
Date: Fri, 03 Sep 1999 14:33:24 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

IOTP v1.0 DSIG needs a stable documentation of DOMHASH to reference
so the DOMHASH draft is being moved into the TRADE WG with the
intent that it also be issued as an Infomrational RFC.  The revised
DOMHASH draft should be posted Tuesday.

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]

From: David Burdett <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "IOTP Trade List (E-mail)" <[email-masked]>
Subject: RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt Part 2
Date: Fri, 3 Sep 1999 09:25:01 -0700 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Rudolf

Thanks for your comments I've responded below marked with ##. Some of your
comments could benefit from more discussion.

I really appreciate you reporting these errors. They are helping to polish
the spec.

David

-----Original Message-----
From: Rudolf Hornig [mailto:[email-masked]]
Sent: Thursday, September 02, 1999 8:11 AM
To: IOTP Trade List (E-mail)
Subject: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt Part 2

Again some additional comments on IOTP draft,

====================================================================
7.4 Trading Role Information Request Component

 <!ELEMENT TradingRoleInfoReq EMPTY>
 <!ATTLIST TradingRoleInfoReq
  ID                 ID      #REQUIRED
  TradingRoleList    NMTOKENS #REQUIRED >
                     ^^^^^^^^       
RH> Please correct the separate DTD file according to this
RH> definition.
##Fixed in DTD##
====================================================================
7.6.1.1 Organisation IDs
RH> ComsumerOrgId is case sensitive however NonConsumerOrgId is
RH> case insensitive. This may cause confusion... and in this 
RH> case the third example should be:
RH> "Consumer:1000247ABH/newjerseybooks.com"
RH> starting with a capital letter...
##Propose making ConsumerOrgId case insensitive. Do you agree?##
====================================================================
7.6.2 Trading Role Element
RH> CancelNetLocn and ErrorNetLocn are IMPLIED according
RH> to the separate DTD file.
## Fixed in spec##
...
RH> ErrorLogNetLocn is mandatory for non consumer roles.
RH> Because there are no mechanisms defined for authenication
RH> on this channel and it is not secured, this type
RH> of logging may introduce security holes. (maybe the
RH> error component, the Consumer is sending, contains also
RH> some previous XML message, which contains sensitive information)
## There shouldn't be a security hole of this type since the content of
earlier messages is never included when reporting an error. At most you
might include just the element or attribute value that was in error.##
RH> Because all the error components should be sent back to the
RH> counterparty, I would suggest to let the server roles implement
RH> their own logging facility. Or I would make the ErrorLogNetLocn
RH> optional... Hints on this ???
##Disagree. When we discussed this we thought it would be simpler to always
include it and leave it to each implementation to decide what they do with
error messages when they receive them. They could just ignore them.##
====================================================================
RH> About DTD in general:
RH> PackagedContent, ContactInfo, PersonName, PostalAddress,
RH> ProtocolBrand, DeliveryData, ErrorLocation, Manifest,
RH> Digest, Attribute, OriginatorInfo, RecipientInfo,
RH> Parameter, IssuerAndSerialNumber and Locator Elements
RH> doesn't have ID attribute. As even for IOTP extensions
RH> it is a requirement to have ID attribute, it would be nice
RH> to have also on all element in IOTP DTD.
## I don't have a really stron view on this. Putting in ID's could make
error reporting simpler since you can specifically identify the instance of
an element that was on error. On the other hand this is a fairly major
change at this stage and I'm not sure it would be worth it. What do others
thing?##
...
RH> The digital signature part is not consistent regarding
RH> capitalisation in attribuite naming.
## This is because its following the conventions in the IOTP dsig spec. One
thought going through my mind is whether or not to include (by copying) the
dsig DTD into the IOTP DTD. You could just leave it separate and use
namespaces to identify which each belonged to. But then do we want to
introduce the requirement that namespaces are used at this late stage when
you don't really need them. Thoughts everyone?##
====================================================================
7.9 Payment Component
RH> As it contains element references, I would suggest to change
RH> from StartAfter to StartAfterRefs just to be consistent
RH> in naming...
##Changed##
====================================================================
7.13.1 Delivery Data Element
...
 <!ATTLIST DeliveryData
  xml:lang           NMTOKEN #IMPLIED
  OkFrom             CDATA   #REQUIRED
  OkTo               CDATA   #REQUIRED
  DelivMethod        NMTOKEN #REQUIRED
  DelivToRef         NMTOKEN #REQUIRED
  DelivReqNetLocn    CDATA   #REQUIRED
  SecDelivReqNetLocn CDATA   #REQUIRED
  ContentSoftwareId  CDATA   #IMPLIED >
RH> DelivReqNetLocn and SecDelivReqNetLocn should be IMPLIED as
RH> only one of them is mandatory
##Absolutely correct! Change made.##

Thanks again for your comments !
Rudi
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rudolf Hornig ([email-masked]), Project Manager 
MeTechnology Ltd. Hungary - a Brokat Company
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

-----------------------------------------------------------------------
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: David Burdett <[email-masked]>
To: "'Yoshiaki KAWATSURA'" <[email-masked]>, [email-masked]
Cc: [email-masked], =?iso-8859-1?Q?VargaAndr=[email-masked]?=
Subject: RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt
Date: Fri, 3 Sep 1999 08:52:46 -0700 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Yoshiakia/Rudolf

Agree with your comments but think we need more discusion around idempotency
... see below.

David

-----Original Message-----
From: Yoshiaki KAWATSURA [mailto:[email-masked]]
Sent: Wednesday, September 01, 1999 1:10 AM
To: [email-masked]
Cc: [email-masked];
=?iso-8859-1?Q?VargaAndr=[email-masked]?=;
[email-masked]
Subject: Re: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt

Rudolf,
My comments are below.

>>>>> Wed, 1 Sep 1999 09:22:17 +0200,
	Rudolf Hornig <[email-masked]> said:

> ========================================================================
> 3.3.1 Transaction Id Component
> ...
>  IotpTransId        Contains data which uniquely identifies the IOTP
>                     Transaction. It must conform to the rules for
>                     Message Ids in [RFC 822].
> 
> RH> I'm not sure about this, but [RFC 822] defines the message id
> RH> as: <some.string@shost>, however NMTOKEN doesn't allow a '@'
> RH> character...
> ========================================================================

You are right. We should change NMTOKEN to CDATA.
##Agreed##
> ========================================================================
> 4.5.2.3 Processing Non-Duplicate Message
> ...
>  [Note]     This approach to handling of duplicate input messages means,
>             if absolutely "identical" messages are received then
>             absolutely "identical" messages are returned. This also
>             applies to Inquiry and Ping transactions when in reality the
>             state of a transaction or the processing ability of the
>             servers may have changed. If up-to-date status of transactions
>             or servers is required, then an IOTP transaction with a new
>             IotpTransId must be used.                               ^^^ 
>  [Note End]                  
> RH> However in "9.2.1 Baseline Transaction Status Inquiry IOTP
Transaction:"
> ...
>  TRANSACTION REFERENCE BLOCK
> 
>  A Trading Role making an inquiry must use the identical Transaction Id
>                                                ^^^^^^^^^
>  Component (see section 3.3.1) that was in the original transaction. The
> ...
> 
> RH> The two requirements are inconsistent as far as I see.
> RH> BTW. Is it really required for IOTP to cache all the Ping and
> RH> Inquery transactions ??? (They do not change anything in the server)
> RH> If idempotency is required, I would suggest using a new message ID
> RH> with the same IotpTransId, but this case every trading role have
> RH> to maintain it's last MessageID, which is not nice at all...
> RH> Or perhaps changing the TimeStamp of the MessageID comp. is enough
> RH> to force the server to give back fresh information ???? (ugly also)
> RH> Maybe a trading role wants to inquery a 
> RH> transaction a week later, and the last used message id for
> RH> this transaction is not present... Any hint on this? 

I believe that idempotency is not required for Ping and Inquiry
transaction. Additionaly I believe we do not need to use new
IotpTransId , we use the same as the IotpTransId of a Purchase
Transaction whenever Inquiry transaction is used.

##The part of the spec that says in the Note ...
>             ... then an IOTP transaction with a new IotpTransId must be
used.
... is wrong. It should read ...
>             ... then an IOTP transaction with a new value for the ID
attribute of the MsgId component must be used.

I also agree that idempotency is not really required for inquiry and ping
transactions. To my mind the question is, what is going to be simpler to
implement? I think we have three possible approaches:
1. Cache every transaction and have have the same approach to every
transaction (this is what the spec says now), or
2. Cache the messages we want to and not the others (i.e. don't cache ping &
inquiry), or
3. Leave to an implementation decision, i.e. if you do send the identical
message you might get the identical response back but then you might get an
updated one.

Option 1 could be simpler to implement in that you have a standard message
content unware process that says "Have I received this before ... yes ... so
I'll resend the last message if its available". As long as inquiries and
pings are relatively infrequent then the overhead in storage and processing
should be relatively small.

Option 2 would allow people to re-use inquiry requests (but why would you
want to?) and would save on what you had to cache but would require that the
content of the message would have to be understood before idempotency
processing could occu. FOr example it would require processing along the
lines of "What kind of message is it? If it's a Ping or an Inquiry then I'll
process it afresh otherwise I'll resend the last message I sent if one is
available."

Option 3 would mean that if you really always wanted to be sure of getting
up-to-date information then you would have to adopt approach 1 since
behaviour of systems/servers in this area would not be predictable.

Which approach do people prefer (or is there another one!) ?
##
> Hope this helps a little, polishing the final version :)
> Regards, Rudi

I believe your comments are very helpful for IOTP Spec :-)
##Definitely. Thanks.##
----
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]
-----------------------------------------------------------------------
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: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-trade-iotp-v1.0-dsig-02.txt
Date: Fri, 03 Sep 1999 07:05:32 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF.

	Title		: Digital Signatures for the v1.0 Internet Open Trading 
                          Protocol (IOTP)
	Author(s)	: K. Davidson, Y. Kawatsura
	Filename	: draft-ietf-trade-iotp-v1.0-dsig-02.txt
	Pages		: 31
	Date		: 02-Sep-99
	
A syntax and procedures are described for the computation and
verification of digital signatures for use within Version 1.0 of the
Internet Open Trading Protocol (IOTP).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-dsig-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-trade-iotp-v1.0-dsig-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-dsig-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-dsig-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-trade-iotp-v1.0-dsig-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

-----------------------------------------------------------------------
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]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
From: Rudolf Hornig <[email-masked]>
To: "IOTP Trade List (E-mail)" <[email-masked]>
Subject: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt Part 2
Date: Thu, 2 Sep 1999 17:10:35 +0200
Importance: Normal
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Again some additional comments on IOTP draft,

====================================================================
7.4 Trading Role Information Request Component

 <!ELEMENT TradingRoleInfoReq EMPTY>
 <!ATTLIST TradingRoleInfoReq
  ID                 ID      #REQUIRED
  TradingRoleList    NMTOKENS #REQUIRED >
                     ^^^^^^^^       
RH> Please correct the separate DTD file according to this
RH> definition.
====================================================================
7.6.1.1 Organisation IDs
RH> ComsumerOrgId is case sensitive however NonConsumerOrgId is
RH> case insensitive. This may cause confusion... and in this 
RH> case the third example should be:
RH> "Consumer:1000247ABH/newjerseybooks.com"
RH> starting with a capital letter...
====================================================================
7.6.2 Trading Role Element
RH> CancelNetLocn and ErrorNetLocn are IMPLIED according
RH> to the separate DTD file.
...
RH> ErrorLogNetLocn is mandatory for non consumer roles.
RH> Because there are no mechanisms defined for authenication
RH> on this channel and it is not secured, this type
RH> of logging may introduce security holes. (maybe the
RH> error component, the Consumer is sending, contains also
RH> some previous XML message, which contains sensitive information)
RH> Because all the error components should be sent back to the
RH> counterparty, I would suggest to let the server roles implement
RH> their own logging facility. Or I would make the ErrorLogNetLocn
RH> optional... Hints on this ???
====================================================================
RH> About DTD in general:
RH> PackagedContent, ContactInfo, PersonName, PostalAddress,
RH> ProtocolBrand, DeliveryData, ErrorLocation, Manifest,
RH> Digest, Attribute, OriginatorInfo, RecipientInfo,
RH> Parameter, IssuerAndSerialNumber and Locator Elements
RH> doesn't have ID attribute. As even for IOTP extensions
RH> it is a requirement to have ID attribute, it would be nice
RH> to have also on all element in IOTP DTD.
...
RH> The digital signature part is not consistent regarding
RH> capitalisation in attribuite naming.
====================================================================
7.9 Payment Component
RH> As it contains element references, I would suggest to change
RH> from StartAfter to StartAfterRefs just to be consistent
RH> in naming...
====================================================================
7.13.1 Delivery Data Element
...
 <!ATTLIST DeliveryData
  xml:lang           NMTOKEN #IMPLIED
  OkFrom             CDATA   #REQUIRED
  OkTo               CDATA   #REQUIRED
  DelivMethod        NMTOKEN #REQUIRED
  DelivToRef         NMTOKEN #REQUIRED
  DelivReqNetLocn    CDATA   #REQUIRED
  SecDelivReqNetLocn CDATA   #REQUIRED
  ContentSoftwareId  CDATA   #IMPLIED >
RH> DelivReqNetLocn and SecDelivReqNetLocn should be IMPLIED as
RH> only one of them is mandatory

Rudi
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rudolf Hornig ([email-masked]), Project Manager 
MeTechnology Ltd. Hungary - a Brokat Company
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

-----------------------------------------------------------------------
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], =?iso-8859-1?Q?VargaAndr=[email-masked]?=
Cc: [email-masked]
Subject: Re: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Wed, 01 Sep 1999 17:10:06 +0900 (JST)
Lines: 68
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Rudolf,
My comments are below.

>>>>> Wed, 1 Sep 1999 09:22:17 +0200,
	Rudolf Hornig <[email-masked]> said:

> ========================================================================
> 3.3.1 Transaction Id Component
> ...
>  IotpTransId        Contains data which uniquely identifies the IOTP
>                     Transaction. It must conform to the rules for
>                     Message Ids in [RFC 822].
> 
> RH> I'm not sure about this, but [RFC 822] defines the message id
> RH> as: <some.string@shost>, however NMTOKEN doesn't allow a '@'
> RH> character...
> ========================================================================

You are right. We should change NMTOKEN to CDATA.

> ========================================================================
> 4.5.2.3 Processing Non-Duplicate Message
> ...
>  [Note]     This approach to handling of duplicate input messages means,
>             if absolutely "identical" messages are received then
>             absolutely "identical" messages are returned. This also
>             applies to Inquiry and Ping transactions when in reality the
>             state of a transaction or the processing ability of the
>             servers may have changed. If up-to-date status of transactions
>             or servers is required, then an IOTP transaction with a new
>             IotpTransId must be used.                               ^^^ 
>  [Note End]                  
> RH> However in "9.2.1 Baseline Transaction Status Inquiry IOTP Transaction:"
> ...
>  TRANSACTION REFERENCE BLOCK
> 
>  A Trading Role making an inquiry must use the identical Transaction Id
>                                                ^^^^^^^^^
>  Component (see section 3.3.1) that was in the original transaction. The
> ...
> 
> RH> The two requirements are inconsistent as far as I see.
> RH> BTW. Is it really required for IOTP to cache all the Ping and
> RH> Inquery transactions ??? (They do not change anything in the server)
> RH> If idempotency is required, I would suggest using a new message ID
> RH> with the same IotpTransId, but this case every trading role have
> RH> to maintain it's last MessageID, which is not nice at all...
> RH> Or perhaps changing the TimeStamp of the MessageID comp. is enough
> RH> to force the server to give back fresh information ???? (ugly also)
> RH> Maybe a trading role wants to inquery a 
> RH> transaction a week later, and the last used message id for
> RH> this transaction is not present... Any hint on this? 

I believe that idempotency is not required for Ping and Inquiry
transaction. Additionaly I believe we do not need to use new
IotpTransId , we use the same as the IotpTransId of a Purchase
Transaction whenever Inquiry transaction is used.

> Hope this helps a little, polishing the final version :)
> Regards, Rudi

I believe your comments are very helpful for IOTP Spec :-)

----
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]

Reply-To: [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
From: Rudolf Hornig <[email-masked]>
To: "IOTP Trade List (E-mail)" <[email-masked]>
Cc: =?iso-8859-1?Q?Varga_Andr=E1s?=@metechnology.com
Subject: Comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt
Date: Wed, 1 Sep 1999 09:22:17 +0200
Importance: Normal
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This is a multi-part message in MIME format.

------=_NextPart_000_0008_01BEF45B.7C82F0F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Here comes some comments on the lates IOTP draft:

========================================================================
2.2.1 Offer Exchange
...
     C <-- M OFFER RESPONSE. Components: Organisation(s) (Consumer,
             DeliverTo, Merchant, Payment Handler, Customer Care); Order;
             Pay Amount; Delivery; Optional Offer Response Signature that
             signs other components

RH> "Pay Amount" should be "Paymnet".
RH> Status and TradingRoleData are missing, and also from the following
RH> list.
========================================================================
2.2.2 Payment Exchange
...
     C --> M        Component: Brand List Selection

 4.                 Merchant checks Brand Selection, creates a Payment
                    Amount information, optionally signs it to authorise
                    payment and sends it to the Consumer

     C <-- M        Component: Pay Amount; Organisation(s) (Merchant and
                    Payment Handler); Optional Offer Response Signature
                    that signs other components

 5.                 Consumer checks the Payment Amount information and if
                    OK requests that the payment starts by sending
                    information to the Payment Handler

     C --------> P  PAYMENT REQUEST. Components: Pay Amount; Organisations
                    (Merchant and Payment Handler); Optional Offer
                    Response Signature that signs other components; Pay
                    Scheme

 6.                 Payment Handler checks information including optional
                    signature and if OK starts exchanging Pay Scheme
                    components for selected payment brand and payment
                    protocol

     C <-------> P  PAYMENT EXCHANGE. Component: Pay Scheme

 7.                 Eventually payment protocol messages finish so Payment
                    Handler sends Pay Receipt and optional signature to
                    the Consumer as proof of payment

     C <-------> P  PAYMENT RESPONSE. Components: Pay Receipt; Payment
                    Note; Optional Offer Response Signature; Optional
                    Payment Receipt Signature that binds the payment to
                    the Offer
RH> - in general: "Payment Amount" -> "Payment"
RH>               "Pay Scheme" -> "PaySchemeData"
RH> - in 5. There are missing components like: Status; BrandList;
RH>   BrandSelection; TradingRoleData
RH> - in 7. Missing components: Status; PaySchemeData; TradingRoleData;
RH> - These components are also missing from the list following Figure 3
========================================================================
2.2.3 Delivery Exchange
...
     C --------> D  DELIVERY REQUEST. Components: Delivery, Organisations:
                    (Merchant, Delivery Handler, DelivTo); Order, Optional
                    Offer Response Signature, Optional Payment Receipt
                    Signature (from Payment Exchange)
RH> Missing: Status; ConsumerDeliveryData; TradingRoledData

 4.                 Delivery Handler checks information and authorisation.
                    Starts or schedules delivery and creates and then
                    sends a delivery not tot the Consumer which can
RH> sends a delivery NOTE TO the Consumer
...
     C <-------- D  DELIVERY RESPONSE. Components: Delivery Note, Optional
                    Delivery Response Signature
RH> Missing: Status
RH> These components are also missing from the list following Figure 4
========================================================================
2.3 Scope of Baseline IOTP
RH> Because the Inquiry and Ping transactions could be initiated
RH> by any trading role, in the "supported Roles/Transaction table" 
RH> I would mention, that a Consumer should only be able to send
RH> Inquiry and Ping transaction. Serving these transactions is 
RH> not a requirement as the Consumer role is represented by an
RH> HTTP client (according to the http supplement)
========================================================================
3.3.1 Transaction Id Component
...
 IotpTransId        Contains data which uniquely identifies the IOTP
                    Transaction. It must conform to the rules for
                    Message Ids in [RFC 822].

RH> I'm not sure about this, but [RFC 822] defines the message id
RH> as: <some.string@shost>, however NMTOKEN doesn't allow a '@'
RH> character...
========================================================================
3.6.1 Extra XML Elements
...
 In order to ensure that documents containing "IOTP:Critical" are valid,
 it is declared as part of the DTD for the extra element as:

 IOTP:Critical     (True | False ) 'True'

RH> Haven't found it in the actual DTD.
RH> This means it SHOULD BE DECLARED as part of the extended DTD ?
========================================================================
4.5.2.3 Processing Non-Duplicate Message
...
 [Note]     This approach to handling of duplicate input messages means,
            if absolutely "identical" messages are received then
            absolutely "identical" messages are returned. This also
            applies to Inquiry and Ping transactions when in reality the
            state of a transaction or the processing ability of the
            servers may have changed. If up-to-date status of transactions
            or servers is required, then an IOTP transaction with a new
            IotpTransId must be used.                               ^^^ 
 [Note End]                  
RH> However in "9.2.1 Baseline Transaction Status Inquiry IOTP Transaction:"
...
 TRANSACTION REFERENCE BLOCK

 A Trading Role making an inquiry must use the identical Transaction Id
                                               ^^^^^^^^^
 Component (see section 3.3.1) that was in the original transaction. The
...

RH> The two requirements are inconsistent as far as I see.
RH> BTW. Is it really required for IOTP to cache all the Ping and
RH> Inquery transactions ??? (They do not change anything in the server)
RH> If idempotency is required, I would suggest using a new message ID
RH> with the same IotpTransId, but this case every trading role have
RH> to maintain it's last MessageID, which is not nice at all...
RH> Or perhaps changing the TimeStamp of the MessageID comp. is enough
RH> to force the server to give back fresh information ???? (ugly also)
RH> Maybe a trading role wants to inquery a 
RH> transaction a week later, and the last used message id for
RH> this transaction is not present... Any hint on this? 
========================================================================
4.6.2.1 Check for Errors in Block Sequence
...
 o Offer Response Block. Check as follows:
   - if the Offer Response Block is not part of an IOTP Transaction that
     is recognised by the Consumer role then there is a Hard Error,
     otherwise
RH> During brand independent purchase without authentication,
RH> OfferResponse (with TPO) is the first message received by the 
RH> Consumer.
========================================================================
7.11 Payment Receipt Component
...
 Note that either the *PayReceiptRefs* attribute, the PackagedContent
 element, or both must be present.
RH> change to: PayReceiptNameRefs attribute...
========================================================================
9.1 Authentication and Payment Related IOTP Transactions
...
 o Brand Independent Offer. This is also an Offer Trading Exchange.
   However, in this instance, the content of the Offer Response does
   depend on the Brand selected.
RH> Change to: does not depend on the Brand selected.
========================================================================
9.1.2.1 Brand Dependent Offer Document Exchange
...
 On receiving an Offer Response IOTP Message (see below) the Consumer may
 either:

 o generate and send the next IOTP Message in the IOTP transaction and
   send it to the required Trading Role. This is dependent on the IOTP
   Transaction, or
 o indicate failure to continue with the IOTP Transaction by sending a
   Cancel Block back to the Consumer containing a Status Component with a
                            ^^^^^^^^
   StatusType of Offer, a ProcessState of Failed and the CompletionCode
   (see section 7.16.4) set to either: ConsCancelled or Unspecified.
RH> Change to: Merchant
========================================================================
9.1.4.3 Delivery Response IOTP Message
...
 The Delivery Response IOTP Message contains a Delivery Response Block
 and an options Signature Block.
        ^^^^^^^
RH> Change: optional
========================================================================
11.1.1 Definition of Payment Instrument
...
 All Payment Instruments have a number, typically an account number, by
                         ^^^^^^^^^^^^^ 
 which the Payment Instrument can be identified.
RH> I'm not sure, but there are some payment protocols, which
RH> enable anonym payment (GeldKarte ???). Is this applys also
RH> for these instruments ???
========================================================================
Hope this helps a little, polishing the final version :)
Regards, Rudi

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rudolf Hornig ([email-masked]), Project Manager 
MeTechnology Ltd. Hungary - a Brokat Company
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

------=_NextPart_000_0008_01BEF45B.7C82F0F0
Content-Type: text/x-vcard;
	name="Rudolf Hornig (E-mail).vcf"
Content-Disposition: attachment;
	filename="Rudolf Hornig (E-mail).vcf"
Content-Transfer-Encoding: 7bit

BEGIN:VCARD
VERSION:2.1
N:Hornig;Rudolf
FN:Rudolf Hornig (E-mail)
ORG:MeTechnology Ltd. (Hungary) - a Brokat Company;Research&Development
TITLE:Project Manager
TEL;WORK;VOICE:+36 (1) 437 04 13
TEL;WORK;FAX:+36 (1) 387 37 98
ADR;WORK:;;Kunigunda utca 58.;Budapest;;H1037;Hungary
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Kunigunda utca 58.=0D=0ABudapest H1037=0D=0AHungary
KEY;X509;ENCODING=BASE64:
    MIICjDCCAfWgAwIBAgIDAUf1MA0GCSqGSIb3DQEBBAUAMIG5MQswCQYDVQQGEwJaQTEVMBMG
    A1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEaMBgGA1UEChMRVGhh
    d3RlIENvbnN1bHRpbmcxKTAnBgNVBAsTIFRoYXd0ZSBQRiBSU0EgSUsgMTk5OC45LjE2IDE3
    OjU1MTYwNAYDVQQDEy1UaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgUlNBIElzc3VlciAxOTk4
    LjkuMTYwHhcNOTkwODI0MDg0MDA3WhcNMDAwODIzMDg0MDA3WjBJMR8wHQYDVQQDExZUaGF3
    dGUgRnJlZW1haWwgTWVtYmVyMSYwJAYJKoZIhvcNAQkBFhdydWRvbGZATWVUZWNobm9sb2d5
    LmNvbTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDH8coNT3BGTG4HGqz08KaFHSjONYQ6BLta
    HwjWmfH0j+M/hQp86tPpLB73RQjDt5lsbb/EkzGA6QShkabMQyBLAgMBAAGjVTBTMCIGA1Ud
    EQQbMBmBF3J1ZG9sZkBNZVRlY2hub2xvZ3kuY29tMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgw
    FoAU/j5gnGuMD7DYM8bKxh5YsHE4teAwDQYJKoZIhvcNAQEEBQADgYEACHlsv89kEhISAVFs
    1TdW9KKW8kluUJDjC7DDnAEgiCLw6mlm2kvHW3NzYONaefEsCBOsYVOIOBg4RW15HCR4+eay
    dEuGJXi510jSc2DN/uyYjNB4okvGKYl/zEbgTqJFEUEjwHtSFDIspCbufD1bj4I0/GQc1+fP
    Vv/VePfpVqo=

EMAIL;PREF;INTERNET:[email-masked]
REV:19990830T133416Z
END:VCARD

------=_NextPart_000_0008_01BEF45B.7C82F0F0--

-----------------------------------------------------------------------
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]