Subject: Taxation (again)
From: Chris Smith <[email-masked]>
To: [email-masked]
Date: Sun, 24 Dec 2000 01:30:53 -0500 (Eastern Standard Time)

Some time back, we had an almost-acrimonious discussion here
regarding taxation and purchase protocols.

Whether you like it or not, that discussion may be about to
return, via the Streamlined Sales Tax Project.

CNNfn has a reasonably complete article on this, with much
background info...

http://cnnfn.cnn.com/2000/12/22/cashflow/q_salestax/index.htm

Quite simply, it looks like the idea of online ordering as
a way to avoid some taxes is not going to fly. The good news
would seem to be that the legislative initiatives are designed
to *reduce* the complexity of the sales tax situation, rather
than simply declare that 'taxes must be collected' without
regard for the difficulty of implementation.

-- 
------------------------------------------------------
 Chris Smith                     <[email-masked]>

Date: Fri, 22 Dec 2000 16:17:52 -0500
From: "Smith, Chris " <[email-masked]>
Subject: Company Change - Chris Smith
To: [email-masked]
Cc: "[email-masked]'" <[email-masked]>

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

--Boundary_(ID_3oN/3GrVzTxtnKOLOybwzQ)
Content-type: text/plain
Content-transfer-encoding: 7BIT

Effective the end of December, I will no longer be employed with
Royal Bank of Canada. As such I will not be participating in
this list from this address.

If you are following up on old correspondence regarding
only working group or IOTP items, that is from
[email-masked], those items can be directed 
to    [email-masked]    . This address has been part
of the TRADE list for some time.

If there are Royal Bank specific items you wish to follow-up
on, I would suggest you contact

    Tim McGaugh
    [email-masked]

to deal with the disposition of those items.

Although I will continue to participate as an individual
where appropriate, I will have to wait until January to
establish how my new employer wishes to handle items or
work such as this.

Best wishes for the coming year...

....Chris Smith

--Boundary_(ID_3oN/3GrVzTxtnKOLOybwzQ)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>Company Change - Chris Smith</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>Effective the end of December, I will no longer be employed with</FONT>
<BR><FONT SIZE=2>Royal Bank of Canada. As such I will not be participating in</FONT>
<BR><FONT SIZE=2>this list from this address.</FONT>
</P>

<P><FONT SIZE=2>If you are following up on old correspondence regarding</FONT>
<BR><FONT SIZE=2>only working group or IOTP items, that is from</FONT>
<BR><FONT SIZE=2>[email-masked], those items can be directed </FONT>
<BR><FONT SIZE=2>to&nbsp;&nbsp;&nbsp; [email-masked]&nbsp;&nbsp;&nbsp; . This address has been part</FONT>
<BR><FONT SIZE=2>of the TRADE list for some time.</FONT>
</P>

<P><FONT SIZE=2>If there are Royal Bank specific items you wish to follow-up</FONT>
<BR><FONT SIZE=2>on, I would suggest you contact</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp; Tim McGaugh</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; [email-masked]</FONT>
</P>

<P><FONT SIZE=2>to deal with the disposition of those items.</FONT>
</P>

<P><FONT SIZE=2>Although I will continue to participate as an individual</FONT>
<BR><FONT SIZE=2>where appropriate, I will have to wait until January to</FONT>
<BR><FONT SIZE=2>establish how my new employer wishes to handle items or</FONT>
<BR><FONT SIZE=2>work such as this.</FONT>
</P>

<P><FONT SIZE=2>Best wishes for the coming year...</FONT>
</P>

<P><FONT SIZE=2>....Chris Smith</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; </FONT>
</P>

</BODY>
</HTML>

--Boundary_(ID_3oN/3GrVzTxtnKOLOybwzQ)--

Date: Thu, 21 Dec 2000 11:06:52 -0500
From: Raghuram Rajah <[email-masked]>
Subject: Fw: FW: Draft minutes of trade IETF San Diego
To: [email-masked]

--Boundary_(ID_PZn1pZ/mqfIbiZ2x4nn4ow)
Content-type: text/plain
Content-transfer-encoding: QUOTED-PRINTABLE

Yes, I did intend to send it to the group and I thought I did too. I =
am surprised it was sent only to you. Sorry about the confusion. Than=
ks for getting me upto speed. =20

Going forward, do we plan to use the mailing list at all, or would we=
 want to discuss in the f2f only?

Will send a write-up on the thoughts that we had developed for repres=
enting rights (we were calling it coupons, though I know it is a mis-=
leading as well) soon to the group (atleast this time ;-) ).

Raghu.

----- Original Message -----
=46rom: Ko Fujimura
Sent: Thursday, December 21, 2000 6:58 AM
To: Raghuram Rajah
Cc: Donald E. Eastlake 3rd; [email-masked]
Subject: Re: FW: Draft minutes of trade IETF San Diego

Hi Raghu,

> Hi Ko / Walter / Donald / all,

I think that your mail is intended to sent the mailing list but sent =
only to me.
Anyway, I would like to answer it.

> I have been a part of this group for over a month now and haven't s=
een any discussion on the rights requirements or the RTS in general. =
Didn't find a whole lot in the archives either.
> Is there a private group working on these requirements and the RTS =
framework?

There was. But, about one year ago I closed it, since it is not activ=
e. So, any discussion
should be done the trade mailing list or face-to-face meeting now. We=
 haven't actively
discussed using the mailing list. But, we had 5 face-to-face meeting =
since the 45th IETF Oslo meeting. I think it enough for discussing re=
quirements.

> The reason I ask is, I have been leading a development of a similar=
 system and have been battling the very same requirements in the cont=
ext of embedded devices with limi=3D
ted computing power. We have made some progress in addressing these r=
equirements and have come up with a generic framework. Though the fra=
mework and the model needs more work, I guess we are headed in the ri=
ght direction.

Thank you. But, I think the next work item is to develop draft for Ri=
ghts Component, i.e., XML representation of rights. I'm not sure if f=
ramework and the model should be specified.

> We would want to present our model, for review by the WG to develop=
 the RTS I-D, potentially.

Meeting agenda is chair's decision, but I think that Don will allow y=
ou to present it.

> Or if the development of the framework or model is already underway=
 by the WG, we would like to contribute to the same. Also, we could a=
dopt the early releases and can=3D
act as a test bed.

Any contributions are welcome! I hope you actively join the discussio=
n.

> Please let me know if a private group is involved in developing the=
se standards? And if so, how can I join that group? How does the work=
ing group operate in developing these drafts?
> Please advise.

Send the trade mailing list what you are thinking. Do not hesitate to=
 do so.

Regards,

Ko

P.S. My I ask your company? Just curious.<br clear=3D3Dall><hr>Get yo=
ur FRE=3D
E download of MSN Explorer at <a href=3D3D"http://explorer.msn.com">h=
ttp://=3D
explorer.msn.com</a><br></p>

------=3D_NextPart_001_0002_01C06B36.9E1312B0
Content-Type: text/html; charset=3D"iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><BODY STYLE=3D3D"font:10pt verdana; border:none;"><DIV>Yes, I d=
id int=3D
end to send it to the group and I thought I did too. I am surprised i=
t wa=3D
s sent only to you. Sorry about the confusion. Thanks for getting me =
upto=3D
speed. </DIV> <DIV>&nbsp;</DIV> <DIV>Going forward, do we plan to use=
 th=3D
e mailing list at all, or would we want to discuss in the f2f only?</=
DIV>=3D
<DIV>&nbsp;</DIV> <DIV>Will send a write-up on the thoughts that we h=
ad =3D
developed for representing rights (we were calling it coupons, though=
 I k=3D
now it is a mis-leading as well) soon to the group (atleast this time=
 ;-)=3D
).</DIV> <DIV>&nbsp;</DIV> <DIV>Raghu.<BR></DIV> <BLOCKQUOTE style=
=3D3D"BO=3D
RDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PA=
DDIN=3D
G-LEFT: 5px; PADDING-RIGHT: 0px"> <DIV style=3D3D"FONT: 10pt Arial">-=
---- O=3D
riginal Message -----</DIV> <DIV style=3D3D"BACKGROUND: #e4e4e4; FONT=
: 10pt=3D
Arial; FONT-COLOR: black"><B>From:</B>&nbsp;Ko Fujimura</DIV> <DIV st=
yle=3D
=3D3D"FONT: 10pt Arial"><B>Sent:</B>&nbsp;Thursday, December 21, 2000=
 6:58 =3D
AM</DIV> <DIV style=3D3D"FONT: 10pt Arial"><B>To:</B>&nbsp;Raghuram R=
ajah</=3D
DIV> <DIV style=3D3D"FONT: 10pt Arial"><B>Cc:</B>&nbsp;Donald E. East=
lake 3=3D
rd; [email-masked]</DIV> <DIV style=3D3D"FONT: 10pt Arial"><B=
>Subje=3D
ct:</B>&nbsp;Re: FW: Draft minutes of trade IETF San Diego</DIV> <DIV=
><BR=3D
></DIV>Hi Raghu,<BR><BR>&gt; Hi Ko / Walter / Donald / all,<BR><BR>I =
thin=3D
k that your mail is intended to sent the mailing list but sent only t=
o me=3D
=2E<BR>Anyway, I would like to answer it.<BR><BR>&gt; I have been a p=
art of=3D
this group for over a month now and haven't seen any discussion on th=
e<B=3D
R>&gt; rights requirements or the RTS in general. Didn't find a whole=
 lot=3D
in the archives either.<BR>&gt; Is there a private group working on t=
hes=3D
e requirements and the RTS framework?<BR><BR>There was. But, about on=
e ye=3D
ar ago I closed it, since it is not active. So, any discussion<BR>sho=
uld =3D
be done the trade mailing list or face-to-face meeting now. We haven'=
t ac=3D
tively<BR>discussed using the mailing list. But, we had 5 face-to-fac=
e me=3D
eting since the 45th IETF Oslo<BR>meeting. I think it enough for disc=
ussi=3D
ng requirements.<BR><BR>&gt; The reason I ask is, I have been leading=
 a d=3D
evelopment of a similar system and have been battling<BR>&gt; the ver=
y sa=3D
me requirements in the context of embedded devices with limited compu=
ting=3D
power.<BR>&gt; We have made some progress in addressing these require=
men=3D
ts and have come up with a generic<BR>&gt; framework. Though the fram=
ewor=3D
k and the model needs more work, I guess we are headed in the right<B=
R>&g=3D
t; direction.<BR><BR>Thank you. But, I think the next work item is to=
 dev=3D
elop draft for Rights Component, i.e., XML<BR>representation of right=
s. I=3D
'm not sure if framework and the model should be specified.<BR><BR>&g=
t; W=3D
e would want to present our model, for review by the WG to develop th=
e RT=3D
S I-D, potentially.<BR><BR>Meeting agenda is chair's decision, but I =
thin=3D
k that Don will allow you to present it.<BR><BR>&gt; Or if the develo=
pmen=3D
t of the framework or model is already underway by the WG, we would l=
ike =3D
to<BR>&gt; contribute to the same. Also, we could adopt the early rel=
ease=3D
s and can act as a test bed.<BR><BR>Any contributions are welcome! I =
hope=3D
you actively join the discussion.<BR><BR>&gt; Please let me know if a=
 pr=3D
ivate group is involved in developing these standards? And if so,<BR>=
&gt;=3D
how can I join that group? How does the working group operate in deve=
lop=3D
ing these drafts?<BR>&gt; Please advise.<BR><BR>Send the trade mailin=
g li=3D
st what you are thinking. Do not hesitate to do so.<BR><BR>Regards,<B=
R><B=3D
R>Ko<BR><BR>P.S. My I ask your company? Just curious.<BR> <DIV></DIV>=
</BL=3D
OCKQUOTE></BODY></HTML><DIV><BR><br clear=3D3Dall><hr>Get your FREE d=
ownloa=3D
d of MSN Explorer at <a href=3D3D"http://explorer.msn.com">http://exp=
lorer.=3D
msn.com</a><br></p></DIV>

