Subject: Trade Questions
From: IETFMAIL <[email-masked]>
To: [email-masked]
Cc: Elad Sion <[email-masked]>
Date: Thu, 24 Dec 1998 09:27:28 +0200

Hello.

My name is Elad Sion, and I am pretty new to the trade list and protocols.
I find this protocol and its implications very interesting.

I do have a few questions, however about v1 and possibly about the
requirements of v2:

1. Is there a way to do bargaining? In many cases, especially when selling
over the internet
  with very little production costs, I would rather sell for less than not
at all. Is there a way to
  'renegotiate' the price?

2. What is the minimum number of round trips it takes to make a purchase?
Can this protocol
  be used with UDP? Is it possible to create a single offer (with an
expiration date) and make
  multiple purchases based on that offer? Is there an expiration date for
offers?

3. Is there a free protocol stack that I can get? Or some implementation
that I can test
  interoperability with?

Thanx a lot,

-- Elad

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available 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' <[email-masked]>
Subject: IOTP Net Locations
Date: Tue, 22 Dec 1998 01:38:50 -0000
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I've just been working through the following change ...

I. Net Locations. Change net locations in Protocol Options or Trading
Role Elements to reflect:
A. 	SuccessNetLocn - per transaction - Where the Consumer goes if the
transaction is successful
B. 	CancelNetLocn - per trading role - where the Consumer goes if the
Consumer cancels the transaction at some point
C. 	xxxRequestLocn - where xxx is payment, delivery, etc the location to
which incoming messages with either no errors or technical errors of any
Severity are sent. This means that anybody who sends a message with
errors in it receives a message that indicates there was an error
D.	ErrorLogNetLocn - per trading role, optional -  where the Consumer
sends IOTP messages if they receive an incoming message in which they
detect a technical error with Severity of HardError or TransientError.
Could be used to send error messages to the software company or some
other organisation responsible for fixing problems in the software which
sent the incoming message.
E.	ErrorNetLocn - per trading role - where the consumer goes after
receiving or generating an Error Block with severity of HardError or
TransientError
F.	Also need to provide guidelines which indicate how the consumer
determines which redirect location to use based on where they are

... and I've come up with a small problem in that the Consumer needs to
know, definitively, which is the "current" Trading Role which should be
used for cases B, D and E above. As it currently stands, the Consumer
has to infer which Organisation sent the message by knowing what sort of
block has been received and which trading role is responsible for it.

What I suggest is that:
*	we include in the Message Id Component (see section 3.3.2) an optional
SenderTradingRoleRef to identify the TradingRole to be used when
problems occur. This element is only optional for messages sent by the
Consumer role and is required for all others
*	we remove SenderNeLocn from the ProtocolOptions Component as its no
longer needed
*	we also add an ID attribute to the Trading Role Element (see section
6.5.2) so that it can be identified

Thoughts?

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]

To: [email-masked]
cc: [email-masked]
Subject: Minutes of 17 December Con Call
Date: Mon, 21 Dec 1998 10:35:30 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

There are primarily based on notes taken by Andrew Drapp.

Attendance:

Terry Allen	Veo
Donald Eastlake	IBM
David Burdett	MXI
Steve Howard	Certicom
Allen McNaughton	I-Net Systems
Michael Hardy	OECD
Andrew Drapp	Hitachi

Status of Documents:
Not much chnage since the last conference call and the IETF meeting.

Signatures:
It was discussed if XML digital signatures should be broken off of the
IETF IOTP group and a new independent group should be formed.  For now
work will continue by Richard Brown while the organizational aspects
are worked on.  What will happen with the W3C, that has security and
packaging on its agenda but has not done much, is unclear.

Steve Howard mentioned that the work on digital signatures appears to
be applicable to National Service/ID cards that some countries are
considering.  This would be a convenient method to offer other
services to citizens.

W3C micropayments:
The W3C has a micropayments initiative that includes payment scheme
selection but the overlap with IOTP is mostly theoretical.
Micropayment schemes are interested in embedded information in HTML
links so that you can piggyback a tiny payment along with the request
when the user clicks on the link and the like.  You might still want
the merchant to be able to say they accept several micropayment
schemes and the user software to automatically select one that the
user supports, but the heavy concern for minimum extra turn-arounds,
minimum extra bulk in messages, and maximum automatability add up to
make it substantially different.  Still, we should keep an eye on this
W3C effort.

Taxes:
Michael (from OECD) discussed his view on taxes within OTP, and how it
has been received on the mail list.  Michael was surprised that there
was a feeling that governments were trying to impose on trade.  All
international large scale business to business is already taxed via
settled procedures.  Business to Consumer transactions are small
enough that some sort of protocol, or combination of protocols will
need to be worked out.

Michael asked what channels he should use to find an official IOTP
liaison to the OECD to discuss technological issues with the OECD.
Donald suggested he contact Scott Bradner who is Vice Preisdent for
Standards of the Internet Society, the umbrella organization for the
IETF.  Many IETF external liaisons are via the IAB (Internet
Architecture Board).

Future Meetings:
Maybe MXI should host the meeting in London.  Since the meeting will
be in February, it should be in a warm place.  London is not warm.
So, southern Europe or southern America will also be considered.

Delays on version 1.0
1. Digital Signatures need to be decided upon (D. Eastlake).
2. IANA registration provisions needed (D. Eastlake).
3. Authentication exchanges need to be clarified (R. Brown).
4. Agreed protocol changes (D. Burdett).
5. SCCD payment methods should be included. (separate document, J. Sowler)

IOTP expansions:
An actual credit card transaction is similar to a government request
for a permit.  Information is transacted, and the government then 
needs to complete a large amount of verification and processing on 
the back end.  According to Steve, it should be possible to expand 
IOTP to include these other functions that do not revolve around
a payment.

Thanks,
Donald

Note: next conferecne call is January 7th.
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available 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: Con Call 17 December 98
Date: Wed, 16 Dec 1998 14:25:05 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This is a reminder that there is a TRADE WG conference call tomorrow
at 9am eastern US time on Thursday.  Call in number is
	212-547-0300 and passcode is
	90216.

Thanks,
Donald
=================================================================
 Donald E. Eastlake 3rd  +1 914-276-2668  [email-masked]
 65 Sindegan 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]

From: Andrew Drapp <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RE: General Question Related to IOTP V 1
Date: Mon, 14 Dec 1998 13:15:12 +0900
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Tom and David,

I have sniped the messages you sent to the ietf list, and
put my responses after them.

[Tom]
>> Through one of the most well known merchants,
>> we performed a statistical analysis and found that the optimal buying
>> experience was no more than 3 mouse clicks after the consumer had selected
>> the products and decided to buy. There is an approximately 30 percent
>> chance the consumer will cancel the order if they are forced to a 4th
>> click. This continues up, with the more clicks.

[David]
> *	once the consumer has clicked 'pay' there shouldn't be any need for
> any more click's since the swapping of data to carry out the payment
> (e.g. between the payment handler/merchant and the payment handler)
> should continue without consumer intervention

[Andrew]
If depends on which click you say 'pay' is.  In our demo version of IOTP,
the consumer presses several buttons that could be labeled 'pay'.  The
first time is when viewing a shopping card, the user presses the purchase
button.  The mall server will then ask for shipping information if required.
There are still quite a few clicks before the transaction is done.  After that,
just before IOTP starts and there is another confirmation button.  There are
still quite a few clicks till the transaction is complete.  The third 'pay' button
is when the IOTP invoice is presented, the consumer confirms it, and 
goes on to the payment step.  There are still several mouse clicks after 
this button.  In the payment exchange, in SET, the consumer must digitally
sign the payment, this requires an additional click.  This sign could also
be considered a pay button.  It is the same with Mondex.  we ask the
consumer to confirm a payment just before it actually occurs.

shopping cart, it takes quite a number of clicks to complete the transaction.
I think Toms complaint is a valid one.  I also think we are on the right
track to solving it.  With the use of auth request, the merchant can 
retrieve shipping information.  This will cut down the number of clicks
required to complete the transaction significantly.  As David mentioned,
the IOTP aware wallet also simplifies payment by eliminating the need to
re-enter credit card information on every purchase.  If the software 
implementation had a few switches, this could also greatly reduce the
number of steps to complete a transaction, such as "AutoConfirm invoices/
receipts/payments/etc.".  

Regards,

Andrew Drapp

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

Date: Thu, 10 Dec 1998 18:06:57 -0800
To: [email-masked]
From: David Burdett <[email-masked]>
Subject: RE: General Question Related to IOTP V 1
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Tom

Thanks for your comments. I've responded in the text marked with >>>.

It's fine by me if you post this (or any reply) to the list.

David

