Subject: RE: Country Codes
From: "Lewis, Tony" <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Date: Fri, 30 Apr 1999 13:44:26 -0700

I recommend settling on one representation. Otherwise, implementers who want
to interoperate with everyone have to implement every possible way of
encoding the information.

Tony
> ----------
> From: 	Tom Arnold[SMTP:[email-masked]]
> Sent: 	Friday, April 30, 1999 11:35 AM
> To: 	Ietf Trade WG
> Subject: 	Re: Country Codes
> 
> I think it would be appropriate to specify ISO 3166 for the country code
> and leave the specification of whether to use alpha 2 or alpha 3 character
> codes to the implementers.  
> 
> At 12:00 AM 4/30/99 +0100, David Burdett wrote: 
> >A while back there was discussion about country codes (see emails from
> Tom 
> >Arnold on 14 March and Don Eastlake on 17 March) that suggested  
> >	In the same manner that ISO4217 is specified for currency codes, 
> >should country codes be specified to ISO3166? Also, does it matter if two
> or 
> >three character codes are used? 
> > 
> >In IOTP country is only used as part of an address (see Postal Address 
> >Element). Therefore mandating use of country codes doesn't seem to be 
> >necessary in my view as I can't think how it would be used although I'm
> open 
> >to counter arguments. 
> > 
> > [snip] 
> 
> 
> Tom Arnold 
> Vice President of Engineering 
> Chief Technical Officer 
> CyberSource Corporation 
> [email-masked] 
> 
> ------------------------------------------------------------------------ 
> This Email and any attached files are confidential and may also be
> privileged.  It is intended only for the individual or entity to whom it
> is addressed.  If you are not the recipient or an authorized agent of the
> recipient, you are hereby notified that any use, dissemination,
> distribution or copying of this communication is strictly prohibited.  If
> you have received this message in error, please contact CyberSource
> Corporation immediately at (408) 556-9100.  Thank you. 
> 
> -----------------------------------------------------------------------
> 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: Fri, 30 Apr 1999 11:35:14 -0700
To: Ietf Trade WG <[email-masked]>
From: Tom Arnold <[email-masked]>
Subject: Re: Country Codes
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I think it would be appropriate to specify ISO 3166 for the country code and leave the specification of whether to use alpha 2 or alpha 3 character codes to the implementers. 

At 12:00 AM 4/30/99 +0100, David Burdett wrote:

>A while back there was discussion about country codes (see emails from Tom

>Arnold on 14 March and Don Eastlake on 17 March) that suggested 

>	In the same manner that ISO4217 is specified for currency codes,

>should country codes be specified to ISO3166? Also, does it matter if two or

>three character codes are used?

>

>In IOTP country is only used as part of an address (see Postal Address

>Element). Therefore mandating use of country codes doesn't seem to be

>necessary in my view as I can't think how it would be used although I'm open

>to counter arguments.

>

> [snip]

Tom Arnold

Vice President of Engineering

Chief Technical Officer

CyberSource Corporation

[email-masked]

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

This Email and any attached files are confidential and may also be
privileged. <bold><italic> </italic></bold>It is intended only for the
individual or entity to whom it is addressed.  If you are not the
recipient or an authorized agent of the recipient, you are hereby
notified that any use, dissemination, distribution or copying of this
communication is strictly prohibited.  If you have received this message
in error, please contact CyberSource Corporation immediately at (408)
556-9100.  Thank you.

-----------------------------------------------------------------------
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]>,  "Lewis, Tony" <[email-masked]>
Cc: Ietf Trade WG <[email-masked]>
Subject: RE: Question for IOTP Authentication
Date: Fri, 30 Apr 1999 20:04:11 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Tony

I can think of three ways that IOTP might be able to meet the requirement
you describe:
*	using the Packaged Content element in the Pay Protocol element (see
section 6.6.4),
*	the Consumer authenticates the Merchant separately using an
authentication transaction, or 
*	a combination of the two.

Each is discussed in a bit more detail below.

PAY PROTOCOL ELEMENT
This involves the merchant including the relevent certificate and message
from the acquirer in the PackagedContent element in the Pay Protocol element
for SET of the Brand List (see spec section  6.6.4), then if the Consumer
wants to use SET for a payment they just pass the data to the SET payment
software working within IOTP which then checks the credentials.

The advantage of this approach is that the certificate will always be there
and no extra messages will be required to retrieve it. The disadvantage is
that it increases the size of the messages.

SEPARATE CONSUMER AUTHENTICATION OF THE MERCHANT
In this case, the SET software recognises that there a certificate and
message from the acquirer is needed and makes a request to the IOTP software
to obtain it. When this need occurs, a separate IOTP Authentication
Transaction (see spec section 8.1.6) is used to get the information. 

This would involve:
*	the Consumer sending an IOTPAuthentication Request message to the
merchant specifying in the Algorithm element that the Merchant should do,
for example, a SET merchant authentication, then
*	the Merchant replying with a Authentication Response message
including the necessary certificate and acquirer message in the Packaged
Content.

COMBINATION
An alternative might be to include some fingerprint of the
certificate/message in the PayProtocol element, so that the consumer SET
software can check if it already has a copy of it. If it hasn't then a
separate consumer initiated IOTP Athentication of the merchant could be used
to obtain it.

Does this make sense?

David

> ----------
> From: 	Lewis, Tony[SMTP:[email-masked]]
> Sent: 	29 April 1999 17:36
> To: 	Yoshiaki KAWATSURA
> Cc: 	Ietf Trade WG
> Subject: 	RE: Question for IOTP Authentication
> 
> David,
> 
> I believe this proposal originates from requirements that SETCo has
> defined
> for SET 2.0 although when we discussed the approach outlined by Yoshiaki
> at
> our meeting last week, we recommended some changes.
> 
> I believe what we will need is the ability for the merchant to push some
> data (certificates and a signed message from the acquirer) to the
> cardholder
> wallet who will use that data to authenticate the merchant. If that can be
> accomplished with the existing authentication transaction then I believe
> your change will satisfy our needs.
> 
> However, there may be other issues behind the input from Hitachi so
> Yoshiaki
> should also respond.
> 
> Tony
> > ----------
> > From: 	David Burdett[SMTP:[email-masked]]
> > Sent: 	Thursday, April 29, 1999 4:00 PM
> > To: 	Yoshiaki KAWATSURA
> > Cc: 	Ietf Trade WG
> > Subject: 	RE: Question for IOTP Authentication
> > 
> > Yoshiaki
> > 
> > As you can see I'm catching up on all the Trade WG emails and have
> thought
> > about your suggestion. In principle I can see why allowing a Consumer to
> > authenticate a Merchant is reasonable as, in the current version of the
> > specification, it states that a Conumer can authenticate a Payment
> Handler
> > or a Delivery Handler (see section 8.1.13 second bullet point) and
> > therefore
> > it is logical that a Consumer should also be able to authenticate a
> > Merchant.
> > 
> > However the method you suggest below for authenticating a Merchant is
> > different from the way the Consumer authenticates a Payment Handler or
> > Delivery Handler in that it is integrated into the transaction (e.g a
> > purchase) which implies a further variation on the message flow. So, I
> > suggest that we meet your requirement by simply changing the first
> bullet
> > point in section 8.1.13 to read the authentication transaction can be
> used
> > ... " by a Consumer to authenticate a *Merchant*, Payment Handler or a
> > Delivery Handler ..."
> > 
> > Is this OK?
> > 
> > David
> > 		
> > 
> > > ----------
> > > From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
> > > Sent: 	29 March 1999 22:45
> > > To: 	[email-masked]
> > > Cc: 	[email-masked]; [email-masked];
> > [email-masked];
> > > [email-masked]
> > > Subject: 	RE: Question for IOTP Authentication
> > > 
> > > David,
> > > I agree with your suggestion.
> > > But I also want to add the Merchant Authenticaton by Consumer 
> > > prior to IOTP Purchase Transaction.
> > > 
> > > These are the same flow as follows,
> > > 
> > > Consumer             Merchant
> > >    <-------------------
> > >          TPO
> > > 
> > >    ------------------->
> > >       Auth Req
> > > 
> > >    <------------------
> > >       Auth Res
> > > 
> > > and Status Block is not sent to the Merchant.
> > > 
> > > After Consumer receives the Auth Response,
> > > 1. If prior to IOTP purchase transaction
> > > Success: Consumer sends the message to the Success NetLocation.
> > > Fail: Stop
> > > 
> > > 2. If in the IOTP Purchase Transaction
> > > Success: Continue the transaction
> > > Fail: Stop.
> > > 
> > > Make sense?
> > > 
> > > This is minor change and I think there is no affect in the IOTP
> > protocol.
> > > Regards,
> > > ----
> > > Yoshiaki Kawatsura : E-mail [email-masked]
> > >  Business & Information Systems Development Devision, Hitachi,Ltd.
> > > Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721
> > > 
> > > 
> > >  >>>>> Fri, 26 Mar 1999 18:20:48 -0000,
> > > 	 David Burdett <[email-masked]> said:
> > > 
> > >  >Yoshiaki
> > >  >
> > >  >The current version of IOTP does not support authentication of the
> > > Merchant
> > >  >by the Consumer. Part of the reasoning behind this is that the
> > Merchant
> > > will
> > >  >include a signature in the offer which can be used for this purpose.
> > >  >HOwever, as you say, the consumer might not want to give address
> > > information
> > >  >until they have authenticated the Merchant.
> > >  >
> > >  >You could actually do this although section 8.1.13 does not
> > specifically
> > >  >state this. What would be requried is that, after the Consumer has
> > > received
> > >  >the TPO, he authenticates the merchant with a separate
> Authentication
> > >  >transaction and then if its  OK continues with the original
> > transaction.
> > >  >
> > >  >Would this make sense? If you think it does then please post the
> idea
> > to
> > > the
> > >  >list. I don't know though if we want to include this in v1.0
> although
> > it
> > >  >could easily go into v 2.0
> > >  >
> > >  >David
> > >  >
> > >  >> ----------
> > >  >> From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
> > >  >> Sent: 	25 March 1999 22:46
> > >  >> To: 	[email-masked]; [email-masked];
> > > [email-masked]
> > >  >> Cc: 	[email-masked]
> > >  >> Subject: 	Question for IOTP Authentication
> > >  >> 
> > >  >> Don and David,
> > >  >> I have a couple of question for IOTP Authentication.
> > >  >> 
> > >  >> Consumer wants to send private information such as home address to
> > >  >> authenticated merchants only for Offer. In fact, SET is attempting
> > to
> > >  >> support simliar functionality. I believe that IOTP should support
> > > this.
> > >  >> 
> > >  >> IOTP version 1.0 cannot do this function in Offer Exchange, since
> > the
> > >  >> Offer Exchange is simplified. The idea would be that initially
> IOTP
> > >  >> processes an Authentication, then a Web browser sends a private
> > >  >> information for Offer, and finally IOTP does Purchase Transaction.
> > In
> > >  >> IOTP version 1.0, IOTP supports a Consumer Authentication by
> > Merchant,
> > >  >> however, IOTP does not support a Merchant Authentication by
> > >  >> Consumer. Is this correct?
> > >  >> 
> > >  >> If this is correct, will IOTP version 2.0 support the Merchant
> > >  >> Authentication by Consumer?
> > >  >> 
> > >  >> Regards,
> > >  >> 
> > >  >> --
> > >  >> Yoshiaki Kawatsura
> > >  >> Hitachi, Ltd.
> > >  >> 
> > >  >
> > > 
> > > 
> > > 
> > > 
> > 
> >
> **************************************************************************
> > ********************
> > 
> > This Email and any attached files are confidential and may also be
> > privileged. 
> > If you are not the intended recipient, please notify the postmaster
> using
> > email 
> > address [email-masked] or call +44 171 557 5000 and ask for the 
> > IT Helpdesk.  You should not copy this email and any attached files, use
> > them 
> > for any purpose or disclose the contents to any other person; all copies
> > of the 
> > Email and associated files in your possession should be destroyed.
> > 
> > Mondex International Limited
> > 47-53 Cannon Street
> > London EC4M 5SQ
> > United Kingdom
> > Registered No: 3122085, England
> > 
> > Phone:          +44 171 557 5000
> > Fax:            +44 171 557 5200
> > Email:          [email-masked]
> > WebSite:        http://www.mondexinternational.com
> > 
> >
> **************************************************************************
> > *******************
> > -----------------------------------------------------------------------
> > Message addressed to: [email-masked]
> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > body to: [email-masked]
> > 
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 

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

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

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

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

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

From: David Burdett <[email-masked]>
To: Don Eastlake <[email-masked]>
Cc: Ietf Trade WG <[email-masked]>
Subject: RE: Using XML as well as HTML 
Date: Fri, 30 Apr 1999 20:04:09 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I agree that XML should be recommended, the problem is how do you discover
if the consumer has XML/XSL support in their IOTP implementation? 

If a merchant or one of the other trading roles is unsure, then they'll
never send order descrciptions, etc, in XML to the consumer. On the other
hand if a particular IOTP consumer client software becomes highly popular
that supports XML/XSL, then it is reasonable safe for merchants to use XML
and more might do so.

Finally, you could argue that since to do IOTP at all, there must be XML
support then at least half the solution *must* be there. In this case, you
could recommend displaying a message to the user of the problem and
displaying XML in a very simple way.

David

> ----------
> From: 	Donald E. Eastlake 3rd[SMTP:[email-masked]]
> Sent: 	29 April 1999 10:04
> To: 	Ietf Trade WG
> Subject: 	Re: Using XML as well as HTML 
> 
> I believe that support for XML should be recommended but not required.
> 
> Thanks,
> Donald
> 
> From:  David Burdett <[email-masked]>
> Message-Id:  <[email-masked]>
> To:  Ietf Trade WG <[email-masked]>
> Date:  Thu, 29 Apr 1999 17:17:05 +0100
> 
> >Following on from my other email on using HTML, the spec doesn't
> currently
> >describe how XML could be used. I think that it should. We could provide
> >similar guidelines for XML/XSL to the ones for HTML. 
> >
> >Who thinks this is a good idea?
> >
> >David
> >
> >THIS EMAIL IS FOR UNRESTRICTED DISTRIBUTION
> >> mailto:<[email-masked]>
> >> Mondex International, US Advanced Technology Office
> >> 111 Pine St, 6th Floor, San Francisco, CA 94111
> >> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 

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

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

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

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

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

From: "Lewis, Tony" <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: RE: Country Codes
Date: Thu, 29 Apr 1999 17:35:55 -0700
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

When we did the work on SET, we settled on the three digit numeric codes
from ISO 3166 for country and ISO 4217 for currency. As I recall, we made
these choices because those are the formats carried in the financial
networks and there was no compelling reason to use alphabetic codes that
would have to be translated by the payment gateway to numeric (and back
again on responses).

Tony

PS) I mentioned to David in an off-list message that my vote is for numeric
for the currency code. (Not that my vote alone changes the outcome.)
> ----------
> From: 	David Burdett[SMTP:[email-masked]]
> Sent: 	Thursday, April 29, 1999 4:00 PM
> To: 	Ietf Trade WG
> Subject: 	Country Codes
> 
> A while back there was discussion about country codes (see emails from Tom
> Arnold on 14 March and Don Eastlake on 17 March) that suggested 
> 	In the same manner that ISO4217 is specified for currency codes,
> should country codes be specified to ISO3166? Also, does it matter if two
> or
> three character codes are used?
> 
> In IOTP country is only used as part of an address (see Postal Address
> Element). Therefore mandating use of country codes doesn't seem to be
> necessary in my view as I can't think how it would be used although I'm
> open
> to counter arguments.
> 
> Thoughts?
> 
> David
> > mailto:<[email-masked]>
> > Mondex International, US Advanced Technology Office
> > 111 Pine St, 6th Floor, San Francisco, CA 94111
> > Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
> > 
> 
> **************************************************************************
> ********************
> 
> This Email and any attached files are confidential and may also be
> privileged. 
> If you are not the intended recipient, please notify the postmaster using
> email 
> address [email-masked] or call +44 171 557 5000 and ask for the 
> IT Helpdesk.  You should not copy this email and any attached files, use
> them 
> for any purpose or disclose the contents to any other person; all copies
> of the 
> Email and associated files in your possession should be destroyed.
> 
> Mondex International Limited
> 47-53 Cannon Street
> London EC4M 5SQ
> United Kingdom
> Registered No: 3122085, England
> 
> Phone:          +44 171 557 5000
> Fax:            +44 171 557 5200
> Email:          [email-masked]
> WebSite:        http://www.mondexinternational.com
> 
> **************************************************************************
> *******************
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: "Lewis, Tony" <[email-masked]>
To: Yoshiaki KAWATSURA <[email-masked]>
Cc: Ietf Trade WG <[email-masked]>
Subject: RE: Question for IOTP Authentication
Date: Thu, 29 Apr 1999 17:36:04 -0700
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David,

I believe this proposal originates from requirements that SETCo has defined
for SET 2.0 although when we discussed the approach outlined by Yoshiaki at
our meeting last week, we recommended some changes.

I believe what we will need is the ability for the merchant to push some
data (certificates and a signed message from the acquirer) to the cardholder
wallet who will use that data to authenticate the merchant. If that can be
accomplished with the existing authentication transaction then I believe
your change will satisfy our needs.

However, there may be other issues behind the input from Hitachi so Yoshiaki
should also respond.

Tony
> ----------
> From: 	David Burdett[SMTP:[email-masked]]
> Sent: 	Thursday, April 29, 1999 4:00 PM
> To: 	Yoshiaki KAWATSURA
> Cc: 	Ietf Trade WG
> Subject: 	RE: Question for IOTP Authentication
> 
> Yoshiaki
> 
> As you can see I'm catching up on all the Trade WG emails and have thought
> about your suggestion. In principle I can see why allowing a Consumer to
> authenticate a Merchant is reasonable as, in the current version of the
> specification, it states that a Conumer can authenticate a Payment Handler
> or a Delivery Handler (see section 8.1.13 second bullet point) and
> therefore
> it is logical that a Consumer should also be able to authenticate a
> Merchant.
> 
> However the method you suggest below for authenticating a Merchant is
> different from the way the Consumer authenticates a Payment Handler or
> Delivery Handler in that it is integrated into the transaction (e.g a
> purchase) which implies a further variation on the message flow. So, I
> suggest that we meet your requirement by simply changing the first bullet
> point in section 8.1.13 to read the authentication transaction can be used
> ... " by a Consumer to authenticate a *Merchant*, Payment Handler or a
> Delivery Handler ..."
> 
> Is this OK?
> 
> David
> 		
> 
> > ----------
> > From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
> > Sent: 	29 March 1999 22:45
> > To: 	[email-masked]
> > Cc: 	[email-masked]; [email-masked];
> [email-masked];
> > [email-masked]
> > Subject: 	RE: Question for IOTP Authentication
> > 
> > David,
> > I agree with your suggestion.
> > But I also want to add the Merchant Authenticaton by Consumer 
> > prior to IOTP Purchase Transaction.
> > 
> > These are the same flow as follows,
> > 
> > Consumer             Merchant
> >    <-------------------
> >          TPO
> > 
> >    ------------------->
> >       Auth Req
> > 
> >    <------------------
> >       Auth Res
> > 
> > and Status Block is not sent to the Merchant.
> > 
> > After Consumer receives the Auth Response,
> > 1. If prior to IOTP purchase transaction
> > Success: Consumer sends the message to the Success NetLocation.
> > Fail: Stop
> > 
> > 2. If in the IOTP Purchase Transaction
> > Success: Continue the transaction
> > Fail: Stop.
> > 
> > Make sense?
> > 
> > This is minor change and I think there is no affect in the IOTP
> protocol.
> > Regards,
> > ----
> > Yoshiaki Kawatsura : E-mail [email-masked]
> >  Business & Information Systems Development Devision, Hitachi,Ltd.
> > Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721
> > 
> > 
> >  >>>>> Fri, 26 Mar 1999 18:20:48 -0000,
> > 	 David Burdett <[email-masked]> said:
> > 
> >  >Yoshiaki
> >  >
> >  >The current version of IOTP does not support authentication of the
> > Merchant
> >  >by the Consumer. Part of the reasoning behind this is that the
> Merchant
> > will
> >  >include a signature in the offer which can be used for this purpose.
> >  >HOwever, as you say, the consumer might not want to give address
> > information
> >  >until they have authenticated the Merchant.
> >  >
> >  >You could actually do this although section 8.1.13 does not
> specifically
> >  >state this. What would be requried is that, after the Consumer has
> > received
> >  >the TPO, he authenticates the merchant with a separate Authentication
> >  >transaction and then if its  OK continues with the original
> transaction.
> >  >
> >  >Would this make sense? If you think it does then please post the idea
> to
> > the
> >  >list. I don't know though if we want to include this in v1.0 although
> it
> >  >could easily go into v 2.0
> >  >
> >  >David
> >  >
> >  >> ----------
> >  >> From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
> >  >> Sent: 	25 March 1999 22:46
> >  >> To: 	[email-masked]; [email-masked];
> > [email-masked]
> >  >> Cc: 	[email-masked]
> >  >> Subject: 	Question for IOTP Authentication
> >  >> 
> >  >> Don and David,
> >  >> I have a couple of question for IOTP Authentication.
> >  >> 
> >  >> Consumer wants to send private information such as home address to
> >  >> authenticated merchants only for Offer. In fact, SET is attempting
> to
> >  >> support simliar functionality. I believe that IOTP should support
> > this.
> >  >> 
> >  >> IOTP version 1.0 cannot do this function in Offer Exchange, since
> the
> >  >> Offer Exchange is simplified. The idea would be that initially IOTP
> >  >> processes an Authentication, then a Web browser sends a private
> >  >> information for Offer, and finally IOTP does Purchase Transaction.
> In
> >  >> IOTP version 1.0, IOTP supports a Consumer Authentication by
> Merchant,
> >  >> however, IOTP does not support a Merchant Authentication by
> >  >> Consumer. Is this correct?
> >  >> 
> >  >> If this is correct, will IOTP version 2.0 support the Merchant
> >  >> Authentication by Consumer?
> >  >> 
> >  >> Regards,
> >  >> 
> >  >> --
> >  >> Yoshiaki Kawatsura
> >  >> Hitachi, Ltd.
> >  >> 
> >  >
> > 
> > 
> > 
> > 
> 
> **************************************************************************
> ********************
> 
> This Email and any attached files are confidential and may also be
> privileged. 
> If you are not the intended recipient, please notify the postmaster using
> email 
> address [email-masked] or call +44 171 557 5000 and ask for the 
> IT Helpdesk.  You should not copy this email and any attached files, use
> them 
> for any purpose or disclose the contents to any other person; all copies
> of the 
> Email and associated files in your possession should be destroyed.
> 
> Mondex International Limited
> 47-53 Cannon Street
> London EC4M 5SQ
> United Kingdom
> Registered No: 3122085, England
> 
> Phone:          +44 171 557 5000
> Fax:            +44 171 557 5200
> Email:          [email-masked]
> WebSite:        http://www.mondexinternational.com
> 
> **************************************************************************
> *******************
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>, [email-masked]
Subject: RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt, part  1
Date: Fri, 30 Apr 1999 00:00:50 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I have responded to Don's comments with comments marked with ###. I have
also recently sent out separate emails on a number of topics which perhaps
warrant more discussion.

David

> ----------
> From: 	[email-masked][SMTP:[email-masked]]
> Sent: 	22 April 1999 15:25
> To: 	[email-masked]
> Subject: 	Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt, part
> 1
> 
> I've done a careful review of the document through section 6 and section
> 13
> and greater and came up with the following somewhat length list of
> suggestions.  I don't think they substantially change the intended meaning
> of the document but those on the list should judge that.
> 
> 
> IMPORTANT:
> 
> "IANA Considerations" needs to be a top level section, perhaps #11.
> Gathering this stuff together into 3.7.3 is good but its still
> unreasonable
> to expect IANA to comb the document to find it.
### Agreed. Move section 3.7.3 to a new section 11 IANA Considerations.###
>      I'm not sure about the criteria for registration.  "IETF Consensus"
> is
> pretty stiff and requires a vote of the IESG.  I should think someone
> could
> register an IOTP Brand or CurrCode by publishing an RFC.  Perhaps that is
> what you mean for ProtocolId but it is not clear.
### Agreed. See separate email.###
>      Toward end so 3.7.3, change "with" to "without".
### Agreed

> MISCELLANEOUS:
> 
> I don't understand the difference between "Objectives" and "Purpose".  I
> suggest that 1.4 and 1.5 be merged 
###Agreed
> and that the reference to "IOTP Business
> Description" which, as far as I know, is not intended to ever become an
> IETF document, be dropped.
###Agreed

> Section 1.7 still refers to an XML Overview section 11.
###Change to refer to IANA considerations

> Page spanning figures, like Figure 3, are really pretty messy.  It would
> be
> better if the text could be made much more terse and this and similar
> figures started high on a page so they aren't split by a page boundary.
### Not sure. See separate email ###

> Section 2.2: suggest "The Open Trading Protocols identify" be changed to
> "IOTP identifies".
### Agreed. Also suggest changing Open Trading Protocol to Internet Open
Trading Protocol in sections: 1.4,1.6, 8, 12 (heading & DTD)###

> Section 2.2: says "IOTP Transactions are composed of these exchanges" but
> does not list Inquiry or Ping exchange.
###This is deliberate. The Inquiry and Ping exchange are not "trading
exchanges" as they are used primarily to to ensure that messages are
exchanged correctly or to determine the current status of a transaction.###

> Starting in section 2.3 and many other places in the document, words or
> phrases are prefixed and suffixed by an underscore character ("_").  This
> is not any normal IETF style.  I suspect it means that the original text
> is
> italic.  These should be suppressed or if that is impossible, a separate
> pass should be done to delete them.
###These seem to be caused by either a non-breakable dash or "smart quotes"
in MS Word being miss-translated when the document is converted to text.
Will fix in next version.###

> In Figure 9, the things which are supposed to be identical or match aren't
> and don't.  Is that deliberate?
### No. Its a mistake. They should be the same. Will be fixed.###

> I don't think that section 3.6 Brands and Brand Selection fits very well
> where it and suggest it be moved into section 10 which could be renamed
> "Brands".
###Agreed. A good idea.###
>      Continuing on Brands, I looked around a bit in SET literature and
> couldn't find anything about Dual or Promotional brands or anything about
> a
> three component SET Brand.  Two components, "brand" and "product" I see in
> the SET literature, such a "MasterCard" or "Visa:Gold".  But not A:B:C and
> no case where a colon is included if there isn't anything after it.  In
> other words, it's "Visa", not "Visa:", and certainly not "Visa::" as a SET
> brand (re also examples in 6.6.1). Can anyone give me any references to
> shed light on this?
### I think this arose as a result of a japanes requirement. See separate
email###

> Section 3.8.1: I don't understand why sub-pages of an HTML main page
> couldn't have links back to the main page.
### Disagree. See separate email.###

> Section 4.1: first section reference says "0"?
###Agreed. Will fix.###

> Figures 10 and 11: These flow diagrams each *almost* fit on a page. If the
> initial "Input IOTP Message" box could be to the side with a horizontal
> arrow and the text were edited down to something a bit more terse, I think
> they would, which would be quite helpful.
### See response to comments about figure 3, and separate email###

> Section 5: Suggest this section be called "Digital Signature" or
> something.
> Usually an IETF Security Considerations section is brief and talks about
> really high level issues.  Material in 5.4 is appropriate for Security
> Considerations.  A separate Security Considerations section would need to
> also say something about deciding when to require signatures, even if it
> is
> just by referring to section 5.1.4, and about depending on payment scheme
> security for the safety of funds, which I didn't see anywhere.
>      Section 5 seems pretty heavy on certificates and public key crypto,
> especially given the originally IOTP v1.0 was going to be secret key only
> and, as I recall, it was with some reluctance that public key hooks were
> added.  The stuff on checking a signature, for example, talks about
> checking the certificate as if there always has to be one.
>      Section 5.1.4: another reason you might not need signatures is the
> that the sender and receiver were on the same machine so it can check
> integrity just by comparing with a saved copy.
### I suggest quite a few changes here specifically:
*	renumber section 5 (and all later sections) as section 6 and rename
as "Digital Signatures and IOTP"
*	insert a new section 5 called "Security Considerations" which is
focussed on the types of IETF security considerations Don describes above.
Specifically including: why you might want (or not want) to use signatures;
use of asymmetric and symmetric cryptography; privacy, and payment protocol
security###

> Section 6.4.2: Need to eliminate reference to "Open Trading Protocol
> Consortium" and suggest dropping whole note. 
### Agreed ###
> I don't see any difference at all between OkTo/OkFrom and amount.  Both
> could appear in human readable
> form in the Order Description and in machine readable form in their
> element.  Recommending that the UI display the machine readable version is
> reasonable (as in 6.4.1).
### I think the note should remain but include suggestion that the OkFrom
and OkTo dates are displayed to the consumer.###

> ContentSoftwareId: the standard text given for this is quite length and
> repeated dozens of time.  If it could be moved to the glossary or
> something
> and a simple "see glossary" put in, it would save many pages.
### Agreed ###

> As previously discussed, change ISO4217 to ISO4217A or the like.
### Suggest change to ISO4217-A. See other email.###

> Just before section 6.7, it says that examples exist in 6.6 when they are
> in 10.
### Agreed. Will fix ###

> Section 6.17: references to the Richard Brown draft and probably not
> appropriate.  RFCs are not supposed to refer to drafts.  About the future,
> I'm not sure you need to say anything but if you do, I think it should
> just
> say the future versions of IOTP will use industry standard XML signature
> technology if it meets IOTP requirements.
### Agreed will change to refer to IOTP Dsig paper and use of standard XML
signature technology in the future###

>      Shouldn't 6.17.1 refer to the IOTP DSIG document?  It's OK to refer
> to
> that draft because the idea is that it and the main protocol document will
> be issued as RFCs simultaneously.  Maybe the XMLDSIG reference should just
> be changed to refer to the IOTP DSIG document.
### ALL references to XMLDSIG shall be changed to reflect IOTPDSIG
instead.###

>      There is a reference in  6.17.1 to payment scheme specific
> algorithms.
> Wouldn't their use be encapsulated inside the packaged contents and be in
> the payment scheme modules, not an IOTP implementation itself?
### Not necessarily. For example a Mondex purse application on a smart card
can be used to authenticate an individual using cryptography on the smart
card chip. This means that the "Algorithm" used for authenticatiojn purposes
could potentially be: SHA1, a digital signature, or a payment protocol
specific algorithm. Therefore suggest no change.###

>      Section 6.18: similarly for certificate reference.  Should point out
> that certs not needed for symmetric keying or for cases where public key
> has been registered at recipient.
### Agreed ###

> Section 6.19.2: For ElContIllegal, ValueTooSmall, and ValueTooLarge, I
> believe it should say "content" rather than "PackagedContent".
### Agreed ###

> TRIVIAL NITS:
> 
> In the Abstract and section 1, Delivery Handler is capitalized but payment
> handler isn't.
### Agreed ###

> It is not usual to have a section like 1.7, History, in an IETF document.
> If the evolution of a protocol sheds light on its technical content,
> that's
> one thing.  But it is not usual to have what is mostly a list of editing
> versions.  Suggest it be dropped to shorten the document.
### Agreed ###

> I'm not sure why there is a skip to new page before section 3.1 or 3.1.2.
> Suggest dropping these to make the document more compact.  RFC style is to
> have no skips to the start of a new page anywhere in the body text.
### This was caused by keeping figure 6 together with the immediately
preceeding lines. ###

> Section 3.8 example packaged content:  I don't like the "Name"s FirstMsg
> and SecondMsg.  Using Msg => Message seems confusing.  Suggest FirstPiece
> and SecondPiece.
### Changed ###

> Section 3.10 says "Where both types of net location are present, the
> following rules apply:" and then gives three rules only the third of which
> applies in the described circumstances.  Suggest moving the first two up
> and combining the quoted phrase with the third.
### Agreed ###

> Section 3.11.1 "treated by the recipient is an error": is -> as
### Fixed ###

> Section 4: "There are a several ..." delete "a"
### Fixed ###

> Section 4.4.1.2: in first sentence has -> have.
### Agreed ###

> Section 4.4.2.9: in first sentence, insert "server" between "the" and
> "unless".
> ### Agreed ###
> 
> Not sure why skip to new page before section 5.3.1 shortly before Figure
> 14
> which overflows onto next page by just one line...
### Fixed ###

> Section 5.3.1.1: numbered subsections, lettered subsubsections:  The text
> at the ends of these 12 subsubsections is substantially the same.
> Starting
> with 3)b) sometimes the final period is omitted.  Suggest moving this text
> up to the numbered section level or to before the whole two level list.
### Tidied up ###

> Section 5.3.1.2: ditto 5.3.1.1 except list is one level.
### Ditto ###

> Section 6.1: towards the end, delete "the" from "that the should".
### Fixed ###

> Section 6.2: Insert "may be" after "there" in "there only one".
### Fixed ###

> Section 6.5.5: PostalCode missing from detailed attributes list.
### Fixed ###

> Just before 6.6.3 and 6.7.1: "in10" -> "in section 10".
### Fixed ###

> Suggest replacing occurrences of "SSL" with "SSL/TLS" and adding the TLS
> RFC to the References.
### Agreed ###

> Section 6.11:  has "Plain/Text" where other similar sentences use "Plain
> Text" which is probably better.  The "/" makes it look like a MIME type
> and
> the MIME type is actually text/plain.  But I would suggest not using the
> MIME type as there isn't a unique one for HTML.
### Agreed ###

> Section 6.12.1: DelivReqNetLocn & SecDelivReqNotLocn: "Mechanism must" ->
> "Mechanism and must".
### Agreed ###

> Section 6.13: Content, should be "PackagedContent" not "Delivery Note".
### Agreed ###

> REFERENCES (section 14)
> 
> For DOM-HASH, can't refer to any Internet-Drafts by URL or filename.  For
> HMAC, suggest refereing to RFC 2104 HMAC: Keyed-Hashing for Message
> Authentication. H. Krawczyk, M. Bellare, R. Canetti. February 1997.
> 
> It looks pretty odd to the IETF spelled out in the RFC references.  I've
> never seen that in an IETF document references section.
> 
> For SET, suggest referencing the SETco.org site, not Mastercard.  Can't
> reference the Brown XMLDSIG draft in an RFC (although you can talk about
> it
> without a URL or file name reference if necessary).
> 
> 
> 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
> 
> 
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 

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

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

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

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

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

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: Country Codes
Date: Fri, 30 Apr 1999 00:00:52 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

A while back there was discussion about country codes (see emails from Tom
Arnold on 14 March and Don Eastlake on 17 March) that suggested 
	In the same manner that ISO4217 is specified for currency codes,
should country codes be specified to ISO3166? Also, does it matter if two or
three character codes are used?

In IOTP country is only used as part of an address (see Postal Address
Element). Therefore mandating use of country codes doesn't seem to be
necessary in my view as I can't think how it would be used although I'm open
to counter arguments.

Thoughts?

David
> mailto:<[email-masked]>
> Mondex International, US Advanced Technology Office
> 111 Pine St, 6th Floor, San Francisco, CA 94111
> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
> 

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

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

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

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

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

