Fw: FW: Draft minutes of trade IETF San Diego

Raghuram Rajah <rraghuram@hotmail.com> Thu, 21 December 2000 16:04 UTC

Date: Thu, 21 Dec 2000 11:06:52 -0500
From: Raghuram Rajah <rraghuram@hotmail.com>
Subject: Fw: FW: Draft minutes of trade IETF San Diego
To: ietf-trade@lists.elistx.com
Message-id: <OE68Qsp7JVrk31riBEc00001cfd@hotmail.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_PZn1pZ/mqfIbiZ2x4nn4ow)"

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. Thanks for getting me upto speed.  

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 representing 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 -----
From: 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 seen 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 active. 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 requirements.

> 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 context of embedded devices with limi=
ted computing power. We have made some progress in addressing 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 next work item is to develop draft for Rights Component, i.e., XML representation of rights. I'm not sure if framework 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 you 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 adopt the early releases and can=
act as a test bed.

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

> Please let me know if a private group is involved 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 are thinking. Do not hesitate to do so.

Regards,

Ko

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

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

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

------=_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 backslash
"\" we will add the next line to it before processing it.  Commands in
the Subject: header are ignored.

There are subscriber commands and elist owner commands.  The subscriber
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 what
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 <rraghuram@hotmail.com>

UNSUBSCRIBE

  The word "unsubscribe" should appear on a line by itself in the body
  of the message.  By default the address that will be unsubscribed is
  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 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 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 server
  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 whether
  or not it was processed.

  If the command was processed a separate message will be sent with the
  results of the command, e.g., in the case of a subscribe command the
  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 will
  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 message
is received for distribution.  Although there are many reasons why a
message submitted to an elist is considered unauthorized, it is always 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 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.  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 that
  are unique to the message being processed.  The values will have been
  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 the
  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 that
  are unique to the message being processed.  The values will have been
  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 authorized
  for distribution.  The message will be removed from the email queue,
  it will be returned to its sender, and it will not be distributed to
  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 that
  are unique to the message being processed.  The values will have been
  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 forwarded
  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 that
  are unique to the message being processed.  The values will have been
  provided to you by the elist command server.  You must supply both the
  command "spam" and the confirmation "yes".
------------------------------------------------------------------------<br clear=all><hr>Get your FREE download of MSN Explorer at <a href="http://explorer.msn.com">http://explorer.msn.com</a><br></p>

Fw: FW: Draft minutes of trade IETF San Diego Raghuram Rajah
Re: FW: Draft minutes of trade IETF San Diego Ko Fujimura
FW: Draft minutes of trade IETF San Diego Eastlake III Donald-LDE008
Re: FW: Draft minutes of trade IETF San Diego Donald E. Eastlake 3rd
Re: Generic Right Trading (was Fw: FW: Draft minu… Donald E. Eastlake 3rd