>----------
>From: 	Tom Arnold[SMTP:[email-masked]]
>Sent: 	06 December 1998 20:11
>To: 	David Burdett; Donald E. Eastlake 3rd
>Subject: 	General Question Related to IOTP V 1
>
>David and Donald,
>
>I'm not certain whether to post this to the list or not as of yet as most
>of the dialog are between people that are very familiar with IOTP and I'm
>still trying to come up to speed so that I can both understand the protocol
>and offer constructive comments. As such, I have a few general questions....
>
>MOST GENERAL: IOTP seems to imply a set of trading roles and a specific
>process. I can see the implementation if a stored-value instrument was
>being presented at some kind of terminal and there was a need to handshake
>and chatter between the consumer, merchant and payment handler. But in the
>web envirnonment where the number of clicks that a consumer is forced to
>perform, this may not be viable. It seems that a consumer might submit
>purchase information to a merchant, and the merchant would proceed and
>process the consumer's payment, if the payment authorization suceeds, the
>merchant processes the delivery exchange on behalf of the consumer, then
>upon delivery, settles the payment transaction. In essence, the consumer
>has concluded a full buying experience with a single button click and never
>distracted from the immediate gratification of the experience. My fear (and
>experience) is that if a system begins to chatter with a consumer, the
>concept of buyer-remorse or frustration sets in and the buyer is more
>likely to cancel the order. Through one of the most well known merchants,
>we performed a statistical analysis and found that the optimal buying
>experience was no more than 3 mouse clicks after the consumer had selected
>the products and decided to buy. There is an approximately 30 percent
>chance the consumer will cancel the order if they are forced to a 4th
>click. This continues up, with the more clicks.
>>>I don't think that in practice you will get the chatter that you
anticipate. The thinking is as follows:
Firstly, before the consumer can click the 'pay' button, he must:
*	decide what he is going to buy
*	decide how to pay, e.g. which credit card, etc,
Once this is known the Consumer can then click the payment and the
payment can progress. A couple of points:
*	unless the consumer knows what they want to buy in advance (e.g. they
have a CD-Rom catalog) and they know what payment methods the merchant
accepts which will only be the case if the consumer already knows the
merchant well, then there inevitably has to be some chatter between the
merchant and the consumer, to discover this information. What IOTP does
is allow automation of part of this process as the merchant can present
a list of payment brands which are accepted (in a structured XML form)
from which the consumer can then make a selection. This means that the
selection process can be automated since the consumer's software can
remember the payment instruments they  have so that the consumer doesn't
have to re-enter the credit card numbers. So in this part of IOTP I
don't think the number of click's which the consumer has to do is
increased they're just done differently
*	once the consumer has clicked 'pay' there shouldn't be any need for
any more click's since the swapping of data to carry out the payment
(e.g. between the payment handler/merchant and the payment handler)
should continue without consumer intervention
*	if the consumer really does know what he wants to buy and how he can
pay there is no reason why IOTP should not allow an 'offer request'
message, from the consumer, which sends this information to the
merchant. The merchant could then, as you suggest, accept the payment,
issue a purchase and payment receipt and deliver the goods in the
response. In version 1.0 of IOTP this almost possible since you can
combine the payment response and delivery response in the same IOTP
message. 
*	I don't think that it will be the *normal* case for the consumer to
know what he wants to buy and how he's going to pay without being in
touch with the merchant, probably on the net, in advance.
>>>
>
>Some more specific questions:
>**** (Payment Exchange: How is the offer protected from tampering by 
>the consumer? In our experience, we had a situation where a consumer
>tampered with a digital offer and changed pricing and product information
>just to prove they could do it. Could the consumer change data in an offer
>inorder to alter the merchant's system behavior?)
>>>Merchants *can* digitally sign the offer which should make it tamper proof.
The payment information in the offer, including the signature, are
then sent to the Payment Handler who should check the signature to
make sure it has not been tampered with. If it has been tampered with
then the payment would fail. In either case, the merchant's system
behaviour would not be changed. The reason signatures are optional
are several, for example:
*	the consumer may be a very thin client and can't actually check
signatures anyway, or
*	the payment handler and merchant may have access to each other's
records (e.g. they're the same company) so the payment handler can check
if the offer has been changed and stop the transaction if it has without
the overhead of signatures.
>>>
>
>**** (Payment Exchange: How will merchant be aware of this out-of-band
>payment exchange? How will they know from a trusted entity that the payment
>was approved/cleared? In a SET pilot that we did in Denmark, we observed
>that the data being exchanged between the wallet running on a consumer's
>desktop and their browser was spoofable. In essence, this wallet upon
>receiving an authorization, would then fire and accept URL where the
>consumer, in this case, could take delivery of their product. Upon
>observing this, merchants immediately requested an out-of-band status that
>would validate to the payment handler that the specific transaction
>referenced in any accept URL was infact valid and successful. Please note:
>that this is a gross over simplification of the technicology but is offered
>as a simple question.)
>>> IOTP doesn't use "accept URLs" for delivery, it used a signed XML message
instead. How it works is as follows ... At the end of the payment
exchange, if signatures are being used, the payment handler creates a
new digital signature that signs the payment receipt as well as the
*signature on the offer response*. This effectively means that the
payment handler asserts that the payment has been made. In order to
get delivery of goods, the following are sent to the Delivery
Handler:
*	the "payment receipt signature", 
*	the "offer response signature"; 
*	a description of the goods being purchased in the Order component"
*	a description of how to do the delivery (delivery component)
*	the organisation component which describes the Merchant
*	the organisation component which describes the Payment Handler
The delivery handler then checks:
*	the Offer response signatue to check that:
*	the merchant who generated the signature is known (checks the
Merchant's Organisation component)
*	the Order description is valid (its signed by the Merchant)
*	Delivery information is valid (signed by the Merchant)
*	the Payment Handler may be a payment handler for this purchase (the
Payment Handler Organisation component is signed by the Merchant)
*	the Payment Receipt signature, to check that 
*	the payment has been made by the Payment Handler known to the
Merchant, and
*	the payment has actually been made (i.e. it signs the offer response
signature)
The Delivery also has "from" amd "to" dates which constrain its
validity.
The Delivery Handler should only do a delivery if all the checks
succeed. There is no need to interrogate a separate third party since
the assurance that delivery can occur is included in the signatures
which the consumer forwards on.
Finally there is still a need for the payment handler and delivery
handler to inform the merchant of the results of the transaction but
this can occur out of band, in batch, and after the transaction has
completed.
>>>
>
>*** (Delivery Exchange: How does this mechanism support impulse buying? I'm
>thinking of Web sites here. Some of the MOST successful sites on the Web
>support one-click, instant gratification. My fear is that by making the
>consumer work through some payment authorization transaction and then onto
>a fulfillment transaction may cause implementation problems. This was the
>primary problem that we saw in the use of a client/consumer wallet for
>payment. There was a significant percent of transactions that went into a
>"wallet wakeup" state and never further. Our only assumption is that the
>consumer bailed out.
> 
>It seems that there are numerous validation steps involved. Why wouldn't 
>the merchant do this for the consumer?)
>>>How do the "instant gratification" web sites work, from my experience, all
the "one-click" does is add something you want to buy to your
shopping cart. IOTP does not address this part of the shopping
experience since we didn't think that merchant's would welcome us
suggesting how their consumers should shop in their store. However
once you get to the "check-out" you still have to fill in credit card
numbers and the like (don't you?) This is where IOTP helps and allows
more automated selection of credit cards etc.
>You say ... "My fear is that by making the consumer work through some payment
>authorization transaction and then onto a fulfillment transaction may cause
implementation problems." IOTP doesn't require this. Once the consumer
accepts the Offer response, all other messages should flow automatically
without consumer intervention (although it's probably a good idea to let
him know what's going on).
I agree with your comments about transactions that go into a"wallet
wakup" state and never further... I know I've done it myself. I think
the main reasons are lack of familiarity and lack of perceived benefit.
Familiarity problems will go away (with effort, education and
experience!) and IOTP offers significant benefit in terms of receipts
which can be used to get problems fixed, feeding into software like
Quicken and even potentially for tax purposes.
>>>

>*** (Section 3.2 The first paragraph refers to organizations shouldn't this
>be "trading roles"?  )
>>> Yes. Trading roles would be a better term to use
>>>
>
>
>There will be more to follow from me.  If you would prefer, I can post this
>to the list in an effort to help educate and stimulate some discussion. 
>
>Thanks.
>
>
>
>Tom Arnold
>Vice President of Engineering
>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: "[email-masked]'" <[email-masked]>,  'Kaye Caldwell' <[email-masked]>
Subject: RE: IOTP in general
Date: Thu, 10 Dec 1998 14:58:51 -0000
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Kaye

>You asked if "IOTP has provisions for delivery of additional documents to the
consumer, such as warranties, licenses, or privacy agreements?"

IOTP has an XML element called an "Order" which can contain a
description of, for example, the goods being purchased. IOTP does not
impose a rigid structure on what it the description should contain and
allows merchants to define the content in whatever way they want, for
example HTML, plain text, XML, or some proprietary format which that
merchant has agreed with its customers. This means that, in this text
the Merchant can easily place things like warranties, licenses or
privacy agreements or whatever else he either wants to do or is required
to do by law or convention.

David

>----------
>From: 	Kaye Caldwell[SMTP:[email-masked]]
>Sent: 	09 December 1998 20:22
>To: 	[email-masked]
>Subject: 	IOTP in general
>
>Pardon what is probably very basic question - but can someone tell me if IOTP
>has provisions for delivery of additional documents to the consumer, such as
>warranties, licenses, or privacy agreements?
>- Kaye
>
>===================================
>Kaye Caldwell,  Policy Director
>CommerceNet 
>
>http://www.Commerce.net
>E-mail: [email-masked]
>Phone: (831) 479-8743    Fax: (408) 273-6345
>===================================
>-----------------------------------------------------------------------
>Message addressed to: [email-masked]
>Archive available at: http://www.elistx.com/archives/ietf-trade/
>To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
>body to: [email-masked]
>
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

Date: Wed, 09 Dec 1998 11:43:48 -0800
To: [email-masked], [email-masked]
From: Kaye Caldwell <[email-masked]>
Subject: RE: IOTP and taxes
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

At 05:45 PM 12/9/98 +0100, [email-masked] wrote:

>A couple of points on the first few paragraphs:
>
>By running the few paragraphs together in this fashion and by quoting me by
>name, some readers may be confused into thinking that the OECD is
>responsible for U.S. sub-national tax policy. This is not the case. The
>30,000 tax jurisdictions are a domestic U.S. challenge over which the OECD
>has no influence or control.

Sorry, Michael, I did not mean to cause confusion on that issue.=A0 However,=
 it
is the U.S. sub-national tax issues that=A0 will affect the international
community if we don't resolve them, since our consumption taxes are
sub-national rather than national.

>The OECD has not suggested that the answers to the who, what, where, when
>and how much questions need necessarily be transported together. The
>information does need to be found somewhere in the audit trail. In trying=
 to
>visualise answers to the questions you might consider a typical physical
>invoice which can include the customer name and shipping or billing=
 address,
>the vendor name and address, a date, a description of the order and an
>amount payable.

I'd disagree on the point that the information needs to be found somewhere -
where is that information found when someone makes a purchase from a=
 physical
store?=A0 A store receipt typically contains store name, date, product
description, tax amount, total amount but identity of the buyer is not
typically part of the record (although sometimes it is).

>Part of the neutrality approach proposed by the OECD would see that the
>existing balance between individual's rights of privacy and the necessities
>of tax administration are maintained. For example the OECD recognises that
>the use of encryption is legitimate in commercial transactions.
>
>The OECD has not proposed a blanket destination based taxation. In
>consumption tax (which the US does not have at the Federal level), the OECD
>has proposed that taxation should be at the place of consumption (because
>this is what consumption tax is all about). The alternative to an
>internationally consistent approach could result in something like country=
 A
>taxing consumption at place of supply and country B taxing consumption at
>place of consumption. In this case a sale from country A to country B would
>result in double taxation for the consumer in country B.

Ths question of course is where does consumption take place? That will be a
difficult determination in the case of consumption via the Internet.=A0 Also
I am
curious to know how the OECD handles purchases in stores by residents of=
 other
countries - for example if I purchase a new article of clothing while on
vacation I will clearly consume that article over a period of years - most=
 of
it in my country of residence, not the country I was vacationing in when I
purchased the item.=A0 Which country taxes that transaction in the OECD -=
 the
country of sale or the country of consumption?=20

>In the case of direct taxes, like income tax, the seller, the merchant, is
>usually responsible for their own income tax and so "seller responsibility"
>is the law. In relation to indirect taxes, the OECD has not proposed=
 "seller
>collection" as a solution, but some business groups have asked the OECD to
>examine such options based on their experience with pilot trials conducted
>for commercial, not taxation, reasons.

Here in the U.S., seller collection works fine when the seller is collecting
for their own state - but when that is extended across state borders it has
created such a mess that the U.S. Supreme Court has said that states can't
require seller collection unles the seller is physically present in the
buyer's
state.=A0 Furthermore, the U.S. Supreme Court invited Congress to overrule=
 them
if Congress so desired.=A0 Congress has since expressly voted DOWN overrulin=
g
the
Supreme Court on that issue, by a margin of 2-1.

>There are a number of mechanisms for collecting consumption tax that do not
>involve "seller collection" and these are in use in some countries for the
>taxation of conventional commerce. As the U.S. does not have a Federal=
 level
>consumption tax, I think that the political difficulties alluded to may be
>to do with sub-Federal taxation, which is not something that the OECD can
>address.=20

Yes, absolutely, the political difficulties I was referring to are in the=
 U.S.
with respect to state taxation of interstate commerce.=A0 I would be=
 extremely
interested in hearing about the mechanisms you refer to that do not involve
seller collection, especially as regard to consumer purchases.

>If the "the tax agencies" you mean the Federal level Revenue authorities of
>OECD countries, lets be clear that the OECD has not suggested that the
>seller should collect a home address with each transaction.

I agree that they have not, but it was certainly hinted at by one OECD=
 member
at the tax meeting in October.

>In the physical world the seller (even, I understand, in California) will
>probably want you to authenticate yourself by comparing your signature on
>the credit card receipt with the one on the back of your card. The seller
>will have also obtained a copy of your card number and it may be possible,
>through the issuing bank, to determine the country in which the card was
>issued and where the card holder resides.=20

Issuing banks are reluctant to provide address information.=A0 It may also=
 be
illegal in California.=A0 It is certainly illegal for the merchant to ask fo=
r
it,
the question of whether it is illegal for the merchant to obtain it from=
 other
parties by use of the credit card number has not been litigated.=A0=20

>This linkage of information is the
>audit trail. I'm not suggesting the seller can, or should, be given access
>to the buyer's residency information, I'm just stating that the seller=
 holds
>a piece of the chain, which links to another party with additional
>information. Each party along the audit trail only needs to keep a record=
 of
>the relevant information for their part of the chain, so that privacy can=
 be
>protected by separation of data. However, if the need arises, and their is
>legal justification and sanction, the audit trail can be reconstructed from
>many sources to give a complete picture to verify an issue.

I agree with this analysis, however it precludes seller collection of
destination based taxes.

>Also, while the EU may have rejected the US proposed merchant privacy
>policy, the OECD is not the EU. The OECD includes such countries as the
>U.S., Canada, Mexico, Japan, Korea, Australia and New Zealand and is a
>consensus building organisation. It is a mistake to characterise the OECD
>and the EU as holding the same views given they have very different
>membership.=20

Again, I agree that the EU and OECD have different views, unfortunately we
must
deal with both and there is the realistic danger that one will require what
the
other prohibits.

>> In general, I would hesitate to deal with the tax issues, particularly in
>> the
>> U.S., until the recommendations of the Internet Tax Freedom Act are
>> published
>> AND ENACTED.=A0=20
>>=20
>The U.S. Internet Tax Freedom Act deals primarily with U.S. sub-Federal
>taxation and so caution IN the U.S. might be warranted.=20
>
>However, at the international level, where the OECD has an international
>co-ordination role, the U.S. view is probably best shown in Presidential
>Directive 6 in the First Annual Report of the U.S. Government Working Group
>on Electronic Commerce, published in November, which states:=A0 "I direct=
 the
>Secretary of the Treasury to work with ... foreign governments to achieve
>agreements that will ensure ...=A0 that existing taxes should be applied in
>ways that avoid inconsistent national tax jurisdictions and double=
 taxation;
>and that tax systems treat economically similar transactions equally,
>regardless of whether such transactions occur through electronic means or
>through more conventional channels of commerce."
>
>The OECD is trying to achieve the application of existing taxes in a=
 neutral
>fashion compared with conventional commerce so I do not believe that
>hesitation is required at this level.
>
So long as "application of existing taxes in a neutral fashion compared with
conventional commerce" is adhered to I would agree, however it is not clear=
 to
me that this is the case.=A0=A0 It is certainly NOT the case in the U.S. whe=
n
local
commerce and mail order commerce are compared.

>> I would also encourage you to consider privacy issues when it comes to
>> consumer
>> purchasing mechanisms.=A0 There is no reason that a consumer should be
>> forced to
>> provide ANY personally identifiable information in order to complete a
>> transaction on the Internet, any more than they would do so in a store on
>> Main
>> Street.
>>=20
>I would agree that privacy needs to be taken into account and that there is
>no reason why a business transaction conducted by electronic commerce means
>should require the disclosure of any more personal information than the=
 same
>transaction conducted on Main Street. The OECD has not suggested otherwise.
>

I'm looking forward to working with the OECD technical advisory groups to
ensure that we can make this a reality.=A0 I do believe it's possible.

- Kaye

=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,  Policy Director
CommerceNet=20

http://www.Commerce.net
E-mail: [email-masked]
Phone: (831) 479-8743    Fax: (408) 273-6345
=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]

Date: Wed, 09 Dec 1998 20:22:44 -0800
To: [email-masked]
From: Kaye Caldwell <[email-masked]>
Subject: IOTP in general
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Pardon what is probably very basic question - but can someone tell me if IOTP
has provisions for delivery of additional documents to the consumer, such as
warranties, licenses, or privacy agreements?
- Kaye

===================================
Kaye Caldwell,  Policy Director
CommerceNet 

http://www.Commerce.net
E-mail: [email-masked]
Phone: (831) 479-8743    Fax: (408) 273-6345
===================================
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available 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, 9 Dec 1998 16:54:31 -0800
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Orlando follow-up
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Kent Davidson wrote in part:

| * Document size
| 	Speaking of KISS, the draft-ietf-trade-iotp-v1.0-protocol-02.txt document is 239 pages long, minus about 4-5 pages of XML intro, 10 pages of the DTD, and a handful of pages of credits and a glossary. Still, it's more than 200 pages long, and probably would take one about a day to just read through, and probably 6 months to implement. I have a concern that the complexity of the protocol will stifle its adoption, as well as limit implementation to a select few. 

I agree it takes awhile.  OTOH, it's a complex problem, very wrinkly.

| 	If anyone else shares these concerns, I would be willing to donate some time to break the document up into several documents for 1.0 to aid in allowing people to comprehend what IOTP is, as well as letting implementation folks digest the information in smaller chunks. Otherwise, we can perhaps do this post fact in 1.1, 1.5, or whatever the new number for 2.0 will be. (another issue brought up in the meeting)

Perhaps what would be most useful would be (nonnormative) short
expositions of IOTP's world view and approaches to major architectural
issues (such as signing of content, which is rather neat and could
be reused by other specifications were it accessible to readers outside
the full draft).  

| * Taxation
| 	One member of the audience said that he felt that the standard would fail if the 1.0 didn't address taxes even in the most minimum way, like just being able to add a field which says this much of the total amount is taxes. 

This is out of scope, see next.

| 	I think we all agree that taxes and taxation is a huge rat-hole, however, I started to look for a way to see if we could add a field or two to the XML in order to put very minimal support for taxes.
| 	I will admit that I am rather new to IOTP and this list, but it seems as if there is no mechanism in OTP to simply send an invoiced list of goods with prices, e.g. 
| 
| 	"Ladies jacket" $245.00
| 	"Umbrella"	$ 45.00
| To which it would be rather simple to add
| 	"FL State tax"	$ 12.95

Right.  IOTP wisely draws the line between payment and all that goes
before.  It is likely that some matters that IOTP allows to be negotiated
as part of payment (what payment instrument am I going to use) will in
some cases be settled in the course of shopping before you get to the
IOTP phase, but it is a Real Good Idea to allow invoices in IOTP only
as included binary content, as a sort of reference.  Other initiatives
are working on how to mark up invoices.

| 	The closest thing which seems to encapsulate this information is the "Order" element, which is included in the OfferRespBlk and DeliveryReqBlk. However, the spec only details a single ShortDesc to describe the goods, and the Order element is included only ONCE.
| 	I would infer that this is because OTP is not meant to be a bill presentment protocol. If I am incorrect, please clarify.

Yes, nor is it meant to be an online shopping protocol.  Think of how long
the document would be if it were ...

| * XML Standards for "common" elements
| 	I was wondering if anyone has looked into using some form of standard DTDs already in XML for consumer/customer address and name information. I haven't been following the XML standards groups well, but perhaps someone has? The element I am referring to is found in the IOTP spec: the PostalAddress element. If so, in the interest of re-use, I think it would be wise to adopt the XML standard version of these, or at a minimum, the field names.

There isn't an XML standard version of this info, and in practical
use, there are several ways of handling addresses.  IOTP's is a reasonable
one; EDI has a different format (though for all I know, in practice EDI
handles addresses variously).  For the Common Business Library (CBL), which 
is a prototype of what you want, I used an EDI-like approach.  I am hoping
that Commerce Net's ECO Framework Working Group will identify appropriate
standards for such things - for addresses there may be multiple formats,
who knows.  

Specifically on IOTP's address structure, it has the great advantage of
accomodating nonordinary address information and marking up only the
parts you can expect to be in every address.

A somewhat dated version of CBL is available at Veo's web site (see sig);
I hope to get an improved version (and in an XML schema language) out 
sometime in January.

regards, Terry Allen

Terry Allen				Veo Systems, Inc.
Business Language Designer	        2440 W. El Camino Real
tallen[at]sonic.net                     Mountain View, Calif., 94040
Common Business Library - available at  http://www.veosystems.com/
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

Date: Wed, 09 Dec 1998 17:12:39 -0500
To: [email-masked]
From: "Kent M. Davidson" <[email-masked]>
Subject: Ad-hoc Orlando Minutes
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I've taken my notes from the Orlando IOTP TRADE meeting and enclosed it for those who were unable to attend. 

This closely resembles Donald's slides, with minor mods. I've also tried to include as many of the questions that came up from the crowd as well, and some answers, though I wasn't able to get everything.

I'll follow up with some of the issues that came up.

*** Internet Open Trading Protocol (IOTP) WG 1:00P - 3:00P 12/9/98

Agenda:
- Agenda Bashing
- draft-rfced-info-blinov-00.txt
	- SCMP (Author: Tom Arnold, Cybersource)
- Status of Documents
	- IOTP Protocol v1.0
		- draft-ietf-trade-iotp-protocol-v1.0-00.txt
		- See message of 17 November 1998
			- packaged content
				- adding names, several instances of content
			- Use trading role component instead of payment component
			- BrandID, IANA services
				- naming schemes for CC
				- SET naming scheme
			- Logging, Sucess/Error/Cancel net locations
				- what URL to go to to log response errors
				- what URL to go to for different errors
			- Authentication, optional preface to other transactions, Auth Response, signature details
				- can send entity/naming/mailing address information in authentication 

	- XML DSIG - draft-trade-xml-sig-00.txt
		- May become a separate WG
	- Architecture
		- posted to list 24 November 1998
	- HTTP Supplement
		"draft-ietf-trade-iotp-http-00.txt"
		- Pragma nocache is HTTP v1.0 only
		- POST responses are not cached
		- See what can be stolen from Application/XML RFC
		- Update for changes to continuation URLs
		- Use GET for Success/Error/Cancel
	- SET Supplement
		- up to draft version 4
		- Packaged Content Issues
		- BrandID, SET:x:y:z versus IOTP:abc
		- (IOTP is not dependent on SET or any other specific payment scheme)
	- SCCD Supplement (Secure Channel Credit Debit)
		- Still to be revised by Jonathan Sowler
- Implementations
	- V0.9 - demo/private
		- Hitachi
		- Royal Bank of Canada
	- V1.0
		- British Telecom
		- CyberSource
		- Differential
		- Hitachi
		- Royal Bank of Canada
	Q?: Anyone talking with customers
		Royal bank talking with ATMs

- v2.0 - form, content
	"talk of renaming to 1.5"
	- Evolutionary change from v1.0
	- "Still water" between v1.0 and v2.0
	- v1.0 doc too big and monolithic
		- issue some subsets of v1.0 with implementation feedback as "v1.1", e.g. "IOTP Messaging"
	- FORM
		- see 19 Nov. message to list
		- split into many documents
			- Overview, Messaging, Offer Excahnge, Payment Exchange, Delivery Exchange, Authentication Exchange, Baseline Transactions, Dynamic Transactions, Customer Care Exchange, Inter-Server Exchange, Payment Supplements, Transport Supplements
	- CONTENT
		- Dynamic Transaction Structuring
		- Offer request block
		- Auth Method Selection
			- Q? Look at RFC 2284, EAP
		- Inter-server messages
		- Cust Care Transaction
		- Recurring Transactions
		- Order Payment Annotation
			- order description for customer
			- adding amounts
		- Fine Tune IOTP Extension Mechanism
			- general to extend via domain name extension names
			- Only add for packaged content
	- HTML Form Field Names
		- Catalog/Standardize HTML Form Field Names for
			- Identification, ship to, etc.
			- IOTP spoken indication
		- Potential Sources
			- Microsoft Wallet special field names
			- SET CA Form field designations
			- Real world merchant sites
			- Java wallet, others?
		- Privacy Implications (P3P)
			(Privacy and Prefereces Platform)
		Q? Anyone want to help standardize this? Working on this?
		A: Slippery slope - privacy considerations.
- Future Con Calls/Meetings
	- Trying co call - every 2 weeks
		- Dec 3 and 17 at 1-212-547-0300
		- Jan 7 and 21 at 1-212-547-0212
		- all with passcode 90216
	- Meeting in US/Europe
		- Feb. 8-11, 1999
	- Meeting at March 1999 IETF
- "Taxation"
	- No taxation hooks in v1.0
	- Current v2.0 ideas include
		- optional way for meracht to indicate what part of purchase price was for taxes (and shipping, etc.)
		- optional way for role to send taxes to tax authority
	- Consumer location
	Q? Buy 10 of an electronic software, not shipped 10 to 1 addres, instead send 9 of my friends to perform a will-call
	A: OBI is more B2B, perhaps need to expand definition of monolithic Consumer to additional definitions
	Q? Need a way to describe basic tax and label it, otherwise IOTP will not succeed
	Q? Merchants selling physical goods, can treat it as a mail order and handle taxation that way
	Q? Will need to send additional attributes to compute tax: Non-profit, reseller, etc. Need standardized attributes.
	Q? Don't want to write the international sales clerk manual

___________________________________________
Kent M. Davidson, VP of Advanced Technology
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]

Date: Wed, 09 Dec 1998 17:08:24 -0500
To: [email-masked]
From: "Kent M. Davidson" <[email-masked]>
Subject: Orlando follow-up
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Based on some of the feedback I heard at the Orlando meeting, here are some of the issues that came up, with some of my own issues and editorializing:

* HTML Forms
	Donald asked for someone to perhaps take on standardizing or coming up with a spec for HTML Form inputs to originate or drive a IOTP session, specifically, for entering consumer data such as name, address, etc. I would be willing to donate some time to this effort if we can come up with a scope of the problem.

* Authentication
	Someone mentioned taking a look at RFC 2284, EAP (Extensible Authentication Protocol?), for the Authentication and Authentication Selection. My cursory opinion is that reuse is better than reinvention, although, don't want to slow things down. If there is interest (KISS!) from the list I will take a look at the RFC and see if it even applies.

* Document size
	Speaking of KISS, the draft-ietf-trade-iotp-v1.0-protocol-02.txt document is 239 pages long, minus about 4-5 pages of XML intro, 10 pages of the DTD, and a handful of pages of credits and a glossary. Still, it's more than 200 pages long, and probably would take one about a day to just read through, and probably 6 months to implement. I have a concern that the complexity of the protocol will stifle its adoption, as well as limit implementation to a select few. 
	If anyone else shares these concerns, I would be willing to donate some time to break the document up into several documents for 1.0 to aid in allowing people to comprehend what IOTP is, as well as letting implementation folks digest the information in smaller chunks. Otherwise, we can perhaps do this post fact in 1.1, 1.5, or whatever the new number for 2.0 will be. (another issue brought up in the meeting)

* Taxation
	One member of the audience said that he felt that the standard would fail if the 1.0 didn't address taxes even in the most minimum way, like just being able to add a field which says this much of the total amount is taxes. 
	I think we all agree that taxes and taxation is a huge rat-hole, however, I started to look for a way to see if we could add a field or two to the XML in order to put very minimal support for taxes.
	I will admit that I am rather new to IOTP and this list, but it seems as if there is no mechanism in OTP to simply send an invoiced list of goods with prices, e.g. 

	"Ladies jacket" $245.00
	"Umbrella"	$ 45.00
To which it would be rather simple to add
	"FL State tax"	$ 12.95

	The closest thing which seems to encapsulate this information is the "Order" element, which is included in the OfferRespBlk and DeliveryReqBlk. However, the spec only details a single ShortDesc to describe the goods, and the Order element is included only ONCE.
	I would infer that this is because OTP is not meant to be a bill presentment protocol. If I am incorrect, please clarify.
	Any comments on this?

* Typos/Inconsistencies and other errors
	I have identified various typos and inconsistencies in the -02 version of the draft. I will draft a separate mail covering the issues I've found.

* XML Standards for "common" elements
	I was wondering if anyone has looked into using some form of standard DTDs already in XML for consumer/customer address and name information. I haven't been following the XML standards groups well, but perhaps someone has? The element I am referring to is found in the IOTP spec: the PostalAddress element. If so, in the interest of re-use, I think it would be wise to adopt the XML standard version of these, or at a minimum, the field names.

Thanks, and looking forward to your comments,

-Kent.

___________________________________________
Kent M. Davidson, VP of Advanced Technology
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]
Subject: RE: IOTP and taxes
Date: Wed, 9 Dec 1998 17:45:53 +0100 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

> Sorry to drop into the tax conversation late, I just became aware of the
> discussion.
> 
> The problem with the tax situation as it now exists is that the question
> of
> what entity will collect the tax owed by the purchaser, and on what basis,
> is
> in a state of flux.  Certainly in the U.S., it is not now the
> responsibility of
> many merchants to collect the tax, although certainly the tax agencies
> would
> prefer to be able to compel them to do so.  The U.S. Supreme Court and
> Congress
> have declined to allow that, due to the complexities of complying with up
> to
> 30,000 possible taxing jurisdicitons in the U.S. alone, all with different
> tax
> rates and (to a lesser extent) which tax different products.
> 
> One of the other big issues in this area is privacy.  Mr. Hardy put it
> exactly
> right: taxes mean "who, what, where, when, and how much".  Transporting
> all of
> this information presents severe privacy issues.  When it comes to taxes
> we
> cannot have all 3 of: privacy, destination-based taxation, and seller
> collection.  Two of the three can be achieved, but NOT all three.  There
> are
> mechanisms for dealing with this that do NOT involve seller collection, or
> do
> not involve destination-based taxation, however achieving them is
> politically
> difficult in the U.S and perhaps as well in Europe.
> 
A couple of points on the first few paragraphs:

By running the few paragraphs together in this fashion and by quoting me by
name, some readers may be confused into thinking that the OECD is
responsible for U.S. sub-national tax policy. This is not the case. The
30,000 tax jurisdictions are a domestic U.S. challenge over which the OECD
has no influence or control.

The OECD has not suggested that the answers to the who, what, where, when
and how much questions need necessarily be transported together. The
information does need to be found somewhere in the audit trail. In trying to
visualise answers to the questions you might consider a typical physical
invoice which can include the customer name and shipping or billing address,
the vendor name and address, a date, a description of the order and an
amount payable.

Part of the neutrality approach proposed by the OECD would see that the
existing balance between individual's rights of privacy and the necessities
of tax administration are maintained. For example the OECD recognises that
the use of encryption is legitimate in commercial transactions.

The OECD has not proposed a blanket destination based taxation. In
consumption tax (which the US does not have at the Federal level), the OECD
has proposed that taxation should be at the place of consumption (because
this is what consumption tax is all about). The alternative to an
internationally consistent approach could result in something like country A
taxing consumption at place of supply and country B taxing consumption at
place of consumption. In this case a sale from country A to country B would
result in double taxation for the consumer in country B.

In the case of direct taxes, like income tax, the OECD is adopting a neutral
approach so that if a conventional sale results in a business in country A
having to pay income tax on the profit, then you should get the same result
if the businesses uses electronic commerce to complete the sale.

In the case of direct taxes, like income tax, the seller, the merchant, is
usually responsible for their own income tax and so "seller responsibility"
is the law. In relation to indirect taxes, the OECD has not proposed "seller
collection" as a solution, but some business groups have asked the OECD to
examine such options based on their experience with pilot trials conducted
for commercial, not taxation, reasons.

There are a number of mechanisms for collecting consumption tax that do not
involve "seller collection" and these are in use in some countries for the
taxation of conventional commerce. As the U.S. does not have a Federal level
consumption tax, I think that the political difficulties alluded to may be
to do with sub-Federal taxation, which is not something that the OECD can
address. 

> To make the issue more clear: imagine if every time you used your credit
> card
> in a store the seller collected your home address (and required you to
> provide
> ID to prove its accuracy).  This is what the tax agencies want on the
> Internet.  It is ILLEGAL in California to ask for that data. And depending
> on
> how the EU Data Protection Directive works out, it could be illegal for a
> merchant to use software that transports user data to third parties.  Or
> it
> could be illegal for an ISP to allow access to out of EU sites that use
> software that transports user data from EU citizens to non-EU merchants.
> Note
> that the EU officials recently REJECTED the U.S. Government's proposed
> merchant
> privacy policy safe harbor agreement.  This is quite a serious problem.
> Furthermore, the U.S. sales tax and European VAT systems are significantly
> different - and harmonizing them could be difficult.
> 
If the "the tax agencies" you mean the Federal level Revenue authorities of
OECD countries, lets be clear that the OECD has not suggested that the
seller should collect a home address with each transaction.

In the physical world the seller (even, I understand, in California) will
probably want you to authenticate yourself by comparing your signature on
the credit card receipt with the one on the back of your card. The seller
will have also obtained a copy of your card number and it may be possible,
through the issuing bank, to determine the country in which the card was
issued and where the card holder resides. This linkage of information is the
audit trail. I'm not suggesting the seller can, or should, be given access
to the buyer's residency information, I'm just stating that the seller holds
a piece of the chain, which links to another party with additional
information. Each party along the audit trail only needs to keep a record of
the relevant information for their part of the chain, so that privacy can be
protected by separation of data. However, if the need arises, and their is
legal justification and sanction, the audit trail can be reconstructed from
many sources to give a complete picture to verify an issue.

Also, while the EU may have rejected the US proposed merchant privacy
policy, the OECD is not the EU. The OECD includes such countries as the
U.S., Canada, Mexico, Japan, Korea, Australia and New Zealand and is a
consensus building organisation. It is a mistake to characterise the OECD
and the EU as holding the same views given they have very different
membership. 

> In general, I would hesitate to deal with the tax issues, particularly in
> the
> U.S., until the recommendations of the Internet Tax Freedom Act are
> published
> AND ENACTED.  
> 
The U.S. Internet Tax Freedom Act deals primarily with U.S. sub-Federal
taxation and so caution IN the U.S. might be warranted. 

However, at the international level, where the OECD has an international
co-ordination role, the U.S. view is probably best shown in Presidential
Directive 6 in the First Annual Report of the U.S. Government Working Group
on Electronic Commerce, published in November, which states:  "I direct the
Secretary of the Treasury to work with ... foreign governments to achieve
agreements that will ensure ...  that existing taxes should be applied in
ways that avoid inconsistent national tax jurisdictions and double taxation;
and that tax systems treat economically similar transactions equally,
regardless of whether such transactions occur through electronic means or
through more conventional channels of commerce."

The OECD is trying to achieve the application of existing taxes in a neutral
fashion compared with conventional commerce so I do not believe that
hesitation is required at this level.

> I would also encourage you to consider privacy issues when it comes to
> consumer
> purchasing mechanisms.  There is no reason that a consumer should be
> forced to
> provide ANY personally identifiable information in order to complete a
> transaction on the Internet, any more than they would do so in a store on
> Main
> Street.
> 
I would agree that privacy needs to be taken into account and that there is
no reason why a business transaction conducted by electronic commerce means
should require the disclosure of any more personal information than the same
transaction conducted on Main Street. The OECD has not suggested otherwise.

> - Kaye Caldwell
> Participant in the OECD tax meetings, Member of the Steering Commiteee of
> the
> National Tax Association's Communicaitons and Electronic Commerce Taxation
> Project, author of the CommerceNet white paper on Sales and Use Taxes and
> Internet Commerce.
> 
> Comments on some earlier messages:
> 
> From [email-masked]:
> 
> >Equally the moritorium,
> >in theory, does not relieve the trader from the usual requirements of
> record
> >keeping and accounting to the tax authority.
> 
> But many traders in interstate commerce in the U.S. do NOT now have those
> requirements, and the moratorium requires states to treat Internet traders
> equivalently.
> 
> >One ought to remember that, notwithstanding a trader may be conducting
> >business electronically,  most tax authorities have draconian powers of
> >investigation and enforcement,
> 
> Again, not always, the U.S. Supreme Court and Congress have NOT extended
> "draconian powers of
> investigation and enforcement, to merchants that do not have physical
> presence
> in the state where the buyer resides.
> 
> From: "Smith, Chris" <[email-masked]>:
> 
> >Perhaps you should go back and look at my actual
> >suggestion. It is analogous to the 'Tax' button on a cash
> >register. Jut because it's there doesn't mean you have to
> >push it.
> >
> >The idea was for the Order Description to contain
> >Payment Annotations - notes that might specify details
> >such as "Value Added Tax UK XX% Paid UKP 1.23". If you
> >as a merchant don't want to include them, then, like
> >not pushing the Tax button, don't include them.
> >
> I would agree with this suggestion, there will need to be a mechanism for
> indicating taxes.  Merchants required to collect them will need that,
> those
> not
> required to do so will simply not use the mechanism.  I would however note
> that
> the complexities of the data that might be required are more than you are
> envisioning, for example, you may need to include exemption status
> handling,
> product classification code, and different amounts for taxes in a state,
> city,
> county and, to quote the AT&T tax person "mosquito abatement districts".  
> (Unfortunately, he was NOT kidding.)  On the other hand, perhaps we will
> be
> successful in reducing the complexity.
> 
> 
> ===================================
> Kaye Caldwell,  Policy Director
> CommerceNet 
> 
> http://www.Commerce.net
> E-mail: [email-masked]
> Phone: (831) 479-8743    Fax: (408) 273-6345
> ===================================
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available 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: Tue, 08 Dec 1998 20:50:24 -0800
To: [email-masked]
From: Kaye Caldwell <[email-masked]>
Subject: IOTP and taxes
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Sorry to drop into the tax conversation late, I just became aware of the
discussion.

The problem with the tax situation as it now exists is that the question of
what entity will collect the tax owed by the purchaser, and on what basis,=
 is
in a state of flux.=A0 Certainly in the U.S., it is not now the
responsibility of
many merchants to collect the tax, although certainly the tax agencies would
prefer to be able to compel them to do so.=A0 The U.S. Supreme Court and
Congress
have declined to allow that, due to the complexities of complying with up to
30,000 possible taxing jurisdicitons in the U.S. alone, all with different=
 tax
rates and (to a lesser extent) which tax different products.

One of the other big issues in this area is privacy.=A0 Mr. Hardy put it=
 exactly
right: taxes mean "who, what, where, when, and how much".=A0 Transporting=
 all of
this information presents severe privacy issues.=A0 When it comes to taxes=
 we
cannot have all 3 of: privacy, destination-based taxation, and seller
collection.=A0 Two of the three can be achieved, but NOT all three.=A0 There=
 are
mechanisms for dealing with this that do NOT involve seller collection, or=
 do
not involve destination-based taxation, however achieving them is=
 politically
difficult in the U.S and perhaps as well in Europe.

To make the issue more clear: imagine if every time you used your credit=
 card
in a store the seller collected your home address (and required you to=
 provide
ID to prove its accuracy).=A0 This is what the tax agencies want on the
Internet.=A0 It is ILLEGAL in California to ask for that data. And depending=
 on
how the EU Data Protection Directive works out, it could be illegal for a
merchant to use software that transports user data to third parties.=A0 Or=
 it
could be illegal for an ISP to allow access to out of EU sites that use
software that transports user data from EU citizens to non-EU merchants.=A0=
 Note
that the EU officials recently REJECTED the U.S. Government's proposed
merchant
privacy policy safe harbor agreement.=A0 This is quite a serious problem.
Furthermore, the U.S. sales tax and European VAT systems are significantly
different - and harmonizing them could be difficult.

In general, I would hesitate to deal with the tax issues, particularly in=
 the
U.S., until the recommendations of the Internet Tax Freedom Act are=
 published
AND ENACTED.=A0=20

I would also encourage you to consider privacy issues when it comes to
consumer
purchasing mechanisms.=A0 There is no reason that a consumer should be=
 forced to
provide ANY personally identifiable information in order to complete a
transaction on the Internet, any more than they would do so in a store on=
 Main
Street.

- Kaye Caldwell
Participant in the OECD tax meetings, Member of the Steering Commiteee of=
 the
National Tax Association's Communicaitons and Electronic Commerce Taxation
Project, author of the CommerceNet white paper on Sales and Use Taxes and
Internet Commerce.

Comments on some earlier messages:

>From [email-masked]:

>Equally the moritorium,
>in theory, does not relieve the trader from the usual requirements of=
 record
>keeping and accounting to the tax authority.

But many traders in interstate commerce in the U.S. do NOT now have those
requirements, and the moratorium requires states to treat Internet traders
equivalently.

>One ought to remember that, notwithstanding a trader may be conducting
>business electronically,=A0 most tax authorities have draconian powers of
>investigation and enforcement,

Again, not always, the U.S. Supreme Court and Congress have NOT extended
"draconian powers of
investigation and enforcement, to merchants that do not have physical=
 presence
in the state where the buyer resides.

From: "Smith, Chris" <[email-masked]>:

>Perhaps you should go back and look at my actual
>suggestion. It is analogous to the 'Tax' button on a cash
>register. Jut because it's there doesn't mean you have to
>push it.
>
>The idea was for the Order Description to contain
>Payment Annotations - notes that might specify details
>such as "Value Added Tax UK XX% Paid UKP 1.23". If you
>as a merchant don't want to include them, then, like
>not pushing the Tax button, don't include them.
>
I would agree with this suggestion, there will need to be a mechanism for
indicating taxes.=A0 Merchants required to collect them will need that, thos=
e
not
required to do so will simply not use the mechanism.=A0 I would however note
that
the complexities of the data that might be required are more than you are
envisioning, for example, you may need to include exemption status handling,
product classification code, and different amounts for taxes in a state,=
 city,
county and, to quote the AT&T tax person "mosquito abatement districts".=A0=
=A0
(Unfortunately, he was NOT kidding.)=A0 On the other hand, perhaps we will=
 be
successful in reducing the complexity.

=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,  Policy Director
CommerceNet=20

http://www.Commerce.net
E-mail: [email-masked]
Phone: (831) 479-8743    Fax: (408) 273-6345
=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: Ross Kouhi <[email-masked]>
To: [email-masked]
Subject: RE: 3 December 1998 TRADE WG conference call minutes
Date: Mon, 7 Dec 1998 11:22:44 -0500
Importance: high
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

> 	> The OECD is looking for the most efficient and unintrusive way
> 	it can to collect taxes on Internet commerce.  The have started
> 	a two year study/planning effort and are tracking protocol
> 	development.  But just popping out with "requirements" in two
> 	years and expecting them to suddenly be incorporated in
> 	protocols is not too likely to work.  So some interaction with
> 	protocol development efforts during that time would be good.
> 
> 	Indirect taxes, such as income taxes, are not a problem until
> 	further into the future.  Consumption taxes such as value
		added and sales taxes are a more near term problem
> 	
> 	To some extent it boils down to record keeping requirements and
> 	no system will be 100% effective.
> 
> 
Taxation being entertained in the protocol sounds like a bad direction.  Any
imposed taxation should be kept as the  responsibility (problem) of the
point of sale, as in conventional commerce.  Anything else is akin to having
a G-Man standing at each cash register removing some cash as you pay for
your chewing gum.  We don't do that, rather, the vendor is required to
tabulate his sales, and - with periodic audits - submits the required
percentage to the appropriate governments.  

Perhaps the appropriate involvment of the electronic systems is for end user
applications to  track the transactions and present the sales total to the
vendor for their use.  The onus then is upon the local governments and
vendors to handle taxes as they will.  That is,  the vendors of applications
(eg. the creators of WWW pages) can be left to write or buy end user
software that will total the sales as required.  

Taxation is generally intended to claim a fee on certain sales in an
geographic area to support programs and services that are 'enjoyed' by those
same consumers.  There is ongoing difficulty in governments to understand
that e-commerce will not necessarily, and in some cases rarely, involve
local people buying from local vendors.   How governments deal with that is
their problem, and responsibility.  

I have no doubt, though, that if they are offered a chance to build in
taxation into a system, they will take the opportunity.  Luckily, if the
OECD won't even have an opinion for 2 years, it sounds like it should be
possible to get a system deployed without imposed taxation at the wrong
place.  This will keep it between the vendor and the governement where it
belongs, rather than in the system that allows the transactions to happen. 

The comment above about record keeping is spot on.  Being new to this forum,
however, I am not certain if the end user's record keeping is something that
is relevant to the protocol discussion.  Are hooks contemplated for the
protocol that will ease the creation of those tools that do the record
keeping?

________________________________________________

                     Ross Kouhi
          Manager, Emerging Technologies
      AT00 Network Edge Technology (NET)
N O R T E L    N E T W O R K S
(613) 763-4586            (613) 763-2096
________________________________________________

 

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

From: "Smith, Chris" <[email-masked]>
To: [email-masked]
Subject: RE: IOTP and taxation
Date: Mon, 7 Dec 1998 11:29:00 -0500 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I wrote:

> > Let's be clear - I don't think anyone *loves* paying
> > taxes. But if the choice is between paying my taxes 
> > or having no e-commerce at all (because it is being 
> > used to avoid taxes), then I'll pay the taxes.

> >     "Further, private sector groups aiming at the
        introduction of new technical standards or protocols for 
        electronic commerce could co-operate by contacting 
        Revenue authorities, e.g. through the OECD, at an early 
        stage to enhance a constructive dialogue designed to 
        find mutually acceptable solutions."

Steve Schear <[email-masked]> wrote:

> As has been discussed on this list before, taxation should 
> not be part of any new on-line trading or transaction 
> protocol any more than it is for existing on-line 
> transaction systems (e.g., credit cards). 

Credit cards are a payment system, and if what we were
discussing was a payment system, then I would agree completely.

But we are discussing a 'trading system'. I don't
agree that you can lump 'trading protocol', 'transaction
protocol', and 'payment protocol' together for this discussion.

The possibility of taxes when trading exists, and as such it
is wise to allow for them. To do otherwise strikes me as the
equivalent of building a cash register that can't do
taxes - something that seems overly idealistic, and
unlikely to be successful in practice.

Merchants who select protocols, either directly, or
indirectly as part of a product, will be interested
in services that match their needs. No matter whether
they, you, or I love the idea, this includes ensuring that
the required taxes (the minimum - no more) are paid.

Merchants - today - who are interested in customer service
will go to extra lengths to ensure that the appropriate
taxes are paid.

United States merchants develop the processes, systems,
and contacts to ensure that their customers' CANADIAN taxes
are paid. This ensures that nothing interferes with their
ability to deliver goods and services to their customers,
no matter where those customers are. This incidentally will
ensure that they do not have to remit U.S. taxes which are
not applicable to Canadians.

> Although 
> its clear many nation states have a strong interest 
> in collecting revenue from Net transactions there's 
> no compelling reason to explicitly build this in to 
> the protocols. The argument that unless we do so 
> e-commerce will somehow be stifled is hollow and 
> amounts to nothing more than the economic equivalent 
> of fear-driven self-censorship.

Perhaps you should go back and look at my actual
suggestion. It is analogous to the 'Tax' button on a cash
register. Jut because it's there doesn't mean you have to
push it.

The idea was for the Order Description to contain
Payment Annotations - notes that might specify details
such as "Value Added Tax UK XX% Paid UKP 1.23". If you
as a merchant don't want to include them, then, like
not pushing the Tax button, don't include them.

If you, as a customer, want to avoid this, then choose
your merchants accordingly. If the merchant is choosing
a protocol where it is clear that taxes are 
noted/annotated/recorded, then this decision can even be
automated.

> There is no such thing as one's 'fair share of taxes'. 
> There is only taxes which are collectable and those which 
> are not. Like patriotism, the concept has oft promoted by 
> those who ignore it themselves.

I don't believe anyone suggested anything different.
A 'fair share of taxes' is your phrase, not mine.
Although there may be no such thing as a 'fair share'
of taxes, many people do seem to complain about
paying 'more than their fair share'.

Failure to accurately represent the absolute minimum
that you are legally supposed to pay rarely means that
you end up paying only the amount originally intended
to be collected. This is the equivalent of a business
that keeps no records. Their lack of record keeping
rarely translates into 'no taxes collected'.

> One true promise of the Net is a global not international 
> place. No need to lift the tent and let the camel (not 
> alone his nose) in.

I'm a little confused by how accurately representing taxes
paid and owing works against you. If you decide to live where
there are no consumption taxes, then accurately representing
either your right to not pay such taxes, or representing taxes
you did pay that you can claim back from other jurisdictions,
works in your interest, does it not?

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

From: [email-masked]
To: [email-masked]
Subject: RE: 3 December 1998 TRADE WG conference call minutes
Date: Mon, 7 Dec 1998 10:31:53 +0100 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

A few clarifications and additional comments on taxes ...

The OECD is basically an international economic forum of the governments of
29 leading countries. Taxation is one of the economic subjects discussed at
the OECD and the OECD is generally regarded as the leading international
organisation dealing with international taxation issues.

The OECD does not have a mandate to address sub-national tax issues.

Basically, electronic commerce activities are currently subject to tax
according to existing tax laws, but administration presents challenges. To
address the challenges several approaches have been discussed, outside of
the OECD, ranging from tax free electronic commerce to specialised taxes
like the bit tax. Both of these approaches are discriminatory and
distortionary and would adversely impact on business planning and investment
by favouring one type of commercial activity over another. Tax is not meant
to have this kind of impact on business. So the OECD approach is neutrality
- apply existing taxes in the least costly and intrusive way possible. 

The OECD has been looking at the taxation implications of Internet
electronic commerce for a few years and at a Ministerial conference in
Ottawa in October this year, Ministers endorsed the proposal that the OECD
should open its processes to include the private sector and non-member
governments in it's work on taxation and electronic commerce.

As a result the OECD is in the process of forming technical advisory groups
on various taxation issues whereby OECD members, non member governments and
the private sector can sit down in equal partnership and look at viable
solutions to some of the taxation issues. 

These groups should be constituted with a two year life in the first
instance.

One of the areas the OECD recognises that it must examine are the emergent
protocols and standards. The intention is that where a commercially
developed protocol / standard is developed to meet a commercial need
(customer authentication, contractual non-repudiation etc.) and that there
is a similar taxation need (e.g. taxpayer authentication) then tax
authorities, through the OECD, should discuss the common needs with the
developers of the protocol / standard. Boiled down, the key tax questions
are: who, where, when, what and how much. While the taxpayer is the primary
source of the answers, independent verification mechanisms (the audit trail
and record thereof) are often required. 

Based on preliminary examination of what IOTP is trying to achieve, there
seems to be some scope for overlap with what tax authorities need in order
to administer existing tax laws.

There are a number of different bodies looking at taxation or related issues
- the European Commission, the World Customs Organisation, APEC, regional
tax bodies etc. The OECD is attempting to create a single portal to bring
these different organisations, as well as individual countries, together
with the private sector in one consideration of the issues so that non
fragmented responses can be developed in a globally consistent fashion.
Hopefully this will also avoid individual groups being fatigued by multiple
meetings with different bodies all trying to cover similar issues.

>From the OECD perspective, indirect taxes, like consumption taxes (VAT, GST,
...) are considered to be a more immediate concern as each current
transaction potentially generates a tax issue. Direct taxes like income tax
are less urgent in the sense that you need to make a profit to be subject to
income tax, but, if businesses are looking to claim current losses against
future profits then income tax issues become more current. 

Michael Hardy

> ----------
> From: 	Donald E. Eastlake 3rd[SMTP:[email-masked]]
> Sent: 	Sunday, 6 December 1998 1:04
> To: 	[email-masked]
> Subject: 	3 December 1998 TRADE WG conference call minutes
> 
> 
> Attendance: Donald Eastlake, David Burdett, Steve Fabes, Michael
> Harvey, Chris Smith, Jason Flick, Doug Taylor
> 
> (1) Document status
> 
> 	SCCD: Jonathan Sowler is expected to post a message to the list
> 	on when he will have a new version.
> 	
> 	XML SIG: On general XML SIG, Donald Eastlake is talking with
> 	Richard Brown and Hiroshi Maruyama about making this a separate
> 	effort covering general XML canonicalization, hashing, and
> 	digital signatures.
> 	
> 	IOTP v1.0 Protocol: Should be final soon.  Donald Eastlake needs
> 	to recommend text on signatures and use of IANA Registration
> 	Facilities.
> 	
> 	HTTP: Changes agreed in Tokyo will be reviewed in Orlando.
> 	
> 	
> (2) draft-rfced-info-blinov-00.txt
> 
> 	Chris Smith had some comments and agreed to write them up and
> 	post them to the list.  All we have been asked to do as a WG
> 	is see if there are any obvious problem with the document or
> 	conflicts with what we are doing.
> 
> (3) Version 2.0
> 
> 	Several people expressed a feeling that there should be some
> 	"still waters" after v1.0 for implementation and
> 	interoperability testing of v2.0.  There was also continued
> 	agreement on the v2.0 document structure reviewed in Tokyo and
> 	already distributed on this list.  Some of the proposed pieces
> 	of the v2.0 documentation might be extremely close to v1.0
> 	because they cover parts that don't change much if at all. Would
> 	it be worth while publishing them as a v1.1 document or the like
> 	for ease of reference? There did not seem to be a clear
> 	consensus and this should be discussed on the list and/or in
> 	Orlando.
> 
> (4) HTML Form Field Names
> 
> 	The question was raised of whether this WG should consider
> 	standardizing or compiling information on common HTML Form Field
> 	Names for use in Internet commerce.  These would be fields that
> 	might occur in forms during shopping and could include ship to
> 	address, name, etc.  This information can also be transferred in
> 	IOTP via an Authentication transaction. The possibility of an
> 	field name that indicated the server spoke IOTP was raised. 
> 	There are privacy implications as there are for Authenticate. 
> 	In general, the reaction was favorable.
> 
> (5) Taxes....
> 
> 	Michael Harvey of the OECD was on the conference call but, as is
> 	the norm in IETF WG's, was representing himself, not making
> 	official statements on behalf of the OECD.  The following are
> 	some summary exerpts of what he said in response to questions by
> 	others on the call.
> 	
> 	The OECD is looking for the most efficient and unintrusive way
> 	it can to collect taxes on Internet commerce.  The have started
> 	a two year study/planning effort and are tracking protocol
> 	development.  But just popping out with "requirements" in two
> 	years and expecting them to suddenly be incorporated in
> 	protocols is not too likely to work.  So some interaction with
> 	protocol development efforts during that time would be good.
> 	
> 	Indirect taxes, such as income taxes, are not a problem until
> 	further into the future.  Consumption taxes such as value
> 	added and sales taxes are a more near term problem.
> 	
> 	To some extent it boils down to record keeping requirements and
> 	no system will be 100% effective.
> 	
> 	The tax authorities tend to think about things in terms of three
> 	populations of transactions, consumer to business, large
> 	business to large business, and other business to business.
> 	There is generally little problem with transactions between
> 	large businesses as they are used to dealing with international
> 	taxation and record keeping requirements.
> 	
> 	There doesn't seem to be any other protocol effort, besides IOTP,
> 	that has done any thinking about taxes except perhaps a little
> 	in the SET Consortium.
> 	
> 	At one point someone suggested that there may be web sites in
> 	the future that give tax avoidance advice.  The response was
> 	that there already are such sites.
> 
> 
> Thanks,
> Donald
> 
> =====================================================================
>  Donald E. Eastlake 3rd   +1 978-287-4877    [email-masked]
>  318 Acton Street         +1 978-371-7148(fax)
>  Carlisle, MA 01741 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]

Date: Sat, 5 Dec 1998 22:47:59 -0800
To: [email-masked], "Smith, Chris" <[email-masked]>
From: Steve Schear <[email-masked]>
Subject: Re: IOTP and taxation
Cc: [email-masked]
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

>Let's be clear - I don't think anyone *loves* paying taxes. But
if the choice is between paying my taxes or having no e-commerce
at all (because it is being used to avoid taxes), then I'll pay
the taxes.

>
        "Further, private sector groups aiming at the
        introduction of new technical standards or protocols for
        electronic commerce could co-operate by contacting
        Revenue authorities, e.g. through the OECD, at an early
        stage to enhance a constructive dialogue designed to
        find mutually acceptable solutions."

As has been discussed on this list before, taxation should not be part of
any new on-line trading or transaction protocol any more than it is for
existing on-line transaction systems (e.g., credit cards). Although its
clear many nation states have a strong interest in collecting revenue from
Net transactions there's no compelling reason to explicitly build this in
to the protocols. The argument that unless we do so e-commerce will somehow
be stifled is hollow and amounts to nothing more than the economic
equivalent of fear-driven self-censorship.

There is no such thing as one's 'fair share of taxes'. There is only taxes
which are collectable and those which are not. Like patriotism, the concept
has oft promoted by those who ignore it themselves.

One true promise of the Net is a global not international place. No need to
lift the tent and let the camel (not alone his nose) in.

--Steve

---------------------------------------------------------------------
Steve Schear              |
CEO                       |
First ECache Corporation  |
3151 N. Rainbow Blvd.     |
Suite 128                 |
Las Vegas, NV 89108       | Internet: [email-masked]
---------------------------------------------------------------------

		"It's your Cache"

PGP mail preferred, see  	http://www.pgp.com and
				http://web.mit.edu/network/pgp.html

RSA fingerprint: FE90 1A95 9DEA 8D61  812E CCA9 A44A FBA9
RSA key: http://keys.pgp.com:11371/pks/lookup?op=index&search=0x55C78B0D

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available 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: 3 December 1998 TRADE WG conference call minutes
Date: Sat, 05 Dec 1998 19:04:32 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Attendance: Donald Eastlake, David Burdett, Steve Fabes, Michael
Harvey, Chris Smith, Jason Flick, Doug Taylor

(1) Document status

	SCCD: Jonathan Sowler is expected to post a message to the list
	on when he will have a new version.
	
	XML SIG: On general XML SIG, Donald Eastlake is talking with
	Richard Brown and Hiroshi Maruyama about making this a separate
	effort covering general XML canonicalization, hashing, and
	digital signatures.
	
	IOTP v1.0 Protocol: Should be final soon.  Donald Eastlake needs
	to recommend text on signatures and use of IANA Registration
	Facilities.
	
	HTTP: Changes agreed in Tokyo will be reviewed in Orlando.

(2) draft-rfced-info-blinov-00.txt

	Chris Smith had some comments and agreed to write them up and
	post them to the list.  All we have been asked to do as a WG
	is see if there are any obvious problem with the document or
	conflicts with what we are doing.

(3) Version 2.0

	Several people expressed a feeling that there should be some
	"still waters" after v1.0 for implementation and
	interoperability testing of v2.0.  There was also continued
	agreement on the v2.0 document structure reviewed in Tokyo and
	already distributed on this list.  Some of the proposed pieces
	of the v2.0 documentation might be extremely close to v1.0
	because they cover parts that don't change much if at all. Would
	it be worth while publishing them as a v1.1 document or the like
	for ease of reference? There did not seem to be a clear
	consensus and this should be discussed on the list and/or in
	Orlando.

(4) HTML Form Field Names

	The question was raised of whether this WG should consider
	standardizing or compiling information on common HTML Form Field
	Names for use in Internet commerce.  These would be fields that
	might occur in forms during shopping and could include ship to
	address, name, etc.  This information can also be transferred in
	IOTP via an Authentication transaction. The possibility of an
	field name that indicated the server spoke IOTP was raised. 
	There are privacy implications as there are for Authenticate. 
	In general, the reaction was favorable.

(5) Taxes....

	Michael Harvey of the OECD was on the conference call but, as is
	the norm in IETF WG's, was representing himself, not making
	official statements on behalf of the OECD.  The following are
	some summary exerpts of what he said in response to questions by
	others on the call.
	
	The OECD is looking for the most efficient and unintrusive way
	it can to collect taxes on Internet commerce.  The have started
	a two year study/planning effort and are tracking protocol
	development.  But just popping out with "requirements" in two
	years and expecting them to suddenly be incorporated in
	protocols is not too likely to work.  So some interaction with
	protocol development efforts during that time would be good.
	
	Indirect taxes, such as income taxes, are not a problem until
	further into the future.  Consumption taxes such as value
	added and sales taxes are a more near term problem.
	
	To some extent it boils down to record keeping requirements and
	no system will be 100% effective.
	
	The tax authorities tend to think about things in terms of three
	populations of transactions, consumer to business, large
	business to large business, and other business to business.
	There is generally little problem with transactions between
	large businesses as they are used to dealing with international
	taxation and record keeping requirements.
	
	There doesn't seem to be any other protocol effort, besides IOTP,
	that has done any thinking about taxes except perhaps a little
	in the SET Consortium.
	
	At one point someone suggested that there may be web sites in
	the future that give tax avoidance advice.  The response was
	that there already are such sites.

Thanks,
Donald

=====================================================================
 Donald E. Eastlake 3rd   +1 978-287-4877    [email-masked]
 318 Acton Street         +1 978-371-7148(fax)
 Carlisle, MA 01741 USA
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
cc: [email-masked]
Subject: General Minutes of the Tokyo TRADE WG Meeting
Date: Fri, 04 Dec 1998 12:18:56 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

These are general minutes of the successful meeting of the IETF TRADE
working group at the offices of Hitachi in Tokyo.  More detailed
supplementary minutes of specific technical output from the meeting
have been posted.  All of this is for review by the mailing list and
in Orlando but the consensus at the meeting will stand unless there is
significant opposition.

MONDAY, NOVEMBER 9th

The day stared with an official greeting by Akira Muramatsu of Hitachi
and a review of the agenda.

There were four main items covered:
(1) We completed discussion of the report from the Royal Bank of
Canada on their implmenetion of Version 0.9 of IOTP.  The output of
this were some items suggested as changed in Version 1.0 and some as
possibilities for Version 2.0.  These have been posted separately.
(2) There was some discussion, in connection with v2.0, of
representing and handling taxes under OTP.  This lead to the optional
Order Payment Annotations (see Tuesday).  It was felt there was no
reason to add a "Tax Exchange" transacation.
(3) There was extensive discussion of Draft 4 of the SET IOTP
Supplement.  This lead to tentative decisions that a provision for
repeating Packaged Content was needed.  There was also much discussion
of BrandIDs.  In IOTP, there is a BrandIDDomain specifier.  For credit
card oriented payment schemes, at least SET, it was decided to simply
use the SET BrandID system prefaced with a "SET:" BrandIDDomain
specifier.  There will also be an "IOTP": BandIDDomain and possibly
others. IANA registration services will be needed to registering BrandIDs
in the IOTP BrandIDDomain and for registering BrandIDDomains.  See
also separate minutes on SET/IOTP.
(4) There was a interesting live demonstration of Hitachi's
implementation of IOTP Version 0.9.  Chris Smith of the Royal Bank of
Canada, and Jason Flick of TouchNet had lots of technical questions
particularly related to client startup (see Wednesday below).

TUESDAY, NOVEMBER 10th

Techncial results of Monday were reviewed by David Burdett. 

-There was discussion of the v1.0 draft mostly leading to some
suggested format changes and attention to the need to make the
signature specification consistent and either included in the v1.0
document or clearly referenced outside of it.

- Possible Version 2.0 additions (on which there has been a separate
posting) include an optional non-critical Order Payment Annotation to
indication such things as what part of payment is taxes, shipping,
etc., or that loyalty points are being awarded for puchase, etc.

- There was extensive presentation and discussion of XML Namespaces
and the XML SIG draft by Richard Brown.  Some argued to keeping the
simplicity of the v~0.9 signatures without use of namespace (which had
been removed from the latest v1.0 draft) while others wanted something
much closer to the XML SIG draft with namespaces.  It was concluded
that the time constraints of Royal Bank, Hitchi, and probably others
who plan to implement v1.0 soon would not be met by the timeline for a
very general XML SIG based on broad XML community input.  Therefore,
some specific signature specification will be incorporated in v1.0.
Donald Eastlake agreed to look at the 0.9 signature spec again and
look at the possibility of a signature based on a simplified version
of the XML SIG draft and make a recommendation as to which should be
incorporated in the v1.0 specification.

WEDNESDAY, NOVEMBER 11th

The remaining agenda was reviewed.

The possibility of a major project in Japan including Hitachi,
Fujitsu, and NTT, several banks, Card issuers: Visa, MasterCard,
Diners Club, JCB, Orient Corpt, Hitachi Credit, and a number of
merchants was leaked to the WG and Asian Business news channels.  The
initial phase would use IOTP over to the Internet in payment system
selection and connecting the merchant roles defined in IOTP.

The Architecture document was not discussed significantly.  People
thought it would be better to wait for more experience with its use.

Discussion of the HTTP Supplement lead to a list of changes that will
be discussed in Orlando and incorporated into an update.  This
dicussion also lead to an extended discussion of NetLocations (URLs)
for error logging and for redirection in case of success, error, or
cancellation of an IOTP Transactions.  (See V1.0 changes already
posted for conclusions.)

There was discussion of changing the target status for the V1.0
protocol document.  The original plan, as embodies in the TRADE WG
charter, was to publish this some months ago as Informational and then
proceed to develope a V2.0 as a Proposed Standard.  However, at this
point, it makes more sense to publish V1.0 as Proposed.  There are at
least three reasons for this: (a) v1.0 is has been under review and
improvement by the WG for some time and it may reasonably be the
consensus of the WG; (b) the Royal Bank, Hitachi, and others will be
implmenting v1.0 so it is likely there will be some interoperability
tests so it may even be possible to advance it to Draft Standard; and
(c) as a minor consideration, even v1.0 needs to call on some IANA
registration for Brands and it is not clear that an Information RFC
can do that.

There was an extensive discussion of "client side start up" and how to
handle authentication of the consumer by the merchant and the like.
Since authentiction can return extended information, this is a path by
which the merchant could ask for the ship to address and the like.
The conclusion was to permit authentication optionally before most
IOTP transactions and to add an AuthStatus message from merchant to
consumer that can be used to turn control back over to the consumer
browser and indicate success or failure of a merchant originated
authencation.

David Burdett proposed a strucutre for IOTP v2.0 documents (see
separate mail) that was well received.

On future meetings, there was a feeling that these three day meetings
outside of the IETF meeting should continue but substantially less
often that the former 6 times a year.  The next such WG meeting was
tentatively set for February 9-11, 1999, in either the US or Europe.
There was strong sentiment for a warm climate location but a specific
location was not selected.  Volunteer hosts are welcome to contact the
WG.  Donald Eastlake will look into the hosting possibilities at IBM.

ATTENDNACE LIST:
Akira Muramatsu, Hitachi
Andrew Drapp, Hitachi
Yoshiaki Kawatsura, Hitachi
Masaaki Hiroya, Hitachi
Donald Eastlake, IBM
Richard Brown, GlobeSet
Chris Smith, Royal Bank
Hajime Kojima, Fujitsu
David Burdett, Mondex
Jason Flick, TouchNet
Doug Taylor, TouchNet
Arakawa, NTT
Kayanuma Toshihiko, Epoch

Thanks,
Donald
=====================================================================
 Donald E. Eastlake 3rd   +1 978-287-4877    [email-masked]
 318 Acton Street         +1 978-371-7148(fax)       [email-masked]
 Carlisle, MA 01741 USA   +1 914 784 7913
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
Subject: Minutes of SET payment protocol within IOTP discussion, Tokyo
Date: Fri, 04 Dec 1998 12:11:43 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

The following minutes were taken by Andrew Drapp of Hitachi.

---
SET/IOTP Supplement

Andrew Drapp gave a presentation on SET/IOTP.  For more details on
SET/IOTP refer to the presentation files.  Key issues that were
decided that is not present in the presentation documentation by
Yoshiaki Kawatsura and Andrew Drapp are the following:

1.  Any place that packaged content appears in the IOTP speck can now
be replaced with multiple instances of packaged content.

2.  All packaged content elements will have an optional Name
attribute.  This will allow software to differentiate between multiple
packaged content elements.

3.  Packaged content intended for another trading role, and passed
through the consumer should be included in the TradingRoles packaged
content, not the Payment packaged content.

4.  The SET BrandID specification will be adopted and used within
SET/IOTP.  SET BrandIDs will use the SET Namespace.  Examples of
BrandIDs are: "iotp:Mondex", "set:MasterCard::", and
"set:Visa:Gold:AmericanAirlines".  The first BrandID is an example of
an IOTP BrandID, and the following two are SET BrandIDs.
 
The various suggestions made be Yoshiaki Kawatsura for modifying the
SET/IOTP specification were all approved.  Again, for more details on
the specifics of those recommendations, see the presentation notes by
Yoshiaki Kawatsura and Andrew Drapp.
---
Regards, 
Andrew Drapp
--
Andrew Drapp
[email-masked]
Systems Development Laboratory, Hitachi Ltd.
Ozenji 1099, Asao, Kawasaki, 215-0013 JAPAN
TEL:+81-44-966-9111   FAX:+81-44-966-1796
PGP Fingerprint: 84D8 3D19 018E 9385 6581  0081 C89C D2AD F06A 565F
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

Date: Thu, 03 Dec 1998 09:32:27 +0200
To: "[email-masked]'" <[email-masked]>
From: Hannu Nikkanen <[email-masked]>
Subject: Re: IOTP version 2.0 ideas
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Hi,

some new ideas for IOTP for your consideration. I'll be in Orlando to
explain this better.

1) Coupons, memberships (in addition to payment instrument) etc.