From: David Burdett <[email-masked]>
To: Yoshiaki KAWATSURA <[email-masked]>
Cc: Ietf Trade WG <[email-masked]>
Subject: RE: Question for IOTP Authentication
Date: Fri, 30 Apr 1999 00:00:54 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Yoshiaki

As you can see I'm catching up on all the Trade WG emails and have thought
about your suggestion. In principle I can see why allowing a Consumer to
authenticate a Merchant is reasonable as, in the current version of the
specification, it states that a Conumer can authenticate a Payment Handler
or a Delivery Handler (see section 8.1.13 second bullet point) and therefore
it is logical that a Consumer should also be able to authenticate a
Merchant.

However the method you suggest below for authenticating a Merchant is
different from the way the Consumer authenticates a Payment Handler or
Delivery Handler in that it is integrated into the transaction (e.g a
purchase) which implies a further variation on the message flow. So, I
suggest that we meet your requirement by simply changing the first bullet
point in section 8.1.13 to read the authentication transaction can be used
... " by a Consumer to authenticate a *Merchant*, Payment Handler or a
Delivery Handler ..."

Is this OK?

David

> ----------
> From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
> Sent: 	29 March 1999 22:45
> To: 	[email-masked]
> Cc: 	[email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: 	RE: Question for IOTP Authentication
> 
> David,
> I agree with your suggestion.
> But I also want to add the Merchant Authenticaton by Consumer 
> prior to IOTP Purchase Transaction.
> 
> These are the same flow as follows,
> 
> Consumer             Merchant
>    <-------------------
>          TPO
> 
>    ------------------->
>       Auth Req
> 
>    <------------------
>       Auth Res
> 
> and Status Block is not sent to the Merchant.
> 
> After Consumer receives the Auth Response,
> 1. If prior to IOTP purchase transaction
> Success: Consumer sends the message to the Success NetLocation.
> Fail: Stop
> 
> 2. If in the IOTP Purchase Transaction
> Success: Continue the transaction
> Fail: Stop.
> 
> Make sense?
> 
> This is minor change and I think there is no affect in the IOTP protocol.
> Regards,
> ----
> Yoshiaki Kawatsura : E-mail [email-masked]
>  Business & Information Systems Development Devision, Hitachi,Ltd.
> Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721
> 
> 
>  >>>>> Fri, 26 Mar 1999 18:20:48 -0000,
> 	 David Burdett <[email-masked]> said:
> 
>  >Yoshiaki
>  >
>  >The current version of IOTP does not support authentication of the
> Merchant
>  >by the Consumer. Part of the reasoning behind this is that the Merchant
> will
>  >include a signature in the offer which can be used for this purpose.
>  >HOwever, as you say, the consumer might not want to give address
> information
>  >until they have authenticated the Merchant.
>  >
>  >You could actually do this although section 8.1.13 does not specifically
>  >state this. What would be requried is that, after the Consumer has
> received
>  >the TPO, he authenticates the merchant with a separate Authentication
>  >transaction and then if its  OK continues with the original transaction.
>  >
>  >Would this make sense? If you think it does then please post the idea to
> the
>  >list. I don't know though if we want to include this in v1.0 although it
>  >could easily go into v 2.0
>  >
>  >David
>  >
>  >> ----------
>  >> From: 	Yoshiaki KAWATSURA[SMTP:[email-masked]]
>  >> Sent: 	25 March 1999 22:46
>  >> To: 	[email-masked]; [email-masked];
> [email-masked]
>  >> Cc: 	[email-masked]
>  >> Subject: 	Question for IOTP Authentication
>  >> 
>  >> Don and David,
>  >> I have a couple of question for IOTP Authentication.
>  >> 
>  >> Consumer wants to send private information such as home address to
>  >> authenticated merchants only for Offer. In fact, SET is attempting to
>  >> support simliar functionality. I believe that IOTP should support
> this.
>  >> 
>  >> IOTP version 1.0 cannot do this function in Offer Exchange, since the
>  >> Offer Exchange is simplified. The idea would be that initially IOTP
>  >> processes an Authentication, then a Web browser sends a private
>  >> information for Offer, and finally IOTP does Purchase Transaction. In
>  >> IOTP version 1.0, IOTP supports a Consumer Authentication by Merchant,
>  >> however, IOTP does not support a Merchant Authentication by
>  >> Consumer. Is this correct?
>  >> 
>  >> If this is correct, will IOTP version 2.0 support the Merchant
>  >> Authentication by Consumer?
>  >> 
>  >> Regards,
>  >> 
>  >> --
>  >> Yoshiaki Kawatsura
>  >> Hitachi, Ltd.
>  >> 
>  >
> 
> 
> 
> 

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

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

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

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

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

To: IETF-Announce: ;
cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-eastlake-card-map-05.txt
Date: Thu, 29 Apr 1999 17:08:37 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

--NextPart

This is a retransmission of an earlier announcement, correcting the author's 
name.

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : ISO 7812/7816 Based Card Numbers and the
			  Domain Name System (DNS)
	Author(s)	: D. Eastlake
	Filename	: draft-eastlake-card-map-05.txt
	Pages		: 17
	Date		: 27-Apr-99
	
There are a variety of servers, web pages, and the like, which
holders of ISO 7812 financial transaction identification card numbers
and ISO 7816 smart card or related numbers may need to locate on the
Internet. For example, some systems assume a smart card holder can
contact the issuer of a smart card application for maintenance and
update functions and the SET protocol assumes that a card holder can
locate the appropriate certification authority to obtain a card
holder certificate. This document specifies a method using the DNS as
an important element in locating card related facilities on the
Internet by mapping ISO 7812 and ISO 7816 based number systems into
domain names within in the card.reg.int domain.
Disclaimer
 
The methods proposed herein are not, at the time of the issuance of
this document, endorsed by the credit card brands or associations for
Use in connection with SET.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-eastlake-card-map-05.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-eastlake-card-map-05.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-eastlake-card-map-05.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-eastlake-card-map-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-eastlake-card-map-05.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 Trade WG <[email-masked]>
Subject: Re: Using XML as well as HTML 
Date: Thu, 29 Apr 1999 13:04:10 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I believe that support for XML should be recommended but not required.

Thanks,
Donald

From:  David Burdett <[email-masked]>
Message-Id:  <[email-masked]>
To:  Ietf Trade WG <[email-masked]>
Date:  Thu, 29 Apr 1999 17:17:05 +0100

>Following on from my other email on using HTML, the spec doesn't currently
>describe how XML could be used. I think that it should. We could provide
>similar guidelines for XML/XSL to the ones for HTML. 
>
>Who thinks this is a good idea?
>
>David
>
>THIS EMAIL IS FOR UNRESTRICTED DISTRIBUTION
>> mailto:<[email-masked]>
>> Mondex International, US Advanced Technology Office
>> 111 Pine St, 6th Floor, San Francisco, CA 94111
>> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: RE: Links in HTML data
Date: Thu, 29 Apr 1999 17:17:04 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I think I better add some clarification on this topic.

Initially, the IOTP specs said that order descriptions, payment notes, etc,
should be simple "plain text" to ensure interoperability and help avoid the
problems that Hannu, Donn and Eric have described. It was then realised that
both pilot implementations based on the v 0.9 spec used HTML and/or XML and
not "plain text".

Conclusion: People don't want to use plain text therefore we better include
a method of handling HTML or XML in the specification. If we don't then
people will use HTML/XML anyway and pretty well all implementations will be
non-conformant !!

Exactly what the specification currently says is attached below but
essentially it is designed to avoid the problems that have been raised.
Don's comment was the sentence at the end of the second bullet point which
says:

	"... the "Main" Packaged Content element must not be referred to
from the HTML in any other Packaged Content"

The general idea is that packaged HTML should really appear to the user as a
simple single or multi page document, much like users would receive in the
real world, where *everything* required to generate the document is included
as packaged content in the Order Description. It therefore doesn't really
make sense, in my view, to be able to follow a link that takes you to the
"Main" packaged content from elsewhere.

On the other hand you don't want to ban links entirely for example you might
want to include in the HTML buttons which say "click here for customer care"
which could take you to a web page where you could report problems. This
could make sense. However another a link which dynamically downloaded over
the web a GIF of your order description would not since the GIF could be
changed after the event. IMOH though I don't think this type of behaviour by
merchants will be particularly widespread. Thoughts anyone on this topic?

David

======= Extract from the v 03 spec ========
  3.8.1 Packaging HTML

  The packaged content may contain HTML. In this case the following
  conventions are followed:

  o references to any documents, images or other things, such as
    sounds or web pages, which can affect the recipient's
    understanding of the data which is being packaged must refer to
    other Packaged Elements contained within the same parent
    element, e.g. an Order Description

  o if more than one Packaged Content element is included within a
    parent element in order to meet the previous requirement, then
    the Name attribute of the top level Packaged Content from which
    references to all other Packaged Elements can be determined,
    should have a value of Main. This means that the "Main"
    Packaged Content element must not be referred to from the HTML
    in any other Packaged Content

  o relative references to other documents, images, etc. from one
    Packaged Content element to another are realised by setting the
    value of the relative reference to the Name attribute of
    another Packaged Content element at the same level and within
    the same parent element

  o no external references that require the reference to be
    resolved immediately should be used. As this could make the
    HTML difficult or impossible to display completely

  o [MIME] is used to encapsulate the data inside each Packaged
    Element. This means that the information in the MIME header
    used to identify the type of data which has been encapsulated
    and therefore how it should be displayed.

  If the above conventions are not followed by, for example, including
  external references which must be resolved, then the recipient of the
  HTML should be informed.

  [Note]   As an implementation guideline the values of the Name
           Attributes allocated to Packaged Content elements should
           make it possible to extract each Packaged Content into a
           directory and then display the HTML directly
  [Note End]             

> ----------
> From: 	Hannu Nikkanen[SMTP:[email-masked]]
> Sent: 	29 April 1999 01:05
> To: 	Ietf Trade WG
> Subject: 	Re: Links in HTML data
> 
> Hi,
> 
> I believe that "what you see is what you sign" would be a better approach.
> 
> In principle, graphics could be used to insert logos of other companies or
> some text, which the signer could not distinguish from the signed part.
> 
> Even if the risk is low, it may lower consumer trust, which probably is
> one
> of the main commercial goals. 
> 
> Hannu
> 
> At 22:45 28.4.1999 +0100, you wrote:
> >Don Eastlake says in his email:
> >
> >	"Section 3.8.1: I don't understand why sub-pages of an HTML main
> >page couldn't have links back to the main page."
> >
> >In IOTP, where HTML is being used to describe a document such as an order
> >description or a payment note, then it is, in many ways being provided as
> an
> >alternative to a single, or multi-page "real world" document. These
> >documents should not in general be :"multi-media" documents, since for
> >purposes of non-refutability, the document should be self-contained and
> not
> >reliant on other records held elsewhere. For this reason links should
> only
> >be used to allow, for example, graphics and other display devices to be
> >included in the document.
> >
> >Therefore in my opinion, this should not be allowed. What do other people
> >think?
> >
> >David
> >> mailto:<[email-masked]>
> >> Mondex International, US Advanced Technology Office
> >> 111 Pine St, 6th Floor, San Francisco, CA 94111
> >> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
> >> 
> >
> >*************************************************************************
> ***
> >******************
> >
> >This Email and any attached files are confidential and may also be
> privileged. 
> >If you are not the intended recipient, please notify the postmaster using
> 
> >email 
> >address [email-masked] or call +44 171 557 5000 and ask for the 
> >IT Helpdesk.  You should not copy this email and any attached files, use
> them 
> >for any purpose or disclose the contents to any other person; all copies
> of 
> >the 
> >Email and associated files in your possession should be destroyed.
> >
> >Mondex International Limited
> >47-53 Cannon Street
> >London EC4M 5SQ
> >United Kingdom
> >Registered No: 3122085, England
> >
> >Phone:          +44 171 557 5000
> >Fax:            +44 171 557 5200
> >Email:          [email-masked]
> >WebSite:        http://www.mondexinternational.com
> >
> >*************************************************************************
> ***
> >*****************
> >-----------------------------------------------------------------------
> >Message addressed to: [email-masked]
> >Archive available at: http://www.elistx.com/archives/ietf-trade/
> >To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> >body to: [email-masked]
> 
> 
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 

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

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

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

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

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

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: Using XML as well as HTML
Date: Thu, 29 Apr 1999 17:17:05 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Following on from my other email on using HTML, the spec doesn't currently
describe how XML could be used. I think that it should. We could provide
similar guidelines for XML/XSL to the ones for HTML. 

Who thinks this is a good idea?

David

THIS EMAIL IS FOR UNRESTRICTED DISTRIBUTION
> mailto:<[email-masked]>
> Mondex International, US Advanced Technology Office
> 111 Pine St, 6th Floor, San Francisco, CA 94111
> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
> 

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

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

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

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

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

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Cc: "Lewis, Tony" <[email-masked]>
Subject: RE: Brand IDs & their registration. Was: RE: Comments on draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part  1
Date: Thu, 29 Apr 1999 17:17:01 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I agree with Tony. Smart card based EMV transactions will be the dominant
payment model within a decade, probably even earlier especially in the
non-US part of the world. The main reasons being, in my view:
*	it will reduce fraud as it's much much harder to copy a smart card
than a mag stripe card
*	it makes internet credit card payments "card present" transactions
which should result in lower merchant fees. This also means that it will be
much harder for customers to claim they never made an internet purchase
*	using a multi-application smart card you will be able to use just
one smart card for debit, credit, electronic cash, a loyalty scheme as well
as hold electronic tickets for anything from local cinema to your next
flight.

To rephrase a MasterCard ad line, "smart cards are the future of money".

David

> ----------
> From: 	Lewis, Tony[SMTP:[email-masked]]
> Sent: 	28 April 1999 20:30
> To: 	Ietf Trade WG
> Subject: 	RE: Brand IDs & their registration. Was: RE: Comments on
> draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part  1
> 
> My point is that the brand is "Visa" no matter whether using IOTP, SET or
> any other protocol.
> 
> As for EMV, the very first live SET 1.0 transaction was made using an EMV
> card with the EMV data carried inside a SET message extension. EMV credit
> and debit products are a significant part of the future of electronic
> commerce. I expect they will be the dominant model for payment in a
> decade.
> 
> Tony
> > ----------
> > From: 	Steve Fabes[SMTP:[email-masked]]
> > Sent: 	Wednesday, April 28, 1999 3:43 PM
> > To: 	Lewis, Tony; Ietf Trade WG
> > Subject: 	Re: Brand IDs & their registration. Was: RE: Comments on
> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > 
> > Tony - do your comments infer that SET.Visa will be the only e-Commerce
> > product that an IOTP product supplier can expect to see. Can you see a
> day
> > when a Visa EMV 3.1.1 (or 3.x.x) based credit product could also be used
> > inside an IOTP product?
> > -----Original Message-----
> > From: Lewis, Tony <[email-masked]>
> > To: Ietf Trade WG <[email-masked]>
> > Date: Wednesday, April 28, 1999 13:21
> > Subject: RE: Brand IDs & their registration. Was: RE: Comments on
> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > 
> > 
> > >David,
> > >
> > >I am new to this group and do not know what lead to the current
> approach.
> > >There are undoubtedly some issues that I don't know about. However, it
> > seems
> > >to me that a brand is a brand no matter what payment protocol is being
> > used.
> > >The only difference I see between "IOTP:Visa" and "SET:Visa" is that
> the
> > >latter indicates that the brand is supported by a specific payment
> > protocol.
> > >Since you need to support brands other than those supported by SET,
> there
> > >will need to be a registry. It seems to me that there should only be
> one
> > >such registry rather than the two being proposed. I recommend having a
> > >single domain for these brands. It seems reasonable to initially
> populate
> > it
> > >using the brands registered with SET and those non-SET brands you
> listed
> > in
> > >your note.
> > >
> > >Tony
> > >> ----------
> > >> From: David Burdett[SMTP:[email-masked]]
> > >> Sent: Wednesday, April 28, 1999 11:36 AM
> > >> To: Ietf Trade WG; Lewis, Tony
> > >> Subject: Brand IDs & their registration. Was: RE: Comments on
> > >> draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
> > >>
> > >> In the current specification the basic idea for identifying brands is
> > that
> > >> they should be of the form "xxx:brandid" where "xxx" can be "SET"
> which
> > >> indicates that the brandid is any valid brandid that is accepted by
> > SET,
> > >> or
> > >> alternatively "IOTP" which can be used to define any brand not
> defined
> > by
> > >> SET. The idea was that we should not need to define "Visa",
> > "MasterCard",
> > >> "American Express", etc more than once since they are already defined
> > and
> > >> registered by SET.
> > >>
> > >> However a couple of problems may arise ...
> > >>
> > >> USING THE SET BRAND ID FOR NON-SET PAYMENTS
> > >> Although IOTP can support SET as a payment protocol, it can also
> > support
> > >> credit card payments (using Secure Channel Credit Debit - SCCD) where
> > the
> > >> credit card information (no, name, expiration date, etc) is coded
> > >> effectively in the clear but with privacy protection provided by
> using
> > a
> > >> secure channel such as SSL. In this way it provides a similar level
> of
> > >> privacy/security as for credit card payments that occur now where a
> web
> > >> page
> > >> form is completed by the user.
> > >>
> > >> My question is, will it be reasonable to use the SET brandid in this
> > way
> > >> to
> > >> cover non-SET credit card payments. I *think* the answer is "yes" as
> > you
> > >> can
> > >> quite imagine a situation where a consumer is offered a choice of
> using
> > >> their VISA credit card to pay using either SET or SCCD.
> > >>
> > >> WHAT BRAND ID SHOULD BE USED FOR CO BRANDS
> > >> If a payment brand, such as a local brand or co-brand, chooses,
> > initiall
> > >> to
> > >> use just SCCD rather than SET then they would not (I think) need to
> > >> register
> > >> their brand with SET. In this case, they might register their brand
> as
> > an
> > >> "IOTP" brand. However if they later adopted SET, they would end up
> with
> > >> potentially two equivalent Brand IDs. Do you think we might be better
> > off
> > >> with a straight IOTP brand and keep all the names under the
> procedures
> > >> defined by IANA? I'm not sure?
> > >>
> > >> REGISTERING NEW BRAND IDs
> > >> To help assist in answering the last point, the following is what I'm
> > >> currently writing as the proposed IANA procedure for registering new
> > brand
> > >> ids. Any comments:
> > >>
> > >> >>>Clip>>>
> > >> The format of the Brand ID is either:
> > >> * SET:setbrand where setbrand is a brand which is accepted by the
> > >> [SET] payment protocol
> > >> * IOTP:iotpbrand where iotpbrand may be:
> > >> - GeldKarte
> > >> - Mondex
> > >>
> > >> New values of the high level prefix (SET or IOTP) should be allocated
> > >> following review on the IETF Trade Working Group mailing list and by
> > the
> > >> Designated Expert.
> > >>
> > >> Values of "setbrand" are allocated as defined in the [SET]
> > specifications.
> > >>
> > >> New values of "iotpbrand" must be announced to the IETF Trade WG
> > mailing
> > >> list and, if there are no objections within three weeks, be allocated
> > on
> > a
> > >> "first come first served" basis.
> > >> <<<End Clip<<<
> > >>
> > >> Regards
> > >>
> > >> David
> > >> > ----------
> > >> > From: Lewis, Tony[SMTP:[email-masked]]
> > >> > Sent: 28 April 1999 08:14
> > >> > To: Ietf Trade WG
> > >> > Subject: RE: Comments on
> draft-ietf-trade-iotp-v1.0-protocol-03.txt,
> > >> > part  1
> > >> >
> > >> > In SET, the BrandID is either "brand" or "brand:product".
> > >> >
> > >> > In Japan, there are products that are co-branded. Essentially these
> > >> > products
> > >> > are private label cards for domestic transactions with an
> > international
> > >> > brand for non-domestic transactions. The private label can be
> > reflected
> > >> in
> > >> > a
> > >> > SET cardholder certificate as the "promotional card name" under the
> > >> > international brand's hierarchy and/or the cardholder can have a
> > >> > certificate
> > >> > issued under the private label hierarchy.
> > >> >
> > >> > There is no provision to carry both the private label (of the
> > Japanese
> > >> > credit card company) and the international brand as part of the SET
> > >> > BrandID.
> > >> >
> > >> > Tony
> > >> > > ----------
> > >> > > From: David Burdett[SMTP:[email-masked]]
> > >> > > Sent: Tuesday, April 27, 1999 6:31 PM
> > >> > > To: Ietf Trade WG; [email-masked]
> > >> > > Subject: RE: Comments on
> > draft-ietf-trade-iotp-v1.0-protocol-03.txt,
> > >> > > part  1
> > >> > >
> > >> > > I'm working my way through Don's comments and came across this
> one
> > >> where
> > >> > > our
> > >> > > friends in Japan might be able to help ... I think ...
> > >> > >
> > >> > > Don says ...
> > >> > >
> > >> > > "I looked around a bit in SET literature and couldn't find
> anything
> > >> > > about Dual or Promotional brands or anything about a three
> > component
> > >> SET
> > >> > > Brand.  Two components, "brand" and "product" I see in the SET
> > >> > literature,
> > >> > > such a "MasterCard" or "Visa:Gold".  But not A:B:C and no case
> > where
> > a
> > >> > > colon
> > >> > > is included if there isn't anything after it.  In other words,
> it's
> > >> > > "Visa",
> > >> > > not "Visa:", and certainly not "Visa::" as a SET brand (re also
> > >> examples
> > >> > > in
> > >> > > 6.6.1)."
> > >> > >
> > >> > > This requirement arose as a result of meeting the needs of the
> > Japan
> > >> > > market.
> > >> > > Can some people who are more familiar with this, please have a
> look
> > at
> > >> > > this
> > >> > > part of the spec and check it is ok please?
> > >> > >
> > >> > > David
> > >> > >
> > >> > > > ----------
> > >> > > > From: [email-masked][SMTP:[email-masked]]
> > >> > > > Sent: 22 April 1999 15:25
> > >> > > > To: [email-masked]
> > >> > > > Subject: Comments on
> > >> draft-ietf-trade-iotp-v1.0-protocol-03.txt, part
> > >> > > > 1
> > >> > > >
> > >> > > > I've done a careful review of the document through section 6
> and
> > >> > section
> > >> > > > 13
> > >> > > > and greater and came up with the following somewhat length list
> > of
> > >> > > > suggestions.  I don't think they substantially change the
> > intended
> > >> > > meaning
> > >> > > > of the document but those on the list should judge that.
> > >> > > >
> > >> > > >
> > >> > > > IMPORTANT:
> > >> > > >
> > >> > > > "IANA Considerations" needs to be a top level section, perhaps
> > #11.
> > >> > > > Gathering this stuff together into 3.7.3 is good but its still
> > >> > > > unreasonable
> > >> > > > to expect IANA to comb the document to find it.
> > >> > > >      I'm not sure about the criteria for registration.  "IETF
> > >> > Consensus"
> > >> > > > is
> > >> > > > pretty stiff and requires a vote of the IESG.  I should think
> > >> someone
> > >> > > > could
> > >> > > > register an IOTP Band or CurrCode by publishing an RFC.
> Perhaps
> > >> that
> > >> > is
> > >> > > > what you mean for ProtocolId but it is not clear.
> > >> > > >      Toward end so 3.7.3, change "with" to "without".
> > >> > > >
> > >> > > >
> > >> > > > MISCELLANEOUS:
> > >> > > >
> > >> > > > I don't understand the difference between "Objectives" and
> > >> "Purpose".
> > >> > I
> > >> > > > suggest that 1.4 and 1.5 be merged and that the reference to
> > "IOTP
> > >> > > > Business
> > >> > > > Description" which, as far as I know, is not intended to ever
> > become
> > >> > an
> > >> > > > IETF document, be dropped.
> > >> > > >
> > >> > > > Section 1.7 still refers to an XML Overview section 11.
> > >> > > >
> > >> > > > Page spanning figures, like Figure 3, are really pretty messy.
> > It
> > >> > would
> > >> > > > be
> > >> > > > better if the text could be made much more terse and this and
> > >> similar
> > >> > > > figures started high on a page so they aren't split by a page
> > >> > boundary.
> > >> > > >
> > >> > > > Section 2.2: suggest "The Open Trading Protocols identify" be
> > >> changed
> > >> > to
> > >> > > > "IOTP identifies".
> > >> > > > Section 2.2: says "IOTP Transactions are composed of these
> > >> exchanges"
> > >> > > but
> > >> > > > does not list Inquiry or Ping exchange.
> > >> > > >
> > >> > > > Starting in section 2.3 and many other places in the document,
> > words
> > >> > or
> > >> > > > phrases are prefixed and suffixed by an underscore character
> > ("_").
> > >> > > This
> > >> > > > is not any normal IETF style.  I suspect it means that the
> > original
> > >> > text
> > >> > > > is
> > >> > > > italic.  These should be suppressed or if that is impossible, a
> > >> > separate
> > >> > > > pass should be done to delete them.
> > >> > > >
> > >> > > > In Figure 9, the things which are supposed to be identical or
> > match
> > >> > > aren't
> > >> > > > and don't.  Is that deliberate?
> > >> > > >
> > >> > > > I don't think that section 3.6 Brands and Brand Selection fits
> > very
> > >> > well
> > >> > > > where it and suggest it be moved into section 10 which could be
> > >> > renamed
> > >> > > > "Brands".
> > >> > > >      Continuing on Brands, I looked around a bit in SET
> > literature
> > >> and
> > >> > > > couldn't find anything about Dual or Promotional brands or
> > anything
> > >> > > about
> > >> > > > a
> > >> > > > three component SET Brand.  Two components, "brand" and
> "product"
> > I
> > >> > see
> > >> > > in
> > >> > > > the SET literature, such a "MasterCard" or "Visa:Gold".  But
> not
> > >> A:B:C
> > >> > > and
> > >> > > > no case where a colon is included if there isn't anything after
> > it.
> > >> > In
> > >> > > > other words, it's "Visa", not "Visa:", and certainly not
> "Visa::"
> > as
> > >> a
> > >> > > SET
> > >> > > > brand (re also examples in 6.6.1). Can anyone give me any
> > references
> > >> > to
> > >> > > > shed light on this?
> > >> > > >
> > >> > > > Section 3.8.1: I don't understand why sub-pages of an HTML main
> > page
> > >> > > > couldn't have links back to the main page.
> > >> > > >
> > >> > > > Section 4.1: first section reference says "0"?
> > >> > > >
> > >> > > > Figures 10 and 11: These flow diagrams each *almost* fit on a
> > page.
> > >> If
> > >> > > the
> > >> > > > initial "Input IOTP Message" box could be to the side with a

> > >> > horizontal
> > >> > > > arrow and the text were edited down to something a bit more
> > terse,
> > I
> > >> > > think
> > >> > > > they would, which would be quite helpful.
> > >> > > >
> > >> > > > Section 5: Suggest this section be called "Digital Signature"
> or
> > >> > > > something.
> > >> > > > Usually an IETF Security Considerations section is brief and
> > talks
> > >> > about
> > >> > > > really high level issues.  Material in 5.4 is appropriate for
> > >> Security
> > >> > > > Considerations.  A separate Security Considerations section
> would
> > >> need
> > >> > > to
> > >> > > > also say something about deciding when to require signatures,
> > even
> > >> if
> > >> > it
> > >> > > > is
> > >> > > > just by referring to section 5.1.4, and about depending on
> > payment
> > >> > > scheme
> > >> > > > security for the safety of funds, which I didn't see anywhere.
> > >> > > >      Section 5 seems pretty heavy on certificates and public
> key
> > >> > crypto,
> > >> > > > especially given the originally IOTP v1.0 was going to be
> secret
> > key
> > >> > > only
> > >> > > > and, as I recall, it was with some reluctance that public key
> > hooks
> > >> > were
> > >> > > > added.  The stuff on checking a signature, for example, talks
> > about
> > >> > > > checking the certificate as if there always has to be one.
> > >> > > >      Section 5.1.4: another reason you might not need
> signatures
> > is
> > >> > the
> > >> > > > that the sender and receiver were on the same machine so it can
> > >> check
> > >> > > > integrity just by comparing with a saved copy.
> > >> > > >
> > >> > > > Section 6.4.2: Need to eliminate reference to "Open Trading
> > Protocol
> > >> > > > Consortium" and suggest dropping whole note. I don't see any
> > >> > difference
> > >> > > at
> > >> > > > all between OkTo/OkFrom and amount.  Both could appear in human
> > >> > readable
> > >> > > > form in the Order Description and in machine readable form in
> > their
> > >> > > > element.  Recommending that the UI display the machine readable
> > >> > version
> > >> > > is
> > >> > > > reasonable (as in 6.4.1).
> > >> > > >
> > >> > > > ContentSoftwareId: the standard text given for this is quite
> > length
> > >> > and
> > >> > > > repeated dozens of time.  If it could be moved to the glossary
> or
> > >> > > > something
> > >> > > > and a simple "see glossary" put in, it would save many pages.
> > >> > > >
> > >> > > > As previously discussed, change ISO4217 to ISO4217A or the
> like.
> > >> > > >
> > >> > > > Just before section 6.7, it says that examples exist in 6.6
> when
> > >> they
> > >> > > are
> > >> > > > in 10.
> > >> > > >
> > >> > > > Section 6.17: references to the Richard Brown draft and
> probably
> > not
> > >> > > > appropriate.  RFCs are not supposed to refer to drafts.  About
> > the
> > >> > > future,
> > >> > > > I'm not sure you need to say anything but if you do, I think it
> > >> should
> > >> > > > just
> > >> > > > say the future versions of IOTP will use industry standard XML
> > >> > signature
> > >> > > > technology if it meets IOTP requirements.
> > >> > > >      Shouldn't 6.17.1 refer to the IOTP DSIG document?  It's OK
> > to
> > >> > refer
> > >> > > > to
> > >> > > > that draft because the idea is that it and the main protocol
> > >> document
> > >> > > will
> > >> > > > be issued as RFCs simultaneously.  Maybe the XMLDSIG reference
> > >> should
> > >> > > just
> > >> > > > be changed to refer to the IOTP DSIG document.
> > >> > > >      There is a reference in  6.17.1 to payment scheme specific
> > >> > > > algorithms.
> > >> > > > Wouldn't their use be encapsulated inside the packaged contents
> > and
> > >> be
> > >> > > in
> > >> > > > the payment scheme modules, not an IOTP implementation itself?
> > >> > > >      Section 6.18: similarly for certificate reference.  Should
> > >> point
> > >> > > out
> > >> > > > that certs not needed for symmetric keying or for cases where
> > public
> > >> > key
> > >> > > > has been registered at recipient.
> > >> > > >
> > >> > > > Section 6.19.2: For ElContIllegal, ValueTooSmall, and
> > ValueTooLarge,
> > >> I
> > >> > > > believe it should say "content" rather than "PackagedContent".
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > TRIVIAL NITS:
> > >> > > >
> > >> > > > In the Abstract and section 1, Delivery Handler is capitalized
> > but
> > >> > > payment
> > >> > > > handler isn't.
> > >> > > >
> > >> > > > It is not usual to have a section like 1.7, History, in an IETF
> > >> > > document.
> > >> > > > If the evolution of a protocol sheds light on its technical
> > content,
> > >> > > > that's
> > >> > > > one thing.  But it is not usual to have what is mostly a list
> of
> > >> > editing
> > >> > > > versions.  Suggest it be dropped to shorten the document.
> > >> > > >
> > >> > > > I'm not sure why there is a skip to new page before section 3.1
> > or
> > >> > > 3.1.2.
> > >> > > > Suggest dropping these to make the document more compact.  RFC
> > style
> > >> > is
> > >> > > to
> > >> > > > have no skips to the start of a new page anywhere in the body
> > text.
> > >> > > >
> > >> > > > Section 3.8 example packaged content:  I don't like the "Name"s
> > >> > FirstMsg
> > >> > > > and SecondMsg.  Using Msg => Message seems confusing.  Suggest
> > >> > > FirstPiece
> > >> > > > and SecondPiece.
> > >> > > >
> > >> > > > Section 3.10 says "Where both types of net location are
> present,
> > the
> > >> > > > following rules apply:" and then gives three rules only the
> third
> > of
> > >> > > which
> > >> > > > applies in the described circumstances.  Suggest moving the
> first
> > >> two
> > >> > up
> > >> > > > and combining the quoted phrase with the third.
> > >> > > >
> > >> > > > Section 3.11.1 "treated by the recipient is an error": is -> as
> > >> > > >
> > >> > > > Section 4: "There are a several ..." delete "a"
> > >> > > >
> > >> > > > Section 4.4.1.2: in first sentence has -> have.
> > >> > > >
> > >> > > > Section 4.4.2.9: in first sentence, insert "server" between
> "the"
> > >> and
> > >> > > > "unless".
> > >> > > >
> > >> > > > Not sure why skip to new page before section 5.3.1 shortly
> before
> > >> > Figure
> > >> > > > 14
> > >> > > > which overflows onto next page by just one line...
> > >> > > >
> > >> > > > Section 5.3.1.1: numbered subsections, lettered subsubsections:
> > The
> > >> > > text
> > >> > > > at the ends of these 12 subsubsections is substantially the
> same.
> > >> > > > Starting
> > >> > > > with 3)b) sometimes the final period is omitted.  Suggest
> moving
> > >> this
> > >> > > text
> > >> > > > up to the numbered section level or to before the whole two
> level
> > >> > list.
> > >> > > >
> > >> > > > Section 5.3.1.2: ditto 5.3.1.1 except list is one level.
> > >> > > >
> > >> > > > Section 6.1: towards the end, delete "the" from "that the
> > should".
> > >> > > >
> > >> > > > Section 6.2: Insert "may be" after "there" in "there only one".
> > >> > > >
> > >> > > > Section 6.5.5: PostalCode missing from detailed attributes
> list.
> > >> > > >
> > >> > > > Just before 6.6.3 and 6.7.1: "in10" -> "in section 10".
> > >> > > >
> > >> > > > Suggest replacing occurrences of "SSL" with "SSL/TLS" and
> adding
> > the
> > >> > TLS
> > >> > > > RFC to the References.
> > >> > > >
> > >> > > > Section 6.11:  has "Plain/Text" where other similar sentences
> use
> > >> > "Plain
> > >> > > > Text" which is probably better.  The "/" makes it look like a
> > MIME
> > >> > type
> > >> > > > and
> > >> > > > the MIME type is actually text/plain.  But I would suggest not
> > using
> > >> > the
> > >> > > > MIME type as there isn't a unique one for HTML.
> > >> > > >
> > >> > > > Section 6.12.1: DelivReqNetLocn & SecDelivReqNotLocn:
> "Mechanism
> > >> must"
> > >> > > ->
> > >> > > > "Mechanism and must".
> > >> > > >
> > >> > > > Section 6.13: Content, should be "PackagedContent" not
> "Delivery
> > >> > Note".
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > REFERENCES (section 14)
> > >> > > >
> > >> > > > For DOM-HASH, can't refer to any Internet-Drafts by URL or
> > filename.
> > >> > > For
> > >> > > > HMAC, suggest refereing to RFC 2104 HMAC: Keyed-Hashing for
> > Message
> > >> > > > Authentication. H. Krawczyk, M. Bellare, R. Canetti. February
> > 1997.
> > >> > > >
> > >> > > > It looks pretty odd to the IETF spelled out in the RFC
> > references.
> > >> > I've
> > >> > > > never seen that in an IETF document references section.
> > >> > > >
> > >> > > > For SET, suggest referencing the SETco.org site, not
> Mastercard.
> > >> > Can't
> > >> > > > reference the Brown XMLDSIG draft in an RFC (although you can
> > talk
> > >> > about
> > >> > > > it
> > >> > > > without a URL or file name reference if necessary).
> > >> > > >
> > >> > > >
> > >> > > > 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
> > >> > > >
> > >> > > >
> > >> > > >
> > >> >
> > -----------------------------------------------------------------------
> > >> > > > Message addressed to: [email-masked]
> > >> > > > Archive available at:
> http://www.elistx.com/archives/ietf-trade/
> > >> > > > To (un)subscribe send a message with "subscribe" or
> "unsubscribe"
> > in
> > >> > the
> > >> > > > body to: [email-masked]
> > >> > > >
> > >> > >
> > >> > >
> > >> >
> > >>
> >
> **************************************************************************
> > >> > > ********************
> > >> > >
> > >> > > This Email and any attached files are confidential and may also
> be
> > >> > > privileged.
> > >> > > If you are not the intended recipient, please notify the
> postmaster
> > >> > using
> > >> > > email
> > >> > > address [email-masked] or call +44 171 557 5000 and ask
> for
> > the
> > >>
> > >> > > IT Helpdesk.  You should not copy this email and any attached
> > files,
> > >> use
> > >> > > them
> > >> > > for any purpose or disclose the contents to any other person; all
> > >> copies
> > >> > > of the
> > >> > > Email and associated files in your possession should be
> destroyed.
> > >> > >
> > >> > > Mondex International Limited
> > >> > > 47-53 Cannon Street
> > >> > > London EC4M 5SQ
> > >> > > United Kingdom
> > >> > > Registered No: 3122085, England
> > >> > >
> > >> > > Phone:          +44 171 557 5000
> > >> > > Fax:            +44 171 557 5200
> > >> > > Email:          [email-masked]
> > >> > > WebSite:        http://www.mondexinternational.com
> > >> > >
> > >> > >
> > >> >
> > >>
> >
> **************************************************************************
> > >> > > *******************
> > >> > >
> > >>
> -----------------------------------------------------------------------
> > >> > > Message addressed to: [email-masked]
> > >> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > >> > > To (un)subscribe send a message with "subscribe" or "unsubscribe"
> > in
> > >> the
> > >> > > body to: [email-masked]
> > >> > >
> > >> >
> > -----------------------------------------------------------------------
> > >> > Message addressed to: [email-masked]
> > >> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > >> > To (un)subscribe send a message with "subscribe" or "unsubscribe"
> in
> > the
> > >> > body to: [email-masked]
> > >> >
> > >>
> > >>
> >
> **************************************************************************
> > >> ********************
> > >>
> > >> This Email and any attached files are confidential and may also be
> > >> privileged.
> > >> If you are not the intended recipient, please notify the postmaster
> > using
> > >> email
> > >> address [email-masked] or call +44 171 557 5000 and ask for
> the
> > >> IT Helpdesk.  You should not copy this email and any attached files,
> > use
> > >> them
> > >> for any purpose or disclose the contents to any other person; all
> > copies
> > >> of the
> > >> Email and associated files in your possession should be destroyed.
> > >>
> > >> Mondex International Limited
> > >> 47-53 Cannon Street
> > >> London EC4M 5SQ
> > >> United Kingdom
> > >> Registered No: 3122085, England
> > >>
> > >> Phone:          +44 171 557 5000
> > >> Fax:            +44 171 557 5200
> > >> Email:          [email-masked]
> > >> WebSite:        http://www.mondexinternational.com
> > >>
> > >>
> >
> **************************************************************************
> > >> *******************
> > >>
> -----------------------------------------------------------------------
> > >> Message addressed to: [email-masked]
> > >> Archive available at: http://www.elistx.com/archives/ietf-trade/
> > >> To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> > the
> > >> body to: [email-masked]
> > >>
> > >-----------------------------------------------------------------------
> > >Message addressed to: [email-masked]
> > >Archive available at: http://www.elistx.com/archives/ietf-trade/
> > >To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> > >body to: [email-masked]
> > >
> > 
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 

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

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

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

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

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

