Company Change - Chris Smith

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

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

Raghu.

-= ---- O=3D riginal Message -----

From: Ko Fujimura

Sent: Thursday, December 21, 2000= 6:58 =3D AM

To: Raghuram R= ajah
Cc: Donald E. East= lake 3=3D rd; fujimura@isl.ntt.co.jp

Subje=3D ct: Re: FW: Draft minutes of trade IETF San Diego

Hi Raghu,

> Hi Ko / Walter / Donald / all,

I = thin=3D k that your mail is intended to sent the mailing list but sent only t= o me=3D =2E
Anyway, I would like to answer it.

> I have been a p= art of=3D this group for over a month now and haven't seen any discussion on th= e> rights requirements or the RTS in general. Didn't find a whole= lot=3D in the archives either.
> Is there a private group working on t= hes=3D e requirements and the RTS framework?

There was. But, about on= e ye=3D ar ago I closed it, since it is not active. So, any discussion
sho= uld =3D be done the trade mailing list or face-to-face meeting now. We haven'= t ac=3D tively
discussed using the mailing list. But, we had 5 face-to-fac= e me=3D eting since the 45th IETF Oslo
meeting. I think it enough for disc= ussi=3D ng requirements.

> The reason I ask is, I have been leading= a d=3D evelopment of a similar system and have been battling
> the ver= y sa=3D me requirements in the context of embedded devices with limited compu= ting=3D power.
> We have made some progress in addressing these require= men=3D ts and have come up with a generic
> framework. Though the fram= ewor=3D k and the model needs more work, I guess we are headed in the right&g=3D t; direction.

Thank you. But, I think the next work item is to= dev=3D elop draft for Rights Component, i.e., XML
representation of right= s. I=3D 'm not sure if framework and the model should be specified.

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

Meeting agenda is chair's decision, but I = thin=3D k that Don will allow you to present it.

> Or if the develo= pmen=3D t of the framework or model is already underway by the WG, we would l= ike =3D to
> contribute to the same. Also, we could adopt the early rel= ease=3D s and can act as a test bed.

Any contributions are welcome! I = hope=3D you actively join the discussion.

> Please let me know if a= pr=3D ivate group is involved in developing these standards? And if so,
= >=3D how can I join that group? How does the working group operate in deve= lop=3D ing these drafts?
> Please advise.

Send the trade mailin= g li=3D st what you are thinking. Do not hesitate to do so.

Regards,Ko

P.S. My I ask your company? Just curious.

=

Get your FREE d= ownloa=3D d of MSN Explorer at http://exp= lorer.=3D msn.com
------=3D_NextPart_001_0002_01C06B36.9E1312B0-- ---------------------------------------------------------------------= --- Your message was received by ietf-trade-request@lists.elistx.com. 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: ietf-trade-help@lists.elistx.com 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 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 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 abuse@elistx.com 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". ---------------------------------------------------------------------= ---
Get your FREE download of MSN Explorer at http://explorer.msn.com
--Boundary_(ID_PZn1pZ/mqfIbiZ2x4nn4ow) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE
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.

Going forward, do we plan to use the mail= ing 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 ;-) ).

R= aghu.

----- Original Message -----
From: Ko Fujimura
Sen= t: Thursday, December 21, 2000 6:58 AM
To: Raghuram Rajah
Cc: D= onald E. Eastlake 3rd; fujimura@isl.ntt.co.jp
Subject: Re: FW: Dra= ft minutes of trade IETF San Diego

Hi Raghu,

> H= i Ko / Walter / Donald / all,

I think that your mail is intend= ed to sent the mailing list but sent only to me.
Anyway, I would l= ike to answer it.

> I have been a part of this group for ov= er a month now and haven't seen any discussion on the rights req= uirements or the RTS in general. Didn't find a whole lot in the archi= ves either.
> Is there a private group working on these require= ments and the RTS framework?

There was. But, about one year ag= o I closed it, since it is not active. So, any discussion
should b= e 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 requirements.

> 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
ted computing power. We have made some progress in address= ing these requirements and have come up with a generic framework= . Though the framework and the model needs more work, I guess we are = headed in the right direction.

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.

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

Meeting agen= da is chair's decision, but I think that Don will allow you to presen= t 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 adopt the early releases and can=3D
act as a test b= ed.

Any contributions are welcome! I hope you actively join th= e discussion.

> 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?=
> Please advise.

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

Regards,

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

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