------=3D_NextPart_001_0002_01C06B36.9E1312B0--
---------------------------------------------------------------------=
---
Your message was received by [email-masked].
We are an automatic elist command server.  This is a help summary.

If you need to contact a person, the elist service manager may be
reached by sending an email message to:

  [email-masked]

We receive messages and expect the content to be lines with commands.
You may send more than one command per message but each command must
appear completely on a line by itself.  If a line ends with a backsla=
sh
"\" we will add the next line to it before processing it.  Commands i=
n
the Subject: header are ignored.

There are subscriber commands and elist owner commands.  The subscrib=
er
commands are described first.  A brief explanation of all commands is
included here.  A more detailed explanation is available at:

  http://lists.elistx.com/doc/email-manage.html

SUBSCRIBER COMMANDS

The following commands may be sent by anyone to the command server.  =
The
command will be processed according to how the elist is configured.  =
You
will always get a reply telling you if a command was processed and wh=
at
was done.

  subscribe
  unsubscribe
  confirm
  who
  help

SUBSCRIBE

  The word "subscribe" should appear on a line by itself in the body =
of
  the message.  By default the address that will be subscribed is
  selected from the first of the following header fields with a value=
:
  REPLY-TO, FROM, SENDER.

  To subscribe an alternate address, or the address of a third party,
  include it on the line after "subscribe".  Any valid email address =
may
  be specified, e.g.:

    subscribe Raghuram Rajah <[email-masked]>

UNSUBSCRIBE

  The word "unsubscribe" should appear on a line by itself in the bod=
y
  of the message.  By default the address that will be unsubscribed i=
s
  selected from the first of the following header fields with a value=
:
  REPLY-TO, FROM, SENDER.

  To unsubscribe an alternate address, or the address of a third part=
y,
  include it on the line after "unsubscribe".  Any valid email addres=
s
  may be specified, e.g.:

    unsubscribe Raghuram Rajah <[email-masked]>

CONFIRM

  The confirm command line is provided to you by the elist command
  server in response to a subscribe or unsubscribe command.  When you
  receive it you must return the entire command line to the elist ser=
ver
  exactly as it was provided to you.  You may break long lines by
  putting a backslash "\" at the end of the incomplete lines.

  In all cases, the command server will respond to the address in the
  first of the following fields to have a value: REPLY-TO, FROM,
  SENDER.  This reply will indicate the command was received and whet=
her
  or not it was processed.

  If the command was processed a separate message will be sent with t=
he
  results of the command, e.g., in the case of a subscribe command th=
e
  subscriber will be sent a welcome message and in the case of an
  unsubscribe command the subscriber will be sent a good-bye message.

WHO

  The word "who" must appear on a line by itself in the body of the
  message.  If the elist owner permits it a copy of the list of
  subscribers will be returned to you.  If it is not permitted you wi=
ll
  receive an acknowledgement telling you so.

HELP

  When the word "help" appears on a line by itself you receive this
  message.

ELIST OWNER COMMANDS

The following commands are not created by users.  They are created by
the command server and sent to elist owners when an unauthorized mess=
age
is received for distribution.  Although there are many reasons why a
message submitted to an elist is considered unauthorized, it is alway=
s a
direct result of how an elist is configured.

The commands are as follows:

  delete
  distribute
  reject
  spam

DELETE

  This command is used to end all processing of a message.  The messa=
ge
  will be removed from the email queue, it will not be returned to it=
s
  sender, and it will not be distributed to your elist.  See also the
  command reject.

  A representative use of this command is:

      delete yes TOKEN IDENTIFIER

  Note that TOKEN and IDENTIFIER must be replaced by actual values th=
at
  are unique to the message being processed.  The values will have be=
en
  provided to you by the elist command server.  You must supply both =
the
  command "delete" and the confirmation "yes".

DISTRIBUTE

  This command is used to distribute the message to your elist.  If t=
he
  elist is archived a copy will be put there also.

  A representative use of this command is:

      distribute yes TOKEN IDENTIFIER

  Note that TOKEN and IDENTIFIER must be replaced by actual values th=
at
  are unique to the message being processed.  The values will have be=
en
  provided to you by the elist command server.  You must supply both =
the
  command "distribute" and the confirmation "yes".

REJECT

  This command is used to reject the distribution of the message and =
to
  send a message to its sender indicating the message was not authori=
zed
  for distribution.  The message will be removed from the email queue=
,
  it will be returned to its sender, and it will not be distributed t=
o
  your elist.  See also the command "delete".

  A representative use of this command is:

      reject yes TOKEN IDENTIFIER

  Note that TOKEN and IDENTIFIER must be replaced by actual values th=
at
  are unique to the message being processed.  The values will have be=
en
  provided to you by the elist command server.  You must supply both =
the
  command "reject" and the confirmation "yes".

SPAM

  This command is used to tell us that you consider the message spam =
and
  you want us to treat it as such.  The message will be removed from =
the
  email queue, it will not be returned to its sender, and it will not=
 be
  distributed to your elist.  In addition, the message will be forwar=
ded
  to [email-masked] for processing.

  A representative use of this command is:

      spam yes TOKEN IDENTIFIER

  Note that TOKEN and IDENTIFIER must be replaced by actual values th=
at
  are unique to the message being processed.  The values will have be=
en
  provided to you by the elist command server.  You must supply both =
the
  command "spam" and the confirmation "yes".
---------------------------------------------------------------------=
---<br clear=3Dall><hr>Get your FREE download of MSN Explorer at <a h=
ref=3D"http://explorer.msn.com">http://explorer.msn.com</a><br></p>

--Boundary_(ID_PZn1pZ/mqfIbiZ2x4nn4ow)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: QUOTED-PRINTABLE

<HTML><BODY STYLE=3D"font:10pt verdana; border:none;"><DIV>Yes, I did=
 intend to send it to the group and I thought I did too. I am surpris=
ed it was sent only to you. Sorry about the confusion. Thanks for get=
ting me upto speed. <BR><BR>Going forward, do we plan to use the mail=
ing list at all, or would we want to discuss in the f2f only?<BR><BR>=
Will send a write-up on the thoughts that we had developed for repres=
enting rights (we were calling it coupons, though I know it is a mis-=
leading as well) soon to the group (atleast this time ;-) ).<BR><BR>R=
aghu.<BR><BR>----- Original Message -----<BR>From: Ko Fujimura<BR>Sen=
t: Thursday, December 21, 2000 6:58 AM<BR>To: Raghuram Rajah<BR>Cc: D=
onald E. Eastlake 3rd; [email-masked]<BR>Subject: Re: FW: Dra=
ft minutes of trade IETF San Diego<BR><BR><BR>Hi Raghu,<BR><BR>&gt; H=
i Ko / Walter / Donald / all,<BR><BR>I think that your mail is intend=
ed to sent the mailing list but sent only to me.<BR>Anyway, I would l=
ike to answer it.<BR><BR>&gt; I have been a part of this group for ov=
er a month now and haven't seen any discussion on the&nbsp;rights req=
uirements or the RTS in general. Didn't find a whole lot in the archi=
ves either.<BR>&gt; Is there a private group working on these require=
ments and the RTS framework?<BR><BR>There was. But, about one year ag=
o I closed it, since it is not active. So, any discussion<BR>should b=
e done the trade mailing list or face-to-face meeting now. We haven't=
 actively<BR>discussed using the mailing list. But, we had 5 face-to-=
face meeting since the 45th IETF Oslo meeting. I think it enough for =
discussing requirements.<BR><BR>&gt; The reason I ask is, I have been=
 leading a development of a similar system and have been battling&nbs=
p;the very same requirements in the context of embedded devices with =
limi=3D<BR>ted computing power. We have made some progress in address=
ing these requirements and have come up with a generic&nbsp;framework=
. Though the framework and the model needs more work, I guess we are =
headed in the right direction.<BR><BR>Thank you. But, I think the nex=
t work item is to develop draft for Rights Component, i.e., XML repre=
sentation of rights. I'm not sure if framework and the model should b=
e specified.<BR><BR>&gt; We would want to present our model, for revi=
ew by the WG to develop the RTS I-D, potentially.<BR><BR>Meeting agen=
da is chair's decision, but I think that Don will allow you to presen=
t it.<BR><BR>&gt; Or if the development of the framework or model is =
already underway by the WG, we would like to contribute to the same. =
Also, we could adopt the early releases and can=3D<BR>act as a test b=
ed.<BR><BR>Any contributions are welcome! I hope you actively join th=
e discussion.<BR><BR>&gt; Please let me know if a private group is in=
volved in developing these standards? And if so, how can I join that =
group? How does the working group operate in developing these drafts?=
<BR>&gt; Please advise.<BR><BR>Send the trade mailing list what you a=
re thinking. Do not hesitate to do so.<BR><BR>Regards,<BR><BR>Ko<BR><=
BR>P.S. My I ask your company? Just curious.&lt;br clear=3D3Dall&gt;&=
lt;hr&gt;Get your FRE=3D<BR>E download of MSN Explorer at &lt;a href=
=3D3D"http://explorer.msn.com"&gt;http://=3D<BR>explorer.msn.com&lt;/=
a&gt;&lt;br&gt;&lt;/p&gt;<BR><BR>------=3D_NextPart_001_0002_01C06B36=
.9E1312B0<BR>Content-Type: text/html; charset=3D"iso-8859-1"<BR>Conte=
nt-Transfer-Encoding: quoted-printable<BR><BR>&lt;HTML&gt;&lt;BODY ST=
YLE=3D3D"font:10pt verdana; border:none;"&gt;&lt;DIV&gt;Yes, I did in=
t=3D<BR>end to send it to the group and I thought I did too. I am sur=
prised it wa=3D<BR>s sent only to you. Sorry about the confusion. Tha=
nks for getting me upto=3D<BR>speed. &lt;/DIV&gt; &lt;DIV&gt;&amp;nbs=
p;&lt;/DIV&gt; &lt;DIV&gt;Going forward, do we plan to use th=3D<BR>e=
 mailing list at all, or would we want to discuss in the f2f only?&lt=
;/DIV&gt;=3D<BR>&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt; &lt;DIV&gt;Will sen=
d a write-up on the thoughts that we had =3D<BR>developed for represe=
nting rights (we were calling it coupons, though I k=3D<BR>now it is =
a mis-leading as well) soon to the group (atleast this time ;-)=3D<BR=
>).&lt;/DIV&gt; &lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt; &lt;DIV&gt;Raghu.&l=
t;BR&gt;&lt;/DIV&gt; &lt;BLOCKQUOTE style=3D3D"BO=3D<BR>RDER-LEFT: #0=
00000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDIN=3D<BR>G-=
LEFT: 5px; PADDING-RIGHT: 0px"&gt; &lt;DIV style=3D3D"FONT: 10pt Aria=
l"&gt;----- O=3D<BR>riginal Message -----&lt;/DIV&gt; &lt;DIV style=
=3D3D"BACKGROUND: #e4e4e4; FONT: 10pt=3D<BR>Arial; FONT-COLOR: black"=
&gt;&lt;B&gt;From:&lt;/B&gt;&amp;nbsp;Ko Fujimura&lt;/DIV&gt; &lt;DIV=
 style=3D<BR>=3D3D"FONT: 10pt Arial"&gt;&lt;B&gt;Sent:&lt;/B&gt;&amp;=