Date: Thu, 29 Apr 1999 11:05:13 +0300
To: Ietf Trade WG <[email-masked]>
From: Hannu Nikkanen <[email-masked]>
Subject: Re: Links in HTML data
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Hi,

I believe that "what you see is what you sign" would be a better approach.

In principle, graphics could be used to insert logos of other companies or
some text, which the signer could not distinguish from the signed part.

Even if the risk is low, it may lower consumer trust, which probably is one
of the main commercial goals. 

Hannu

At 22:45 28.4.1999 +0100, you wrote:
>Don Eastlake says in his email:
>
>	"Section 3.8.1: I don't understand why sub-pages of an HTML main
>page couldn't have links back to the main page."
>
>In IOTP, where HTML is being used to describe a document such as an order
>description or a payment note, then it is, in many ways being provided as an
>alternative to a single, or multi-page "real world" document. These
>documents should not in general be :"multi-media" documents, since for
>purposes of non-refutability, the document should be self-contained and not
>reliant on other records held elsewhere. For this reason links should only
>be used to allow, for example, graphics and other display devices to be
>included in the document.
>
>Therefore in my opinion, this should not be allowed. What do other people
>think?
>
>David
>> mailto:<[email-masked]>
>> Mondex International, US Advanced Technology Office
>> 111 Pine St, 6th Floor, San Francisco, CA 94111
>> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
>> 
>
>****************************************************************************
>******************
>
>This Email and any attached files are confidential and may also be
privileged. 
>If you are not the intended recipient, please notify the postmaster using 
>email 
>address [email-masked] or call +44 171 557 5000 and ask for the 
>IT Helpdesk.  You should not copy this email and any attached files, use them 
>for any purpose or disclose the contents to any other person; all copies of 
>the 
>Email and associated files in your possession should be destroyed.
>
>Mondex International Limited
>47-53 Cannon Street
>London EC4M 5SQ
>United Kingdom
>Registered No: 3122085, England
>
>Phone:          +44 171 557 5000
>Fax:            +44 171 557 5200
>Email:          [email-masked]
>WebSite:        http://www.mondexinternational.com
>
>****************************************************************************
>*****************
>-----------------------------------------------------------------------
>Message addressed to: [email-masked]
>Archive available at: http://www.elistx.com/archives/ietf-trade/
>To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
>body to: [email-masked]

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

From: "Lewis, Tony" <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: RE: Brand IDs & their registration. Was: RE: Comments on draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part  1
Date: Wed, 28 Apr 1999 20:30:29 -0700
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

My point is that the brand is "Visa" no matter whether using IOTP, SET or
any other protocol.

As for EMV, the very first live SET 1.0 transaction was made using an EMV
card with the EMV data carried inside a SET message extension. EMV credit
and debit products are a significant part of the future of electronic
commerce. I expect they will be the dominant model for payment in a decade.

Tony
> ----------
> From: 	Steve Fabes[SMTP:[email-masked]]
> Sent: 	Wednesday, April 28, 1999 3:43 PM
> To: 	Lewis, Tony; Ietf Trade WG
> Subject: 	Re: Brand IDs & their registration. Was: RE: Comments on
> draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
> 
> Tony - do your comments infer that SET.Visa will be the only e-Commerce
> product that an IOTP product supplier can expect to see. Can you see a day
> when a Visa EMV 3.1.1 (or 3.x.x) based credit product could also be used
> inside an IOTP product?
> -----Original Message-----
> From: Lewis, Tony <[email-masked]>
> To: Ietf Trade WG <[email-masked]>
> Date: Wednesday, April 28, 1999 13:21
> Subject: RE: Brand IDs & their registration. Was: RE: Comments on
> draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1
> 
> 
> >David,
> >
> >I am new to this group and do not know what lead to the current approach.
> >There are undoubtedly some issues that I don't know about. However, it
> seems
> >to me that a brand is a brand no matter what payment protocol is being
> used.
> >The only difference I see between "IOTP:Visa" and "SET:Visa" is that the
> >latter indicates that the brand is supported by a specific payment
> protocol.
> >Since you need to support brands other than those supported by SET, there
> >will need to be a registry. It seems to me that there should only be one
> >such registry rather than the two being proposed. I recommend having a
> >single domain for these brands. It seems reasonable to initially populate
> it
> >using the brands registered with SET and those non-SET brands you listed
> in
> >your note.
> >
> >Tony
> >> ----------
> >> From: David Burdett[SMTP:[email-masked]]
> >> Sent: Wednesday, April 28, 1999 11:36 AM
> >> To: Ietf Trade WG; Lewis, Tony
> >> Subject: Brand IDs & their registration. Was: RE: Comments on
> >> draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
> >>
> >> In the current specification the basic idea for identifying brands is
> that
> >> they should be of the form "xxx:brandid" where "xxx" can be "SET" which
> >> indicates that the brandid is any valid brandid that is accepted by
> SET,
> >> or
> >> alternatively "IOTP" which can be used to define any brand not defined
> by
> >> SET. The idea was that we should not need to define "Visa",
> "MasterCard",
> >> "American Express", etc more than once since they are already defined
> and
> >> registered by SET.
> >>
> >> However a couple of problems may arise ...
> >>
> >> USING THE SET BRAND ID FOR NON-SET PAYMENTS
> >> Although IOTP can support SET as a payment protocol, it can also
> support
> >> credit card payments (using Secure Channel Credit Debit - SCCD) where
> the
> >> credit card information (no, name, expiration date, etc) is coded
> >> effectively in the clear but with privacy protection provided by using
> a
> >> secure channel such as SSL. In this way it provides a similar level of
> >> privacy/security as for credit card payments that occur now where a web
> >> page
> >> form is completed by the user.
> >>
> >> My question is, will it be reasonable to use the SET brandid in this
> way
> >> to
> >> cover non-SET credit card payments. I *think* the answer is "yes" as
> you
> >> can
> >> quite imagine a situation where a consumer is offered a choice of using
> >> their VISA credit card to pay using either SET or SCCD.
> >>
> >> WHAT BRAND ID SHOULD BE USED FOR CO BRANDS
> >> If a payment brand, such as a local brand or co-brand, chooses,
> initiall
> >> to
> >> use just SCCD rather than SET then they would not (I think) need to
> >> register
> >> their brand with SET. In this case, they might register their brand as
> an
> >> "IOTP" brand. However if they later adopted SET, they would end up with
> >> potentially two equivalent Brand IDs. Do you think we might be better
> off
> >> with a straight IOTP brand and keep all the names under the procedures
> >> defined by IANA? I'm not sure?
> >>
> >> REGISTERING NEW BRAND IDs
> >> To help assist in answering the last point, the following is what I'm
> >> currently writing as the proposed IANA procedure for registering new
> brand
> >> ids. Any comments:
> >>
> >> >>>Clip>>>
> >> The format of the Brand ID is either:
> >> * SET:setbrand where setbrand is a brand which is accepted by the
> >> [SET] payment protocol
> >> * IOTP:iotpbrand where iotpbrand may be:
> >> - GeldKarte
> >> - Mondex
> >>
> >> New values of the high level prefix (SET or IOTP) should be allocated
> >> following review on the IETF Trade Working Group mailing list and by
> the
> >> Designated Expert.
> >>
> >> Values of "setbrand" are allocated as defined in the [SET]
> specifications.
> >>
> >> New values of "iotpbrand" must be announced to the IETF Trade WG
> mailing
> >> list and, if there are no objections within three weeks, be allocated
> on
> a
> >> "first come first served" basis.
> >> <<<End Clip<<<
> >>
> >> Regards
> >>
> >> David
> >> > ----------
> >> > From: Lewis, Tony[SMTP:[email-masked]]
> >> > Sent: 28 April 1999 08:14
> >> > To: Ietf Trade WG
> >> > Subject: RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt,
> >> > part  1
> >> >
> >> > In SET, the BrandID is either "brand" or "brand:product".
> >> >
> >> > In Japan, there are products that are co-branded. Essentially these
> >> > products
> >> > are private label cards for domestic transactions with an
> international
> >> > brand for non-domestic transactions. The private label can be
> reflected
> >> in
> >> > a
> >> > SET cardholder certificate as the "promotional card name" under the
> >> > international brand's hierarchy and/or the cardholder can have a
> >> > certificate
> >> > issued under the private label hierarchy.
> >> >
> >> > There is no provision to carry both the private label (of the
> Japanese
> >> > credit card company) and the international brand as part of the SET
> >> > BrandID.
> >> >
> >> > Tony
> >> > > ----------
> >> > > From: David Burdett[SMTP:[email-masked]]
> >> > > Sent: Tuesday, April 27, 1999 6:31 PM
> >> > > To: Ietf Trade WG; [email-masked]
> >> > > Subject: RE: Comments on
> draft-ietf-trade-iotp-v1.0-protocol-03.txt,
> >> > > part  1
> >> > >
> >> > > I'm working my way through Don's comments and came across this one
> >> where
> >> > > our
> >> > > friends in Japan might be able to help ... I think ...
> >> > >
> >> > > Don says ...
> >> > >
> >> > > "I looked around a bit in SET literature and couldn't find anything
> >> > > about Dual or Promotional brands or anything about a three
> component
> >> SET
> >> > > Brand.  Two components, "brand" and "product" I see in the SET
> >> > literature,
> >> > > such a "MasterCard" or "Visa:Gold".  But not A:B:C and no case
> where
> a
> >> > > colon
> >> > > is included if there isn't anything after it.  In other words, it's
> >> > > "Visa",
> >> > > not "Visa:", and certainly not "Visa::" as a SET brand (re also
> >> examples
> >> > > in
> >> > > 6.6.1)."
> >> > >
> >> > > This requirement arose as a result of meeting the needs of the
> Japan
> >> > > market.
> >> > > Can some people who are more familiar with this, please have a look
> at
> >> > > this
> >> > > part of the spec and check it is ok please?
> >> > >
> >> > > David
> >> > >
> >> > > > ----------
> >> > > > From: [email-masked][SMTP:[email-masked]]
> >> > > > Sent: 22 April 1999 15:25
> >> > > > To: [email-masked]
> >> > > > Subject: Comments on
> >> draft-ietf-trade-iotp-v1.0-protocol-03.txt, part
> >> > > > 1
> >> > > >
> >> > > > I've done a careful review of the document through section 6 and
> >> > section
> >> > > > 13
> >> > > > and greater and came up with the following somewhat length list
> of
> >> > > > suggestions.  I don't think they substantially change the
> intended
> >> > > meaning
> >> > > > of the document but those on the list should judge that.
> >> > > >
> >> > > >
> >> > > > IMPORTANT:
> >> > > >
> >> > > > "IANA Considerations" needs to be a top level section, perhaps
> #11.
> >> > > > Gathering this stuff together into 3.7.3 is good but its still
> >> > > > unreasonable
> >> > > > to expect IANA to comb the document to find it.
> >> > > >      I'm not sure about the criteria for registration.  "IETF
> >> > Consensus"
> >> > > > is
> >> > > > pretty stiff and requires a vote of the IESG.  I should think
> >> someone
> >> > > > could
> >> > > > register an IOTP Band or CurrCode by publishing an RFC.  Perhaps
> >> that
> >> > is
> >> > > > what you mean for ProtocolId but it is not clear.
> >> > > >      Toward end so 3.7.3, change "with" to "without".
> >> > > >
> >> > > >
> >> > > > MISCELLANEOUS:
> >> > > >
> >> > > > I don't understand the difference between "Objectives" and
> >> "Purpose".
> >> > I
> >> > > > suggest that 1.4 and 1.5 be merged and that the reference to
> "IOTP
> >> > > > Business
> >> > > > Description" which, as far as I know, is not intended to ever
> become
> >> > an
> >> > > > IETF document, be dropped.
> >> > > >
> >> > > > Section 1.7 still refers to an XML Overview section 11.
> >> > > >
> >> > > > Page spanning figures, like Figure 3, are really pretty messy.
> It
> >> > would
> >> > > > be
> >> > > > better if the text could be made much more terse and this and
> >> similar
> >> > > > figures started high on a page so they aren't split by a page
> >> > boundary.
> >> > > >
> >> > > > Section 2.2: suggest "The Open Trading Protocols identify" be
> >> changed
> >> > to
> >> > > > "IOTP identifies".
> >> > > > Section 2.2: says "IOTP Transactions are composed of these
> >> exchanges"
> >> > > but
> >> > > > does not list Inquiry or Ping exchange.
> >> > > >
> >> > > > Starting in section 2.3 and many other places in the document,
> words
> >> > or
> >> > > > phrases are prefixed and suffixed by an underscore character
> ("_").
> >> > > This
> >> > > > is not any normal IETF style.  I suspect it means that the
> original
> >> > text
> >> > > > is
> >> > > > italic.  These should be suppressed or if that is impossible, a
> >> > separate
> >> > > > pass should be done to delete them.
> >> > > >
> >> > > > In Figure 9, the things which are supposed to be identical or
> match
> >> > > aren't
> >> > > > and don't.  Is that deliberate?
> >> > > >
> >> > > > I don't think that section 3.6 Brands and Brand Selection fits
> very
> >> > well
> >> > > > where it and suggest it be moved into section 10 which could be
> >> > renamed
> >> > > > "Brands".
> >> > > >      Continuing on Brands, I looked around a bit in SET
> literature
> >> and
> >> > > > couldn't find anything about Dual or Promotional brands or
> anything
> >> > > about
> >> > > > a
> >> > > > three component SET Brand.  Two components, "brand" and "product"
> I
> >> > see
> >> > > in
> >> > > > the SET literature, such a "MasterCard" or "Visa:Gold".  But not
> >> A:B:C
> >> > > and
> >> > > > no case where a colon is included if there isn't anything after
> it.
> >> > In
> >> > > > other words, it's "Visa", not "Visa:", and certainly not "Visa::"
> as
> >> a
> >> > > SET
> >> > > > brand (re also examples in 6.6.1). Can anyone give me any
> references
> >> > to
> >> > > > shed light on this?
> >> > > >
> >> > > > Section 3.8.1: I don't understand why sub-pages of an HTML main
> page
> >> > > > couldn't have links back to the main page.
> >> > > >
> >> > > > Section 4.1: first section reference says "0"?
> >> > > >
> >> > > > Figures 10 and 11: These flow diagrams each *almost* fit on a
> page.
> >> If
> >> > > the
> >> > > > initial "Input IOTP Message" box could be to the side with a
> >> > horizontal
> >> > > > arrow and the text were edited down to something a bit more
> terse,
> I
> >> > > think
> >> > > > they would, which would be quite helpful.
> >> > > >
> >> > > > Section 5: Suggest this section be called "Digital Signature" or
> >> > > > something.
> >> > > > Usually an IETF Security Considerations section is brief and
> talks
> >> > about
> >> > > > really high level issues.  Material in 5.4 is appropriate for
> >> Security
> >> > > > Considerations.  A separate Security Considerations section would
> >> need
> >> > > to
> >> > > > also say something about deciding when to require signatures,
> even
> >> if
> >> > it
> >> > > > is
> >> > > > just by referring to section 5.1.4, and about depending on
> payment
> >> > > scheme
> >> > > > security for the safety of funds, which I didn't see anywhere.
> >> > > >      Section 5 seems pretty heavy on certificates and public key
> >> > crypto,
> >> > > > especially given the originally IOTP v1.0 was going to be secret
> key
> >> > > only
> >> > > > and, as I recall, it was with some reluctance that public key
> hooks
> >> > were
> >> > > > added.  The stuff on checking a signature, for example, talks
> about
> >> > > > checking the certificate as if there always has to be one.
> >> > > >      Section 5.1.4: another reason you might not need signatures
> is
> >> > the
> >> > > > that the sender and receiver were on the same machine so it can
> >> check
> >> > > > integrity just by comparing with a saved copy.
> >> > > >
> >> > > > Section 6.4.2: Need to eliminate reference to "Open Trading
> Protocol
> >> > > > Consortium" and suggest dropping whole note. I don't see any
> >> > difference
> >> > > at
> >> > > > all between OkTo/OkFrom and amount.  Both could appear in human
> >> > readable
> >> > > > form in the Order Description and in machine readable form in
> their
> >> > > > element.  Recommending that the UI display the machine readable
> >> > version
> >> > > is
> >> > > > reasonable (as in 6.4.1).
> >> > > >
> >> > > > ContentSoftwareId: the standard text given for this is quite
> length
> >> > and
> >> > > > repeated dozens of time.  If it could be moved to the glossary or
> >> > > > something
> >> > > > and a simple "see glossary" put in, it would save many pages.
> >> > > >
> >> > > > As previously discussed, change ISO4217 to ISO4217A or the like.
> >> > > >
> >> > > > Just before section 6.7, it says that examples exist in 6.6 when
> >> they
> >> > > are
> >> > > > in 10.
> >> > > >
> >> > > > Section 6.17: references to the Richard Brown draft and probably
> not
> >> > > > appropriate.  RFCs are not supposed to refer to drafts.  About
> the
> >> > > future,
> >> > > > I'm not sure you need to say anything but if you do, I think it
> >> should
> >> > > > just
> >> > > > say the future versions of IOTP will use industry standard XML
> >> > signature
> >> > > > technology if it meets IOTP requirements.
> >> > > >      Shouldn't 6.17.1 refer to the IOTP DSIG document?  It's OK
> to
> >> > refer
> >> > > > to
> >> > > > that draft because the idea is that it and the main protocol
> >> document
> >> > > will
> >> > > > be issued as RFCs simultaneously.  Maybe the XMLDSIG reference
> >> should
> >> > > just
> >> > > > be changed to refer to the IOTP DSIG document.
> >> > > >      There is a reference in  6.17.1 to payment scheme specific
> >> > > > algorithms.
> >> > > > Wouldn't their use be encapsulated inside the packaged contents
> and
> >> be
> >> > > in
> >> > > > the payment scheme modules, not an IOTP implementation itself?
> >> > > >      Section 6.18: similarly for certificate reference.  Should
> >> point
> >> > > out
> >> > > > that certs not needed for symmetric keying or for cases where
> public
> >> > key
> >> > > > has been registered at recipient.
> >> > > >
> >> > > > Section 6.19.2: For ElContIllegal, ValueTooSmall, and
> ValueTooLarge,
> >> I
> >> > > > believe it should say "content" rather than "PackagedContent".
> >> > > >
> >> > > >
> >> > > >
> >> > > > TRIVIAL NITS:
> >> > > >
> >> > > > In the Abstract and section 1, Delivery Handler is capitalized
> but
> >> > > payment
> >> > > > handler isn't.
> >> > > >
> >> > > > It is not usual to have a section like 1.7, History, in an IETF
> >> > > document.
> >> > > > If the evolution of a protocol sheds light on its technical
> content,
> >> > > > that's
> >> > > > one thing.  But it is not usual to have what is mostly a list of
> >> > editing
> >> > > > versions.  Suggest it be dropped to shorten the document.
> >> > > >
> >> > > > I'm not sure why there is a skip to new page before section 3.1
> or
> >> > > 3.1.2.
> >> > > > Suggest dropping these to make the document more compact.  RFC
> style
> >> > is
> >> > > to
> >> > > > have no skips to the start of a new page anywhere in the body
> text.
> >> > > >
> >> > > > Section 3.8 example packaged content:  I don't like the "Name"s
> >> > FirstMsg
> >> > > > and SecondMsg.  Using Msg => Message seems confusing.  Suggest
> >> > > FirstPiece
> >> > > > and SecondPiece.
> >> > > >
> >> > > > Section 3.10 says "Where both types of net location are present,
> the
> >> > > > following rules apply:" and then gives three rules only the third
> of
> >> > > which
> >> > > > applies in the described circumstances.  Suggest moving the first
> >> two
> >> > up
> >> > > > and combining the quoted phrase with the third.
> >> > > >
> >> > > > Section 3.11.1 "treated by the recipient is an error": is -> as
> >> > > >
> >> > > > Section 4: "There are a several ..." delete "a"
> >> > > >
> >> > > > Section 4.4.1.2: in first sentence has -> have.
> >> > > >
> >> > > > Section 4.4.2.9: in first sentence, insert "server" between "the"
> >> and
> >> > > > "unless".
> >> > > >
> >> > > > Not sure why skip to new page before section 5.3.1 shortly before
> >> > Figure
> >> > > > 14
> >> > > > which overflows onto next page by just one line...
> >> > > >
> >> > > > Section 5.3.1.1: numbered subsections, lettered subsubsections:
> The
> >> > > text
> >> > > > at the ends of these 12 subsubsections is substantially the same.
> >> > > > Starting
> >> > > > with 3)b) sometimes the final period is omitted.  Suggest moving
> >> this
> >> > > text
> >> > > > up to the numbered section level or to before the whole two level
> >> > list.
> >> > > >
> >> > > > Section 5.3.1.2: ditto 5.3.1.1 except list is one level.
> >> > > >
> >> > > > Section 6.1: towards the end, delete "the" from "that the
> should".
> >> > > >
> >> > > > Section 6.2: Insert "may be" after "there" in "there only one".
> >> > > >
> >> > > > Section 6.5.5: PostalCode missing from detailed attributes list.
> >> > > >
> >> > > > Just before 6.6.3 and 6.7.1: "in10" -> "in section 10".
> >> > > >
> >> > > > Suggest replacing occurrences of "SSL" with "SSL/TLS" and adding
> the
> >> > TLS
> >> > > > RFC to the References.
> >> > > >
> >> > > > Section 6.11:  has "Plain/Text" where other similar sentences use
> >> > "Plain
> >> > > > Text" which is probably better.  The "/" makes it look like a
> MIME
> >> > type
> >> > > > and
> >> > > > the MIME type is actually text/plain.  But I would suggest not
> using
> >> > the
> >> > > > MIME type as there isn't a unique one for HTML.
> >> > > >
> >> > > > Section 6.12.1: DelivReqNetLocn & SecDelivReqNotLocn: "Mechanism
> >> must"
> >> > > ->
> >> > > > "Mechanism and must".
> >> > > >
> >> > > > Section 6.13: Content, should be "PackagedContent" not "Delivery
> >> > Note".
> >> > > >
> >> > > >
> >> > > >
> >> > > > REFERENCES (section 14)
> >> > > >
> >> > > > For DOM-HASH, can't refer to any Internet-Drafts by URL or
> filename.
> >> > > For
> >> > > > HMAC, suggest refereing to RFC 2104 HMAC: Keyed-Hashing for
> Message
> >> > > > Authentication. H. Krawczyk, M. Bellare, R. Canetti. February
> 1997.
> >> > > >
> >> > > > It looks pretty odd to the IETF spelled out in the RFC
> references.
> >> > I've
> >> > > > never seen that in an IETF document references section.
> >> > > >
> >> > > > For SET, suggest referencing the SETco.org site, not Mastercard.
> >> > Can't
> >> > > > reference the Brown XMLDSIG draft in an RFC (although you can
> talk
> >> > about
> >> > > > it
> >> > > > without a URL or file name reference if necessary).
> >> > > >
> >> > > >
> >> > > > 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
> >> > > >
> >> > > >
> >> > > >
> >> >
> -----------------------------------------------------------------------
> >> > > > Message addressed to: [email-masked]
> >> > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> >> > > > To (un)subscribe send a message with "subscribe" or "unsubscribe"
> in
> >> > the
> >> > > > body to: [email-masked]
> >> > > >
> >> > >
> >> > >
> >> >
> >>
> **************************************************************************
> >> > > ********************
> >> > >
> >> > > This Email and any attached files are confidential and may also be
> >> > > privileged.
> >> > > If you are not the intended recipient, please notify the postmaster
> >> > using
> >> > > email
> >> > > address [email-masked] or call +44 171 557 5000 and ask for
> the
> >>
> >> > > IT Helpdesk.  You should not copy this email and any attached
> files,
> >> use
> >> > > them
> >> > > for any purpose or disclose the contents to any other person; all
> >> copies
> >> > > of the
> >> > > Email and associated files in your possession should be destroyed.
> >> > >
> >> > > Mondex International Limited
> >> > > 47-53 Cannon Street
> >> > > London EC4M 5SQ
> >> > > United Kingdom
> >> > > Registered No: 3122085, England
> >> > >
> >> > > Phone:          +44 171 557 5000
> >> > > Fax:            +44 171 557 5200
> >> > > Email:          [email-masked]
> >> > > WebSite:        http://www.mondexinternational.com
> >> > >
> >> > >
> >> >
> >>
> **************************************************************************
> >> > > *******************
> >> > >
> >> -----------------------------------------------------------------------
> >> > > Message addressed to: [email-masked]
> >> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> >> > > To (un)subscribe send a message with "subscribe" or "unsubscribe"
> in
> >> the
> >> > > body to: [email-masked]
> >> > >
> >> >
> -----------------------------------------------------------------------
> >> > Message addressed to: [email-masked]
> >> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> >> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> >> > body to: [email-masked]
> >> >
> >>
> >>
> **************************************************************************
> >> ********************
> >>
> >> This Email and any attached files are confidential and may also be
> >> privileged.
> >> If you are not the intended recipient, please notify the postmaster
> using
> >> email
> >> address [email-masked] or call +44 171 557 5000 and ask for the
> >> IT Helpdesk.  You should not copy this email and any attached files,
> use
> >> them
> >> for any purpose or disclose the contents to any other person; all
> copies
> >> of the
> >> Email and associated files in your possession should be destroyed.
> >>
> >> Mondex International Limited
> >> 47-53 Cannon Street
> >> London EC4M 5SQ
> >> United Kingdom
> >> Registered No: 3122085, England
> >>
> >> Phone:          +44 171 557 5000
> >> Fax:            +44 171 557 5200
> >> Email:          [email-masked]
> >> WebSite:        http://www.mondexinternational.com
> >>
> >>
> **************************************************************************
> >> *******************
> >> -----------------------------------------------------------------------
> >> Message addressed to: [email-masked]
> >> Archive available at: http://www.elistx.com/archives/ietf-trade/
> >> To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> >> body to: [email-masked]
> >>
> >-----------------------------------------------------------------------
> >Message addressed to: [email-masked]
> >Archive available at: http://www.elistx.com/archives/ietf-trade/
> >To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> >body to: [email-masked]
> >
> 
-----------------------------------------------------------------------
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, 28 Apr 1999 19:50:47 -0700
From: Donn Mukensnable <[email-masked]>
Organization: Field Services
To: Eric Murray <[email-masked]>
CC: David Burdett <[email-masked]>,  Ietf Trade WG <[email-masked]>
Subject: Re: Links in HTML data
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

 If the linked-to data were converted to a relative URL and 'bundled'
along with the response to the requested page than the syncrhonization
of the data could be preserved.  However, this opens up the potential of
circular references, long chains, and other voluminous data flows. 

Donn Mukensnable

Eric Murray wrote:
> 
> On Wed, Apr 28, 1999 at 10:45:43PM +0100, David Burdett wrote:
> > Don Eastlake says in his email:
> >
> >       "Section 3.8.1: I don't understand why sub-pages of an HTML main
> > page couldn't have links back to the main page."
> >
> > In IOTP, where HTML is being used to describe a document such as an order
> > description or a payment note, then it is, in many ways being provided as an
> > alternative to a single, or multi-page "real world" document. These
> > documents should not in general be :"multi-media" documents, since for
> > purposes of non-refutability, the document should be self-contained and not
> > reliant on other records held elsewhere. For this reason links should only
> > be used to allow, for example, graphics and other display devices to be
> > included in the document.
> >
> > Therefore in my opinion, this should not be allowed. What do other people
> > think?
> 
> I think that links should not be allowed at all.
> 
> Otherwise there is a possibility of repudiating the transaction as "not
> as it was represented"- the purchaser could claim that the link she
> followed represented something different than what she received because
> the seller switched the data that the links pointed to during the
> transaction.  This goes for links to images in addition to links to
> other documents, as a picture could be used to mislead just as well as a
> document.
> 
> Links also present a problem in reviewing orders in a purchaser's
> database- an order made a week ago might have links to pages which have
> since been updated.   How is the purchaser to know what he's supposed to
> receive?
> 
> --
> Eric Murray          N*Able Technologies                    www.nabletech.com
> (email:  ericm  at the sites lne.com or nabletech.com)     PGP keyid:E03F65E5
> -----------------------------------------------------------------------
> 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, 28 Apr 1999 18:02:47 -0700
From: Eric Murray <[email-masked]>
To: David Burdett <[email-masked]>
Cc: Ietf Trade WG <[email-masked]>
Subject: Re: Links in HTML data
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

On Wed, Apr 28, 1999 at 10:45:43PM +0100, David Burdett wrote:
> Don Eastlake says in his email:
> 
> 	"Section 3.8.1: I don't understand why sub-pages of an HTML main
> page couldn't have links back to the main page."
> 
> In IOTP, where HTML is being used to describe a document such as an order
> description or a payment note, then it is, in many ways being provided as an
> alternative to a single, or multi-page "real world" document. These
> documents should not in general be :"multi-media" documents, since for
> purposes of non-refutability, the document should be self-contained and not
> reliant on other records held elsewhere. For this reason links should only
> be used to allow, for example, graphics and other display devices to be
> included in the document.
> 
> Therefore in my opinion, this should not be allowed. What do other people
> think?

I think that links should not be allowed at all.

Otherwise there is a possibility of repudiating the transaction as "not
as it was represented"- the purchaser could claim that the link she
followed represented something different than what she received because
the seller switched the data that the links pointed to during the
transaction.  This goes for links to images in addition to links to
other documents, as a picture could be used to mislead just as well as a
document.

Links also present a problem in reviewing orders in a purchaser's
database- an order made a week ago might have links to pages which have
since been updated.   How is the purchaser to know what he's supposed to
receive?

-- 
Eric Murray          N*Able Technologies                    www.nabletech.com
(email:  ericm  at the sites lne.com or nabletech.com)     PGP keyid:E03F65E5
-----------------------------------------------------------------------
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: Steve Fabes <[email-masked]>
To: "Lewis, Tony" <[email-masked]>, Ietf Trade WG <[email-masked]>
Subject: Re: Brand IDs & their registration. Was: RE: Comments on draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
Date: Wed, 28 Apr 1999 15:43:30 -0700
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Tony - do your comments infer that SET.Visa will be the only e-Commerce
product that an IOTP product supplier can expect to see. Can you see a day
when a Visa EMV 3.1.1 (or 3.x.x) based credit product could also be used
inside an IOTP product?
-----Original Message-----
From: Lewis, Tony <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Date: Wednesday, April 28, 1999 13:21
Subject: RE: Brand IDs & their registration. Was: RE: Comments on
draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1