<HTML><BODY ST= YLE=3D3D"font:10pt verdana; border:none;"><DIV>Yes, I did in= t=3D
end to send it to the group and I thought I did too. I am sur= prised it wa=3D
s sent only to you. Sorry about the confusion. Tha= nks for getting me upto=3D
speed. </DIV> <DIV>&nbs= p;</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> </DIV> <DIV>Will sen= d a write-up on the thoughts that we had =3D
developed for represe= nting 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> </DIV> <DIV>Raghu.&l= t;BR></DIV> <BLOCKQUOTE style=3D3D"BO=3D
RDER-LEFT: #0= 00000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDIN=3D
G-= LEFT: 5px; PADDING-RIGHT: 0px"> <DIV style=3D3D"FONT: 10pt Aria= l">----- O=3D
riginal Message -----</DIV> <DIV style= =3D3D"BACKGROUND: #e4e4e4; FONT: 10pt=3D
Arial; FONT-COLOR: black"= ><B>From:</B> Ko Fujimura</DIV> <DIV= style=3D
=3D3D"FONT: 10pt Arial"><B>Sent:</B>&= nbsp;Thursday, December 21, 2000 6:58 =3D
AM</DIV> <DIV s= tyle=3D3D"FONT: 10pt Arial"><B>To:</B> Raghur= am Rajah</=3D
DIV> <DIV style=3D3D"FONT: 10pt Arial">&= lt;B>Cc:</B> Donald E. Eastlake 3=3D
rd; fujimur= a@isl.ntt.co.jp</DIV> <DIV style=3D3D"FONT: 10pt Arial">&= lt;B>Subje=3D
ct:</B> Re: FW: Draft minutes of t= rade IETF San Diego</DIV> <DIV><BR=3D
></DIV&= gt;Hi Raghu,<BR><BR>> Hi Ko / Walter / Donald / al= l,<BR><BR>I thin=3D
k that your mail is intended to se= nt the mailing list but sent only to me=3D
.<BR>Anyway, I wo= uld like to answer it.<BR><BR>> I have been a part= of=3D
this group for over a month now and haven't seen any discus= sion on the<B=3D
R>> rights requirements or the RTS i= n general. Didn't find a whole lot=3D
in the archives either.<B= R>> Is there a private group working on thes=3D
e requir= ements and the RTS framework?<BR><BR>There was. But, abou= t one ye=3D
ar ago I closed it, since it is not active. So, any di= scussion<BR>should =3D
be done the trade mailing list or fac= e-to-face meeting now. We haven't ac=3D
tively<BR>discussed = using the mailing list. But, we had 5 face-to-face me=3D
eting sin= ce the 45th IETF Oslo<BR>meeting. I think it enough for discuss= i=3D
ng requirements.<BR><BR>> The reason I ask= is, I have been leading a d=3D
evelopment of a similar system and= have been battling<BR>> the very sa=3D
me requiremen= ts in the context of embedded devices with limited computing=3D
po= wer.<BR>> We have made some progress in addressing these= requiremen=3D
ts and have come up with a generic<BR>&gt= ; framework. Though the framewor=3D
k and the model needs more wor= k, I guess we are headed in the right<BR>&g=3D
t; direct= ion.<BR><BR>Thank you. But, I think the next work item is= to dev=3D
elop draft for Rights Component, i.e., XML<BR>rep= resentation of rights. I=3D
'm not sure if framework and the model= should be specified.<BR><BR>> W=3D
e would wan= t to present our model, for review by the WG to develop the RT=3D
= S I-D, potentially.<BR><BR>Meeting agenda is chair's deci= sion, but I thin=3D
k that Don will allow you to present it.<BR= ><BR>> Or if the developmen=3D
t of the framework = or model is already underway by the WG, we would like =3D
to<BR= >> contribute to the same. Also, we could adopt the early r= elease=3D
s and can act as a test bed.<BR><BR>Any cont= ributions are welcome! I hope=3D
you actively join the discussion.= <BR><BR>> Please let me know if a pr=3D
ivate g= roup is involved in developing these standards? And if so,<BR>&= amp;gt;=3D
how can I join that group? How does the working group o= perate in develop=3D
ing these drafts?<BR>> Please ad= vise.<BR><BR>Send the trade mailing li=3D
st what you = are thinking. Do not hesitate to do so.<BR><BR>Regards,&l= t;BR><B=3D
R>Ko<BR><BR>P.S. My I ask your com= pany? Just curious.<BR> <DIV></DIV></BL=3D
OC= KQUOTE></BODY></HTML><DIV><BR><br clear= =3D3Dall><hr>Get your FREE downloa=3D
d of MSN Explorer a= t <a href=3D3D"http://explorer.msn.com">http://explorer.=3D
= msn.com</a><br></p></DIV>

------=3D_Ne= xtPart_001_0002_01C06B36.9E1312B0--
------------------------------= ------------------------------------------
Your message was receiv= ed by ietf-trade-request@lists.elistx.com.
We are an automatic eli= st command server. This is a help summary.

If you need t= o contact a person, the elist service manager may be
reached by se= nding an email message to:

ietf-trade-help@lists.elistx= .com

We receive messages and expect the content to be lines wi= th commands.
You may send more than one command per message but ea= ch command must
appear completely on a line by itself. If a = line ends with a backslash
"\" we will add the next line to it bef= ore processing it. Commands in
the Subject: header are ignor= ed.

There are subscriber commands and elist owner commands.&nb= sp; The subscriber
commands are described first. A brief exp= lanation of all commands is
included here. A more detailed e= xplanation is available at:

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

SUBSCRIBER COMMANDS

The following co= mmands may be sent by anyone to the command server. The
comm= and will be processed according to how the elist is configured. = You
will always get a reply telling you if a command was processe= d and what
was done.

subscribe
unsubscribe=
confirm
who
help

SUBSCRIBE
<= BR> The word "subscribe" should appear on a line by itself in t= he body of
the message. By default the address that w= ill be subscribed is
selected from the first of the followi= ng header fields with a value:
REPLY-TO, FROM, SENDER.
<= BR> To subscribe an alternate address, or the address of a thir= d party,
include it on the line after "subscribe". An= y valid email address may
be specified, e.g.:

=    subscribe Raghuram Rajah <rraghuram@hotmail.com>
UNSUBSCRIBE

The word "unsubscribe" should appear = on a line by itself in the body
of the message. By de= fault the address that will be unsubscribed is
selected fro= m the first of the following header fields with a value:
RE= PLY-TO, FROM, SENDER.

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

    unsubscribe Raghuram Rajah= <rraghuram@hotmail.com>

CONFIRM

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

In all cases, the command serve= r 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 whether
o= r not it was processed.

If the command was processed a = separate message will be sent with the
results of the comma= nd, e.g., in the case of a subscribe command the
subscriber= will be sent a welcome message and in the case of an
unsub= scribe 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 i= t a copy of the list of
subscribers will be returned to you= . If it is not permitted you will
receive an acknowle= dgement 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 no= t created by users. They are created by
the command server a= nd sent to elist owners when an unauthorized message
is received f= or distribution. Although there are many reasons why a
messa= ge submitted to an elist is considered unauthorized, it is always adirect result of how an elist is configured.

The commands ar= e as follows:

delete
distribute
rej= ect
spam

DELETE