Most physical Merchants and some manufacturers offer incentives to
Consumers using 
membership ("Club XX" etc) or coupons.

The incentives may be:

a) special prices to products;
b) "two for the price of one"
c) coupons, which give discount to groups of products;
d) coupons, which have monetary value (to be used with any purchase at the
Merchant).

Note, that a, b and c effect the pre-tax price.

2) Customer may have contracts with subcontractors of the Merchant. The
Consumer may 
advice the Merchant to use the services of a certain subcontractor and make
this 
subcomtractor charge the Consumer directly.

As an example, I'm working for a Telco in Finland, where the market is
quite liberalized. 
Here, in addition to the all cost in one bill, Consumers may have contracts
with both 
local and long-distance Telco and have contracted to have automatically
separate billing. 
Technically, the Consumer dials the long-distance number, the local telco
routes the call 
in a special way to the long distance Telco, which recognizes the Consumer
from originating 
telepnone number. So, no call specific negotiation between the Consumer and
the subcontractor 
(long distance telco) takes place. (If You wonder why, e.g. homecalls of
employers may be 
added to company contract for quantity discounts).

The principle seems to expand also to other areas.

3) IOTP is very Consumer activity oriented. That is really needed for
privacy etc. but some 
merchants would like to make shopping easy for the customer. The main
points are:

a) shopping carts
b) the Merchants queries the Payment handler about the payment (sometimes
Consumers are "lost" 
and do not contract delivery handler) and take care of the activation of
delivery.

We should support also a "active Merchant" option.

Hannu 

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

From: "Smith, Chris" <[email-masked]>
To: "[email-masked]" <[email-masked]>,  "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: IOTP and taxation
Date: Wed, 2 Dec 1998 10:35:00 -0500 
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Jane Hill wrote:

> 1.  Tax authorities will start to try to enforce
>     existing forms of taxation on e- commerce. The
>     result could be painful for everyone involved.
>
> 2. Traders will want an 'approved' method of accounting
>    to their tax authority, in which they can have
>    confidence. The tax authority will want to see a
>    secure/ tamper evident method of record keeping,
>    probably approved by them in any event.
>
> 3. Traders will also start to realise that they may
>    not only be taxable 'at home' but also in the
>    countries into which they are selling.

Words to note! 

The thoughts here seem to overlap heavily with the direction of the OECD 
paper. In addition, the OECD paper suggests that

        "Further, private sector groups aiming at the 
        introduction of new technical standards or protocols for 
        electronic commerce could co-operate by contacting 
        Revenue authorities, e.g. through the OECD, at an early 
        stage to enhance a constructive dialogue designed to 
        find mutually acceptable solutions."
        