>David,
>
>I am new to this group and do not know what lead to the current approach.
>There are undoubtedly some issues that I don't know about. However, it
seems
>to me that a brand is a brand no matter what payment protocol is being
used.
>The only difference I see between "IOTP:Visa" and "SET:Visa" is that the
>latter indicates that the brand is supported by a specific payment
protocol.
>Since you need to support brands other than those supported by SET, there
>will need to be a registry. It seems to me that there should only be one
>such registry rather than the two being proposed. I recommend having a
>single domain for these brands. It seems reasonable to initially populate
it
>using the brands registered with SET and those non-SET brands you listed in
>your note.
>
>Tony
>> ----------
>> From: David Burdett[SMTP:[email-masked]]
>> Sent: Wednesday, April 28, 1999 11:36 AM
>> To: Ietf Trade WG; Lewis, Tony
>> Subject: Brand IDs & their registration. Was: RE: Comments on
>> draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
>>
>> In the current specification the basic idea for identifying brands is
that
>> they should be of the form "xxx:brandid" where "xxx" can be "SET" which
>> indicates that the brandid is any valid brandid that is accepted by SET,
>> or
>> alternatively "IOTP" which can be used to define any brand not defined by
>> SET. The idea was that we should not need to define "Visa", "MasterCard",
>> "American Express", etc more than once since they are already defined and
>> registered by SET.
>>
>> However a couple of problems may arise ...
>>
>> USING THE SET BRAND ID FOR NON-SET PAYMENTS
>> Although IOTP can support SET as a payment protocol, it can also support
>> credit card payments (using Secure Channel Credit Debit - SCCD) where the
>> credit card information (no, name, expiration date, etc) is coded
>> effectively in the clear but with privacy protection provided by using a
>> secure channel such as SSL. In this way it provides a similar level of
>> privacy/security as for credit card payments that occur now where a web
>> page
>> form is completed by the user.
>>
>> My question is, will it be reasonable to use the SET brandid in this way
>> to
>> cover non-SET credit card payments. I *think* the answer is "yes" as you
>> can
>> quite imagine a situation where a consumer is offered a choice of using
>> their VISA credit card to pay using either SET or SCCD.
>>
>> WHAT BRAND ID SHOULD BE USED FOR CO BRANDS
>> If a payment brand, such as a local brand or co-brand, chooses, initiall
>> to
>> use just SCCD rather than SET then they would not (I think) need to
>> register
>> their brand with SET. In this case, they might register their brand as an
>> "IOTP" brand. However if they later adopted SET, they would end up with
>> potentially two equivalent Brand IDs. Do you think we might be better off
>> with a straight IOTP brand and keep all the names under the procedures
>> defined by IANA? I'm not sure?
>>
>> REGISTERING NEW BRAND IDs
>> To help assist in answering the last point, the following is what I'm
>> currently writing as the proposed IANA procedure for registering new
brand
>> ids. Any comments:
>>
>> >>>Clip>>>
>> The format of the Brand ID is either:
>> * SET:setbrand where setbrand is a brand which is accepted by the
>> [SET] payment protocol
>> * IOTP:iotpbrand where iotpbrand may be:
>> - GeldKarte
>> - Mondex
>>
>> New values of the high level prefix (SET or IOTP) should be allocated
>> following review on the IETF Trade Working Group mailing list and by the
>> Designated Expert.
>>
>> Values of "setbrand" are allocated as defined in the [SET]
specifications.
>>
>> New values of "iotpbrand" must be announced to the IETF Trade WG mailing
>> list and, if there are no objections within three weeks, be allocated on
a
>> "first come first served" basis.
>> <<<End Clip<<<
>>
>> Regards
>>
>> David
>> > ----------
>> > From: Lewis, Tony[SMTP:[email-masked]]
>> > Sent: 28 April 1999 08:14
>> > To: Ietf Trade WG
>> > Subject: RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt,
>> > part  1
>> >
>> > In SET, the BrandID is either "brand" or "brand:product".
>> >
>> > In Japan, there are products that are co-branded. Essentially these
>> > products
>> > are private label cards for domestic transactions with an international
>> > brand for non-domestic transactions. The private label can be reflected
>> in
>> > a
>> > SET cardholder certificate as the "promotional card name" under the
>> > international brand's hierarchy and/or the cardholder can have a
>> > certificate
>> > issued under the private label hierarchy.
>> >
>> > There is no provision to carry both the private label (of the Japanese
>> > credit card company) and the international brand as part of the SET
>> > BrandID.
>> >
>> > Tony
>> > > ----------
>> > > From: David Burdett[SMTP:[email-masked]]
>> > > Sent: Tuesday, April 27, 1999 6:31 PM
>> > > To: Ietf Trade WG; [email-masked]
>> > > Subject: RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt,
>> > > part  1
>> > >
>> > > I'm working my way through Don's comments and came across this one
>> where
>> > > our
>> > > friends in Japan might be able to help ... I think ...
>> > >
>> > > Don says ...
>> > >
>> > > "I looked around a bit in SET literature and couldn't find anything
>> > > about Dual or Promotional brands or anything about a three component
>> SET
>> > > Brand.  Two components, "brand" and "product" I see in the SET
>> > literature,
>> > > such a "MasterCard" or "Visa:Gold".  But not A:B:C and no case where
a
>> > > colon
>> > > is included if there isn't anything after it.  In other words, it's
>> > > "Visa",
>> > > not "Visa:", and certainly not "Visa::" as a SET brand (re also
>> examples
>> > > in
>> > > 6.6.1)."
>> > >
>> > > This requirement arose as a result of meeting the needs of the Japan
>> > > market.
>> > > Can some people who are more familiar with this, please have a look
at
>> > > this
>> > > part of the spec and check it is ok please?
>> > >
>> > > David
>> > >
>> > > > ----------
>> > > > From: [email-masked][SMTP:[email-masked]]
>> > > > Sent: 22 April 1999 15:25
>> > > > To: [email-masked]
>> > > > Subject: Comments on
>> draft-ietf-trade-iotp-v1.0-protocol-03.txt, part
>> > > > 1
>> > > >
>> > > > I've done a careful review of the document through section 6 and
>> > section
>> > > > 13
>> > > > and greater and came up with the following somewhat length list of
>> > > > suggestions.  I don't think they substantially change the intended
>> > > meaning
>> > > > of the document but those on the list should judge that.
>> > > >
>> > > >
>> > > > IMPORTANT:
>> > > >
>> > > > "IANA Considerations" needs to be a top level section, perhaps #11.
>> > > > Gathering this stuff together into 3.7.3 is good but its still
>> > > > unreasonable
>> > > > to expect IANA to comb the document to find it.
>> > > >      I'm not sure about the criteria for registration.  "IETF
>> > Consensus"
>> > > > is
>> > > > pretty stiff and requires a vote of the IESG.  I should think
>> someone
>> > > > could
>> > > > register an IOTP Band or CurrCode by publishing an RFC.  Perhaps
>> that
>> > is
>> > > > what you mean for ProtocolId but it is not clear.
>> > > >      Toward end so 3.7.3, change "with" to "without".
>> > > >
>> > > >
>> > > > MISCELLANEOUS:
>> > > >
>> > > > I don't understand the difference between "Objectives" and
>> "Purpose".
>> > I
>> > > > suggest that 1.4 and 1.5 be merged and that the reference to "IOTP
>> > > > Business
>> > > > Description" which, as far as I know, is not intended to ever
become
>> > an
>> > > > IETF document, be dropped.
>> > > >
>> > > > Section 1.7 still refers to an XML Overview section 11.
>> > > >
>> > > > Page spanning figures, like Figure 3, are really pretty messy.  It
>> > would
>> > > > be
>> > > > better if the text could be made much more terse and this and
>> similar
>> > > > figures started high on a page so they aren't split by a page
>> > boundary.
>> > > >
>> > > > Section 2.2: suggest "The Open Trading Protocols identify" be
>> changed
>> > to
>> > > > "IOTP identifies".
>> > > > Section 2.2: says "IOTP Transactions are composed of these
>> exchanges"
>> > > but
>> > > > does not list Inquiry or Ping exchange.
>> > > >
>> > > > Starting in section 2.3 and many other places in the document,
words
>> > or
>> > > > phrases are prefixed and suffixed by an underscore character ("_").
>> > > This
>> > > > is not any normal IETF style.  I suspect it means that the original
>> > text
>> > > > is
>> > > > italic.  These should be suppressed or if that is impossible, a
>> > separate
>> > > > pass should be done to delete them.
>> > > >
>> > > > In Figure 9, the things which are supposed to be identical or match
>> > > aren't
>> > > > and don't.  Is that deliberate?
>> > > >
>> > > > I don't think that section 3.6 Brands and Brand Selection fits very
>> > well
>> > > > where it and suggest it be moved into section 10 which could be
>> > renamed
>> > > > "Brands".
>> > > >      Continuing on Brands, I looked around a bit in SET literature
>> and
>> > > > couldn't find anything about Dual or Promotional brands or anything
>> > > about
>> > > > a
>> > > > three component SET Brand.  Two components, "brand" and "product" I
>> > see
>> > > in
>> > > > the SET literature, such a "MasterCard" or "Visa:Gold".  But not
>> A:B:C
>> > > and
>> > > > no case where a colon is included if there isn't anything after it.
>> > In
>> > > > other words, it's "Visa", not "Visa:", and certainly not "Visa::"
as
>> a
>> > > SET
>> > > > brand (re also examples in 6.6.1). Can anyone give me any
references
>> > to
>> > > > shed light on this?
>> > > >
>> > > > Section 3.8.1: I don't understand why sub-pages of an HTML main
page
>> > > > couldn't have links back to the main page.
>> > > >
>> > > > Section 4.1: first section reference says "0"?
>> > > >
>> > > > Figures 10 and 11: These flow diagrams each *almost* fit on a page.
>> If
>> > > the
>> > > > initial "Input IOTP Message" box could be to the side with a
>> > horizontal
>> > > > arrow and the text were edited down to something a bit more terse,
I
>> > > think
>> > > > they would, which would be quite helpful.
>> > > >
>> > > > Section 5: Suggest this section be called "Digital Signature" or
>> > > > something.
>> > > > Usually an IETF Security Considerations section is brief and talks
>> > about
>> > > > really high level issues.  Material in 5.4 is appropriate for
>> Security
>> > > > Considerations.  A separate Security Considerations section would
>> need
>> > > to
>> > > > also say something about deciding when to require signatures, even
>> if
>> > it
>> > > > is
>> > > > just by referring to section 5.1.4, and about depending on payment
>> > > scheme
>> > > > security for the safety of funds, which I didn't see anywhere.
>> > > >      Section 5 seems pretty heavy on certificates and public key
>> > crypto,
>> > > > especially given the originally IOTP v1.0 was going to be secret
key
>> > > only
>> > > > and, as I recall, it was with some reluctance that public key hooks
>> > were
>> > > > added.  The stuff on checking a signature, for example, talks about
>> > > > checking the certificate as if there always has to be one.
>> > > >      Section 5.1.4: another reason you might not need signatures is
>> > the
>> > > > that the sender and receiver were on the same machine so it can
>> check
>> > > > integrity just by comparing with a saved copy.
>> > > >
>> > > > Section 6.4.2: Need to eliminate reference to "Open Trading
Protocol
>> > > > Consortium" and suggest dropping whole note. I don't see any
>> > difference
>> > > at
>> > > > all between OkTo/OkFrom and amount.  Both could appear in human
>> > readable
>> > > > form in the Order Description and in machine readable form in their
>> > > > element.  Recommending that the UI display the machine readable
>> > version
>> > > is
>> > > > reasonable (as in 6.4.1).
>> > > >
>> > > > ContentSoftwareId: the standard text given for this is quite length
>> > and
>> > > > repeated dozens of time.  If it could be moved to the glossary or
>> > > > something
>> > > > and a simple "see glossary" put in, it would save many pages.
>> > > >
>> > > > As previously discussed, change ISO4217 to ISO4217A or the like.
>> > > >
>> > > > Just before section 6.7, it says that examples exist in 6.6 when
>> they
>> > > are
>> > > > in 10.
>> > > >
>> > > > Section 6.17: references to the Richard Brown draft and probably
not
>> > > > appropriate.  RFCs are not supposed to refer to drafts.  About the
>> > > future,
>> > > > I'm not sure you need to say anything but if you do, I think it
>> should
>> > > > just
>> > > > say the future versions of IOTP will use industry standard XML
>> > signature
>> > > > technology if it meets IOTP requirements.
>> > > >      Shouldn't 6.17.1 refer to the IOTP DSIG document?  It's OK to
>> > refer
>> > > > to
>> > > > that draft because the idea is that it and the main protocol
>> document
>> > > will
>> > > > be issued as RFCs simultaneously.  Maybe the XMLDSIG reference
>> should
>> > > just
>> > > > be changed to refer to the IOTP DSIG document.
>> > > >      There is a reference in  6.17.1 to payment scheme specific
>> > > > algorithms.
>> > > > Wouldn't their use be encapsulated inside the packaged contents and
>> be
>> > > in
>> > > > the payment scheme modules, not an IOTP implementation itself?
>> > > >      Section 6.18: similarly for certificate reference.  Should
>> point
>> > > out
>> > > > that certs not needed for symmetric keying or for cases where
public
>> > key
>> > > > has been registered at recipient.
>> > > >
>> > > > Section 6.19.2: For ElContIllegal, ValueTooSmall, and
ValueTooLarge,
>> I
>> > > > believe it should say "content" rather than "PackagedContent".
>> > > >
>> > > >
>> > > >
>> > > > TRIVIAL NITS:
>> > > >
>> > > > In the Abstract and section 1, Delivery Handler is capitalized but
>> > > payment
>> > > > handler isn't.
>> > > >
>> > > > It is not usual to have a section like 1.7, History, in an IETF
>> > > document.
>> > > > If the evolution of a protocol sheds light on its technical
content,
>> > > > that's
>> > > > one thing.  But it is not usual to have what is mostly a list of
>> > editing
>> > > > versions.  Suggest it be dropped to shorten the document.
>> > > >
>> > > > I'm not sure why there is a skip to new page before section 3.1 or
>> > > 3.1.2.
>> > > > Suggest dropping these to make the document more compact.  RFC
style
>> > is
>> > > to
>> > > > have no skips to the start of a new page anywhere in the body text.
>> > > >
>> > > > Section 3.8 example packaged content:  I don't like the "Name"s
>> > FirstMsg
>> > > > and SecondMsg.  Using Msg => Message seems confusing.  Suggest
>> > > FirstPiece
>> > > > and SecondPiece.
>> > > >
>> > > > Section 3.10 says "Where both types of net location are present,
the
>> > > > following rules apply:" and then gives three rules only the third
of
>> > > which
>> > > > applies in the described circumstances.  Suggest moving the first
>> two
>> > up
>> > > > and combining the quoted phrase with the third.
>> > > >
>> > > > Section 3.11.1 "treated by the recipient is an error": is -> as
>> > > >
>> > > > Section 4: "There are a several ..." delete "a"
>> > > >
>> > > > Section 4.4.1.2: in first sentence has -> have.
>> > > >
>> > > > Section 4.4.2.9: in first sentence, insert "server" between "the"
>> and
>> > > > "unless".
>> > > >
>> > > > Not sure why skip to new page before section 5.3.1 shortly before
>> > Figure
>> > > > 14
>> > > > which overflows onto next page by just one line...
>> > > >
>> > > > Section 5.3.1.1: numbered subsections, lettered subsubsections:
The
>> > > text
>> > > > at the ends of these 12 subsubsections is substantially the same.
>> > > > Starting
>> > > > with 3)b) sometimes the final period is omitted.  Suggest moving
>> this
>> > > text
>> > > > up to the numbered section level or to before the whole two level
>> > list.
>> > > >
>> > > > Section 5.3.1.2: ditto 5.3.1.1 except list is one level.
>> > > >
>> > > > Section 6.1: towards the end, delete "the" from "that the should".
>> > > >
>> > > > Section 6.2: Insert "may be" after "there" in "there only one".
>> > > >
>> > > > Section 6.5.5: PostalCode missing from detailed attributes list.
>> > > >
>> > > > Just before 6.6.3 and 6.7.1: "in10" -> "in section 10".
>> > > >
>> > > > Suggest replacing occurrences of "SSL" with "SSL/TLS" and adding
the
>> > TLS
>> > > > RFC to the References.
>> > > >
>> > > > Section 6.11:  has "Plain/Text" where other similar sentences use
>> > "Plain
>> > > > Text" which is probably better.  The "/" makes it look like a MIME
>> > type
>> > > > and
>> > > > the MIME type is actually text/plain.  But I would suggest not
using
>> > the
>> > > > MIME type as there isn't a unique one for HTML.
>> > > >
>> > > > Section 6.12.1: DelivReqNetLocn & SecDelivReqNotLocn: "Mechanism
>> must"
>> > > ->
>> > > > "Mechanism and must".
>> > > >
>> > > > Section 6.13: Content, should be "PackagedContent" not "Delivery
>> > Note".
>> > > >
>> > > >
>> > > >
>> > > > REFERENCES (section 14)
>> > > >
>> > > > For DOM-HASH, can't refer to any Internet-Drafts by URL or
filename.
>> > > For
>> > > > HMAC, suggest refereing to RFC 2104 HMAC: Keyed-Hashing for Message
>> > > > Authentication. H. Krawczyk, M. Bellare, R. Canetti. February 1997.
>> > > >
>> > > > It looks pretty odd to the IETF spelled out in the RFC references.
>> > I've
>> > > > never seen that in an IETF document references section.
>> > > >
>> > > > For SET, suggest referencing the SETco.org site, not Mastercard.
>> > Can't
>> > > > reference the Brown XMLDSIG draft in an RFC (although you can talk
>> > about
>> > > > it
>> > > > without a URL or file name reference if necessary).
>> > > >
>> > > >
>> > > > 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
>> > > >
>> > > >
>> > > >
>> > -----------------------------------------------------------------------
>> > > > Message addressed to: [email-masked]
>> > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
>> > > > To (un)subscribe send a message with "subscribe" or "unsubscribe"
in
>> > the
>> > > > body to: [email-masked]
>> > > >
>> > >
>> > >
>> >
>>
**************************************************************************
>> > > ********************
>> > >
>> > > This Email and any attached files are confidential and may also be
>> > > privileged.
>> > > If you are not the intended recipient, please notify the postmaster
>> > using
>> > > email
>> > > address [email-masked] or call +44 171 557 5000 and ask for
the
>>
>> > > IT Helpdesk.  You should not copy this email and any attached files,
>> use
>> > > them
>> > > for any purpose or disclose the contents to any other person; all
>> copies
>> > > of the
>> > > Email and associated files in your possession should be destroyed.
>> > >
>> > > Mondex International Limited
>> > > 47-53 Cannon Street
>> > > London EC4M 5SQ
>> > > United Kingdom
>> > > Registered No: 3122085, England
>> > >
>> > > Phone:          +44 171 557 5000
>> > > Fax:            +44 171 557 5200
>> > > Email:          [email-masked]
>> > > WebSite:        http://www.mondexinternational.com
>> > >
>> > >
>> >
>>
**************************************************************************
>> > > *******************
>> > >
>> -----------------------------------------------------------------------
>> > > Message addressed to: [email-masked]
>> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
>> > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
>> the
>> > > body to: [email-masked]
>> > >
>> > -----------------------------------------------------------------------
>> > Message addressed to: [email-masked]
>> > Archive available at: http://www.elistx.com/archives/ietf-trade/
>> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
the
>> > body to: [email-masked]
>> >
>>
>>
**************************************************************************
>> ********************
>>
>> This Email and any attached files are confidential and may also be
>> privileged.
>> If you are not the intended recipient, please notify the postmaster using
>> email
>> address [email-masked] or call +44 171 557 5000 and ask for the
>> IT Helpdesk.  You should not copy this email and any attached files, use
>> them
>> for any purpose or disclose the contents to any other person; all copies
>> of the
>> Email and associated files in your possession should be destroyed.
>>
>> Mondex International Limited
>> 47-53 Cannon Street
>> London EC4M 5SQ
>> United Kingdom
>> Registered No: 3122085, England
>>
>> Phone:          +44 171 557 5000
>> Fax:            +44 171 557 5200
>> Email:          [email-masked]
>> WebSite:        http://www.mondexinternational.com
>>
>>
**************************************************************************
>> *******************
>> -----------------------------------------------------------------------
>> Message addressed to: [email-masked]
>> Archive available at: http://www.elistx.com/archives/ietf-trade/
>> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
>> body to: [email-masked]
>>
>-----------------------------------------------------------------------
>Message addressed to: [email-masked]
>Archive available at: http://www.elistx.com/archives/ietf-trade/
>To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
>body to: [email-masked]
>

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

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: IANA Considerations
Date: Wed, 28 Apr 1999 22:45:37 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Below is the revised text for IANA considerations for the IOTP
specification. Essentially it consists of a re-worked section 3.7.3 from the
last draft as a new section 11.

If anyone has any comments please let me know.

David
========================
11. IANA Considerations

11.1 Codes Controlled by IANA

To help ensure interoperability, there is  a need for codes  used
by IOTP  to be  maintained in  a controlled  environment so  that
their meaning  and usage  are well  defined and  duplicate  codes
avoided. [IANA] is the mechanism to  be used for this purpose  as
described in RFC 2434.

The element types  and attributes names  to which this  procedure
applies is shown  in the table  below together  with the  initial
values that are valid for these attributes.

  Element Type/                      Attribute Values
 Attribute Name

Algorithm/        "sha1" - indicates that authentication consists of
Name              [SHA1] has of the challenge data
(When Algorithm
is a child of an  "signature" - indicates that authentication consists
AuthData          of the generation of a digital signature.
component)
                  "Pay:ppp" where "ppp" may be set to any valid value
                  for "iotpbrand" (see below)

                  With the exception of Authentication Methods that
                  begin with "pay:", new values are allocated
                  following review on the IETF Trade Working Group
                  mailing list and by the Designated Expert.

                  [Note]   The Algorithm element is likely to be
                           eventually defined within the [DSIG] name
                           space. It is likely that the maintenance
                           procedure defined here may need to vary
                           over time, as the DSIG proposals become
                           more widely adopted.
                  [Note End] 

Brand/BrandId     "SET:setbrand" where setbrand is a brand which is
                  accepted by the [SET] payment protocol

                  "IOTP:iotpbrand" where iotpbrand may be:
                  o "GeldKarte"
                  o "Mondex"

                  New values of the high level prefix (SET or IOTP)
                  are allocated following review on the IETF Trade
                  Working Group mailing list and by the Designated
                  Expert.

                  Values of "setbrand" are allocated as defined in the
                  [SET] specifications.

                  New values of "iotpbrand" must be announced to the
                  IETF Trade WG mailing list and, if there are no
                  objections within three weeks, are allocated on a
                  "first come first served" basis.

CurrencyAmount/   Currency codes are dependent on CurrCodeType (see
CurrCode          below).

                  If CurrCodeType is "ISO4217-A" then the currency
                  code is an alphabetic code as defined by [ISO4217]

                  If CurrCodeType is "IOTP" then new values must be
                  announced to the IETF Trade WG mailing list and, if
                  there are no objections within three weeks, are
                  allocated on a "first come first served" basis.

                  [Note]   The Currency Code Type of IOTP, is designed
                           to allow the support of "new" psuedo
                           currencies such as loyalty or frequent
                           flyer points. At the time of writing this
                           specification, no currency codes of this
                           type have been defined.
                  [Note End] 

CurrencyAmount/   "ISO4217-A"
CurrCodeType
                  "IOTP"

                  New values of CurrCodeType attribute are allocated
                  following review on the IETF Trade Working Group
                  mailing list and by the Designated Expert.

DeliveryData/     "Post"
DelivMethod
                  "Web"

                  "Email"

                  New values of Delivery Method attribute are
                  allocated following review on the IETF Trade Working
                  Group mailing list and by the Designated Expert.
                  This may require the publication of additional
                  documentation to describe how the delivery method is
                  used.

PackagedContent/  "PCDATA"
Content
                  "MIME"

                  "MIME:mimetype" (where mimetype must be the same as
                  content-type as defined by [MIME] )

                  "XML"

                  If the Content attribute is of the form
                  "MIME"mimetype", then control of new values for
                  "mimetype" is as defined in [MIME].

                  Otherwise, new values of the Content attribute are
                  allocated following review on the IETF Trade Working
                  Group mailing list and by the Designated Expert.
                  This may require the publication of additional
                  documentation to describe how the new attribute is
                  used within a Packaged Content element.

RelatedTo/        "OtpTransaction"
RelationshipType
                  "Reference"

                  New values of the RelationshipType attribute are
                  allocated following review on the IETF Trade Working
                  Group mailing list and by the Designated Expert.
                  This may require the publication of additional
                  documentation to describe how the delivery method is
                  used.

Status/           Offer
StatusType
                  Payment

                  Delivery

                  Authentication

                  New values of the Status Type attribute are
                  allocated following:
                  o publication to the IETF Trade Working Group, of an
                    RFC describing the Trading Exchange, Trading Roles
                    and associated components that relate to the
                    Status, and
                  o review of the document on the IETF Trade Working
                    Group mailing list and by the Designated Expert.

                  [Note]   The document describing new values for the
                           Status Type attribute may be combined with
                           documents that describe new Trading Roles
                           and types of signatures (see below).
                  [Note End] 

TradingRole/      "Consumer"
TradingRole
                  "Merchant"

                  "PaymentHandler"

                  "DeliveryHandler"

                  "DelivTo"

                  "CustCare"

                  New values of the Trading Role attribute are
                  allocated following:
                  o publication to the IETF Trade Working Group, of an
                    RFC describing the Trading Exchange, Trading Roles
                    and associated components that relate to the
                    Trading Role, and
                  o review of the document on the IETF Trade Working
                    Group mailing list and by the Designated Expert.

                  [Note]   The document describing new values for the
                           Trading Role attribute may be combined with
                           documents that describe new Status Types
                           (see above) and types of signatures (see
                            below).
                  [Note End] 

TransId/          "BaselineAuthentication"
OtpTransType
                  "BaselineDeposit"

                  "BaselinePurchase"

                  "BaselineRefund"

                  "BaselineWithdrawal"

                  "BaselineValueExchange"

                  "BaselineInquiry"

                  "BaselinePing"

                  New values of the OtpTransType attribute are
                  allocated following:
                  o publication to the IETF Trade Working Group, of an
                    RFC describing the new IOTP Transaction, and
                  o review of the document on the IETF Trade Working
                   Group mailing list and by the Designated Expert.

Attribute/        "OfferResponse"
Content
(see Signature    "PaymentResponse"
Component)
                  "DeliveryResponse"

                  "AuthenticationRequest"

                  "AuthenticationResponse"

                  "PingRequest"

                  "PingResponse"

                  New values of the code that define the type of a
                  signature are allocated following:
                  o publication to the IETF Trade Working Group, of an
                    RFC describing the Trading Exchange where the
                    signature is being used, and
                  o review of the document on the IETF Trade Working
                    Group mailing list and by the Designated Expert.

                  [Note]   The document describing new values for the
                           types of signatures may be combined with
                           documents that describe new Status Types
                           and Trading Roles (see above).
                  [Note End] 

11.2 Codes not controlled by IANA

In addition to the formal  development and registration of  codes
as described  above, there  is still  a  need for  developers  to
experiment using new IOTP codes.  For this reason, "user  defined
codes" may be used  to identify additional  values for the  codes
contained within this specification without the need for them  to
be registered with IANA.

The definition of a user defined code is as follows:

user_defined_code ::= ( "x-" | "X-" ) NameChar(NameChar)*

NameChar            NameChar  has the  same definition  as the  [XML]
                    definition of NameChar

Use of domain names (see [DNS]) to make user defined codes unique
is recommended although this method cannot be relied upon.
===================================================

THIS EMAIL IS FOR UNLIMITED DISTRIBUTION

> mailto:<[email-masked]>
> Mondex International, US Advanced Technology Office
> 111 Pine St, 6th Floor, San Francisco, CA 94111
> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
> 

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

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

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

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

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

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: New IOTP spec doiagram style. Comments please.
Date: Wed, 28 Apr 1999 22:45:41 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

One of the comments that Don Eastlake makes about the latest version of the
IOTP spec is as follows ...

	"Page spanning figures, like Figure 3, are really pretty messy.  It
would be better if the text could be made much more terse and this and
similar figures started high on a page so they aren't split by a page
boundary."

I agree with Don that the diagrams are messy, but they contain the same text
as in an earlier version which used a drawing package to create them using
just "text". If the diagrams are made more terse, then some of the
explanation will have to be omitted.

An alternative is to adopt a different type of text diagram (see example
below which should be viewed in a fixed font).
Do people think this style is better. If there is a reasonable consensus
that it is then I will change the diagrams, otherwise I am inclined to leave
as is.

David
EXAMPLE of partially re-worked figure 3. See the current spec for the
original.

 CONSUMER               <<< IOTP MESSAGE >>>                    MERCHANT
  1. Consumer decides to trade and sends information about the
     transaction (requests an offer) to the Merchant, e.g.
     using HTML

        >>>Information on what is being paid for (outside scope of IOTP)>>>

                           2. Merchant decides which payment brand and
                              currencies/amounts to offer, places them in a
Brand
                              List Component and sends them to the Consumer

                           <<<< Brand List Component <<<<

  3. Consumer selects the payment brand, protocol and
     currency/amount, creates a Brand Selection Component and
     send it to the Merchant

                        >>>> Brand Selection Component >>>>

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

               <<< Pay Amount; Organisations: Merchant  <<<
               <<< & Payment Handler; Signature (Offer) <<<

  5 Consumer checks the Payment Amount information and if OK
     reuqests that the payment starts by sending a Payment
     Request to the Payment Handler

       >>>      Brand List; Brand Selection; Pay Amount; Pay Scheme;
>>>
       >>> Organisations: Merchant and Payment Handler; Signature (Offer)
>>>

                                      etc ...

THIS EMAIL IS FOR UNLIMITED DISTRIBUTION
> mailto:<[email-masked]>
> Mondex International, US Advanced Technology Office
> 111 Pine St, 6th Floor, San Francisco, CA 94111
> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
> 

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

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

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

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

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

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: Links in HTML data
Date: Wed, 28 Apr 1999 22:45:43 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Don Eastlake says in his email:

	"Section 3.8.1: I don't understand why sub-pages of an HTML main
page couldn't have links back to the main page."

In IOTP, where HTML is being used to describe a document such as an order
description or a payment note, then it is, in many ways being provided as an
alternative to a single, or multi-page "real world" document. These
documents should not in general be :"multi-media" documents, since for
purposes of non-refutability, the document should be self-contained and not
reliant on other records held elsewhere. For this reason links should only
be used to allow, for example, graphics and other display devices to be
included in the document.

Therefore in my opinion, this should not be allowed. What do other people
think?

David
> mailto:<[email-masked]>
> Mondex International, US Advanced Technology Office
> 111 Pine St, 6th Floor, San Francisco, CA 94111
> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
> 

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

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

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

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

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

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: OECD Tag
Date: Wed, 28 Apr 1999 22:45:38 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

For everyone's information, a record of the OECD tag meeting held in
Washington DC last week will be made publically available on an OECD web
site in due course. This is likely to take a couple of weeks.

Once I am aware that this record is available I will post a message to this
list describing how to get hold of it.

Regards

David

THIS EMAIL IS FOR UNLIMITED DISTRIBUTION
> mailto:<[email-masked]>
> Mondex International, US Advanced Technology Office
> 111 Pine St, 6th Floor, San Francisco, CA 94111
> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
> 

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

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

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

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

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

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: Currency Codes and IOTP
Date: Wed, 28 Apr 1999 22:45:32 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

In the (fairly) recent discussion on currency codes, the options identified
were:
*	3 character alphabetic ISO4217 codes as the only accepted standard 
*	3 digit numeric ISO4217 codes as the only accepted standard, or
*	either alphabetic or numeric ISO4217 codes as the accepted standard,
using different currency code types (either ISO4217-A or IS4217-N) to
specify which is being used.

By my reckoning, the views represented by the various emails were as
follows:
*	Masaaki Hiroya - no preference - just wants a decision, points out
that Mondex uses alpha
*	Don Eastlake - alphabetic
*	Chris Smith - both, and self identify since a code made of numbers
must be numeric
*	David Burdett (me)  - alphabetic but make currency code type
ISO4217-A
*	Kent Davidson - alphabetic
*	Tom Arnold  - either - mandate just one
*	Milton Anderson - alphabetic as OFX, Integrion Gold, IFX from BITS,
FSTC echeck and FSTC BIPS all use alpha
*	Yoshiaka Kowatsura - points out that SET uses numeric
*	Donald Eastlake - points out that ISO 8583 also uses numeric
*	Milton Anderson - points out that EDI uses alpha
*	Steven Sims - points out that Proton uses numeric.

By my analysis that makes:
*	four individuals in favour of alpha (me, Don E, Kent D, Milton A) vs
two for numeric (Yoshiaka K, Steven S), and
*	seven protocols for alpha (Mondex, OFX, Integrion Gold, IFX, FSTC
eCheck, FSTC BIPS and EDI) vs two for numeric (SET and Proton)

So, on since the majority are leaning towards alpha, I plan to change the
IOTP specifcation so that CurrCodeType is "ISO4217-A" instead of just
"ISO4217" indicating that the currency code is an alphabetic currency code.

Regards

David
THIS EMAIL IS FOR UNLIMITED DISTRIBUTION.
> mailto:<[email-masked]>
> Mondex International, US Advanced Technology Office
> 111 Pine St, 6th Floor, San Francisco, CA 94111
> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
> 

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

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

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

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

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

To: [email-masked]
Subject: iotp.org
Date: Wed, 28 Apr 1999 16:07:10 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Just for your information, to reduce possibilities for confusion
between the old acronym (otp) and new (IOTP), I obtained iotp.org and
set it up for now to point to the grossly out of date otp.org web
site.  A simple updated web site should be developed so you can get at
it from either name...

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: "Lewis, Tony" <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: RE: Brand IDs & their registration. Was: RE: Comments on draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part  1
Date: Wed, 28 Apr 1999 12:45:48 -0700
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David,

I am new to this group and do not know what lead to the current approach.
There are undoubtedly some issues that I don't know about. However, it seems
to me that a brand is a brand no matter what payment protocol is being used.
The only difference I see between "IOTP:Visa" and "SET:Visa" is that the
latter indicates that the brand is supported by a specific payment protocol.
Since you need to support brands other than those supported by SET, there
will need to be a registry. It seems to me that there should only be one
such registry rather than the two being proposed. I recommend having a
single domain for these brands. It seems reasonable to initially populate it
using the brands registered with SET and those non-SET brands you listed in
your note.