This command is used t= o end all processing of a message. The message
will b= e removed from the email queue, it will not be returned to its
&nb= sp; sender, and it will not be distributed to your elist. See a= lso 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 that
are unique to the message b= eing processed. The values will have been
provided to= you by the elist command server. You must supply both the
&= nbsp; command "delete" and the confirmation "yes".

DISTRIBUTE<= BR>
This command is used to distribute the message to your = elist. If the
elist is archived a copy will be put th= ere also.

A representative use of this command is:
<= BR>      distribute yes TOKEN IDENTIFIER
=
Note that TOKEN and IDENTIFIER must be replaced by actual = values that
are unique to the message being processed. = ; The values will have been
provided to you by the elist co= mmand server. You must supply both the
command "distr= ibute" and the confirmation "yes".

REJECT

This c= ommand is used to reject the distribution of the message and to
&n= bsp; send a message to its sender indicating the message was not auth= orized
for distribution. The message will be removed = =66rom the email queue,
it will be returned to its sender, = and it will not be distributed to
your elist. See als= o the command "delete".

A representative use of this co= mmand is:

      reject yes TOKEN IDEN= TIFIER

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

SPAM

Th= is command is used to tell us that you consider the message spam and<= BR> you want us to treat it as such. The message 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.&nbs= p; In addition, the message will be forwarded
to abuse@elis= tx.com for processing.

A representative use of this com= mand is:

      spam yes TOKEN IDENTIF= IER

Note that TOKEN and IDENTIFIER must be replaced by = actual values that
are unique to the message being processe= d. The values will have been
provided to you by the e= list command server. You must supply both the
command= "spam" and the confirmation "yes".
------------------------------= ------------------------------------------