nbsp;Thursday, December 21, 2000 6:58 =3D<BR>AM&lt;/DIV&gt; &lt;DIV s=
tyle=3D3D"FONT: 10pt Arial"&gt;&lt;B&gt;To:&lt;/B&gt;&amp;nbsp;Raghur=
am Rajah&lt;/=3D<BR>DIV&gt; &lt;DIV style=3D3D"FONT: 10pt Arial"&gt;&=
lt;B&gt;Cc:&lt;/B&gt;&amp;nbsp;Donald E. Eastlake 3=3D<BR>rd; fujimur=
[email-masked]&lt;/DIV&gt; &lt;DIV style=3D3D"FONT: 10pt Arial"&gt;&=
lt;B&gt;Subje=3D<BR>ct:&lt;/B&gt;&amp;nbsp;Re: FW: Draft minutes of t=
rade IETF San Diego&lt;/DIV&gt; &lt;DIV&gt;&lt;BR=3D<BR>&gt;&lt;/DIV&=
gt;Hi Raghu,&lt;BR&gt;&lt;BR&gt;&amp;gt; Hi Ko / Walter / Donald / al=
l,&lt;BR&gt;&lt;BR&gt;I thin=3D<BR>k that your mail is intended to se=
nt the mailing list but sent only to me=3D<BR>.&lt;BR&gt;Anyway, I wo=
uld like to answer it.&lt;BR&gt;&lt;BR&gt;&amp;gt; I have been a part=
 of=3D<BR>this group for over a month now and haven't seen any discus=
sion on the&lt;B=3D<BR>R&gt;&amp;gt; rights requirements or the RTS i=
n general. Didn't find a whole lot=3D<BR>in the archives either.&lt;B=
R&gt;&amp;gt; Is there a private group working on thes=3D<BR>e requir=
ements and the RTS framework?&lt;BR&gt;&lt;BR&gt;There was. But, abou=
t one ye=3D<BR>ar ago I closed it, since it is not active. So, any di=
scussion&lt;BR&gt;should =3D<BR>be done the trade mailing list or fac=
e-to-face meeting now. We haven't ac=3D<BR>tively&lt;BR&gt;discussed =
using the mailing list. But, we had 5 face-to-face me=3D<BR>eting sin=
ce the 45th IETF Oslo&lt;BR&gt;meeting. I think it enough for discuss=
i=3D<BR>ng requirements.&lt;BR&gt;&lt;BR&gt;&amp;gt; The reason I ask=
 is, I have been leading a d=3D<BR>evelopment of a similar system and=
 have been battling&lt;BR&gt;&amp;gt; the very sa=3D<BR>me requiremen=
ts in the context of embedded devices with limited computing=3D<BR>po=
wer.&lt;BR&gt;&amp;gt; We have made some progress in addressing these=
 requiremen=3D<BR>ts and have come up with a generic&lt;BR&gt;&amp;gt=
; framework. Though the framewor=3D<BR>k and the model needs more wor=
k, I guess we are headed in the right&lt;BR&gt;&amp;g=3D<BR>t; direct=
ion.&lt;BR&gt;&lt;BR&gt;Thank you. But, I think the next work item is=
 to dev=3D<BR>elop draft for Rights Component, i.e., XML&lt;BR&gt;rep=
resentation of rights. I=3D<BR>'m not sure if framework and the model=
 should be specified.&lt;BR&gt;&lt;BR&gt;&amp;gt; W=3D<BR>e would wan=
t to present our model, for review by the WG to develop the RT=3D<BR>=
S I-D, potentially.&lt;BR&gt;&lt;BR&gt;Meeting agenda is chair's deci=
sion, but I thin=3D<BR>k that Don will allow you to present it.&lt;BR=
&gt;&lt;BR&gt;&amp;gt; Or if the developmen=3D<BR>t of the framework =
or model is already underway by the WG, we would like =3D<BR>to&lt;BR=
&gt;&amp;gt; contribute to the same. Also, we could adopt the early r=
elease=3D<BR>s and can act as a test bed.&lt;BR&gt;&lt;BR&gt;Any cont=
ributions are welcome! I hope=3D<BR>you actively join the discussion.=
&lt;BR&gt;&lt;BR&gt;&amp;gt; Please let me know if a pr=3D<BR>ivate g=
roup is involved in developing these standards? And if so,&lt;BR&gt;&=
amp;gt;=3D<BR>how can I join that group? How does the working group o=
perate in develop=3D<BR>ing these drafts?&lt;BR&gt;&amp;gt; Please ad=
vise.&lt;BR&gt;&lt;BR&gt;Send the trade mailing li=3D<BR>st what you =
are thinking. Do not hesitate to do so.&lt;BR&gt;&lt;BR&gt;Regards,&l=
t;BR&gt;&lt;B=3D<BR>R&gt;Ko&lt;BR&gt;&lt;BR&gt;P.S. My I ask your com=
pany? Just curious.&lt;BR&gt; &lt;DIV&gt;&lt;/DIV&gt;&lt;/BL=3D<BR>OC=
KQUOTE&gt;&lt;/BODY&gt;&lt;/HTML&gt;&lt;DIV&gt;&lt;BR&gt;&lt;br clear=
=3D3Dall&gt;&lt;hr&gt;Get your FREE downloa=3D<BR>d of MSN Explorer a=
t &lt;a href=3D3D"http://explorer.msn.com"&gt;http://explorer.=3D<BR>=
msn.com&lt;/a&gt;&lt;br&gt;&lt;/p&gt;&lt;/DIV&gt;<BR><BR>------=3D_Ne=
xtPart_001_0002_01C06B36.9E1312B0--<BR>------------------------------=
------------------------------------------<BR>Your message was receiv=
ed by [email-masked].<BR>We are an automatic eli=
st command server.&nbsp; This is a help summary.<BR><BR>If you need t=
o contact a person, the elist service manager may be<BR>reached by se=
nding an email message to:<BR><BR>&nbsp; [email-masked]=
.com<BR><BR>We receive messages and expect the content to be lines wi=
th commands.<BR>You may send more than one command per message but ea=
ch command must<BR>appear completely on a line by itself.&nbsp; If a =
line ends with a backslash<BR>"\" we will add the next line to it bef=
ore processing it.&nbsp; Commands in<BR>the Subject: header are ignor=
ed.<BR><BR>There are subscriber commands and elist owner commands.&nb=
sp; The subscriber<BR>commands are described first.&nbsp; A brief exp=
lanation of all commands is<BR>included here.&nbsp; A more detailed e=
xplanation is available at:<BR><BR>&nbsp; http://lists.elistx.com/doc=
/email-manage.html<BR><BR>SUBSCRIBER COMMANDS<BR><BR>The following co=
mmands may be sent by anyone to the command server.&nbsp; The<BR>comm=
and will be processed according to how the elist is configured.&nbsp;=
 You<BR>will always get a reply telling you if a command was processe=
d and what<BR>was done.<BR><BR>&nbsp; subscribe<BR>&nbsp; unsubscribe=
<BR>&nbsp; confirm<BR>&nbsp; who<BR>&nbsp; help<BR><BR>SUBSCRIBE<BR><=
BR>&nbsp; The word "subscribe" should appear on a line by itself in t=
he body of<BR>&nbsp; the message.&nbsp; By default the address that w=
ill be subscribed is<BR>&nbsp; selected from the first of the followi=
ng header fields with a value:<BR>&nbsp; REPLY-TO, FROM, SENDER.<BR><=
BR>&nbsp; To subscribe an alternate address, or the address of a thir=
d party,<BR>&nbsp; include it on the line after "subscribe".&nbsp; An=
y valid email address may<BR>&nbsp; be specified, e.g.:<BR><BR>&nbsp;=
&nbsp;&nbsp; subscribe Raghuram Rajah &lt;[email-masked]&gt;<B=
R><BR>UNSUBSCRIBE<BR><BR>&nbsp; The word "unsubscribe" should appear =
on a line by itself in the body<BR>&nbsp; of the message.&nbsp; By de=
fault the address that will be unsubscribed is<BR>&nbsp; selected fro=
m the first of the following header fields with a value:<BR>&nbsp; RE=
PLY-TO, FROM, SENDER.<BR><BR>&nbsp; To unsubscribe an alternate addre=
ss, or the address of a third party,<BR>&nbsp; include it on the line=
 after "unsubscribe".&nbsp; Any valid email address<BR>&nbsp; may be =
specified, e.g.:<BR><BR>&nbsp;&nbsp;&nbsp; unsubscribe Raghuram Rajah=
 &lt;[email-masked]&gt;<BR><BR>CONFIRM<BR><BR>&nbsp; The confi=
rm command line is provided to you by the elist command<BR>&nbsp; ser=
ver in response to a subscribe or unsubscribe command.&nbsp; When you=
<BR>&nbsp; receive it you must return the entire command line to the =
elist server<BR>&nbsp; exactly as it was provided to you.&nbsp; You m=
ay break long lines by<BR>&nbsp; putting a backslash "\" at the end o=
f the incomplete lines.<BR><BR>&nbsp; In all cases, the command serve=
r will respond to the address in the<BR>&nbsp; first of the following=
 fields to have a value: REPLY-TO, FROM,<BR>&nbsp; SENDER.&nbsp; This=
 reply will indicate the command was received and whether<BR>&nbsp; o=
r not it was processed.<BR><BR>&nbsp; If the command was processed a =
separate message will be sent with the<BR>&nbsp; results of the comma=
nd, e.g., in the case of a subscribe command the<BR>&nbsp; subscriber=
 will be sent a welcome message and in the case of an<BR>&nbsp; unsub=
scribe command the subscriber will be sent a good-bye message.<BR><BR=
>WHO<BR><BR>&nbsp; The word "who" must appear on a line by itself in =
the body of the<BR>&nbsp; message.&nbsp; If the elist owner permits i=
t a copy of the list of<BR>&nbsp; subscribers will be returned to you=
.&nbsp; If it is not permitted you will<BR>&nbsp; receive an acknowle=
dgement telling you so.<BR><BR>HELP<BR><BR>&nbsp; When the word "help=
" appears on a line by itself you receive this<BR>&nbsp; message.<BR>=
<BR><BR><BR>ELIST OWNER COMMANDS<BR><BR>The following commands are no=
t created by users.&nbsp; They are created by<BR>the command server a=
nd sent to elist owners when an unauthorized message<BR>is received f=
or distribution.&nbsp; Although there are many reasons why a<BR>messa=
ge submitted to an elist is considered unauthorized, it is always a<B=
R>direct result of how an elist is configured.<BR><BR>The commands ar=
e as follows:<BR><BR>&nbsp; delete<BR>&nbsp; distribute<BR>&nbsp; rej=
ect<BR>&nbsp; spam<BR><BR>DELETE<BR><BR>&nbsp; This command is used t=
o end all processing of a message.&nbsp; The message<BR>&nbsp; will b=
e removed from the email queue, it will not be returned to its<BR>&nb=
sp; sender, and it will not be distributed to your elist.&nbsp; See a=
lso the<BR>&nbsp; command reject.<BR><BR>&nbsp; A representative use =
of this command is:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; delete yes =
TOKEN IDENTIFIER<BR><BR>&nbsp; Note that TOKEN and IDENTIFIER must be=
 replaced by actual values that<BR>&nbsp; are unique to the message b=
eing processed.&nbsp; The values will have been<BR>&nbsp; provided to=
 you by the elist command server.&nbsp; You must supply both the<BR>&=