Tony
> ----------
> From: 	David Burdett[SMTP:[email-masked]]
> Sent: 	Wednesday, April 28, 1999 11:36 AM
> To: 	Ietf Trade WG; Lewis, Tony
> Subject: 	Brand IDs & their registration. Was: RE: Comments on
> draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
> 
> In the current specification the basic idea for identifying brands is that
> they should be of the form "xxx:brandid" where "xxx" can be "SET" which
> indicates that the brandid is any valid brandid that is accepted by SET,
> or
> alternatively "IOTP" which can be used to define any brand not defined by
> SET. The idea was that we should not need to define "Visa", "MasterCard",
> "American Express", etc more than once since they are already defined and
> registered by SET.
> 
> However a couple of problems may arise ...
> 
> USING THE SET BRAND ID FOR NON-SET PAYMENTS
> Although IOTP can support SET as a payment protocol, it can also support
> credit card payments (using Secure Channel Credit Debit - SCCD) where the
> credit card information (no, name, expiration date, etc) is coded
> effectively in the clear but with privacy protection provided by using a
> secure channel such as SSL. In this way it provides a similar level of
> privacy/security as for credit card payments that occur now where a web
> page
> form is completed by the user.
> 
> My question is, will it be reasonable to use the SET brandid in this way
> to
> cover non-SET credit card payments. I *think* the answer is "yes" as you
> can
> quite imagine a situation where a consumer is offered a choice of using
> their VISA credit card to pay using either SET or SCCD.
> 
> WHAT BRAND ID SHOULD BE USED FOR CO BRANDS
> If a payment brand, such as a local brand or co-brand, chooses, initiall
> to
> use just SCCD rather than SET then they would not (I think) need to
> register
> their brand with SET. In this case, they might register their brand as an
> "IOTP" brand. However if they later adopted SET, they would end up with
> potentially two equivalent Brand IDs. Do you think we might be better off
> with a straight IOTP brand and keep all the names under the procedures
> defined by IANA? I'm not sure?
> 
> REGISTERING NEW BRAND IDs
> To help assist in answering the last point, the following is what I'm
> currently writing as the proposed IANA procedure for registering new brand
> ids. Any comments:
> 
> >>>Clip>>>
> The format of the Brand ID is either:
> *	SET:setbrand where setbrand is a brand which is accepted by the
> [SET] payment protocol
> *	IOTP:iotpbrand where iotpbrand may be:
> 	- GeldKarte
> 	- Mondex
> 
> New values of the high level prefix (SET or IOTP) should be allocated
> following review on the IETF Trade Working Group mailing list and by the
> Designated Expert.
> 
> Values of "setbrand" are allocated as defined in the [SET] specifications.
> 
> New values of "iotpbrand" must be announced to the IETF Trade WG mailing
> list and, if there are no objections within three weeks, be allocated on a
> "first come first served" basis.
> <<<End Clip<<<
> 
> Regards
> 
> David
> > ----------
> > From: 	Lewis, Tony[SMTP:[email-masked]]
> > Sent: 	28 April 1999 08:14
> > To: 	Ietf Trade WG
> > Subject: 	RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt,
> > part  1
> > 
> > In SET, the BrandID is either "brand" or "brand:product".
> > 
> > In Japan, there are products that are co-branded. Essentially these
> > products
> > are private label cards for domestic transactions with an international
> > brand for non-domestic transactions. The private label can be reflected
> in
> > a
> > SET cardholder certificate as the "promotional card name" under the
> > international brand's hierarchy and/or the cardholder can have a
> > certificate
> > issued under the private label hierarchy.
> > 
> > There is no provision to carry both the private label (of the Japanese
> > credit card company) and the international brand as part of the SET
> > BrandID.
> > 
> > Tony
> > > ----------
> > > From: 	David Burdett[SMTP:[email-masked]]
> > > Sent: 	Tuesday, April 27, 1999 6:31 PM
> > > To: 	Ietf Trade WG; [email-masked]
> > > Subject: 	RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt,
> > > part  1
> > > 
> > > I'm working my way through Don's comments and came across this one
> where
> > > our
> > > friends in Japan might be able to help ... I think ...
> > > 
> > > Don says ...
> > > 
> > > 	"I looked around a bit in SET literature and couldn't find anything
> > > about Dual or Promotional brands or anything about a three component
> SET
> > > Brand.  Two components, "brand" and "product" I see in the SET
> > literature,
> > > such a "MasterCard" or "Visa:Gold".  But not A:B:C and no case where a
> > > colon
> > > is included if there isn't anything after it.  In other words, it's
> > > "Visa",
> > > not "Visa:", and certainly not "Visa::" as a SET brand (re also
> examples
> > > in
> > > 6.6.1)."
> > > 
> > > This requirement arose as a result of meeting the needs of the Japan
> > > market.
> > > Can some people who are more familiar with this, please have a look at
> > > this
> > > part of the spec and check it is ok please?
> > > 
> > > David
> > > 
> > > > ----------
> > > > From: 	[email-masked][SMTP:[email-masked]]
> > > > Sent: 	22 April 1999 15:25
> > > > To: 	[email-masked]
> > > > Subject: 	Comments on
> draft-ietf-trade-iotp-v1.0-protocol-03.txt, part
> > > > 1
> > > > 
> > > > I've done a careful review of the document through section 6 and
> > section
> > > > 13
> > > > and greater and came up with the following somewhat length list of
> > > > suggestions.  I don't think they substantially change the intended
> > > meaning
> > > > of the document but those on the list should judge that.
> > > > 
> > > > 
> > > > IMPORTANT:
> > > > 
> > > > "IANA Considerations" needs to be a top level section, perhaps #11.
> > > > Gathering this stuff together into 3.7.3 is good but its still
> > > > unreasonable
> > > > to expect IANA to comb the document to find it.
> > > >      I'm not sure about the criteria for registration.  "IETF
> > Consensus"
> > > > is
> > > > pretty stiff and requires a vote of the IESG.  I should think
> someone
> > > > could
> > > > register an IOTP Band or CurrCode by publishing an RFC.  Perhaps
> that
> > is
> > > > what you mean for ProtocolId but it is not clear.
> > > >      Toward end so 3.7.3, change "with" to "without".
> > > > 
> > > > 
> > > > MISCELLANEOUS:
> > > > 
> > > > I don't understand the difference between "Objectives" and
> "Purpose".
> > I
> > > > suggest that 1.4 and 1.5 be merged and that the reference to "IOTP
> > > > Business
> > > > Description" which, as far as I know, is not intended to ever become
> > an
> > > > IETF document, be dropped.
> > > > 
> > > > Section 1.7 still refers to an XML Overview section 11.
> > > > 
> > > > Page spanning figures, like Figure 3, are really pretty messy.  It
> > would
> > > > be
> > > > better if the text could be made much more terse and this and
> similar
> > > > figures started high on a page so they aren't split by a page
> > boundary.
> > > > 
> > > > Section 2.2: suggest "The Open Trading Protocols identify" be
> changed
> > to
> > > > "IOTP identifies".
> > > > Section 2.2: says "IOTP Transactions are composed of these
> exchanges"
> > > but
> > > > does not list Inquiry or Ping exchange.
> > > > 
> > > > Starting in section 2.3 and many other places in the document, words
> > or
> > > > phrases are prefixed and suffixed by an underscore character ("_").
> > > This
> > > > is not any normal IETF style.  I suspect it means that the original
> > text
> > > > is
> > > > italic.  These should be suppressed or if that is impossible, a
> > separate
> > > > pass should be done to delete them.
> > > > 
> > > > In Figure 9, the things which are supposed to be identical or match
> > > aren't
> > > > and don't.  Is that deliberate?
> > > > 
> > > > I don't think that section 3.6 Brands and Brand Selection fits very
> > well
> > > > where it and suggest it be moved into section 10 which could be
> > renamed
> > > > "Brands".
> > > >      Continuing on Brands, I looked around a bit in SET literature
> and
> > > > couldn't find anything about Dual or Promotional brands or anything
> > > about
> > > > a
> > > > three component SET Brand.  Two components, "brand" and "product" I
> > see
> > > in
> > > > the SET literature, such a "MasterCard" or "Visa:Gold".  But not
> A:B:C
> > > and
> > > > no case where a colon is included if there isn't anything after it.
> > In
> > > > other words, it's "Visa", not "Visa:", and certainly not "Visa::" as
> a
> > > SET
> > > > brand (re also examples in 6.6.1). Can anyone give me any references
> > to
> > > > shed light on this?
> > > > 
> > > > Section 3.8.1: I don't understand why sub-pages of an HTML main page
> > > > couldn't have links back to the main page.
> > > > 
> > > > Section 4.1: first section reference says "0"?
> > > > 
> > > > Figures 10 and 11: These flow diagrams each *almost* fit on a page.
> If
> > > the
> > > > initial "Input IOTP Message" box could be to the side with a
> > horizontal
> > > > arrow and the text were edited down to something a bit more terse, I
> > > think
> > > > they would, which would be quite helpful.
> > > > 
> > > > Section 5: Suggest this section be called "Digital Signature" or
> > > > something.
> > > > Usually an IETF Security Considerations section is brief and talks
> > about
> > > > really high level issues.  Material in 5.4 is appropriate for
> Security
> > > > Considerations.  A separate Security Considerations section would
> need
> > > to
> > > > also say something about deciding when to require signatures, even
> if
> > it
> > > > is
> > > > just by referring to section 5.1.4, and about depending on payment
> > > scheme
> > > > security for the safety of funds, which I didn't see anywhere.
> > > >      Section 5 seems pretty heavy on certificates and public key
> > crypto,
> > > > especially given the originally IOTP v1.0 was going to be secret key
> > > only
> > > > and, as I recall, it was with some reluctance that public key hooks
> > were
> > > > added.  The stuff on checking a signature, for example, talks about
> > > > checking the certificate as if there always has to be one.
> > > >      Section 5.1.4: another reason you might not need signatures is
> > the
> > > > that the sender and receiver were on the same machine so it can
> check
> > > > integrity just by comparing with a saved copy.
> > > > 
> > > > Section 6.4.2: Need to eliminate reference to "Open Trading Protocol
> > > > Consortium" and suggest dropping whole note. I don't see any
> > difference
> > > at
> > > > all between OkTo/OkFrom and amount.  Both could appear in human
> > readable
> > > > form in the Order Description and in machine readable form in their
> > > > element.  Recommending that the UI display the machine readable
> > version
> > > is
> > > > reasonable (as in 6.4.1).
> > > > 
> > > > ContentSoftwareId: the standard text given for this is quite length
> > and
> > > > repeated dozens of time.  If it could be moved to the glossary or
> > > > something
> > > > and a simple "see glossary" put in, it would save many pages.
> > > > 
> > > > As previously discussed, change ISO4217 to ISO4217A or the like.
> > > > 
> > > > Just before section 6.7, it says that examples exist in 6.6 when
> they
> > > are
> > > > in 10.
> > > > 
> > > > Section 6.17: references to the Richard Brown draft and probably not
> > > > appropriate.  RFCs are not supposed to refer to drafts.  About the
> > > future,
> > > > I'm not sure you need to say anything but if you do, I think it
> should
> > > > just
> > > > say the future versions of IOTP will use industry standard XML
> > signature
> > > > technology if it meets IOTP requirements.
> > > >      Shouldn't 6.17.1 refer to the IOTP DSIG document?  It's OK to
> > refer
> > > > to
> > > > that draft because the idea is that it and the main protocol
> document
> > > will
> > > > be issued as RFCs simultaneously.  Maybe the XMLDSIG reference
> should
> > > just
> > > > be changed to refer to the IOTP DSIG document.
> > > >      There is a reference in  6.17.1 to payment scheme specific
> > > > algorithms.
> > > > Wouldn't their use be encapsulated inside the packaged contents and
> be
> > > in
> > > > the payment scheme modules, not an IOTP implementation itself?
> > > >      Section 6.18: similarly for certificate reference.  Should
> point
> > > out
> > > > that certs not needed for symmetric keying or for cases where public
> > key
> > > > has been registered at recipient.
> > > > 
> > > > Section 6.19.2: For ElContIllegal, ValueTooSmall, and ValueTooLarge,
> I
> > > > believe it should say "content" rather than "PackagedContent".
> > > > 
> > > > 
> > > > 
> > > > TRIVIAL NITS:
> > > > 
> > > > In the Abstract and section 1, Delivery Handler is capitalized but
> > > payment
> > > > handler isn't.
> > > > 
> > > > It is not usual to have a section like 1.7, History, in an IETF
> > > document.
> > > > If the evolution of a protocol sheds light on its technical content,
> > > > that's
> > > > one thing.  But it is not usual to have what is mostly a list of
> > editing
> > > > versions.  Suggest it be dropped to shorten the document.
> > > > 
> > > > I'm not sure why there is a skip to new page before section 3.1 or
> > > 3.1.2.
> > > > Suggest dropping these to make the document more compact.  RFC style
> > is
> > > to
> > > > have no skips to the start of a new page anywhere in the body text.
> > > > 
> > > > Section 3.8 example packaged content:  I don't like the "Name"s
> > FirstMsg
> > > > and SecondMsg.  Using Msg => Message seems confusing.  Suggest
> > > FirstPiece
> > > > and SecondPiece.
> > > > 
> > > > Section 3.10 says "Where both types of net location are present, the
> > > > following rules apply:" and then gives three rules only the third of
> > > which
> > > > applies in the described circumstances.  Suggest moving the first
> two
> > up
> > > > and combining the quoted phrase with the third.
> > > > 
> > > > Section 3.11.1 "treated by the recipient is an error": is -> as
> > > > 
> > > > Section 4: "There are a several ..." delete "a"
> > > > 
> > > > Section 4.4.1.2: in first sentence has -> have.
> > > > 
> > > > Section 4.4.2.9: in first sentence, insert "server" between "the"
> and
> > > > "unless".
> > > > 
> > > > Not sure why skip to new page before section 5.3.1 shortly before
> > Figure
> > > > 14
> > > > which overflows onto next page by just one line...
> > > > 
> > > > Section 5.3.1.1: numbered subsections, lettered subsubsections:  The
> > > text
> > > > at the ends of these 12 subsubsections is substantially the same.
> > > > Starting
> > > > with 3)b) sometimes the final period is omitted.  Suggest moving
> this
> > > text
> > > > up to the numbered section level or to before the whole two level
> > list.
> > > > 
> > > > Section 5.3.1.2: ditto 5.3.1.1 except list is one level.
> > > > 
> > > > Section 6.1: towards the end, delete "the" from "that the should".
> > > > 
> > > > Section 6.2: Insert "may be" after "there" in "there only one".
> > > > 
> > > > Section 6.5.5: PostalCode missing from detailed attributes list.
> > > > 
> > > > Just before 6.6.3 and 6.7.1: "in10" -> "in section 10".
> > > > 
> > > > Suggest replacing occurrences of "SSL" with "SSL/TLS" and adding the
> > TLS
> > > > RFC to the References.
> > > > 
> > > > Section 6.11:  has "Plain/Text" where other similar sentences use
> > "Plain
> > > > Text" which is probably better.  The "/" makes it look like a MIME
> > type
> > > > and
> > > > the MIME type is actually text/plain.  But I would suggest not using
> > the
> > > > MIME type as there isn't a unique one for HTML.
> > > > 
> > > > Section 6.12.1: DelivReqNetLocn & SecDelivReqNotLocn: "Mechanism
> must"
> > > ->
> > > > "Mechanism and must".
> > > > 
> > > > Section 6.13: Content, should be "PackagedContent" not "Delivery
> > Note".
> > > > 
> > > > 
> > > > 
> > > > REFERENCES (section 14)
> > > > 
> > > > For DOM-HASH, can't refer to any Internet-Drafts by URL or filename.
> > > For
> > > > HMAC, suggest refereing to RFC 2104 HMAC: Keyed-Hashing for Message
> > > > Authentication. H. Krawczyk, M. Bellare, R. Canetti. February 1997.
> > > > 
> > > > It looks pretty odd to the IETF spelled out in the RFC references.
> > I've
> > > > never seen that in an IETF document references section.
> > > > 
> > > > For SET, suggest referencing the SETco.org site, not Mastercard.
> > Can't
> > > > reference the Brown XMLDSIG draft in an RFC (although you can talk
> > about
> > > > it
> > > > without a URL or file name reference if necessary).
> > > > 
> > > > 
> > > > 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
> > > > 
> > > > 
> > > >
> > -----------------------------------------------------------------------
> > > > Message addressed to: [email-masked]
> > > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> > the
> > > > body to: [email-masked]
> > > > 
> > > 
> > >
> >
> **************************************************************************
> > > ********************
> > > 
> > > This Email and any attached files are confidential and may also be
> > > privileged. 
> > > If you are not the intended recipient, please notify the postmaster
> > using
> > > email 
> > > address [email-masked] or call +44 171 557 5000 and ask for the
> 
> > > IT Helpdesk.  You should not copy this email and any attached files,
> use
> > > them 
> > > for any purpose or disclose the contents to any other person; all
> copies
> > > of the 
> > > Email and associated files in your possession should be destroyed.
> > > 
> > > Mondex International Limited
> > > 47-53 Cannon Street
> > > London EC4M 5SQ
> > > United Kingdom
> > > Registered No: 3122085, England
> > > 
> > > Phone:          +44 171 557 5000
> > > Fax:            +44 171 557 5200
> > > Email:          [email-masked]
> > > WebSite:        http://www.mondexinternational.com
> > > 
> > >
> >
> **************************************************************************
> > > *******************
> > >
> -----------------------------------------------------------------------
> > > Message addressed to: [email-masked]
> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> > > body to: [email-masked]
> > > 
> > -----------------------------------------------------------------------
> > Message addressed to: [email-masked]
> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > body to: [email-masked]
> > 
> 
> **************************************************************************
> ********************
> 
> This Email and any attached files are confidential and may also be
> privileged. 
> If you are not the intended recipient, please notify the postmaster using
> email 
> address [email-masked] or call +44 171 557 5000 and ask for the 
> IT Helpdesk.  You should not copy this email and any attached files, use
> them 
> for any purpose or disclose the contents to any other person; all copies
> of the 
> Email and associated files in your possession should be destroyed.
> 
> Mondex International Limited
> 47-53 Cannon Street
> London EC4M 5SQ
> United Kingdom
> Registered No: 3122085, England
> 
> Phone:          +44 171 557 5000
> Fax:            +44 171 557 5200
> Email:          [email-masked]
> WebSite:        http://www.mondexinternational.com
> 
> **************************************************************************
> *******************
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
Cc: [email-masked]
Cc: [email-masked]
Subject: RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt, part  1
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Thu, 29 Apr 1999 04:52:39 +0900 (JST)
Lines: 406
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Tony,
Yes, we know about the definition of SET BrandId.

But SET/IOTP defines the IOTP BrandID as follows in order that we
can discount for each promotional brand and co-brand.

--
<Assumptions>
1. The brand identification codes (character strings) defined in SET
are used in the IOTP BrandID.

2. SET BrandID is defined as brand:[Product]. In SET, The brandID is
a brand name, which corresponds to the brand of the payment
card. Additional, The Product is a product name, which is defined the
type of product within the specific brand.

3. [Product] below is the same as the sub data of SET BrandID defined
in SET.

4. [PCN] below is a Promotional Card Name and is written in the
Certificates.

Set IOTP BrandId as follows.
SET:brand:[Product]:[PCN]

[]:Optional Field

Since SET BrandID has a colon between brand and Product, the three
colons should be able to delimit Brand, Product, and PCN.

Examples: 
SET:Visa:Gold:Walmart 
-> in this case, SET BrandID is "Visa:Gold".

SET:Visa::Visa-UC_Card
-> in this case, SET BrandID is "Visa".

SET:Visa::
-> in this case, SET BrandID is "Visa".

Thanks,

--
Yoshiaki Kawatsura Hitachi, Ltd.  

P.S. I will be in vacation from 29 Apr. to 9 Apr. This is called
golden week in Japanese. :-)

 >>>>> Wed, 28 Apr 1999 08:14:28 -0700,
	"Lewis, Tony" <[email-masked]> said:

> In SET, the BrandID is either "brand" or "brand:product".
> 
> In Japan, there are products that are co-branded. Essentially these products
> are private label cards for domestic transactions with an international
> brand for non-domestic transactions. The private label can be reflected in a
> SET cardholder certificate as the "promotional card name" under the
> international brand's hierarchy and/or the cardholder can have a certificate
> issued under the private label hierarchy.
> 
> There is no provision to carry both the private label (of the Japanese
> credit card company) and the international brand as part of the SET BrandID.
> 
> Tony
> > ----------
> > From: 	David Burdett[SMTP:[email-masked]]
> > Sent: 	Tuesday, April 27, 1999 6:31 PM
> > To: 	Ietf Trade WG; [email-masked]
> > Subject: 	RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt,
> > part  1
> > 
> > I'm working my way through Don's comments and came across this one where
> > our
> > friends in Japan might be able to help ... I think ...
> > 
> > Don says ...
> > 
> > 	"I looked around a bit in SET literature and couldn't find anything
> > about Dual or Promotional brands or anything about a three component SET
> > Brand.  Two components, "brand" and "product" I see in the SET literature,
> > such a "MasterCard" or "Visa:Gold".  But not A:B:C and no case where a
> > colon
> > is included if there isn't anything after it.  In other words, it's
> > "Visa",
> > not "Visa:", and certainly not "Visa::" as a SET brand (re also examples
> > in
> > 6.6.1)."
> > 
> > This requirement arose as a result of meeting the needs of the Japan
> > market.
> > Can some people who are more familiar with this, please have a look at
> > this
> > part of the spec and check it is ok please?
> > 
> > David
> > 
> > > ----------
> > > From: 	[email-masked][SMTP:[email-masked]]
> > > Sent: 	22 April 1999 15:25
> > > To: 	[email-masked]
> > > Subject: 	Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt, part
> > > 1
> > > 
> > > I've done a careful review of the document through section 6 and section
> > > 13
> > > and greater and came up with the following somewhat length list of
> > > suggestions.  I don't think they substantially change the intended
> > meaning
> > > of the document but those on the list should judge that.
> > > 
> > > 
> > > IMPORTANT:
> > > 
> > > "IANA Considerations" needs to be a top level section, perhaps #11.
> > > Gathering this stuff together into 3.7.3 is good but its still
> > > unreasonable
> > > to expect IANA to comb the document to find it.
> > >      I'm not sure about the criteria for registration.  "IETF Consensus"
> > > is
> > > pretty stiff and requires a vote of the IESG.  I should think someone
> > > could
> > > register an IOTP Band or CurrCode by publishing an RFC.  Perhaps that is
> > > what you mean for ProtocolId but it is not clear.
> > >      Toward end so 3.7.3, change "with" to "without".
> > > 
> > > 
> > > MISCELLANEOUS:
> > > 
> > > I don't understand the difference between "Objectives" and "Purpose".  I
> > > suggest that 1.4 and 1.5 be merged and that the reference to "IOTP
> > > Business
> > > Description" which, as far as I know, is not intended to ever become an
> > > IETF document, be dropped.
> > > 
> > > Section 1.7 still refers to an XML Overview section 11.
> > > 
> > > Page spanning figures, like Figure 3, are really pretty messy.  It would
> > > be
> > > better if the text could be made much more terse and this and similar
> > > figures started high on a page so they aren't split by a page boundary.
> > > 
> > > Section 2.2: suggest "The Open Trading Protocols identify" be changed to
> > > "IOTP identifies".
> > > Section 2.2: says "IOTP Transactions are composed of these exchanges"
> > but
> > > does not list Inquiry or Ping exchange.
> > > 
> > > Starting in section 2.3 and many other places in the document, words or
> > > phrases are prefixed and suffixed by an underscore character ("_").
> > This
> > > is not any normal IETF style.  I suspect it means that the original text
> > > is
> > > italic.  These should be suppressed or if that is impossible, a separate
> > > pass should be done to delete them.
> > > 
> > > In Figure 9, the things which are supposed to be identical or match
> > aren't
> > > and don't.  Is that deliberate?
> > > 
> > > I don't think that section 3.6 Brands and Brand Selection fits very well
> > > where it and suggest it be moved into section 10 which could be renamed
> > > "Brands".
> > >      Continuing on Brands, I looked around a bit in SET literature and
> > > couldn't find anything about Dual or Promotional brands or anything
> > about
> > > a
> > > three component SET Brand.  Two components, "brand" and "product" I see
> > in
> > > the SET literature, such a "MasterCard" or "Visa:Gold".  But not A:B:C
> > and
> > > no case where a colon is included if there isn't anything after it.  In
> > > other words, it's "Visa", not "Visa:", and certainly not "Visa::" as a
> > SET
> > > brand (re also examples in 6.6.1). Can anyone give me any references to
> > > shed light on this?
> > > 
> > > Section 3.8.1: I don't understand why sub-pages of an HTML main page
> > > couldn't have links back to the main page.
> > > 
> > > Section 4.1: first section reference says "0"?
> > > 
> > > Figures 10 and 11: These flow diagrams each *almost* fit on a page. If
> > the
> > > initial "Input IOTP Message" box could be to the side with a horizontal
> > > arrow and the text were edited down to something a bit more terse, I
> > think
> > > they would, which would be quite helpful.
> > > 
> > > Section 5: Suggest this section be called "Digital Signature" or
> > > something.
> > > Usually an IETF Security Considerations section is brief and talks about
> > > really high level issues.  Material in 5.4 is appropriate for Security
> > > Considerations.  A separate Security Considerations section would need
> > to
> > > also say something about deciding when to require signatures, even if it
> > > is
> > > just by referring to section 5.1.4, and about depending on payment
> > scheme
> > > security for the safety of funds, which I didn't see anywhere.
> > >      Section 5 seems pretty heavy on certificates and public key crypto,
> > > especially given the originally IOTP v1.0 was going to be secret key
> > only
> > > and, as I recall, it was with some reluctance that public key hooks were
> > > added.  The stuff on checking a signature, for example, talks about
> > > checking the certificate as if there always has to be one.
> > >      Section 5.1.4: another reason you might not need signatures is the
> > > that the sender and receiver were on the same machine so it can check
> > > integrity just by comparing with a saved copy.
> > > 
> > > Section 6.4.2: Need to eliminate reference to "Open Trading Protocol
> > > Consortium" and suggest dropping whole note. I don't see any difference
> > at
> > > all between OkTo/OkFrom and amount.  Both could appear in human readable
> > > form in the Order Description and in machine readable form in their
> > > element.  Recommending that the UI display the machine readable version
> > is
> > > reasonable (as in 6.4.1).
> > > 
> > > ContentSoftwareId: the standard text given for this is quite length and
> > > repeated dozens of time.  If it could be moved to the glossary or
> > > something
> > > and a simple "see glossary" put in, it would save many pages.
> > > 
> > > As previously discussed, change ISO4217 to ISO4217A or the like.
> > > 
> > > Just before section 6.7, it says that examples exist in 6.6 when they
> > are
> > > in 10.
> > > 
> > > Section 6.17: references to the Richard Brown draft and probably not
> > > appropriate.  RFCs are not supposed to refer to drafts.  About the
> > future,
> > > I'm not sure you need to say anything but if you do, I think it should
> > > just
> > > say the future versions of IOTP will use industry standard XML signature
> > > technology if it meets IOTP requirements.
> > >      Shouldn't 6.17.1 refer to the IOTP DSIG document?  It's OK to refer
> > > to
> > > that draft because the idea is that it and the main protocol document
> > will
> > > be issued as RFCs simultaneously.  Maybe the XMLDSIG reference should
> > just
> > > be changed to refer to the IOTP DSIG document.
> > >      There is a reference in  6.17.1 to payment scheme specific
> > > algorithms.
> > > Wouldn't their use be encapsulated inside the packaged contents and be
> > in
> > > the payment scheme modules, not an IOTP implementation itself?
> > >      Section 6.18: similarly for certificate reference.  Should point
> > out
> > > that certs not needed for symmetric keying or for cases where public key
> > > has been registered at recipient.
> > > 
> > > Section 6.19.2: For ElContIllegal, ValueTooSmall, and ValueTooLarge, I
> > > believe it should say "content" rather than "PackagedContent".
> > > 
> > > 
> > > 
> > > TRIVIAL NITS:
> > > 
> > > In the Abstract and section 1, Delivery Handler is capitalized but
> > payment
> > > handler isn't.
> > > 
> > > It is not usual to have a section like 1.7, History, in an IETF
> > document.
> > > If the evolution of a protocol sheds light on its technical content,
> > > that's
> > > one thing.  But it is not usual to have what is mostly a list of editing
> > > versions.  Suggest it be dropped to shorten the document.
> > > 
> > > I'm not sure why there is a skip to new page before section 3.1 or
> > 3.1.2.
> > > Suggest dropping these to make the document more compact.  RFC style is
> > to
> > > have no skips to the start of a new page anywhere in the body text.
> > > 
> > > Section 3.8 example packaged content:  I don't like the "Name"s FirstMsg
> > > and SecondMsg.  Using Msg => Message seems confusing.  Suggest
> > FirstPiece
> > > and SecondPiece.
> > > 
> > > Section 3.10 says "Where both types of net location are present, the
> > > following rules apply:" and then gives three rules only the third of
> > which
> > > applies in the described circumstances.  Suggest moving the first two up
> > > and combining the quoted phrase with the third.
> > > 
> > > Section 3.11.1 "treated by the recipient is an error": is -> as
> > > 
> > > Section 4: "There are a several ..." delete "a"
> > > 
> > > Section 4.4.1.2: in first sentence has -> have.
> > > 
> > > Section 4.4.2.9: in first sentence, insert "server" between "the" and
> > > "unless".
> > > 
> > > Not sure why skip to new page before section 5.3.1 shortly before Figure
> > > 14
> > > which overflows onto next page by just one line...
> > > 
> > > Section 5.3.1.1: numbered subsections, lettered subsubsections:  The
> > text
> > > at the ends of these 12 subsubsections is substantially the same.
> > > Starting
> > > with 3)b) sometimes the final period is omitted.  Suggest moving this
> > text
> > > up to the numbered section level or to before the whole two level list.
> > > 
> > > Section 5.3.1.2: ditto 5.3.1.1 except list is one level.
> > > 
> > > Section 6.1: towards the end, delete "the" from "that the should".
> > > 
> > > Section 6.2: Insert "may be" after "there" in "there only one".
> > > 
> > > Section 6.5.5: PostalCode missing from detailed attributes list.
> > > 
> > > Just before 6.6.3 and 6.7.1: "in10" -> "in section 10".
> > > 
> > > Suggest replacing occurrences of "SSL" with "SSL/TLS" and adding the TLS
> > > RFC to the References.
> > > 
> > > Section 6.11:  has "Plain/Text" where other similar sentences use "Plain
> > > Text" which is probably better.  The "/" makes it look like a MIME type
> > > and
> > > the MIME type is actually text/plain.  But I would suggest not using the
> > > MIME type as there isn't a unique one for HTML.
> > > 
> > > Section 6.12.1: DelivReqNetLocn & SecDelivReqNotLocn: "Mechanism must"
> > ->
> > > "Mechanism and must".
> > > 
> > > Section 6.13: Content, should be "PackagedContent" not "Delivery Note".
> > > 
> > > 
> > > 
> > > REFERENCES (section 14)
> > > 
> > > For DOM-HASH, can't refer to any Internet-Drafts by URL or filename.
> > For
> > > HMAC, suggest refereing to RFC 2104 HMAC: Keyed-Hashing for Message
> > > Authentication. H. Krawczyk, M. Bellare, R. Canetti. February 1997.
> > > 
> > > It looks pretty odd to the IETF spelled out in the RFC references.  I've
> > > never seen that in an IETF document references section.
> > > 
> > > For SET, suggest referencing the SETco.org site, not Mastercard.  Can't
> > > reference the Brown XMLDSIG draft in an RFC (although you can talk about
> > > it
> > > without a URL or file name reference if necessary).
> > > 
> > > 
> > > 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
> > > 
> > > 
> > > -----------------------------------------------------------------------
> > > Message addressed to: [email-masked]
> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > > body to: [email-masked]
> > > 
> > 
> > **************************************************************************
> > ********************
> > 
> > This Email and any attached files are confidential and may also be
> > privileged. 
> > If you are not the intended recipient, please notify the postmaster using
> > email 
> > address [email-masked] or call +44 171 557 5000 and ask for the 
> > IT Helpdesk.  You should not copy this email and any attached files, use
> > them 
> > for any purpose or disclose the contents to any other person; all copies
> > of the 
> > Email and associated files in your possession should be destroyed.
> > 
> > Mondex International Limited
> > 47-53 Cannon Street
> > London EC4M 5SQ
> > United Kingdom
> > Registered No: 3122085, England
> > 
> > Phone:          +44 171 557 5000
> > Fax:            +44 171 557 5200
> > Email:          [email-masked]
> > WebSite:        http://www.mondexinternational.com
> > 
> > **************************************************************************
> > *******************
> > -----------------------------------------------------------------------
> > Message addressed to: [email-masked]
> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > body to: [email-masked]
> > 
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>, "Lewis, Tony" <[email-masked]>
Subject: Brand IDs & their registration. Was: RE: Comments on draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
Date: Wed, 28 Apr 1999 19:36:56 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

In the current specification the basic idea for identifying brands is that
they should be of the form "xxx:brandid" where "xxx" can be "SET" which
indicates that the brandid is any valid brandid that is accepted by SET, or
alternatively "IOTP" which can be used to define any brand not defined by
SET. The idea was that we should not need to define "Visa", "MasterCard",
"American Express", etc more than once since they are already defined and
registered by SET.

However a couple of problems may arise ...

USING THE SET BRAND ID FOR NON-SET PAYMENTS
Although IOTP can support SET as a payment protocol, it can also support
credit card payments (using Secure Channel Credit Debit - SCCD) where the
credit card information (no, name, expiration date, etc) is coded
effectively in the clear but with privacy protection provided by using a
secure channel such as SSL. In this way it provides a similar level of
privacy/security as for credit card payments that occur now where a web page
form is completed by the user.

My question is, will it be reasonable to use the SET brandid in this way to
cover non-SET credit card payments. I *think* the answer is "yes" as you can
quite imagine a situation where a consumer is offered a choice of using
their VISA credit card to pay using either SET or SCCD.

WHAT BRAND ID SHOULD BE USED FOR CO BRANDS
If a payment brand, such as a local brand or co-brand, chooses, initiall to
use just SCCD rather than SET then they would not (I think) need to register
their brand with SET. In this case, they might register their brand as an
"IOTP" brand. However if they later adopted SET, they would end up with
potentially two equivalent Brand IDs. Do you think we might be better off
with a straight IOTP brand and keep all the names under the procedures
defined by IANA? I'm not sure?

REGISTERING NEW BRAND IDs
To help assist in answering the last point, the following is what I'm
currently writing as the proposed IANA procedure for registering new brand
ids. Any comments:

>>>Clip>>>
The format of the Brand ID is either:
*	SET:setbrand where setbrand is a brand which is accepted by the
[SET] payment protocol
*	IOTP:iotpbrand where iotpbrand may be:
	- GeldKarte
	- Mondex

New values of the high level prefix (SET or IOTP) should be allocated
following review on the IETF Trade Working Group mailing list and by the
Designated Expert.

Values of "setbrand" are allocated as defined in the [SET] specifications.

New values of "iotpbrand" must be announced to the IETF Trade WG mailing
list and, if there are no objections within three weeks, be allocated on a
"first come first served" basis.
<<<End Clip<<<

Regards