Get your FREE download of MSN E= xplorer at http://explorer.msn.co= m
--Boundary_(ID_PZn1pZ/mqfIbiZ2x4nn4ow)-- Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5W004013TDC2@eListX.com>; Wed, 20 Dec 2000 18:27:13 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5W004013TCC1@eListX.com>; Wed, 20 Dec 2000 18:27:12 -0500 (EST) Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5W004043TCBX@eListX.com> (original mail from dee3@torque.pothole.com) ; Wed, 20 Dec 2000 18:27:12 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5W004013TBBV@eListX.com> for ietf-trade@elist.lists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Wed, 20 Dec 2000 18:27:11 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5W004013TBBU@eListX.com> for ietf-trade@elist.lists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Wed, 20 Dec 2000 18:27:11 -0500 (EST) Received: from torque.pothole.com ([38.138.52.132]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G5W000E83T9NJ@eListX.com> for ietf-trade@lists.elistx.com; Wed, 20 Dec 2000 18:27:11 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id SAA31326 for ietf-trade@lists.elistx.com; Wed, 20 Dec 2000 18:31:34 -0500 (EST) Date: Wed, 20 Dec 2000 18:31:34 -0500 From: "Donald E. Eastlake 3rd" Subject: Slides from TRADE WG meeting in SanDiego To: ietf-trade@lists.elistx.com Message-id: <200012202331.SAA31326@torque.pothole.com> Content-type: TEXT/PLAIN X-Authentication-warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , X-MTS: smtp The Slides form the TRADE WG meeting in San Diego are available in power point form from Sorry for the delay in making these available. Donald ===================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1 508-634-2066(h) Milford, MA 01757 USA +1 508-261-5434(w) Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5V00C017BFZ8@eListX.com>; Wed, 20 Dec 2000 06:45:15 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5V00C017BEZ6@eListX.com>; Wed, 20 Dec 2000 06:45:15 -0500 (EST) Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5V00C047BEZ3@eListX.com> (original mail from fujimura@isl.ntt.co.jp) ; Wed, 20 Dec 2000 06:45:14 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5V00C017BDZ1@eListX.com> for ietf-trade@elist.lists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Wed, 20 Dec 2000 06:45:13 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5V00C017BDZ0@eListX.com> for ietf-trade@elist.lists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Wed, 20 Dec 2000 06:45:13 -0500 (EST) Received: from tama3.tas.ntt.co.jp (tama3.tas.ntt.co.jp [192.68.248.40]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G5V00BA17BBJE@eListX.com> for ietf-trade@lists.elistx.com; Wed, 20 Dec 2000 06:45:13 -0500 (EST) Received: from nttmail.ecl.ntt.co.jp (nttmail.tas.ntt.co.jp [192.68.248.11]) by tama3.tas.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id UAA15119 for ; Wed, 20 Dec 2000 20:44:32 +0900 (JST envelope-from fujimura@isl.ntt.co.jp) Received: from alsace.isl.ntt.co.jp by nttmail.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/10/05/00) with ESMTP id UAA27336 for ; Wed, 20 Dec 2000 20:44:31 +0900 (JST envelope-from fujimura@isl.ntt.co.jp) Received: from isl.ntt.co.jp (degas.isl.ntt.co.jp [129.60.104.56]) by alsace.isl.ntt.co.jp (8.8.8/3.7W) with ESMTP id UAA04225; Wed, 20 Dec 2000 20:44:30 +0900 (JST) Date: Wed, 20 Dec 2000 20:48:37 +0900 From: Ko Fujimura Subject: Re: FW: Draft minutes of trade IETF San Diego To: ietf-trade@lists.elistx.com Cc: fujimura@isl.ntt.co.jp Message-id: <3A409C95.F1746D9B@isl.ntt.co.jp> MIME-version: 1.0 X-Mailer: Mozilla 4.75 [ja] (Win98; U) Content-type: text/plain Content-transfer-encoding: 7BIT X-Accept-Language: ja References: <51228FAD179FD4118A8600D0B76FE2621881A2@ma07exm01.corp.isg.mot.com> List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , 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 dee3@torque.pothole.com > Minutes: Walter Houser houser.walt@forum.va.gov ... > 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 Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5K00501LGYAU@eListX.com>; Thu, 14 Dec 2000 13:17:22 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5K00501LGYAS@eListX.com>; Thu, 14 Dec 2000 13:17:22 -0500 (EST) Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5K00504LGXAP@eListX.com> (original mail from Donald.Eastlake@motorola.com); Thu, 14 Dec 2000 13:17:21 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5K00501LGXAN@eListX.com> for ietf-trade@elist.lists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Thu, 14 Dec 2000 13:17:21 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5K00501LGWAM@eListX.com> for ietf-trade@elist.lists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Thu, 14 Dec 2000 13:17:20 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G5K0025TLGWW3@eListX.com> for ietf-trade@lists.elistx.com; Thu, 14 Dec 2000 13:17:20 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id LAA19445 for ; Thu, 14 Dec 2000 11:16:45 -0700 (MST) Received: [from ma07exm01.corp.isg.mot.com (ma07exm01.corp.isg.mot.com [134.33.90.80]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id LAA24797 for ; Thu, 14 Dec 2000 11:16:44 -0700 (MST) Received: by ma07exm01.corp.isg.mot.com with Internet Mail Service (5.5.2651.58) id ; Thu, 14 Dec 2000 13:16:43 -0500 Content-return: allowed Date: Thu, 14 Dec 2000 13:16:42 -0500 From: Eastlake III Donald-LDE008 Subject: FW: Draft minutes of trade IETF San Diego To: "'ietf-trade@lists.elistx.com'" Message-id: <51228FAD179FD4118A8600D0B76FE2621881A2@ma07exm01.corp.isg.mot.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , Minutes of the Internet Open Trading Protocol Working Group (trade) Wednesday, December 13 at 1300-1500 ===================================== CHAIR: Donald Eastlake 3rd dee3@torque.pothole.com Minutes: Walter Houser houser.walt@forum.va.gov 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. Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4W00101KJR7H@eListX.com>; Fri, 01 Dec 2000 13:55:04 -0500 (EST) Received: from ELISTS-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4W00103KJP76@eListX.com> (original mail from dee3@torque.pothole.com) ; Fri, 01 Dec 2000 13:55:01 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4W00101KJH73@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Fri, 01 Dec 2000 13:54:54 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4W00101KJE72@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Fri, 01 Dec 2000 13:54:52 -0500 (EST) Received: from torque.pothole.com ([38.138.52.132]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G4W00MIUKJAAV@eListX.com> for ietf-trade@lists.elistx.com; Fri, 01 Dec 2000 13:54:48 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id NAA07043; Fri, 01 Dec 2000 13:58:51 -0500 (EST) Date: Fri, 01 Dec 2000 13:58:51 -0500 From: "Donald E. Eastlake 3rd" Subject: Draft TRADE WG San Diego Meeting Agenda To: ietf-trade@lists.elistx.com Cc: lde008@dma.isg.mot.com Message-id: <200012011858.NAA07043@torque.pothole.com> Content-type: TEXT/PLAIN X-Authentication-warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , X-MTS: smtp 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 dee3@torque.pothole.com 155 Beaver Street +1 508-634-2066(h) Milford, MA 01757 USA +1 508-261-5434(w) Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G6200E047GBDK@eListX.com> (original mail from smith@interlog.com); Sun, 24 Dec 2000 01:31:23 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G6200E017GADI@eListX.com> for ietf-trade@elist.lists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Sun, 24 Dec 2000 01:31:23 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G6200E017GADH@eListX.com> for ietf-trade@elist.lists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Sun, 24 Dec 2000 01:31:22 -0500 (EST) Received: from smtp.interlog.com (bretweir.total.net [154.11.89.176]) by eListX.com (PMDF V6.0-24 #44856) with SMTP id <0G6200AEM7GAAJ@eListX.com> for ietf-trade@lists.elistx.com; Sun, 24 Dec 2000 01:31:22 -0500 (EST) Received: (qmail 26435 invoked from network); Sun, 24 Dec 2000 06:30:44 +0000 Received: from unknown (HELO ip95.toronto79.dialup.canada.psi.net) (154.20.73.95) by bretweir.total.net with SMTP; Sun, 24 Dec 2000 06:30:44 +0000 Date: Sun, 24 Dec 2000 01:30:53 -0500 (Eastern Standard Time) From: Chris Smith Subject: Taxation (again) In-reply-to: <55D770EEA49FD4118FDE00D0B7692F912430C6@SE001035.rbc1.royalbank.com> X-X-Sender: smith@mail.interlog.com To: ietf-trade@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , 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 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5Z00104N6YJ9@eListX.com> (original mail from CHRIS.SMITH@ROYALBANK.COM) ; Fri, 22 Dec 2000 16:18:35 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5Z00101N6XJ5@eListX.com> for ietf-trade@elist.lists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Fri, 22 Dec 2000 16:18:34 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5Z00101N6XJ4@eListX.com> for ietf-trade@elist.lists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Fri, 22 Dec 2000 16:18:33 -0500 (EST) Received: from uhrbc1p1.royalbank.com (uhrbc1p1.royalbank.com [198.96.131.220]) by eListX.com (PMDF V6.0-24 #44856) with SMTP id <0G5Z00KD9N6WKK@eListX.com> for ietf-trade@lists.elistx.com; Fri, 22 Dec 2000 16:18:33 -0500 (EST) Received: from wsecure2.royalbank.com by uhrbc1p1.royalbank.com via smtpd (for one.elistx.com [209.116.252.130]) with SMTP; Fri, 22 Dec 2000 21:14:21 +0000 (UT) Received: from 10.224.0.67 by se001020.royalbank.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v4.5); Fri, 22 Dec 2000 16:20:25 -0500 Received: by SE001017.rbc1.royalbank.com with Internet Mail Service ( 5.5.2650.21) id ; Fri, 22 Dec 2000 16:17:53 -0500 Date: Fri, 22 Dec 2000 16:17:52 -0500 From: "Smith, Chris " Subject: Company Change - Chris Smith To: ietf-trade@lists.elistx.com Cc: "'tim.mcgaugh@royalbank.com'" Message-id: <55D770EEA49FD4118FDE00D0B7692F912430C6@SE001035.rbc1.royalbank.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: multipart/alternative; boundary="Boundary_(ID_3oN/3GrVzTxtnKOLOybwzQ)" X-Server-Uuid: d237928a-6c98-11d3-985c-00a0c9ea509d X-WSS-ID: 165D1A13719447-01-01 List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , 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 chris.smith@royalbank.com, those items can be directed to smith@interlog.com . 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 tim.mcgaugh@royalbank.com 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 Company Change - Chris Smith

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
chris.smith@royalbank.com, those items can be directed
to    smith@interlog.com    . 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
    tim.mcgaugh@royalbank.com

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)-- Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5X00G01DYT28@eListX.com>; Thu, 21 Dec 2000 11:04:05 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5X00G01DYT27@eListX.com>; Thu, 21 Dec 2000 11:04:05 -0500 (EST) Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5X00G04DYS22@eListX.com> (original mail from rraghuram@hotmail.com) ; Thu, 21 Dec 2000 11:04:05 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5X00G01DYR1Y@eListX.com> for ietf-trade@elist.lists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Thu, 21 Dec 2000 11:04:04 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5X00G01DYQ1X@eListX.com> for ietf-trade@elist.lists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Thu, 21 Dec 2000 11:04:02 -0500 (EST) Received: from hotmail.com (oe68.law7.hotmail.com [216.33.236.207]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G5X00E5TDYPLL@eListX.com> for ietf-trade@lists.elistx.com; Thu, 21 Dec 2000 11:04:02 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 21 Dec 2000 08:03:23 -0800 Date: Thu, 21 Dec 2000 11:06:52 -0500 From: Raghuram Rajah Subject: Fw: FW: Draft minutes of trade IETF San Diego X-Originating-IP: [64.240.212.5] To: ietf-trade@lists.elistx.com Message-id: MIME-version: 1.0 X-Mailer: MSN Explorer 6.00.0010.0900 Content-type: multipart/alternative; boundary="Boundary_(ID_PZn1pZ/mqfIbiZ2x4nn4ow)" List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , X-OriginalArrivalTime: 21 Dec 2000 16:03:23.0798 (UTC) FILETIME=[8BD21B60:01C06B67] --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; fujimura@isl.ntt.co.jp 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.
Get yo= ur FRE=3D E download of MSN Explorer at h= ttp://=3D explorer.msn.com
------=3D_NextPart_001_0002_01C06B36.9E1312B0 Content-Type: text/html; charset=3D"iso-8859-1" Content-Transfer-Encoding: quoted-printable
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.

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

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

Raghu.

-= ---- O=3D riginal Message -----

From: Ko Fujimura

Sent: Thursday, December 21, 2000= 6:58 =3D AM

To: Raghuram R= ajah
Cc: Donald E. East= lake 3=3D rd; fujimura@isl.ntt.co.jp

Subje=3D ct: Re: FW: Draft minutes of trade IETF San Diego

Hi Raghu,

> Hi Ko / Walter / Donald / all,

I = thin=3D k that your mail is intended to sent the mailing list but sent only t= o me=3D =2E
Anyway, I would like to answer it.

> I have been a p= art of=3D this group for over a month now and haven't seen any discussion on th= e> rights requirements or the RTS in general. Didn't find a whole= lot=3D in the archives either.
> Is there a private group working on t= hes=3D e requirements and the RTS framework?

There was. But, about on= e ye=3D ar ago I closed it, since it is not active. So, any discussion
sho= uld =3D be done the trade mailing list or face-to-face meeting now. We haven'= t ac=3D tively
discussed using the mailing list. But, we had 5 face-to-fac= e me=3D eting since the 45th IETF Oslo
meeting. I think it enough for disc= ussi=3D ng requirements.

> The reason I ask is, I have been leading= a d=3D evelopment of a similar system and have been battling
> the ver= y sa=3D me requirements in the context of embedded devices with limited compu= ting=3D power.
> We have made some progress in addressing these require= men=3D ts and have come up with a generic
> framework. Though the fram= ewor=3D k and the model needs more work, I guess we are headed in the right&g=3D t; direction.

Thank you. But, I think the next work item is to= dev=3D elop draft for Rights Component, i.e., XML
representation of right= s. I=3D 'm not sure if framework and the model should be specified.

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

Meeting agenda is chair's decision, but I = thin=3D k that Don will allow you to present it.

> Or if the develo= pmen=3D t of the framework or model is already underway by the WG, we would l= ike =3D to
> contribute to the same. Also, we could adopt the early rel= ease=3D s and can act as a test bed.

Any contributions are welcome! I = hope=3D you actively join the discussion.

> Please let me know if a= pr=3D ivate group is involved in developing these standards? And if so,
= >=3D how can I join that group? How does the working group operate in deve= lop=3D ing these drafts?
> Please advise.

Send the trade mailin= g li=3D st what you are thinking. Do not hesitate to do so.

Regards,Ko

P.S. My I ask your company? Just curious.

=

Get your FREE d= ownloa=3D d of MSN Explorer at http://exp= lorer.=3D msn.com
------=3D_NextPart_001_0002_01C06B36.9E1312B0-- ---------------------------------------------------------------------= --- Your message was received by ietf-trade-request@lists.elistx.com. 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: ietf-trade-help@lists.elistx.com 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 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 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 abuse@elistx.com 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". ---------------------------------------------------------------------= ---
Get your FREE download of MSN Explorer at http://explorer.msn.com
--Boundary_(ID_PZn1pZ/mqfIbiZ2x4nn4ow) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE
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.

Going forward, do we plan to use the mail= ing 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 ;-) ).

R= aghu.

----- Original Message -----
From: Ko Fujimura
Sen= t: Thursday, December 21, 2000 6:58 AM
To: Raghuram Rajah
Cc: D= onald E. Eastlake 3rd; fujimura@isl.ntt.co.jp
Subject: Re: FW: Dra= ft minutes of trade IETF San Diego

Hi Raghu,

> H= i Ko / Walter / Donald / all,

I think that your mail is intend= ed to sent the mailing list but sent only to me.
Anyway, I would l= ike to answer it.

> I have been a part of this group for ov= er a month now and haven't seen any discussion on the rights req= uirements or the RTS in general. Didn't find a whole lot in the archi= ves either.
> Is there a private group working on these require= ments and the RTS framework?

There was. But, about one year ag= o I closed it, since it is not active. So, any discussion
should b= e 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 requirements.

> 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
ted computing power. We have made some progress in address= ing these requirements and have come up with a generic framework= . Though the framework and the model needs more work, I guess we are = headed in the right direction.

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.

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

Meeting agen= da is chair's decision, but I think that Don will allow you to presen= t 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 adopt the early releases and can=3D
act as a test b= ed.

Any contributions are welcome! I hope you actively join th= e discussion.

> 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?=
> Please advise.

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

Regards,

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

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

<HTML><BODY ST= YLE=3D3D"font:10pt verdana; border:none;"><DIV>Yes, I did in= t=3D
end to send it to the group and I thought I did too. I am sur= prised it wa=3D
s sent only to you. Sorry about the confusion. Tha= nks for getting me upto=3D
speed. </DIV> <DIV>&nbs= p;</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> </DIV> <DIV>Will sen= d a write-up on the thoughts that we had =3D
developed for represe= nting 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> </DIV> <DIV>Raghu.&l= t;BR></DIV> <BLOCKQUOTE style=3D3D"BO=3D
RDER-LEFT: #0= 00000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDIN=3D
G-= LEFT: 5px; PADDING-RIGHT: 0px"> <DIV style=3D3D"FONT: 10pt Aria= l">----- O=3D
riginal Message -----</DIV> <DIV style= =3D3D"BACKGROUND: #e4e4e4; FONT: 10pt=3D
Arial; FONT-COLOR: black"= ><B>From:</B> Ko Fujimura</DIV> <DIV= style=3D
=3D3D"FONT: 10pt Arial"><B>Sent:</B>&= nbsp;Thursday, December 21, 2000 6:58 =3D
AM</DIV> <DIV s= tyle=3D3D"FONT: 10pt Arial"><B>To:</B> Raghur= am Rajah</=3D
DIV> <DIV style=3D3D"FONT: 10pt Arial">&= lt;B>Cc:</B> Donald E. Eastlake 3=3D
rd; fujimur= a@isl.ntt.co.jp</DIV> <DIV style=3D3D"FONT: 10pt Arial">&= lt;B>Subje=3D
ct:</B> Re: FW: Draft minutes of t= rade IETF San Diego</DIV> <DIV><BR=3D
></DIV&= gt;Hi Raghu,<BR><BR>> Hi Ko / Walter / Donald / al= l,<BR><BR>I thin=3D
k that your mail is intended to se= nt the mailing list but sent only to me=3D
.<BR>Anyway, I wo= uld like to answer it.<BR><BR>> I have been a part= of=3D
this group for over a month now and haven't seen any discus= sion on the<B=3D
R>> rights requirements or the RTS i= n general. Didn't find a whole lot=3D
in the archives either.<B= R>> Is there a private group working on thes=3D
e requir= ements and the RTS framework?<BR><BR>There was. But, abou= t one ye=3D
ar ago I closed it, since it is not active. So, any di= scussion<BR>should =3D
be done the trade mailing list or fac= e-to-face meeting now. We haven't ac=3D
tively<BR>discussed = using the mailing list. But, we had 5 face-to-face me=3D
eting sin= ce the 45th IETF Oslo<BR>meeting. I think it enough for discuss= i=3D
ng requirements.<BR><BR>> The reason I ask= is, I have been leading a d=3D
evelopment of a similar system and= have been battling<BR>> the very sa=3D
me requiremen= ts in the context of embedded devices with limited computing=3D
po= wer.<BR>> We have made some progress in addressing these= requiremen=3D
ts and have come up with a generic<BR>&gt= ; framework. Though the framewor=3D
k and the model needs more wor= k, I guess we are headed in the right<BR>&g=3D
t; direct= ion.<BR><BR>Thank you. But, I think the next work item is= to dev=3D
elop draft for Rights Component, i.e., XML<BR>rep= resentation of rights. I=3D
'm not sure if framework and the model= should be specified.<BR><BR>> W=3D
e would wan= t to present our model, for review by the WG to develop the RT=3D
= S I-D, potentially.<BR><BR>Meeting agenda is chair's deci= sion, but I thin=3D
k that Don will allow you to present it.<BR= ><BR>> Or if the developmen=3D
t of the framework = or model is already underway by the WG, we would like =3D
to<BR= >> contribute to the same. Also, we could adopt the early r= elease=3D
s and can act as a test bed.<BR><BR>Any cont= ributions are welcome! I hope=3D
you actively join the discussion.= <BR><BR>> Please let me know if a pr=3D
ivate g= roup is involved in developing these standards? And if so,<BR>&= amp;gt;=3D
how can I join that group? How does the working group o= perate in develop=3D
ing these drafts?<BR>> Please ad= vise.<BR><BR>Send the trade mailing li=3D
st what you = are thinking. Do not hesitate to do so.<BR><BR>Regards,&l= t;BR><B=3D
R>Ko<BR><BR>P.S. My I ask your com= pany? Just curious.<BR> <DIV></DIV></BL=3D
OC= KQUOTE></BODY></HTML><DIV><BR><br clear= =3D3Dall><hr>Get your FREE downloa=3D
d of MSN Explorer a= t <a href=3D3D"http://explorer.msn.com">http://explorer.=3D
= msn.com</a><br></p></DIV>

------=3D_Ne= xtPart_001_0002_01C06B36.9E1312B0--
------------------------------= ------------------------------------------
Your message was receiv= ed by ietf-trade-request@lists.elistx.com.
We are an automatic eli= st command server. This is a help summary.

If you need t= o contact a person, the elist service manager may be
reached by se= nding an email message to:

ietf-trade-help@lists.elistx= .com

We receive messages and expect the content to be lines wi= th commands.
You may send more than one command per message but ea= ch command must
appear completely on a line by itself. If a = line ends with a backslash
"\" we will add the next line to it bef= ore processing it. Commands in
the Subject: header are ignor= ed.

There are subscriber commands and elist owner commands.&nb= sp; The subscriber
commands are described first. A brief exp= lanation of all commands is
included here. A more detailed e= xplanation is available at:

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

SUBSCRIBER COMMANDS

The following co= mmands may be sent by anyone to the command server. The
comm= and will be processed according to how the elist is configured. = You
will always get a reply telling you if a command was processe= d and what
was done.

subscribe
unsubscribe=
confirm
who
help

SUBSCRIBE
<= BR> The word "subscribe" should appear on a line by itself in t= he body of
the message. By default the address that w= ill be subscribed is
selected from the first of the followi= ng header fields with a value:
REPLY-TO, FROM, SENDER.
<= BR> To subscribe an alternate address, or the address of a thir= d party,
include it on the line after "subscribe". An= y valid email address may
be specified, e.g.:

=    subscribe Raghuram Rajah <rraghuram@hotmail.com>
UNSUBSCRIBE

The word "unsubscribe" should appear = on a line by itself in the body
of the message. By de= fault the address that will be unsubscribed is
selected fro= m the first of the following header fields with a value:
RE= PLY-TO, FROM, SENDER.

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

    unsubscribe Raghuram Rajah= <rraghuram@hotmail.com>

CONFIRM

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

In all cases, the command serve= r 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 whether
o= r not it was processed.

If the command was processed a = separate message will be sent with the
results of the comma= nd, e.g., in the case of a subscribe command the
subscriber= will be sent a welcome message and in the case of an
unsub= scribe 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 i= t a copy of the list of
subscribers will be returned to you= . If it is not permitted you will
receive an acknowle= dgement 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 no= t created by users. They are created by
the command server a= nd sent to elist owners when an unauthorized message
is received f= or distribution. Although there are many reasons why a
messa= ge submitted to an elist is considered unauthorized, it is always adirect result of how an elist is configured.

The commands ar= e as follows:

delete
distribute
rej= ect
spam

DELETE

This command is used t= o end all processing of a message. The message
will b= e removed from the email queue, it will not be returned to its
&nb= sp; sender, and it will not be distributed to your elist. See a= lso 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 that
are unique to the message b= eing processed. The values will have been
provided to= you by the elist command server. You must supply both the
&= nbsp; command "delete" and the confirmation "yes".

DISTRIBUTE<= BR>
This command is used to distribute the message to your = elist. If the
elist is archived a copy will be put th= ere also.

A representative use of this command is:
<= BR>      distribute yes TOKEN IDENTIFIER
=
Note that TOKEN and IDENTIFIER must be replaced by actual = values that
are unique to the message being processed. = ; The values will have been
provided to you by the elist co= mmand server. You must supply both the
command "distr= ibute" and the confirmation "yes".

REJECT

This c= ommand is used to reject the distribution of the message and to
&n= bsp; send a message to its sender indicating the message was not auth= orized
for distribution. The message will be removed = =66rom the email queue,
it will be returned to its sender, = and it will not be distributed to
your elist. See als= o the command "delete".

A representative use of this co= mmand is:

      reject yes TOKEN IDEN= TIFIER

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

SPAM

Th= is command is used to tell us that you consider the message spam and<= BR> you want us to treat it as such. The message 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.&nbs= p; In addition, the message will be forwarded
to abuse@elis= tx.com for processing.

A representative use of this com= mand is:

      spam yes TOKEN IDENTIF= IER

Note that TOKEN and IDENTIFIER must be replaced by = actual values that
are unique to the message being processe= d. The values will have been
provided to you by the e= list command server. You must supply both the
command= "spam" and the confirmation "yes".
------------------------------= ------------------------------------------

Get your FREE download of MSN E= xplorer at http://explorer.msn.co= m
--Boundary_(ID_PZn1pZ/mqfIbiZ2x4nn4ow)-- Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5W004013TDC2@eListX.com>; Wed, 20 Dec 2000 18:27:13 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5W004013TCC1@eListX.com>; Wed, 20 Dec 2000 18:27:12 -0500 (EST) Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5W004043TCBX@eListX.com> (original mail from dee3@torque.pothole.com) ; Wed, 20 Dec 2000 18:27:12 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5W004013TBBV@eListX.com> for ietf-trade@elist.lists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Wed, 20 Dec 2000 18:27:11 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5W004013TBBU@eListX.com> for ietf-trade@elist.lists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Wed, 20 Dec 2000 18:27:11 -0500 (EST) Received: from torque.pothole.com ([38.138.52.132]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G5W000E83T9NJ@eListX.com> for ietf-trade@lists.elistx.com; Wed, 20 Dec 2000 18:27:11 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id SAA31326 for ietf-trade@lists.elistx.com; Wed, 20 Dec 2000 18:31:34 -0500 (EST) Date: Wed, 20 Dec 2000 18:31:34 -0500 From: "Donald E. Eastlake 3rd" Subject: Slides from TRADE WG meeting in SanDiego To: ietf-trade@lists.elistx.com Message-id: <200012202331.SAA31326@torque.pothole.com> Content-type: TEXT/PLAIN X-Authentication-warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , X-MTS: smtp The Slides form the TRADE WG meeting in San Diego are available in power point form from Sorry for the delay in making these available. Donald ===================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1 508-634-2066(h) Milford, MA 01757 USA +1 508-261-5434(w) Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5V00C017BFZ8@eListX.com>; Wed, 20 Dec 2000 06:45:15 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5V00C017BEZ6@eListX.com>; Wed, 20 Dec 2000 06:45:15 -0500 (EST) Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5V00C047BEZ3@eListX.com> (original mail from fujimura@isl.ntt.co.jp) ; Wed, 20 Dec 2000 06:45:14 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5V00C017BDZ1@eListX.com> for ietf-trade@elist.lists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Wed, 20 Dec 2000 06:45:13 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5V00C017BDZ0@eListX.com> for ietf-trade@elist.lists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Wed, 20 Dec 2000 06:45:13 -0500 (EST) Received: from tama3.tas.ntt.co.jp (tama3.tas.ntt.co.jp [192.68.248.40]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G5V00BA17BBJE@eListX.com> for ietf-trade@lists.elistx.com; Wed, 20 Dec 2000 06:45:13 -0500 (EST) Received: from nttmail.ecl.ntt.co.jp (nttmail.tas.ntt.co.jp [192.68.248.11]) by tama3.tas.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id UAA15119 for ; Wed, 20 Dec 2000 20:44:32 +0900 (JST envelope-from fujimura@isl.ntt.co.jp) Received: from alsace.isl.ntt.co.jp by nttmail.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/10/05/00) with ESMTP id UAA27336 for ; Wed, 20 Dec 2000 20:44:31 +0900 (JST envelope-from fujimura@isl.ntt.co.jp) Received: from isl.ntt.co.jp (degas.isl.ntt.co.jp [129.60.104.56]) by alsace.isl.ntt.co.jp (8.8.8/3.7W) with ESMTP id UAA04225; Wed, 20 Dec 2000 20:44:30 +0900 (JST) Date: Wed, 20 Dec 2000 20:48:37 +0900 From: Ko Fujimura Subject: Re: FW: Draft minutes of trade IETF San Diego To: ietf-trade@lists.elistx.com Cc: fujimura@isl.ntt.co.jp Message-id: <3A409C95.F1746D9B@isl.ntt.co.jp> MIME-version: 1.0 X-Mailer: Mozilla 4.75 [ja] (Win98; U) Content-type: text/plain Content-transfer-encoding: 7BIT X-Accept-Language: ja References: <51228FAD179FD4118A8600D0B76FE2621881A2@ma07exm01.corp.isg.mot.com> List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , 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 dee3@torque.pothole.com > Minutes: Walter Houser houser.walt@forum.va.gov ... > 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 Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5K00501LGYAU@eListX.com>; Thu, 14 Dec 2000 13:17:22 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5K00501LGYAS@eListX.com>; Thu, 14 Dec 2000 13:17:22 -0500 (EST) Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5K00504LGXAP@eListX.com> (original mail from Donald.Eastlake@motorola.com); Thu, 14 Dec 2000 13:17:21 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5K00501LGXAN@eListX.com> for ietf-trade@elist.lists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Thu, 14 Dec 2000 13:17:21 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G5K00501LGWAM@eListX.com> for ietf-trade@elist.lists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Thu, 14 Dec 2000 13:17:20 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G5K0025TLGWW3@eListX.com> for ietf-trade@lists.elistx.com; Thu, 14 Dec 2000 13:17:20 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id LAA19445 for ; Thu, 14 Dec 2000 11:16:45 -0700 (MST) Received: [from ma07exm01.corp.isg.mot.com (ma07exm01.corp.isg.mot.com [134.33.90.80]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id LAA24797 for ; Thu, 14 Dec 2000 11:16:44 -0700 (MST) Received: by ma07exm01.corp.isg.mot.com with Internet Mail Service (5.5.2651.58) id ; Thu, 14 Dec 2000 13:16:43 -0500 Content-return: allowed Date: Thu, 14 Dec 2000 13:16:42 -0500 From: Eastlake III Donald-LDE008 Subject: FW: Draft minutes of trade IETF San Diego To: "'ietf-trade@lists.elistx.com'" Message-id: <51228FAD179FD4118A8600D0B76FE2621881A2@ma07exm01.corp.isg.mot.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , Minutes of the Internet Open Trading Protocol Working Group (trade) Wednesday, December 13 at 1300-1500 ===================================== CHAIR: Donald Eastlake 3rd dee3@torque.pothole.com Minutes: Walter Houser houser.walt@forum.va.gov 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. Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4W00101KJR7H@eListX.com>; Fri, 01 Dec 2000 13:55:04 -0500 (EST) Received: from ELISTS-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4W00103KJP76@eListX.com> (original mail from dee3@torque.pothole.com) ; Fri, 01 Dec 2000 13:55:01 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4W00101KJH73@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Fri, 01 Dec 2000 13:54:54 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4W00101KJE72@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Fri, 01 Dec 2000 13:54:52 -0500 (EST) Received: from torque.pothole.com ([38.138.52.132]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G4W00MIUKJAAV@eListX.com> for ietf-trade@lists.elistx.com; Fri, 01 Dec 2000 13:54:48 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id NAA07043; Fri, 01 Dec 2000 13:58:51 -0500 (EST) Date: Fri, 01 Dec 2000 13:58:51 -0500 From: "Donald E. Eastlake 3rd" Subject: Draft TRADE WG San Diego Meeting Agenda To: ietf-trade@lists.elistx.com Cc: lde008@dma.isg.mot.com Message-id: <200012011858.NAA07043@torque.pothole.com> Content-type: TEXT/PLAIN X-Authentication-warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , X-MTS: smtp 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 dee3@torque.pothole.com 155 Beaver Street +1 508-634-2066(h) Milford, MA 01757 USA +1 508-261-5434(w)