nbsp; command "delete" and the confirmation "yes".<BR><BR>DISTRIBUTE<=
BR><BR>&nbsp; This command is used to distribute the message to your =
elist.&nbsp; If the<BR>&nbsp; elist is archived a copy will be put th=
ere also.<BR><BR>&nbsp; A representative use of this command is:<BR><=
BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; distribute yes TOKEN IDENTIFIER<BR>=
<BR>&nbsp; Note that TOKEN and IDENTIFIER must be replaced by actual =
values that<BR>&nbsp; are unique to the message being processed.&nbsp=
; The values will have been<BR>&nbsp; provided to you by the elist co=
mmand server.&nbsp; You must supply both the<BR>&nbsp; command "distr=
ibute" and the confirmation "yes".<BR><BR>REJECT<BR><BR>&nbsp; This c=
ommand is used to reject the distribution of the message and to<BR>&n=
bsp; send a message to its sender indicating the message was not auth=
orized<BR>&nbsp; for distribution.&nbsp; The message will be removed =
=66rom the email queue,<BR>&nbsp; it will be returned to its sender, =
and it will not be distributed to<BR>&nbsp; your elist.&nbsp; See als=
o the command "delete".<BR><BR>&nbsp; A representative use of this co=
mmand is:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; reject yes TOKEN IDEN=
TIFIER<BR><BR>&nbsp; Note that TOKEN and IDENTIFIER must be replaced =
by actual values that<BR>&nbsp; are unique to the message being proce=
ssed.&nbsp; The values will have been<BR>&nbsp; provided to you by th=
e elist command server.&nbsp; You must supply both the<BR>&nbsp; comm=
and "reject" and the confirmation "yes".<BR><BR>SPAM<BR><BR>&nbsp; Th=
is command is used to tell us that you consider the message spam and<=
BR>&nbsp; you want us to treat it as such.&nbsp; The message will be =
removed from the<BR>&nbsp; email queue, it will not be returned to it=
s sender, and it will not be<BR>&nbsp; distributed to your elist.&nbs=
p; In addition, the message will be forwarded<BR>&nbsp; to abuse@elis=
tx.com for processing.<BR><BR>&nbsp; A representative use of this com=
mand is:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; spam yes TOKEN IDENTIF=
IER<BR><BR>&nbsp; Note that TOKEN and IDENTIFIER must be replaced by =
actual values that<BR>&nbsp; are unique to the message being processe=
d.&nbsp; The values will have been<BR>&nbsp; provided to you by the e=
list command server.&nbsp; You must supply both the<BR>&nbsp; command=
 "spam" and the confirmation "yes".<BR>------------------------------=
------------------------------------------<BR></DIV> <DIV></DIV></BOD=
Y></HTML><DIV><BR><br clear=3Dall><hr>Get your FREE download of MSN E=
xplorer at <a href=3D"http://explorer.msn.com">http://explorer.msn.co=
m</a><br></p></DIV>

--Boundary_(ID_PZn1pZ/mqfIbiZ2x4nn4ow)--

Date: Wed, 20 Dec 2000 18:31:34 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Slides from TRADE WG meeting in SanDiego
To: [email-masked]

The Slides form the TRADE WG meeting in San Diego are available in power
point form from
	<ftp://torque.pothole.com/pub/ietf-trade/IETF-SanDiego/>

Sorry for the delay in making these available.
Donald

=====================================================================
 Donald E. Eastlake 3rd                      [email-masked]
 155 Beaver Street                                +1 508-634-2066(h)
 Milford, MA 01757 USA                            +1 508-261-5434(w)

Date: Wed, 20 Dec 2000 20:48:37 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: FW: Draft minutes of trade IETF San Diego
To: [email-masked]
Cc: [email-masked]

Hi Walter and Donald,

Thank you very much for the minutes. I have a few comments:

Eastlake III Donald-LDE008 wrote:
> 
> Minutes of the Internet Open Trading Protocol Working Group (trade)
> 
> Wednesday, December 13 at 1300-1500
> =====================================
> 
> CHAIR: Donald Eastlake 3rd [email-masked]
> Minutes: Walter Houser [email-masked]
...
> 7. Digital Rights Requirements - also known as Requirement for Generic
> Payments Rights - presentation by Ko Fujimura.

The title was "Requirements for Generic Rights Trading"
 
> RTS is an infrastructure to circulate diverse types of digitally
> represented rights. RTS is enables digital versions of coupons and
> tickets. We need to prevent copying.  RTS should allow sharing between
> several issuers. There are five requirements:
> 
> -       Prevent alternation
> -       Provide non-repudiation,
> -       Provide idempotency (one and only one)
> -       Prevent reproduction
> -       Prevent duplicate redemption.
> 
> Fujimura presented a Chart for Positioning of RTS in trading area shows
> the relationship of RTS with respect to IOTP. Hole observes that one needs
> to trust the coupon. Fujimura replied that trust of the coupon is the
> result of the issuer, which can be handed around by untrusted bodies. 

Yes, but more correctly, I replied that:

"trust of the coupon is the result of the issuer and the RTS. The issuer is
responsible for the contents of the right and the RTS is responsible
for preventing copy. In other words, if there is trust in the issuer and 
the RTS, trust of the holder who transfers or redeems the coupon is not 
required."

> The RTS object is an XML object, which would be defined by the WG.

I think it means that:

"The objects transported by the RTS is an XML Components which would be defined 
by the WG."
 
> Hole observed that the definition of the data representation is distinct from
> the transport issues. The latter may be appropriate for the WG, but they
> are nontrivial.
>
> The working group suggested several terms to use in lieu of digital rights
> or electronic rights, such as trading right, entitlement, coupon, and
> certificate. There was concern about confusion of the term rights with
> access control rights. Entitlement was thought cumbersome. Coupon
> communicates too much of a limitation. Certificate has a specific meaning
> with respect to network security.
...

Please add:

"It was agreed to decide the term using the mailing list."

Thanks.

Ko

Content-return: allowed
Date: Thu, 14 Dec 2000 13:16:42 -0500
From: Eastlake III Donald-LDE008 <[email-masked]>
Subject: FW: Draft minutes of trade IETF San Diego
To: "[email-masked]'" <[email-masked]>

Minutes of the Internet Open Trading Protocol Working Group (trade)

Wednesday, December 13 at 1300-1500
=====================================

CHAIR: Donald Eastlake 3rd [email-masked]
Minutes: Walter Houser [email-masked]

AGENDA:

 1  Agenda Bashing
 2  Status of Documents
 3  Implementation Experience
 4  Documents in Last Call
 5  New Charter
 6  ECML V2 Requirements
 7  Digital Rights Requirements
 8  IOTP V2 Requirements
 9  TRADE Mailing List Inactivity
10  Schedule of Future Actions/Meetings

1. Agenda basking - no changes. 

2. Status of Documents - Five RFCs have been issued and are listed on the
current charter at http://ietf.org/html.charters/trade-charter.html. 
Two drafts are in working group last call and a few more in process, also
listed on the charter page.

3. Implementation Experiences of IOTP
 - Hitachi, et al, 
 - Chris Smith, Royal Bank of Canada. 
Betty deBruijn asked for contacts for implementers. Don said he would
contact Hitachi and post a contact for them if they will provide one. 

4. Of the currents drafts, two are in last call: Payment API for v1.0
Internet Open Trading Protocol (IOTP) at
http://ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-papi-03.txt and 
SET Supplement for the v1.0 Internet Open Trading Protocol (IOTP) at
http://ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-set-02.txt

5. New Charter - Don presented the language for the new charter to be
considered by the IESG on December 28, 2000. It has not changed much from
previous charters.  Two items are declared out of scope for IOTP version
2.0: legal and regulatory issues with respect to the implementation of the
protocol, design of the XML messaging layer. The WG will specify the
requirements for digitally represented trading rights. The WG will specify
requirements and a syntax and processing model for ECML v2. Ned suggested
that Secure Channel Credit/Debit be referred to in the Charter text.  Ko
Fujimura asked that DRT specifications be added to the new charter. There
was a consensus among those at the meeting to do this.

00 Nov WG Last Call of SET Supplement and Payment API
00 Dec ID for Secure Channel Credit and debit
00 Dec submit to IESG SET Supplement and Payment API
00 Dec ID for ECML V2.0 requirements
01 Jan submit to IESG "Digital Requirements" and ECML v2.0 requirements
01 Jan ID of ECML v2.0 specification
01 Mar submit to IESG Secure Channel Credit/Debit
01 Apr submit to IESG IOTP V2.0 requirements 
01 Apr submit to IESG ECML V2.0 specification (proposed standard in XML) 

6. ECML Version 2.0 Requirements Document by Parsons and Shepherd. ECML
v1.0 describes the customer to merchant fields to be transferred in an
HTML form. There is also a usage guide. Steve Hole and Ko Fujimura raised
the question "Should there be a more explicit data model?" There are
fields for carrying the transaction. Don Eastlake thought this could be
added to the requirements document.  ECML should include multiple payment
elements and types and improved company-to-company exchanges. It also
refers to P3P for eCommerce, W3C note dated Nov 29, 1999. This note is
ECML v1.0 plus some more payment fields but with strong P3P flavor.
Shipper information and other more complex information should go to IOTP.
Microsoft and Versign have established WinPayment.  IFX and OFX are in
competition. Mark Hale of Interval noted that Mismal and IFX have
fundamental differences in how they write their specification. When we say
XML, Hole asked, "Do you go for attribute values or do you go for sub
elements?" 

Eastlake asked for specification applications for the ECML v2 requirements
document; the current entries are left over from the XMLDSIG document.
Hole suggested making the content representation like the generic
representation. This would allow us to move the objects around. Mia
Lahteenmaki asked what does the "simcard" string field mean and what is the
protocol reference for SIM card payment? Kevin McCandliss asked "What about
verification?" Eastlake said this is referenced via ISO 8583. Hole says it
is
usually out-of-band, say over SSL or using EBXML payload in an S/MIME
envelope. 

7. Digital Rights Requirements - also known as Requirement for Generic
Payments Rights - presentation by Ko Fujimura. 

RTS is an infrastructure to circulate diverse types of digitally
represented rights. RTS is enables digital versions of coupons and
tickets. We need to prevent copying.  RTS should allow sharing between
several issuers. There are five requirements: 

-	Prevent alternation  
-	Provide non-repudiation, 
-	Provide idempotency (one and only one) 
-	Prevent reproduction
-	Prevent duplicate redemption. 

Fujimura presented a Chart for Positioning of RTS in trading area shows
the relationship of RTS with respect to IOTP. Hole observes that one needs
to trust the coupon. Fujimura replied that trust of the coupon is the
result of the issuer, which can be handed around by untrusted bodies. The
RTS object is an XML object, which would be defined by the WG. Hole
observed that the definition of the data representation is distinct from
the transport issues. The latter may be appropriate for the WG, but they
are nontrivial. 

The working group suggested several terms to use in lieu of digital rights
or electronic rights, such as trading right, entitlement, coupon, and
certificate. There was concern about confusion of the term rights with
access control rights. Entitlement was thought cumbersome. Coupon
communicates too much of a limitation. Certificate has a specific meaning
with respect to network security. 

8. IOTP v2 requirements. 
An author is needed for a number of items in this document. Some have
asked for a standard way in IOTP v2 for payment protocols to communicate
outside of IOTP as well as the current payment tunneling through IOTP v1.
V2 would include payment for real property, personal property, or personal
services. It may not include escrow payments depending on whether the
dynamic definition of trading sequences area is included in v2. Customer
workflow processes are out of scope for v2. Status queries are in scope. 

9. Inactivity of the mailing lists.  Should we advertise the work of the
WG on other mailing lists? Hole suggested several groups including IFX and
OFX. They both do payment vehicles for merchant requirements. 

10. The WG will meet in Minneapolis in March. Meanwhile, we need to finish
up the ECML requirements and the specification documents. There was no
call to hold an interim meeting. 

Date: Fri, 01 Dec 2000 13:58:51 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Draft TRADE WG San Diego Meeting Agenda
To: [email-masked]
Cc: [email-masked]

Here is a rough preliminary draft agenda.  Comments welcome.

TRADE WG Draft Agenda

13:00	Agenday Bashing
13:10	New Charter (*) / Document Status
13:20	Implementation Experience
13:30	Documents in Last Call
	- Payment API
	- SET Supplement
13:45	ECML V2 Requirements
14:05	Digital Rights Requirements
14:30	IOTP V2 Requirements
14:50	Schedule Future Actions/Meetings
15:00	End

* = I have submitted a new charter to our Area Director.  By
the December meeting it may have been approved or we may have
feedback on it.

=====================================================================
 Donald E. Eastlake 3rd                      [email-masked]
 155 Beaver Street                                +1 508-634-2066(h)
 Milford, MA 01757 USA                            +1 508-261-5434(w)