David
> ----------
> From: 	Lewis, Tony[SMTP:[email-masked]]
> Sent: 	28 April 1999 08:14
> To: 	Ietf Trade WG
> Subject: 	RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt,
> part  1
> 
> In SET, the BrandID is either "brand" or "brand:product".
> 
> In Japan, there are products that are co-branded. Essentially these
> products
> are private label cards for domestic transactions with an international
> brand for non-domestic transactions. The private label can be reflected in
> a
> SET cardholder certificate as the "promotional card name" under the
> international brand's hierarchy and/or the cardholder can have a
> certificate
> issued under the private label hierarchy.
> 
> There is no provision to carry both the private label (of the Japanese
> credit card company) and the international brand as part of the SET
> BrandID.
> 
> Tony
> > ----------
> > From: 	David Burdett[SMTP:[email-masked]]
> > Sent: 	Tuesday, April 27, 1999 6:31 PM
> > To: 	Ietf Trade WG; [email-masked]
> > Subject: 	RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt,
> > part  1
> > 
> > I'm working my way through Don's comments and came across this one where
> > our
> > friends in Japan might be able to help ... I think ...
> > 
> > Don says ...
> > 
> > 	"I looked around a bit in SET literature and couldn't find anything
> > about Dual or Promotional brands or anything about a three component SET
> > Brand.  Two components, "brand" and "product" I see in the SET
> literature,
> > such a "MasterCard" or "Visa:Gold".  But not A:B:C and no case where a
> > colon
> > is included if there isn't anything after it.  In other words, it's
> > "Visa",
> > not "Visa:", and certainly not "Visa::" as a SET brand (re also examples
> > in
> > 6.6.1)."
> > 
> > This requirement arose as a result of meeting the needs of the Japan
> > market.
> > Can some people who are more familiar with this, please have a look at
> > this
> > part of the spec and check it is ok please?
> > 
> > David
> > 
> > > ----------
> > > From: 	[email-masked][SMTP:[email-masked]]
> > > Sent: 	22 April 1999 15:25
> > > To: 	[email-masked]
> > > Subject: 	Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt, part
> > > 1
> > > 
> > > I've done a careful review of the document through section 6 and
> section
> > > 13
> > > and greater and came up with the following somewhat length list of
> > > suggestions.  I don't think they substantially change the intended
> > meaning
> > > of the document but those on the list should judge that.
> > > 
> > > 
> > > IMPORTANT:
> > > 
> > > "IANA Considerations" needs to be a top level section, perhaps #11.
> > > Gathering this stuff together into 3.7.3 is good but its still
> > > unreasonable
> > > to expect IANA to comb the document to find it.
> > >      I'm not sure about the criteria for registration.  "IETF
> Consensus"
> > > is
> > > pretty stiff and requires a vote of the IESG.  I should think someone
> > > could
> > > register an IOTP Band or CurrCode by publishing an RFC.  Perhaps that
> is
> > > what you mean for ProtocolId but it is not clear.
> > >      Toward end so 3.7.3, change "with" to "without".
> > > 
> > > 
> > > MISCELLANEOUS:
> > > 
> > > I don't understand the difference between "Objectives" and "Purpose".
> I
> > > suggest that 1.4 and 1.5 be merged and that the reference to "IOTP
> > > Business
> > > Description" which, as far as I know, is not intended to ever become
> an
> > > IETF document, be dropped.
> > > 
> > > Section 1.7 still refers to an XML Overview section 11.
> > > 
> > > Page spanning figures, like Figure 3, are really pretty messy.  It
> would
> > > be
> > > better if the text could be made much more terse and this and similar
> > > figures started high on a page so they aren't split by a page
> boundary.
> > > 
> > > Section 2.2: suggest "The Open Trading Protocols identify" be changed
> to
> > > "IOTP identifies".
> > > Section 2.2: says "IOTP Transactions are composed of these exchanges"
> > but
> > > does not list Inquiry or Ping exchange.
> > > 
> > > Starting in section 2.3 and many other places in the document, words
> or
> > > phrases are prefixed and suffixed by an underscore character ("_").
> > This
> > > is not any normal IETF style.  I suspect it means that the original
> text
> > > is
> > > italic.  These should be suppressed or if that is impossible, a
> separate
> > > pass should be done to delete them.
> > > 
> > > In Figure 9, the things which are supposed to be identical or match
> > aren't
> > > and don't.  Is that deliberate?
> > > 
> > > I don't think that section 3.6 Brands and Brand Selection fits very
> well
> > > where it and suggest it be moved into section 10 which could be
> renamed
> > > "Brands".
> > >      Continuing on Brands, I looked around a bit in SET literature and
> > > couldn't find anything about Dual or Promotional brands or anything
> > about
> > > a
> > > three component SET Brand.  Two components, "brand" and "product" I
> see
> > in
> > > the SET literature, such a "MasterCard" or "Visa:Gold".  But not A:B:C
> > and
> > > no case where a colon is included if there isn't anything after it.
> In
> > > other words, it's "Visa", not "Visa:", and certainly not "Visa::" as a
> > SET
> > > brand (re also examples in 6.6.1). Can anyone give me any references
> to
> > > shed light on this?
> > > 
> > > Section 3.8.1: I don't understand why sub-pages of an HTML main page
> > > couldn't have links back to the main page.
> > > 
> > > Section 4.1: first section reference says "0"?
> > > 
> > > Figures 10 and 11: These flow diagrams each *almost* fit on a page. If
> > the
> > > initial "Input IOTP Message" box could be to the side with a
> horizontal
> > > arrow and the text were edited down to something a bit more terse, I
> > think
> > > they would, which would be quite helpful.
> > > 
> > > Section 5: Suggest this section be called "Digital Signature" or
> > > something.
> > > Usually an IETF Security Considerations section is brief and talks
> about
> > > really high level issues.  Material in 5.4 is appropriate for Security
> > > Considerations.  A separate Security Considerations section would need
> > to
> > > also say something about deciding when to require signatures, even if
> it
> > > is
> > > just by referring to section 5.1.4, and about depending on payment
> > scheme
> > > security for the safety of funds, which I didn't see anywhere.
> > >      Section 5 seems pretty heavy on certificates and public key
> crypto,
> > > especially given the originally IOTP v1.0 was going to be secret key
> > only
> > > and, as I recall, it was with some reluctance that public key hooks
> were
> > > added.  The stuff on checking a signature, for example, talks about
> > > checking the certificate as if there always has to be one.
> > >      Section 5.1.4: another reason you might not need signatures is
> the
> > > that the sender and receiver were on the same machine so it can check
> > > integrity just by comparing with a saved copy.
> > > 
> > > Section 6.4.2: Need to eliminate reference to "Open Trading Protocol
> > > Consortium" and suggest dropping whole note. I don't see any
> difference
> > at
> > > all between OkTo/OkFrom and amount.  Both could appear in human
> readable
> > > form in the Order Description and in machine readable form in their
> > > element.  Recommending that the UI display the machine readable
> version
> > is
> > > reasonable (as in 6.4.1).
> > > 
> > > ContentSoftwareId: the standard text given for this is quite length
> and
> > > repeated dozens of time.  If it could be moved to the glossary or
> > > something
> > > and a simple "see glossary" put in, it would save many pages.
> > > 
> > > As previously discussed, change ISO4217 to ISO4217A or the like.
> > > 
> > > Just before section 6.7, it says that examples exist in 6.6 when they
> > are
> > > in 10.
> > > 
> > > Section 6.17: references to the Richard Brown draft and probably not
> > > appropriate.  RFCs are not supposed to refer to drafts.  About the
> > future,
> > > I'm not sure you need to say anything but if you do, I think it should
> > > just
> > > say the future versions of IOTP will use industry standard XML
> signature
> > > technology if it meets IOTP requirements.
> > >      Shouldn't 6.17.1 refer to the IOTP DSIG document?  It's OK to
> refer
> > > to
> > > that draft because the idea is that it and the main protocol document
> > will
> > > be issued as RFCs simultaneously.  Maybe the XMLDSIG reference should
> > just
> > > be changed to refer to the IOTP DSIG document.
> > >      There is a reference in  6.17.1 to payment scheme specific
> > > algorithms.
> > > Wouldn't their use be encapsulated inside the packaged contents and be
> > in
> > > the payment scheme modules, not an IOTP implementation itself?
> > >      Section 6.18: similarly for certificate reference.  Should point
> > out
> > > that certs not needed for symmetric keying or for cases where public
> key
> > > has been registered at recipient.
> > > 
> > > Section 6.19.2: For ElContIllegal, ValueTooSmall, and ValueTooLarge, I
> > > believe it should say "content" rather than "PackagedContent".
> > > 
> > > 
> > > 
> > > TRIVIAL NITS:
> > > 
> > > In the Abstract and section 1, Delivery Handler is capitalized but
> > payment
> > > handler isn't.
> > > 
> > > It is not usual to have a section like 1.7, History, in an IETF
> > document.
> > > If the evolution of a protocol sheds light on its technical content,
> > > that's
> > > one thing.  But it is not usual to have what is mostly a list of
> editing
> > > versions.  Suggest it be dropped to shorten the document.
> > > 
> > > I'm not sure why there is a skip to new page before section 3.1 or
> > 3.1.2.
> > > Suggest dropping these to make the document more compact.  RFC style
> is
> > to
> > > have no skips to the start of a new page anywhere in the body text.
> > > 
> > > Section 3.8 example packaged content:  I don't like the "Name"s
> FirstMsg
> > > and SecondMsg.  Using Msg => Message seems confusing.  Suggest
> > FirstPiece
> > > and SecondPiece.
> > > 
> > > Section 3.10 says "Where both types of net location are present, the
> > > following rules apply:" and then gives three rules only the third of
> > which
> > > applies in the described circumstances.  Suggest moving the first two
> up
> > > and combining the quoted phrase with the third.
> > > 
> > > Section 3.11.1 "treated by the recipient is an error": is -> as
> > > 
> > > Section 4: "There are a several ..." delete "a"
> > > 
> > > Section 4.4.1.2: in first sentence has -> have.
> > > 
> > > Section 4.4.2.9: in first sentence, insert "server" between "the" and
> > > "unless".
> > > 
> > > Not sure why skip to new page before section 5.3.1 shortly before
> Figure
> > > 14
> > > which overflows onto next page by just one line...
> > > 
> > > Section 5.3.1.1: numbered subsections, lettered subsubsections:  The
> > text
> > > at the ends of these 12 subsubsections is substantially the same.
> > > Starting
> > > with 3)b) sometimes the final period is omitted.  Suggest moving this
> > text
> > > up to the numbered section level or to before the whole two level
> list.
> > > 
> > > Section 5.3.1.2: ditto 5.3.1.1 except list is one level.
> > > 
> > > Section 6.1: towards the end, delete "the" from "that the should".
> > > 
> > > Section 6.2: Insert "may be" after "there" in "there only one".
> > > 
> > > Section 6.5.5: PostalCode missing from detailed attributes list.
> > > 
> > > Just before 6.6.3 and 6.7.1: "in10" -> "in section 10".
> > > 
> > > Suggest replacing occurrences of "SSL" with "SSL/TLS" and adding the
> TLS
> > > RFC to the References.
> > > 
> > > Section 6.11:  has "Plain/Text" where other similar sentences use
> "Plain
> > > Text" which is probably better.  The "/" makes it look like a MIME
> type
> > > and
> > > the MIME type is actually text/plain.  But I would suggest not using
> the
> > > MIME type as there isn't a unique one for HTML.
> > > 
> > > Section 6.12.1: DelivReqNetLocn & SecDelivReqNotLocn: "Mechanism must"
> > ->
> > > "Mechanism and must".
> > > 
> > > Section 6.13: Content, should be "PackagedContent" not "Delivery
> Note".
> > > 
> > > 
> > > 
> > > REFERENCES (section 14)
> > > 
> > > For DOM-HASH, can't refer to any Internet-Drafts by URL or filename.
> > For
> > > HMAC, suggest refereing to RFC 2104 HMAC: Keyed-Hashing for Message
> > > Authentication. H. Krawczyk, M. Bellare, R. Canetti. February 1997.
> > > 
> > > It looks pretty odd to the IETF spelled out in the RFC references.
> I've
> > > never seen that in an IETF document references section.
> > > 
> > > For SET, suggest referencing the SETco.org site, not Mastercard.
> Can't
> > > reference the Brown XMLDSIG draft in an RFC (although you can talk
> about
> > > it
> > > without a URL or file name reference if necessary).
> > > 
> > > 
> > > 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
> > > 
> > > 
> > >
> -----------------------------------------------------------------------
> > > Message addressed to: [email-masked]
> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> > > body to: [email-masked]
> > > 
> > 
> >
> **************************************************************************
> > ********************
> > 
> > This Email and any attached files are confidential and may also be
> > privileged. 
> > If you are not the intended recipient, please notify the postmaster
> using
> > email 
> > address [email-masked] or call +44 171 557 5000 and ask for the 
> > IT Helpdesk.  You should not copy this email and any attached files, use
> > them 
> > for any purpose or disclose the contents to any other person; all copies
> > of the 
> > Email and associated files in your possession should be destroyed.
> > 
> > Mondex International Limited
> > 47-53 Cannon Street
> > London EC4M 5SQ
> > United Kingdom
> > Registered No: 3122085, England
> > 
> > Phone:          +44 171 557 5000
> > Fax:            +44 171 557 5200
> > Email:          [email-masked]
> > WebSite:        http://www.mondexinternational.com
> > 
> >
> **************************************************************************
> > *******************
> > -----------------------------------------------------------------------
> > Message addressed to: [email-masked]
> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > body to: [email-masked]
> > 
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 

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

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

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

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

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

From: "Lewis, Tony" <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt, part  1
Date: Wed, 28 Apr 1999 08:14:28 -0700
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

In SET, the BrandID is either "brand" or "brand:product".

In Japan, there are products that are co-branded. Essentially these products
are private label cards for domestic transactions with an international
brand for non-domestic transactions. The private label can be reflected in a
SET cardholder certificate as the "promotional card name" under the
international brand's hierarchy and/or the cardholder can have a certificate
issued under the private label hierarchy.

There is no provision to carry both the private label (of the Japanese
credit card company) and the international brand as part of the SET BrandID.

Tony
> ----------
> From: 	David Burdett[SMTP:[email-masked]]
> Sent: 	Tuesday, April 27, 1999 6:31 PM
> To: 	Ietf Trade WG; [email-masked]
> Subject: 	RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt,
> part  1
> 
> I'm working my way through Don's comments and came across this one where
> our
> friends in Japan might be able to help ... I think ...
> 
> Don says ...
> 
> 	"I looked around a bit in SET literature and couldn't find anything
> about Dual or Promotional brands or anything about a three component SET
> Brand.  Two components, "brand" and "product" I see in the SET literature,
> such a "MasterCard" or "Visa:Gold".  But not A:B:C and no case where a
> colon
> is included if there isn't anything after it.  In other words, it's
> "Visa",
> not "Visa:", and certainly not "Visa::" as a SET brand (re also examples
> in
> 6.6.1)."
> 
> This requirement arose as a result of meeting the needs of the Japan
> market.
> Can some people who are more familiar with this, please have a look at
> this
> part of the spec and check it is ok please?
> 
> David
> 
> > ----------
> > From: 	[email-masked][SMTP:[email-masked]]
> > Sent: 	22 April 1999 15:25
> > To: 	[email-masked]
> > Subject: 	Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt, part
> > 1
> > 
> > I've done a careful review of the document through section 6 and section
> > 13
> > and greater and came up with the following somewhat length list of
> > suggestions.  I don't think they substantially change the intended
> meaning
> > of the document but those on the list should judge that.
> > 
> > 
> > IMPORTANT:
> > 
> > "IANA Considerations" needs to be a top level section, perhaps #11.
> > Gathering this stuff together into 3.7.3 is good but its still
> > unreasonable
> > to expect IANA to comb the document to find it.
> >      I'm not sure about the criteria for registration.  "IETF Consensus"
> > is
> > pretty stiff and requires a vote of the IESG.  I should think someone
> > could
> > register an IOTP Band or CurrCode by publishing an RFC.  Perhaps that is
> > what you mean for ProtocolId but it is not clear.
> >      Toward end so 3.7.3, change "with" to "without".
> > 
> > 
> > MISCELLANEOUS:
> > 
> > I don't understand the difference between "Objectives" and "Purpose".  I
> > suggest that 1.4 and 1.5 be merged and that the reference to "IOTP
> > Business
> > Description" which, as far as I know, is not intended to ever become an
> > IETF document, be dropped.
> > 
> > Section 1.7 still refers to an XML Overview section 11.
> > 
> > Page spanning figures, like Figure 3, are really pretty messy.  It would
> > be
> > better if the text could be made much more terse and this and similar
> > figures started high on a page so they aren't split by a page boundary.
> > 
> > Section 2.2: suggest "The Open Trading Protocols identify" be changed to
> > "IOTP identifies".
> > Section 2.2: says "IOTP Transactions are composed of these exchanges"
> but
> > does not list Inquiry or Ping exchange.
> > 
> > Starting in section 2.3 and many other places in the document, words or
> > phrases are prefixed and suffixed by an underscore character ("_").
> This
> > is not any normal IETF style.  I suspect it means that the original text
> > is
> > italic.  These should be suppressed or if that is impossible, a separate
> > pass should be done to delete them.
> > 
> > In Figure 9, the things which are supposed to be identical or match
> aren't
> > and don't.  Is that deliberate?
> > 
> > I don't think that section 3.6 Brands and Brand Selection fits very well
> > where it and suggest it be moved into section 10 which could be renamed
> > "Brands".
> >      Continuing on Brands, I looked around a bit in SET literature and
> > couldn't find anything about Dual or Promotional brands or anything
> about
> > a
> > three component SET Brand.  Two components, "brand" and "product" I see
> in
> > the SET literature, such a "MasterCard" or "Visa:Gold".  But not A:B:C
> and
> > no case where a colon is included if there isn't anything after it.  In
> > other words, it's "Visa", not "Visa:", and certainly not "Visa::" as a
> SET
> > brand (re also examples in 6.6.1). Can anyone give me any references to
> > shed light on this?
> > 
> > Section 3.8.1: I don't understand why sub-pages of an HTML main page
> > couldn't have links back to the main page.
> > 
> > Section 4.1: first section reference says "0"?
> > 
> > Figures 10 and 11: These flow diagrams each *almost* fit on a page. If
> the
> > initial "Input IOTP Message" box could be to the side with a horizontal
> > arrow and the text were edited down to something a bit more terse, I
> think
> > they would, which would be quite helpful.
> > 
> > Section 5: Suggest this section be called "Digital Signature" or
> > something.
> > Usually an IETF Security Considerations section is brief and talks about
> > really high level issues.  Material in 5.4 is appropriate for Security
> > Considerations.  A separate Security Considerations section would need
> to
> > also say something about deciding when to require signatures, even if it
> > is
> > just by referring to section 5.1.4, and about depending on payment
> scheme
> > security for the safety of funds, which I didn't see anywhere.
> >      Section 5 seems pretty heavy on certificates and public key crypto,
> > especially given the originally IOTP v1.0 was going to be secret key
> only
> > and, as I recall, it was with some reluctance that public key hooks were
> > added.  The stuff on checking a signature, for example, talks about
> > checking the certificate as if there always has to be one.
> >      Section 5.1.4: another reason you might not need signatures is the
> > that the sender and receiver were on the same machine so it can check
> > integrity just by comparing with a saved copy.
> > 
> > Section 6.4.2: Need to eliminate reference to "Open Trading Protocol
> > Consortium" and suggest dropping whole note. I don't see any difference
> at
> > all between OkTo/OkFrom and amount.  Both could appear in human readable
> > form in the Order Description and in machine readable form in their
> > element.  Recommending that the UI display the machine readable version
> is
> > reasonable (as in 6.4.1).
> > 
> > ContentSoftwareId: the standard text given for this is quite length and
> > repeated dozens of time.  If it could be moved to the glossary or
> > something
> > and a simple "see glossary" put in, it would save many pages.
> > 
> > As previously discussed, change ISO4217 to ISO4217A or the like.
> > 
> > Just before section 6.7, it says that examples exist in 6.6 when they
> are
> > in 10.
> > 
> > Section 6.17: references to the Richard Brown draft and probably not
> > appropriate.  RFCs are not supposed to refer to drafts.  About the
> future,
> > I'm not sure you need to say anything but if you do, I think it should
> > just
> > say the future versions of IOTP will use industry standard XML signature
> > technology if it meets IOTP requirements.
> >      Shouldn't 6.17.1 refer to the IOTP DSIG document?  It's OK to refer
> > to
> > that draft because the idea is that it and the main protocol document
> will
> > be issued as RFCs simultaneously.  Maybe the XMLDSIG reference should
> just
> > be changed to refer to the IOTP DSIG document.
> >      There is a reference in  6.17.1 to payment scheme specific
> > algorithms.
> > Wouldn't their use be encapsulated inside the packaged contents and be
> in
> > the payment scheme modules, not an IOTP implementation itself?
> >      Section 6.18: similarly for certificate reference.  Should point
> out
> > that certs not needed for symmetric keying or for cases where public key
> > has been registered at recipient.
> > 
> > Section 6.19.2: For ElContIllegal, ValueTooSmall, and ValueTooLarge, I
> > believe it should say "content" rather than "PackagedContent".
> > 
> > 
> > 
> > TRIVIAL NITS:
> > 
> > In the Abstract and section 1, Delivery Handler is capitalized but
> payment
> > handler isn't.
> > 
> > It is not usual to have a section like 1.7, History, in an IETF
> document.
> > If the evolution of a protocol sheds light on its technical content,
> > that's
> > one thing.  But it is not usual to have what is mostly a list of editing
> > versions.  Suggest it be dropped to shorten the document.
> > 
> > I'm not sure why there is a skip to new page before section 3.1 or
> 3.1.2.
> > Suggest dropping these to make the document more compact.  RFC style is
> to
> > have no skips to the start of a new page anywhere in the body text.
> > 
> > Section 3.8 example packaged content:  I don't like the "Name"s FirstMsg
> > and SecondMsg.  Using Msg => Message seems confusing.  Suggest
> FirstPiece
> > and SecondPiece.
> > 
> > Section 3.10 says "Where both types of net location are present, the
> > following rules apply:" and then gives three rules only the third of
> which
> > applies in the described circumstances.  Suggest moving the first two up
> > and combining the quoted phrase with the third.
> > 
> > Section 3.11.1 "treated by the recipient is an error": is -> as
> > 
> > Section 4: "There are a several ..." delete "a"
> > 
> > Section 4.4.1.2: in first sentence has -> have.
> > 
> > Section 4.4.2.9: in first sentence, insert "server" between "the" and
> > "unless".
> > 
> > Not sure why skip to new page before section 5.3.1 shortly before Figure
> > 14
> > which overflows onto next page by just one line...
> > 
> > Section 5.3.1.1: numbered subsections, lettered subsubsections:  The
> text
> > at the ends of these 12 subsubsections is substantially the same.
> > Starting
> > with 3)b) sometimes the final period is omitted.  Suggest moving this
> text
> > up to the numbered section level or to before the whole two level list.
> > 
> > Section 5.3.1.2: ditto 5.3.1.1 except list is one level.
> > 
> > Section 6.1: towards the end, delete "the" from "that the should".
> > 
> > Section 6.2: Insert "may be" after "there" in "there only one".
> > 
> > Section 6.5.5: PostalCode missing from detailed attributes list.
> > 
> > Just before 6.6.3 and 6.7.1: "in10" -> "in section 10".
> > 
> > Suggest replacing occurrences of "SSL" with "SSL/TLS" and adding the TLS
> > RFC to the References.
> > 
> > Section 6.11:  has "Plain/Text" where other similar sentences use "Plain
> > Text" which is probably better.  The "/" makes it look like a MIME type
> > and
> > the MIME type is actually text/plain.  But I would suggest not using the
> > MIME type as there isn't a unique one for HTML.
> > 
> > Section 6.12.1: DelivReqNetLocn & SecDelivReqNotLocn: "Mechanism must"
> ->
> > "Mechanism and must".
> > 
> > Section 6.13: Content, should be "PackagedContent" not "Delivery Note".
> > 
> > 
> > 
> > REFERENCES (section 14)
> > 
> > For DOM-HASH, can't refer to any Internet-Drafts by URL or filename.
> For
> > HMAC, suggest refereing to RFC 2104 HMAC: Keyed-Hashing for Message
> > Authentication. H. Krawczyk, M. Bellare, R. Canetti. February 1997.
> > 
> > It looks pretty odd to the IETF spelled out in the RFC references.  I've
> > never seen that in an IETF document references section.
> > 
> > For SET, suggest referencing the SETco.org site, not Mastercard.  Can't
> > reference the Brown XMLDSIG draft in an RFC (although you can talk about
> > it
> > without a URL or file name reference if necessary).
> > 
> > 
> > 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
> > 
> > 
> > -----------------------------------------------------------------------
> > Message addressed to: [email-masked]
> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > body to: [email-masked]
> > 
> 
> **************************************************************************
> ********************
> 
> This Email and any attached files are confidential and may also be
> privileged. 
> If you are not the intended recipient, please notify the postmaster using
> email 
> address [email-masked] or call +44 171 557 5000 and ask for the 
> IT Helpdesk.  You should not copy this email and any attached files, use
> them 
> for any purpose or disclose the contents to any other person; all copies
> of the 
> Email and associated files in your possession should be destroyed.
> 
> Mondex International Limited
> 47-53 Cannon Street
> London EC4M 5SQ
> United Kingdom
> Registered No: 3122085, England
> 
> Phone:          +44 171 557 5000
> Fax:            +44 171 557 5200
> Email:          [email-masked]
> WebSite:        http://www.mondexinternational.com
> 
> **************************************************************************
> *******************
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>, [email-masked]
Subject: RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt, part  1
Date: Wed, 28 Apr 1999 02:31:36 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I'm working my way through Don's comments and came across this one where our
friends in Japan might be able to help ... I think ...

Don says ...

	"I looked around a bit in SET literature and couldn't find anything
about Dual or Promotional brands or anything about a three component SET
Brand.  Two components, "brand" and "product" I see in the SET literature,
such a "MasterCard" or "Visa:Gold".  But not A:B:C and no case where a colon
is included if there isn't anything after it.  In other words, it's "Visa",
not "Visa:", and certainly not "Visa::" as a SET brand (re also examples in
6.6.1)."

This requirement arose as a result of meeting the needs of the Japan market.
Can some people who are more familiar with this, please have a look at this
part of the spec and check it is ok please?

David

> ----------
> From: 	[email-masked][SMTP:[email-masked]]
> Sent: 	22 April 1999 15:25
> To: 	[email-masked]
> Subject: 	Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt, part
> 1
> 
> I've done a careful review of the document through section 6 and section
> 13
> and greater and came up with the following somewhat length list of
> suggestions.  I don't think they substantially change the intended meaning
> of the document but those on the list should judge that.
> 
> 
> IMPORTANT:
> 
> "IANA Considerations" needs to be a top level section, perhaps #11.
> Gathering this stuff together into 3.7.3 is good but its still
> unreasonable
> to expect IANA to comb the document to find it.
>      I'm not sure about the criteria for registration.  "IETF Consensus"
> is
> pretty stiff and requires a vote of the IESG.  I should think someone
> could
> register an IOTP Band or CurrCode by publishing an RFC.  Perhaps that is
> what you mean for ProtocolId but it is not clear.
>      Toward end so 3.7.3, change "with" to "without".
> 
> 
> MISCELLANEOUS:
> 
> I don't understand the difference between "Objectives" and "Purpose".  I
> suggest that 1.4 and 1.5 be merged and that the reference to "IOTP
> Business
> Description" which, as far as I know, is not intended to ever become an
> IETF document, be dropped.
> 
> Section 1.7 still refers to an XML Overview section 11.
> 
> Page spanning figures, like Figure 3, are really pretty messy.  It would
> be
> better if the text could be made much more terse and this and similar
> figures started high on a page so they aren't split by a page boundary.
> 
> Section 2.2: suggest "The Open Trading Protocols identify" be changed to
> "IOTP identifies".
> Section 2.2: says "IOTP Transactions are composed of these exchanges" but
> does not list Inquiry or Ping exchange.
> 
> Starting in section 2.3 and many other places in the document, words or
> phrases are prefixed and suffixed by an underscore character ("_").  This
> is not any normal IETF style.  I suspect it means that the original text
> is
> italic.  These should be suppressed or if that is impossible, a separate
> pass should be done to delete them.
> 
> In Figure 9, the things which are supposed to be identical or match aren't
> and don't.  Is that deliberate?
> 
> I don't think that section 3.6 Brands and Brand Selection fits very well
> where it and suggest it be moved into section 10 which could be renamed
> "Brands".
>      Continuing on Brands, I looked around a bit in SET literature and
> couldn't find anything about Dual or Promotional brands or anything about
> a
> three component SET Brand.  Two components, "brand" and "product" I see in
> the SET literature, such a "MasterCard" or "Visa:Gold".  But not A:B:C and
> no case where a colon is included if there isn't anything after it.  In
> other words, it's "Visa", not "Visa:", and certainly not "Visa::" as a SET
> brand (re also examples in 6.6.1). Can anyone give me any references to
> shed light on this?
> 
> Section 3.8.1: I don't understand why sub-pages of an HTML main page
> couldn't have links back to the main page.
> 
> Section 4.1: first section reference says "0"?
> 
> Figures 10 and 11: These flow diagrams each *almost* fit on a page. If the
> initial "Input IOTP Message" box could be to the side with a horizontal
> arrow and the text were edited down to something a bit more terse, I think
> they would, which would be quite helpful.
> 
> Section 5: Suggest this section be called "Digital Signature" or
> something.
> Usually an IETF Security Considerations section is brief and talks about
> really high level issues.  Material in 5.4 is appropriate for Security
> Considerations.  A separate Security Considerations section would need to
> also say something about deciding when to require signatures, even if it
> is
> just by referring to section 5.1.4, and about depending on payment scheme
> security for the safety of funds, which I didn't see anywhere.
>      Section 5 seems pretty heavy on certificates and public key crypto,
> especially given the originally IOTP v1.0 was going to be secret key only
> and, as I recall, it was with some reluctance that public key hooks were
> added.  The stuff on checking a signature, for example, talks about
> checking the certificate as if there always has to be one.
>      Section 5.1.4: another reason you might not need signatures is the
> that the sender and receiver were on the same machine so it can check
> integrity just by comparing with a saved copy.
> 
> Section 6.4.2: Need to eliminate reference to "Open Trading Protocol
> Consortium" and suggest dropping whole note. I don't see any difference at
> all between OkTo/OkFrom and amount.  Both could appear in human readable
> form in the Order Description and in machine readable form in their
> element.  Recommending that the UI display the machine readable version is
> reasonable (as in 6.4.1).
> 
> ContentSoftwareId: the standard text given for this is quite length and
> repeated dozens of time.  If it could be moved to the glossary or
> something
> and a simple "see glossary" put in, it would save many pages.
> 
> As previously discussed, change ISO4217 to ISO4217A or the like.
> 
> Just before section 6.7, it says that examples exist in 6.6 when they are
> in 10.
> 
> Section 6.17: references to the Richard Brown draft and probably not
> appropriate.  RFCs are not supposed to refer to drafts.  About the future,
> I'm not sure you need to say anything but if you do, I think it should
> just
> say the future versions of IOTP will use industry standard XML signature
> technology if it meets IOTP requirements.
>      Shouldn't 6.17.1 refer to the IOTP DSIG document?  It's OK to refer
> to
> that draft because the idea is that it and the main protocol document will
> be issued as RFCs simultaneously.  Maybe the XMLDSIG reference should just
> be changed to refer to the IOTP DSIG document.
>      There is a reference in  6.17.1 to payment scheme specific
> algorithms.
> Wouldn't their use be encapsulated inside the packaged contents and be in
> the payment scheme modules, not an IOTP implementation itself?
>      Section 6.18: similarly for certificate reference.  Should point out
> that certs not needed for symmetric keying or for cases where public key
> has been registered at recipient.
> 
> Section 6.19.2: For ElContIllegal, ValueTooSmall, and ValueTooLarge, I
> believe it should say "content" rather than "PackagedContent".
> 
> 
> 
> TRIVIAL NITS:
> 
> In the Abstract and section 1, Delivery Handler is capitalized but payment
> handler isn't.
> 
> It is not usual to have a section like 1.7, History, in an IETF document.
> If the evolution of a protocol sheds light on its technical content,
> that's
> one thing.  But it is not usual to have what is mostly a list of editing
> versions.  Suggest it be dropped to shorten the document.
> 
> I'm not sure why there is a skip to new page before section 3.1 or 3.1.2.
> Suggest dropping these to make the document more compact.  RFC style is to
> have no skips to the start of a new page anywhere in the body text.
> 
> Section 3.8 example packaged content:  I don't like the "Name"s FirstMsg
> and SecondMsg.  Using Msg => Message seems confusing.  Suggest FirstPiece
> and SecondPiece.
> 
> Section 3.10 says "Where both types of net location are present, the
> following rules apply:" and then gives three rules only the third of which
> applies in the described circumstances.  Suggest moving the first two up
> and combining the quoted phrase with the third.
> 
> Section 3.11.1 "treated by the recipient is an error": is -> as
> 
> Section 4: "There are a several ..." delete "a"
> 
> Section 4.4.1.2: in first sentence has -> have.
> 
> Section 4.4.2.9: in first sentence, insert "server" between "the" and
> "unless".
> 
> Not sure why skip to new page before section 5.3.1 shortly before Figure
> 14
> which overflows onto next page by just one line...
> 
> Section 5.3.1.1: numbered subsections, lettered subsubsections:  The text
> at the ends of these 12 subsubsections is substantially the same.
> Starting
> with 3)b) sometimes the final period is omitted.  Suggest moving this text
> up to the numbered section level or to before the whole two level list.
> 
> Section 5.3.1.2: ditto 5.3.1.1 except list is one level.
> 
> Section 6.1: towards the end, delete "the" from "that the should".
> 
> Section 6.2: Insert "may be" after "there" in "there only one".
> 
> Section 6.5.5: PostalCode missing from detailed attributes list.
> 
> Just before 6.6.3 and 6.7.1: "in10" -> "in section 10".
> 
> Suggest replacing occurrences of "SSL" with "SSL/TLS" and adding the TLS
> RFC to the References.
> 
> Section 6.11:  has "Plain/Text" where other similar sentences use "Plain
> Text" which is probably better.  The "/" makes it look like a MIME type
> and
> the MIME type is actually text/plain.  But I would suggest not using the
> MIME type as there isn't a unique one for HTML.
> 
> Section 6.12.1: DelivReqNetLocn & SecDelivReqNotLocn: "Mechanism must" ->
> "Mechanism and must".
> 
> Section 6.13: Content, should be "PackagedContent" not "Delivery Note".
> 
> 
> 
> REFERENCES (section 14)
> 
> For DOM-HASH, can't refer to any Internet-Drafts by URL or filename.  For
> HMAC, suggest refereing to RFC 2104 HMAC: Keyed-Hashing for Message
> Authentication. H. Krawczyk, M. Bellare, R. Canetti. February 1997.
> 
> It looks pretty odd to the IETF spelled out in the RFC references.  I've
> never seen that in an IETF document references section.
> 
> For SET, suggest referencing the SETco.org site, not Mastercard.  Can't
> reference the Brown XMLDSIG draft in an RFC (although you can talk about
> it
> without a URL or file name reference if necessary).
> 
> 
> 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
> 
> 
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 

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

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

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

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

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

