Subject: Protocol Action: Internet Open Trading Protocol (IOTP) HTTP Supplement to Proposed Standard
From: The IESG <[email-masked]>
To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>, IANA <[email-masked]>
Date: Fri, 21 Jul 2000 14:30:27 -0400

The IESG has approved the Internet-Draft 'Internet Open Trading
Protocol (IOTP) HTTP Supplement' <draft-ietf-trade-iotp-http-07.txt> as
a Proposed Standard.

In the same action, the IESG approved publication of HTTP MIME Type
Handler Detection <draft-ietf-trade-mime-detector-03.txt> as an
Informational RFC.

These documents are the product of the Internet Open Trading Protocol
Working Group.  The IESG contact persons are Ned Freed and Patrik
Faltstrom.

Technical Summary
 
Internet Open Trading Protocol (IOTP) messages will be carried as XML
documents. As such, the goal of mapping to the transport layer is to
ensure that the underlying XML documents are carried successfully
between the various parties.

The document draft-ietf-trade-iotp-http-07.txt describes that mapping
for the Hyper Text Transport Protocol (HTTP), Versions 1.0 and 1.1
[RFCs 1945, 2616].

The document draft-ietf-trade-mime-detector-03.txt explains common
problems with the use of Accept header in HTTP for serverside discovery
of client capabilities, and describes what can be done (spring 2000)
using Java and other mechanisms to give client as good content as
possible.

Working Group Summary

There was consensus in the working group. The content type
application/iotp has been discussed on the ietf-types mailing list.

Protocol Quality

The documents were reviewed by Patrik Faltstrom.

Date: Wed, 19 Jul 2000 10:56:52 -0400
From: Donald Eastlake 3rd <[email-masked]>
Subject: TRADE WG meeting at Pittsburgh IETF meeting
Sender: [email-masked]
To: [email-masked]
Cc: [email-masked]

The TRADE WG meeting has been scheduled for 1pm (1300) to 3:15pm
(1515) on Tuesday, August 1st, at the Pittsburgh IETF meeting.

Donald
==================================================================
 Donald Eastlake 3rd  +1 978-562-2827(h)  [email-masked]
 140 Forest Avenue     +1 508-261-5434(w)  [email-masked]
 Hudson, MA 01749 USA

Date: Sat, 15 Jul 2000 10:30:50 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: update ECML 1.1 draft
To: [email-masked]
Cc: [email-masked]

The ECML alliance has produced an updated ECML 1.1 draft which is
available at
<ftp://ftp.pothole.com/pub/dee3/draft-eastlake-ecom-fields2-03.txt>.

Donald

=====================================================================
 Donald E. Eastlake 3rd                      [email-masked]
 140 Forest Avenue                                +1 978-562-2827(h)
 Hudson, MA 01749 USA                             +1 508-261-5434(w)

Date: Fri, 14 Jul 2000 20:32:12 -0400 (Eastern Daylight Time)
From: Chris Smith <[email-masked]>
Subject: Re: Two questions to IOTP spec
To: Johannes Lessmann <[email-masked]>
Cc: [email-masked]

On Fri, 14 Jul 2000, Johannes Lessmann wrote:

> I have two questions:
> 
> 1) Imagine a consumer makes an order (step 1 in Offer Doc Exchange).
>    How can a merchant directly tell him that the ordered goods are
>    not available. As far as i see, the merchant would need to
>    send back an Offer Resp Block with Status comp with CompletionCode
>    "PermNotAvail" or "TempNotAvail". But in order to do this, the 
>    StatusType must be "Delivery". Yet we are in an Offer Exchange, so
>    the StatusType has to be "Offer" according to the spec.
>    Where am i wrong?

IOTP is a purchase protocol, and as such, would not normally get invoked
until after 'shopping' is finished. A completely integrated merchant
would control the availability of goods to be placed in a virtual shopping
cart (for example).

When the consumer indicates "checkout", the merchant would already know
that only available items are in the cart and so everything that the
consumer wants is available.

Alternatively, if there is the possibility of unavailable items in the
cart, the merchant has three choices:

a) since the request to 'checkout' is not actually a request of
type application/iotp, the merchant is free to respond with text/html
and specify the goods that are not available. The consumer can then
be given controls to either remove the goods from the cart, accept
them as backordered, or any other option the merchant thinks is
worthwhile.

b) The merchant can proceed to produce an offer of type application/iotp,
and the invoice details can specify that items are included (and to
be paid for) or have been back-ordered, and can be paid for at a later
date.