Date: Sun, 24 Dec 2000 01:30:53 -0500 (Eastern Standard Time)
From: Chris Smith <[email-masked]>
Subject: Taxation (again)
To: [email-masked]

Some time back, we had an almost-acrimonious discussion here
regarding taxation and purchase protocols.

Whether you like it or not, that discussion may be about to
return, via the Streamlined Sales Tax Project.

CNNfn has a reasonably complete article on this, with much
background info...

http://cnnfn.cnn.com/2000/12/22/cashflow/q_salestax/index.htm

Quite simply, it looks like the idea of online ordering as
a way to avoid some taxes is not going to fly. The good news
would seem to be that the legislative initiatives are designed
to *reduce* the complexity of the sales tax situation, rather
than simply declare that 'taxes must be collected' without
regard for the difficulty of implementation.

-- 
------------------------------------------------------
 Chris Smith                     <[email-masked]>

Date: Fri, 22 Dec 2000 16:17:52 -0500
From: "Smith, Chris " <[email-masked]>
Subject: Company Change - Chris Smith
To: [email-masked]
Cc: "[email-masked]'" <[email-masked]>

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

--Boundary_(ID_3oN/3GrVzTxtnKOLOybwzQ)
Content-type: text/plain
Content-transfer-encoding: 7BIT

Effective the end of December, I will no longer be employed with
Royal Bank of Canada. As such I will not be participating in
this list from this address.

If you are following up on old correspondence regarding
only working group or IOTP items, that is from
[email-masked], those items can be directed 
to    [email-masked]    . This address has been part
of the TRADE list for some time.

If there are Royal Bank specific items you wish to follow-up
on, I would suggest you contact

    Tim McGaugh
    [email-masked]

to deal with the disposition of those items.

Although I will continue to participate as an individual
where appropriate, I will have to wait until January to
establish how my new employer wishes to handle items or
work such as this.

Best wishes for the coming year...

....Chris Smith

--Boundary_(ID_3oN/3GrVzTxtnKOLOybwzQ)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>Company Change - Chris Smith</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>Effective the end of December, I will no longer be employed with</FONT>
<BR><FONT SIZE=2>Royal Bank of Canada. As such I will not be participating in</FONT>
<BR><FONT SIZE=2>this list from this address.</FONT>
</P>

<P><FONT SIZE=2>If you are following up on old correspondence regarding</FONT>
<BR><FONT SIZE=2>only working group or IOTP items, that is from</FONT>
<BR><FONT SIZE=2>[email-masked], those items can be directed </FONT>
<BR><FONT SIZE=2>to&nbsp;&nbsp;&nbsp; [email-masked]&nbsp;&nbsp;&nbsp; . This address has been part</FONT>
<BR><FONT SIZE=2>of the TRADE list for some time.</FONT>
</P>

<P><FONT SIZE=2>If there are Royal Bank specific items you wish to follow-up</FONT>
<BR><FONT SIZE=2>on, I would suggest you contact</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp; Tim McGaugh</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; [email-masked]</FONT>
</P>

<P><FONT SIZE=2>to deal with the disposition of those items.</FONT>
</P>

<P><FONT SIZE=2>Although I will continue to participate as an individual</FONT>
<BR><FONT SIZE=2>where appropriate, I will have to wait until January to</FONT>
<BR><FONT SIZE=2>establish how my new employer wishes to handle items or</FONT>
<BR><FONT SIZE=2>work such as this.</FONT>
</P>

<P><FONT SIZE=2>Best wishes for the coming year...</FONT>
</P>

<P><FONT SIZE=2>....Chris Smith</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; </FONT>
</P>

</BODY>
</HTML>

--Boundary_(ID_3oN/3GrVzTxtnKOLOybwzQ)--

Date: Thu, 21 Dec 2000 11:06:52 -0500
From: Raghuram Rajah <[email-masked]>
Subject: Fw: FW: Draft minutes of trade IETF San Diego
To: [email-masked]

--Boundary_(ID_PZn1pZ/mqfIbiZ2x4nn4ow)
Content-type: text/plain
Content-transfer-encoding: QUOTED-PRINTABLE

Yes, I did intend to send it to the group and I thought I did too. I =
am surprised it was sent only to you. Sorry about the confusion. Than=
ks for getting me upto speed. =20

Going forward, do we plan to use the mailing list at all, or would we=
 want to discuss in the f2f only?

Will send a write-up on the thoughts that we had developed for repres=
enting rights (we were calling it coupons, though I know it is a mis-=
leading as well) soon to the group (atleast this time ;-) ).

Raghu.

----- Original Message -----
=46rom: Ko Fujimura
Sent: Thursday, December 21, 2000 6:58 AM
To: Raghuram Rajah
Cc: Donald E. Eastlake 3rd; [email-masked]
Subject: Re: FW: Draft minutes of trade IETF San Diego

Hi Raghu,

> Hi Ko / Walter / Donald / all,

I think that your mail is intended to sent the mailing list but sent =
only to me.
Anyway, I would like to answer it.

> I have been a part of this group for over a month now and haven't s=
een any discussion on the rights requirements or the RTS in general. =
Didn't find a whole lot in the archives either.
> Is there a private group working on these requirements and the RTS =
framework?

There was. But, about one year ago I closed it, since it is not activ=
e. So, any discussion
should be done the trade mailing list or face-to-face meeting now. We=
 haven't actively
discussed using the mailing list. But, we had 5 face-to-face meeting =
since the 45th IETF Oslo meeting. I think it enough for discussing re=
quirements.

> The reason I ask is, I have been leading a development of a similar=
 system and have been battling the very same requirements in the cont=
ext of embedded devices with limi=3D
ted computing power. We have made some progress in addressing these r=
equirements and have come up with a generic framework. Though the fra=
mework and the model needs more work, I guess we are headed in the ri=
ght direction.

Thank you. But, I think the next work item is to develop draft for Ri=
ghts Component, i.e., XML representation of rights. I'm not sure if f=
ramework and the model should be specified.

> We would want to present our model, for review by the WG to develop=
 the RTS I-D, potentially.

Meeting agenda is chair's decision, but I think that Don will allow y=
ou to present it.

> Or if the development of the framework or model is already underway=
 by the WG, we would like to contribute to the same. Also, we could a=
dopt the early releases and can=3D
act as a test bed.

Any contributions are welcome! I hope you actively join the discussio=
n.

> Please let me know if a private group is involved in developing the=
se standards? And if so, how can I join that group? How does the work=
ing group operate in developing these drafts?
> Please advise.

Send the trade mailing list what you are thinking. Do not hesitate to=
 do so.

Regards,

Ko

P.S. My I ask your company? Just curious.<br clear=3D3Dall><hr>Get yo=
ur FRE=3D
E download of MSN Explorer at <a href=3D3D"http://explorer.msn.com">h=
ttp://=3D
explorer.msn.com</a><br></p>

------=3D_NextPart_001_0002_01C06B36.9E1312B0
Content-Type: text/html; charset=3D"iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><BODY STYLE=3D3D"font:10pt verdana; border:none;"><DIV>Yes, I d=
id int=3D
end to send it to the group and I thought I did too. I am surprised i=
t wa=3D
s sent only to you. Sorry about the confusion. Thanks for getting me =
upto=3D
speed. </DIV> <DIV>&nbsp;</DIV> <DIV>Going forward, do we plan to use=
 th=3D
e mailing list at all, or would we want to discuss in the f2f only?</=
DIV>=3D
<DIV>&nbsp;</DIV> <DIV>Will send a write-up on the thoughts that we h=
ad =3D
developed for representing rights (we were calling it coupons, though=
 I k=3D
now it is a mis-leading as well) soon to the group (atleast this time=
 ;-)=3D
).</DIV> <DIV>&nbsp;</DIV> <DIV>Raghu.<BR></DIV> <BLOCKQUOTE style=
=3D3D"BO=3D
RDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PA=
DDIN=3D
G-LEFT: 5px; PADDING-RIGHT: 0px"> <DIV style=3D3D"FONT: 10pt Arial">-=
---- O=3D
riginal Message -----</DIV> <DIV style=3D3D"BACKGROUND: #e4e4e4; FONT=
: 10pt=3D
Arial; FONT-COLOR: black"><B>From:</B>&nbsp;Ko Fujimura</DIV> <DIV st=
yle=3D
=3D3D"FONT: 10pt Arial"><B>Sent:</B>&nbsp;Thursday, December 21, 2000=
 6:58 =3D
AM</DIV> <DIV style=3D3D"FONT: 10pt Arial"><B>To:</B>&nbsp;Raghuram R=
ajah</=3D
DIV> <DIV style=3D3D"FONT: 10pt Arial"><B>Cc:</B>&nbsp;Donald E. East=
lake 3=3D
rd; [email-masked]</DIV> <DIV style=3D3D"FONT: 10pt Arial"><B=
>Subje=3D
ct:</B>&nbsp;Re: FW: Draft minutes of trade IETF San Diego</DIV> <DIV=
><BR=3D
></DIV>Hi Raghu,<BR><BR>&gt; Hi Ko / Walter / Donald / all,<BR><BR>I =
thin=3D
k that your mail is intended to sent the mailing list but sent only t=
o me=3D
=2E<BR>Anyway, I would like to answer it.<BR><BR>&gt; I have been a p=
art of=3D
this group for over a month now and haven't seen any discussion on th=
e<B=3D
R>&gt; rights requirements or the RTS in general. Didn't find a whole=
 lot=3D
in the archives either.<BR>&gt; Is there a private group working on t=
hes=3D
e requirements and the RTS framework?<BR><BR>There was. But, about on=
e ye=3D
ar ago I closed it, since it is not active. So, any discussion<BR>sho=
uld =3D
be done the trade mailing list or face-to-face meeting now. We haven'=
t ac=3D
tively<BR>discussed using the mailing list. But, we had 5 face-to-fac=
e me=3D
eting since the 45th IETF Oslo<BR>meeting. I think it enough for disc=
ussi=3D
ng requirements.<BR><BR>&gt; The reason I ask is, I have been leading=
 a d=3D
evelopment of a similar system and have been battling<BR>&gt; the ver=
y sa=3D
me requirements in the context of embedded devices with limited compu=
ting=3D
power.<BR>&gt; We have made some progress in addressing these require=
men=3D
ts and have come up with a generic<BR>&gt; framework. Though the fram=
ewor=3D
k and the model needs more work, I guess we are headed in the right<B=
R>&g=3D
t; direction.<BR><BR>Thank you. But, I think the next work item is to=
 dev=3D
elop draft for Rights Component, i.e., XML<BR>representation of right=
s. I=3D
'm not sure if framework and the model should be specified.<BR><BR>&g=
t; W=3D
e would want to present our model, for review by the WG to develop th=
e RT=3D
S I-D, potentially.<BR><BR>Meeting agenda is chair's decision, but I =
thin=3D
k that Don will allow you to present it.<BR><BR>&gt; Or if the develo=
pmen=3D
t of the framework or model is already underway by the WG, we would l=
ike =3D
to<BR>&gt; contribute to the same. Also, we could adopt the early rel=
ease=3D
s and can act as a test bed.<BR><BR>Any contributions are welcome! I =
hope=3D
you actively join the discussion.<BR><BR>&gt; Please let me know if a=
 pr=3D
ivate group is involved in developing these standards? And if so,<BR>=
&gt;=3D
how can I join that group? How does the working group operate in deve=
lop=3D
ing these drafts?<BR>&gt; Please advise.<BR><BR>Send the trade mailin=
g li=3D
st what you are thinking. Do not hesitate to do so.<BR><BR>Regards,<B=
R><B=3D
R>Ko<BR><BR>P.S. My I ask your company? Just curious.<BR> <DIV></DIV>=
</BL=3D
OCKQUOTE></BODY></HTML><DIV><BR><br clear=3D3Dall><hr>Get your FREE d=
ownloa=3D
d of MSN Explorer at <a href=3D3D"http://explorer.msn.com">http://exp=
lorer.=3D
msn.com</a><br></p></DIV>