which would suggest that we are (in general) being asked to 
include taxation at some level in our scope. Jane's comments 
make clear that the merchant, as well, can have a strong 
interest in having their taxation records a clean and 
straight-forward as possible.

Finally, consumers...

Let's be clear - I don't think anyone *loves* paying taxes. But 
if the choice is between paying my taxes or having no e-commerce 
at all (because it is being used to avoid taxes), then I'll pay 
the taxes.

Once we pass that point, I want to pay *only* the taxes I need 
to. If I buy from a merchant in a foreign country, I would like 
the following:

1) I want to pay only my consumption taxes.

2) I don't want to pay consumption taxes for where the merchant
   is location.

3) I want the taxes paid as efficiently as possible. I don't
   want to have to pay a customs broker an addtion fee if at
   all possible, and I don't want goods stopped at a border,
   either because the taxes aren't paid, or because the fact
   that they are paid is not clear.

The merchant, in fact, wants the same thing, because he (I 
assume) wants me to buy from him.

So where does IOTP fit in?

1) We already carry Organization information categorized
   according to trading roles. It is not difficult to envision
   that this can serve to identify clear a merchant's Point Of
   Sale, and a purchaser's Point Of Consumption. If these are
   clearly identified, then the taxes owing can be calculated
   accurately.

2) We recently discussed the idea of Payment Annotations. This
   would be added to IOTP (meaning "it is not there now"), and
   would be an addendum to the Offer. Each Payment Annotation
   would provide additional information about the Offer, and in
   particular about details of the Payment.