From: [email-masked]
To: [email-masked]
Date: Thu, 22 Apr 1999 18:25:11 -0400
Subject: Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt, part 1
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I've done a careful review of the document through section 6 and section 13
and greater and came up with the following somewhat length list of
suggestions.  I don't think they substantially change the intended meaning
of the document but those on the list should judge that.

IMPORTANT:

"IANA Considerations" needs to be a top level section, perhaps #11.
Gathering this stuff together into 3.7.3 is good but its still unreasonable
to expect IANA to comb the document to find it.
     I'm not sure about the criteria for registration.  "IETF Consensus" is
pretty stiff and requires a vote of the IESG.  I should think someone could
register an IOTP Band or CurrCode by publishing an RFC.  Perhaps that is
what you mean for ProtocolId but it is not clear.
     Toward end so 3.7.3, change "with" to "without".

MISCELLANEOUS:

I don't understand the difference between "Objectives" and "Purpose".  I
suggest that 1.4 and 1.5 be merged and that the reference to "IOTP Business
Description" which, as far as I know, is not intended to ever become an
IETF document, be dropped.

Section 1.7 still refers to an XML Overview section 11.

Page spanning figures, like Figure 3, are really pretty messy.  It would be
better if the text could be made much more terse and this and similar
figures started high on a page so they aren't split by a page boundary.

Section 2.2: suggest "The Open Trading Protocols identify" be changed to
"IOTP identifies".
Section 2.2: says "IOTP Transactions are composed of these exchanges" but
does not list Inquiry or Ping exchange.

Starting in section 2.3 and many other places in the document, words or
phrases are prefixed and suffixed by an underscore character ("_").  This
is not any normal IETF style.  I suspect it means that the original text is
italic.  These should be suppressed or if that is impossible, a separate
pass should be done to delete them.

In Figure 9, the things which are supposed to be identical or match aren't
and don't.  Is that deliberate?

I don't think that section 3.6 Brands and Brand Selection fits very well
where it and suggest it be moved into section 10 which could be renamed
"Brands".
     Continuing on Brands, I looked around a bit in SET literature and
couldn't find anything about Dual or Promotional brands or anything about a
three component SET Brand.  Two components, "brand" and "product" I see in
the SET literature, such a "MasterCard" or "Visa:Gold".  But not A:B:C and
no case where a colon is included if there isn't anything after it.  In
other words, it's "Visa", not "Visa:", and certainly not "Visa::" as a SET
brand (re also examples in 6.6.1). Can anyone give me any references to
shed light on this?

Section 3.8.1: I don't understand why sub-pages of an HTML main page
couldn't have links back to the main page.

Section 4.1: first section reference says "0"?

Figures 10 and 11: These flow diagrams each *almost* fit on a page. If the
initial "Input IOTP Message" box could be to the side with a horizontal
arrow and the text were edited down to something a bit more terse, I think
they would, which would be quite helpful.

Section 5: Suggest this section be called "Digital Signature" or something.
Usually an IETF Security Considerations section is brief and talks about
really high level issues.  Material in 5.4 is appropriate for Security
Considerations.  A separate Security Considerations section would need to
also say something about deciding when to require signatures, even if it is
just by referring to section 5.1.4, and about depending on payment scheme
security for the safety of funds, which I didn't see anywhere.
     Section 5 seems pretty heavy on certificates and public key crypto,
especially given the originally IOTP v1.0 was going to be secret key only
and, as I recall, it was with some reluctance that public key hooks were
added.  The stuff on checking a signature, for example, talks about
checking the certificate as if there always has to be one.
     Section 5.1.4: another reason you might not need signatures is the
that the sender and receiver were on the same machine so it can check
integrity just by comparing with a saved copy.

Section 6.4.2: Need to eliminate reference to "Open Trading Protocol
Consortium" and suggest dropping whole note. I don't see any difference at
all between OkTo/OkFrom and amount.  Both could appear in human readable
form in the Order Description and in machine readable form in their
element.  Recommending that the UI display the machine readable version is
reasonable (as in 6.4.1).

ContentSoftwareId: the standard text given for this is quite length and
repeated dozens of time.  If it could be moved to the glossary or something
and a simple "see glossary" put in, it would save many pages.

As previously discussed, change ISO4217 to ISO4217A or the like.

Just before section 6.7, it says that examples exist in 6.6 when they are
in 10.

Section 6.17: references to the Richard Brown draft and probably not
appropriate.  RFCs are not supposed to refer to drafts.  About the future,
I'm not sure you need to say anything but if you do, I think it should just
say the future versions of IOTP will use industry standard XML signature
technology if it meets IOTP requirements.
     Shouldn't 6.17.1 refer to the IOTP DSIG document?  It's OK to refer to
that draft because the idea is that it and the main protocol document will
be issued as RFCs simultaneously.  Maybe the XMLDSIG reference should just
be changed to refer to the IOTP DSIG document.
     There is a reference in  6.17.1 to payment scheme specific algorithms.
Wouldn't their use be encapsulated inside the packaged contents and be in
the payment scheme modules, not an IOTP implementation itself?
     Section 6.18: similarly for certificate reference.  Should point out
that certs not needed for symmetric keying or for cases where public key
has been registered at recipient.

Section 6.19.2: For ElContIllegal, ValueTooSmall, and ValueTooLarge, I
believe it should say "content" rather than "PackagedContent".

TRIVIAL NITS:

In the Abstract and section 1, Delivery Handler is capitalized but payment
handler isn't.

It is not usual to have a section like 1.7, History, in an IETF document.
If the evolution of a protocol sheds light on its technical content, that's
one thing.  But it is not usual to have what is mostly a list of editing
versions.  Suggest it be dropped to shorten the document.

I'm not sure why there is a skip to new page before section 3.1 or 3.1.2.
Suggest dropping these to make the document more compact.  RFC style is to
have no skips to the start of a new page anywhere in the body text.

Section 3.8 example packaged content:  I don't like the "Name"s FirstMsg
and SecondMsg.  Using Msg => Message seems confusing.  Suggest FirstPiece
and SecondPiece.

Section 3.10 says "Where both types of net location are present, the
following rules apply:" and then gives three rules only the third of which
applies in the described circumstances.  Suggest moving the first two up
and combining the quoted phrase with the third.

Section 3.11.1 "treated by the recipient is an error": is -> as

Section 4: "There are a several ..." delete "a"

Section 4.4.1.2: in first sentence has -> have.

Section 4.4.2.9: in first sentence, insert "server" between "the" and
"unless".

Not sure why skip to new page before section 5.3.1 shortly before Figure 14
which overflows onto next page by just one line...

Section 5.3.1.1: numbered subsections, lettered subsubsections:  The text
at the ends of these 12 subsubsections is substantially the same.  Starting
with 3)b) sometimes the final period is omitted.  Suggest moving this text
up to the numbered section level or to before the whole two level list.

Section 5.3.1.2: ditto 5.3.1.1 except list is one level.

Section 6.1: towards the end, delete "the" from "that the should".

Section 6.2: Insert "may be" after "there" in "there only one".

Section 6.5.5: PostalCode missing from detailed attributes list.

Just before 6.6.3 and 6.7.1: "in10" -> "in section 10".

Suggest replacing occurrences of "SSL" with "SSL/TLS" and adding the TLS
RFC to the References.

Section 6.11:  has "Plain/Text" where other similar sentences use "Plain
Text" which is probably better.  The "/" makes it look like a MIME type and
the MIME type is actually text/plain.  But I would suggest not using the
MIME type as there isn't a unique one for HTML.

Section 6.12.1: DelivReqNetLocn & SecDelivReqNotLocn: "Mechanism must" ->
"Mechanism and must".

Section 6.13: Content, should be "PackagedContent" not "Delivery Note".

REFERENCES (section 14)

For DOM-HASH, can't refer to any Internet-Drafts by URL or filename.  For
HMAC, suggest refereing to RFC 2104 HMAC: Keyed-Hashing for Message
Authentication. H. Krawczyk, M. Bellare, R. Canetti. February 1997.

It looks pretty odd to the IETF spelled out in the RFC references.  I've
never seen that in an IETF document references section.

For SET, suggest referencing the SETco.org site, not Mastercard.  Can't
reference the Brown XMLDSIG draft in an RFC (although you can talk about it
without a URL or file name reference if necessary).

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

-----------------------------------------------------------------------
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, 12 Apr 1999 08:23:52 -0700
To: [email-masked]
From: Steve Schear <[email-masked]>
Subject: RE: "A Riddle at the Register"
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

At 12:40 PM 4/7/99 -0400, Smith, Chris wrote:
>
>In the real world, it's not always true that the merchant is 
>responsible for collecting and remitting sales (consumption) 
>taxes. If there is insufficient evidence of appropriate taxes 
>paid on goods from a foreign jurisdiction, the *recipient* has 
>to pay them in order to release the goods (it's happened to 
>me....). Also, optionally, some merchants can refuse to take 
>part in tax collection, obligating the buyer to pay the tax 
>(cars, for example)(it's happened to me...).

All these complex rules will likely lead to a dichotomy in merchant
approaches in the near term. One group (larger established retailers) will
develop/purchase complex middleware to capture and attempt to process the
spagetti tax codes, many others will capture the data make a gross estimate
of their possible liabilities and penalties and then wait to be contacted,
still others (the more entrapreneurial) will make the leap of faith that
many or most of these taxes will never be collectable and adopt practices
to actively ignore them.

Although many assume that each nation state will have the means to impose
their tax rules on the Internet, or that widespread tax agreements will be
adopted and implemented, Netizen are proving to be broadly resistant to
authority. 

--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: Dave Birch <[email-masked]>,  Don Eastlake <[email-masked]>
Cc: Ietf Trade WG <[email-masked]>
Subject: RE: OECD Tags 
Date: Mon, 12 Apr 1999 16:00:45 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I agree.

I'm working on MXI lawyers to get the standard MXI trailer changed, but
until I can, apologies again. There isn't anything I can do unless I use
anothe email address.

David

> ----------
> From: 	Donald E. Eastlake 3rd[SMTP:[email-masked]]
> Sent: 	12 April 1999 05:47
> To: 	Dave Birch
> Cc: 	Ietf Trade WG
> Subject: 	Re: OECD Tags 
> 
> 
> Nothing volunatrily posted to an IETF workging group mailing list is
> confidential.  This sort of junk notice is something lawyers sometimes
> try to impose even though it is frequently untrue.  I suggest we just
> ignore such things unless there is a clear consensus that it is a
> problem.
> 
> Thanks,
> Donald
> 
> From:  Dave Birch <[email-masked]>
> Date:  Mon, 12 Apr 1999 12:28:11 +0100
> To:  Ietf Trade WG <[email-masked]>
> Content-Type:  text/plain; charset="US-ASCII"
> Message-Id:  <[email-masked]>
> Sender:  [email-masked]
> Precedence:  bulk
> X-elistx:  ietf-trade
> Source-Info:   From (or Sender) name not authenticated.
> >David Burdett said
> >
> >>This Email and any attached files are confidential
> >
> >Confidential to whom?
> >
> >Regards,
> >Dave Birch.
> >
> >...  My own opinion (I think!) given solely in my capacity as  ...
> >...         an interested member of the general public         ...
> >...                                                            ...
> >...  mailto:[email-masked]   .........  http://pobox.com/~dgwb ...
> >
> >-----------------------------------------------------------------------
> >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]
> 

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

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

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

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondex.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: Dave Birch <[email-masked]>
cc: Ietf Trade WG <[email-masked]>
Subject: Re: OECD Tags 
Date: Mon, 12 Apr 1999 08:47:41 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Nothing volunatrily posted to an IETF workging group mailing list is
confidential.  This sort of junk notice is something lawyers sometimes
try to impose even though it is frequently untrue.  I suggest we just
ignore such things unless there is a clear consensus that it is a
problem.

Thanks,
Donald

From:  Dave Birch <[email-masked]>
Date:  Mon, 12 Apr 1999 12:28:11 +0100
To:  Ietf Trade WG <[email-masked]>
Content-Type:  text/plain; charset="US-ASCII"
Message-Id:  <[email-masked]>
Sender:  [email-masked]
Precedence:  bulk
X-elistx:  ietf-trade
Source-Info:   From (or Sender) name not authenticated.
>David Burdett said
>
>>This Email and any attached files are confidential
>
>Confidential to whom?
>
>Regards,
>Dave Birch.
>
>...  My own opinion (I think!) given solely in my capacity as  ...
>...         an interested member of the general public         ...
>...                                                            ...
>...  mailto:[email-masked]   .........  http://pobox.com/~dgwb ...
>
>-----------------------------------------------------------------------
>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]

Subject: Re: OECD Tags
Date: Mon, 12 Apr 1999 12:28:11 +0100
From: Dave Birch <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David Burdett said

>This Email and any attached files are confidential

Confidential to whom?

Regards,
Dave Birch.

...  My own opinion (I think!) given solely in my capacity as  ...
...         an interested member of the general public         ...
...                                                            ...
...  mailto:[email-masked]   .........  http://pobox.com/~dgwb ...

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

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: FW: OECD Tags
Date: Fri, 9 Apr 1999 18:57:17 +0100 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I have received a couple of comments (such as the one below from Mark) about
the "trailer" attached by Mondex International to all outgoing e-mails.

This version of the trailer has recently been added as a result advice by
MXI's legal advisor's and is added automatically by the MXI e-mail server.
This means I cannot turn it off and cannot change it.

Since the IETF Trade WG is an open mailing list, I want to use this email to
put on record that, for any emails I personally send to this list, the
statement "This Email and any attached files are confidential and may also
be privileged" contained in the trailer does not apply.

David Burdett

> ----------
> From: 	[email-masked][SMTP:[email-masked]]
> Sent: 	09 April 1999 03:17
> To: 	[email-masked]
> Subject: 	OECD Tags
> 
> David, your mail to the group list has these words about "confidential and
> may also be privileged".   I assume you don't mean that in the context of
> a
> mailing list, but suggest you should fix your mail trailer....
> 
> Hope things are going well for you.
> 
> --------------------------------
> Mark H. Linehan
> IBM, Mgr. of Internet Emerging Payment Technology
> 
> phone: (914) 784-7860 or IBM tieline 863-7860
> fax: (914) 784-3833 or IBM tieline 863-3833
> internet: [email-masked] or [email-masked]
> Notes: Mark H Linehan/Hawthorne/IBM @ IBMUS
> 
> ---------------------- Forwarded by Mark H Linehan/Hawthorne/IBM on
> 04/09/99 06:15 AM ---------------------------
> 
> 
> David Burdett <[email-masked]> on 04/07/99 06:12:00 PM
> 
> To:   Ietf Trade WG <[email-masked]>
> cc:    (bcc: Mark H Linehan/Hawthorne/IBM)
> Subject:  OECD Tags
> 
> 
> 
> 
> 
> If you want to find out more about the OECD Technology Tags and register
> to
> *receive* the results of email discussions please go to ...
> 
> http://www.oecd.org/daf/fa/e_com/tag.htm
> 
> David
> > mailto:<[email-masked]>
> > Mondex International, US Advanced Technology Office
> > 111 Pine St, 6th Floor, San Francisco, CA 94111
> > Tel/Voicemail: +1 415 645 6973   Fax: +1 415 956 9370
> >
> 
> **************************************************************************
> *
> ***********
> 
> This Email and any attached files are confidential and may also be
> privileged.
> If you are not the intended recipient,  please notify the postmaster using
> email
> address [email-masked] or calling +44 171 557 5000 and ask for the
> IT
> Helpdesk; you should not copy this email and any attached files, use them
> for any
> purpose or disclose the contents to any other person.
> Destroy all copies of the Email and associated files in your possession.
> 
> Mondex International Limited
> 47-53 Cannon Street
> London EC4M 5SQ
> United Kingdom
> Registered No: 3122085, England
> 
> Phone:          +44 171 557 5000
> Fax:            +44 171 557 5200
> Email:          [email-masked]
> WebSite:        http://www.mondex.com
> 
> **************************************************************************
> *
> *************
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 
> 
> 

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

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

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

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

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

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: OECD Tags
Date: Wed, 7 Apr 1999 23:12:00 +0100 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

If you want to find out more about the OECD Technology Tags and register to
*receive* the results of email discussions please go to ...

http://www.oecd.org/daf/fa/e_com/tag.htm

David
> mailto:<[email-masked]>
> Mondex International, US Advanced Technology Office
> 111 Pine St, 6th Floor, San Francisco, CA 94111
> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
> 

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

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

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

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

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

From: "Smith, Chris" <[email-masked]>
To: [email-masked]
Subject: RE: "A Riddle at the Register"
Date: Wed, 7 Apr 1999 12:40:00 -0400 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

In the real world, it's not always true that the merchant is 
responsible for collecting and remitting sales (consumption) 
taxes. If there is insufficient evidence of appropriate taxes 
paid on goods from a foreign jurisdiction, the *recipient* has 
to pay them in order to release the goods (it's happened to 
me....). Also, optionally, some merchants can refuse to take 
part in tax collection, obligating the buyer to pay the tax 
(cars, for example)(it's happened to me...).

As to the exemptions, there are two common approaches.

1) The merchant doesn't support exemptions. The buyer wants 
documentation regarding taxes they did pay so that they can 
claim them back from the tax jurisdiction. Simple and easy for 
the merchant, somewhat cumbersome for customer and tax 
authority.

2) The merchant supports exemptions, but the buyer must provide 
evidence to support their claim to the exemption. In many 
jurisdictions, this takes the form of a 'tax number'. More 
appropriate, and likely a better scenario, but likely requiring 
digital certificates in a virtual commerce scenario.

There is a slightly different take on all of this discussion; if 
we assume little or no change as 'deliverable goods' commerce 
moves from real to virtual, then I still want each merchant to 
clearly indicate the taxes I paid in *their* jurisdiction. I 
still have the responsibility for paying duties and taxes on my 
end, but I want clear documentation to claim back the foreign 
taxes from the foreign jurisdiction. (I am assuming, 
incidentally, that the foreign jurisdiction is insisting that 
all of its merchants treat all sales as local because there is 
no trustworthy mechanism to prove location. This seems a logical 
reaction to a loss of tax base due to the move to virtual.)

This is the standard procedure today - I pay the New York state 
taxes, keep my reciepts, get the New York tax rebate form, and 
then submit the rebate form from Ontario, Canada, showing the 
taxes to be rebated. New York state then cuts me a check for the 
taxes I paid but didn't need to pay.

But keep in mind the whole point of this discussion - does IOTP need to 
be involved in any of the 'rules and calculations', or is it enough to 
simply say 'you have paid $$ in tax'?

On 1999-04-06 22:03, Kaye Caldwell wrote:

> However, what the merchant does need to understand is that if the
> "mechanism" gets the rules wrong the merchant will be financially liable
> for the tax, interest, and penalties. And don't forget the "rules: also
> include exemptions based on who the buyer is. (Govt, reseller,
> non-profit, farmer, etc, etc)  Also the merchant will have to pay the
> "mechanism" supplier to keep the "mechanism" up to date.

> At 07:06 PM 4/6/99 -0400, Chris wrote: 
>
> [...]

>> The merchant just has to have *some* mechanism to get the tax
>> correct. He does not *have* to understand the rules. (That is
>> one way to do it, but it's not clear that it's the best one in
>> a multi-jurisdictional/ multi-tax environment.)
>>
>> More to the point, I don't think that IOTP is going to fill
>> such a role. I think all we clearly need to do is indicate
>> some fundamental aspects of any tax paid:
>>
>> 1) The jurisdiction (which may be a hierarchial description)
>>    "Geographical" "CA" "ON"    Canada.Ontario
>>
>> 2) Which tax within that jurisdiction.
>>    "PST"        Provincal Sales Tax
>>
>> 3) How much is this tax
>>    "0.80" "CAD" An amount and currency
>>
>> 4) An indication as to who has the money now, such as
>>    a nerchant tax number.
>>    "1002383404"
>>
>> 5) Optionally - a note regarding the tax, suitable
>>    for one line display
>>    "Ontario PST - 8%"
>>
>> This can be repeated for any additional taxes. (Airline tickets
>> often provide a really complicated example.)
>> I do not see any requirement that an IOTP message provide all
>> the information needed to allow any party (merchant or
>> consumer) to re-do the detailed tax calculation. There
>> certainly is no such requirement in the real world of commerce.
>> Anyone who wants to redo the tax calculation would normally
>> have to take responsibility for finding and learning the
>> relevant tax rules.
>>
>>...Chris Smith
>>   Royal Bank of Canada
-----------------------------------------------------------------------
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: "Richard D. Brown" <[email-masked]>
To: "'Smith, Chris'" <[email-masked]>,  'Ietf Trade WG' <[email-masked]>,  'David Burdett' <[email-masked]>
Subject: RE: "A Riddle at the Register"
Date: Wed, 7 Apr 1999 11:25:14 -0500
Importance: Normal
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I do not think that IOTP problem is about "how tax is being computed or how
difficult it will be to compute such tax." Supposedly, as the legislators
will define the rules, some technology providers will package adequate
engines to perform such cumbersome calculations.

The real problem is that some tax computation might require pieces of
information beyond the ones directly available to the Seller (i.e
characteristics of the goods being sold and tax juridiction of the Seller).
Among others, tax computation may require the location of the Buyer at time
of purchase, the permanent tax juridiction of the Buyer, the type of the
Buyer (Corporate vs. Consumer), etc... Therefore, the real problem will
consist of providing securely these pieces of information to the Seller.

There are two other aspects that the legislators may want to consider if
electronic commerce transactions were to be taxed. The first one is to
provide an audit trail of the tax collected by the Seller (to make sure they
are properly reversed to the tax agencies). This would be something like
these huge rolls of paper in the cash registers. To this purpose, IOTP and
other trade protocols may have to provide for a tax item in the description
of the Order. The second aspect will be how to provide adequate feedback to
the Buyer so that he can understand why and for what he is being taxed. As a
consumer, I may agree to pay tax (if so defined by law), but I want to make
sure that I have been charged appropriately. I do not want the tax item to
become an equivalent to "shipping and handling" in those cheap TV adds - a
means for the Seller to recoup part of an appealing discount for example.

Sincerely,

Richard D. Brown
Software Architect - R&D
GlobeSet, Inc. Austin TX - U.S.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Smith, Chris
> Sent: Tuesday, April 06, 1999 6:06 PM
> To: Ietf Trade WG; David Burdett
> Subject: RE: "A Riddle at the Register"
>
>
>
> OK, maybe meat and ice cream aren't good examples - but I can see
> bottled water being sold over the Internet. It doesn't go stale, it
> doesn't need to be kept cold, and you might want to order
> special water
> from a remote location.
>
>    The 'break point' is 500 mL. (millilitres)
>
>    The defining characteristic is 'manufacturer packaging'.
>
> So:
>
>    1 x 600 mL bottle is tax free.
>    1 x 300 mL bottle is taxed.
>
>    A prepackaged box of 6 x 300 mL bottles (1800mL) is tax free.
>
>    A 'merchant packed' box of 6 x 300 mL bottles (1800mL) is taxed.
>
>    If the merchant opens the prepackaged box of 6 (tax free) and
>    places the individual bottles in his own box, it is now taxed. (!)
>
>
> Trust me - we don't get out of this issue by claiming it just won't
> happen.
>
> However, I think we can get out of it by simply making clear
> that it is
> not the job of the merchant (and, by extension, IOTP) to
> explain the tax
> rules to the consumer. In fact, only whoever calculates the
> tax needs to
> understand the rules.
>
> The merchant just has to have *some* mechanism to get the tax
> correct.
> He does not *have* to understand the rules. (That is one way
> to do it,
> but it's not clear that it's the best one in a multi-jurisdictional/
> multi-tax environment.)
>
> More to the point, I don't think that IOTP is going to fill
> such a role.
> I think all we clearly need to do is indicate some
> fundamental aspects
> of any tax paid:
>
>
> 1) The jurisdiction (which may be a hierarchial description)
>    "Geographical" "CA" "ON"    Canada.Ontario
>
> 2) Which tax within that jurisdiction.
>    "PST"        Provincal Sales Tax
>
> 3) How much is this tax
>    "0.80" "CAD" An amount and currency
>
> 4) An indication as to who has the money now, such as a
> nerchant tax number.
>    "1002383404"
>
> 5) Optionally - a note regarding the tax, suitable for one
> line display
>    "Ontario PST - 8%"
>
> This can be repeated for any additional taxes. (Airline tickets often
> provide a
> really complicated example.)
>
> I do not see any requirement that an IOTP message provide all the
> information
> needed to allow any party (merchant or consumer) to re-do the
> detailed tax
> calculation. There certainly is no such requirement in the
> real world of
> commerce. Anyone who wants to redo the tax calculation would
> normally have
> to
> take responsibility for finding and learning the relevant tax rules.
>
> ...Chris Smith
>    Royal Bank of Canada
>
>
> ______________________________ Reply Separator
> _________________________________
> Subject: RE: "A Riddle at the Register"
> Author:  "David Burdett" [SMTP:[email-masked]] at Internet
> Date:    1999-04-06 13:57
>
>
> Mark provides some interesting examples of bizarre tax rules
> that currently
> exist. But if you look at them closely, I can't honestly seem
> many of the
> products Mark suggests being sold over the Internet to out of state
> customers, for example:
> *     heated frozen food would be inedible and unsafe to eat
> *     a cold meat sandwich would be stale
> *     the ice cream cone would have melted
>
> To do physical delivery takes time which will help remove
> from the equation
> a whole variety of food related products from Internet commerce.
>
> However I agree with Mark that collecing "out of state" (or
> even "out of
> country" !! ) tax is not a simple thing to do and will
> require effective
> ways of communicating the necessary "tax rules" from those
> that set them to
> those that need to apply them - perhaps the Internet could be
> used for this.
>
> I also think that a simplification of the rules themselves
> will probably be
> required ... and that will take a lot of talking ...
>
> David
> --------------------------------------------------------------
> ---------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or
> "unsubscribe" in the
> body to: [email-masked]
>

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

From: "Smith, Chris" <[email-masked]>
To: Ietf Trade WG <[email-masked]>,  David Burdett <[email-masked]>
Subject: RE: "A Riddle at the Register"
Date: Tue, 6 Apr 1999 19:06:00 -0400 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

OK, maybe meat and ice cream aren't good examples - but I can see 
bottled water being sold over the Internet. It doesn't go stale, it 
doesn't need to be kept cold, and you might want to order special water 
from a remote location.

   The 'break point' is 500 mL. (millilitres)

   The defining characteristic is 'manufacturer packaging'.

So:

   1 x 600 mL bottle is tax free.
   1 x 300 mL bottle is taxed.

   A prepackaged box of 6 x 300 mL bottles (1800mL) is tax free.

   A 'merchant packed' box of 6 x 300 mL bottles (1800mL) is taxed.

   If the merchant opens the prepackaged box of 6 (tax free) and
   places the individual bottles in his own box, it is now taxed. (!)

Trust me - we don't get out of this issue by claiming it just won't 
happen.
 
However, I think we can get out of it by simply making clear that it is 
not the job of the merchant (and, by extension, IOTP) to explain the tax 
rules to the consumer. In fact, only whoever calculates the tax needs to 
understand the rules. 

The merchant just has to have *some* mechanism to get the tax correct. 
He does not *have* to understand the rules. (That is one way to do it, 
but it's not clear that it's the best one in a multi-jurisdictional/ 
multi-tax environment.)

More to the point, I don't think that IOTP is going to fill such a role. 
I think all we clearly need to do is indicate some fundamental aspects 
of any tax paid:

1) The jurisdiction (which may be a hierarchial description)
   "Geographical" "CA" "ON"    Canada.Ontario

2) Which tax within that jurisdiction.
   "PST"        Provincal Sales Tax

3) How much is this tax
   "0.80" "CAD" An amount and currency

4) An indication as to who has the money now, such as a nerchant tax number.
   "1002383404"

5) Optionally - a note regarding the tax, suitable for one line display
   "Ontario PST - 8%"

This can be repeated for any additional taxes. (Airline tickets often
provide a 
really complicated example.)

I do not see any requirement that an IOTP message provide all the
information 
needed to allow any party (merchant or consumer) to re-do the detailed tax 
calculation. There certainly is no such requirement in the real world of 
commerce. Anyone who wants to redo the tax calculation would normally have
to 
take responsibility for finding and learning the relevant tax rules.

...Chris Smith
   Royal Bank of Canada

______________________________ Reply Separator
_________________________________
Subject: RE: "A Riddle at the Register"
Author:  "David Burdett" [SMTP:[email-masked]] at Internet
Date:    1999-04-06 13:57

Mark provides some interesting examples of bizarre tax rules that currently 
exist. But if you look at them closely, I can't honestly seem many of the 
products Mark suggests being sold over the Internet to out of state 
customers, for example:
*     heated frozen food would be inedible and unsafe to eat 
*     a cold meat sandwich would be stale
*     the ice cream cone would have melted

To do physical delivery takes time which will help remove from the equation 
a whole variety of food related products from Internet commerce.