------=3D_NextPart_001_0002_01C06B36.9E1312B0--
---------------------------------------------------------------------=
---
Your message was received by [email-masked].
We are an automatic elist command server.  This is a help summary.

If you need to contact a person, the elist service manager may be
reached by sending an email message to:

  [email-masked]

We receive messages and expect the content to be lines with commands.
You may send more than one command per message but each command must
appear completely on a line by itself.  If a line ends with a backsla=
sh
"\" we will add the next line to it before processing it.  Commands i=
n
the Subject: header are ignored.

There are subscriber commands and elist owner commands.  The subscrib=
er
commands are described first.  A brief explanation of all commands is
included here.  A more detailed explanation is available at:

  http://lists.elistx.com/doc/email-manage.html

SUBSCRIBER COMMANDS

The following commands may be sent by anyone to the command server.  =
The
command will be processed according to how the elist is configured.  =
You
will always get a reply telling you if a command was processed and wh=
at
was done.

  subscribe
  unsubscribe
  confirm
  who
  help

SUBSCRIBE

  The word "subscribe" should appear on a line by itself in the body =
of
  the message.  By default the address that will be subscribed is
  selected from the first of the following header fields with a value=
:
  REPLY-TO, FROM, SENDER.

  To subscribe an alternate address, or the address of a third party,
  include it on the line after "subscribe".  Any valid email address =
may
  be specified, e.g.:

    subscribe Raghuram Rajah <[email-masked]>

UNSUBSCRIBE

  The word "unsubscribe" should appear on a line by itself in the bod=
y
  of the message.  By default the address that will be unsubscribed i=
s
  selected from the first of the following header fields with a value=
:
  REPLY-TO, FROM, SENDER.

  To unsubscribe an alternate address, or the address of a third part=
y,
  include it on the line after "unsubscribe".  Any valid email addres=
s
  may be specified, e.g.:

    unsubscribe Raghuram Rajah <[email-masked]>

CONFIRM

  The confirm command line is provided to you by the elist command
  server in response to a subscribe or unsubscribe command.  When you
  receive it you must return the entire command line to the elist ser=
ver
  exactly as it was provided to you.  You may break long lines by
  putting a backslash "\" at the end of the incomplete lines.

  In all cases, the command server will respond to the address in the
  first of the following fields to have a value: REPLY-TO, FROM,
  SENDER.  This reply will indicate the command was received and whet=
her
  or not it was processed.

  If the command was processed a separate message will be sent with t=
he
  results of the command, e.g., in the case of a subscribe command th=
e
  subscriber will be sent a welcome message and in the case of an
  unsubscribe command the subscriber will be sent a good-bye message.

WHO

  The word "who" must appear on a line by itself in the body of the
  message.  If the elist owner permits it a copy of the list of
  subscribers will be returned to you.  If it is not permitted you wi=
ll
  receive an acknowledgement telling you so.

HELP

  When the word "help" appears on a line by itself you receive this
  message.

ELIST OWNER COMMANDS

The following commands are not created by users.  They are created by
the command server and sent to elist owners when an unauthorized mess=
age
is received for distribution.  Although there are many reasons why a
message submitted to an elist is considered unauthorized, it is alway=
s a
direct result of how an elist is configured.

The commands are as follows:

  delete
  distribute
  reject
  spam

DELETE

  This command is used to end all processing of a message.  The messa=
ge
  will be removed from the email queue, it will not be returned to it=
s
  sender, and it will not be distributed to your elist.  See also the
  command reject.

  A representative use of this command is:

      delete yes TOKEN IDENTIFIER

  Note that TOKEN and IDENTIFIER must be replaced by actual values th=
at
  are unique to the message being processed.  The values will have be=
en
  provided to you by the elist command server.  You must supply both =
the
  command "delete" and the confirmation "yes".

DISTRIBUTE

  This command is used to distribute the message to your elist.  If t=
he
  elist is archived a copy will be put there also.

  A representative use of this command is:

      distribute yes TOKEN IDENTIFIER

  Note that TOKEN and IDENTIFIER must be replaced by actual values th=
at
  are unique to the message being processed.  The values will have be=
en
  provided to you by the elist command server.  You must supply both =
the
  command "distribute" and the confirmation "yes".

REJECT

  This command is used to reject the distribution of the message and =
to
  send a message to its sender indicating the message was not authori=
zed
  for distribution.  The message will be removed from the email queue=
,
  it will be returned to its sender, and it will not be distributed t=
o
  your elist.  See also the command "delete".

  A representative use of this command is:

      reject yes TOKEN IDENTIFIER

  Note that TOKEN and IDENTIFIER must be replaced by actual values th=
at
  are unique to the message being processed.  The values will have be=
en
  provided to you by the elist command server.  You must supply both =
the
  command "reject" and the confirmation "yes".

SPAM

  This command is used to tell us that you consider the message spam =
and
  you want us to treat it as such.  The message will be removed from =
the
  email queue, it will not be returned to its sender, and it will not=
 be
  distributed to your elist.  In addition, the message will be forwar=
ded
  to [email-masked] for processing.

  A representative use of this command is:

      spam yes TOKEN IDENTIFIER

  Note that TOKEN and IDENTIFIER must be replaced by actual values th=
at
  are unique to the message being processed.  The values will have be=
en
  provided to you by the elist command server.  You must supply both =
the
  command "spam" and the confirmation "yes".
---------------------------------------------------------------------=
---<br clear=3Dall><hr>Get your FREE download of MSN Explorer at <a h=
ref=3D"http://explorer.msn.com">http://explorer.msn.com</a><br></p>

--Boundary_(ID_PZn1pZ/mqfIbiZ2x4nn4ow)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: QUOTED-PRINTABLE

<HTML><BODY STYLE=3D"font:10pt verdana; border:none;"><DIV>Yes, I did=
 intend to send it to the group and I thought I did too. I am surpris=
ed it was sent only to you. Sorry about the confusion. Thanks for get=
ting me upto speed. <BR><BR>Going forward, do we plan to use the mail=
ing list at all, or would we want to discuss in the f2f only?<BR><BR>=
Will send a write-up on the thoughts that we had developed for repres=
enting rights (we were calling it coupons, though I know it is a mis-=
leading as well) soon to the group (atleast this time ;-) ).<BR><BR>R=
aghu.<BR><BR>----- Original Message -----<BR>From: Ko Fujimura<BR>Sen=
t: Thursday, December 21, 2000 6:58 AM<BR>To: Raghuram Rajah<BR>Cc: D=
onald E. Eastlake 3rd; [email-masked]<BR>Subject: Re: FW: Dra=
ft minutes of trade IETF San Diego<BR><BR><BR>Hi Raghu,<BR><BR>&gt; H=
i Ko / Walter / Donald / all,<BR><BR>I think that your mail is intend=
ed to sent the mailing list but sent only to me.<BR>Anyway, I would l=
ike to answer it.<BR><BR>&gt; I have been a part of this group for ov=
er a month now and haven't seen any discussion on the&nbsp;rights req=
uirements or the RTS in general. Didn't find a whole lot in the archi=
ves either.<BR>&gt; Is there a private group working on these require=
ments and the RTS framework?<BR><BR>There was. But, about one year ag=
o I closed it, since it is not active. So, any discussion<BR>should b=
e done the trade mailing list or face-to-face meeting now. We haven't=
 actively<BR>discussed using the mailing list. But, we had 5 face-to-=
face meeting since the 45th IETF Oslo meeting. I think it enough for =
discussing requirements.<BR><BR>&gt; The reason I ask is, I have been=
 leading a development of a similar system and have been battling&nbs=
p;the very same requirements in the context of embedded devices with =
limi=3D<BR>ted computing power. We have made some progress in address=
ing these requirements and have come up with a generic&nbsp;framework=
. Though the framework and the model needs more work, I guess we are =
headed in the right direction.<BR><BR>Thank you. But, I think the nex=
t work item is to develop draft for Rights Component, i.e., XML repre=
sentation of rights. I'm not sure if framework and the model should b=
e specified.<BR><BR>&gt; We would want to present our model, for revi=
ew by the WG to develop the RTS I-D, potentially.<BR><BR>Meeting agen=
da is chair's decision, but I think that Don will allow you to presen=
t it.<BR><BR>&gt; Or if the development of the framework or model is =
already underway by the WG, we would like to contribute to the same. =
Also, we could adopt the early releases and can=3D<BR>act as a test b=
ed.<BR><BR>Any contributions are welcome! I hope you actively join th=
e discussion.<BR><BR>&gt; Please let me know if a private group is in=
volved in developing these standards? And if so, how can I join that =
group? How does the working group operate in developing these drafts?=
<BR>&gt; Please advise.<BR><BR>Send the trade mailing list what you a=
re thinking. Do not hesitate to do so.<BR><BR>Regards,<BR><BR>Ko<BR><=
BR>P.S. My I ask your company? Just curious.&lt;br clear=3D3Dall&gt;&=
lt;hr&gt;Get your FRE=3D<BR>E download of MSN Explorer at &lt;a href=
=3D3D"http://explorer.msn.com"&gt;http://=3D<BR>explorer.msn.com&lt;/=
a&gt;&lt;br&gt;&lt;/p&gt;<BR><BR>------=3D_NextPart_001_0002_01C06B36=
.9E1312B0<BR>Content-Type: text/html; charset=3D"iso-8859-1"<BR>Conte=
nt-Transfer-Encoding: quoted-printable<BR><BR>&lt;HTML&gt;&lt;BODY ST=
YLE=3D3D"font:10pt verdana; border:none;"&gt;&lt;DIV&gt;Yes, I did in=
t=3D<BR>end to send it to the group and I thought I did too. I am sur=
prised it wa=3D<BR>s sent only to you. Sorry about the confusion. Tha=
nks for getting me upto=3D<BR>speed. &lt;/DIV&gt; &lt;DIV&gt;&amp;nbs=
p;&lt;/DIV&gt; &lt;DIV&gt;Going forward, do we plan to use th=3D<BR>e=
 mailing list at all, or would we want to discuss in the f2f only?&lt=
;/DIV&gt;=3D<BR>&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt; &lt;DIV&gt;Will sen=
d a write-up on the thoughts that we had =3D<BR>developed for represe=
nting rights (we were calling it coupons, though I k=3D<BR>now it is =
a mis-leading as well) soon to the group (atleast this time ;-)=3D<BR=
>).&lt;/DIV&gt; &lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt; &lt;DIV&gt;Raghu.&l=
t;BR&gt;&lt;/DIV&gt; &lt;BLOCKQUOTE style=3D3D"BO=3D<BR>RDER-LEFT: #0=
00000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDIN=3D<BR>G-=
LEFT: 5px; PADDING-RIGHT: 0px"&gt; &lt;DIV style=3D3D"FONT: 10pt Aria=
l"&gt;----- O=3D<BR>riginal Message -----&lt;/DIV&gt; &lt;DIV style=
=3D3D"BACKGROUND: #e4e4e4; FONT: 10pt=3D<BR>Arial; FONT-COLOR: black"=
&gt;&lt;B&gt;From:&lt;/B&gt;&amp;nbsp;Ko Fujimura&lt;/DIV&gt; &lt;DIV=
 style=3D<BR>=3D3D"FONT: 10pt Arial"&gt;&lt;B&gt;Sent:&lt;/B&gt;&amp;=