Perhaps an example:

   Merchant:  Tops R Us, Toronto, Ontario, Canada
   Consumer:  123 Street, Ottawa, Ontario, Canada
   goods:     1 shirt
   Payment:   $115 (CAD)
   Payment Annotation: Canada,GoodsServicesTax $7 (CAD)
   Payment Annotation: Canada,Ontario ProvSalesTax $8 (CAD)

The Payment Annotation can then be bound into the Offer by the 
Merchant, serving as a definitive record of the taxes that are 
owed as a result of this trade.

A different example highlights the exact role:

   Merchant:  Tops R Us, Toronto, Ontario, Canada
   Consumer:  123 Street, Buffalo, New York, United States
   goods:     1 shirt
   Payment:   $106 (CAD)
   Payment Annotation: United States,New York StateTax $6 (CAD)

Both the Consumer in Buffalo and the Merchant in Toronto benefit from a 
definitive record. The completed Offers are the starting point for 
documenting:

1) that the Merchant has collected all Point of Consumption taxes
2) that each Consumer has paid the appropriate Consumption Taxes
3) that each Consumer has paid the MINIMUM Consumption Taxes

Such documentation eases the merchant's record keeping task, and serves 
as the starting point for goods to travel expeditiously across borders.

It should be noted that Payment Annotations do NOT describe the entire 
breakdown of the Payment. In fact, they are not used at all in most 
cases. The primary role is to provide an Order Description independent 
way of describing information that is common the many disparate forms of 
Order Descriptions. Remember that Order Descriptions in IOTP are opaque 
- they do not contain information that is in 'IOTP format'. It would be 
necessary to understand every Order Description in order to extract this 
information. Rather than place this burden of understanding all Order 
Descriptions on other parties who need this info, the merchant (or their 
agent or software) extracts the information to IOTP format - a 
considerablely smaller problem.