c) If the merchant is confident that re-supply is coming soon, they can
simply create an offer for all requested goods, accept payment, and
ship goods as they arrive. In this case, the merchant should have some
contingency arrangements in the event that expected shipments do not
arrive.

> 2) As far as i see, the IOTP only deals with communication between
>    a consumer and a non-consumer. Is that true? Would it not be
>    sensefull if the Delivery Request were initiated by the merchant
>    rather than the consumer (step 1 of Delivery Doc Exchange)?
>    How does a merchant get to know that the payment was successfully
>    performed? Or cancelled?

If a merchant wishes, they can assign themselves all the roles of
Merchant, PaymentHandler, and DeliveryHandler. That way, they get
to see all the information you have indicated.

The trading roles are like actors in a play. Any given merchant is
free to set up a "one-man show" and play all the parts himself.

In many cases, though, merchants are already outsourcing their
logistics. In this case, the DeliveryHandler could even be (example!)
FedEx, who can read the DeliveryRequest, check the original OfferResponse
signature from the Merchant and the PaymentResponse signature from the
PaymentHandler, and move the goods from storage into the delivery channel.

In a best case scenario, you could order physical goods at 11:59 PM for
next day 9 AM delivery.

IOTP simply *allows* (but does not force) this capability.

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

Date: Fri, 14 Jul 2000 23:12:25 +1000
From: Renato Iannella <[email-masked]>
Subject: Re: Other name for "digital-right"?
To: Ko Fujimura <[email-masked]>, [email-masked]

--On 13/7/00 10:04 AM +0900 Ko Fujimura wrote:

>> Call it a "voucher", but don't use the word "rights" as this
>> means "intellectual property rights".
>
> Thank you for a good suggestion. But I have another concern; a "voucher"
> might be an appropriate word in USA but it might be misunderstood as a
> "discount coupon" in UK. So, I prefer a word of which meaning is more
> neutral.
>
> In this sense, I would like to stick to "rights". Are there any idea
> like "XXXXX rights" which correspond to "IP rights"?

I think the term "rights" is the potentially more misleading term.
For example, if you compare it to XRML [1].

Cheers...Renato                      <http://purl.net/net/renato>
Chief Scientist, IPR Systems Pty Ltd      <http://iprsystems.com>
...............................unlocking the value of information

[1] http://www.xrml.org/

Date: Fri, 14 Jul 2000 12:16:08 +0200
From: Johannes Lessmann <[email-masked]>
Subject: Two questions to IOTP spec
Sender: [email-masked]
To: [email-masked]

Hi,

i intend to make a test implementation of IOTP.

I have two questions:

1) Imagine a consumer makes an order (step 1 in Offer Doc Exchange).
   How can a merchant directly tell him that the ordered goods are
   not available. As far as i see, the merchant would need to
   send back an Offer Resp Block with Status comp with CompletionCode
   "PermNotAvail" or "TempNotAvail". But in order to do this, the 
   StatusType must be "Delivery". Yet we are in an Offer Exchange, so
   the StatusType has to be "Offer" according to the spec.
   Where am i wrong?

2) As far as i see, the IOTP only deals with communication between
   a consumer and a non-consumer. Is that true? Would it not be
   sensefull if the Delivery Request were initiated by the merchant
   rather than the consumer (step 1 of Delivery Doc Exchange)?
   How does a merchant get to know that the payment was successfully
   performed? Or cancelled?
   
Please excuse me if the quesions were already discussed earlier.

Thanks,

Johannes
C-Lab, Germany

Date: Thu, 13 Jul 2000 00:42:12 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: TRADE meeting in Pittsburgh
To: [email-masked]
Cc: [email-masked]

The first preliminary IETF schedule for the upcoming meeting in
Pittsburg, which may get posted on the IETF web site
<http://www.ietf.org> tonight, had the TRADE WG meeting on Thursday.
However, due to a conflict, I have asked the schedulers to see if they
can move it earlier in the week.

Thanks,
Donald
=====================================================================
 Donald E. Eastlake 3rd                      [email-masked]
 140 Forest Avenue                                +1 978-562-2827(h)
 Hudson, MA 01749 USA                             +1 508-261-5434(w)

Date: Thu, 13 Jul 2000 10:04:58 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: Other name for "digital-right"?
To: [email-masked]

I received a comment:

> > I agreed it, but I'm still wondering how to change it. There are several
> > candidates, e.g., electronic rights, digital instruments, XML-Rights,
> > XML-Ticket, ... but I haven't decided yet. Does anyone give me any idea?
> > Any suggestion is appreciated.
> 
> Call it a "voucher", but don't use the word "rights" as this
> means "intellectual property rights".

Thank you for a good suggestion. But I have another concern; a "voucher"
might be an appropriate word in USA but it might be misunderstood as a
"discount coupon" in UK. So, I prefer a word of which meaning is more
neutral.

In this sense, I would like to stick to "rights". Are there any idea
like "XXXXX rights" which correspond to "IP rights"?

Ko

Date: Tue, 11 Jul 2000 20:53:06 +0900
From: Ko Fujimura <[email-masked]>
Subject: Other name for "digital-right"?
To: [email-masked]

Hi all,

I'm now working on revising draft-ietf-trade-dtr-requirements-00.

Someone pointed out that "digital-right" is confusing with "IP rights"
at the last meeting as described in the meeting note:
http://lists.elistx.com/archives/ietf-trade/200004/msg00000.html

I agreed it, but I'm still wondering how to change it. There are several
candidates, e.g., electronic rights, digital instruments, XML-Rights,
XML-Ticket, ... but I haven't decided yet. Does anyone give me any idea?
Any suggestion is appreciated.

Ko
----------------------------------------------------------
Ko Fujimura, NTT Information Sharing Platform Laboratories
1-1 Hikarinooka, Yokosuka-shi, Kanagawa 239-0847, JAPAN
Tel: +81-(0)468-59-3814, Fax: +81-(0)468-59-2241
Email: [email-masked]

Date: Mon, 10 Jul 2000 16:02:42 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: TRADE WG meeting at IETF in Pittsburgh
To: [email-masked]

Hi,

I'm working on a draft agenda.  Anyone who would like to make any
presentations at the TRADE WG meeting at the IETF Pittsburgh meeting
<http://www.ietf.org//meetings/IETF-48.html> should contact me.

Thanks,
Donald

=====================================================================
 Donald E. Eastlake 3rd                      [email-masked]
 140 Forest Avenue                                +1 978-562-2827(h)
 Hudson, MA 01749 USA                             +1 508-261-5434(w)

Date: Fri, 21 Jul 2000 14:30:27 -0400
From: The IESG <[email-masked]>
Subject: Protocol Action: Internet Open Trading Protocol (IOTP) HTTP	Supplement to Proposed Standard
Sender: [email-masked]
To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>, IANA <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>
Cc: [email-masked]

The IESG has approved the Internet-Draft 'Internet Open Trading
Protocol (IOTP) HTTP Supplement' <draft-ietf-trade-iotp-http-07.txt> as
a Proposed Standard.

In the same action, the IESG approved publication of HTTP MIME Type
Handler Detection <draft-ietf-trade-mime-detector-03.txt> as an
Informational RFC.

These documents are the product of the Internet Open Trading Protocol
Working Group.  The IESG contact persons are Ned Freed and Patrik
Faltstrom.

Technical Summary
 
Internet Open Trading Protocol (IOTP) messages will be carried as XML
documents. As such, the goal of mapping to the transport layer is to
ensure that the underlying XML documents are carried successfully
between the various parties.

The document draft-ietf-trade-iotp-http-07.txt describes that mapping
for the Hyper Text Transport Protocol (HTTP), Versions 1.0 and 1.1
[RFCs 1945, 2616].

The document draft-ietf-trade-mime-detector-03.txt explains common
problems with the use of Accept header in HTTP for serverside discovery
of client capabilities, and describes what can be done (spring 2000)
using Java and other mechanisms to give client as good content as
possible.

Working Group Summary

There was consensus in the working group. The content type
application/iotp has been discussed on the ietf-types mailing list.

Protocol Quality

The documents were reviewed by Patrik Faltstrom.

Date: Wed, 19 Jul 2000 10:56:52 -0400
From: Donald Eastlake 3rd <[email-masked]>
Subject: TRADE WG meeting at Pittsburgh IETF meeting
Sender: [email-masked]
To: [email-masked]
Cc: [email-masked]

The TRADE WG meeting has been scheduled for 1pm (1300) to 3:15pm
(1515) on Tuesday, August 1st, at the Pittsburgh IETF meeting.

Donald
==================================================================
 Donald Eastlake 3rd  +1 978-562-2827(h)  [email-masked]
 140 Forest Avenue     +1 508-261-5434(w)  [email-masked]
 Hudson, MA 01749 USA

