Subject: Comments of IOTP DSIG.
From: Yoshiaki KAWATSURA <[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.

(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+,
           )

(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.

(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.

(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

-----------------------------------------------------------------------
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], [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: Question for IOTP Authentication
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Tue, 30 Mar 1999 14:45:54 +0900 (JST)
Lines: 96
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

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

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

From: Werner Hans <[email-masked]>
To: [email-masked]
Date: Mon, 29 Mar 1999 16:13:59 +0200
Subject: Architecture and Payment API
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

--Message-Boundary-19337
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body

Hi,

I have checked the recent document posted by Don and
applied some minor changes that were introduced with
the recent changes of IOTP.
The main changes address:
- the removal of payment customer care topics,
-  updates of completion and error codes.

Werner
------------------------------
Werner Hans - Systemanalytiker
Atos
Pascalstrasse 19
D-52076 Aachen
Tel.: +49 -2408 148349
<www.atos-group.de>

--Message-Boundary-19337
Content-type: text/plain; charset=US-ASCII
Content-disposition: inline
Content-description: Attachment information.

The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any another MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

   ---- File information -----------
     File:  iotpar101current.zip
     Date:  29 Mar 1999, 15:59
     Size:  883130 bytes.
     Type:  ZIP-archive

--Message-Boundary-19337
Content-type: Application/ZIP; name="iotpar101current.zip"
Content-disposition: attachment; filename="iotpar101current.zip"
Content-transfer-encoding: BASE64

--Message-Boundary-19337--
-----------------------------------------------------------------------
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: Zahid Ahmed <[email-masked]>
To: "Donald E. Eastlake 3rd" <[email-masked]>,  [email-masked]
Subject: RE: IP addresses & Taxes & Directories?
Date: Tue, 23 Mar 1999 20:28:44 -0800
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

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;

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 
geographical information and orgainzational information? Is that
going to be available in secure DNS any time soon? From the
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.

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)

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

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

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

To: [email-masked]
Subject: -protocol-03.txt and -dsig-00.txt working group last call
Date: Wed, 24 Mar 1999 09:47:40 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

As I announced without objection at the meeting in Minneapolis last
week, I am initiating a two week working group last call on the
draft-ietf-trade-iotp-v1.0-protocol-03.txt and
draft-ietf-trade-iotp-v1.0-dsig-00.txt drafts for publication as
Informational RFCs.  They are targeted as Informational as they (or at
least draft-ietf-trade-iotp-v1.0-protocol-03.txt) are arguably
primarily the output of the Open Trading Protocol Consortium which had
change control over IOTP before it was transfered to the IETF.

I'm sure there will be some nits and minor changes but assuming
there is rough consensus on the drafts and changes, they can be
incorporated and the resultant document forwarded to the IESG in
April.

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]

Date: Wed, 24 Mar 1999 12:49:10 +0000
To: [email-masked]
From: Graham Klyne <[email-masked]>
Subject: RE: Capability detection
Cc: [email-masked]
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

At 11:18 23/03/99 -0500, [email-masked] wrote:
>## A big advantage of IOTP is that if it is installed at the merchant
>## and the consumer, the merchant need only display a single "buy" or
>## "pay" button even as the merchant adds new payment schemes.
>## Without IOTP, you are generally reduced to having a button per
>## payment scheme and if the poor user clicks on the wrong one, the
>## transaction fails.
>
>## There is a "standards way" of solving this: the Accepts header.  But
>## Netscape and Microsoft, in their competitive scramble have produced
>## a very jumbled browers landscape out there as to what is actually
>## deployed.  In terms of 'acceptance', I think that waiting
>## around a couple of years for there to be an almost universally
>## deployed "standards way" of doing this is to guarantee little
>## acceptance of IOTP or anything else that encounters this problem on
>## the global Internet.  (They could, of course, always be used in
>## controlled pilot or intranet environments.)

The work of 'conneg' was motivated in part by a desire to extend and clean
up the expressive power of constructs like "Accept".  The root idea is that
features other than just content-type can be used to characterize a
recipient's capabilities, and the 'conneg' framework is a standards-track
mechanism to do just this.

What 'conneg' does not to is define a specific *mechanism* for
communicating capability information, as that was seen as something that
must depend upon the particular protocol used.

Given the extensible 'conneg' framework, defining a simple header to
indicate capabilities should be a relatively easy matter.  For Internet
fax, an additional field in an MDN may be used, and (in time) 'rescap' will
provide an alternative mechanism.  For HTTP, I can imagine a header like
'Accept-features:' that provides capability information.

For IOTP (and I don't know the spec in any detail) I would imagine that an
IOTP-specific field containing a 'conneg' string, and appropriate media
feature registrations as required for IOTP, might be used.

I am not trying to claim that 'conneg' and related work is the Right Way
for IOTP, just to ensure that it is not rejected for the wrong reasons.

>## I agee that the TRADE WG shouldn't care about a "general" solution to
>## this class of problem. But I havn't figured out a way to construct a
>## solution such that the type of solution only works for applicaiton/iotp.

Well, yes, exactly.

#g

------------
Graham Klyne
([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]
Subject: IP addresses (was Re OECD technical advisory group on e-commerce and professional data assessment)
Date: Tue, 23 Mar 1999 22:08:46 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

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]

To: [email-masked]
Subject: RE: More Minneapolis Slides
Date: Tue, 23 Mar 1999 17:47:00 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

There was a permissions problem with this file
but it has been fixed.

Donald

Message-Id:  <[email-masked]>
To:  [email-masked]
Subject:  More Minneapolis Slides
Date:  Tue, 23 Mar 1999 09:02:13 -0500
From:  "Donald E. Eastlake 3rd" <[email-masked]>

Dave Brudett's presentations are available at
<ftp://ftp.pothole.com/pub/ietf-trade/IETF_Minneapolis_DSB.zip>

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: [email-masked]
To: [email-masked]
Date: Tue, 23 Mar 1999 11:18:31 -0500
Subject: RE: Capability detectio9n (was: "Wallet" Detection)
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

See comments below preceeded by ##...

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

Ian King <[email-masked]> on 03/17/99 12:34:26 PM

To:   "'Donald E. Eastlake 3rd '" <[email-masked]>, "'Graham Klyne
      '" <[email-masked]>
cc:   "[email-masked] '" <[email-masked]> (bcc: Donald
      Eastlake/Hawthorne/IBM)
Subject:  RE: Capability detectio9n (was: "Wallet" Detection)

RESCAP was a BOF on Monday.  While I did not attend, the title is
suggestive
of a solution for this problem space.

## If it is a solution and even if it were elevated to standard today, I
## think it would be a couple of years before it was widely deployed.

## Every day people create web pages or items designed to be displayed
## in web pages, such as banner ads, that need to know if a MIME type
## handler is installed at a user's browser so they can offer the user
## an installation/download option or gracefully degrade when the
## requisit MIME type handler is not installed.  My concept in
## suggesting this work item was to document the best current
## engineering practice we can find in this area as a suggestion to
## the IOTP merchant site implementer today.

The problem of doing things in a "standards way" is that yes, it takes
time.
However, the ultimate win is usually worth it, in terms of acceptance and
interoperability.  :-)

## A big advantage of IOTP is that if it is installed at the merchant
## and the consumer, the merchant need only display a single "buy" or
## "pay" button even as the merchant adds new payment schemes.
## Without IOTP, you are generally reduced to having a button per
## payment scheme and if the poor user clicks on the wrong one, the
## transaction fails.

## There is a "standards way" of solving this: the Accepts header.  But
## Netscape and Microsoft, in their competitive scramble have produced
## a very jumbled browers landscape out there as to what is actually
## deployed.  In terms of 'acceptance', I think that waiting
## around a couple of years for there to be an almost universally
## deployed "standards way" of doing this is to guarantee little
## acceptance of IOTP or anything else that encounters this problem on
## the global Internet.  (They could, of course, always be used in
## controlled pilot or intranet environments.)

And, while this may be a piece that will make IOTP
better (although I can't see that it's essential), I'd still suggest that a
"general" solution to this class of problem is out of scope for the group.

## I agee that the TRADE WG shouldn't care about a "general" solution to
## this class of problem. But I havn't figured out a way to construct a
## solution such that the type of solution only works for applicaiton/iotp.
## And, I don't understand why effort should be put into being sure the
## suggested technique is broken for other cases.  If you have some ideas
## on how to solve this for IOTP only, I'd be happyt to hear them.

## Thanks,
## Donald

Ian King <[email-masked]>
Internet Bill Delivery & Payment
MICROSOFT CORPORATION

-----Original Message-----
From: Donald E. Eastlake 3rd
To: Graham Klyne
Cc: [email-masked]
Sent: 3/16/99 11:55 PM
Subject: Re: Capability detectio9n (was: "Wallet" Detection)

"conneg" seems to be primarily concerned with future development in
how to negotiate the form of delivered information, not its type.
As such, I don't see how it is relevant to designing a workable
technique
for near term implementation.  Even if a new standards track document
popped out soon, it could be long time before it is ceployed.

"rescap" doesn't seem to be on the IETF web pages right now.

Thanks,
Donald

From:  Graham Klyne <[email-masked]>
Message-Id:  <[email-masked]>
X-Sender:  [email-masked]
Date:  Tue, 16 Mar 1999 21:47:10 +0000
To:  "Donald E. Eastlake 3rd" <[email-masked]>
Cc:  [email-masked]

>At 11:37 14/03/99 -0500, Donald E. Eastlake 3rd wrote:
>>
>>For the Internet Open Trading Protocol and similar protocols operating
>>via HTTP, web servers are frequently faced with the problem of
>>determining whether software to handle the protocol they wish to use
>>is installed at the user's browser/machine.  This frequently means
>>finding out if a particular MIME type, such as application/iotp, is
>>being handled.
>
>I would suggest that the work of the 'conneg' group might be surveyed
for
>possibly useful components (including some recent I-D submissions).
>
>Also, the 'rescap' group's work might prove to have some relevance.
>
>#g
>
>------------
>Graham Klyne
>([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]
Subject: More Minneapolis Slides
Date: Tue, 23 Mar 1999 09:02:13 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Dave Brudett's presentations are available at
<ftp://ftp.pothole.com/pub/ietf-trade/IETF_Minneapolis_DSB.zip>

Thanks,
Donald

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

To: [email-masked]
Subject: Taxes and the IETF TRADE Working Group
Date: Tue, 23 Mar 1999 08:26:06 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

As far as I am aware, the only specific proposal before the working
group is the ability to optionally annotate an order description so
that it can be indicated what part of the price is taxes (and/or
shipping and/or handling etc.).  Since this sort of annotation is
common on paper documents that one gets in the concrete world, they
seem like a good idea to me.  In all the arguments, I haven't seen any
good reason not to include the option to permit merchants to make such
annotations.

Most of the discussion on taxes has little to do with the Internet
Opne Trading Protocol we are developing, at least as it stands now.
But I hesitate to clamp down too hard on the discussion because the
ways in which governments will want to tax various types of
transactions will likely, in opinion, effect future versions of the
protocol.

In thinking about taxes on Internet purchases, it is important to
remember that a substantial number of them are for hard goods that get
shipped to the consumer.  In those cases, I don't see that using the
Internet for communications in making the purchase is much differnt
from using the telephone.

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: [email-masked]
To: [email-masked], [email-masked]
Subject: RE: OECD technical advisory group on e-commerce and professional  data assessmen
Date: Tue, 23 Mar 1999 11:16:40 +0100
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This thread started with David Burdett noting that he had been invited to
participate in an OECD technical advisory group (TAG).

The OECD is explicitly bringing together business and government groups
together to find solutions to the taxation challenges presented by
electronic commerce in a manner that is mutually agreeable and creates the
least burden on the system. 

I'll be at the same meeting as David in April and some background on the
OECD and its position in relation to taxation and electronic commerce might
be helpful.

The OECD is not interested in new taxes for electronic commerce. Neutral tax
treatment between conventional and electronic commerce is the desired
outcome - a level playing field. Tilting the playing field in either
direction disadvantages part of an economy and benefits nobody in the long
run.

At a practical level, neutrality still means that taxpayers are responsible
for filling in their tax returns and having documents like receipts and
invoices to work from. The existing laws already apply to the electronic
commerce environment.

I imagine that people will chose to use IOTP for a number of reasons - the
convenience of matching buyer and seller payment systems in a single
interface, the generation of documentation for warranty claims etc. If the
protocol also helps people with their tax position, it just adds more value,
so its more attractive.

The OECD is not going to dictate what the IOTP must be or must include.
However it seems as thought IOTP already includes most of the elements that
people might need to work out their tax position at the end of the year. If,
on closer examination, tax experts find that IOTP does not contain a field
for some useful piece of tax information, they'll suggest it to the IOTP
people who can decide for themselves whether they want to include the field
or not.

So, what's in it for the tax people?

If tax people know that the systems underlying electronic commerce support
individuals (or companies, trusts, partnerships...) to get their tax
position correct, then there is less chance of innocent errors when people
are meeting their tax obligations. 

The existing laws already apply, but the practical mechanisms have not yet
caught up. When you buy something locally you know who you are dealing with
and both parties know what local taxes might apply. You also get some type
of receipt or invoice which you can use if you need to claim a tax deduction
etc. With mail order, even from a foreign country, it's similar. You get
documentation to help you answer tax questions and to provide comfort in the
form of warranties etc. You are able to make an informed decision about the
foreign country with which you are dealing, and whether you think it has
*reputable* businesses. You will also possibly have access to phone or fax
or e-mail contacts for queries or customer support.

One of the key things from the above example, is that commercial trust is
important. Commercial trust often revolves around identity - "who am I
dealing with".

I think that technologies like digital signatures might provide answers on
identity. I guess that IOTP will record some details of buyer and seller
(like an invoice in the real world), but that the validation of identity
will be done by reliance on some other system (according to the mutually
agreeable arrangement reached between buyer and seller). Whatever technology
is used to answer the question of "who am I dealing with" in the commercial
sense, it might also answer the "who" questions for tax purposes, or
intellectual property, or contact law etc.

A number of useful OECD documents on the tax issues are available from: 

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

ranging from the technical to the more concrete. The Taxation Discussion
Paper perhaps containing some of the most interesting things to consider.

-----------------------------------------------------------------------
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: Sun, 21 Mar 1999 13:32:45 -0800
To: Dave Birch <[email-masked]>,  "Milton M. Anderson" <[email-masked]>,  Ietf Trade WG <[email-masked]>
From: Bob Glushko <[email-masked]>
Subject: Re: Re OECD technical advisory group on e-commerce and professional data assessmen
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

At 08:44 PM 3/21/99 +0000, Dave Birch wrote:
>Milton M. Anderson said
>
>>How hard is it to install a hacker tool that will
>>spoof the PIII serial number?
>
>Please! I wasn't serious, just illustrating how ridiculous this whole 
>thread is becoming.
>

Not ridiculous at all.

I've heard that people are already building such P3 serial number spoofers.
 I think the spoofer should send back the telephone number of the
Electronic Frontier Foundation or some other organization concerned with
privacy rights (suitably masked so that any application requesting the
number can't reject it out of hand). 

Even if Intel is forced to let you disable the serial number, there is
nothing to stop Microsoft or any other publisher of software or content to
require that you enable it as a condition of installation.  I can imagine
that Windows 2000 installation will say  "sorry, we can't install unless
you let us know exactly who you are.....so we can track copies of
everything you do"

I suspect that this was the plan all along. Intel has now been taken off
the hook as the bad guy cause it obviously can't dictate to Microsoft. It
will have to portray itself as the dupe instead.

bob glushko

-- 
Robert J. Glushko, Ph.D., [email-masked], [email-masked]
Director, Advanced Technology, Commerce One Inc. 
2440 W. El Camino Real, Suite 710, Mt. View CA 94040 USA  **  (650) 623-2802
MOS->DYX and proud of it
-----------------------------------------------------------------------
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, 22 Mar 1999 12:32:31 +0000
To: John Messing <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: Re: Re OECD technical advisory group on e-commerce and professional data assessmen
Cc: Ietf Trade WG <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

At 07:30 28/02/98 -0700, John Messing wrote:
>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.

I think using IP addresses to determine physical location for legal
purposes would be an architectural nightmare for the Internet.  Do we
really want encourage people to erect mirrors on the information
superhighway, in addition to the fog already being experienced? (See
<draft-carpenter-transparency-00.txt>).

#g

------------
Graham Klyne
([email-masked])

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

Date: Mon, 22 Mar 1999 09:14:10 +0000
Subject: Re: Re OECD technical advisory group on e-commerce and profession al data assessmen
From: Neil McEvoy <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

----------
>From: John Messing <[email-masked]>
>

> 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

That just won't work, at least not in the way intended. I have a Compuserve
account because they have POPs worldwide - and wherever I am (and, for that
matter, whoever I am), they always assign a .com address. You can bet this
would be a 'dot Cayman Islands' address if US taxes turned out to be too
onerous.

Short of embedding tamper-proof ID chips and GPS receivers in our skulls,
none of these ideas will work. Like I said at the beginning of this thread,
governments should concentrate on cost-effective ways of raising taxes.

Neil
----------------------------------------------------------------
Neil McEvoy, Director                                   Hyperion
                                         8 Frederick Sanger Road
http://www.hyperion.co.uk/                  Surrey Research Park
mailto:[email-masked]                 Guildford, Surrey, UK
Finger for PGP public key                 Tel:+44 (0)1483 301793
(new key Jan 98)                          Fax:+44 (0)1483 301793

Where people, networks and money come together..consult Hyperion

----------
>From: John Messing <[email-masked]>
>To: Dave Birch <[email-masked]>,  "Milton M. Anderson"
<[email-masked]>,  Ietf Trade WG <[email-masked]>
>Subject: Re: Re OECD technical advisory group on e-commerce and profession al
data assessmen
>Date: Sat, Feb 28, 1998, 10:59 pm
>

> 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
-----------------------------------------------------------------------
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: Fri, 19 Mar 1999 15:14:33 -0500
Subject: TRADE WG Draft Minutes from Minneapolis
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Here are draft minutes of the TRADE working group meeting at the 44th IETF
meeting in Minneapolis taken by Kent Davidson.  Please send comments or
corrections to the list.  Thanks, Donald

TRADE Meeting 3/17/1999
-----------------------
Started 1999, March 17th, 13:05

Chair, Donald Eastlake

Agenda presented

David Burdett, Mondex: talk about evolution of documents

Changes between draft versions 02 and 03 of the main IOTP protocol
document.
    Outlined below...

Digital Signatures
    - Updated to reflect dsig draft. Updated section 5
    - separate paper covering dsig
    - revised DTD

Authentication
    - Last November, decided to permit authentcation to preceed any
transaction
    - Changes to offer and payment request

IOTP Transactions Section
    - Changes driven by authentication changes
    - Result:
    - Single def of message flow (how you do the payment, etc.)
    - Individual sections for each tranactions
    - Shorter!

- Payment Instrument Customer Care (PICC)
    Concluded:
    - Transaction definition not fully developed
    - really more of a financial transaction doesn't involve in "trade"
    Therefore
    - Removed PICC transaction
    - Removed PICC role

Hitachi: putting a document together on how they will implelement PICC

- Packaged Content
    Indentified requirements for multiple Packaged Content
    - Support some Payment protocols, receipts for SET
    - to support encapsulation of HTML

- BrandID
    - confusion over brand names and distinguish
    Therefore:
    - changed the way payment brands are identified to more closely mirror
the approach adopted by SET
    - Payment brands are now: "SET:" or "IOTP:" followed by the SET brand
structure or IANA registered IOTP name space brands, respectively

Q: SET uses internal colons in it Brands, problem?
A: Andrew: No - uses whole SET name, not a problem.

Use of IETF/IANA as registry of names and identifiers:
    - BrandIDs
    - Trading Role
    - Methods of delivering data

Delivery Exchange
    - Delivery Response may now also be signed
    Rationale:
    - Consisteny
    - easy
    - implementators thought was good Idea

HTML Support
    - All v0.9 implementations have used HTML as packaged content,
        spec doesn't support it so decided to add it

Misc
    - Removed XML tutorial section
    - Net Locations - tidied up defs

Donald:
    - How to proceed
    - Working Group last call
    - Any objections for continuing that way?  None, so will proceed.

David:
    Created document called XML Messaging
    Could call something different, suggestions
    In a sense, tied into how IOTP might evolve in the future

Evolution of IOTP?
    This is how it could evolve:

DSIG to go to its own BOF, related to IOTP dsig
XML messaging make use of constructs in IOTP, could be a separate standard

Develop domain specific items after feedback from pilots of IOTP 1.0

Any questions? (None.)

XML Messaging
     - What might be in this spec?

Start off by looking in the overview.
    What do you do on the internet? Make a request, send a response.
    Very simple exchange of messages.

Some exchanges need to be more complex than that. More than one
interaction, both parties need to end in a consistent state.
1st party -> 2nd party. Swapping messages until necessary until get a
response back.

More general case in how IOTP is done, use this type of message to do a
delivery.

Multiple document exchange to combine multiple messages together, creating
transactions.

Example of doing purchase of a airline ticket. All these messages need to
be encapsulated inside of something.

What do people think?

- Audience: Absolutely, my company is trying to send encapsulated XML data
back and forth.

David:
    - This is an example of how we can combine things together

Lifted from the current IOTP spec the data elements which are used in
messaging

At start of IOTP, transaction reference block
A complete message would be all of that (pointing to transaction page)

Within each transaction block have a Signature block which is optional

The actual data can be anything

Lets look at a transaction and the signatures bit

Trans Ref Block: Consists of trans ID block, msg ID block
    The transID contains the ID for the element and a globally unique ID
for the whole transaction, plus a timestamp
    The msgID gives the ID of the software, the time created, and the
message id, unique for the message

Q: Can you link transactions?
A: Yes, RelatedTo option allows for linking of different transactions

Audience: Good example is authorization for credit card payment and
subsequent settlement

Signatures can sign any data, any message in the same transaction

If you've got 1 transaction here, this 3rd party could sign some data which
it would then receive. Provide the credentials of the signer to
authenticate through another party for a 3rd party. If that trust hierarchy
is there.

We then got into an example of how signatures would work. (Wish this could
be in color.)

Signature 1 could be used to authorize a service to start.
Sig 2 can authenticate completion of transaction, even if a failure state.
Sig 1 and 2 can get send to 3rd party who can then authenticate both, and
provide a complete audit trail of what is going on.

This is the way IOTP works right now.

Q: ... (can't hear)
A: any sort of 3 party exchange can be reduced to a series of 2 party
exchanges. No reason why the 1st party here...

Back to 1st example (flight example)

This 2nd party may be intermediary. Parallel inquiries on other airline
databases, no reason why you can't have other inquiries to other databases.

Did this answer your question?

Q: Does the 2nd party in this example keep state about the transaction?

A: Quite possible that the 2nd party and the 4th party are the same people.
They need to maintain state between the request and the response. The 1st
party (Consumer) needs to maintain state all the way through.

Errors
------
Receive errors - document received was wrong and here's why
May optionally apply to any data within a message

Error Block: 2 compoments
    - Description of the error
    - Textual desc
    - Where the error exists
Could be a fatal error, can specify severity
Generalized mechanism, got an error, here's why

Another thing inside IOTP is packaged content, may want to encapsulate data
within other docs. IOTP has a way of doing this...

Single Round Trip document exchange, or may have a more complex doc
exchange

Request, any number of Exchange messages, Response messages

Common requirements for document exchanges:
- Request Message
    - What you want to do, may use signatures, may depend on success of
previous exchanges
    - Who sent the message

Exchange Message
    - Optional
    - May contain data

Response Messages
    - What happened, status information indiciated success for failure
    - signatures to prove action happened

Response Message, Example
    In response message got data describing result. Depended on what data
you're swapping, what sevice you're trying to do
    It also needs some status information about business success of
failure, payment failed, funds not available. Technical failure is "XML is
not correct". Business failure is "XML is perfect, just can't do what you
want to do."
    May link signatures back to earlier signature. You can see how this
signature signed this signature up top.

This kind of thing you may have inside a response message, inside a request
message, which resulted in that as a response.

talked about how signatures can link requests across organizations or
across requests, slide 23

Q: (Handout is different than printed slides)
A: Mentioned that, minor error in two slides in handout has been fixed.

Status component
    - Report on the status of a particular service or response reference to
that data element which describes what you were going to do. The Status
component which is not shown here which should refer to a particular
element. Got a completion code which indicates the status of the process.
It is a useful way for defining this type of thing which may be extended.

Part 3:
Transaction Status Inquiry
    - Quite easy for one party to send to another party to get status of a
transaction.
    If transactions are broken down can restart a transaction.
    If you're waiting for goods to be delivered, waiting for them to be
shipped, can inquire as to the status of the shipping

Payment transaction

What we could do is take this specification and back to (slide 4) use these
for implmenetation, lift this out and create a new standard for exchanging
XML documents. How can we best take it forward.

Donald:

Favorable response to modularizing documents, whether it should be handled
in some other way, say, as a general way for doing this for a variety of
applications.

Core applications protocol BoF (APPLCORE), asking for drafts for this type
of thing. The mindset tere, however, was different than this so they may
not want to take it.

Q: For now the focus is to stay in the IOTP protocol? Is there any intent
of becoming generic XML messaging?

A: Donald: It was described in that fashion but it was designed part of the
trading protocol effort. There's virtue in layering, etc. Even if it's
never used outside of this protocol, it makes sense to keep it as a
separate, modular document.

Q: May apply in the OBI community
A: OBI is heading towards XML, should serve OBI quite well. Requirements
might be different, but messaging might fit in unmodified. OBI is another
organization. Any individuals may present this to OBI, and if I receive
requests from them I'm happy to speak with them.

Q: ApplCore, creating something general, cautious about calling it generic
when it has no experience outside of IOTP.
A: David: Talked with an individual who said they needed this for apps work
for XML

Q: Same as in dsig BOF, XML owned by W3C, should we be taking this on
A: IP was designed by IETF, not all applications using IP are within IETF,
not a great argument.

Q: David: Useful? Donald: Separate into a different document?
A: (Consensus in favor)

Audience: Useful to unclutter the current docuemnt.

Donald introduced:

Kent Davidson, Differential: Spoke about XML DSIG document
    Based on Richard Brown's digital signing document, which was going to
be originally part of IOTP.
    His document was very broad and had various aspects which did not apply
to IOTP, and so in a smaller meeting in Ft. Lauderdale we spoke
specifically about how to reduce his document into what we have today.
    Major changes were making Originator and Recipient information specific
to IOTP, instead of the generic representation in dsig, made the algorithm
specifications more reusable to keep the signature components of IOTP
small. Questions, or comments, speak with me.

HTTP Supplement:
    How to do IOTP over HTTP
    originally by Chris Smith
    not a high level
    suggest reading with critical eye
    HTTP expertise before last call

Architecture and Payment API
    - Example of how you might structure an implementation, how you might
have an interface to different payment systems, etc.
    - URL on slide is not valid for this, yet but it has been mailed to the
list and will be at the URL real soon now.  It's still a Microsoft World
document and has not yet been IETFized

Mailing list comments

SET Supplement
    To talk about how to interoperate with SET
    Andrew: Changes made on current API document. New version will be out
in a month or two.

SCCD Supplement
    Secure Channel Credit Debit
    early draft of that, JCP draft coming this week
    Use credit card info in SET structure to transmit the essential
information back and forth

No doc yet to use eCheck with IOTP
Wallet Detection item, described below, could use its own document, etc.

David: SCCD help?

Q: We interface with a ton of payment gateways, willing to take that on.
[Tom Arnold from CyberSource.]

Implementations
- SMILE: Hitachi, Fijitsu, NTT, etc.
    - Andrew Drapp
- Royal Bank of Canada
     - Chris Smith
- Differential
    - Kent Davidson
- CyberSource
    - Tom Arnold
- British Telecom (JCP, Ltd.)

Andrew Drapp: SMILE project
1) Standard Smart Card Interface for smart cards
- Consumers can use their cards everywhere
2) Trading protocol for multi-payment methods in Japan
- Based on IOTP 1.0
- Enhanced for Japanese specific options (Payment with Bonus Plan)

Q: David: Feed changes back through IOTP group
A: No, not initially.

Q: Donald: IOTP additions or SET additions?
A: SET already includes Japanese additions. Won't make it incompatible.

Settlement Support Center
- Standard IOTP Format
Consumer at home, visits Virtual mall, does IOTP with Settlement Center.

Settlement Center connetcs to banks, credit card, or electronic cash
issuer.

Retailer, pay in stores with these smart cards

Smart Card to purchase from Home, Retailer, Public Facility
Connect through internet to virtual malls.

Trial Systems Overview
    - Pay via IOTP, download

Project Schedule
    - Implementation this fall

Member Companies
    - VISA, MC Japan, UC Card, DC Card, JCB, Orient Corp., Hitachi Credit

Banks: Tokyo-Mitsubishi, Sanwa, Asahi, Daiichi Kangyo, Fuji, Association of
Regional Banks

Vendors: Hitachi, Fujitsu, NTT, Oki

Content Providers: DNP, PA

Sponsored by MITI (Ministry of International Trade and Industry)

Donald: Wallet Detection

Most browser don't tell you it accepts a type in the header, just pass in
*/*, really have to use JavaScript or ActiveX.

Kent: We've actually solved this problem, have to detect browser type, and
solved the problem for both browser types.

Donald: Ok, if this is or is not a problem, make sense to create a document
which outlines how to do this, and it will be applicable for
application/iotp as it will for any other MIME type.

Miscellaneous:

X9.59 - Secure Object for account based payment protocols. Not a payment
system. Objects which are signatures over data elements. Request whether
someone has access to that account. Since we have a mechanism which is
payment system independent. Less practical in the short run, the banks need
to support it.

Easier to send along with a X9.59 object the credit card info which it
secures.

No one volunteer to do any work or further investigation in this area.

Updating the Working Group Charter
- "v2" Schedule

Nothing specific, people should be thinking about that.
May end up updating it before next IETF meeting.

Current Charter on www.ietf.org

Lastly:

Future Meetings: July IETF, Oslo, Norway.

No additional working group meetings anticipated in the short term.
Schedule meeting at next IETF in Oslo, Norway.

Meeting terminated 1999, March 17, 14:35

_____________________________
Kent M. Davidson
Vice President of Engineering
Differential, Inc.
direct (408)864-0604
fax    (408)864-0601
mailto:[email-masked]
http://www.differential.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: Fri, 19 Mar 1999 15:22:32 -0500
Subject: RE: Capability detection (was: "Wallet" Detection)
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Chris,

Yes, that is essentially the way to do it if you have those JavaScript
facilities available.  I think for IE, you need to use ActiveX to query the
Registry.

Donald

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

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

"Smith, Chris" <[email-masked]> on 03/17/99 11:46:00 AM

To:   Graham Klyne <[email-masked]>, "Donald E. Eastlake 3rd"
      <[email-masked]>
cc:   "[email-masked]" <[email-masked]> (bcc: Donald
      Eastlake/Hawthorne/IBM)
Subject:  RE: Capability detection (was: "Wallet" Detection)

I think what was intended was something like the following:

If the following short script is included in any form that a merchant
sends to a consumer, when the form returns it may then also include a
setting that shows the presence of 'application/iotp' MIME handling.

!---------------------------------------
 <SCRIPT LANGUAGE=JAVASCRIPT>
 <!-- hide it
 if (navigator.appName=="netscape") {  // wise precaution
   if (navigator.mimeTypes["application/iotp"]) {
     document.write("<INPUT TYPE=HIDDEN NAME='iotp' VALUE='y'>")
     }
   else {
     document.write("<INPUT TYPE=HIDDEN NAME='iotp' VALUE='n'>")
     }
   }
 // end and hide -->
 </SCRIPT>
!---------------------------------------

Note that this only works for Netscape browsers past version 3 with
JavaScript
enabled. However, it should not interfere with any other techniques that
might
be used in other browsers. It should also not interfere with any other
e-commerce system detection techniques.

Note that the script will return either a definitive 'y' or 'n' - if the
script does not run, then there is no setting returned at all.

I've been looking for a succint solution for the other major browser for
about
15 months now, and I have yet to see anything that does the job. Is it
really
that hard to do in MSIE?

...Chris Smith
   Royal Bank
   416.348.6090

______________________________ Reply Separator
_________________________________
Subject: Re: Capability detectio9n (was: "Wallet" Detection)
Author:  "Donald E. Eastlake 3rd" [SMTP:[email-masked]] at
Internet
Date:    1999-03-17 02:55

"conneg" seems to be primarily concerned with future development in
how to negotiate the form of delivered information, not its type.
As such, I don't see how it is relevant to designing a workable technique
for near term implementation.  Even if a new standards track document
popped out soon, it could be long time before it is ceployed.

"rescap" doesn't seem to be on the IETF web pages right now.

Thanks,
Donald

From:  Graham Klyne <[email-masked]>
Message-Id:  <[email-masked]>
X-Sender:  [email-masked]
Date:  Tue, 16 Mar 1999 21:47:10 +0000
To:  "Donald E. Eastlake 3rd" <[email-masked]>
Cc:  [email-masked]

>At 11:37 14/03/99 -0500, Donald E. Eastlake 3rd wrote:
>>
>>For the Internet Open Trading Protocol and similar protocols operating
>>via HTTP, web servers are frequently faced with the problem of
>>determining whether software to handle the protocol they wish to use
>>is installed at the user's browser/machine.  This frequently means
>>finding out if a particular MIME type, such as application/iotp, is
>>being handled.
>
>I would suggest that the work of the 'conneg' group might be surveyed for
>possibly useful components (including some recent I-D submissions).
>
>Also, the 'rescap' group's work might prove to have some relevance.
>
>#g
>
>------------
>Graham Klyne
>([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]
-----------------------------------------------------------------------
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: John Messing <[email-masked]>
To: Dave Birch <[email-masked]>,  "Milton M. Anderson" <[email-masked]>,  Ietf Trade WG <[email-masked]>
Subject: Re: Re OECD technical advisory group on e-commerce and profession	al data assessmen
Date: Sun, 21 Mar 1999 19:03:26 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

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.

-----Original Message-----
From: Dave Birch <[email-masked]>
To: Milton M. Anderson <[email-masked]>; Ietf Trade WG
<[email-masked]>
Date: Sunday, March 21, 1999 1:57 PM
Subject: Re: Re OECD technical advisory group on e-commerce and profession
al data assessmen

>Milton M. Anderson said
>
>>How hard is it to install a hacker tool that will
>>spoof the PIII serial number?
>
>Please! I wasn't serious, just illustrating how ridiculous this whole
>thread is becoming.
>
>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: Re OECD technical advisory group on e-commerce and profession	al data assessmen
Date: Sun, 21 Mar 1999 20:44:51 +0000
From: Dave Birch <[email-masked]>
To: "Milton M. Anderson" <[email-masked]>,  Ietf Trade WG <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Milton M. Anderson said

>How hard is it to install a hacker tool that will
>spoof the PIII serial number?

Please! I wasn't serious, just illustrating how ridiculous this whole 
thread is becoming.

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: "Milton M. Anderson" <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Subject: Re: Re OECD technical advisory group on e-commerce and profession	al data assessmen
Date: Sun, 21 Mar 1999 13:16:48 -0500
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Do IP addresses map to tax authority boundaries?

How hard is it to install a hacker tool that will
spoof the PIII serial number?

Milt

-----Original Message-----
From: John Messing <[email-masked]>
To: Dave Birch <[email-masked]>; David Burdett
<[email-masked]>; Ietf Trade WG <[email-masked]>;
[email-masked] <[email-masked]>
Date: Sunday, March 21, 1999 10:45 AM
Subject: Re: Re OECD technical advisory group on e-commerce and profession al data
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.
>
>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.
>
>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.
>

-----------------------------------------------------------------------
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: John Messing <[email-masked]>
To: Dave Birch <[email-masked]>,  David Burdett <[email-masked]>,  Ietf Trade WG <[email-masked]>, [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
Subject: Re: Re OECD technical advisory group on e-commerce and profession	al data assessmen
Date: Sun, 21 Mar 1999 10:34:44 -0400
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

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.

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.

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.

-----Original Message-----
From: Dave Birch <[email-masked]>
To: David Burdett <[email-masked]>; Ietf Trade WG
<[email-masked]>; [email-masked] <[email-masked]>
Date: Sunday, March 21, 1999 1:00 AM
Subject: RE: Re OECD technical advisory group on e-commerce and profession
al data assessmen

>David Burdett said
>
>>Smart Cards could help provide the answer to identifying the location of
the
>>customer since they are secure and portable.
>
>Surely only something that isn't portable can help to identify location.
>Perhaps the IOTP wallet could be read the serial number from consumers
>Pentium III processors and use them as the basis for identifying the
>consumers jurisdiction for tax purposes.
>
>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: Re OECD technical advisory group on e-commerce and profession	al data assessmen
Date: Sun, 21 Mar 1999 07:51:34 +0000
From: Dave Birch <[email-masked]>
To: David Burdett <[email-masked]>,  Ietf Trade WG <[email-masked]>, [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David Burdett said

>Smart Cards could help provide the answer to identifying the location of the
>customer since they are secure and portable.

Surely only something that isn't portable can help to identify location. 
Perhaps the IOTP wallet could be read the serial number from consumers 
Pentium III processors and use them as the basis for identifying the 
consumers jurisdiction for tax purposes.

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]

Date: Sat, 20 Mar 1999 12:14:31 -0800
To: "Milton M. Anderson" <[email-masked]>,  David Burdett <[email-masked]>,  Ietf Trade WG <[email-masked]>, [email-masked]
From: Kaye Caldwell <[email-masked]>
Subject: Re: Re OECD technical advisory group on e-commerce and professional data assessmen
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

A relevant question is WHETHER smart cards should identify the location of=
 the
customer.=A0 Until the questions of whether identification should be=
 required,
and identification of what (residence?, billing address?, use?, purchase
location?) are determined by the tax agencies, and applied in a neutral=
 manner
to both on-line and over-the-counter transactions, trying to determine the
data
elements necessary is bound to be unproductive. Furthermore, the privacy
issues
are enormous. Let's not forget the recent Intel chip ID controversy.
Imagine if
the chip not only provided an id #, but also your address! Not a pretty
picture.

At 02:11 PM 3/20/99 -0500, Milton M. Anderson wrote:
>David,
>
>I'm not sure how smart cards would help in identifying
>the location of the customer?=A0 If the tax jurisdictions are determined
>by the point of use or consumption, then what is needed is the
>user's current location, not a place of residence.=A0 However,
>both current location and residence may be needed if for example,
>the authorities treat downloading a video as an ephemeral entertainment
>and taxed at the current location, while treating downloading of
>software as a permanent acquisition and subject to use tax at the
>place of residence.
>
>If the location can be established, then location can be mapped to
>the various federal, state, regional, county, and local tax authorities,
>taking into account various tax incentives and abatements that the
>higher levels may have granted at the lower levels, e.g. enterprise
>zones.
>
>Whether a given tax by a given authority will apply at a given
>schedule rate may depend on:
>
>1.=A0 The identity and characteristics of the customer.=A0 E.g. a=
 non-profit
>organization may not be subject to a tax, a corporation may remit taxes
>directly instead of having them remitted by the seller, the same good or
>service bought for a business purpose may be taxed differently
>than when bought for personal use.
>
>2.=A0 The nature, type, number and price of the good or
>services being sold.=A0 E.g. >6 donuts are not taxed as food, while
>< 7 donuts are taxed as a snack; items of clothing > $100 are taxed
>as luxury goods, while items < $100 are not; software might
>be taxed differently when bundled with a system versus
>purchased separately.=A0=A0 In general, it is not possible to simply
>use a table of SKU by location by tax authority by percentage.
>
>Milt
>
>-----Original Message-----
>From: David Burdett <[email-masked]>
>To: Ietf Trade WG <[email-masked]>; [email-masked]
<[email-masked]>
>Date: Friday, March 19, 1999 9:07 PM
>Subject: RE: Re OECD technical advisory group on e-commerce and=
 professional
data
>assessmen
>
>
>>A couple of small comments on what I think is an excellent summary ...
>>
>>David
>>
>>Jane says:
>> "how a merchant establishes the location of the customer,
>>particularly in the supply of an intangible product/service delivered
>>electronically" ... "is likely to be beyond the scope and purpose of IOTP
>>??? - or not???=A0 It also poses some complexities, I imagine, in
>>incorporating into IOTP the facility to include different tax rates"
>>
>>Smart Cards could help provide the answer to identifying the location of=
 the
>>customer since they are secure and portable. They could also be used to=
 sign
>>requests for goods to be provided to the Merchant.
>>
>>One possible way IOTP could record multiple tax rates is with an element
>>which looked something like (these are purely illustrative):
>><TaxData Id=3D'M1.1'
>> TaxType=3D'NY State'
>> TaxRate=3D'5%'
>> Amount=3D'30.00'
>> CurrCode=3D'USD' />
>><TaxData Id=3D'M1.2'
>> TaxType=3D'New York City'
>> TaxRate=3D'1%'
>> Amount=3D'6.00'
>> CurrCode=3D'USD' />
>>
>>This idea is that you could have multiple different tax data entries if
>>multiple different taxes applied. IOTP would primarily help by providing a
>>mechanism by which the tax amounts due could be recorded. It would NOT, in
>>my opinion, specify how the taxes due should be calculated.
>>
>>David
>>
>>> ----------
>>> From: [email-masked][SMTP:[email-masked]]
>>> Sent: 16 March 1999 14:38
>>> To: [email-masked]
>>> Subject: Re OECD technical advisory group on e-commerce and
>>> professional data assessmen
>>>
>>> In response to=A0 Neil and David's e-mails on this subject
>>>
>>> Such tax laws on sales as described by David are already in place in=
 many
>>> countries for conventional commerce. This is, in fact exactly what VAT
does
>>> (at least in the EU), merchants are responsible for tax collection and
>>> remission to the tax authorities. As I wrote in an e-mail to the group
last
>>> year, my understanding of the current position on taxation of=
 e-commerce,
is
>>> not that it is necessarily tax free but that governments have pledged=
 not
to
>>> introduce any new forms of taxation. In many cases, where e-commerce
appears
>>> to be tax-free, the more likely situation is that applicable taxes are
simply
>>> not being collected.
>>>
>>> As far as relocation by businesses to low tax /no tax areas are=
 concerned,
it
>>> would appear that the OECD is alert to the possibility of tax=
 competition
>>> between jurisdictions and envisages dealing with this issue in a
variety of
>>> ways that aim to protect countries' existing tax bases from erosion.
Further
>>> consideration is to be given to the OECD Model Tax Convention=A0 and=
 whether
the
>>> existing rules giving rise to a liability to taxation by a non resident
>>> enterprise are applicable to e-commerce; whether new rules are
necessary to
>>> minimise tax avoidance (and to discourage relocation)
>>>
>>> At the OECD Ottawa Conference in 1998, the conference endorsed 5
principles
>>> relating to the future of taxation of e-commerce, namely:
>>>
>>> 1. neutrality,
>>> i.e that taxation of e-commerce should be compatible and equitable with
>>> taxation of conventional commerce; that business decisions should be
motivated
>>> by economic rather than tax considerations
>>>
>>> 2. efficiency
>>> compliance costs should be kept to a minimum
>>>
>>> 3. certainty and simplicity
>>> - so that tax payers will know in advance what their liability will be,
>>> including where and how the tax is to be accounted
>>>
>>> 4. effectiveness and fairness
>>>=A0 - the potential for evasion and avoidance should be minimised, but
>>> counteracting measures should be proportional to the risks involved
>>>
>>> 5. flexibility
>>> - tax systems should be flexible and dynamic to ensure that they keep=
 pace
>>> with technological and commercial developments.
>>>
>>> There were a number of other issues discussed at the conference. This
e-mail
>>> does not attempt to summarise them all, but the following may be=
 relevant
to
>>> IOTP.
>>>
>>> - there is an intention to try to draw non-OECD countries into=
 discussions
on
>>> e-commerce taxation in order to promote global harmony of tax laws and
>>> systems.
>>>
>>> - it is proposed that intangible products' should not be treated as
'goods'
>>> for taxation purposes. I believe there is still some on-going
discussion on
>>> how certain types of intangible products should be classed, i.e. as
services
>>> or as royalties etc , which would affect the method/ type of taxation -
>>> however, this is another story too complicated to go into here.
>>>
>>> - it is also proposed that consumption taxes on e-commerce 'products'
should
>>> be imposed in the jurisdiction in which they are consumed. Although
this is
>>> compatible with some existing principles e.g VAT on services within EU,=
 it
>>> does raise many questions as to how a merchant establishes the location=
 of
the
>>> customer, particularly in the supply of an intangible product/service
>>> delivered electronically.=A0 However, at present, this is likely to be
beyond
>>> the scope and purpose of IOTP ??? - or not???=A0 It also poses some
>>> complexities, I imagine, in incorporating into IOTP the facility to
include
>>> different tax rates, although I have no doubt that this is an=
 unavoidable
>>> issue for the future, not just for accounting purposes but as business
>>> customers may require tax (VAT) receipts.
>>>
>>> - there are also further discussions to take place in relation to what
factors
>>> determine where consumption rakes place and how taxes should be
administered
>>> particularly when the supplier is located outside the relevant tax
>jurisdiction.
>>>
>>> - there is also to be further clarification as to what constitutes
'permanent
>>> establishment' (i.e. the test for liablility to taxation in a=
 jurisdiction
of
>>> the profits of a non resident enterprise or business), in particular in
what
>>> circumstances servers and web sites constitute 'permanent=
 establishment'.
It
>>> is likely that the concept of permanent establishment is not=
 particularly
>>> appropriate as a test in relation to certain types of e-commerce
enterprises,
>>> and that further consideration of alternative rules for the tax=
 liability
of
>>> their profits is needed.
>>>
>>> - tax authorities should improve their service to taxpayers both in
providing
>>> easily accessible information and in the administration and collection
>>> services. Procedures should be simplified and available technology used
>>>
>>> - there should be particular attention paid to SME's, (which are likely=
 to
>>> have little or no experience of the pitfalls of international commerce=
 and
>>> taxation.)
>>>
>>> - avoidance of double taxation or no taxation (and indeed of tax
competition
>>> between jurisdictions)
>>>
>>> - governments should collaborate to detect and deal with tax fraud and
>>> evasion.
>>>
>>> - the OECD encourages consultation with the business and technology
sectors
>>> and to have regard, where possible to solutions developed by them.
>>>
>>> On the technological side, this may result (my guess) in the OECD and
>>> governments looking for solutions to provide:
>>>
>>> - means of identifying (including location) the parties to an e-commerce
>>> transaction. As far as businesses are concerned, this may be dealt with=
 in
>>> part by requirements as to registration of the business with tax
authorities
>>> or through Internet Protocol number allocation records; and the=
 provision
on
>>> relevant information (such as registered address and VAT number etc.. )=
 on
the
>>> web site. There is an overlap here with other aspects of e-commerce
associated
>>> with consumer protection laws, e.g. the European Commission is=
 considering
a
>>> draft directive which covers this.=A0 Identification of the consumer and=
 his
>>> location poses more difficulties, particularly if the onus is to be=
 placed
on
>>> the merchant to record this information.
>>>
>>> - alternative forms of audit trails specific to e-commerce
>>>=A0 Basically the primary duty to account to the relevant tax authority=
 lies
with
>>> the tax payer. However, authorities traditionally use secondary sources=
 of
>>> information (sometimes from third parties) to verify the tax payers
accounts,
>>> such as bank statements, delivery records, purchase/ sales records which
>>> create an audit trail and can be cross-checked etc.. In e- commerce
>>> transactions, particularly those relatiing to intangibles the trail or
indeed
>>> any record at all may be eliminated (disintermediation) Naturally, tax
>>> authorities are anxious to detect or establish new forms of audit=
 trails,
>>> relevant to e-commerce.=A0 In doing so the 5 basic principles (set out
above)
>>> should apply. It is also my assumption that other conventional=
 principles
will
>>> apply, such as privacy/data protection and banking confidentiality.
>>>
>>> - secure, tamper-evident electronic means of record keeping and=
 accounting
to
>>> tax authorities (including the filing of required documents with tax
>>> authorities and collection/payment)
>>>
>>>=A0 Almost all jurisdiction already have procedures for obtaining=
 information
>>> relevant to tax enforcement, usually a duty to disclose is imposed on=
 the
>>> taxpayer and if he fails to comply, the tax due will simply be assessed=
 by
the
>>> authority, plus penalties, These procedures are usually supplemented by
powers
>>> of search and seizure. In such circumstances, the taxpayer generally=
 finds
it
>>> cost effective to provide the relevant disclosure. Difficulties may=
 arise
>>> where the information is either held abroad and therefore beyond the
>>> jurisdiction of the tax authority, or held in an electronic form which=
 is
not
>>> easily accessible or reliable as to its integrity.=A0 In my view the=
 answer
to
>>> this is part technological and part legal.
>>>
>>> In terms of the technological solution IOTP potentially can play a
valuable
>>> role. By that I DO NOT mean as a tax authority agent or spy; I mean by
>>> providing an essential service to merchants who already have duties and
>>> liabilities to their tax authority. Inevitably tax authorities will
require
>>> merchants involved in e-commerce to maintain their electronic records=
 and
>>> accounting procedures in a secure and tamper evident manner. One could
>>> envisage that tax authorities might specify which protocols or standards
>>> fulfilled its requirements in this regard. This is not new; very often=
 in
>>> conventional commerce there may be requirements as to how/what records
should
>>> be kept and/or how accounts should be presented. It has always been my
view
>>> that meeting these requirements is likely greatly to enhance IOTP's
>>> attractiveness to merchants - 'peace of mind' factor.
>>>
>>> The legal contribution in the equation, in my view, is to ensure=
 existing
laws
>>> as to inspection /disclosure are effective or amended in relation to
>>> electronic records and are enforceable beyond jusidictional boundaries.=
 I
am
>>> not a great fan of mandatory key escrow proposals; I actually see no
reason
>>> that the penalties for refusal to allow proper legal access to encrypted
>>> stored data should be materially different to those available for
conventional
>>> forms of non-disclosure.
>>>
>>> Again, I should reiterate that this does not attempt to be a=
 comprehensive
>>> discussion of all the issues raised at the Ottawa Conference, nor all=
 the
ways
>>> in which technology has a role to play. No doubt David will be able to
>>> feedback valuable information about that after his first meeting in=
 April.
It
>>> is my view that developments and solutions for e-commerce are likely to
>>> require multi-disciplinary imput, most notably from technological,
business
>>> and legal sources.
>>>
>>> I also do not pretend that I have been able to track down proposed legal
>>> developments in more than a few jurisdictions, but it would appear that
the
>>> USA and the European Union are committed to following the OECD=
 guidelines
and
>>> recommendations. It has to be remembered that a resolution of taxation
issues
>>> is necessary for the removal of one of the barriers to successful
e-commerce
>>> for the future. As far as I can tell 'bit tax' is no longer being
considered
>>> as an option; the trend is to apply conventional forms of taxation,
collection
>>> and enforcement as far as possible to e-commerce. New rules may have to=
 be
>>> devised to deal with the electronic supply of intangibles to ensure
compliance
>>> with taxation laws; also in relation to liability to taxation to their
>>> profits. Amendments to laws and tax treaties may also be needed to=
 provide
>>> greater uniformity of taxation globally, including in relation to
>>> international co-operation in investigation and enforcement.=A0 No doubt=
 the
>>> OECD will ask the technology sector to provide solutions which will be
>>> attractive to business enterprises and make the OECD goals achievable.
>>>
>>> Jane Hill
>>> -----------------------------------------------------------------------
>>> Message addressed to: [email-masked]
>>> Archive available at:
<http://www.elistx.com/>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/>http://www.elistx.com/archives/i
etf-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/>http://www.elistx.com/archives/i
etf-trade/
>To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
>body to: [email-masked]
>=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Kaye Caldwell - (831) 479-8743 - Fax: (831) 479-9247 - E-mail:
[email-masked]
Editor, Software Industry Issues (www.SoftwareIndustry.org/issues/)
President & Policy Director, Silicon Valley Software Industry Coalition
(www.SoftwareIndustry.org/coalition/)
Policy Director, CommerceNet (www.commerce.net/work/appc.html)
President, Computer Software Industry Association
(www.SoftwareIndustry.org/csia/)
Legislative Director, Software Forum  (www.SoftwareForum.org/)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
-----------------------------------------------------------------------
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: David Burdett <[email-masked]>,  Ietf Trade WG <[email-masked]>, [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
Subject: Re: Re OECD technical advisory group on e-commerce and professional data assessmen
Date: Sat, 20 Mar 1999 14:11:43 -0500
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David,

I'm not sure how smart cards would help in identifying
the location of the customer?  If the tax jurisdictions are determined
by the point of use or consumption, then what is needed is the
user's current location, not a place of residence.  However,
both current location and residence may be needed if for example,
the authorities treat downloading a video as an ephemeral entertainment
and taxed at the current location, while treating downloading of
software as a permanent acquisition and subject to use tax at the
place of residence.

If the location can be established, then location can be mapped to
the various federal, state, regional, county, and local tax authorities,
taking into account various tax incentives and abatements that the
higher levels may have granted at the lower levels, e.g. enterprise
zones.

Whether a given tax by a given authority will apply at a given
schedule rate may depend on:

1.  The identity and characteristics of the customer.  E.g. a non-profit
organization may not be subject to a tax, a corporation may remit taxes
directly instead of having them remitted by the seller, the same good or
service bought for a business purpose may be taxed differently
than when bought for personal use.

2.  The nature, type, number and price of the good or
services being sold.  E.g. >6 donuts are not taxed as food, while
< 7 donuts are taxed as a snack; items of clothing > $100 are taxed
as luxury goods, while items < $100 are not; software might
be taxed differently when bundled with a system versus
purchased separately.   In general, it is not possible to simply
use a table of SKU by location by tax authority by percentage.

Milt

-----Original Message-----
From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>; [email-masked] <[email-masked]>
Date: Friday, March 19, 1999 9:07 PM
Subject: RE: Re OECD technical advisory group on e-commerce and professional data
assessmen

>A couple of small comments on what I think is an excellent summary ...
>
>David
>
>Jane says:
> "how a merchant establishes the location of the customer,
>particularly in the supply of an intangible product/service delivered
>electronically" ... "is likely to be beyond the scope and purpose of IOTP
>??? - or not???  It also poses some complexities, I imagine, in
>incorporating into IOTP the facility to include different tax rates"
>
>Smart Cards could help provide the answer to identifying the location of the
>customer since they are secure and portable. They could also be used to sign
>requests for goods to be provided to the Merchant.
>
>One possible way IOTP could record multiple tax rates is with an element
>which looked something like (these are purely illustrative):
><TaxData Id='M1.1'
> TaxType='NY State'
> TaxRate='5%'
> Amount='30.00'
> CurrCode='USD' />
><TaxData Id='M1.2'
> TaxType='New York City'
> TaxRate='1%'
> Amount='6.00'
> CurrCode='USD' />
>
>This idea is that you could have multiple different tax data entries if
>multiple different taxes applied. IOTP would primarily help by providing a
>mechanism by which the tax amounts due could be recorded. It would NOT, in
>my opinion, specify how the taxes due should be calculated.
>
>David
>
>> ----------
>> From: [email-masked][SMTP:[email-masked]]
>> Sent: 16 March 1999 14:38
>> To: [email-masked]
>> Subject: Re OECD technical advisory group on e-commerce and
>> professional data assessmen
>>
>> In response to  Neil and David's e-mails on this subject
>>
>> Such tax laws on sales as described by David are already in place in many
>> countries for conventional commerce. This is, in fact exactly what VAT does
>> (at least in the EU), merchants are responsible for tax collection and
>> remission to the tax authorities. As I wrote in an e-mail to the group last
>> year, my understanding of the current position on taxation of e-commerce, is
>> not that it is necessarily tax free but that governments have pledged not to
>> introduce any new forms of taxation. In many cases, where e-commerce appears
>> to be tax-free, the more likely situation is that applicable taxes are simply
>> not being collected.
>>
>> As far as relocation by businesses to low tax /no tax areas are concerned, it
>> would appear that the OECD is alert to the possibility of tax competition
>> between jurisdictions and envisages dealing with this issue in a variety of
>> ways that aim to protect countries' existing tax bases from erosion. Further
>> consideration is to be given to the OECD Model Tax Convention  and whether the
>> existing rules giving rise to a liability to taxation by a non resident
>> enterprise are applicable to e-commerce; whether new rules are necessary to
>> minimise tax avoidance (and to discourage relocation)
>>
>> At the OECD Ottawa Conference in 1998, the conference endorsed 5 principles
>> relating to the future of taxation of e-commerce, namely:
>>
>> 1. neutrality,
>> i.e that taxation of e-commerce should be compatible and equitable with
>> taxation of conventional commerce; that business decisions should be motivated
>> by economic rather than tax considerations
>>
>> 2. efficiency
>> compliance costs should be kept to a minimum
>>
>> 3. certainty and simplicity
>> - so that tax payers will know in advance what their liability will be,
>> including where and how the tax is to be accounted
>>
>> 4. effectiveness and fairness
>>  - the potential for evasion and avoidance should be minimised, but
>> counteracting measures should be proportional to the risks involved
>>
>> 5. flexibility
>> - tax systems should be flexible and dynamic to ensure that they keep pace
>> with technological and commercial developments.
>>
>> There were a number of other issues discussed at the conference. This e-mail
>> does not attempt to summarise them all, but the following may be relevant to
>> IOTP.
>>
>> - there is an intention to try to draw non-OECD countries into discussions on
>> e-commerce taxation in order to promote global harmony of tax laws and
>> systems.
>>
>> - it is proposed that intangible products' should not be treated as 'goods'
>> for taxation purposes. I believe there is still some on-going discussion on
>> how certain types of intangible products should be classed, i.e. as services
>> or as royalties etc , which would affect the method/ type of taxation -
>> however, this is another story too complicated to go into here.
>>
>> - it is also proposed that consumption taxes on e-commerce 'products' should
>> be imposed in the jurisdiction in which they are consumed. Although this is
>> compatible with some existing principles e.g VAT on services within EU, it
>> does raise many questions as to how a merchant establishes the location of the
>> customer, particularly in the supply of an intangible product/service
>> delivered electronically.  However, at present, this is likely to be beyond
>> the scope and purpose of IOTP ??? - or not???  It also poses some
>> complexities, I imagine, in incorporating into IOTP the facility to include
>> different tax rates, although I have no doubt that this is an unavoidable
>> issue for the future, not just for accounting purposes but as business
>> customers may require tax (VAT) receipts.
>>
>> - there are also further discussions to take place in relation to what factors
>> determine where consumption rakes place and how taxes should be administered
>> particularly when the supplier is located outside the relevant tax
jurisdiction.
>>
>> - there is also to be further clarification as to what constitutes 'permanent
>> establishment' (i.e. the test for liablility to taxation in a jurisdiction of
>> the profits of a non resident enterprise or business), in particular in what
>> circumstances servers and web sites constitute 'permanent establishment'. It
>> is likely that the concept of permanent establishment is not particularly
>> appropriate as a test in relation to certain types of e-commerce enterprises,
>> and that further consideration of alternative rules for the tax liability of
>> their profits is needed.
>>
>> - tax authorities should improve their service to taxpayers both in providing
>> easily accessible information and in the administration and collection
>> services. Procedures should be simplified and available technology used
>>
>> - there should be particular attention paid to SME's, (which are likely to
>> have little or no experience of the pitfalls of international commerce and
>> taxation.)
>>
>> - avoidance of double taxation or no taxation (and indeed of tax competition
>> between jurisdictions)
>>
>> - governments should collaborate to detect and deal with tax fraud and
>> evasion.
>>
>> - the OECD encourages consultation with the business and technology sectors
>> and to have regard, where possible to solutions developed by them.
>>
>> On the technological side, this may result (my guess) in the OECD and
>> governments looking for solutions to provide:
>>
>> - means of identifying (including location) the parties to an e-commerce
>> transaction. As far as businesses are concerned, this may be dealt with in
>> part by requirements as to registration of the business with tax authorities
>> or through Internet Protocol number allocation records; and the provision on
>> relevant information (such as registered address and VAT number etc.. ) on the
>> web site. There is an overlap here with other aspects of e-commerce associated
>> with consumer protection laws, e.g. the European Commission is considering a
>> draft directive which covers this.  Identification of the consumer and his
>> location poses more difficulties, particularly if the onus is to be placed on
>> the merchant to record this information.
>>
>> - alternative forms of audit trails specific to e-commerce
>>  Basically the primary duty to account to the relevant tax authority lies with
>> the tax payer. However, authorities traditionally use secondary sources of
>> information (sometimes from third parties) to verify the tax payers accounts,
>> such as bank statements, delivery records, purchase/ sales records which
>> create an audit trail and can be cross-checked etc.. In e- commerce
>> transactions, particularly those relatiing to intangibles the trail or indeed
>> any record at all may be eliminated (disintermediation) Naturally, tax
>> authorities are anxious to detect or establish new forms of audit trails,
>> relevant to e-commerce.  In doing so the 5 basic principles (set out above)
>> should apply. It is also my assumption that other conventional principles will
>> apply, such as privacy/data protection and banking confidentiality.
>>
>> - secure, tamper-evident electronic means of record keeping and accounting to
>> tax authorities (including the filing of required documents with tax
>> authorities and collection/payment)
>>
>>  Almost all jurisdiction already have procedures for obtaining information
>> relevant to tax enforcement, usually a duty to disclose is imposed on the
>> taxpayer and if he fails to comply, the tax due will simply be assessed by the
>> authority, plus penalties, These procedures are usually supplemented by powers
>> of search and seizure. In such circumstances, the taxpayer generally finds it
>> cost effective to provide the relevant disclosure. Difficulties may arise
>> where the information is either held abroad and therefore beyond the
>> jurisdiction of the tax authority, or held in an electronic form which is not
>> easily accessible or reliable as to its integrity.  In my view the answer to
>> this is part technological and part legal.
>>
>> In terms of the technological solution IOTP potentially can play a valuable
>> role. By that I DO NOT mean as a tax authority agent or spy; I mean by
>> providing an essential service to merchants who already have duties and
>> liabilities to their tax authority. Inevitably tax authorities will require
>> merchants involved in e-commerce to maintain their electronic records and
>> accounting procedures in a secure and tamper evident manner. One could
>> envisage that tax authorities might specify which protocols or standards
>> fulfilled its requirements in this regard. This is not new; very often in
>> conventional commerce there may be requirements as to how/what records should
>> be kept and/or how accounts should be presented. It has always been my view
>> that meeting these requirements is likely greatly to enhance IOTP's
>> attractiveness to merchants - 'peace of mind' factor.
>>
>> The legal contribution in the equation, in my view, is to ensure existing laws
>> as to inspection /disclosure are effective or amended in relation to
>> electronic records and are enforceable beyond jusidictional boundaries. I am
>> not a great fan of mandatory key escrow proposals; I actually see no reason
>> that the penalties for refusal to allow proper legal access to encrypted
>> stored data should be materially different to those available for conventional
>> forms of non-disclosure.
>>
>> Again, I should reiterate that this does not attempt to be a comprehensive
>> discussion of all the issues raised at the Ottawa Conference, nor all the ways
>> in which technology has a role to play. No doubt David will be able to
>> feedback valuable information about that after his first meeting in April. It
>> is my view that developments and solutions for e-commerce are likely to
>> require multi-disciplinary imput, most notably from technological, business
>> and legal sources.
>>
>> I also do not pretend that I have been able to track down proposed legal
>> developments in more than a few jurisdictions, but it would appear that the
>> USA and the European Union are committed to following the OECD guidelines and
>> recommendations. It has to be remembered that a resolution of taxation issues
>> is necessary for the removal of one of the barriers to successful e-commerce
>> for the future. As far as I can tell 'bit tax' is no longer being considered
>> as an option; the trend is to apply conventional forms of taxation, collection
>> and enforcement as far as possible to e-commerce. New rules may have to be
>> devised to deal with the electronic supply of intangibles to ensure compliance
>> with taxation laws; also in relation to liability to taxation to their
>> profits. Amendments to laws and tax treaties may also be needed to provide
>> greater uniformity of taxation globally, including in relation to
>> international co-operation in investigation and enforcement.  No doubt the
>> OECD will ask the technology sector to provide solutions which will be
>> attractive to business enterprises and make the OECD goals achievable.
>>
>> Jane Hill
>> -----------------------------------------------------------------------
>> 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]>, [email-masked]
Subject: RE: Re OECD technical advisory group on e-commerce and profession al data assessmen
Date: Sat, 20 Mar 1999 01:57:48 -0000
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

A couple of small comments on what I think is an excellent summary ...

David

Jane says:
	"how a merchant establishes the location of the customer,
particularly in the supply of an intangible product/service delivered
electronically" ... "is likely to be beyond the scope and purpose of IOTP
??? - or not???  It also poses some complexities, I imagine, in
incorporating into IOTP the facility to include different tax rates"

Smart Cards could help provide the answer to identifying the location of the
customer since they are secure and portable. They could also be used to sign
requests for goods to be provided to the Merchant.

One possible way IOTP could record multiple tax rates is with an element
which looked something like (these are purely illustrative):
<TaxData Id='M1.1'
	TaxType='NY State'
	TaxRate='5%'
	Amount='30.00'
	CurrCode='USD' />
<TaxData Id='M1.2'
	TaxType='New York City'
	TaxRate='1%'
	Amount='6.00'
	CurrCode='USD' />

This idea is that you could have multiple different tax data entries if
multiple different taxes applied. IOTP would primarily help by providing a
mechanism by which the tax amounts due could be recorded. It would NOT, in
my opinion, specify how the taxes due should be calculated.

David

> ----------
> From: 	[email-masked][SMTP:[email-masked]]
> Sent: 	16 March 1999 14:38
> To: 	[email-masked]
> Subject: 	Re OECD technical advisory group on e-commerce and
> professional data assessmen
> 
> In response to  Neil and David's e-mails on this subject
> 
> Such tax laws on sales as described by David are already in place in many
> countries for conventional commerce. This is, in fact exactly what VAT
> does
> (at least in the EU), merchants are responsible for tax collection and
> remission to the tax authorities. As I wrote in an e-mail to the group
> last
> year, my understanding of the current position on taxation of e-commerce,
> is
> not that it is necessarily tax free but that governments have pledged not
> to
> introduce any new forms of taxation. In many cases, where e-commerce
> appears
> to be tax-free, the more likely situation is that applicable taxes are
> simply
> not being collected. 
> 
> As far as relocation by businesses to low tax /no tax areas are concerned,
> it
> would appear that the OECD is alert to the possibility of tax competition
> between jurisdictions and envisages dealing with this issue in a variety
> of
> ways that aim to protect countries' existing tax bases from erosion.
> Further
> consideration is to be given to the OECD Model Tax Convention  and whether
> the
> existing rules giving rise to a liability to taxation by a non resident
> enterprise are applicable to e-commerce; whether new rules are necessary
> to
> minimise tax avoidance (and to discourage relocation)
> 
> At the OECD Ottawa Conference in 1998, the conference endorsed 5
> principles
> relating to the future of taxation of e-commerce, namely:
> 
> 1. neutrality, 
> i.e that taxation of e-commerce should be compatible and equitable with
> taxation of conventional commerce; that business decisions should be
> motivated
> by economic rather than tax considerations 
> 
> 2. efficiency
> compliance costs should be kept to a minimum
> 
> 3. certainty and simplicity
> - so that tax payers will know in advance what their liability will be,
> including where and how the tax is to be accounted
> 
> 4. effectiveness and fairness
>  - the potential for evasion and avoidance should be minimised, but
> counteracting measures should be proportional to the risks involved
> 
> 5. flexibility
> - tax systems should be flexible and dynamic to ensure that they keep pace
> with technological and commercial developments.
> 
> There were a number of other issues discussed at the conference. This
> e-mail
> does not attempt to summarise them all, but the following may be relevant
> to
> IOTP.
> 
> - there is an intention to try to draw non-OECD countries into discussions
> on
> e-commerce taxation in order to promote global harmony of tax laws and
> systems.
> 
> - it is proposed that intangible products' should not be treated as
> 'goods'
> for taxation purposes. I believe there is still some on-going discussion
> on
> how certain types of intangible products should be classed, i.e. as
> services
> or as royalties etc , which would affect the method/ type of taxation -
> however, this is another story too complicated to go into here. 
> 
> - it is also proposed that consumption taxes on e-commerce 'products'
> should
> be imposed in the jurisdiction in which they are consumed. Although this
> is
> compatible with some existing principles e.g VAT on services within EU, it
> does raise many questions as to how a merchant establishes the location of
> the
> customer, particularly in the supply of an intangible product/service
> delivered electronically.  However, at present, this is likely to be
> beyond
> the scope and purpose of IOTP ??? - or not???  It also poses some
> complexities, I imagine, in incorporating into IOTP the facility to
> include
> different tax rates, although I have no doubt that this is an unavoidable
> issue for the future, not just for accounting purposes but as business
> customers may require tax (VAT) receipts. 
> 
> - there are also further discussions to take place in relation to what
> factors
> determine where consumption rakes place and how taxes should be
> administered
> particularly when the supplier is located outside the relevant tax
> jurisdiction.
> 
> - there is also to be further clarification as to what constitutes
> 'permanent
> establishment' (i.e. the test for liablility to taxation in a jurisdiction
> of
> the profits of a non resident enterprise or business), in particular in
> what
> circumstances servers and web sites constitute 'permanent establishment'.
> It
> is likely that the concept of permanent establishment is not particularly
> appropriate as a test in relation to certain types of e-commerce
> enterprises,
> and that further consideration of alternative rules for the tax liability
> of
> their profits is needed.
> 
> - tax authorities should improve their service to taxpayers both in
> providing
> easily accessible information and in the administration and collection
> services. Procedures should be simplified and available technology used 
> 
> - there should be particular attention paid to SME's, (which are likely to
> have little or no experience of the pitfalls of international commerce and
> taxation.)
> 
> - avoidance of double taxation or no taxation (and indeed of tax
> competition
> between jurisdictions)
> 
> - governments should collaborate to detect and deal with tax fraud and
> evasion.
> 
> - the OECD encourages consultation with the business and technology
> sectors
> and to have regard, where possible to solutions developed by them.
> 
> On the technological side, this may result (my guess) in the OECD and
> governments looking for solutions to provide:
> 
> - means of identifying (including location) the parties to an e-commerce
> transaction. As far as businesses are concerned, this may be dealt with in
> part by requirements as to registration of the business with tax
> authorities
> or through Internet Protocol number allocation records; and the provision
> on
> relevant information (such as registered address and VAT number etc.. ) on
> the
> web site. There is an overlap here with other aspects of e-commerce
> associated
> with consumer protection laws, e.g. the European Commission is considering
> a
> draft directive which covers this.  Identification of the consumer and his
> location poses more difficulties, particularly if the onus is to be placed
> on
> the merchant to record this information.
> 
> - alternative forms of audit trails specific to e-commerce 
>  Basically the primary duty to account to the relevant tax authority lies
> with
> the tax payer. However, authorities traditionally use secondary sources of
> information (sometimes from third parties) to verify the tax payers
> accounts,
> such as bank statements, delivery records, purchase/ sales records which
> create an audit trail and can be cross-checked etc.. In e- commerce
> transactions, particularly those relatiing to intangibles the trail or
> indeed
> any record at all may be eliminated (disintermediation) Naturally, tax
> authorities are anxious to detect or establish new forms of audit trails,
> relevant to e-commerce.  In doing so the 5 basic principles (set out
> above)
> should apply. It is also my assumption that other conventional principles
> will
> apply, such as privacy/data protection and banking confidentiality.
> 
> - secure, tamper -evident electronic means of record keeping and
> accounting to
> tax authorities (including the filing of required documents with tax
> authorities and collection/payment)
> 
>  Almost all jurisdiction already have procedures for obtaining information
> relevant to tax enforcement, usually a duty to disclose is imposed on the
> taxpayer and if he fails to comply, the tax due will simply be assessed by
> the
> authority, plus penalties, These procedures are usually supplemented by
> powers
> of search and seizure. In such circumstances, the taxpayer generally finds
> it
> cost effective to provide the relevant disclosure. Difficulties may arise
> where the information is either held abroad and therefore beyond the
> jurisdiction of the tax authority, or held in an electronic form which is
> not
> easily accessible or reliable as to its integrity.  In my view the answer
> to
> this is part technological and part legal.   
> 
> In terms of the technological solution IOTP potentially can play a
> valuable
> role. By that I DO NOT mean as a tax authority agent or spy; I mean by
> providing an essential service to merchants who already have duties and
> liabilities to their tax authority. Inevitably tax authorities will
> require
> merchants involved in e-commerce to maintain their electronic records and
> accounting procedures in a secure and tamper evident manner. One could
> envisage that tax authorities might specify which protocols or standards
> fulfilled its requirements in this regard. This is not new; very often in
> conventional commerce there may be requirements as to how/what records
> should
> be kept and/or how accounts should be presented. It has always been my
> view
> that meeting these requirements is likely greatly to enhance IOTP's
> attractiveness to merchants - 'peace of mind' factor.
> 
> The legal contribution in the equation, in my view, is to ensure existing
> laws
> as to inspection /disclosure are effective or amended in relation to
> electronic records and are enforceable beyond jusidictional boundaries. I
> am
> not a great fan of mandatory key escrow proposals; I actually see no
> reason
> that the penalties for refusal to allow proper legal access to encrypted
> stored data should be materially different to those available for
> conventional
> forms of non-disclosure.
> 
> Again, I should reiterate that this does not attempt to be a comprehensive
> discussion of all the issues raised at the Ottawa Conference, nor all the
> ways
> in which technology has a role to play. No doubt David will be able to
> feedback valuable information about that after his first meeting in April.
> It
> is my view that developments and solutions for e-commerce are likely to
> require multi-disciplinary imput, most notably from technological,
> business
> and legal sources.
> 
> I also do not pretend that I have been able to track down proposed legal
> developments in more than a few jurisdictions, but it would appear that
> the
> USA and the European Union are committed to following the OECD guidelines
> and
> recommendations. It has to be remembered that a resolution of taxation
> issues
> is necessary for the removal of one of the barriers to successful
> e-commerce
> for the future. As far as I can tell 'bit tax' is no longer being
> considered
> as an option; the trend is to apply conventional forms of taxation,
> collection
> and enforcement as far as possible to e-commerce. New rules may have to be
> devised to deal with the electronic supply of intangibles to ensure
> compliance
> with taxation laws; also in relation to liability to taxation to their
> profits. Amendments to laws and tax treaties may also be needed to provide
> greater uniformity of taxation globally, including in relation to
> international co-operation in investigation and enforcement.  No doubt the
> OECD will ask the technology sector to provide solutions which will be
> attractive to business enterprises and make the OECD goals achievable.
> 
> Jane Hill
> -----------------------------------------------------------------------
> 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: Tom Arnold <[email-masked]>
cc: "[email-masked]" <[email-masked]>
Subject: Re: Country Codes in IOTP 
Date: Thu, 18 Mar 1999 01:42:49 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Doesn't it actually specify 2 and 3 letter alpha codes as well as the
three digit United Nations country number?

I agree that we should use the two letter country code but I think the
codes should be iso3166-a2, iso3166-a3, and iso3166-n.  On the other
hand there is probably less reason for custom countries than there
is for custom currencies (frequrent flyer miles, etc.)...

Thanks,
Donald

From:  Tom Arnold <[email-masked]>
Message-Id:  <[email-masked]>
X-Sender:  [email-masked]
Date:  Sun, 14 Mar 1999 15:30:20 -0800
To:  "[email-masked]" <[email-masked]>

>Sorry to send this again, but I blew the original version. ISO 3166-3:1999
>specifies both two character alphanumeric and numeric country codes. My
>actual question was related to the thread of the ISO 4217 discussion on the
>list in asking that the IOTP specification define country codes as well as
>currency codes. Further to suggest that the same specification be used on
>the country code as was discribed on the currency code. This would be
>country code type "iso3166-3:1999-a" for the alphanumeric version, and
>"iso3166-3:1999-a" for the numeric version.
>
>
>>Date: Sun, 14 Mar 1999 15:23:03 -0800
>>To: "[email-masked]" <[email-masked]>
>>From: Tom Arnold <[email-masked]>
>>Subject: Country Codes in IOTP
>>In-Reply-To: <[email-masked]>
>>References: <[email-masked]>
><[email-masked]>
>>
>>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?
>
>Tom Arnold
>Vice President of Engineering
>Chief Technical Officer
>CyberSource Corporation
>[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: [email-masked]
To: [email-masked]
Date: Thu, 18 Mar 1999 00:49:55 -0500
Subject: Main slides for TRADE WG meeting at IETF Minneapolis Meeting
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

--0__=JF7DnWGX0k0EaGhAXmjk6MQzEyH5N5uHWUkXXmv92OZoBiWZbcU4Wsdo
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Here are my main slides from the TRADE working group meeting today.

Thanks,
Donald

 (See attached file: trade.ppt)
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

--0__=JF7DnWGX0k0EaGhAXmjk6MQzEyH5N5uHWUkXXmv92OZoBiWZbcU4Wsdo
Content-type: application/octet-stream; 
	name="trade.ppt"
Content-Disposition: attachment; filename="trade.ppt"
Content-transfer-encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAIwAAAAAAAAAA
EAAAJgAAAAEAAAD+////AAAAACQAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
AAAAAAAAAAAAAAAA

--0__=JF7DnWGX0k0EaGhAXmjk6MQzEyH5N5uHWUkXXmv92OZoBiWZbcU4Wsdo--

-----------------------------------------------------------------------
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, 17 Mar 1999 22:16:20 +0000
To: "Donald E. Eastlake 3rd" <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: RE: Capability detection (was: "Wallet" Detection)
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

>Subject: Re: Capability detectio9n (was: "Wallet" Detection)
>Author:  "Donald E. Eastlake 3rd" [SMTP:[email-masked]] at Internet
>Date:    1999-03-17 02:55
>
>
>"conneg" seems to be primarily concerned with future development in 
>how to negotiate the form of delivered information, not its type.
>As such, I don't see how it is relevant to designing a workable technique 
>for near term implementation.  Even if a new standards track document 
>popped out soon, it could be long time before it is ceployed.

It is true that the primary focus of 'conneg' has been media features, of
which MIME content-type is but one aspect.  I was reacting to a posting
which I understood to imply a way of determining whether a particular MIME
type was acceptable to a particular recipient.

Standards track documents covering feature registration and composing
syntax have been published (just).  I am proposing a feature tag
registration for MIME content-type at this week's WG meeting.  I accept
that maybe it's overkill for your purpose, but felt it worth pointing out.

Use of the basic feature description syntax is not dependent upon
deployment of other services, any more than, say, MIME or XML.  It's a way
of describing certain things.

>"rescap" doesn't seem to be on the IETF web pages right now.

It is still at the pre-WG stage.  So I guess deployment would be a problem
here, even if it were appropriate to your requirements.

#g

------------
Graham Klyne
([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: Graham Klyne <[email-masked]>,  "Donald E. Eastlake 3rd" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: Capability detection (was: "Wallet" Detection)
Date: Wed, 17 Mar 1999 11:46:00 -0500
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I think what was intended was something like the following:

If the following short script is included in any form that a merchant 
sends to a consumer, when the form returns it may then also include a 
setting that shows the presence of 'application/iotp' MIME handling.

!---------------------------------------
 <SCRIPT LANGUAGE=JAVASCRIPT>
 <!-- hide it
 if (navigator.appName=="netscape") {  // wise precaution
   if (navigator.mimeTypes["application/iotp"]) {
     document.write("<INPUT TYPE=HIDDEN NAME='iotp' VALUE='y'>")
     }
   else {
     document.write("<INPUT TYPE=HIDDEN NAME='iotp' VALUE='n'>")
     }
   }
 // end and hide -->
 </SCRIPT>
!---------------------------------------

Note that this only works for Netscape browsers past version 3 with
JavaScript 
enabled. However, it should not interfere with any other techniques that
might 
be used in other browsers. It should also not interfere with any other 
e-commerce system detection techniques.

Note that the script will return either a definitive 'y' or 'n' - if the 
script does not run, then there is no setting returned at all. 

I've been looking for a succint solution for the other major browser for
about 
15 months now, and I have yet to see anything that does the job. Is it
really 
that hard to do in MSIE? 

...Chris Smith
   Royal Bank
   416.348.6090

______________________________ Reply Separator
_________________________________
Subject: Re: Capability detectio9n (was: "Wallet" Detection)
Author:  "Donald E. Eastlake 3rd" [SMTP:[email-masked]] at Internet
Date:    1999-03-17 02:55

"conneg" seems to be primarily concerned with future development in 
how to negotiate the form of delivered information, not its type.
As such, I don't see how it is relevant to designing a workable technique 
for near term implementation.  Even if a new standards track document 
popped out soon, it could be long time before it is ceployed.

"rescap" doesn't seem to be on the IETF web pages right now.

Thanks,
Donald

From:  Graham Klyne <[email-masked]>
Message-Id:  <[email-masked]> 
X-Sender:  [email-masked]
Date:  Tue, 16 Mar 1999 21:47:10 +0000
To:  "Donald E. Eastlake 3rd" <[email-masked]> 
Cc:  [email-masked]

>At 11:37 14/03/99 -0500, Donald E. Eastlake 3rd wrote: 
>>
>>For the Internet Open Trading Protocol and similar protocols operating 
>>via HTTP, web servers are frequently faced with the problem of 
>>determining whether software to handle the protocol they wish to use 
>>is installed at the user's browser/machine.  This frequently means 
>>finding out if a particular MIME type, such as application/iotp, is 
>>being handled.
>
>I would suggest that the work of the 'conneg' group might be surveyed for 
>possibly useful components (including some recent I-D submissions).
>
>Also, the 'rescap' group's work might prove to have some relevance. 
>
>#g
>
>------------
>Graham Klyne
>([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]
-----------------------------------------------------------------------
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 Architecture ver. 1.0.1
Date: Wed, 17 Mar 1999 03:48:59 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

----Next_Part(Tue_Mar__9_12:28:23_1999_809)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Here is the latest version of the Architecture and Payment API
document in MS-word 97 format.  I believe this document should
eventually be issued as an Information RFC.  It needs to be
IETF'ized to do that...

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

----Next_Part(Tue_Mar__9_12:28:23_1999_809)--
Content-Type: Application/Octet-Stream
Content-Description: iotpar101current.zip
Content-Disposition: attachment; filename=iotpar101current.zip
Content-Transfer-Encoding: base64

----Next_Part(Tue_Mar__9_12:28:23_1999_809)----

------- End of Forwarded Message

-----------------------------------------------------------------------
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: Ian King <[email-masked]>
To: "'Donald E. Eastlake 3rd '" <[email-masked]>,  'Graham Klyne ' <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>
Subject: RE: Capability detectio9n (was: "Wallet" Detection) 
Date: Wed, 17 Mar 1999 09:34:26 -0800
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

RESCAP was a BOF on Monday.  While I did not attend, the title is suggestive
of a solution for this problem space.  

The problem of doing things in a "standards way" is that yes, it takes time.
However, the ultimate win is usually worth it, in terms of acceptance and
interoperability.  :-) And, while this may be a piece that will make IOTP
better (although I can't see that it's essential), I'd still suggest that a
"general" solution to this class of problem is out of scope for the group.  

Ian King <[email-masked]>
Internet Bill Delivery & Payment
MICROSOFT CORPORATION

-----Original Message-----
From: Donald E. Eastlake 3rd
To: Graham Klyne
Cc: [email-masked]
Sent: 3/16/99 11:55 PM
Subject: Re: Capability detectio9n (was: "Wallet" Detection) 

"conneg" seems to be primarily concerned with future development in
how to negotiate the form of delivered information, not its type.
As such, I don't see how it is relevant to designing a workable
technique
for near term implementation.  Even if a new standards track document
popped out soon, it could be long time before it is ceployed.

"rescap" doesn't seem to be on the IETF web pages right now.

Thanks,
Donald

From:  Graham Klyne <[email-masked]>
Message-Id:  <[email-masked]>
X-Sender:  [email-masked]
Date:  Tue, 16 Mar 1999 21:47:10 +0000
To:  "Donald E. Eastlake 3rd" <[email-masked]>
Cc:  [email-masked]

>At 11:37 14/03/99 -0500, Donald E. Eastlake 3rd wrote:
>>
>>For the Internet Open Trading Protocol and similar protocols operating
>>via HTTP, web servers are frequently faced with the problem of
>>determining whether software to handle the protocol they wish to use
>>is installed at the user's browser/machine.  This frequently means
>>finding out if a particular MIME type, such as application/iotp, is
>>being handled.
>
>I would suggest that the work of the 'conneg' group might be surveyed
for
>possibly useful components (including some recent I-D submissions).
>
>Also, the 'rescap' group's work might prove to have some relevance.
>
>#g
>
>------------
>Graham Klyne
>([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]
-----------------------------------------------------------------------
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: Graham Klyne <[email-masked]>
cc: [email-masked]
Subject: Re: Capability detectio9n (was: "Wallet" Detection) 
Date: Wed, 17 Mar 1999 02:55:19 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

"conneg" seems to be primarily concerned with future development in
how to negotiate the form of delivered information, not its type.
As such, I don't see how it is relevant to designing a workable technique
for near term implementation.  Even if a new standards track document
popped out soon, it could be long time before it is ceployed.

"rescap" doesn't seem to be on the IETF web pages right now.

Thanks,
Donald

From:  Graham Klyne <[email-masked]>
Message-Id:  <[email-masked]>
X-Sender:  [email-masked]
Date:  Tue, 16 Mar 1999 21:47:10 +0000
To:  "Donald E. Eastlake 3rd" <[email-masked]>
Cc:  [email-masked]

>At 11:37 14/03/99 -0500, Donald E. Eastlake 3rd wrote:
>>
>>For the Internet Open Trading Protocol and similar protocols operating
>>via HTTP, web servers are frequently faced with the problem of
>>determining whether software to handle the protocol they wish to use
>>is installed at the user's browser/machine.  This frequently means
>>finding out if a particular MIME type, such as application/iotp, is
>>being handled.
>
>I would suggest that the work of the 'conneg' group might be surveyed for
>possibly useful components (including some recent I-D submissions).
>
>Also, the 'rescap' group's work might prove to have some relevance.
>
>#g
>
>------------
>Graham Klyne
>([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: [email-masked]
Date: Tue, 16 Mar 1999 17:38:29 EST
To: [email-masked]
Subject: Re OECD technical advisory group on e-commerce and professional data assessmen
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

In response to  Neil and David's e-mails on this subject

Such tax laws on sales as described by David are already in place in many
countries for conventional commerce. This is, in fact exactly what VAT does
(at least in the EU), merchants are responsible for tax collection and
remission to the tax authorities. As I wrote in an e-mail to the group last
year, my understanding of the current position on taxation of e-commerce, is
not that it is necessarily tax free but that governments have pledged not to
introduce any new forms of taxation. In many cases, where e-commerce appears
to be tax-free, the more likely situation is that applicable taxes are simply
not being collected. 

As far as relocation by businesses to low tax /no tax areas are concerned, it
would appear that the OECD is alert to the possibility of tax competition
between jurisdictions and envisages dealing with this issue in a variety of
ways that aim to protect countries' existing tax bases from erosion.  Further
consideration is to be given to the OECD Model Tax Convention  and whether the
existing rules giving rise to a liability to taxation by a non resident
enterprise are applicable to e-commerce; whether new rules are necessary to
minimise tax avoidance (and to discourage relocation)

At the OECD Ottawa Conference in 1998, the conference endorsed 5 principles
relating to the future of taxation of e-commerce, namely:

1. neutrality, 
i.e that taxation of e-commerce should be compatible and equitable with
taxation of conventional commerce; that business decisions should be motivated
by economic rather than tax considerations 

2. efficiency
compliance costs should be kept to a minimum

3. certainty and simplicity
- so that tax payers will know in advance what their liability will be,
including where and how the tax is to be accounted

4. effectiveness and fairness
 - the potential for evasion and avoidance should be minimised, but
counteracting measures should be proportional to the risks involved

5. flexibility
- tax systems should be flexible and dynamic to ensure that they keep pace
with technological and commercial developments.

There were a number of other issues discussed at the conference. This e-mail
does not attempt to summarise them all, but the following may be relevant to
IOTP.

- there is an intention to try to draw non-OECD countries into discussions on
e-commerce taxation in order to promote global harmony of tax laws and
systems.

- it is proposed that intangible products' should not be treated as 'goods'
for taxation purposes. I believe there is still some on-going discussion on
how certain types of intangible products should be classed, i.e. as services
or as royalties etc , which would affect the method/ type of taxation -
however, this is another story too complicated to go into here. 

- it is also proposed that consumption taxes on e-commerce 'products' should
be imposed in the jurisdiction in which they are consumed. Although this is
compatible with some existing principles e.g VAT on services within EU, it
does raise many questions as to how a merchant establishes the location of the
customer, particularly in the supply of an intangible product/service
delivered electronically.  However, at present, this is likely to be beyond
the scope and purpose of IOTP ??? - or not???  It also poses some
complexities, I imagine, in incorporating into IOTP the facility to include
different tax rates, although I have no doubt that this is an unavoidable
issue for the future, not just for accounting purposes but as business
customers may require tax (VAT) receipts. 

- there are also further discussions to take place in relation to what factors
determine where consumption rakes place and how taxes should be administered
particularly when the supplier is located outside the relevant tax
jurisdiction.

- there is also to be further clarification as to what constitutes 'permanent
establishment' (i.e. the test for liablility to taxation in a jurisdiction of
the profits of a non resident enterprise or business), in particular in what
circumstances servers and web sites constitute 'permanent establishment'. It
is likely that the concept of permanent establishment is not particularly
appropriate as a test in relation to certain types of e-commerce enterprises,
and that further consideration of alternative rules for the tax liability of
their profits is needed.

- tax authorities should improve their service to taxpayers both in providing
easily accessible information and in the administration and collection
services. Procedures should be simplified and available technology used 

- there should be particular attention paid to SME's, (which are likely to
have little or no experience of the pitfalls of international commerce and
taxation.)

- avoidance of double taxation or no taxation (and indeed of tax competition
between jurisdictions)

- governments should collaborate to detect and deal with tax fraud and
evasion.

- the OECD encourages consultation with the business and technology sectors
and to have regard, where possible to solutions developed by them.

On the technological side, this may result (my guess) in the OECD and
governments looking for solutions to provide:

- means of identifying (including location) the parties to an e-commerce
transaction. As far as businesses are concerned, this may be dealt with in
part by requirements as to registration of the business with tax authorities
or through Internet Protocol number allocation records; and the provision on
relevant information (such as registered address and VAT number etc.. ) on the
web site. There is an overlap here with other aspects of e-commerce associated
with consumer protection laws, e.g. the European Commission is considering a
draft directive which covers this.  Identification of the consumer and his
location poses more difficulties, particularly if the onus is to be placed on
the merchant to record this information.

- alternative forms of audit trails specific to e-commerce 
 Basically the primary duty to account to the relevant tax authority lies with
the tax payer. However, authorities traditionally use secondary sources of
information (sometimes from third parties) to verify the tax payers accounts,
such as bank statements, delivery records, purchase/ sales records which
create an audit trail and can be cross-checked etc.. In e- commerce
transactions, particularly those relatiing to intangibles the trail or indeed
any record at all may be eliminated (disintermediation) Naturally, tax
authorities are anxious to detect or establish new forms of audit trails,
relevant to e-commerce.  In doing so the 5 basic principles (set out above)
should apply. It is also my assumption that other conventional principles will
apply, such as privacy/data protection and banking confidentiality.

- secure, tamper -evident electronic means of record keeping and accounting to
tax authorities (including the filing of required documents with tax
authorities and collection/payment)

 Almost all jurisdiction already have procedures for obtaining information
relevant to tax enforcement, usually a duty to disclose is imposed on the
taxpayer and if he fails to comply, the tax due will simply be assessed by the
authority, plus penalties, These procedures are usually supplemented by powers
of search and seizure. In such circumstances, the taxpayer generally finds it
cost effective to provide the relevant disclosure. Difficulties may arise
where the information is either held abroad and therefore beyond the
jurisdiction of the tax authority, or held in an electronic form which is not
easily accessible or reliable as to its integrity.  In my view the answer to
this is part technological and part legal.   

In terms of the technological solution IOTP potentially can play a valuable
role. By that I DO NOT mean as a tax authority agent or spy; I mean by
providing an essential service to merchants who already have duties and
liabilities to their tax authority. Inevitably tax authorities will require
merchants involved in e-commerce to maintain their electronic records and
accounting procedures in a secure and tamper evident manner. One could
envisage that tax authorities might specify which protocols or standards
fulfilled its requirements in this regard. This is not new; very often in
conventional commerce there may be requirements as to how/what records should
be kept and/or how accounts should be presented. It has always been my view
that meeting these requirements is likely greatly to enhance IOTP's
attractiveness to merchants - 'peace of mind' factor.

The legal contribution in the equation, in my view, is to ensure existing laws
as to inspection /disclosure are effective or amended in relation to
electronic records and are enforceable beyond jusidictional boundaries. I am
not a great fan of mandatory key escrow proposals; I actually see no reason
that the penalties for refusal to allow proper legal access to encrypted
stored data should be materially different to those available for conventional
forms of non-disclosure.

Again, I should reiterate that this does not attempt to be a comprehensive
discussion of all the issues raised at the Ottawa Conference, nor all the ways
in which technology has a role to play. No doubt David will be able to
feedback valuable information about that after his first meeting in April.  It
is my view that developments and solutions for e-commerce are likely to
require multi-disciplinary imput, most notably from technological, business
and legal sources.

I also do not pretend that I have been able to track down proposed legal
developments in more than a few jurisdictions, but it would appear that the
USA and the European Union are committed to following the OECD guidelines and
recommendations. It has to be remembered that a resolution of taxation issues
is necessary for the removal of one of the barriers to successful e-commerce
for the future. As far as I can tell 'bit tax' is no longer being considered
as an option; the trend is to apply conventional forms of taxation, collection
and enforcement as far as possible to e-commerce. New rules may have to be
devised to deal with the electronic supply of intangibles to ensure compliance
with taxation laws; also in relation to liability to taxation to their
profits. Amendments to laws and tax treaties may also be needed to provide
greater uniformity of taxation globally, including in relation to
international co-operation in investigation and enforcement.  No doubt the
OECD will ask the technology sector to provide solutions which will be
attractive to business enterprises and make the OECD goals achievable.

Jane Hill
-----------------------------------------------------------------------
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, 16 Mar 1999 21:47:10 +0000
To: "Donald E. Eastlake 3rd" <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: Capability detectio9n (was: "Wallet" Detection)
Cc: [email-masked]
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

At 11:37 14/03/99 -0500, Donald E. Eastlake 3rd wrote:
>
>For the Internet Open Trading Protocol and similar protocols operating
>via HTTP, web servers are frequently faced with the problem of
>determining whether software to handle the protocol they wish to use
>is installed at the user's browser/machine.  This frequently means
>finding out if a particular MIME type, such as application/iotp, is
>being handled.

I would suggest that the work of the 'conneg' group might be surveyed for
possibly useful components (including some recent I-D submissions).

Also, the 'rescap' group's work might prove to have some relevance.

#g

------------
Graham Klyne
([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: RE: OECD technical advisory group on e-commerce and professional  data assesment
Date: Mon, 15 Mar 1999 20:06:29 -0000
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Neil

I think I agree with you, especially the bit about companies re-locating to
low tax areas. I'm pretty sure that the people working at the OECD are aware
of this risk which is why they are trying to get a multi-national
co-ordinated approach which would stand a better chance of success. If the
OECD initiative doesn't succeed then I think the only other option when
businesses start relocating to different countries, is for tax authorities
to increase some other tax (income tax?) to compensate. Do we want that?

I also agree that we don't want to over-complicate IOTP. What I currently
envision, at the *most* is adding an additional optional element in the
Offer Response which would allow a merchant to state the taxes which were
being imposed and why. As it is optional I think it should mean backwards
compatibility with the current spec. I am currently strongly inclined to
resist aything much more, although it's not really a good idea to pre-judge
what the results of the TAG will be.

As far as using an alternative protocol, that's not the real issue. IOTP can
work in any country by anybody who wants to implement it. Just because IOTP
*could* allow tax information to be recorded, it doesn't mean that if you
use IOTP then you have to collect tax. So if you re-locate your business to
a low tax domain to avoid paying tax, then you could still use IOTP.

It's just that *if* tax IS going to be collected on the net, then wouldn't
it be better to have a common approach towards doing it?

David

> ----------
> From: 	Neil McEvoy[SMTP:[email-masked]]
> Sent: 	15 March 1999 09:02
> To: 	Ietf Trade WG
> Subject: 	Re: OECD technical advisory group on e-commerce and
> professional  data assesment
> 
> 
> > All it would take is for tax authority who has some type of jurisdiction
> > over a merchant to pass a law that says "collect x% on all your sales
> over
> > the Internet and give them to me" and the merchant would *have* to
> collect
> > them if he wanted to stay in business.
> 
> ...in that jurisdiction.
> 
> Tax competition drives business, especially "weightless" business which is
> easy to re-locate, to low cost areas. The best example is the creation of
> the multi-trillion eurodollar market in London following the imposition of
> a
> withholding tax in the US. Now that cross-border financial transactions
> are
> becoming available to the rest of us, I think we can expect at least a
> trend
> for commerce servers to be located in low or no tax jurisdictions.
> 
> I sense we actually agree on most of these things if we steer clear of the
> kind of absolutes in my last polemic! So, I would suggest a stance at the
> OECD along the following lines:
> 
> - don't imagine a tax bonanza: attempts to raise these kind of taxes will
> be
> self limiting
> 
> - please don't try to complicate enabling technologies like IOTP overly;
> it
> will be an incentive to go offshore _and_ use a simpler protocol.
> 
> Regards
> Neil
> ----------------------------------------------------------------
> Neil McEvoy, Director                                   Hyperion
>                                          8 Frederick Sanger Road
> http://www.hyperion.co.uk/                  Surrey Research Park
> mailto:[email-masked]                 Guildford, Surrey, UK
> Finger for PGP public key                 Tel:+44 (0)1483 301793
> (new key Jan 98)                          Fax:+44 (0)1483 301793
> 
> Where people, networks and money come together..consult Hyperion
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

Date: Mon, 15 Mar 1999 17:02:11 +0000
Subject: Re: OECD technical advisory group on e-commerce and professional  data assesment
From: Neil McEvoy <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

> All it would take is for tax authority who has some type of jurisdiction
> over a merchant to pass a law that says "collect x% on all your sales over
> the Internet and give them to me" and the merchant would *have* to collect
> them if he wanted to stay in business.

...in that jurisdiction.

Tax competition drives business, especially "weightless" business which is
easy to re-locate, to low cost areas. The best example is the creation of
the multi-trillion eurodollar market in London following the imposition of a
withholding tax in the US. Now that cross-border financial transactions are
becoming available to the rest of us, I think we can expect at least a trend
for commerce servers to be located in low or no tax jurisdictions.

I sense we actually agree on most of these things if we steer clear of the
kind of absolutes in my last polemic! So, I would suggest a stance at the
OECD along the following lines:

- don't imagine a tax bonanza: attempts to raise these kind of taxes will be
self limiting

- please don't try to complicate enabling technologies like IOTP overly; it
will be an incentive to go offshore _and_ use a simpler protocol.

Regards
Neil
----------------------------------------------------------------
Neil McEvoy, Director                                   Hyperion
                                         8 Frederick Sanger Road
http://www.hyperion.co.uk/                  Surrey Research Park
mailto:[email-masked]                 Guildford, Surrey, UK
Finger for PGP public key                 Tel:+44 (0)1483 301793
(new key Jan 98)                          Fax:+44 (0)1483 301793

Where people, networks and money come together..consult Hyperion
-----------------------------------------------------------------------
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: OECD technical advisory group on e-commerce and professional  data assesment
Date: Mon, 15 Mar 1999 16:06:26 -0000
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I agree it's impossible to tax "bits" since you can't easily detect where
the bits are going to. However if your are buying something, whether it's
delivered digitally or physically, then you have to make a payment and this
where a "tax" could be levied.

All it would take is for tax authority who has some type of jurisdiction
over a merchant to pass a law that says "collect x% on all your sales over
the Internet and give them to me" and the merchant would *have* to collect
them if he wanted to stay in business.

If e-commerce keeps on growing in the way it seems to be, then I think it is
a real possibility that a tax authority, in some state or country, might
declare this type of unilateral tax collection because they are losing too
much tax revenue which they have to recover in some way (does anybody
disagree?).

It would be much better if there was a more reasoned, effective, fairer,
workable, low cost method of collecting taxes if they are to be imposed, and
this is what I think the OECD wants to help facilitate, at least on an
international level. I think two things need to be done to do this:
*	working out what taxes should apply and the rules to be used in
calculating them, and
*	making sure that, once you know what the rules are, you have a good
effective infrastructure in place to effectively record, collect and
transfer the revenue to the appropriate tax authority.

I really haven't a clue what the rules for calculating tax should be ...
I'll leave that to the tax experts. But I do think that protocols like IOTP
can help with the recording, collection and transfer of the taxes which, I
think, is the focus of the Technical Advisory Group.

David
> ----------
> From: 	Neil McEvoy[SMTP:[email-masked]]
> Sent: 	15 March 1999 00:48
> To: 	Ietf Trade WG
> Subject: 	Re: OECD technical advisory group on e-commerce and
> professional data assesment
> 
> 
> 
> ----------
> >From: David Burdett <[email-masked]>
> 
> > At the end of last year, there was discussion on the Trade WG about how
> IOTP
> > could potentially be used to support the record keeping associated with
> the
> > collection of tax information.
> >
> > Following on from this I've been invited to join the OECD technical
> advisory
> > group on e-commerce which will hold its inaugural meeting in Washington
> on
> > 20-21 April.
> >
> > If anyone has any comments, views, opinions, ideas, or anything else
> that
> > you want to make on or about this topic please send me an email or
> > preferably e-mail the list.
> >
> 
> In the end, it will be impossible to collect taxes on bits, because
> they're
> too easy to smuggle. Tell them to tax atoms instead, e.g land, buildings,
> etc.
> 
> Cheers
> Neil
> 
> ----------------------------------------------------------------
> Neil McEvoy, Director                                   Hyperion
>                                          8 Frederick Sanger Road
> http://www.hyperion.co.uk/                  Surrey Research Park
> mailto:[email-masked]                 Guildford, Surrey, UK
> Finger for PGP public key                 Tel:+44 (0)1483 301793
> (new key Jan 98)                          Fax:+44 (0)1483 301793
> 
> Where people, networks and money come together..consult Hyperion
> -----------------------------------------------------------------------
> 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: Ian King <[email-masked]>
To: "Donald E. Eastlake 3rd" <[email-masked]>
Cc: [email-masked]
Subject: RE: "Wallet" Detection 
Date: Mon, 15 Mar 1999 07:33:00 -0800
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I think I was "hearing" something different, too.  I was concerned you were
suggesting Yet Another New Header.  :-)  You're right, browsers are often
configurable in such manner as you suggest (and I'm almost certain IE is).
But again, it does sound like an instance of a more general problem.  -- Ian

-----Original Message-----
From: Donald E. Eastlake 3rd [mailto:[email-masked]]
Sent: Monday, March 15, 1999 12:25 AM
To: Ian King
Cc: [email-masked]
Subject: Re: "Wallet" Detection 

Sorry, I must not have made what I was suggesting clear.

It's really not that big a deal.  You can find various "sniffer" code
documented here and there all over the web.  Anyone trying to deal
with VRML or various streaming media, etc., needs to try to figure out
if some plug-in or MIME type handler or other is installed.

Anyone trying to deploy IOTP in the open Internet context has this
problem.  Why should everyone trying to do that be doomed to attack
this problem independently?  With a little pooling of information, I
think a workable suggestion could be put together as an Informational
document.

Maybe something "under development" will make this task easier and in
the future a better recommendation would exist but that does not solve
the problem now.  I'm not suggesting assuming any change in browsers
so whether there is, or will soon be, something to solve this that the
browser makers "are looking for" wouldn't affect this.  In any case,
diffusion of browers is slower that it used to be.  Enough people have
multi-feature browsers stuffed with features that there is less
incentive to snap up the latest version.  If a better technique were
standardized today, how many years would it be berfore it was in X% of
the browsers out there?

I've been looking into this some and it seems to me that a combination
of conditional JavaScript and ActiveX Registry query could do the
trick in enough of the cases to be a reasonable engineering solution.

I don't quite see what the problem is here with "multiple solutions".
If there are multiple ways that work with the bulk of current browsers
for the server to tell if a MIME type is supported at a browser, that
does not seem like a problem.  If the WG wants to do this and there is
a rough consensus to suggest one way or a few alternatives, that way
or those alternatives could be documented.

Thanks,
Donald

From:  Ian King <[email-masked]>
Message-ID:  <FFD1BA74C6A7D111A09500805F9F88F50C93E1FC@RED-MSG-43>
To:  "Donald E. Eastlake 3rd" <[email-masked]>,
[email-masked]
Date:  Sun, 14 Mar 1999 21:29:59 -0800

>Ouch -- that's a big problem, and I'd suggest that it can only be
considered
>in the context of what "may be under development", to avoid multiple
>solutions to the same problem.  And coming up with a "solution" that
doesn't
>have that consensus won't address the current browsers, because the browser
>makers will be looking for that broad consensus.  -- Ian
>
>-----Original Message-----
>From: Donald E. Eastlake 3rd [mailto:[email-masked]]
>Sent: Sunday, March 14, 1999 8:37 AM
>To: [email-masked]
>Subject: "Wallet" Detection
>
>
>
>For the Internet Open Trading Protocol and similar protocols operating
>via HTTP, web servers are frequently faced with the problem of
>determining whether software to handle the protocol they wish to use
>is installed at the user's browser/machine.  This frequently means
>finding out if a particular MIME type, such as application/iotp, is
>being handled.
>
>Theoretically this should be determinable from HTTP headers and may be
>in some cases but too many browsers send "*/*" for the MIME types they
>accept.  Other methods of negotiations may be under development but
>what I'm talking about is solving the actual oeprational problem on
>the bulk of the browsers actually in use from today to within the next
>6 to 12 months.
>
>I'd like to suggest a work item for the TRADE WG to develop an
>Informational RFC suggesting a real workable way to do this.
>
>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]

Subject: RE: Issues on Currency Code Types in IOTP
Date: Mon, 15 Mar 99 10:02:43 +0000
From: Steven Sims <[email-masked]>
MMDF-Warning:  Unable to confirm address in preceding line at one.eListX.com
To: Yoshiaki KAWATSURA <[email-masked]>, [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

>Unfortunately, SET uses three digit code as the currency codes.
>Does anybody know other protocols which is used three digit code
> as the currency codes?

The widest used electronic purse card in the world, Proton, also uses the 
three digit currency codes.

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]

Date: Sun, 14 Mar 1999 15:06:53 -0800
To: "Donald E. Eastlake 3rd" <[email-masked]>
From: Tom Arnold <[email-masked]>
Subject: Re: "Wallet" Detection
Cc: [email-masked]
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I see the relevance to wallets. But, beyond that this would be a very good
piece for general "plug-in" detection as well. Out of necessity, we have
implemented a technique to detect the presence of a download tool or
streaming viewer prior to downloading content. In essence, we need to
determine if we have to provide a tool (plug-in) to the consumer before
streaming the content. I think this would be a valuable protocol to have
documented or at least complete the research and determine a best practice
in the field as I wonder if some other WG has done anything with this.

At 11:37 AM 3/14/99 -0500, Donald E. Eastlake 3rd wrote:
>
>For the Internet Open Trading Protocol and similar protocols operating
>via HTTP, web servers are frequently faced with the problem of
>determining whether software to handle the protocol they wish to use
>is installed at the user's browser/machine.  This frequently means
>finding out if a particular MIME type, such as application/iotp, is
>being handled.
>
>Theoretically this should be determinable from HTTP headers and may be
>in some cases but too many browsers send "*/*" for the MIME types they
>accept.  Other methods of negotiations may be under development but
>what I'm talking about is solving the actual oeprational problem on
>the bulk of the browsers actually in use from today to within the next
>6 to 12 months.
>
>I'd like to suggest a work item for the TRADE WG to develop an
>Informational RFC suggesting a real workable way to do this.
>
>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]
>
>

Tom Arnold
Vice President of Engineering
Chief Technical Officer
CyberSource Corporation
[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: Sun, 14 Mar 1999 15:23:03 -0800
To: "[email-masked]" <[email-masked]>
From: Tom Arnold <[email-masked]>
Subject: Country Codes in IOTP
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

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?

Tom Arnold
Vice President of Engineering
Chief Technical Officer
CyberSource Corporation
[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: Sun, 14 Mar 1999 15:30:20 -0800
To: "[email-masked]" <[email-masked]>
From: Tom Arnold <[email-masked]>
Subject: Country Codes in IOTP
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Sorry to send this again, but I blew the original version. ISO 3166-3:1999
specifies both two character alphanumeric and numeric country codes. My
actual question was related to the thread of the ISO 4217 discussion on the
list in asking that the IOTP specification define country codes as well as
currency codes. Further to suggest that the same specification be used on
the country code as was discribed on the currency code. This would be
country code type "iso3166-3:1999-a" for the alphanumeric version, and
"iso3166-3:1999-a" for the numeric version.

>Date: Sun, 14 Mar 1999 15:23:03 -0800
>To: "[email-masked]" <[email-masked]>
>From: Tom Arnold <[email-masked]>
>Subject: Country Codes in IOTP
>In-Reply-To: <[email-masked]>
>References: <[email-masked]>
<[email-masked]>
>
>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?

Tom Arnold
Vice President of Engineering
Chief Technical Officer
CyberSource Corporation
[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: "Milton M. Anderson" <[email-masked]>
To: David Burdett <[email-masked]>
Cc: [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at one.eListX.com
Subject: Re: Issues on Currency Code Types in IOTP
Date: Mon, 15 Mar 1999 08:28:10 -0500
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David

See also http://www.unece.org/cefact/index.htm
Select "Code Lists"
Select "Currency Codes"

This leads me to believe that EDI
uses 3 alpha currency codes.  
There are also example 820s on the
web that show 3 alpha codes.

Milt

-----Original Message-----
From: David Burdett <[email-masked]>
To: Milton M. Anderson <[email-masked]>
Cc: Ietf Trade WG <[email-masked]>
Date: Sunday, March 14, 1999 7:25 PM
Subject: RE: Issues on Currency Code Types in IOTP

>I've received this reply from Milton Anderson.
>
>On this basis I think we should *definitely* go for the alpha codes.
>
>Does anybody disagree?
>
>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]

To: Yoshiaki KAWATSURA <[email-masked]>
cc: [email-masked]
Subject: Re: Issues on Currency Code Types in IOTP 
Date: Mon, 15 Mar 1999 04:04:44 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I think ISO 8583 does....

From:  Yoshiaki KAWATSURA <[email-masked]>
To:  [email-masked]
Cc:  [email-masked]
In-Reply-To:  Your message of "Mon, 15 Mar 1999 00:24:25 -0000"
	     	<[email-masked]>
References:  <[email-masked]>
Content-Type:  Text/Plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
Message-Id:  <[email-masked]>
Date:  Mon, 15 Mar 1999 13:32:39 +0900 (JST)
X-Dispatcher:  imput version 980905(IM100)
Lines:  17
Sender:  [email-masked]
Precedence:  bulk
X-elistx:  ietf-trade
Source-Info:   From (or Sender) name not authenticated.
>Unfortunately, SET uses three digit code as the currency codes.
>Does anybody know other protocols which is used three digit code
> as the currency codes?
>
>--
>Yoshiaki Kawatsura
>Hitachi, Ltd.
>
>
>
>
>
>
>
>
>
>
>-----------------------------------------------------------------------
>Message addressed to: [email-masked]
>Archive available at: http://www.elistx.com/archives/ietf-trade/
>To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
>body to: [email-masked]
-----------------------------------------------------------------------
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, 15 Mar 1999 08:48:16 +0000
Subject: Re: OECD technical advisory group on e-commerce and professional data assesment
From: Neil McEvoy <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

----------
>From: David Burdett <[email-masked]>

> At the end of last year, there was discussion on the Trade WG about how IOTP
> could potentially be used to support the record keeping associated with the
> collection of tax information.
>
> Following on from this I've been invited to join the OECD technical advisory
> group on e-commerce which will hold its inaugural meeting in Washington on
> 20-21 April.
>
> If anyone has any comments, views, opinions, ideas, or anything else that
> you want to make on or about this topic please send me an email or
> preferably e-mail the list.
>

In the end, it will be impossible to collect taxes on bits, because they're
too easy to smuggle. Tell them to tax atoms instead, e.g land, buildings,
etc.

Cheers
Neil

----------------------------------------------------------------
Neil McEvoy, Director                                   Hyperion
                                         8 Frederick Sanger Road
http://www.hyperion.co.uk/                  Surrey Research Park
mailto:[email-masked]                 Guildford, Surrey, UK
Finger for PGP public key                 Tel:+44 (0)1483 301793
(new key Jan 98)                          Fax:+44 (0)1483 301793

Where people, networks and money come together..consult Hyperion
-----------------------------------------------------------------------
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: Ian King <[email-masked]>
cc: [email-masked]
Subject: Re: "Wallet" Detection 
Date: Mon, 15 Mar 1999 03:25:21 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Sorry, I must not have made what I was suggesting clear.

It's really not that big a deal.  You can find various "sniffer" code
documented here and there all over the web.  Anyone trying to deal
with VRML or various streaming media, etc., needs to try to figure out
if some plug-in or MIME type handler or other is installed.

Anyone trying to deploy IOTP in the open Internet context has this
problem.  Why should everyone trying to do that be doomed to attack
this problem independently?  With a little pooling of information, I
think a workable suggestion could be put together as an Informational
document.

Maybe something "under development" will make this task easier and in
the future a better recommendation would exist but that does not solve
the problem now.  I'm not suggesting assuming any change in browsers
so whether there is, or will soon be, something to solve this that the
browser makers "are looking for" wouldn't affect this.  In any case,
diffusion of browers is slower that it used to be.  Enough people have
multi-feature browsers stuffed with features that there is less
incentive to snap up the latest version.  If a better technique were
standardized today, how many years would it be berfore it was in X% of
the browsers out there?

I've been looking into this some and it seems to me that a combination
of conditional JavaScript and ActiveX Registry query could do the
trick in enough of the cases to be a reasonable engineering solution.

I don't quite see what the problem is here with "multiple solutions".
If there are multiple ways that work with the bulk of current browsers
for the server to tell if a MIME type is supported at a browser, that
does not seem like a problem.  If the WG wants to do this and there is
a rough consensus to suggest one way or a few alternatives, that way
or those alternatives could be documented.

Thanks,
Donald

From:  Ian King <[email-masked]>
Message-ID:  <FFD1BA74C6A7D111A09500805F9F88F50C93E1FC@RED-MSG-43>
To:  "Donald E. Eastlake 3rd" <[email-masked]>, [email-masked]
Date:  Sun, 14 Mar 1999 21:29:59 -0800

>Ouch -- that's a big problem, and I'd suggest that it can only be considered
>in the context of what "may be under development", to avoid multiple
>solutions to the same problem.  And coming up with a "solution" that doesn't
>have that consensus won't address the current browsers, because the browser
>makers will be looking for that broad consensus.  -- Ian
>
>-----Original Message-----
>From: Donald E. Eastlake 3rd [mailto:[email-masked]]
>Sent: Sunday, March 14, 1999 8:37 AM
>To: [email-masked]
>Subject: "Wallet" Detection
>
>
>
>For the Internet Open Trading Protocol and similar protocols operating
>via HTTP, web servers are frequently faced with the problem of
>determining whether software to handle the protocol they wish to use
>is installed at the user's browser/machine.  This frequently means
>finding out if a particular MIME type, such as application/iotp, is
>being handled.
>
>Theoretically this should be determinable from HTTP headers and may be
>in some cases but too many browsers send "*/*" for the MIME types they
>accept.  Other methods of negotiations may be under development but
>what I'm talking about is solving the actual oeprational problem on
>the bulk of the browsers actually in use from today to within the next
>6 to 12 months.
>
>I'd like to suggest a work item for the TRADE WG to develop an
>Informational RFC suggesting a real workable way to do this.
>
>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]

From: Ian King <[email-masked]>
To: "Donald E. Eastlake 3rd" <[email-masked]>,  [email-masked]
Subject: RE: "Wallet" Detection
Date: Sun, 14 Mar 1999 21:29:59 -0800
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Ouch -- that's a big problem, and I'd suggest that it can only be considered
in the context of what "may be under development", to avoid multiple
solutions to the same problem.  And coming up with a "solution" that doesn't
have that consensus won't address the current browsers, because the browser
makers will be looking for that broad consensus.  -- Ian

-----Original Message-----
From: Donald E. Eastlake 3rd [mailto:[email-masked]]
Sent: Sunday, March 14, 1999 8:37 AM
To: [email-masked]
Subject: "Wallet" Detection

For the Internet Open Trading Protocol and similar protocols operating
via HTTP, web servers are frequently faced with the problem of
determining whether software to handle the protocol they wish to use
is installed at the user's browser/machine.  This frequently means
finding out if a particular MIME type, such as application/iotp, is
being handled.

Theoretically this should be determinable from HTTP headers and may be
in some cases but too many browsers send "*/*" for the MIME types they
accept.  Other methods of negotiations may be under development but
what I'm talking about is solving the actual oeprational problem on
the bulk of the browsers actually in use from today to within the next
6 to 12 months.

I'd like to suggest a work item for the TRADE WG to develop an
Informational RFC suggesting a real workable way to do this.

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]

To: [email-masked]
Cc: [email-masked]
Subject: RE: Issues on Currency Code Types in IOTP
From: Yoshiaki KAWATSURA <[email-masked]>
Date: Mon, 15 Mar 1999 13:32:39 +0900 (JST)
Lines: 17
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Unfortunately, SET uses three digit code as the currency codes.
Does anybody know other protocols which is used three digit code
 as the currency codes?

--
Yoshiaki Kawatsura
Hitachi, Ltd.

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

From: David Burdett <[email-masked]>
To: "Milton M. Anderson" <[email-masked]>
Cc: Ietf Trade WG <[email-masked]>
Subject: RE: Issues on Currency Code Types in IOTP
Date: Mon, 15 Mar 1999 00:24:25 -0000
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I've received this reply from Milton Anderson.

On this basis I think we should *definitely* go for the alpha codes.

Does anybody disagree?

David

> ----------
> From: 	Milton M. Anderson[SMTP:[email-masked]]
> Sent: 	13 March 1999 14:44
> To: 	David Burdett
> Subject: 	Re: Issues on Currency Code Types in IOTP
> 
> David,
> 
> OFX, Integrion Gold, IFX from BITS,
> FSTC echeck and FSTC BIPS all used
> the 3 alpha codes.  
> 
> Milt
> 
> Milton M. Anderson
> Technical Projects Director
> Financial Services Technology Consortium
> 276 Dartmouth Avenue
> Fair Haven, NJ 07704-3121
> +1 732 747 1514
> [email-masked]
> 
> 
> -----Original Message-----
> From: David Burdett <[email-masked]>
> To: Ietf Trade WG <[email-masked]>
> Date: Friday, March 12, 1999 9:56 PM
> Subject: RE: Issues on Currency Code Types in IOTP
> 
> 
> >Kent said ...
> >
> >> Assuming an implementor would get the ISO4217 Spec and cut and paste
> the
> >> codes for implementation, I don't see any problem in putting in both
> >> 
> >I agree but ...
> >* New codes are occasionally added, e.g. for the euro, therefore the
> >table would need to be maintained
> >* the look up table takes up space and if you're on a thin client you
> >*might* not want to have to include it.
> >
> >David
> >
> >> ----------
> >> From: Kent M. Davidson[SMTP:[email-masked]]
> >> Sent: 12 March 1999 10:38
> >> To: [email-masked]
> >> Subject: RE: Issues on Currency Code Types in IOTP
> >> 
> >> However, from an implementation point of view, an implementor must then
> >> put in lookup tables for *both* character and digit codes.
> >> 
> >> Not that it really makes that much of a difference in the
> implementation.
> >> You are correct that it is clear and unambiguous.
> >> 
> >> Assuming an implementor would get the ISO4217 Spec and cut and paste
> the
> >> codes for implementation, I don't see any problem in putting in both.
> >> 
> >> However, if it comes down to choosing one or another, I'll agree with
> >> Donald and agree with the preference for letters in lieu of digits.
> >> 
> >> -Kent.
> >> 
> >> At 11:30 AM 3/12/99 -0500, Smith, Chris wrote:
> >> >
> >> >Is this actually a problem?
> >> >
> >> >Note that any given currency code will either be a numeric or
> alphabetic 
> >> >code. As such, the type of ISO4217 code can be quickly determined by 
> >> >looking at the actual code provided.
> >> >
> >> >Put another way:
> >> >
> >> >   ISO4217: USD
> >> >
> >> >and
> >> >
> >> >   ISO4217: 840
> >> >
> >> >are both clear and unambiguous, and it is possible to translate
> without 
> >> >loss from one to the other and back again.
> >> >
> >> >...Chris
> >> >
> >> 
> >> _____________________________
> >> Kent M. Davidson
> >> Vice President of Engineering
> >> Differential, Inc.
> >> direct (408)864-0604 
> >> fax    (408)864-0601             
> >> mailto:[email-masked]
> >> http://www.differential.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]

To: [email-masked]
Subject: "Wallet" Detection
Date: Sun, 14 Mar 1999 11:37:18 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

For the Internet Open Trading Protocol and similar protocols operating
via HTTP, web servers are frequently faced with the problem of
determining whether software to handle the protocol they wish to use
is installed at the user's browser/machine.  This frequently means
finding out if a particular MIME type, such as application/iotp, is
being handled.

Theoretically this should be determinable from HTTP headers and may be
in some cases but too many browsers send "*/*" for the MIME types they
accept.  Other methods of negotiations may be under development but
what I'm talking about is solving the actual oeprational problem on
the bulk of the browsers actually in use from today to within the next
6 to 12 months.

I'd like to suggest a work item for the TRADE WG to develop an
Informational RFC suggesting a real workable way to do this.

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]

Date: Sat, 13 Mar 1999 16:48:21 -0800
To: "[email-masked]" <[email-masked]>
From: Tom Arnold <[email-masked]>
Subject: RE: Issues on Currency Code Types in IOTP
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

We run a gateway and must provide applications and interfaces that support
both ISO4217 forms. I would agree with Donald on this, but would also
suggest that support for both forms not be mandated in the specification.
An either or condition would be preferred.

At 10:38 AM 3/12/99 -0800, Kent M. Davidson wrote:
>However, from an implementation point of view, an implementor must then
put in lookup tables for *both* character and digit codes.
>
>Not that it really makes that much of a difference in the implementation.
You are correct that it is clear and unambiguous.
>
>Assuming an implementor would get the ISO4217 Spec and cut and paste the
codes for implementation, I don't see any problem in putting in both.
>
>However, if it comes down to choosing one or another, I'll agree with
Donald and agree with the preference for letters in lieu of digits.
>
>-Kent.
>
>At 11:30 AM 3/12/99 -0500, Smith, Chris wrote:
>>
>>Is this actually a problem?
>>
>>Note that any given currency code will either be a numeric or alphabetic 
>>code. As such, the type of ISO4217 code can be quickly determined by 
>>looking at the actual code provided.
>>
>>Put another way:
>>
>>   ISO4217: USD
>>
>>and
>>
>>   ISO4217: 840
>>
>>are both clear and unambiguous, and it is possible to translate without 
>>loss from one to the other and back again.
>>
>>...Chris
>>
>
>_____________________________
>Kent M. Davidson
>Vice President of Engineering
>Differential, Inc.
>direct (408)864-0604 
>fax    (408)864-0601             
>mailto:[email-masked]
>http://www.differential.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]
>
>

Tom Arnold
Vice President of Engineering
Chief Technical Officer
CyberSource Corporation
[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: RE: Issues on Currency Code Types in IOTP
Date: Sat, 13 Mar 1999 02:48:11 -0000
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Kent said ...

> Assuming an implementor would get the ISO4217 Spec and cut and paste the
> codes for implementation, I don't see any problem in putting in both
> 
I agree but ...
*	New codes are occasionally added, e.g. for the euro, therefore the
table would need to be maintained
*	the look up table takes up space and if you're on a thin client you
*might* not want to have to include it.

David

> ----------
> From: 	Kent M. Davidson[SMTP:[email-masked]]
> Sent: 	12 March 1999 10:38
> To: 	[email-masked]
> Subject: 	RE: Issues on Currency Code Types in IOTP
> 
> However, from an implementation point of view, an implementor must then
> put in lookup tables for *both* character and digit codes.
> 
> Not that it really makes that much of a difference in the implementation.
> You are correct that it is clear and unambiguous.
> 
> Assuming an implementor would get the ISO4217 Spec and cut and paste the
> codes for implementation, I don't see any problem in putting in both.
> 
> However, if it comes down to choosing one or another, I'll agree with
> Donald and agree with the preference for letters in lieu of digits.
> 
> -Kent.
> 
> At 11:30 AM 3/12/99 -0500, Smith, Chris wrote:
> >
> >Is this actually a problem?
> >
> >Note that any given currency code will either be a numeric or alphabetic 
> >code. As such, the type of ISO4217 code can be quickly determined by 
> >looking at the actual code provided.
> >
> >Put another way:
> >
> >   ISO4217: USD
> >
> >and
> >
> >   ISO4217: 840
> >
> >are both clear and unambiguous, and it is possible to translate without 
> >loss from one to the other and back again.
> >
> >...Chris
> >
> 
> _____________________________
> Kent M. Davidson
> Vice President of Engineering
> Differential, Inc.
> direct (408)864-0604 
> fax    (408)864-0601             
> mailto:[email-masked]
> http://www.differential.com
> 
> 
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

Date: Fri, 12 Mar 1999 10:38:39 -0800
To: "[email-masked]" <[email-masked]>
From: "Kent M. Davidson" <[email-masked]>
Subject: RE: Issues on Currency Code Types in IOTP
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

However, from an implementation point of view, an implementor must then put in lookup tables for *both* character and digit codes.

Not that it really makes that much of a difference in the implementation. You are correct that it is clear and unambiguous.

Assuming an implementor would get the ISO4217 Spec and cut and paste the codes for implementation, I don't see any problem in putting in both.

However, if it comes down to choosing one or another, I'll agree with Donald and agree with the preference for letters in lieu of digits.

-Kent.

At 11:30 AM 3/12/99 -0500, Smith, Chris wrote:
>
>Is this actually a problem?
>
>Note that any given currency code will either be a numeric or alphabetic 
>code. As such, the type of ISO4217 code can be quickly determined by 
>looking at the actual code provided.
>
>Put another way:
>
>   ISO4217: USD
>
>and
>
>   ISO4217: 840
>
>are both clear and unambiguous, and it is possible to translate without 
>loss from one to the other and back again.
>
>...Chris
>

_____________________________
Kent M. Davidson
Vice President of Engineering
Differential, Inc.
direct (408)864-0604 
fax    (408)864-0601             
mailto:[email-masked]
http://www.differential.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: "Smith, Chris" <[email-masked]>
cc: "[email-masked]" <[email-masked]>
Subject: Re: Issues on Currency Code Types in IOTP 
Date: Fri, 12 Mar 1999 14:21:44 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

While I suppose it is possible to understand either way, I think having
one as canconical form is best...

Thanks,
Donald

From:  "Smith, Chris" <[email-masked]>
To:  "[email-masked]" <[email-masked]>
Date:  Fri, 12 Mar 1999 11:30:00 -0500
Content-Type:  text/plain
Message-ID:   <[email-masked]>
Sender:  [email-masked]
Precedence:  bulk
X-elistx:  ietf-trade
Source-Info:   From (or Sender) name not authenticated.
>
>Is this actually a problem?
>
>Note that any given currency code will either be a numeric or alphabetic 
>code. As such, the type of ISO4217 code can be quickly determined by 
>looking at the actual code provided.
>
>Put another way:
>
>   ISO4217: USD
>
>and
>
>   ISO4217: 840
>
>are both clear and unambiguous, and it is possible to translate without 
>loss from one to the other and back again.
>
>...Chris
>
>
>
>______________________________ Reply Separator
>_________________________________
>Subject: Issues on Currency Code Types in IOTP
>Author:  "Masaaki Hiroya" [SMTP:[email-masked]] at Internet
>Date:    1999-03-12 00:33
>
>
>According to the IOTP specification, the currency code type should 
>be set to "ISO4217".  However, there are two types of currency codes 
>in "ISO4217".  One of them is a 3-letter alphabetic code such
>as "USD", "GBP" and "JPY". The other is a 3-digit numeric code 
>such as 840, 826 and 392.
>
>As far as I know, Mondex uses alphabetic codes, but SET uses numeric codes.
>
>Can both types defined in ISO4217 be used by IOTP?
>If so, I think that the two currency code types should be distinguished 
>by IOTP systems by using CurrencyCodeType Attributes in IOTP messages, 
>for example: "ISO4217-Alphabet" and "ISO4217-Number"
>
>Otherwise, we should define which currency code type should be used 
>in IOTP, just the alphabetic one or just the numeric one.
>
>David's comments are as follows:
>> The pros andcons as I see it are:
>> *     using numbers. Follow the SET approach of using a numeric code. This
>
>> might be a good idea, especially in the light of recent discussions on the
>
>> SET-discuss which highlighted that EUR was the old mnmnonic for the ECO as
>
>> well as the new mnemonic for the Euro. However new currencies aren't
>> invented very often so this might not be a practical problem!
>> *     using letters. On the other hand USD is actually immediately
>> recognisable whereas 840 is not. This means that if we use a number, then
>we 
>> would need a table to translate it into a name
>>
>
>Any comments?
>
>Masaaki
>
>
>-----
>Masaaki Hiroya
>Systems Development Laboratory
>Hitachi, Ltd.
>email: [email-masked]
>tel: +81-44-966-9111(ext.3552)
>fax: +81-44-966-1796
>----------------------------------------------------------------------- 
>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: RE: Issues on Currency Code Types in IOTP 
Date: Fri, 12 Mar 1999 18:57:44 -0000
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I don't think we should require *both* numeric and alpha to be implemented
as I can't see any benefit and it would make it more complex to implement.
On this basis I'd go for the alpha code on ground of understandability.

If every implementer knew that in OTP the currency code was always alpha,
then it could be relied upon. However I do think that making the currency
code type "ISO4217-A" as Don suggests is a good idea.

David

> ----------
> From: 	Donald E. Eastlake 3rd[SMTP:[email-masked]]
> Sent: 	12 March 1999 08:49
> To: 	Masaaki Hiroya
> Cc: 	[email-masked]
> Subject: 	Re: Issues on Currency Code Types in IOTP 
> 
> 
> I like the alphabetic codes much more, myself, because they are easily
> understood as the two letter ISO 3166 country code followed by a
> letter for the currency.  This handles the admittedly rare case of
> "currency rollover" or multiple currencies in a country quite
> naturally.  The three digit currency codes are really just the three
> digit ISO 3166 country codes.  This allows only one curreny per
> country and is harder to understand.  Both have some problems with
> transnational currencies but manage to handle it.
> 
> SET uses numeric codes because the actually back end bank credit card
> networks, as I understand it, use numeric codes.  (And they probably
> were originally set up to do that to save a few bits in encoding.)
> 
> I suggest that the spec be changed to specify "ISO4217-A" as the
> mandatory to implement alpha codes and define "ISO4217-N" as the
> numeric codes which could be optional.
> 
> Thanks,
> Donald
> 
> From:  Masaaki Hiroya <[email-masked]>
> Message-Id:  <[email-masked]>
> X-Sender:  [email-masked]
> Date:  Fri, 12 Mar 1999 14:33:28 +0900
> To:  [email-masked]
> 
> >According to the IOTP specification, the currency code type should
> >be set to "ISO4217".  However, there are two types of currency codes
> >in "ISO4217".  One of them is a 3-letter alphabetic code such 
> >as "USD", "GBP" and "JPY". The other is a 3-digit numeric code
> >such as 840, 826 and 392.
> >
> >As far as I know, Mondex uses alphabetic codes, but SET uses numeric
> codes.
> >
> >Can both types defined in ISO4217 be used by IOTP?
> >If so, I think that the two currency code types should be distinguished 
> >by IOTP systems by using CurrencyCodeType Attributes in IOTP messages, 
> >for example: "ISO4217-Alphabet" and "ISO4217-Number"
> >
> >Otherwise, we should define which currency code type should be used
> >in IOTP, just the alphabetic one or just the numeric one.
> >
> >David's comments are as follows:
> >> The pros andcons as I see it are:
> >> *	using numbers. Follow the SET approach of using a numeric code. This
> >> might be a good idea, especially in the light of recent discussions on
> the
> >> SET-discuss which highlighted that EUR was the old mnmnonic for the ECO
> as
> >> well as the new mnemonic for the Euro. However new currencies aren't
> >> invented very often so this might not be a practical problem!
> >> *	using letters. On the other hand USD is actually immediately
> >> recognisable whereas 840 is not. This means that if we use a number,
> then we
> >> would need a table to translate it into a name
> >> 
> >
> >Any comments?
> >
> >Masaaki
> >
> >
> >-----
> >Masaaki Hiroya
> >Systems Development Laboratory
> >Hitachi, Ltd.
> >email: [email-masked]
> >tel: +81-44-966-9111(ext.3552)
> >fax: +81-44-966-1796
> >-----------------------------------------------------------------------
> >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: OECD technical advisory group on e-commerce and professional data assesment
Date: Fri, 12 Mar 1999 18:57:45 -0000
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

At the end of last year, there was discussion on the Trade WG about how IOTP
could potentially be used to support the record keeping associated with the
collection of tax information.

Following on from this I've been invited to join the OECD technical advisory
group on e-commerce which will hold its inaugural meeting in Washington on
20-21 April.

If anyone has any comments, views, opinions, ideas, or anything else that
you want to make on or about this topic please send me an email or
preferably e-mail the list. 

In this way I hope to take the views of the Trade WG properly into account
during the meeting.

Regards

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

From: "Smith, Chris" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RE: Issues on Currency Code Types in IOTP
Date: Fri, 12 Mar 1999 11:30:00 -0500
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Is this actually a problem?

Note that any given currency code will either be a numeric or alphabetic 
code. As such, the type of ISO4217 code can be quickly determined by 
looking at the actual code provided.

Put another way:

   ISO4217: USD

and

   ISO4217: 840

are both clear and unambiguous, and it is possible to translate without 
loss from one to the other and back again.

...Chris

______________________________ Reply Separator
_________________________________
Subject: Issues on Currency Code Types in IOTP
Author:  "Masaaki Hiroya" [SMTP:[email-masked]] at Internet
Date:    1999-03-12 00:33

According to the IOTP specification, the currency code type should 
be set to "ISO4217".  However, there are two types of currency codes 
in "ISO4217".  One of them is a 3-letter alphabetic code such
as "USD", "GBP" and "JPY". The other is a 3-digit numeric code 
such as 840, 826 and 392.

As far as I know, Mondex uses alphabetic codes, but SET uses numeric codes.

Can both types defined in ISO4217 be used by IOTP?
If so, I think that the two currency code types should be distinguished 
by IOTP systems by using CurrencyCodeType Attributes in IOTP messages, 
for example: "ISO4217-Alphabet" and "ISO4217-Number"

Otherwise, we should define which currency code type should be used 
in IOTP, just the alphabetic one or just the numeric one.

David's comments are as follows:
> The pros andcons as I see it are:
> *     using numbers. Follow the SET approach of using a numeric code. This

> might be a good idea, especially in the light of recent discussions on the

> SET-discuss which highlighted that EUR was the old mnmnonic for the ECO as

> well as the new mnemonic for the Euro. However new currencies aren't
> invented very often so this might not be a practical problem!
> *     using letters. On the other hand USD is actually immediately
> recognisable whereas 840 is not. This means that if we use a number, then
we 
> would need a table to translate it into a name
>

Any comments?

Masaaki

-----
Masaaki Hiroya
Systems Development Laboratory
Hitachi, Ltd.
email: [email-masked]
tel: +81-44-966-9111(ext.3552)
fax: +81-44-966-1796
----------------------------------------------------------------------- 
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: Masaaki Hiroya <[email-masked]>
cc: [email-masked]
Subject: Re: Issues on Currency Code Types in IOTP 
Date: Fri, 12 Mar 1999 11:49:51 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I like the alphabetic codes much more, myself, because they are easily
understood as the two letter ISO 3166 country code followed by a
letter for the currency.  This handles the admittedly rare case of
"currency rollover" or multiple currencies in a country quite
naturally.  The three digit currency codes are really just the three
digit ISO 3166 country codes.  This allows only one curreny per
country and is harder to understand.  Both have some problems with
transnational currencies but manage to handle it.

SET uses numeric codes because the actually back end bank credit card
networks, as I understand it, use numeric codes.  (And they probably
were originally set up to do that to save a few bits in encoding.)

I suggest that the spec be changed to specify "ISO4217-A" as the
mandatory to implement alpha codes and define "ISO4217-N" as the
numeric codes which could be optional.

Thanks,
Donald

From:  Masaaki Hiroya <[email-masked]>
Message-Id:  <[email-masked]>
X-Sender:  [email-masked]
Date:  Fri, 12 Mar 1999 14:33:28 +0900
To:  [email-masked]

>According to the IOTP specification, the currency code type should
>be set to "ISO4217".  However, there are two types of currency codes
>in "ISO4217".  One of them is a 3-letter alphabetic code such 
>as "USD", "GBP" and "JPY". The other is a 3-digit numeric code
>such as 840, 826 and 392.
>
>As far as I know, Mondex uses alphabetic codes, but SET uses numeric codes.
>
>Can both types defined in ISO4217 be used by IOTP?
>If so, I think that the two currency code types should be distinguished 
>by IOTP systems by using CurrencyCodeType Attributes in IOTP messages, 
>for example: "ISO4217-Alphabet" and "ISO4217-Number"
>
>Otherwise, we should define which currency code type should be used
>in IOTP, just the alphabetic one or just the numeric one.
>
>David's comments are as follows:
>> The pros andcons as I see it are:
>> *	using numbers. Follow the SET approach of using a numeric code. This
>> might be a good idea, especially in the light of recent discussions on the
>> SET-discuss which highlighted that EUR was the old mnmnonic for the ECO as
>> well as the new mnemonic for the Euro. However new currencies aren't
>> invented very often so this might not be a practical problem!
>> *	using letters. On the other hand USD is actually immediately
>> recognisable whereas 840 is not. This means that if we use a number, then we
>> would need a table to translate it into a name
>> 
>
>Any comments?
>
>Masaaki
>
>
>-----
>Masaaki Hiroya
>Systems Development Laboratory
>Hitachi, Ltd.
>email: [email-masked]
>tel: +81-44-966-9111(ext.3552)
>fax: +81-44-966-1796
>-----------------------------------------------------------------------
>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, 12 Mar 1999 14:33:28 +0900
To: [email-masked]
From: Masaaki Hiroya <[email-masked]>
Subject: Issues on Currency Code Types in IOTP
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

According to the IOTP specification, the currency code type should
be set to "ISO4217".  However, there are two types of currency codes
in "ISO4217".  One of them is a 3-letter alphabetic code such 
as "USD", "GBP" and "JPY". The other is a 3-digit numeric code
such as 840, 826 and 392.

As far as I know, Mondex uses alphabetic codes, but SET uses numeric codes.

Can both types defined in ISO4217 be used by IOTP?
If so, I think that the two currency code types should be distinguished 
by IOTP systems by using CurrencyCodeType Attributes in IOTP messages, 
for example: "ISO4217-Alphabet" and "ISO4217-Number"

Otherwise, we should define which currency code type should be used
in IOTP, just the alphabetic one or just the numeric one.

David's comments are as follows:
> The pros andcons as I see it are:
> *	using numbers. Follow the SET approach of using a numeric code. This
> might be a good idea, especially in the light of recent discussions on the
> SET-discuss which highlighted that EUR was the old mnmnonic for the ECO as
> well as the new mnemonic for the Euro. However new currencies aren't
> invented very often so this might not be a practical problem!
> *	using letters. On the other hand USD is actually immediately
> recognisable whereas 840 is not. This means that if we use a number, then we
> would need a table to translate it into a name
> 

Any comments?

Masaaki

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-trade-iotp-http-01.txt
Date: Wed, 03 Mar 1999 17:02:48 -0500
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

--NextPart

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

	Title		: Internet Open Trading Protocol (IOTP) HTTP Supplement
	Author(s)	: D. Eastlake 3rd, C. Smith
	Filename	: draft-ietf-trade-iotp-http-01.txt
	Pages		: 8
	Date		: 02-Mar-99
	
   Internet Open Trading Protocol (IOTP) messages will be carried as XML
   documents. As such, the goal of mapping to the transport layer is to
   ensure that the underlying XML documents are carried successfully
   between the various parties.
 
   This documents describes that mapping for the Hyper Text Transport
   Protocol (HTTP), Versions 1.0 and 1.1.

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-trade-iotp-http-01.txt

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

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

--OtherAccess--

--NextPart--

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-trade-iotp-v1.0-protocol-03.txt
Date: Wed, 03 Mar 1999 17:01:25 -0500
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

--NextPart

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

	Title		: Internet Open Trading Protocol - IOTP Version 1.0
	Author(s)	: D. Burdett
	Filename	: draft-ietf-trade-iotp-v1.0-protocol-03.txt
	Pages		: 305
	Date		: 02-Mar-99
	
  The Internet Open Trading Protocol (IOTP) provides an interoperable
  framework for Internet commerce. It is payment system independent and
  encapsulates payment systems such as SET, Mondex, CyberCash, DigiCash,
  GeldKarte, etc. IOTP is able to handle cases where such merchant roles
  as the shopping site, the payment handler, the Delivery Handler of
  goods or services, and the provider of customer support are performed
  by different parties or by one party.

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-trade-iotp-v1.0-protocol-03.txt
Date: Wed, 03 Mar 1999 17:01:25 -0500
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

--NextPart

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

	Title		: Internet Open Trading Protocol - IOTP Version 1.0
	Author(s)	: D. Burdett
	Filename	: draft-ietf-trade-iotp-v1.0-protocol-03.txt
	Pages		: 305
	Date		: 02-Mar-99
	
  The Internet Open Trading Protocol (IOTP) provides an interoperable
  framework for Internet commerce. It is payment system independent and
  encapsulates payment systems such as SET, Mondex, CyberCash, DigiCash,
  GeldKarte, etc. IOTP is able to handle cases where such merchant roles
  as the shopping site, the payment handler, the Delivery Handler of
  goods or services, and the provider of customer support are performed
  by different parties or by one party.

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-trade-iotp-http-01.txt
Date: Wed, 03 Mar 1999 17:02:48 -0500
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

--NextPart

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

	Title		: Internet Open Trading Protocol (IOTP) HTTP Supplement
	Author(s)	: D. Eastlake 3rd, C. Smith
	Filename	: draft-ietf-trade-iotp-http-01.txt
	Pages		: 8
	Date		: 02-Mar-99
	
   Internet Open Trading Protocol (IOTP) messages will be carried as XML
   documents. As such, the goal of mapping to the transport layer is to
   ensure that the underlying XML documents are carried successfully
   between the various parties.
 
   This documents describes that mapping for the Hyper Text Transport
   Protocol (HTTP), Versions 1.0 and 1.1.

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-trade-iotp-http-01.txt

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

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

--OtherAccess--

--NextPart--

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-trade-iotp-v1.0-dsig-00.txt
Date: Tue, 02 Mar 1999 18:25:02 -0500
Status: U
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

--NextPart

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-trade-iotp-v1.0-dsig-00.txt
Date: Tue, 02 Mar 1999 18:25:02 -0500
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

--NextPart

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

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

To: [email-masked]
Subject: TRADE WG meeting scheduled for Minneaplois
Date: Mon, 01 Mar 1999 12:53:41 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

The TRADE WG meeting ath the Minneapolis IETF meeting has been scheduled for
a two hour slot Wednesday afternoon as I requested:

	Wednesday, March 17 at 1300-1500
		other groups scheduled at that time: svrloc, delta-v, isis, pkix,
			slums, issll, mboned
===================================================================
 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]