However I agree with Mark that collecing "out of state" (or even "out of 
country" !! ) tax is not a simple thing to do and will require effective 
ways of communicating the necessary "tax rules" from those that set them to 
those that need to apply them - perhaps the Internet could be used for this.

I also think that a simplification of the rules themselves will probably be 
required ... and that will take a lot of talking ...

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

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: Tax rules and authorities
Date: Wed, 7 Apr 1999 01:58:37 +0100 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I'm under no illusion as to the wide variety of existing tax rules and
regulations. However, put simply, what they all seem to boil down to is:
*	where's the buyer
*	where's the seller
*	what's being sold

We haven't really talked about "what's being sold" much but this also causes
a whole set of problems to be solved since, for example:
*	a ladies handbag might be categorized in France as a luxury good if
it costs more than ~$150 or the equivalent in French Francs and result in a
higher tax rate than if it costs less. So a US merchant would have to know
which exchange rate to use to work out the tax to apply
*	in some countries, the tax rate to apply depends on the
categorization of the goods, for example, childrens clothes in the UK incur
no tax but clothes designed for adults do. So a Canadian merchant would have
to potentially categorize the clothes they sell depending on the UK or some
other foreign tax authorities categorization of those goods ... and each
country might have different rules ...

I am sure that we can keep on finding more and more examples of how hard it
is to work out the tax rules which apply which I don't think is particularly
useful, so I want to make a few points:
*	the OECD Department of Fiscal Affairs IS aware of the types of
problems such as the ones I've described above and the others that have been
discussed on this list
*	the problem is not new, there are existing customs and excise rules
that have to be used to calculate the tax to apply when importing goods
*	there are several "Technical Advisory Groups" which have been set up
as part of this OECD initiative to address just the types of problems that
have been discussed
*	we, the members of  the Trade WG are not in a position to set
taxation rules either locally, nationally or internationally.

BUT ...

*If*, the OECD work results in a workable rules and procedures for
calculating tax on net purchases, then:
*	there will be benefits for everyone, if there is an effective way of
recording the taxes that are calculated as a result of applying those rules
... whatever they might be
*	IOTP has the potential to be the vehicle for recording in a standard
way, the taxes applied

Let's see what the OECD tags produce.

David
> Mondex International Limited
> mailto:<[email-masked]>
> US Advanced Technology Office: 111 Pine St, 6th Floor, San Francisco, CA
> 94111
> Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
> 

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

This email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient,  please notify the postmaster using email 
address [email-masked] or calling +44 171 557 5000 and asking for the IT 
Helpdesk; you should not copy this email and any attached files, use them for any 
purpose or disclose the contents to any other person.

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

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

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

From: "Milton M. Anderson" <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: Re: "A Riddle at the Register"
Date: Tue, 6 Apr 1999 17:01:02 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Just out of curiosity, does anyone know whether the
purchase of a DIVX movie at the store followed by the
purchase of several subsequent performances is taxed
differently than the purchase of a DVD?

I can see some enterprising lawmakers writing tax laws that
say downloading and playing an MP3 in real time is a 
performance which is taxed differently than downloading 
and storing the MP3 on your hard drive as a purchase
of music.  Sort of like "are you eating it here or taking
it out".   And what happens if you don't download it to 
your own location, but to a server in another state?

Milt

-----Original Message-----
From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Date: Tuesday, April 06, 1999 2:06 PM
Subject: RE: "A Riddle at the Register"

>Mark provides some interesting examples of bizarre tax rules that currently
>exist. But if you look at them closely, I can't honestly seem many of the
>products Mark suggests being sold over the Internet to out of state
>customers, for example:
>* heated frozen food would be inedible and unsafe to eat
>* a cold meat sandwich would be stale
>* the ice cream cone would have melted
>
>To do physical delivery takes time which will help remove from the equation
>a whole variety of food related products from Internet commerce.
>
>However I agree with Mark that collecing "out of state" (or even "out of
>country" !! ) tax is not a simple thing to do and will require effective
>ways of communicating the necessary "tax rules" from those that set them to
>those that need to apply them - perhaps the Internet could be used for this.
>I also think that a simplification of the rules themselves will probably be
>required ... and that will take a lot of talking ...
>
>David
>

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

From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: RE: "A Riddle at the Register"
Date: Tue, 6 Apr 1999 18:57:17 +0100 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Mark provides some interesting examples of bizarre tax rules that currently
exist. But if you look at them closely, I can't honestly seem many of the
products Mark suggests being sold over the Internet to out of state
customers, for example:
*	heated frozen food would be inedible and unsafe to eat
*	a cold meat sandwich would be stale
*	the ice cream cone would have melted

To do physical delivery takes time which will help remove from the equation
a whole variety of food related products from Internet commerce.

However I agree with Mark that collecing "out of state" (or even "out of
country" !! ) tax is not a simple thing to do and will require effective
ways of communicating the necessary "tax rules" from those that set them to
those that need to apply them - perhaps the Internet could be used for this.
I also think that a simplification of the rules themselves will probably be
required ... and that will take a lot of talking ...

David

> ----------
> From: 	[email-masked][SMTP:[email-masked]]
> Sent: 	06 April 1999 03:12
> To: 	[email-masked]
> Subject: 	"A Riddle at the Register"
> 
> The subject line of this email is the title of a recent article in the NY
> Times about the difficulties local food merchants have with the NY state
> sales tax rules.  The underlying rule is that most products have sales tax
> applied at the point of purchase, but most food (and medicine) are
> excepted.  However, there are many special rules:
> 
> * Frozen food is not taxed, but the same food is taxed if heated and
> served
> on a plate, ready-to-eat.
> 
> * For many years, regular size marshmellows were taxed as candy, but
> miniature marshmellows were not taxed because they were considered recipe
> ingredients.  (This one was finally changed after many years of
> complaints.)
> 
> * Cold cuts (i.e. sliced ham & other preserved meats) are tax-free when
> sold in bulk, but are taxed when served on a plate, or in a sandwich.
> 
> * Ice cream sold in bulk is not taxed, but the same ice cream is taxed
> when
> served as an individual portion in an ice cream cone.
> 
> The point of the article is that merchants have real difficulty applying
> these tax rules properly - particularly the smaller merchants.  Smart cash
> registers help a lot by applying the right regulations to items that are
> identified by reading bar codes, but the rules change from time-to-time.
> 
> My own point is that it seems clear that an Internet tax regime that
> expects non-NY merchants to apply NY's sales tax rules is doomed to
> failure.
> 
> --------------------------------
> Mark H. Linehan
> IBM, Mgr. of Internet Emerging Payment Technology
> 
> phone: (914) 784-7860 or IBM tieline 863-7860
> fax: (914) 784-3833 or IBM tieline 863-3833
> internet: [email-masked] or [email-masked]
> Notes: Mark H Linehan/Hawthorne/IBM @ IBMUS
> 
> 
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 

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

This email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient,  please notify the postmaster using email 
address [email-masked] or calling +44 171 557 5000 and asking for the IT 
Helpdesk; you should not copy this email and any attached files, use them for any 
purpose or disclose the contents to any other person.

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

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

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

Date: Tue, 06 Apr 1999 09:40:34 -0700
Subject: Re: "A Riddle at the Register"
From: Aram Perez <[email-masked]>
To: [email-masked], [email-masked]
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Along the same line, several times at certain ice cream parlor(s) here in 
California I've been asked if I was buying ice cream "for here or to go".
After the second time of being asked, I asked why it mattered. It turns out
that if you buy ice cream "for here", i.e. you want to eat it inside the
store, you get taxed. However, if you buy the ice cream "to go", you will
not get taxed.

Go figure,
Aram Perez

> The subject line of this email is the title of a recent article in the NY
> Times about the difficulties local food merchants have with the NY state
> sales tax rules.  The underlying rule is that most products have sales tax
> applied at the point of purchase, but most food (and medicine) are
> excepted.  However, there are many special rules:
>
> * Frozen food is not taxed, but the same food is taxed if heated and served
> on a plate, ready-to-eat.
>
> * For many years, regular size marshmellows were taxed as candy, but
> miniature marshmellows were not taxed because they were considered recipe
> ingredients.  (This one was finally changed after many years of
> complaints.)
>
> * Cold cuts (i.e. sliced ham & other preserved meats) are tax-free when
> sold in bulk, but are taxed when served on a plate, or in a sandwich.
>
> * Ice cream sold in bulk is not taxed, but the same ice cream is taxed when
> served as an individual portion in an ice cream cone.
>
> The point of the article is that merchants have real difficulty applying
> these tax rules properly - particularly the smaller merchants.  Smart cash
> registers help a lot by applying the right regulations to items that are
> identified by reading bar codes, but the rules change from time-to-time.
>
> My own point is that it seems clear that an Internet tax regime that
> expects non-NY merchants to apply NY's sales tax rules is doomed to
> failure.
>
> --------------------------------
> Mark H. Linehan
> IBM, Mgr. of Internet Emerging Payment Technology
>
> phone: (914) 784-7860 or IBM tieline 863-7860
> fax: (914) 784-3833 or IBM tieline 863-3833
> internet: [email-masked] or [email-masked]
> Notes: Mark H Linehan/Hawthorne/IBM @ IBMUS
>
>
> -----------------------------------------------------------------------
> 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: [email-masked]
To: [email-masked]
Date: Tue, 6 Apr 1999 06:12:34 -0400
Subject: "A Riddle at the Register"
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

The subject line of this email is the title of a recent article in the NY
Times about the difficulties local food merchants have with the NY state
sales tax rules.  The underlying rule is that most products have sales tax
applied at the point of purchase, but most food (and medicine) are
excepted.  However, there are many special rules:

* Frozen food is not taxed, but the same food is taxed if heated and served
on a plate, ready-to-eat.

* For many years, regular size marshmellows were taxed as candy, but
miniature marshmellows were not taxed because they were considered recipe
ingredients.  (This one was finally changed after many years of
complaints.)

* Cold cuts (i.e. sliced ham & other preserved meats) are tax-free when
sold in bulk, but are taxed when served on a plate, or in a sandwich.

* Ice cream sold in bulk is not taxed, but the same ice cream is taxed when
served as an individual portion in an ice cream cone.

The point of the article is that merchants have real difficulty applying
these tax rules properly - particularly the smaller merchants.  Smart cash
registers help a lot by applying the right regulations to items that are
identified by reading bar codes, but the rules change from time-to-time.

My own point is that it seems clear that an Internet tax regime that
expects non-NY merchants to apply NY's sales tax rules is doomed to
failure.

--------------------------------
Mark H. Linehan
IBM, Mgr. of Internet Emerging Payment Technology

phone: (914) 784-7860 or IBM tieline 863-7860
fax: (914) 784-3833 or IBM tieline 863-3833
internet: [email-masked] or [email-masked]
Notes: Mark H Linehan/Hawthorne/IBM @ IBMUS

-----------------------------------------------------------------------
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: Comments of IOTP DSIG.
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Tue, 06 Apr 1999 11:26:04 +0900 (JST)
Lines: 59
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Kent,
>>>>> Thu, 01 Apr 1999 14:41:07 -0800,
 	"Kent M. Davidson" <[email-masked]> said:
 
 > >(b) 4.3.5 I do not understand why the Attributes element is needed.
 > >I think that this is because there is no attribute in Attributes.  
 > >
 > >I suggest to remove the followings,
 > >
 > >Current:
 > >   <!ELEMENT Manifest
 > >           (       Algorithm+,
 > >                   Digest+,
 > >                   Attributes?,
 > >                   OriginatorInfo,
 > >                   RecipientInfo+,
 > >           )
 > >
 > >
 > >My New Suggestion:
 > >   <!ELEMENT Manifest
 > >           (       Algorithm+,
 > >                   Digest+,
 > >                   Attribute*,
 > >                   OriginatorInfo,
 > >                   RecipientInfo+,
 > >           )
 > 
 > This is merely a matter of style, and really doesn't make any functional difference except you can reference all Attributes via a single node. Unless other people think it's a good idea to remove it, I'd rather leave it in.
 
Yes, this is just a matter of style, but this would be considered important.
you write about the objective for your draft Chapter 2 as following:
"-- Provide lightweight signatures with minimal redundancy"
It seems to me that this part of your draft might contradict this objective.
What do other people think?
 
 > >(c) The XML reference is only the backward reference, such that one
 > >pass procedure, in order to lighten the signature process.
 > >
 > >Therefore I suggest the following replacement.
 > >
 > > (1) To exchange the order between Signature Component and Certificate
 > >     Component.
 > >
 > > (2) To exchange the order between Manifest Element and Value Element.
 > 
 > Ordering in XML is arbitrary and does not need to be enforced. You
 > may order the elements in your XML document in whatever order you
 > wish. No need to change the document.
 
I would rather take different perspective. We have to obey the DTD
definition different from the specification. For example, if we use
the internal DTD in the IOTP wallet, this might occur the DTD error.

Regards,
----
Yoshiaki Kawatsura : E-mail [email-masked]
 Business & Information Systems Development Devision, 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, 01 Apr 1999 14:41:07 -0800
To: [email-masked]
From: "Kent M. Davidson" <[email-masked]>
Subject: Re: Comments of IOTP DSIG.
Cc: [email-masked]
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

At 03:30 PM 3/30/99 +0900, Yoshiaki KAWATSURA wrote:
>I have some comments for IOTP DSIG.
>
>(a) 3.2 Digest Element
>There is no DTD definition of Resource Element.
>We should add the definition of DTD.

Sorry, this was an oversight. I will remove the extraneous Resource references in the document.

>(b) 4.3.5 I do not understand why the Attributes element is needed.
>I think that this is because there is no attribute in Attributes.  
>
>I suggest to remove the followings,
>
>Current:
>   <!ELEMENT Manifest
>           (       Algorithm+,
>                   Digest+,
>                   Attributes?,
>                   OriginatorInfo,
>                   RecipientInfo+,
>           )
>
>
>My New Suggestion:
>   <!ELEMENT Manifest
>           (       Algorithm+,
>                   Digest+,
>                   Attribute*,
>                   OriginatorInfo,
>                   RecipientInfo+,
>           )

This is merely a matter of style, and really doesn't make any functional difference except you can reference all Attributes via a single node. Unless other people think it's a good idea to remove it, I'd rather leave it in.

>(c) The XML reference is only the backward reference, such that one
>pass procedure, in order to lighten the signature process.
>
>Therefore I suggest the following replacement.
>
> (1) To exchange the order between Signature Component and Certificate
>     Component.
>
> (2) To exchange the order between Manifest Element and Value Element.

Ordering in XML is arbitrary and does not need to be enforced. You may order the elements in your XML document in whatever order you wish. No need to change the document.

>(d) I just wonder who and how will the ANY data define in 4.3.7, 4.3.8
>and 4.3.9?  Additionally, who and how will the type data define in
>4.4.1?  We should define the above data for the reason of
>interoperability.  And I suggest that these data(include chapter 5)
>should be defined in the separate document.

Anyone may define the ANY data definition. It is intended for anyone to put information they deem necessary into the element. An acceptible implementation can only view the attributes defined by the standard, and ignore any other internal elements.

I will ditto what Don said about the other elements:

>For 4.3.9, what type of parameter is appropriate is defined by the
>Algorithm.
>
>For 4.3.7 and 4.3.8, the signer and verifier can agree on what they
>want to put there.  In v1.0, they are assumed to have prior
>acquaintenace and can agree on this.
>
>On 4.4.1, I guess at least one value should be put in the Supported
>Algorithms section, like it says...

Thanks!

-Kent.

>(e) 5 Supported Algorithm
>The current draft specifies the supported algorithms as follows,
>"The IOTP specification 1.0 requires the implementation of the DOM-HASH,
>SHA1,MD5,DSA and HMAC algorithms to provide a compliant implementation 
>of IOTP 1.0. Implementation of RSA is also recommended."
>I think this is very restricted because the REQUIRE is used as the same
>mean of MANDATORY in the RFC2026, so I suggest "requires the
>implementaton of" should be replaced by "should implement."
>
>Regards,
>----
>Yoshiaki Kawatsura : E-mail [email-masked]
> Business & Information Systems Development Devision, Hitachi,Ltd.
>Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721

_____________________________________________________________
Kent M. Davidson
VP Engineering
Differential, Inc.
http://www.differential.com
main (650)426-1100
fax  (650)426-1101

-----------------------------------------------------------------------
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: Zahid Ahmed <[email-masked]>
cc: [email-masked]
Subject: Re: IP addresses & Taxes & Directories? 
Date: Thu, 01 Apr 1999 12:11:02 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This continues to have relatively little to do with any specifics
before the working group...

From:  Zahid Ahmed <[email-masked]>
Message-ID:  <[email-masked]>
To:  "Donald E. Eastlake 3rd" <[email-masked]>, [email-masked]
Date:  Tue, 23 Mar 1999 20:28:44 -0800

>I guess this discussion has gone from tax processing information
>that needs to be transmitted by the client to IP address resolution
>on the receiver side...
>
>Donald brought up the subject of secure DNSs so that when an
>OTP-aware server receives a request we can have some assurance that
>the request was coming from Proxy/Firewall/NAT location whose
>domain address is indeed "ibm.com" and not abc.com.
>
>To summarize, following informaion is minimally needed:
>
>1) Domain Information
>   High degree of assurance the network source of the request;

Why is this needed?  Do you believe tax authorities are going to
define tax obligations in terms of domain name?  I can't see, given
the nature of DNS, how that could be resonable.  Say you decided to
give some tax status to someone because of the apparent geographic
implications of their domain name.  First of all, there is no
guarantee it is correct.  For example, the host asylum.sf.ca.us, which
looks from its name like a machine in San Francisco, California, and
which it was at one time, has for many years been in Cambridge,
Massachusetts.  Even if you enforced a requirement where all city
level US registrars would only give out names to those who reside in
their city, there is no reasonable way to stop subdelegations.  Even
if asylum.sf.ca.us were in SanFrancisco, that says nothing about
example.asylum.sf.ca.us, which could be created by asylum, or
subexample.example.asylum.sf.ca.us which could be created by asylum or
by the example.asylum if it is delegated.

>2) Location Information
>   The geographical origin of the requestor immediate orgainziation; 
>   this is possibly available in the locality attribute of X.509 
>   certificate. However, what if the client uses the cert from a 
>   directory server from another state/country?
>
>3) Principal Information
>   need to know the identity of the requestor (as an individual,
>   possibly an (registered) organization - i.e., a group, or a
>   some other global/certified end entity Id);
>
>Now I know work is going on to specify secure DNS frameworks so
>that we can trust lookup results from DNSs. However, what about 

Note that all it does is make sure you can trust that the contents of
DNS are what those with authority over that part of the DNS have set
up, not that it is true or useful.  That is, that data you get from
the root zone ".", including who has authority over its subzones like
.com, is what those with authority over the generally accepted root
want; that the data you get from .com, including who has authority
over its subzones like example.com, is what those with delegated
authority over .com want; that the data you get from example.com,
including, say, the IP address to use for www.example.com, is what
those with delegated authority over example.com want; etc.

>geographical information and orgainzational information? Is that
>going to be available in secure DNS any time soon? From the

Secure DNS can secure any information that the DNS can store.  It
doesn't add to that, except that it adds security related stuff
(signatures, keys, etc.).  There is an LOC RR that can encode location
but it is not widely used (see RFC 1876, "A Means for Expressing
Location Information in the Domain Name System",
<http://www.ietf.org/rfc/rfc1876.txt>).

>RFC 2538 I have seen focus on AltSubjectName which can be used to 
>include DNS info. Don't know how you'll use that information alone 
>to find out about geographical origin of the request and more 
>specifically, the "Tax Domain" of the request.

RFC 2538 is just about how to store certificates in the DNS.
Certificates are signed entities and are normally verfied based on the
signature in the certificate.  You can store all kinds of info inside
certificates and if you trust the issuer of the certificate, maybe you
can trust that info.

>However, I think we need to consider simpler solutions:
>1) LDAP Directory Servers accessible over the extranet/internet
>   s.t. they store domain information which can be inquired over the 
>   internet once the request is received. SubjAltName would be
>   ideal for directories.
>
>2) Configure Proxy Servers and Firewalls to transparently 
>   attach common, static, organizational and geographical information 
>   about the client as part of the client cert:
>	- geographical location of the request sender;
>	- organization's Id (this need to reflect the global enterprise
>        ID, including any divisional info, e.g., IBM Global Services)

In my opinion, changing all the proxy servers and firewall in the world
is impractical.

>OTP is about payment protocols, but to solve this problem (the identity
>of the user, the orgins of the user, etc.) we also need an easily 
>deployable and cheap infrastructure...

IOTP is about trading.  Most any payment protocol can be tunneled
through IOTP.  The paymnet protocols generally provide their own
security.  The merchant mostly cares about getting paid.  They don't
don't generally need the identity of the customer.  And even if their
were a global tax inftrastrucutre, it is not clear that they need more
than the minimum information to figure out what tax rate to apply.

>Zahid Ahmed                     Commerce One, Inc.
>Commerce Security Architect
>email: [email-masked]
>v: (650)-623-2814
>fax: (650)-938-8055

Thanks,
Donald

>> -----Original Message-----
>> From: Donald E. Eastlake 3rd [mailto:[email-masked]]
>> Sent: Tuesday, March 23, 1999 7:09 PM
>> To: [email-masked]
>> Subject: IP addresses (was Re OECD technical advisory group on
>> e-commerce and professional data assessment)
>> 
>> This doesn't have much to do with the IOTP protocol but I suppose it
>> might somehow effect future versions...\
>> 
>>  > Date:    Sat, 28 Feb 1998 07:30:33 MST
>>  > From:    John Messing <[email-masked]>
>>  > Subject: Re: Re OECD technical advisory group on 
>> e-commerce and professional da
>>  >      ***ta assessmen
>>  > 
>>  > One of the pieces of data that a browser transmits to an 
>> inquiring server is
>>  > the static or dynamic IP address that it is currently 
>> using. A static IP
>>  > address is one that does not change. A dynamic IP address 
>> is provided on a
>>  > rotational basis by an ISP and usually changes with each 
>> connection. Most
>>  > consumers probably use ISP's and dynamic IP addresses.
>> 
>> Well, it is not particularly that a browser explicitly transits an IP
>> address when it does a query.  It is that the TCP connection process
>> that underlies any HTTP, FTP, SMTP/POP/IMAP (email), etc., transfer
>> necessarily involves each end learning the IP address of the other
>> end.  But, in all cases you may be getting the IP address of some
>> intermediate NAT (network address translation) box and/or firewall
>> and/or proxy/cache.
>> 
>>  > This address can be captured by the server and stored. The 
>> dyamic addresses,
>>  > for consumers, usually are modem of an ISP. The ISP's 
>> jurisdiction will not
>>  > necessarily be that of the user, but in most cases, it 
>> probably is. That
>>  > might be a place to begin for determining place of origin.
>> 
>> In fact, the address is almost always captured and written to a log
>> file, although the web server usually tries to translate the numeric
>> IP address into a domain name first.
>> 
>>  > The problem of using the P3 id no. is
>>  > 1. not everyone will have an Intel chip of that generation, and
>>  > 2. it will probably cause a ruckus among privacy groups to 
>> suggest it.
>> 
>> The IP address, while not particularly valuable, is certainly more
>> likely to be authentic than an id number that simply purports to be
>> a Pentium 3 serial number.  It seem to me a lot easier to fake that
>> than the IP addres.
>> 
>> 
>>  > Date:    Sun, 21 Mar 1999 13:16:48 EST
>>  > From:    "Milton M. Anderson" <[email-masked]>
>>  > Subject: Re: Re OECD technical advisory group on 
>> e-commerce and professional da
>>  >      ***ta assessmen
>>  > 
>>  > Do IP addresses map to tax authority boundaries?
>> 
>> Not particularly.  Big blocks of IP address are frequently allocated
>> to specific registries or ISPs or companies but its common for
>> someone with a big block to sub-allocate them to activites in a wide
>> variety of locations.
>> 
>>  > How hard is it to install a hacker tool that will
>>  > spoof the PIII serial number?
>> 
>> From all I know, I think it would be pretty easy.
>> 
>>  > Milt
>> 
>> 
>>  > Date:    Sat, 28 Feb 1998 15:59:15 MST
>>  > From:    John Messing <[email-masked]>
>>  > Subject: Re: Re OECD technical advisory group on 
>> e-commerce and professional da
>>  >      ***ta assessmen
>>  > 
>>  > I disagree that this thread is ridiculous. If the various 
>> participating
>>  > countries are willing to agree that the IP address of the 
>> ISP is the point
>>  > of sale because that is where the buyer logs on to the 
>> Internet, then it
>>  > might be a basis for a taxation convention between 
>> agreeing countries. The
>>  > ISP's all have corporate addresses in some jurisdiction or 
>> other. One need
>>  > only to consult internic to find out the jurisdiction 
>> where they are
>>  > located. If the seller is located in another jurisdiction 
>> from the buyer as
>>  > defined above, then intra country taxation issues can be 
>> negotiated and
>>  > presumably resolved.
>> 
>> Well, if you want to look up a numeric IP address, you need to ask
>> the regional IP registries, ARIN, RIPE, and/or APNIC, not the
>> Internic.  If you can back translate the IP addresses to domain
>> names and they are in a top level domain that the Internic handles
>> (.com, .net, .org, .edu), you can inquire there.  I don't know how
>> good the IP registry's records are but the Internic's have
>> essentially no quality control. As far as I can see, NSI will store
>> essentially any garbage you want in its records.  I suspect data
>> quality in the national domain name registries (.us, .ca, .uk, .jp,
>> etc.) varies a lot from country to country.
>> 
>> I would also note, that if you control an IP address, you can
>> generally put whatever domain name you want in its inverse lookup
>> location.  So if I control 10.123.61.30, I would normally also control
>> the data stored under 30.61.123.10.in-addr.arpa and could, for
>> exmaple, store a pointer to "whitehouse.gov" or "microsoft.com" or
>> "no.such.domain.name" there. However, you can get some assurance by,
>> after doing the inverse lookup, then doing the forward lookup and
>> seeing if you get back to the same numeric IP address you started out
>> with.  And all this will be improved when domain name system security
>> is deployued.  (Note: Network 10 is reserved for local use so IP
>> addresses starting with "10.", which I used in this example, are not
>> globally meaningful or unique and such networks have to be connected
>> to the global Internet through a NAT box to translate to a globally
>> unique address for routing.)
>> 
>> 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]

rom [email-masked]  Thu Apr  1 13:22:16 1999
From: David Burdett <[email-masked]>
To: [email-masked]
Subject: RE: IP addresses & Taxes & Directories? 
Date: Thu, 1 Apr 1999 18:58:56 +0100 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

The conclusion I'm drawing from this particular part of the thread is:
1. There will almost certainly be a need to somehow securely identify the
"tax location" (for want of a better phrase) of the parties involved so that
the correct taxes can be calculated.
2. Knowing how the "tax location" is defined *may* have some relevance on
IOTP since we will probably want to record it within the IOTP messages
somehow
3. Basing "tax location" on DNS, IP addresses or some other feature of
Internet topology does not look like a good idea.
4. We should let the tax experts work out what rules should apply for
determining "tax location" and calculating the apropriate tax to collect,
check that the approach is viable, and then work out how to best record it
in IOTP.

David

> ----------
> From: 	Donald E. Eastlake 3rd[SMTP:[email-masked]]
> Sent: 	01 April 1999 09:11
> To: 	Zahid Ahmed
> Cc: 	[email-masked]
> Subject: 	Re: IP addresses & Taxes & Directories? 
> 
> 
> This continues to have relatively little to do with any specifics
> before the working group...
> 
> From:  Zahid Ahmed <[email-masked]>
> Message-ID:
> <[email-masked]>
> To:  "Donald E. Eastlake 3rd" <[email-masked]>,
> [email-masked]
> Date:  Tue, 23 Mar 1999 20:28:44 -0800
> 
> >I guess this discussion has gone from tax processing information
> >that needs to be transmitted by the client to IP address resolution
> >on the receiver side...
> >
> >Donald brought up the subject of secure DNSs so that when an
> >OTP-aware server receives a request we can have some assurance that
> >the request was coming from Proxy/Firewall/NAT location whose
> >domain address is indeed "ibm.com" and not abc.com.
> >
> >To summarize, following informaion is minimally needed:
> >
> >1) Domain Information
> >   High degree of assurance the network source of the request;
> 
> Why is this needed?  Do you believe tax authorities are going to
> define tax obligations in terms of domain name?  I can't see, given
> the nature of DNS, how that could be resonable.  Say you decided to
> give some tax status to someone because of the apparent geographic
> implications of their domain name.  First of all, there is no
> guarantee it is correct.  For example, the host asylum.sf.ca.us, which
> looks from its name like a machine in San Francisco, California, and
> which it was at one time, has for many years been in Cambridge,
> Massachusetts.  Even if you enforced a requirement where all city
> level US registrars would only give out names to those who reside in
> their city, there is no reasonable way to stop subdelegations.  Even
> if asylum.sf.ca.us were in SanFrancisco, that says nothing about
> example.asylum.sf.ca.us, which could be created by asylum, or
> subexample.example.asylum.sf.ca.us which could be created by asylum or
> by the example.asylum if it is delegated.
> 
> >2) Location Information
> >   The geographical origin of the requestor immediate orgainziation; 
> >   this is possibly available in the locality attribute of X.509 
> >   certificate. However, what if the client uses the cert from a 
> >   directory server from another state/country?
> >
> >3) Principal Information
> >   need to know the identity of the requestor (as an individual,
> >   possibly an (registered) organization - i.e., a group, or a
> >   some other global/certified end entity Id);
> >
> >Now I know work is going on to specify secure DNS frameworks so
> >that we can trust lookup results from DNSs. However, what about 
> 
> Note that all it does is make sure you can trust that the contents of
> DNS are what those with authority over that part of the DNS have set
> up, not that it is true or useful.  That is, that data you get from
> the root zone ".", including who has authority over its subzones like
> .com, is what those with authority over the generally accepted root
> want; that the data you get from .com, including who has authority
> over its subzones like example.com, is what those with delegated
> authority over .com want; that the data you get from example.com,
> including, say, the IP address to use for www.example.com, is what
> those with delegated authority over example.com want; etc.
> 
> >geographical information and orgainzational information? Is that
> >going to be available in secure DNS any time soon? From the
> 
> Secure DNS can secure any information that the DNS can store.  It
> doesn't add to that, except that it adds security related stuff
> (signatures, keys, etc.).  There is an LOC RR that can encode location
> but it is not widely used (see RFC 1876, "A Means for Expressing
> Location Information in the Domain Name System",
> <http://www.ietf.org/rfc/rfc1876.txt>).
> 
> >RFC 2538 I have seen focus on AltSubjectName which can be used to 
> >include DNS info. Don't know how you'll use that information alone 
> >to find out about geographical origin of the request and more 
> >specifically, the "Tax Domain" of the request.
> 
> RFC 2538 is just about how to store certificates in the DNS.
> Certificates are signed entities and are normally verfied based on the
> signature in the certificate.  You can store all kinds of info inside
> certificates and if you trust the issuer of the certificate, maybe you
> can trust that info.
> 
> >However, I think we need to consider simpler solutions:
> >1) LDAP Directory Servers accessible over the extranet/internet
> >   s.t. they store domain information which can be inquired over the 
> >   internet once the request is received. SubjAltName would be
> >   ideal for directories.
> >
> >2) Configure Proxy Servers and Firewalls to transparently 
> >   attach common, static, organizational and geographical information 
> >   about the client as part of the client cert:
> >	- geographical location of the request sender;
> >	- organization's Id (this need to reflect the global enterprise
> >        ID, including any divisional info, e.g., IBM Global Services)
> 
> In my opinion, changing all the proxy servers and firewall in the world
> is impractical.
> 
> >OTP is about payment protocols, but to solve this problem (the identity
> >of the user, the orgins of the user, etc.) we also need an easily 
> >deployable and cheap infrastructure...
> 
> IOTP is about trading.  Most any payment protocol can be tunneled
> through IOTP.  The paymnet protocols generally provide their own
> security.  The merchant mostly cares about getting paid.  They don't
> don't generally need the identity of the customer.  And even if their
> were a global tax inftrastrucutre, it is not clear that they need more
> than the minimum information to figure out what tax rate to apply.
> 
> >Zahid Ahmed                     Commerce One, Inc.
> >Commerce Security Architect
> >email: [email-masked]
> >v: (650)-623-2814
> >fax: (650)-938-8055
> 
> Thanks,
> Donald
> 
> >> -----Original Message-----
> >> From: Donald E. Eastlake 3rd [mailto:[email-masked]]
> >> Sent: Tuesday, March 23, 1999 7:09 PM
> >> To: [email-masked]
> >> Subject: IP addresses (was Re OECD technical advisory group on
> >> e-commerce and professional data assessment)
> >> 
> >> This doesn't have much to do with the IOTP protocol but I suppose it
> >> might somehow effect future versions...\
> >> 
> >>  > Date:    Sat, 28 Feb 1998 07:30:33 MST
> >>  > From:    John Messing <[email-masked]>
> >>  > Subject: Re: Re OECD technical advisory group on 
> >> e-commerce and professional da
> >>  >      ***ta assessmen
> >>  > 
> >>  > One of the pieces of data that a browser transmits to an 
> >> inquiring server is
> >>  > the static or dynamic IP address that it is currently 
> >> using. A static IP
> >>  > address is one that does not change. A dynamic IP address 
> >> is provided on a
> >>  > rotational basis by an ISP and usually changes with each 
> >> connection. Most
> >>  > consumers probably use ISP's and dynamic IP addresses.
> >> 
> >> Well, it is not particularly that a browser explicitly transits an IP
> >> address when it does a query.  It is that the TCP connection process
> >> that underlies any HTTP, FTP, SMTP/POP/IMAP (email), etc., transfer
> >> necessarily involves each end learning the IP address of the other
> >> end.  But, in all cases you may be getting the IP address of some
> >> intermediate NAT (network address translation) box and/or firewall
> >> and/or proxy/cache.
> >> 
> >>  > This address can be captured by the server and stored. The 
> >> dyamic addresses,
> >>  > for consumers, usually are modem of an ISP. The ISP's 
> >> jurisdiction will not
> >>  > necessarily be that of the user, but in most cases, it 
> >> probably is. That
> >>  > might be a place to begin for determining place of origin.
> >> 
> >> In fact, the address is almost always captured and written to a log
> >> file, although the web server usually tries to translate the numeric
> >> IP address into a domain name first.
> >> 
> >>  > The problem of using the P3 id no. is
> >>  > 1. not everyone will have an Intel chip of that generation, and
> >>  > 2. it will probably cause a ruckus among privacy groups to 
> >> suggest it.
> >> 
> >> The IP address, while not particularly valuable, is certainly more
> >> likely to be authentic than an id number that simply purports to be
> >> a Pentium 3 serial number.  It seem to me a lot easier to fake that
> >> than the IP addres.
> >> 
> >> 
> >>  > Date:    Sun, 21 Mar 1999 13:16:48 EST
> >>  > From:    "Milton M. Anderson" <[email-masked]>
> >>  > Subject: Re: Re OECD technical advisory group on 
> >> e-commerce and professional da
> >>  >      ***ta assessmen
> >>  > 
> >>  > Do IP addresses map to tax authority boundaries?
> >> 
> >> Not particularly.  Big blocks of IP address are frequently allocated
> >> to specific registries or ISPs or companies but its common for
> >> someone with a big block to sub-allocate them to activites in a wide
> >> variety of locations.
> >> 
> >>  > How hard is it to install a hacker tool that will
> >>  > spoof the PIII serial number?
> >> 
> >> From all I know, I think it would be pretty easy.
> >> 
> >>  > Milt
> >> 
> >> 
> >>  > Date:    Sat, 28 Feb 1998 15:59:15 MST
> >>  > From:    John Messing <[email-masked]>
> >>  > Subject: Re: Re OECD technical advisory group on 
> >> e-commerce and professional da
> >>  >      ***ta assessmen
> >>  > 
> >>  > I disagree that this thread is ridiculous. If the various 
> >> participating
> >>  > countries are willing to agree that the IP address of the 
> >> ISP is the point
> >>  > of sale because that is where the buyer logs on to the 
> >> Internet, then it
> >>  > might be a basis for a taxation convention between 
> >> agreeing countries. The
> >>  > ISP's all have corporate addresses in some jurisdiction or 
> >> other. One need
> >>  > only to consult internic to find out the jurisdiction 
> >> where they are
> >>  > located. If the seller is located in another jurisdiction 
> >> from the buyer as
> >>  > defined above, then intra country taxation issues can be 
> >> negotiated and
> >>  > presumably resolved.
> >> 
> >> Well, if you want to look up a numeric IP address, you need to ask
> >> the regional IP registries, ARIN, RIPE, and/or APNIC, not the
> >> Internic.  If you can back translate the IP addresses to domain
> >> names and they are in a top level domain that the Internic handles
> >> (.com, .net, .org, .edu), you can inquire there.  I don't know how
> >> good the IP registry's records are but the Internic's have
> >> essentially no quality control. As far as I can see, NSI will store
> >> essentially any garbage you want in its records.  I suspect data
> >> quality in the national domain name registries (.us, .ca, .uk, .jp,
> >> etc.) varies a lot from country to country.
> >> 
> >> I would also note, that if you control an IP address, you can
> >> generally put whatever domain name you want in its inverse lookup
> >> location.  So if I control 10.123.61.30, I would normally also control
> >> the data stored under 30.61.123.10.in-addr.arpa and could, for
> >> exmaple, store a pointer to "whitehouse.gov" or "microsoft.com" or
> >> "no.such.domain.name" there. However, you can get some assurance by,
> >> after doing the inverse lookup, then doing the forward lookup and
> >> seeing if you get back to the same numeric IP address you started out
> >> with.  And all this will be improved when domain name system security
> >> is deployued.  (Note: Network 10 is reserved for local use so IP
> >> addresses starting with "10.", which I used in this example, are not
> >> globally meaningful or unique and such networks have to be connected
> >> to the global Internet through a NAT box to translate to a globally
> >> unique address for routing.)
> >> 
> >> 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]
> 
-----------------------------------------------------------------------
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]

wTo: Yoshiaki KAWATSURA <[email-masked]>
cc: [email-masked]
Subject: Re: Comments of IOTP DSIG. 
Date: Thu, 01 Apr 1999 01:11:40 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

From:  Yoshiaki KAWATSURA <[email-masked]>
Message-Id:  <[email-masked]>
To:  [email-masked]
Cc:  [email-masked]
Date:  Tue, 30 Mar 1999 15:30:10 +0900 (JST)

>I have some comments for IOTP DSIG.
>
>(a) 3.2 Digest Element
>There is no DTD definition of Resource Element.
>We should add the definition of DTD.

Due to the limited requirements of IOTP, we put multiple digests into
the Manifest and don't really need a separate Resource element, do we?

>(b) 4.3.5 I do not understand why the Attributes element is needed.
>I think that this is because there is no attribute in Attributes.  
>
>I suggest to remove the followings,
>
>Current:
>   <!ELEMENT Manifest
>           (       Algorithm+,
>                   Digest+,
>                   Attributes?,
>                   OriginatorInfo,
>                   RecipientInfo+,
>           )
>
>
>My New Suggestion:
>   <!ELEMENT Manifest
>           (       Algorithm+,
>                   Digest+,
>                   Attribute*,
>                   OriginatorInfo,
>                   RecipientInfo+,
>           )

You have a point but I think that on balance we should leave it there
in case some implementation of v1.0 wants to add some authenticated
attribute.

>(c) The XML reference is only the backward reference, such that one
>pass procedure, in order to lighten the signature process.
>
>Therefore I suggest the following replacement.
>
> (1) To exchange the order between Signature Component and Certificate
>     Component.

I think the main concern is to avoid buffering the main part of the
docment.  Buffering the IOTPSignatures element doesn't seem like such
a big thing.  Still, I don't have any problem with swapping these.
Does anyone else have an opinion?

> (2) To exchange the order between Manifest Element and Value Element.

Same comment as (1) above...

>(d) I just wonder who and how will the ANY data define in 4.3.7, 4.3.8
>and 4.3.9?  Additionally, who and how will the type data define in
>4.4.1?  We should define the above data for the reason of
>interoperability.  And I suggest that these data(include chapter 5)
>should be defined in the separate document.

For 4.3.9, what type of parameter is appropriate is defined by the
Algorithm.

For 4.3.7 and 4.3.8, the signer and verifier can agree on what they
want to put there.  In v1.0, they are assumed to have prior
acquaintenace and can agree on this.

On 4.4.1, I guess at least one value should be put in the Supported
Algorithms section, like it says...

>(e) 5 Supported Algorithm
>The current draft specifies the supported algorithms as follows,
>"The IOTP specification 1.0 requires the implementation of the DOM-HASH,
>SHA1,MD5,DSA and HMAC algorithms to provide a compliant implementation 
>of IOTP 1.0. Implementation of RSA is also recommended."
>I think this is very restricted because the REQUIRE is used as the same
>mean of MANDATORY in the RFC2026, so I suggest "requires the
>implementaton of" should be replaced by "should implement."

The idea was that at least one algorithm of each required type should
be mandatory so that any two compliant implementations can
interoperate.  I suppose MD5 should be dropped from the list.  The
ones that are required are all, as far as I know, free from licensing
restrictions.

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

Thanks,
Donald
===================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668   [email-masked]
 65 Shindegan Hill Rd, RR#1  +1 914-784-7913(w)     [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]