Date: Sat, 15 Jul 2000 10:30:50 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: update ECML 1.1 draft
To: [email-masked]
Cc: [email-masked]

The ECML alliance has produced an updated ECML 1.1 draft which is
available at
<ftp://ftp.pothole.com/pub/dee3/draft-eastlake-ecom-fields2-03.txt>.

Donald

=====================================================================
 Donald E. Eastlake 3rd                      [email-masked]
 140 Forest Avenue                                +1 978-562-2827(h)
 Hudson, MA 01749 USA                             +1 508-261-5434(w)

Date: Fri, 14 Jul 2000 20:32:12 -0400 (Eastern Daylight Time)
From: Chris Smith <[email-masked]>
Subject: Re: Two questions to IOTP spec
To: Johannes Lessmann <[email-masked]>
Cc: [email-masked]

On Fri, 14 Jul 2000, Johannes Lessmann wrote:

> I have two questions:
> 
> 1) Imagine a consumer makes an order (step 1 in Offer Doc Exchange).
>    How can a merchant directly tell him that the ordered goods are
>    not available. As far as i see, the merchant would need to
>    send back an Offer Resp Block with Status comp with CompletionCode
>    "PermNotAvail" or "TempNotAvail". But in order to do this, the 
>    StatusType must be "Delivery". Yet we are in an Offer Exchange, so
>    the StatusType has to be "Offer" according to the spec.
>    Where am i wrong?

IOTP is a purchase protocol, and as such, would not normally get invoked
until after 'shopping' is finished. A completely integrated merchant
would control the availability of goods to be placed in a virtual shopping
cart (for example).

When the consumer indicates "checkout", the merchant would already know
that only available items are in the cart and so everything that the
consumer wants is available.

Alternatively, if there is the possibility of unavailable items in the
cart, the merchant has three choices:

a) since the request to 'checkout' is not actually a request of
type application/iotp, the merchant is free to respond with text/html
and specify the goods that are not available. The consumer can then
be given controls to either remove the goods from the cart, accept
them as backordered, or any other option the merchant thinks is
worthwhile.

b) The merchant can proceed to produce an offer of type application/iotp,
and the invoice details can specify that items are included (and to
be paid for) or have been back-ordered, and can be paid for at a later
date.

c) If the merchant is confident that re-supply is coming soon, they can
simply create an offer for all requested goods, accept payment, and
ship goods as they arrive. In this case, the merchant should have some
contingency arrangements in the event that expected shipments do not
arrive.

> 2) As far as i see, the IOTP only deals with communication between
>    a consumer and a non-consumer. Is that true? Would it not be
>    sensefull if the Delivery Request were initiated by the merchant
>    rather than the consumer (step 1 of Delivery Doc Exchange)?
>    How does a merchant get to know that the payment was successfully
>    performed? Or cancelled?

If a merchant wishes, they can assign themselves all the roles of
Merchant, PaymentHandler, and DeliveryHandler. That way, they get
to see all the information you have indicated.

The trading roles are like actors in a play. Any given merchant is
free to set up a "one-man show" and play all the parts himself.

In many cases, though, merchants are already outsourcing their
logistics. In this case, the DeliveryHandler could even be (example!)
FedEx, who can read the DeliveryRequest, check the original OfferResponse
signature from the Merchant and the PaymentResponse signature from the
PaymentHandler, and move the goods from storage into the delivery channel.

In a best case scenario, you could order physical goods at 11:59 PM for
next day 9 AM delivery.

IOTP simply *allows* (but does not force) this capability.

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

Date: Fri, 14 Jul 2000 23:12:25 +1000
From: Renato Iannella <[email-masked]>
Subject: Re: Other name for "digital-right"?
To: Ko Fujimura <[email-masked]>, [email-masked]

--On 13/7/00 10:04 AM +0900 Ko Fujimura wrote:

>> Call it a "voucher", but don't use the word "rights" as this
>> means "intellectual property rights".
>
> Thank you for a good suggestion. But I have another concern; a "voucher"
> might be an appropriate word in USA but it might be misunderstood as a
> "discount coupon" in UK. So, I prefer a word of which meaning is more
> neutral.
>
> In this sense, I would like to stick to "rights". Are there any idea
> like "XXXXX rights" which correspond to "IP rights"?

I think the term "rights" is the potentially more misleading term.
For example, if you compare it to XRML [1].