nbsp;Thursday, December 21, 2000 6:58 =3D<BR>AM&lt;/DIV&gt; &lt;DIV s=
tyle=3D3D"FONT: 10pt Arial"&gt;&lt;B&gt;To:&lt;/B&gt;&amp;nbsp;Raghur=
am Rajah&lt;/=3D<BR>DIV&gt; &lt;DIV style=3D3D"FONT: 10pt Arial"&gt;&=
lt;B&gt;Cc:&lt;/B&gt;&amp;nbsp;Donald E. Eastlake 3=3D<BR>rd; fujimur=
[email-masked]&lt;/DIV&gt; &lt;DIV style=3D3D"FONT: 10pt Arial"&gt;&=
lt;B&gt;Subje=3D<BR>ct:&lt;/B&gt;&amp;nbsp;Re: FW: Draft minutes of t=
rade IETF San Diego&lt;/DIV&gt; &lt;DIV&gt;&lt;BR=3D<BR>&gt;&lt;/DIV&=
gt;Hi Raghu,&lt;BR&gt;&lt;BR&gt;&amp;gt; Hi Ko / Walter / Donald / al=
l,&lt;BR&gt;&lt;BR&gt;I thin=3D<BR>k that your mail is intended to se=
nt the mailing list but sent only to me=3D<BR>.&lt;BR&gt;Anyway, I wo=
uld like to answer it.&lt;BR&gt;&lt;BR&gt;&amp;gt; I have been a part=
 of=3D<BR>this group for over a month now and haven't seen any discus=
sion on the&lt;B=3D<BR>R&gt;&amp;gt; rights requirements or the RTS i=
n general. Didn't find a whole lot=3D<BR>in the archives either.&lt;B=
R&gt;&amp;gt; Is there a private group working on thes=3D<BR>e requir=
ements and the RTS framework?&lt;BR&gt;&lt;BR&gt;There was. But, abou=
t one ye=3D<BR>ar ago I closed it, since it is not active. So, any di=
scussion&lt;BR&gt;should =3D<BR>be done the trade mailing list or fac=
e-to-face meeting now. We haven't ac=3D<BR>tively&lt;BR&gt;discussed =
using the mailing list. But, we had 5 face-to-face me=3D<BR>eting sin=
ce the 45th IETF Oslo&lt;BR&gt;meeting. I think it enough for discuss=
i=3D<BR>ng requirements.&lt;BR&gt;&lt;BR&gt;&amp;gt; The reason I ask=
 is, I have been leading a d=3D<BR>evelopment of a similar system and=
 have been battling&lt;BR&gt;&amp;gt; the very sa=3D<BR>me requiremen=
ts in the context of embedded devices with limited computing=3D<BR>po=
wer.&lt;BR&gt;&amp;gt; We have made some progress in addressing these=
 requiremen=3D<BR>ts and have come up with a generic&lt;BR&gt;&amp;gt=
; framework. Though the framewor=3D<BR>k and the model needs more wor=
k, I guess we are headed in the right&lt;BR&gt;&amp;g=3D<BR>t; direct=
ion.&lt;BR&gt;&lt;BR&gt;Thank you. But, I think the next work item is=
 to dev=3D<BR>elop draft for Rights Component, i.e., XML&lt;BR&gt;rep=
resentation of rights. I=3D<BR>'m not sure if framework and the model=
 should be specified.&lt;BR&gt;&lt;BR&gt;&amp;gt; W=3D<BR>e would wan=
t to present our model, for review by the WG to develop the RT=3D<BR>=
S I-D, potentially.&lt;BR&gt;&lt;BR&gt;Meeting agenda is chair's deci=
sion, but I thin=3D<BR>k that Don will allow you to present it.&lt;BR=
&gt;&lt;BR&gt;&amp;gt; Or if the developmen=3D<BR>t of the framework =
or model is already underway by the WG, we would like =3D<BR>to&lt;BR=
&gt;&amp;gt; contribute to the same. Also, we could adopt the early r=
elease=3D<BR>s and can act as a test bed.&lt;BR&gt;&lt;BR&gt;Any cont=
ributions are welcome! I hope=3D<BR>you actively join the discussion.=
&lt;BR&gt;&lt;BR&gt;&amp;gt; Please let me know if a pr=3D<BR>ivate g=
roup is involved in developing these standards? And if so,&lt;BR&gt;&=
amp;gt;=3D<BR>how can I join that group? How does the working group o=
perate in develop=3D<BR>ing these drafts?&lt;BR&gt;&amp;gt; Please ad=
vise.&lt;BR&gt;&lt;BR&gt;Send the trade mailing li=3D<BR>st what you =
are thinking. Do not hesitate to do so.&lt;BR&gt;&lt;BR&gt;Regards,&l=
t;BR&gt;&lt;B=3D<BR>R&gt;Ko&lt;BR&gt;&lt;BR&gt;P.S. My I ask your com=
pany? Just curious.&lt;BR&gt; &lt;DIV&gt;&lt;/DIV&gt;&lt;/BL=3D<BR>OC=
KQUOTE&gt;&lt;/BODY&gt;&lt;/HTML&gt;&lt;DIV&gt;&lt;BR&gt;&lt;br clear=
=3D3Dall&gt;&lt;hr&gt;Get your FREE downloa=3D<BR>d of MSN Explorer a=
t &lt;a href=3D3D"http://explorer.msn.com"&gt;http://explorer.=3D<BR>=
msn.com&lt;/a&gt;&lt;br&gt;&lt;/p&gt;&lt;/DIV&gt;<BR><BR>------=3D_Ne=
xtPart_001_0002_01C06B36.9E1312B0--<BR>------------------------------=
------------------------------------------<BR>Your message was receiv=
ed by [email-masked].<BR>We are an automatic eli=
st command server.&nbsp; This is a help summary.<BR><BR>If you need t=
o contact a person, the elist service manager may be<BR>reached by se=
nding an email message to:<BR><BR>&nbsp; [email-masked]=
.com<BR><BR>We receive messages and expect the content to be lines wi=
th commands.<BR>You may send more than one command per message but ea=
ch command must<BR>appear completely on a line by itself.&nbsp; If a =
line ends with a backslash<BR>"\" we will add the next line to it bef=
ore processing it.&nbsp; Commands in<BR>the Subject: header are ignor=
ed.<BR><BR>There are subscriber commands and elist owner commands.&nb=
sp; The subscriber<BR>commands are described first.&nbsp; A brief exp=
lanation of all commands is<BR>included here.&nbsp; A more detailed e=
xplanation is available at:<BR><BR>&nbsp; http://lists.elistx.com/doc=
/email-manage.html<BR><BR>SUBSCRIBER COMMANDS<BR><BR>The following co=
mmands may be sent by anyone to the command server.&nbsp; The<BR>comm=
and will be processed according to how the elist is configured.&nbsp;=
 You<BR>will always get a reply telling you if a command was processe=
d and what<BR>was done.<BR><BR>&nbsp; subscribe<BR>&nbsp; unsubscribe=
<BR>&nbsp; confirm<BR>&nbsp; who<BR>&nbsp; help<BR><BR>SUBSCRIBE<BR><=
BR>&nbsp; The word "subscribe" should appear on a line by itself in t=
he body of<BR>&nbsp; the message.&nbsp; By default the address that w=
ill be subscribed is<BR>&nbsp; selected from the first of the followi=
ng header fields with a value:<BR>&nbsp; REPLY-TO, FROM, SENDER.<BR><=
BR>&nbsp; To subscribe an alternate address, or the address of a thir=
d party,<BR>&nbsp; include it on the line after "subscribe".&nbsp; An=
y valid email address may<BR>&nbsp; be specified, e.g.:<BR><BR>&nbsp;=
&nbsp;&nbsp; subscribe Raghuram Rajah &lt;[email-masked]&gt;<B=
R><BR>UNSUBSCRIBE<BR><BR>&nbsp; The word "unsubscribe" should appear =
on a line by itself in the body<BR>&nbsp; of the message.&nbsp; By de=
fault the address that will be unsubscribed is<BR>&nbsp; selected fro=
m the first of the following header fields with a value:<BR>&nbsp; RE=
PLY-TO, FROM, SENDER.<BR><BR>&nbsp; To unsubscribe an alternate addre=
ss, or the address of a third party,<BR>&nbsp; include it on the line=
 after "unsubscribe".&nbsp; Any valid email address<BR>&nbsp; may be =
specified, e.g.:<BR><BR>&nbsp;&nbsp;&nbsp; unsubscribe Raghuram Rajah=
 &lt;[email-masked]&gt;<BR><BR>CONFIRM<BR><BR>&nbsp; The confi=
rm command line is provided to you by the elist command<BR>&nbsp; ser=
ver in response to a subscribe or unsubscribe command.&nbsp; When you=
<BR>&nbsp; receive it you must return the entire command line to the =
elist server<BR>&nbsp; exactly as it was provided to you.&nbsp; You m=
ay break long lines by<BR>&nbsp; putting a backslash "\" at the end o=
f the incomplete lines.<BR><BR>&nbsp; In all cases, the command serve=
r will respond to the address in the<BR>&nbsp; first of the following=
 fields to have a value: REPLY-TO, FROM,<BR>&nbsp; SENDER.&nbsp; This=
 reply will indicate the command was received and whether<BR>&nbsp; o=
r not it was processed.<BR><BR>&nbsp; If the command was processed a =
separate message will be sent with the<BR>&nbsp; results of the comma=
nd, e.g., in the case of a subscribe command the<BR>&nbsp; subscriber=
 will be sent a welcome message and in the case of an<BR>&nbsp; unsub=
scribe command the subscriber will be sent a good-bye message.<BR><BR=
>WHO<BR><BR>&nbsp; The word "who" must appear on a line by itself in =
the body of the<BR>&nbsp; message.&nbsp; If the elist owner permits i=
t a copy of the list of<BR>&nbsp; subscribers will be returned to you=
.&nbsp; If it is not permitted you will<BR>&nbsp; receive an acknowle=
dgement telling you so.<BR><BR>HELP<BR><BR>&nbsp; When the word "help=
" appears on a line by itself you receive this<BR>&nbsp; message.<BR>=
<BR><BR><BR>ELIST OWNER COMMANDS<BR><BR>The following commands are no=
t created by users.&nbsp; They are created by<BR>the command server a=
nd sent to elist owners when an unauthorized message<BR>is received f=
or distribution.&nbsp; Although there are many reasons why a<BR>messa=
ge submitted to an elist is considered unauthorized, it is always a<B=
R>direct result of how an elist is configured.<BR><BR>The commands ar=
e as follows:<BR><BR>&nbsp; delete<BR>&nbsp; distribute<BR>&nbsp; rej=
ect<BR>&nbsp; spam<BR><BR>DELETE<BR><BR>&nbsp; This command is used t=
o end all processing of a message.&nbsp; The message<BR>&nbsp; will b=
e removed from the email queue, it will not be returned to its<BR>&nb=
sp; sender, and it will not be distributed to your elist.&nbsp; See a=
lso the<BR>&nbsp; command reject.<BR><BR>&nbsp; A representative use =
of this command is:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; delete yes =
TOKEN IDENTIFIER<BR><BR>&nbsp; Note that TOKEN and IDENTIFIER must be=
 replaced by actual values that<BR>&nbsp; are unique to the message b=
eing processed.&nbsp; The values will have been<BR>&nbsp; provided to=
 you by the elist command server.&nbsp; You must supply both the<BR>&=