Having done this, we can also consider the role of an 'international tax 
processor' who serves as the merchants agent in matters of international 
taxation - calculating, collecting, and remitting, as appropriate, the 
needed taxes. This leaves the merchant with the same job as today - 
namely, handling their own national taxes - while providing them access 
to a level playing field of international commerce. The tax processor 
can specialize in that role, ensuring the accuracy of foreign tax 
calculations, and efficiently handling the foreign remittances. All 
relevant tax authorities get exactly what is owed to them, without 
having the establish large-scale or cumbersome foreign merchant 
dealings.

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

I've gone on at length here, but I think some this was needed as 
background to the discussion.

In particular, having read all of this, please think and comment on the 
idea of Payment Annotations in IOTP. This is actually the only real 
change we would need to consider in IOTP. It seems to offer tremendous 
value for the size of the change.

Your thoughts and views are needed.

----------------------------------------------------------------------- 
Message addressed to: [email-masked]
Archive available 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: Conference Call December 3
Date: Wed, 02 Dec 1998 08:20:33 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Just a reminder that there will be a conference call tomorrow at 9am
eastern US time.  Call in number 1-212-547-0300, passcode 90216.

Agenda:
(1) Status of documents.
(2) Discussion of the changes reported out of the Tokyo meeting.
(3) Any comments on draft-rfced-info-blinov-00.txt.
(4) Discussion of agenda for the meeting in Orlando.
(5) Any discussion of v2.