Cheers...Renato                      <http://purl.net/net/renato>
Chief Scientist, IPR Systems Pty Ltd      <http://iprsystems.com>
...............................unlocking the value of information

[1] http://www.xrml.org/

Date: Fri, 14 Jul 2000 12:16:08 +0200
From: Johannes Lessmann <[email-masked]>
Subject: Two questions to IOTP spec
Sender: [email-masked]
To: [email-masked]

Hi,

i intend to make a test implementation of IOTP.

I have two questions:

1) Imagine a consumer makes an order (step 1 in Offer Doc Exchange).
   How can a merchant directly tell him that the ordered goods are
   not available. As far as i see, the merchant would need to
   send back an Offer Resp Block with Status comp with CompletionCode
   "PermNotAvail" or "TempNotAvail". But in order to do this, the 
   StatusType must be "Delivery". Yet we are in an Offer Exchange, so
   the StatusType has to be "Offer" according to the spec.
   Where am i wrong?

2) As far as i see, the IOTP only deals with communication between
   a consumer and a non-consumer. Is that true? Would it not be
   sensefull if the Delivery Request were initiated by the merchant
   rather than the consumer (step 1 of Delivery Doc Exchange)?
   How does a merchant get to know that the payment was successfully
   performed? Or cancelled?
   
Please excuse me if the quesions were already discussed earlier.

Thanks,

Johannes
C-Lab, Germany

Date: Thu, 13 Jul 2000 00:42:12 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: TRADE meeting in Pittsburgh
To: [email-masked]
Cc: [email-masked]

The first preliminary IETF schedule for the upcoming meeting in
Pittsburg, which may get posted on the IETF web site
<http://www.ietf.org> tonight, had the TRADE WG meeting on Thursday.
However, due to a conflict, I have asked the schedulers to see if they
can move it earlier in the week.

Thanks,
Donald
=====================================================================
 Donald E. Eastlake 3rd                      [email-masked]
 140 Forest Avenue                                +1 978-562-2827(h)
 Hudson, MA 01749 USA                             +1 508-261-5434(w)

Date: Thu, 13 Jul 2000 10:04:58 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: Other name for "digital-right"?
To: [email-masked]

I received a comment:

> > I agreed it, but I'm still wondering how to change it. There are several
> > candidates, e.g., electronic rights, digital instruments, XML-Rights,
> > XML-Ticket, ... but I haven't decided yet. Does anyone give me any idea?
> > Any suggestion is appreciated.
> 
> Call it a "voucher", but don't use the word "rights" as this
> means "intellectual property rights".

Thank you for a good suggestion. But I have another concern; a "voucher"
might be an appropriate word in USA but it might be misunderstood as a
"discount coupon" in UK. So, I prefer a word of which meaning is more
neutral.

In this sense, I would like to stick to "rights". Are there any idea
like "XXXXX rights" which correspond to "IP rights"?

Ko

Date: Tue, 11 Jul 2000 20:53:06 +0900
From: Ko Fujimura <[email-masked]>
Subject: Other name for "digital-right"?
To: [email-masked]

Hi all,

I'm now working on revising draft-ietf-trade-dtr-requirements-00.

Someone pointed out that "digital-right" is confusing with "IP rights"
at the last meeting as described in the meeting note:
http://lists.elistx.com/archives/ietf-trade/200004/msg00000.html

I agreed it, but I'm still wondering how to change it. There are several
candidates, e.g., electronic rights, digital instruments, XML-Rights,
XML-Ticket, ... but I haven't decided yet. Does anyone give me any idea?
Any suggestion is appreciated.

Ko
----------------------------------------------------------
Ko Fujimura, NTT Information Sharing Platform Laboratories
1-1 Hikarinooka, Yokosuka-shi, Kanagawa 239-0847, JAPAN
Tel: +81-(0)468-59-3814, Fax: +81-(0)468-59-2241
Email: [email-masked]

Date: Mon, 10 Jul 2000 16:02:42 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: TRADE WG meeting at IETF in Pittsburgh
To: [email-masked]

Hi,

I'm working on a draft agenda.  Anyone who would like to make any
presentations at the TRADE WG meeting at the IETF Pittsburgh meeting
<http://www.ietf.org//meetings/IETF-48.html> should contact me.

Thanks,
Donald

=====================================================================
 Donald E. Eastlake 3rd                      [email-masked]
 140 Forest Avenue                                +1 978-562-2827(h)
 Hudson, MA 01749 USA                             +1 508-261-5434(w)