nbsp; command "delete" and the confirmation "yes".<BR><BR>DISTRIBUTE<=
BR><BR>&nbsp; This command is used to distribute the message to your =
elist.&nbsp; If the<BR>&nbsp; elist is archived a copy will be put th=
ere also.<BR><BR>&nbsp; A representative use of this command is:<BR><=
BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; distribute yes TOKEN IDENTIFIER<BR>=
<BR>&nbsp; Note that TOKEN and IDENTIFIER must be replaced by actual =
values that<BR>&nbsp; are unique to the message being processed.&nbsp=
; The values will have been<BR>&nbsp; provided to you by the elist co=
mmand server.&nbsp; You must supply both the<BR>&nbsp; command "distr=
ibute" and the confirmation "yes".<BR><BR>REJECT<BR><BR>&nbsp; This c=
ommand is used to reject the distribution of the message and to<BR>&n=
bsp; send a message to its sender indicating the message was not auth=
orized<BR>&nbsp; for distribution.&nbsp; The message will be removed =
=66rom the email queue,<BR>&nbsp; it will be returned to its sender, =
and it will not be distributed to<BR>&nbsp; your elist.&nbsp; See als=
o the command "delete".<BR><BR>&nbsp; A representative use of this co=
mmand is:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; reject yes TOKEN IDEN=
TIFIER<BR><BR>&nbsp; Note that TOKEN and IDENTIFIER must be replaced =
by actual values that<BR>&nbsp; are unique to the message being proce=
ssed.&nbsp; The values will have been<BR>&nbsp; provided to you by th=
e elist command server.&nbsp; You must supply both the<BR>&nbsp; comm=
and "reject" and the confirmation "yes".<BR><BR>SPAM<BR><BR>&nbsp; Th=
is command is used to tell us that you consider the message spam and<=
BR>&nbsp; you want us to treat it as such.&nbsp; The message will be =
removed from the<BR>&nbsp; email queue, it will not be returned to it=
s sender, and it will not be<BR>&nbsp; distributed to your elist.&nbs=
p; In addition, the message will be forwarded<BR>&nbsp; to abuse@elis=
tx.com for processing.<BR><BR>&nbsp; A representative use of this com=
mand is:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; spam yes TOKEN IDENTIF=
IER<BR><BR>&nbsp; Note that TOKEN and IDENTIFIER must be replaced by =
actual values that<BR>&nbsp; are unique to the message being processe=
d.&nbsp; The values will have been<BR>&nbsp; provided to you by the e=
list command server.&nbsp; You must supply both the<BR>&nbsp; command=
 "spam" and the confirmation "yes".<BR>------------------------------=
------------------------------------------<BR></DIV> <DIV></DIV></BOD=
Y></HTML><DIV><BR><br clear=3Dall><hr>Get your FREE download of MSN E=
xplorer at <a href=3D"http://explorer.msn.com">http://explorer.msn.co=
m</a><br></p></DIV>

--Boundary_(ID_PZn1pZ/mqfIbiZ2x4nn4ow)--

Date: Wed, 20 Dec 2000 18:31:34 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Slides from TRADE WG meeting in SanDiego
To: [email-masked]

The Slides form the TRADE WG meeting in San Diego are available in power
point form from
	<ftp://torque.pothole.com/pub/ietf-trade/IETF-SanDiego/>

Sorry for the delay in making these available.
Donald

=====================================================================
 Donald E. Eastlake 3rd                      [email-masked]
 155 Beaver Street                                +1 508-634-2066(h)
 Milford, MA 01757 USA                            +1 508-261-5434(w)

Date: Wed, 20 Dec 2000 20:48:37 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: FW: Draft minutes of trade IETF San Diego
To: [email-masked]
Cc: [email-masked]

Hi Walter and Donald,

Thank you very much for the minutes. I have a few comments:

Eastlake III Donald-LDE008 wrote:
> 
> Minutes of the Internet Open Trading Protocol Working Group (trade)
> 
> Wednesday, December 13 at 1300-1500
> =====================================
> 
> CHAIR: Donald Eastlake 3rd [email-masked]
> Minutes: Walter Houser [email-masked]
...
> 7. Digital Rights Requirements - also known as Requirement for Generic
> Payments Rights - presentation by Ko Fujimura.

The title was "Requirements for Generic Rights Trading"
 
> RTS is an infrastructure to circulate diverse types of digitally
> represented rights. RTS is enables digital versions of coupons and
> tickets. We need to prevent copying.  RTS should allow sharing between
> several issuers. There are five requirements:
> 
> -       Prevent alternation
> -       Provide non-repudiation,
> -       Provide idempotency (one and only one)
> -       Prevent reproduction
> -       Prevent duplicate redemption.
> 
> Fujimura presented a Chart for Positioning of RTS in trading area shows
> the relationship of RTS with respect to IOTP. Hole observes that one needs
> to trust the coupon. Fujimura replied that trust of the coupon is the
> result of the issuer, which can be handed around by untrusted bodies. 

Yes, but more correctly, I replied that:

"trust of the coupon is the result of the issuer and the RTS. The issuer is
responsible for the contents of the right and the RTS is responsible
for preventing copy. In other words, if there is trust in the issuer and 
the RTS, trust of the holder who transfers or redeems the coupon is not 
required."

> The RTS object is an XML object, which would be defined by the WG.

I think it means that:

"The objects transported by the RTS is an XML Components which would be defined 
by the WG."
 
> Hole observed that the definition of the data representation is distinct from
> the transport issues. The latter may be appropriate for the WG, but they
> are nontrivial.
>
> The working group suggested several terms to use in lieu of digital rights
> or electronic rights, such as trading right, entitlement, coupon, and
> certificate. There was concern about confusion of the term rights with
> access control rights. Entitlement was thought cumbersome. Coupon
> communicates too much of a limitation. Certificate has a specific meaning
> with respect to network security.
...

Please add:

"It was agreed to decide the term using the mailing list."

Thanks.

Ko

Content-return: allowed
Date: Thu, 14 Dec 2000 13:16:42 -0500
From: Eastlake III Donald-LDE008 <[email-masked]>
Subject: FW: Draft minutes of trade IETF San Diego
To: "[email-masked]'" <[email-masked]>

Minutes of the Internet Open Trading Protocol Working Group (trade)

Wednesday, December 13 at 1300-1500
=====================================

CHAIR: Donald Eastlake 3rd [email-masked]
Minutes: Walter Houser [email-masked]

AGENDA:

 1  Agenda Bashing
 2  Status of Documents
 3  Implementation Experience
 4  Documents in Last Call
 5  New Charter
 6  ECML V2 Requirements
 7  Digital Rights Requirements
 8  IOTP V2 Requirements
 9  TRADE Mailing List Inactivity
10  Schedule of Future Actions/Meetings

1. Agenda basking - no changes. 

2. Status of Documents - Five RFCs have been issued and are listed on the
current charter at http://ietf.org/html.charters/trade-charter.html. 
Two drafts are in working group last call and a few more in process, also
listed on the charter page.

3. Implementation Experiences of IOTP
 - Hitachi, et al, 
 - Chris Smith, Royal Bank of Canada. 
Betty deBruijn asked for contacts for implementers. Don said he would
contact Hitachi and post a contact for them if they will provide one. 

4. Of the currents drafts, two are in last call: Payment API for v1.0
Internet Open Trading Protocol (IOTP) at
http://ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-papi-03.txt and 
SET Supplement for the v1.0 Internet Open Trading Protocol (IOTP) at
http://ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-set-02.txt

5. New Charter - Don presented the language for the new charter to be
considered by the IESG on December 28, 2000. It has not changed much from
previous charters.  Two items are declared out of scope for IOTP version
2.0: legal and regulatory issues with respect to the implementation of the
protocol, design of the XML messaging layer. The WG will specify the
requirements for digitally represented trading rights. The WG will specify
requirements and a syntax and processing model for ECML v2. Ned suggested
that Secure Channel Credit/Debit be referred to in the Charter text.  Ko
Fujimura asked that DRT specifications be added to the new charter. There
was a consensus among those at the meeting to do this.

00 Nov WG Last Call of SET Supplement and Payment API
00 Dec ID for Secure Channel Credit and debit
00 Dec submit to IESG SET Supplement and Payment API
00 Dec ID for ECML V2.0 requirements
01 Jan submit to IESG "Digital Requirements" and ECML v2.0 requirements
01 Jan ID of ECML v2.0 specification
01 Mar submit to IESG Secure Channel Credit/Debit
01 Apr submit to IESG IOTP V2.0 requirements 
01 Apr submit to IESG ECML V2.0 specification (proposed standard in XML) 

6. ECML Version 2.0 Requirements Document by Parsons and Shepherd. ECML
v1.0 describes the customer to merchant fields to be transferred in an
HTML form. There is also a usage guide. Steve Hole and Ko Fujimura raised
the question "Should there be a more explicit data model?" There are
fields for carrying the transaction. Don Eastlake thought this could be
added to the requirements document.  ECML should include multiple payment
elements and types and improved company-to-company exchanges. It also
refers to P3P for eCommerce, W3C note dated Nov 29, 1999. This note is
ECML v1.0 plus some more payment fields but with strong P3P flavor.
Shipper information and other more complex information should go to IOTP.
Microsoft and Versign have established WinPayment.  IFX and OFX are in
competition. Mark Hale of Interval noted that Mismal and IFX have
fundamental differences in how they write their specification. When we say
XML, Hole asked, "Do you go for attribute values or do you go for sub
elements?" 

Eastlake asked for specification applications for the ECML v2 requirements
document; the current entries are left over from the XMLDSIG document.
Hole suggested making the content representation like the generic
representation. This would allow us to move the objects around. Mia
Lahteenmaki asked what does the "simcard" string field mean and what is the
protocol reference for SIM card payment? Kevin McCandliss asked "What about
verification?" Eastlake said this is referenced via ISO 8583. Hole says it
is
usually out-of-band, say over SSL or using EBXML payload in an S/MIME
envelope. 

7. Digital Rights Requirements - also known as Requirement for Generic
Payments Rights - presentation by Ko Fujimura. 

RTS is an infrastructure to circulate diverse types of digitally
represented rights. RTS is enables digital versions of coupons and
tickets. We need to prevent copying.  RTS should allow sharing between
several issuers. There are five requirements: 

-	Prevent alternation  
-	Provide non-repudiation, 
-	Provide idempotency (one and only one) 
-	Prevent reproduction
-	Prevent duplicate redemption. 

Fujimura presented a Chart for Positioning of RTS in trading area shows
the relationship of RTS with respect to IOTP. Hole observes that one needs
to trust the coupon. Fujimura replied that trust of the coupon is the
result of the issuer, which can be handed around by untrusted bodies. The
RTS object is an XML object, which would be defined by the WG. Hole
observed that the definition of the data representation is distinct from
the transport issues. The latter may be appropriate for the WG, but they
are nontrivial. 

The working group suggested several terms to use in lieu of digital rights
or electronic rights, such as trading right, entitlement, coupon, and
certificate. There was concern about confusion of the term rights with
access control rights. Entitlement was thought cumbersome. Coupon
communicates too much of a limitation. Certificate has a specific meaning
with respect to network security. 

8. IOTP v2 requirements. 
An author is needed for a number of items in this document. Some have
asked for a standard way in IOTP v2 for payment protocols to communicate
outside of IOTP as well as the current payment tunneling through IOTP v1.
V2 would include payment for real property, personal property, or personal
services. It may not include escrow payments depending on whether the
dynamic definition of trading sequences area is included in v2. Customer
workflow processes are out of scope for v2. Status queries are in scope. 

9. Inactivity of the mailing lists.  Should we advertise the work of the
WG on other mailing lists? Hole suggested several groups including IFX and
OFX. They both do payment vehicles for merchant requirements. 

10. The WG will meet in Minneapolis in March. Meanwhile, we need to finish
up the ECML requirements and the specification documents. There was no
call to hold an interim meeting. 

Date: Fri, 01 Dec 2000 13:58:51 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Draft TRADE WG San Diego Meeting Agenda
To: [email-masked]
Cc: [email-masked]

Here is a rough preliminary draft agenda.  Comments welcome.

TRADE WG Draft Agenda

13:00	Agenday Bashing
13:10	New Charter (*) / Document Status
13:20	Implementation Experience
13:30	Documents in Last Call
	- Payment API
	- SET Supplement
13:45	ECML V2 Requirements
14:05	Digital Rights Requirements
14:30	IOTP V2 Requirements
14:50	Schedule Future Actions/Meetings
15:00	End

* = I have submitted a new charter to our Area Director.  By
the December meeting it may have been approved or we may have
feedback on it.

=====================================================================
 Donald E. Eastlake 3rd                      [email-masked]
 155 Beaver Street                                +1 508-634-2066(h)
 Milford, MA 01757 USA                            +1 508-261-5434(w)