The conference call bridge is reserved for 1 1/2 hours but we
certainly don't need to go that long unless people are interested and
there is useful work being done.

Thanks,
Donald
=====================================================================
 Donald E. Eastlake 3rd   +1 978-287-4877    [email-masked]
 318 Acton Street         +1 978-371-7148(fax)
 Carlisle, MA 01741 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]
Date: Wed, 2 Dec 1998 06:21:48 EST
To: [email-masked]
Cc: [email-masked]
Subject: IOTP and taxation
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

David,

If this does not reach the IOTP list would you please forward it.

I have thought from my first involvement with IOTP that it had great potential
in addressing not just some of the  taxation issues but also other e- commerce
issues, particularly in respect to to legal requirements relating to consumer
transactions. I actually think this should be viewed as a plus not a minus.

The US may have a five year moritorium on the introduction of new forms of
taxation on Internet trade but many countries do not. Equally the moritorium,
in theory, does not relieve the trader from the usual requirements of record
keeping and accounting to the tax authority.  Forget about new forms of
Internet taxation, there is already a vast array of existing forms of taxation
which do apply NOW to e-commerce.

One ought to remember that, notwithstanding a trader may be conducting
business electronically,  most tax authorities have draconian powers of
investigation and enforcement, i.e. which can extend into the electronic
environment.  Most traders will want to carry out their business activities
legitimately, certainly they will want to avoid the unwelcome attentions of
their local tax authority. Potentially, IOTP can help with that, particularly
if it has the  seal of approval from the relevant tax authority.

As a small point, I can't actually see tax authorities being eager to
intervene in transactions as a trusted third party, surely cost alone would be
a deterrent?  Wouldn't providing the information required in the
'Organisation' component be rather an inhibitor in 'consumer' based
transactions ? Equally, tracing the geographic location of the 'tax payer'
purchaser of intangible goods is a well known problem for which currently,
there appears to be no easy answer.

I think that certain things are likely to happen in the not too distant
future:

1.  Tax authorities will start to try to enforce existing forms of taxation on
e- commerce. The result could be painful for everyone involved.

2. Traders will want an 'approved' method of accounting to their tax
authority, in which they can have confidence. The tax authority will want to
see a secure/ tamper evident method of record keeping, probably approved by
them in any event.

3. Traders will also start to realise that they may not only be taxable 'at
home' but also in the countries into which they are selling. 

I think the issues are more complex than as set out in David's e-mail and I do
not think that IOTP can solve them all, but there could be advantages to IOTP
in taking this route which deserve very careful consideration. As I have said
before, I also believe IOTP has unrecognised potential in other legal aspects
of e-commerce, which as yet, have not been addressed.

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, 01 Dec 1998 09:10:08 +0000
Subject: Re: IOTP and Tax Collection
From: Neil McEvoy <[email-masked]>
To: David Burdett <[email-masked]>,  "[email-masked]'" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

>This e-mail describes a potential way in which IOTP could be used to
>facilitate the recording and collection of tax information associated
>with e-commerce.

I don't think this is the usual way for new forms of commerce to develop: if
parties have a mutual benefit in executing trades they figure practical ways
of so doing: if the class of transactions becomes big enough to appear on
governments' radar, they (governments) try to figure ways of taxing them,
but it's not always practical, particularly if other jurisdictions don't tax
that class of transaction.

We should be so lucky if IOTP transactions appear on the radars, and our
efforts should be bent to this, because it's _our_ problem. Collecting taxes
on any or all e-commerce transactions may also be a  problem, but it's _not
our_ problem.

Regards,
Neil

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