Subject: Re: Document changes Oct 99 - March 2000
From: "Donald E. Eastlake 3rd" <[email-masked]>
To: Russell Perry <[email-masked]>
Cc: [email-masked]
Date: Thu, 30 Mar 2000 06:28:07 -0500

The draft-ietf-trade-iotp-v1.0-protocol-07.txt draft is the final draft for
the V1.0 of IOTP and will be out as an RFC soon.  The -papi- draft is
a little out of date but is expected to be updated within a month.  After
than happens, the SET Supplement will be updated.

Donald

From:  Russell Perry <[email-masked]>
Date:  Wed, 29 Mar 2000 09:11:59 +0100
To:  [email-masked]
Message-id:  <[email-masked]>

>Hi,
>
>I'm looking for some help to clarify some of the apparent discrepancies
>between the following documents:
>draft-ietf-trade-iotp-v1.0-protocol-07.txt (Oct '99) and
>draft-ietf-trade-iotp-v1.0-papi-00.txt (March 2000).  For example,
>several element tags are not specified in the latter document.  Is this
>because both documents should be read together, or does it reflect the
>evolution of the protocol?  
>
>Also, am I right in assuming that the running footer of "*papi-00.txt"
>(SET supplement...) is a typo, or is there a more sinister explanation
>:)  Thanks.
>
>
>Regards,
>
>Russ.

Date: Thu, 30 Mar 2000 06:22:37 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Re: IOTP meeting in 47th IETF
To: Chun OUYANG <[email-masked]>
Cc: [email-masked]

Thanks for your note.  The draft of the official minutes will be
posted shortly.

Actually, it's the IOTP HTTP Supplement and the MIME Handler Detector
drafts that I plan to working group Last Call soon, after one more
revision.  It the working group is satisfied, they would then be
forwarded to the IESG.  It will be a while before IOTP v2.0.

B2BXML was a BoF also held at this IETF meeting.

Donald

From:  Chun OUYANG <[email-masked]>
Date:  Thu, 30 Mar 2000 19:00:24 +0930
Sender:  [email-masked]
To:  [email-masked]
Message-id:  <[email-masked]>
Organization:  ITR

>FYI,
>
>...
>
>PS: 1. IOTP transport and IOTP v2.0 will be submit to IESG soon.
>       2. xml dsig and b2b xml were also discussed in this IETF meeting.
>
>Thanks,
>
>Chun
>

Date: Thu, 30 Mar 2000 19:00:24 +0930
From: Chun OUYANG <[email-masked]>
Subject: IOTP meeting in 47th IETF
Sender: [email-masked]
To: [email-masked]
Organization: ITR

FYI,

Trade WG held its meeting in 47th IETF
(http://www.ietf.org/meetings/IETF-47.html) yesterday afternoon. IOTP
and its related protocols have been discussed.  The Chair, Sir Donald
Eastlake, organized the meeting and gave an overview of IOTPs, the
history and future. An presentation on DRT was given by Mr. Ko Fujimura
from NTT.

Here is both the good news and bad news for IOTP. The good news is it
will soon become an informational RFC; the bad news is, then it will be
the longest RFC document in IETF, according to Patrik, one of the ADs in
Applications Area.

Could I said boldly that as there isnt any standardized interoperable
framework for EC on Internet except IOTP, I do hope that it can be a
robust architecure for EC with world-wide popularity in the future.

Thanks a lot to Yoshiaki and Andrew from Hitachi for the very nice talk
with them on IOTP. Hopefully to have more discussion with the people
interested in IOTP, EC or related issues in the future. Furthermore, it
couldnt be better if some gurus can give their advice to me, in my
future work on IOTP.

PS: 1. IOTP transport and IOTP v2.0 will be submit to IESG soon.
       2. xml dsig and b2b xml were also discussed in this IETF meeting.

Thanks,

Chun

Date: Wed, 29 Mar 2000 09:11:59 +0100
From: Russell Perry <[email-masked]>
Subject: Document changes Oct 99 - March 2000
To: [email-masked]

Hi,

I'm looking for some help to clarify some of the apparent discrepancies
between the following documents:
draft-ietf-trade-iotp-v1.0-protocol-07.txt (Oct '99) and
draft-ietf-trade-iotp-v1.0-papi-00.txt (March 2000).  For example,
several element tags are not specified in the latter document.  Is this
because both documents should be read together, or does it reflect the
evolution of the protocol?  

Also, am I right in assuming that the running footer of "*papi-00.txt"
(SET supplement...) is a typo, or is there a more sinister explanation
:)  Thanks.

Regards,

Russ.

Content-return: allowed
Date: Tue, 28 Mar 2000 17:02:30 -0800
From: David Burdett <[email-masked]>
Subject: RE: Some questions on "draft-ietf-trade-xmlmsg-requirements-00.tx	t"
To: 'Shinji Kikuchi' <[email-masked]>, [email-masked]

Comments inline marked with ## ...

David

-----Original Message-----
From: Shinji Kikuchi [mailto:[email-masked]]
Sent: Thursday, March 23, 2000 3:33 AM
To: [email-masked]
Subject: Some questions on "draft-ietf-trade-xmlmsg-requirements-00.txt"

Dear Sirs

  I'm just a new commer to this mailing list. Actually, I have several
questions on the document of 

 "draft-ietf-trade-xmlmsg-requirements-00.txt" .

Could anyone let me know the right ideas to below items, please ?

1)First, according to the description in the document,  around
   "2.2.4 Document Choreography", we MUST(?) set some descriptions
   regarding controling sequence or selection,  inside of Messages, 
   in particular, in the case of "Explicit".

    The most suitable part for it or associated with it inside messages
   seems to be "Message Routing Information" part , I guess.

   However, according to the description around
  "2.1.7 Message Routing Information",  I feel a little bits difference 
  due to below . By the only description with " Each 'hop' results in 
  another entry.." seems to result in eventually "Peer to Peer" in 
  each interaction  in "Hub" way.

    Therefore, still hard to get idea regarding relationship between
   Routing matter and Document Choreography clearly,  unfortunetely.
   If there were more details of it, it would be more clear, I think.

   Anyway, is it right idea, or misunderstanding absolutely ?
##In my view, choreography, is one of the hardest areas to do. Also by using
implicit choreography, then typcially these days the choreography is hard
coded into the applications that send/receive the messages.##

2)Next, please suggest the future plan or current status regarding other
   parts of this series. According to this specification document,  Other
   7 parts have been planned.   Actually, I am interesting in Secure
   Messaging Part  [XMLMSG-SM].  I am minding that status, now.
   So,  please let me know it, if possible.
##Much of the work on XML messaging is currently being done within the
auspices of ebXML. See http://www.ebxml.org/project_teams/transport.htm for
more details.##

Thanks, S.Kikuchi.

Regards
----------------------------------------------------------
Shinji Kikuchi @ NEC Corp.
Client-Server Software Labs. Development Environment Lab.
Tel:+81-3-5476-1085(JPN), Fax:+81-3-5476-1084(JPN)

Resent-date: Thu, 23 Mar 2000 07:33:00 -0500 (EST)
Date: Thu, 23 Mar 2000 20:33:03 +0900
From: Shinji Kikuchi <[email-masked]>
Subject: Some questions on "draft-ietf-trade-xmlmsg-requirements-00.txt"
Sender: [email-masked]
To: [email-masked]
Resent-message-id: <[email-masked]>

Dear Sirs

  I'm just a new commer to this mailing list. Actually, I have several
questions on the document of 

 "draft-ietf-trade-xmlmsg-requirements-00.txt" .

Could anyone let me know the right ideas to below items, please ?

1)First, according to the description in the document,  around
   "2.2.4 Document Choreography", we MUST(?) set some descriptions
   regarding controling sequence or selection,  inside of Messages, 
   in particular, in the case of "Explicit".

    The most suitable part for it or associated with it inside messages
   seems to be "Message Routing Information" part , I guess.

   However, according to the description around
  "2.1.7 Message Routing Information",  I feel a little bits difference 
  due to below . By the only description with " Each 'hop' results in 
  another entry.." seems to result in eventually "Peer to Peer" in 
  each interaction  in "Hub" way.

    Therefore, still hard to get idea regarding relationship between
   Routing matter and Document Choreography clearly,  unfortunetely.
   If there were more details of it, it would be more clear, I think.

   Anyway, is it right idea, or misunderstanding absolutely ?

2)Next, please suggest the future plan or current status regarding other
   parts of this series. According to this specification document,  Other
   7 parts have been planned.   Actually, I am interesting in Secure
   Messaging Part  [XMLMSG-SM].  I am minding that status, now.
   So,  please let me know it, if possible.

Thanks, S.Kikuchi.

Regards
----------------------------------------------------------
Shinji Kikuchi @ NEC Corp.
Client-Server Software Labs. Development Environment Lab.
Tel:+81-3-5476-1085(JPN), Fax:+81-3-5476-1084(JPN)

Date: Tue, 21 Mar 2000 13:55:04 -0500
From: "Smith, Chris " <[email-masked]>
Subject: RE: Yet more on APPLICATION/IOTP
To: "'Donald E. Eastlake 3rd'" <[email-masked]>, [email-masked]

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

--Boundary_(ID_Y8q/uz8A+m6FwW7R+qgpHg)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

Call me conservative on this one - since there was not yet a formal
decision on the matter, we have continued to use APPLICATION/X-IOTP
even for IOTP 1.0 (which also is not returned from the editor's desk
with an RFC number).

I realize that I should probably join the ietf-types mailing list
to find this out, but ... is there any ideas on an alternate way
besides modifying the actual MIME type to indicate that XML is in
use?

If there were, I would prefer...

   APPLICATION/IOTP
   ...with a charset parameter
   ...with an encoding or markup parameter

The other alternative - a really big one, at that - would be
to use:

   XML/IOTP
   ...with a charset parameter

..to my mind, this better captures the actual idea of what is
happening here. This is much the same as using IMAGE/ or TEXT/
where the /xxx "sub-describes" the higher level item.

------------------------------------------------------------=20
=A0Chris =
Smith=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 +1.416.348.6090=20
=A0Royal =
Bank=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
[email-masked]=20

  =20

> -----Original Message-----
> From: Donald E. Eastlake 3rd [mailto:[email-masked]]
> Sent: March 21, 2000 09:34 AM
> To: [email-masked]
> Subject: Yet more on APPLICATION/IOTP
>=20
>=20
>=20
> There continues to be an incredible blizzard of messages on the
> ietf-types mailing list about whether "-xml" suffixes or the like on
> MIME types is good or bad, etc.  In general, the weight of the
> argument seems to be in favor of this...  So the question is would
> changing to application/iotp-xml be a hardship on current
> implementations and implementation efforts?  (Early efforts used
> APPLICATION/X-IOTP.)
>=20
> Also, it turns out that Section F of the XML spec has been changed.
> External charset indications, such as an optional charset =
Content-Type
> parameter, if present, over-ride and internal indication of character
> encoding in XML, as specified in Informational RFC 2376.  So if there
> is an optional charset option, which is probably a good idea, then
> when present, it should over-riode any encoding specification
> appearing before the XML document unless we wnat to be =
non-standard...
>=20
> Donald
>=20
>=20
> ------- Forwarded Message
>=20
> Date:  Thu, 09 Mar 2000 23:49:47 -0500
> From:  "Donald E. Eastlake 3rd" <[email-masked]>
> Subject:  More on APPLICATION/IOTP
> To:  [email-masked]
> Message-id:  <[email-masked]>
>=20
> The MIME type registartion template I posted to the ietf-types list
> has caused a lot of comment.  None of it is really about IOTP, it
> is all about two issues:
> (1) should it really be APPLICATION/IOTP-XML
> and
> (2) should it allow/require a charset parameter
>=20
> That is, people are arguing about whether all new XML content MIME
> types should have a subtype with a "-xml" on the end.  I would
> assume we don't want to change due to existing implementations.
>=20
> On the charset paramter issue, I think I should add it as an
> optional parameter.  Section F of the XML 1.0 specification makes
> it clear that the charset as indicated by the actual data
> including any byte order mark and encoding declaration and that
> any "external" charset, as the charset parameter would be, is
> "solely for error recovery."
>=20
> Thanks,
> donald
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>  Donald E. Eastlake 3rd                      [email-masked]
>  65 Shindegan Hill Road, RR#1                     +1 914-276-2668(h)
>  Carmel, NY 10512 USA                             +1 508-261-5434(w)
>=20
> ------- End of Forwarded Message
>=20
>=20
> --JAA02481.953649127/torque.pothole.com--
>=20
>=20
> ------- End of Forwarded Message
>=20
>=20

--Boundary_(ID_Y8q/uz8A+m6FwW7R+qgpHg)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: Yet more on APPLICATION/IOTP</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>Call me conservative on this one - since there was =
not yet a formal</FONT>
<BR><FONT SIZE=3D2>decision on the matter, we have continued to use =
APPLICATION/X-IOTP</FONT>
<BR><FONT SIZE=3D2>even for IOTP 1.0 (which also is not returned from =
the editor's desk</FONT>
<BR><FONT SIZE=3D2>with an RFC number).</FONT>
</P>

<P><FONT SIZE=3D2>I realize that I should probably join the ietf-types =
mailing list</FONT>
<BR><FONT SIZE=3D2>to find this out, but ... is there any ideas on an =
alternate way</FONT>
<BR><FONT SIZE=3D2>besides modifying the actual MIME type to indicate =
that XML is in</FONT>
<BR><FONT SIZE=3D2>use?</FONT>
</P>

<P><FONT SIZE=3D2>If there were, I would prefer...</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; APPLICATION/IOTP</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; ...with a charset parameter</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; ...with an encoding or markup =
parameter</FONT>
</P>

<P><FONT SIZE=3D2>The other alternative - a really big one, at that - =
would be</FONT>
<BR><FONT SIZE=3D2>to use:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; XML/IOTP</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; ...with a charset parameter</FONT>
</P>

<P><FONT SIZE=3D2>..to my mind, this better captures the actual idea of =
what is</FONT>
<BR><FONT SIZE=3D2>happening here. This is much the same as using =
IMAGE/ or TEXT/</FONT>
<BR><FONT SIZE=3D2>where the /xxx &quot;sub-describes&quot; the higher =
level item.</FONT>
</P>

<P><FONT =
SIZE=3D2>------------------------------------------------------------ =
</FONT>
<BR><FONT SIZE=3D2>=A0Chris =
Smith=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 +1.416.348.6090 </FONT>
<BR><FONT SIZE=3D2>=A0Royal =
Bank=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
[email-masked] </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&nbsp;&nbsp; </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Donald E. Eastlake 3rd [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: March 21, 2000 09:34 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Yet more on APPLICATION/IOTP</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; There continues to be an incredible blizzard of =
messages on the</FONT>
<BR><FONT SIZE=3D2>&gt; ietf-types mailing list about whether =
&quot;-xml&quot; suffixes or the like on</FONT>
<BR><FONT SIZE=3D2>&gt; MIME types is good or bad, etc.&nbsp; In =
general, the weight of the</FONT>
<BR><FONT SIZE=3D2>&gt; argument seems to be in favor of this...&nbsp; =
So the question is would</FONT>
<BR><FONT SIZE=3D2>&gt; changing to application/iotp-xml be a hardship =
on current</FONT>
<BR><FONT SIZE=3D2>&gt; implementations and implementation =
efforts?&nbsp; (Early efforts used</FONT>
<BR><FONT SIZE=3D2>&gt; APPLICATION/X-IOTP.)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Also, it turns out that Section F of the XML =
spec has been changed.</FONT>
<BR><FONT SIZE=3D2>&gt; External charset indications, such as an =
optional charset Content-Type</FONT>
<BR><FONT SIZE=3D2>&gt; parameter, if present, over-ride and internal =
indication of character</FONT>
<BR><FONT SIZE=3D2>&gt; encoding in XML, as specified in Informational =
RFC 2376.&nbsp; So if there</FONT>
<BR><FONT SIZE=3D2>&gt; is an optional charset option, which is =
probably a good idea, then</FONT>
<BR><FONT SIZE=3D2>&gt; when present, it should over-riode any encoding =
specification</FONT>
<BR><FONT SIZE=3D2>&gt; appearing before the XML document unless we =
wnat to be non-standard...</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Donald</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; ------- Forwarded Message</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Date:&nbsp; Thu, 09 Mar 2000 23:49:47 =
-0500</FONT>
<BR><FONT SIZE=3D2>&gt; From:&nbsp; &quot;Donald E. Eastlake 3rd&quot; =
&lt;[email-masked]&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Subject:&nbsp; More on APPLICATION/IOTP</FONT>
<BR><FONT SIZE=3D2>&gt; To:&nbsp; [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Message-id:&nbsp; =
&lt;[email-masked]&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The MIME type registartion template I posted to =
the ietf-types list</FONT>
<BR><FONT SIZE=3D2>&gt; has caused a lot of comment.&nbsp; None of it =
is really about IOTP, it</FONT>
<BR><FONT SIZE=3D2>&gt; is all about two issues:</FONT>
<BR><FONT SIZE=3D2>&gt; (1) should it really be =
APPLICATION/IOTP-XML</FONT>
<BR><FONT SIZE=3D2>&gt; and</FONT>
<BR><FONT SIZE=3D2>&gt; (2) should it allow/require a charset =
parameter</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; That is, people are arguing about whether all =
new XML content MIME</FONT>
<BR><FONT SIZE=3D2>&gt; types should have a subtype with a =
&quot;-xml&quot; on the end.&nbsp; I would</FONT>
<BR><FONT SIZE=3D2>&gt; assume we don't want to change due to existing =
implementations.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; On the charset paramter issue, I think I should =
add it as an</FONT>
<BR><FONT SIZE=3D2>&gt; optional parameter.&nbsp; Section F of the XML =
1.0 specification makes</FONT>
<BR><FONT SIZE=3D2>&gt; it clear that the charset as indicated by the =
actual data</FONT>
<BR><FONT SIZE=3D2>&gt; including any byte order mark and encoding =
declaration and that</FONT>
<BR><FONT SIZE=3D2>&gt; any &quot;external&quot; charset, as the =
charset parameter would be, is</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;solely for error recovery.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks,</FONT>
<BR><FONT SIZE=3D2>&gt; donald</FONT>
<BR><FONT SIZE=3D2>&gt; =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; Donald E. Eastlake =
3rd&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; 65 Shindegan Hill Road, =
RR#1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +1 =
914-276-2668(h)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; Carmel, NY 10512 =
USA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; +1 508-261-5434(w)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; ------- End of Forwarded Message</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
--JAA02481.953649127/torque.pothole.com--</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; ------- End of Forwarded Message</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>

--Boundary_(ID_Y8q/uz8A+m6FwW7R+qgpHg)--

Date: Tue, 21 Mar 2000 09:34:15 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Yet more on APPLICATION/IOTP
To: [email-masked]

There continues to be an incredible blizzard of messages on the
ietf-types mailing list about whether "-xml" suffixes or the like on
MIME types is good or bad, etc.  In general, the weight of the
argument seems to be in favor of this...  So the question is would
changing to application/iotp-xml be a hardship on current
implementations and implementation efforts?  (Early efforts used
APPLICATION/X-IOTP.)

Also, it turns out that Section F of the XML spec has been changed.
External charset indications, such as an optional charset Content-Type
parameter, if present, over-ride and internal indication of character
encoding in XML, as specified in Informational RFC 2376.  So if there
is an optional charset option, which is probably a good idea, then
when present, it should over-riode any encoding specification
appearing before the XML document unless we wnat to be non-standard...

Donald

------- Forwarded Message

Date:  Thu, 09 Mar 2000 23:49:47 -0500
From:  "Donald E. Eastlake 3rd" <[email-masked]>
Subject:  More on APPLICATION/IOTP
To:  [email-masked]
Message-id:  <[email-masked]>

The MIME type registartion template I posted to the ietf-types list
has caused a lot of comment.  None of it is really about IOTP, it
is all about two issues:
(1) should it really be APPLICATION/IOTP-XML
and
(2) should it allow/require a charset parameter

That is, people are arguing about whether all new XML content MIME
types should have a subtype with a "-xml" on the end.  I would
assume we don't want to change due to existing implementations.

On the charset paramter issue, I think I should add it as an
optional parameter.  Section F of the XML 1.0 specification makes
it clear that the charset as indicated by the actual data
including any byte order mark and encoding declaration and that
any "external" charset, as the charset parameter would be, is
"solely for error recovery."

Thanks,
donald
=====================================================================
 Donald E. Eastlake 3rd                      [email-masked]
 65 Shindegan Hill Road, RR#1                     +1 914-276-2668(h)
 Carmel, NY 10512 USA                             +1 508-261-5434(w)

------- End of Forwarded Message

--JAA02481.953649127/torque.pothole.com--

------- End of Forwarded Message

Date: Mon, 13 Mar 2000 06:20:18 -0500
From: [email-masked]
Subject: I-D ACTION:draft-ietf-trade-iotp-v1.0-set-00.txt
Sender: [email-masked]
To: IETF-Announce: ;
Cc: [email-masked]
Reply-to: [email-masked]

--Boundary_(ID_SaHN2PKUmiWfFWlnj/GItg)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF.

	Title		: SET Supplement for the v1.0 Internet Open Trading 
                          Protocol (IOTP)
	Author(s)	: Y. Kawatsura
	Filename	: draft-ietf-trade-iotp-v1.0-set-00.txt
	Pages		: 58
	Date		: 10-Mar-00
	
This document describes detailed Input/Output parameter for the IOTP
Payment API and a procedure in the Payment Bridge for use SET as the
payment protocol within Version 1.0 of the Internet Open Trading
Protocol (IOTP).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-set-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-trade-iotp-v1.0-set-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-set-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--Boundary_(ID_SaHN2PKUmiWfFWlnj/GItg)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_Y1VfW+E0QDgODMiFIAVTPA)"

--Boundary_(ID_Y1VfW+E0QDgODMiFIAVTPA)
Content-type: Message/External-body; access-type="mail-server";
 server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-set-00.txt

--Boundary_(ID_Y1VfW+E0QDgODMiFIAVTPA)
Content-type: Message/External-body;
 name="draft-ietf-trade-iotp-v1.0-set-00.txt"; site="ftp.ietf.org";
 access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--Boundary_(ID_Y1VfW+E0QDgODMiFIAVTPA)--

--Boundary_(ID_SaHN2PKUmiWfFWlnj/GItg)--

Date: Mon, 13 Mar 2000 06:20:13 -0500
From: [email-masked]
Subject: I-D ACTION:draft-ietf-trade-iotp-v1.0-papi-00.txt
Sender: [email-masked]
To: IETF-Announce: ;
Cc: [email-masked]
Reply-to: [email-masked]

--Boundary_(ID_t2R19dfjPsS4VmDnaKpQ3Q)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF.

	Title		: Architecture and Payment API for Internet Open Trading
                          Protocol (IOTP)
	Author(s)	: W. Hans, H. Beykirch, M. Hiroya, Y. Kawatsura
	Filename	: draft-ietf-trade-iotp-v1.0-papi-00.txt
	Pages		: 143
	Date		: 10-Mar-00
	
The Trading Architecture proposes an abstract layered model of the
IOTP based trading environment. Its description sketches the
essential functional and data modules and their interfaces at each
trading role's installation. This abstract view deals as a guideline
for the modules' mapping to actual software modules.
The second part of this document focuses on the Payment API that
improves the essential interface that relates to payment
transactions. Such interface exists at the Consumers', the Merchants'
and the Payment Handlers' installations connecting the actual payment
software components/legacy systems and the generic IOTP aware front
end application.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-papi-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-trade-iotp-v1.0-papi-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-papi-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--Boundary_(ID_t2R19dfjPsS4VmDnaKpQ3Q)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_DrNEC/duxiY9uA42MMTqGA)"

--Boundary_(ID_DrNEC/duxiY9uA42MMTqGA)
Content-type: Message/External-body; access-type="mail-server";
 server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-papi-00.txt

--Boundary_(ID_DrNEC/duxiY9uA42MMTqGA)
Content-type: Message/External-body;
 name="draft-ietf-trade-iotp-v1.0-papi-00.txt"; site="ftp.ietf.org";
 access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--Boundary_(ID_DrNEC/duxiY9uA42MMTqGA)--

--Boundary_(ID_t2R19dfjPsS4VmDnaKpQ3Q)--

Date: Mon, 13 Mar 2000 15:45:27 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: IOTP and Coupons (was RE: future OTP transactions)
To: [email-masked]
Cc: [email-masked]

Hi,

At Fri, 10 Mar 2000 14:35:34 -0500,
Smith, Chris  <[email-masked]> wrote:
> 
> [1  <text/plain; iso-8859-1 (7bit)>]
> Because the blocks in a PaymentRequest (the included
> payment system data) have names, it would be possible
> to add additional out-ot-payment-protocol blocks that
> contained the needed information.
> 
> This would be fine for IOTP, but some payment systems
> might consider these additional blocks to be non-standard.
> 
> In a more general case, you could take advantage of a
> couple of other features:
> 
> 1) IOTP allows Authentication transactions prior to
>    any other transaction. Also, the final version
>    provided a way to send several Authentication
>    types in the same request.
> 
>    A coupon is a form of authorization/authentication,
>    so a special Authentication Supplement could be
>    created to handle them.
> 
>    Thus a single Auth up front could be the equivalent
>    of the merchant asking "Do you have AirMiles", "Do
>    you have coupons", "Are you a club member" - all in
>    one step.
> 
>    Since the AUth precedes the OfferResponse generation,
>    any information returned on the Auth can be used to
>    make changes in pricing.
> 
> 2) IOTP does allow for brand-dependent offers as well,
>    where the payment brand selection precedes the final
>    generation of the OfferResponse.

Yes, the current IOTP spec allows several ways to process coupons,
gift certificates, or loyality points. 

Redemption of a coupon, for example, can be implemented as the Offer,
Payment, and/or Authentication Exchanges depending on the Merchant
decision as Chris pointed out. Issuance of a coupon can also be
implemented as the Delivery Exchanges. 

I would like to mention my understanding of the relationship between
the Digital-Right Trading (DRT) and IOTP model. In short, I think
that DRT is a component which can be commonly used within the IOTP
Exchanges. In other words, I think that the DRT is layered under the
IOTP Exchanges.  

> > -----Original Message-----
> > From: David Bourget [mailto:[email-masked]]
> > Sent: January 6, 1998 09:15 AM
> > To: [email-masked]
> > Subject: future OTP transactions
> > 
> > 
> > Hi,
> > 
> > First question:
> > I'd like to know if there is plans for future OTP transactions
> > supporting negociation of promotional offers and prices. 
> > Example : I've
> > got a gift certificate, which is only a reference number, and I'd like
> > to know its real value. This kind of interaction would allow current
> > web-based promotional offers to be used in an OTP context.

Since one of the goals of the Digital-Right Trading is to provide a
common language to exchange such a promotional offer information
needed in the IOTP exchanges, such kind of gift certificates should/can
be covered in the DRT model and language. Using the language, it might
be roughly defined as below, although the protocols might be left
vendor-specific.  

<DigitalRight>
  <Issuer ...>
  <Promise ReferenceNumber=00001>
  <Holder AuthenticateInfo=...>
</DigitalRight>

Thanks,

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-8329
Email: [email-masked]

Date: Fri, 10 Mar 2000 14:35:34 -0500
From: "Smith, Chris " <[email-masked]>
Subject: IOTP and Coupons (was RE: future OTP transactions)
To: [email-masked]

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

--Boundary_(ID_/CwfSxjx7lLcoUJQloRL4g)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit

Because the blocks in a PaymentRequest (the included
payment system data) have names, it would be possible
to add additional out-ot-payment-protocol blocks that
contained the needed information.

This would be fine for IOTP, but some payment systems
might consider these additional blocks to be non-standard.

In a more general case, you could take advantage of a
couple of other features:

1) IOTP allows Authentication transactions prior to
   any other transaction. Also, the final version
   provided a way to send several Authentication
   types in the same request.

   A coupon is a form of authorization/authentication,
   so a special Authentication Supplement could be
   created to handle them.

   Thus a single Auth up front could be the equivalent
   of the merchant asking "Do you have AirMiles", "Do
   you have coupons", "Are you a club member" - all in
   one step.

   Since the AUth precedes the OfferResponse generation,
   any information returned on the Auth can be used to
   make changes in pricing.

2) IOTP does allow for brand-dependent offers as well,
   where the payment brand selection precedes the final
   generation of the OfferResponse.

------------------------------------------------------------ 
 Chris Smith                                +1.416.348.6090 
 Royal Bank                       [email-masked] 

P.S. Unless you have some psychic ability that allowed you
to phrase such coherent questions over two years ago, you
need to reset the clock on your system -- see the Sent:
line below.

> -----Original Message-----
> From: David Bourget [mailto:[email-masked]]
> Sent: January 6, 1998 09:15 AM
> To: [email-masked]
> Subject: future OTP transactions
> 
> 
> Hi,
> 
> First question:
> I'd like to know if there is plans for future OTP transactions
> supporting negociation of promotional offers and prices. 
> Example : I've
> got a gift certificate, which is only a reference number, and I'd like
> to know its real value. This kind of interaction would allow current
> web-based promotional offers to be used in an OTP context.
> 
> Second question:
> Where can I find information about the current work related 
> to SCCD ? I
> can't find anything on the web or the working group site.
> 
> 
> 
> 
> 
> 
> 

--Boundary_(ID_/CwfSxjx7lLcoUJQloRL4g)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>IOTP and Coupons (was RE: future OTP transactions)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Because the blocks in a PaymentRequest (the =
included</FONT>
<BR><FONT SIZE=3D2>payment system data) have names, it would be =
possible</FONT>
<BR><FONT SIZE=3D2>to add additional out-ot-payment-protocol blocks =
that</FONT>
<BR><FONT SIZE=3D2>contained the needed information.</FONT>
</P>

<P><FONT SIZE=3D2>This would be fine for IOTP, but some payment =
systems</FONT>
<BR><FONT SIZE=3D2>might consider these additional blocks to be =
non-standard.</FONT>
</P>

<P><FONT SIZE=3D2>In a more general case, you could take advantage of =
a</FONT>
<BR><FONT SIZE=3D2>couple of other features:</FONT>
</P>

<P><FONT SIZE=3D2>1) IOTP allows Authentication transactions prior =
to</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; any other transaction. Also, the final =
version</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; provided a way to send several =
Authentication</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; types in the same request.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; A coupon is a form of =
authorization/authentication,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; so a special Authentication Supplement =
could be</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; created to handle them.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; Thus a single Auth up front could be the =
equivalent</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; of the merchant asking &quot;Do you =
have AirMiles&quot;, &quot;Do</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; you have coupons&quot;, &quot;Are you a =
club member&quot; - all in</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; one step.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; Since the AUth precedes the =
OfferResponse generation,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; any information returned on the Auth =
can be used to</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; make changes in pricing.</FONT>
</P>

<P><FONT SIZE=3D2>2) IOTP does allow for brand-dependent offers as =
well,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; where the payment brand selection =
precedes the final</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; generation of the OfferResponse.</FONT>
</P>

<P><FONT =
SIZE=3D2>------------------------------------------------------------ =
</FONT>
<BR><FONT SIZE=3D2>=A0Chris =
Smith=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 +1.416.348.6090 </FONT>
<BR><FONT SIZE=3D2>=A0Royal =
Bank=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
[email-masked] </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>P.S. Unless you have some psychic ability that =
allowed you</FONT>
<BR><FONT SIZE=3D2>to phrase such coherent questions over two years =
ago, you</FONT>
<BR><FONT SIZE=3D2>need to reset the clock on your system -- see the =
Sent:</FONT>
<BR><FONT SIZE=3D2>line below.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: David Bourget [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: January 6, 1998 09:15 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: future OTP transactions</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; First question:</FONT>
<BR><FONT SIZE=3D2>&gt; I'd like to know if there is plans for future =
OTP transactions</FONT>
<BR><FONT SIZE=3D2>&gt; supporting negociation of promotional offers =
and prices. </FONT>
<BR><FONT SIZE=3D2>&gt; Example : I've</FONT>
<BR><FONT SIZE=3D2>&gt; got a gift certificate, which is only a =
reference number, and I'd like</FONT>
<BR><FONT SIZE=3D2>&gt; to know its real value. This kind of =
interaction would allow current</FONT>
<BR><FONT SIZE=3D2>&gt; web-based promotional offers to be used in an =
OTP context.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Second question:</FONT>
<BR><FONT SIZE=3D2>&gt; Where can I find information about the current =
work related </FONT>
<BR><FONT SIZE=3D2>&gt; to SCCD ? I</FONT>
<BR><FONT SIZE=3D2>&gt; can't find anything on the web or the working =
group site.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>

--Boundary_(ID_/CwfSxjx7lLcoUJQloRL4g)--

Date: Fri, 10 Mar 2000 14:23:26 -0500
From: "Smith, Chris " <[email-masked]>
Subject: Adopting IOTP (was RE: future OTP transactions)
To: [email-masked]

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

--Boundary_(ID_KIrvwjciVZhzAJQI4FVOPw)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit

One question at a time...

In my opinion, Version 1 of IOTP satisfies the requirements
of the vast majority of e-retailing sites, as far as the 
customer side is concerned.

Adoption is subject to the chicken-and-egg problem.
Merchants won't jump in large numbers to a protocol (or 
even a full standard) unless their customers are using 
it. Customers won't jump in huge numbers unless they 
see merchants offering it.

That said - IOTP is structured to make it's adoption 
relatively easy. For the simplest setup, the merchant will 
simply issue an OfferResponse, and then be prepared to 
accept a DeliveryRequest. The working idea is that the 
PaymentHandler is operated by one (or more - competition) 
agencies, much the way credit card processors operate today.
The merchant's task is made considerably simpler if they 
don't have to handle the payment steps, just deliver when
notified of successful payments. In a dedicated 
implementation, even if SCCD is used (which is roughly 
equivalent to SSL today) the merchant no longer carries the
credit card info with its attendant risks. The risks are 
now transferred to the PaymentHandler - however, ensuring 
that relatively few PaymentHandlers are properly secured
and defended is easier than ensuring that a relatively 
large number of Merchants are secured and defended.

Interestingly, IOTP, if adopted, makes the addition of
additional payment systems much easier. The merchant simply
updates their offer to indicate the acceptance of the added
payment system and the details of the PaymentHandler for
that system.

------------------------------------------------------------ 
 Chris Smith                                +1.416.348.6090 
 Royal Bank                       [email-masked] 

> -----Original Message-----
> From: David Bourget [mailto:[email-masked]]
> Subject: Re: future OTP transactions

> - Second, the real one: What are the expectations of the WG 
> about merchants
> adoption of the protocol ? I'm talking about e-retailing 
> sites like Amazon, Cdnow
> etc. Do you consider "baseline" OTP to fullfil most of their 
> requirements, i.e will
> they have to wait until v2 ?

--Boundary_(ID_KIrvwjciVZhzAJQI4FVOPw)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>Adopting IOTP (was RE: future OTP transactions)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>One question at a time...</FONT>
</P>

<P><FONT SIZE=3D2>In my opinion, Version 1 of IOTP satisfies the =
requirements</FONT>
<BR><FONT SIZE=3D2>of the vast majority of e-retailing sites, as far as =
the </FONT>
<BR><FONT SIZE=3D2>customer side is concerned.</FONT>
</P>

<P><FONT SIZE=3D2>Adoption is subject to the chicken-and-egg =
problem.</FONT>
<BR><FONT SIZE=3D2>Merchants won't jump in large numbers to a protocol =
(or </FONT>
<BR><FONT SIZE=3D2>even a full standard) unless their customers are =
using </FONT>
<BR><FONT SIZE=3D2>it. Customers won't jump in huge numbers unless they =
</FONT>
<BR><FONT SIZE=3D2>see merchants offering it.</FONT>
</P>

<P><FONT SIZE=3D2>That said - IOTP is structured to make it's adoption =
</FONT>
<BR><FONT SIZE=3D2>relatively easy. For the simplest setup, the =
merchant will </FONT>
<BR><FONT SIZE=3D2>simply issue an OfferResponse, and then be prepared =
to </FONT>
<BR><FONT SIZE=3D2>accept a DeliveryRequest. The working idea is that =
the </FONT>
<BR><FONT SIZE=3D2>PaymentHandler is operated by one (or more - =
competition) </FONT>
<BR><FONT SIZE=3D2>agencies, much the way credit card processors =
operate today.</FONT>
<BR><FONT SIZE=3D2>The merchant's task is made considerably simpler if =
they </FONT>
<BR><FONT SIZE=3D2>don't have to handle the payment steps, just deliver =
when</FONT>
<BR><FONT SIZE=3D2>notified of successful payments. In a dedicated =
</FONT>
<BR><FONT SIZE=3D2>implementation, even if SCCD is used (which is =
roughly </FONT>
<BR><FONT SIZE=3D2>equivalent to SSL today) the merchant no longer =
carries the</FONT>
<BR><FONT SIZE=3D2>credit card info with its attendant risks. The risks =
are </FONT>
<BR><FONT SIZE=3D2>now transferred to the PaymentHandler - however, =
ensuring </FONT>
<BR><FONT SIZE=3D2>that relatively few PaymentHandlers are properly =
secured</FONT>
<BR><FONT SIZE=3D2>and defended is easier than ensuring that a =
relatively </FONT>
<BR><FONT SIZE=3D2>large number of Merchants are secured and =
defended.</FONT>
</P>

<P><FONT SIZE=3D2>Interestingly, IOTP, if adopted, makes the addition =
of</FONT>
<BR><FONT SIZE=3D2>additional payment systems much easier. The merchant =
simply</FONT>
<BR><FONT SIZE=3D2>updates their offer to indicate the acceptance of =
the added</FONT>
<BR><FONT SIZE=3D2>payment system and the details of the PaymentHandler =
for</FONT>
<BR><FONT SIZE=3D2>that system.</FONT>
</P>

<P><FONT =
SIZE=3D2>------------------------------------------------------------ =
</FONT>
<BR><FONT SIZE=3D2>=A0Chris =
Smith=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 +1.416.348.6090 </FONT>
<BR><FONT SIZE=3D2>=A0Royal =
Bank=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
[email-masked] </FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: David Bourget [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: future OTP transactions</FONT>
</P>

<P><FONT SIZE=3D2>&gt; - Second, the real one: What are the =
expectations of the WG </FONT>
<BR><FONT SIZE=3D2>&gt; about merchants</FONT>
<BR><FONT SIZE=3D2>&gt; adoption of the protocol ? I'm talking about =
e-retailing </FONT>
<BR><FONT SIZE=3D2>&gt; sites like Amazon, Cdnow</FONT>
<BR><FONT SIZE=3D2>&gt; etc. Do you consider &quot;baseline&quot; OTP =
to fullfil most of their </FONT>
<BR><FONT SIZE=3D2>&gt; requirements, i.e will</FONT>
<BR><FONT SIZE=3D2>&gt; they have to wait until v2 ?</FONT>
</P>

</BODY>
</HTML>

--Boundary_(ID_KIrvwjciVZhzAJQI4FVOPw)--

Date: Fri, 10 Mar 2000 14:08:02 -0500
From: "Smith, Chris " <[email-masked]>
Subject: RE: error handling
To: [email-masked]

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

--Boundary_(ID_zth3wilshPvLHxAEHc2xoQ)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit

At some point, the client will determine that there is a problem,
either because some evidence of an unacceptable reply exists, or
because a timeout expires.

In both cases, the client is permitted to resubmit the original
request. (Keep in mind that the client does not know whether or
not the original was even received by the server.)

At the server side, the receipt of identical requests is supposed
to result in the return of the original corresponding reply. Thus,
even if the server has processed the request once already, the
response can be retrieved a second time without difficulty. (A
corollary to this is that the server is expected to check all
inbound requests to see if they are duplicates of previous requests.)

Over the most common transport, HTTP, there are no sessions held open.
As a result, the client can even become disconnected from the network,
but if the client has done a proper job of retaining state on its
end, the final request can be re-sent, and the transaction completed,
once the network reconnects.

------------------------------------------------------------ 
 Chris Smith                                +1.416.348.6090 
 Royal Bank                       [email-masked] 

> -----Original Message-----
> From: David Bourget [mailto:[email-masked]]
> Subject: error handling

> What happen if there is an error in the last message of a transaction
> happing over HTTP ? The last message, maybe a delivery note, 
> is supposed
> to close the transaction so the server will not be waiting for a
> confirmation before commiting the changes made in the 
> transaction. This
> mean that at this point the transaction cannot be rolled back. But if
> the last message is all garbage, then our customer is in trouble. What
> is the solution provided by the OTP to this problem ?

--Boundary_(ID_zth3wilshPvLHxAEHc2xoQ)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>RE: error handling</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>At some point, the client will determine that there =
is a problem,</FONT>
<BR><FONT SIZE=3D2>either because some evidence of an unacceptable =
reply exists, or</FONT>
<BR><FONT SIZE=3D2>because a timeout expires.</FONT>
</P>

<P><FONT SIZE=3D2>In both cases, the client is permitted to resubmit =
the original</FONT>
<BR><FONT SIZE=3D2>request. (Keep in mind that the client does not know =
whether or</FONT>
<BR><FONT SIZE=3D2>not the original was even received by the =
server.)</FONT>
</P>

<P><FONT SIZE=3D2>At the server side, the receipt of identical requests =
is supposed</FONT>
<BR><FONT SIZE=3D2>to result in the return of the original =
corresponding reply. Thus,</FONT>
<BR><FONT SIZE=3D2>even if the server has processed the request once =
already, the</FONT>
<BR><FONT SIZE=3D2>response can be retrieved a second time without =
difficulty. (A</FONT>
<BR><FONT SIZE=3D2>corollary to this is that the server is expected to =
check all</FONT>
<BR><FONT SIZE=3D2>inbound requests to see if they are duplicates of =
previous requests.)</FONT>
</P>

<P><FONT SIZE=3D2>Over the most common transport, HTTP, there are no =
sessions held open.</FONT>
<BR><FONT SIZE=3D2>As a result, the client can even become disconnected =
from the network,</FONT>
<BR><FONT SIZE=3D2>but if the client has done a proper job of retaining =
state on its</FONT>
<BR><FONT SIZE=3D2>end, the final request can be re-sent, and the =
transaction completed,</FONT>
<BR><FONT SIZE=3D2>once the network reconnects.</FONT>
</P>

<P><FONT =
SIZE=3D2>------------------------------------------------------------ =
</FONT>
<BR><FONT SIZE=3D2>=A0Chris =
Smith=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 +1.416.348.6090 </FONT>
<BR><FONT SIZE=3D2>=A0Royal =
Bank=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
[email-masked] </FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: David Bourget [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Subject: error handling</FONT>
</P>

<P><FONT SIZE=3D2>&gt; What happen if there is an error in the last =
message of a transaction</FONT>
<BR><FONT SIZE=3D2>&gt; happing over HTTP ? The last message, maybe a =
delivery note, </FONT>
<BR><FONT SIZE=3D2>&gt; is supposed</FONT>
<BR><FONT SIZE=3D2>&gt; to close the transaction so the server will not =
be waiting for a</FONT>
<BR><FONT SIZE=3D2>&gt; confirmation before commiting the changes made =
in the </FONT>
<BR><FONT SIZE=3D2>&gt; transaction. This</FONT>
<BR><FONT SIZE=3D2>&gt; mean that at this point the transaction cannot =
be rolled back. But if</FONT>
<BR><FONT SIZE=3D2>&gt; the last message is all garbage, then our =
customer is in trouble. What</FONT>
<BR><FONT SIZE=3D2>&gt; is the solution provided by the OTP to this =
problem ?</FONT>
</P>

</BODY>
</HTML>

--Boundary_(ID_zth3wilshPvLHxAEHc2xoQ)--

Resent-date: Fri, 10 Mar 2000 09:15:03 -0500 (EST)
Date: Tue, 03 Mar 1998 17:48:35 -0500
From: David Bourget <[email-masked]>
Subject: error handling
Sender: [email-masked]
To: [email-masked]
Reply-to: [email-masked]
Resent-message-id: <[email-masked]>

Hi,

I'm almost flooding this mailing list these days, but I've got a
puzzling question :

What happen if there is an error in the last message of a transaction
happing over HTTP ? The last message, maybe a delivery note, is supposed
to close the transaction so the server will not be waiting for a
confirmation before commiting the changes made in the transaction. This
mean that at this point the transaction cannot be rolled back. But if
the last message is all garbage, then our customer is in trouble. What
is the solution provided by the OTP to this problem ?

thank you,
David

Resent-date: Fri, 10 Mar 2000 09:14:09 -0500 (EST)
Date: Wed, 07 Jan 1998 17:13:50 -0500
From: David Bourget <[email-masked]>
Subject: Re: future OTP transactions
Sender: [email-masked]
To: "Donald E. Eastlake 3rd" <[email-masked]>
Cc: [email-masked]
Reply-to: [email-masked]
Resent-message-id: <[email-masked]>

Hi,

Thank you for the information Donald.

I'm presently studying the specification and two other questions arises that you or
other people on this mailing list might be able to answer :

- First, trivial question: is there a version of the 1.0 draft in word, html or any
kind of browsable format that would make the experience more enjoyable than
scrolling in a 200 pages ASCII file ? I can't find any. That is, can I have the
source ? (I have found the version on otp.org to be not enaught current)

- Second, the real one: What are the expectations of the WG about merchants
adoption of the protocol ? I'm talking about e-retailing sites like Amazon, Cdnow
etc. Do you consider "baseline" OTP to fullfil most of their requirements, i.e will
they have to wait until v2 ?

- Finaly, a third question : I'm trying to fit the baseline purchase transaction on
current .com merchants purchase transaction model and the following questions arise
:
    - Can a baseline purchase transaction happen as follow  :
    [ client
]
[ merchant ]
    shop
    select shipping     --- I wanna
buy-->                                              start transaction here
                               <-----order,brandslist
etc----                                prepare order
    select payment    -------(
                                very simple
payment                                         process payment, generate delivery
note
                                protocol, that is : here's my card number
                                )----->
    happy customer     <---------delivery note--------

In fact, I'm trying to figure out what is the simplest form of a purchase
transaction supported by an OTP agent.
It seems to me that being able to do such simples transactions is a priority for
online merchants who wants to save bandwidth and streamline the buying process.

regards,
David

Date: Thu, 09 Mar 2000 23:49:47 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: More on APPLICATION/IOTP
To: [email-masked]

The MIME type registartion template I posted to the ietf-types list
has caused a lot of comment.  None of it is really about IOTP, it
is all about two issues:
(1) should it really be APPLICATION/IOTP-XML
and
(2) should it allow/require a charset parameter

That is, people are arguing about whether all new XML content MIME
types should have a subtype with a "-xml" on the end.  I would
assume we don't want to change due to existing implementations.

On the charset paramter issue, I think I should add it as an
optional parameter.  Section F of the XML 1.0 specification makes
it clear that the charset as indicated by the actual data
including any byte order mark and encoding declaration and that
any "external" charset, as the charset parameter would be, is
"solely for error recovery."

Thanks,
donald
=====================================================================
 Donald E. Eastlake 3rd                      [email-masked]
 65 Shindegan Hill Road, RR#1                     +1 914-276-2668(h)
 Carmel, NY 10512 USA                             +1 508-261-5434(w)

Date: Thu, 09 Mar 2000 23:13:33 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Re: question about IotpSignature..!
To: Andre Chan <[email-masked]>
Cc: IOTP Group <[email-masked]>

It's just the declaration of three algorithms.  Each is identified by
an ID.  All of them but algorithm A2 take as an explicit parameter or
argument another algorithm identified by an ID.

I don't know what you mean by "using sha1 first".  It is dom-hash
which produces a serialization of the DOM which is fed to sha1.

Donald

From:  Andre Chan <[email-masked]>
Date:  Thu, 09 Mar 2000 14:44:17 +0800
To:  IOTP Group <[email-masked]>
Resent-message-id:  <[email-masked]>
Message-id:  <[email-masked]>

>	I would like to ask what is the meaning of the Element "Parameter". From
>the example below (which I copy for the doc
>"draft-ietf-trade-iotp-v1.0-dsig-05.txt" page 15), I will guess the
>signature are generated by the following sequence A2, A1, A3. That means I
>will use sha1 first, then dom-hash and finally use the rsa to sign it. But,
>the right sequence should be A1, A2, A3. How do I interpret the meaning of
>the below example?
>
>   <Algorithm ID='A1' type='digest' name='urn:ibm-com:dom-hash'>
>           <Parameter type='AlgorithmRef'>A2</Parameter>
>   </Algorithm>
>   <Algorithm ID='A2' type='digest' name='urn:nist-gov:sha1'>
>   </Algorithm>
>   <Algorithm ID='A3' type='signature' name='urn:rsasdi-com:rsa-encryption'>
>           <Parameter type='AlgorithmRef'>A1</Parameter>
>   </Algorithm>
>
>Thanks
>
>Andre
>

Date: Thu, 09 Mar 2000 23:06:06 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Re: future OTP transactions
To: [email-masked]
Cc: [email-masked]

Truly different structured transactions will probably wait until IOTP
v2.

Digital Right such as promotional offers are also being a topic which
has been discussed at TRADE WG meetings.  See
<ftp://ftp.ietf.org//internet-drafts/draft-ietf-trade-drt-requirements-00.txt>.

I post an additonal response on SCCD shortly.

Donald

From:  David Bourget <[email-masked]>
Resent-From:  [email-masked]
Resent-date:  Thu, 09 Mar 2000 08:15:40 -0500 (EST)
Date:  Tue, 06 Jan 1998 09:15:22 -0500
Sender:  [email-masked]
To:  [email-masked]
Reply-to:  [email-masked]
Resent-message-id:  <[email-masked]>
Message-id:  <[email-masked]>

>Hi,
>
>First question:
>I'd like to know if there is plans for future OTP transactions
>supporting negociation of promotional offers and prices. Example : I've
>got a gift certificate, which is only a reference number, and I'd like
>to know its real value. This kind of interaction would allow current
>web-based promotional offers to be used in an OTP context.
>
>Second question:
>Where can I find information about the current work related to SCCD ? I
>can't find anything on the web or the working group site.

Resent-date: Thu, 09 Mar 2000 08:17:02 -0500 (EST)
Date: Thu, 09 Mar 2000 14:44:17 +0800
From: Andre Chan <[email-masked]>
Subject: question about IotpSignature..!
Sender: [email-masked]
To: IOTP Group <[email-masked]>
Resent-message-id: <[email-masked]>
Importance: Normal

	I would like to ask what is the meaning of the Element "Parameter". From
the example below (which I copy for the doc
"draft-ietf-trade-iotp-v1.0-dsig-05.txt" page 15), I will guess the
signature are generated by the following sequence A2, A1, A3. That means I
will use sha1 first, then dom-hash and finally use the rsa to sign it. But,
the right sequence should be A1, A2, A3. How do I interpret the meaning of
the below example?

   <Algorithm ID='A1' type='digest' name='urn:ibm-com:dom-hash'>
           <Parameter type='AlgorithmRef'>A2</Parameter>
   </Algorithm>
   <Algorithm ID='A2' type='digest' name='urn:nist-gov:sha1'>
   </Algorithm>
   <Algorithm ID='A3' type='signature' name='urn:rsasdi-com:rsa-encryption'>
           <Parameter type='AlgorithmRef'>A1</Parameter>
   </Algorithm>

Thanks

Andre

Resent-date: Thu, 09 Mar 2000 08:15:40 -0500 (EST)
Date: Tue, 06 Jan 1998 09:15:22 -0500
From: David Bourget <[email-masked]>
Subject: future OTP transactions
Sender: [email-masked]
To: [email-masked]
Reply-to: [email-masked]
Resent-message-id: <[email-masked]>

Hi,

First question:
I'd like to know if there is plans for future OTP transactions
supporting negociation of promotional offers and prices. Example : I've
got a gift certificate, which is only a reference number, and I'd like
to know its real value. This kind of interaction would allow current
web-based promotional offers to be used in an OTP context.

Second question:
Where can I find information about the current work related to SCCD ? I
can't find anything on the web or the working group site.

Date: Thu, 09 Mar 2000 06:29:31 -0500
From: [email-masked]
Subject: I-D ACTION:draft-ietf-trade-mime-detector-02.txt
Sender: [email-masked]
To: IETF-Announce: ;
Cc: [email-masked]
Reply-to: [email-masked]

--Boundary_(ID_oFE9mjUlnUmpmdC0YiWKAQ)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF.

	Title		: HTTP MIME Type Handler Detection
	Author(s)	: D. Eastlake 3rd, C. Smith, D. Soroka
	Filename	: draft-ietf-trade-mime-detector-02.txt
	Pages		: 13
	Date		: 08-Mar-00
	
Entities composing web pages to provide services over HTTP frequently
have the problem of not knowing what MIME types have handlers
installed at a user's browser.  For example, whether an IOTP or VRML
or SET or some streaming media handler is available.  In many cases
they would want to display different web pages or content depending
on a MIME handler's availability.  This document summarizes a
reasonable technique to solve this problem for most of the browsers
actually deployed on the Internet as of August 1999.  It is intended
to be of practical use to implementors during the period before the
wide deployment of superior standards based techniques which may be
developed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trade-mime-detector-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-trade-mime-detector-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-trade-mime-detector-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--Boundary_(ID_oFE9mjUlnUmpmdC0YiWKAQ)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_pxaAQiXC0L/Q5UTYnWFEdg)"

--Boundary_(ID_pxaAQiXC0L/Q5UTYnWFEdg)
Content-type: Message/External-body; access-type="mail-server";
 server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-trade-mime-detector-02.txt

--Boundary_(ID_pxaAQiXC0L/Q5UTYnWFEdg)
Content-type: Message/External-body;
 name="draft-ietf-trade-mime-detector-02.txt"; site="ftp.ietf.org";
 access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--Boundary_(ID_pxaAQiXC0L/Q5UTYnWFEdg)--

--Boundary_(ID_oFE9mjUlnUmpmdC0YiWKAQ)--

Date: Thu, 09 Mar 2000 09:22:16 +0100
From: Rudolf Hornig <[email-masked]>
Subject: RE: IOTP implementations
To: "'Donald E. Eastlake 3rd'" <[email-masked]>
Cc: [email-masked]
Reply-to: [email-masked]
Importance: Normal

This is a multi-part message in MIME format.

--Boundary_(ID_yEDJ9rCPde7Fdt+QFI1kGg)
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: 7bit

> As far as I know, IOTP 0.9 was implemented by Hitachi and the Royal
> Bank of Canada.
> 
> The following have said they are implementing IOTP 1.0:
> 	Hitachi (SMILE Project)
> 	Royal Bank of Canada
> 	SIZ
> 	CyberSource
> 	Differential
> 	Xenosys Corporation
> 
> Donald
We have also an 1.0 implementation here at Brokat...

Rudolf
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rudolf Hornig ([email-masked]), Project Leader 
MeTechnology Ltd. Hungary - a Brokat Company
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

--Boundary_(ID_yEDJ9rCPde7Fdt+QFI1kGg)
Content-type: text/x-vcard; name="Rudolf Hornig (E-mail).vcf"
Content-disposition: attachment; filename="Rudolf Hornig (E-mail).vcf"
Content-transfer-encoding: 7bit

BEGIN:VCARD
VERSION:2.1
N:Hornig;Rudolf
FN:Rudolf Hornig (E-mail)
ORG:MeTechnology Ltd. (Hungary) - a Brokat Company;Research&Development
TITLE:Project Manager
TEL;WORK;VOICE:+36 (1) 437 04 13
TEL;WORK;FAX:+36 (1) 387 37 98
ADR;WORK:;;Kunigunda utca 58.;Budapest;;H1037;Hungary
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Kunigunda utca 58.=0D=0ABudapest H1037=0D=0AHungary
KEY;X509;ENCODING=BASE64:
    MIICjDCCAfWgAwIBAgIDAUf1MA0GCSqGSIb3DQEBBAUAMIG5MQswCQYDVQQGEwJaQTEVMBMG
    A1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEaMBgGA1UEChMRVGhh
    d3RlIENvbnN1bHRpbmcxKTAnBgNVBAsTIFRoYXd0ZSBQRiBSU0EgSUsgMTk5OC45LjE2IDE3
    OjU1MTYwNAYDVQQDEy1UaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgUlNBIElzc3VlciAxOTk4
    LjkuMTYwHhcNOTkwODI0MDg0MDA3WhcNMDAwODIzMDg0MDA3WjBJMR8wHQYDVQQDExZUaGF3
    dGUgRnJlZW1haWwgTWVtYmVyMSYwJAYJKoZIhvcNAQkBFhdydWRvbGZATWVUZWNobm9sb2d5
    LmNvbTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDH8coNT3BGTG4HGqz08KaFHSjONYQ6BLta
    HwjWmfH0j+M/hQp86tPpLB73RQjDt5lsbb/EkzGA6QShkabMQyBLAgMBAAGjVTBTMCIGA1Ud
    EQQbMBmBF3J1ZG9sZkBNZVRlY2hub2xvZ3kuY29tMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgw
    FoAU/j5gnGuMD7DYM8bKxh5YsHE4teAwDQYJKoZIhvcNAQEEBQADgYEACHlsv89kEhISAVFs
    1TdW9KKW8kluUJDjC7DDnAEgiCLw6mlm2kvHW3NzYONaefEsCBOsYVOIOBg4RW15HCR4+eay
    dEuGJXi510jSc2DN/uyYjNB4okvGKYl/zEbgTqJFEUEjwHtSFDIspCbufD1bj4I0/GQc1+fP
    Vv/VePfpVqo=

EMAIL;PREF;INTERNET:[email-masked]
REV:19990830T133416Z
END:VCARD

--Boundary_(ID_yEDJ9rCPde7Fdt+QFI1kGg)--

Date: Wed, 08 Mar 2000 18:37:16 -0800
From: Ron Ehli <[email-masked]>
Subject: RE: IOTP implementations
To: [email-masked]
Importance: Normal

PayByCheck.com is also implementing IOTP 1.0 for select services.

> -----Original Message-----
> From: Donald E. Eastlake 3rd [mailto:[email-masked]]
> Sent: Wednesday, March 08, 2000 4:31 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: IOTP implementations
> 
> 
> 
> As far as I know, IOTP 0.9 was implemented by Hitachi and the Royal
> Bank of Canada.
> 
> The following have said they are implementing IOTP 1.0:
> 	Hitachi (SMILE Project)
> 	Royal Bank of Canada
> 	SIZ
> 	CyberSource
> 	Differential
> 	Xenosys Corporation
> 
> Donald
> 
> From:  David Bourget <[email-masked]>
> Resent-From:  [email-masked]
> Resent-date:  Wed, 08 Mar 2000 16:15:49 -0500 (EST)
> Date:  Wed, 08 Mar 2000 15:44:07 -0500
> Sender:  [email-masked]
> To:  [email-masked]
> Reply-to:  [email-masked]
> Resent-message-id:  <[email-masked]>
> Message-id:  <[email-masked]>
> 
> >Hi,
> >
> >Could someone give me some pointers on early IOTP 
> implementations ? Is there any ?
> >
> >/David
> 

Date: Wed, 08 Mar 2000 19:30:59 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Re: IOTP implementations
To: [email-masked]
Cc: [email-masked]

As far as I know, IOTP 0.9 was implemented by Hitachi and the Royal
Bank of Canada.

The following have said they are implementing IOTP 1.0:
	Hitachi (SMILE Project)
	Royal Bank of Canada
	SIZ
	CyberSource
	Differential
	Xenosys Corporation

Donald

From:  David Bourget <[email-masked]>
Resent-From:  [email-masked]
Resent-date:  Wed, 08 Mar 2000 16:15:49 -0500 (EST)
Date:  Wed, 08 Mar 2000 15:44:07 -0500
Sender:  [email-masked]
To:  [email-masked]
Reply-to:  [email-masked]
Resent-message-id:  <[email-masked]>
Message-id:  <[email-masked]>

>Hi,
>
>Could someone give me some pointers on early IOTP implementations ? Is there any ?
>
>/David

Resent-date: Wed, 08 Mar 2000 16:15:49 -0500 (EST)
Date: Wed, 08 Mar 2000 15:44:07 -0500
From: David Bourget <[email-masked]>
Subject: IOTP implementations
Sender: [email-masked]
To: [email-masked]
Reply-to: [email-masked]
Resent-message-id: <[email-masked]>

Hi,

Could someone give me some pointers on early IOTP implementations ? Is there any ?

/David

Date: Wed, 08 Mar 2000 15:21:45 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: APPLICATION/IOTP
To: [email-masked]

I went ahead and sent APPLICATION/IOTP to the IETF-Types list, like
you are supposed to for new MIME types, and Ned Freed, who is the type
czar, thinks its OK.  draft-ietf-trade-iotp-http-04.txt still needs to
be approved by the IESG.

Donald

------- Forwarded Message

From:  [email-masked]
Date:  Wed, 08 Mar 2000 12:09:27 -0800 (PST)
Subject:  Re: Registration of MIME media type APPLICATION/IOTP
In-reply-to:  "Your message dated Wed, 08 Mar 2000 14:59:59 -0500"
	      <[email-masked]>
To:  "Donald E. Eastlake 3rd" <[email-masked]>
Cc:  [email-masked], [email-masked]
Message-id:  <[email-masked]>

This registration looks fine to me.

				Ned

> [See also draft-ietf-trade-iotp-http-04.txt]

>       MIME media type name: APPLICATION

>       MIME subtype name: IOTP

>       Required parameters: (none)

>       Optional parameters: (none)

>       Encoding considerations: Content is XML and may in some cases
>       require quoted printable or base64 encoding.  However, no encoding
>       is required for HTTP transport which is expected to be common.

>       Security considerations: IOTP includes provisions for digital
>       authentication but for confidentiality, other mechanisms such as
>       TLS should be used.  See Security Consideration section of
>       draft-ietf-trade-iotp-v1.0-protocol-07.txt in RFC Editor's queue.

>       Interoperability considerations:  See draft-ietf-trade-iotp-v1.0-
>       protocol-07.txt in RFC Editor's queue.

>       Published specification: See draft-ietf-trade-iotp-v1.0-protocol-
>       07.txt in RFC Editor's queue.

>       Applications which use this media type:  Internet Open Trading
>       Protocol applications.

>       Additional information: (none)

>       Person & email address to contact for further information:
>          Name: Donald E. Eastlake 3rd
>          Email: [email-masked]

>       Intended usage: COMMON

>       Author/Change controller: IETF

> =====================================================================
>  Donald E. Eastlake 3rd                      [email-masked]
>  65 Shindegan Hill Road, RR#1                     +1 914-276-2668(h)
>  Carmel, NY 10512 USA                             +1 508-261-5434(w)

------- End of Forwarded Message

Date: Tue, 07 Mar 2000 06:29:35 -0500
From: [email-masked]
Subject: I-D ACTION:draft-ietf-trade-iotp-http-04.txt
Sender: [email-masked]
To: IETF-Announce: ;
Cc: [email-masked]
Reply-to: [email-masked]

--Boundary_(ID_QkGemhOeIA11z+6ONPAmBw)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF.

	Title		: Internet Open Trading Protocol (IOTP) HTTP Supplement
	Author(s)	: D. Eastlake 3rd,  C. Smith
	Filename	: draft-ietf-trade-iotp-http-04.txt
	Pages		: 9
	Date		: 06-Mar-00
	
Internet Open Trading Protocol (IOTP [draft-ietf-trade-iotp-v1.0-
protocol-*.txt]) 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.
This documents describes that mapping for the Hyper Text Transport
Protocol (HTTP), Versions 1.0 and 1.1.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-http-04.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-trade-iotp-http-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-trade-iotp-http-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--Boundary_(ID_QkGemhOeIA11z+6ONPAmBw)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_up69Rd8G4GVU3LoZW/LS6w)"

--Boundary_(ID_up69Rd8G4GVU3LoZW/LS6w)
Content-type: Message/External-body; access-type="mail-server";
 server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-trade-iotp-http-04.txt

--Boundary_(ID_up69Rd8G4GVU3LoZW/LS6w)
Content-type: Message/External-body; name="draft-ietf-trade-iotp-http-04.txt";
 site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--Boundary_(ID_up69Rd8G4GVU3LoZW/LS6w)--

--Boundary_(ID_QkGemhOeIA11z+6ONPAmBw)--

Date: Fri, 03 Mar 2000 14:12:08 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: Has any agenda come out
To: [email-masked]
Cc: [email-masked]

At Wed, 01 Mar 2000 22:03:24 -0500,
Donald E. Eastlake 3rd <[email-masked]> wrote:
> 
> Nope.  I'll try to get a preliminary one out soon.  People are welcom
> to send me suggestions.

I would like to have time to talk about the objective of digital-right
trading briefly again, and discuss on the major requirements, e.g.,
necessity of transferability, introduction of a parameter in the
digital-right definition language to select digital-right trading
protocol. I think it will need about 20 minute.

Is there anyone else who would like to talk about on digital-right
trading? 

I'm also very interested in the requirements for ECML version 2. I'm
looking forward to see the draft.

Regards,

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-8329
Email: [email-masked]

Date: Wed, 01 Mar 2000 22:03:24 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Re: Has any agenda come out
To: Chun OUYANG <[email-masked]>
Cc: [email-masked]

Nope.  I'll try to get a preliminary one out soon.  People are welcom
to send me suggestions.

Thanks,
Donald

From:  Chun OUYANG <[email-masked]>
Date:  Thu, 02 Mar 2000 13:12:25 +1030
Sender:  [email-masked]
To:  [email-masked]
Message-id:  <[email-masked]>
Organization:  ITR

>Has any agenda of trade WG in the coming IETF come out?
>
>Chun Ouyang
>

Date: Thu, 02 Mar 2000 13:12:25 +1030
From: Chun OUYANG <[email-masked]>
Subject: Has any agenda come out
Sender: [email-masked]
To: [email-masked]
Organization: ITR

Has any agenda of trade WG in the coming IETF come out?

Chun Ouyang

Date: Wed, 01 Mar 2000 17:46:26 -0800
From: David Blondeau <[email-masked]>
Subject: [ietf-trade] OT: This is a test
To: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_CRAhbweGdzIRTlQc3TmUwQ)
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: quoted-printable

As I didn't receive any mail since I have subscribed (5 days), I make a =
test=20
David Blondeau

--Boundary_(ID_CRAhbweGdzIRTlQc3TmUwQ)
Content-type: text/html; charset="iso-8859-1"
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>As I didn't receive any mail since I =
have=20
subscribed (5 days), I make a test </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>David =
Blondeau</FONT></DIV></BODY></HTML>

--Boundary_(ID_CRAhbweGdzIRTlQc3TmUwQ)--

Date: Thu, 30 Mar 2000 06:28:07 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Re: Document changes Oct 99 - March 2000
To: Russell Perry <[email-masked]>
Cc: [email-masked]

The draft-ietf-trade-iotp-v1.0-protocol-07.txt draft is the final draft for
the V1.0 of IOTP and will be out as an RFC soon.  The -papi- draft is
a little out of date but is expected to be updated within a month.  After
than happens, the SET Supplement will be updated.

Donald

From:  Russell Perry <[email-masked]>
Date:  Wed, 29 Mar 2000 09:11:59 +0100
To:  [email-masked]
Message-id:  <[email-masked]>

>Hi,
>
>I'm looking for some help to clarify some of the apparent discrepancies
>between the following documents:
>draft-ietf-trade-iotp-v1.0-protocol-07.txt (Oct '99) and
>draft-ietf-trade-iotp-v1.0-papi-00.txt (March 2000).  For example,
>several element tags are not specified in the latter document.  Is this
>because both documents should be read together, or does it reflect the
>evolution of the protocol?  
>
>Also, am I right in assuming that the running footer of "*papi-00.txt"
>(SET supplement...) is a typo, or is there a more sinister explanation
>:)  Thanks.
>
>
>Regards,
>
>Russ.

Date: Thu, 30 Mar 2000 06:22:37 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Re: IOTP meeting in 47th IETF
To: Chun OUYANG <[email-masked]>
Cc: [email-masked]

Thanks for your note.  The draft of the official minutes will be
posted shortly.

Actually, it's the IOTP HTTP Supplement and the MIME Handler Detector
drafts that I plan to working group Last Call soon, after one more
revision.  It the working group is satisfied, they would then be
forwarded to the IESG.  It will be a while before IOTP v2.0.

B2BXML was a BoF also held at this IETF meeting.

Donald

From:  Chun OUYANG <[email-masked]>
Date:  Thu, 30 Mar 2000 19:00:24 +0930
Sender:  [email-masked]
To:  [email-masked]
Message-id:  <[email-masked]>
Organization:  ITR

>FYI,
>
>...
>
>PS: 1. IOTP transport and IOTP v2.0 will be submit to IESG soon.
>       2. xml dsig and b2b xml were also discussed in this IETF meeting.
>
>Thanks,
>
>Chun
>

Date: Thu, 30 Mar 2000 19:00:24 +0930
From: Chun OUYANG <[email-masked]>
Subject: IOTP meeting in 47th IETF
Sender: [email-masked]
To: [email-masked]
Organization: ITR

FYI,

Trade WG held its meeting in 47th IETF
(http://www.ietf.org/meetings/IETF-47.html) yesterday afternoon. IOTP
and its related protocols have been discussed.  The Chair, Sir Donald
Eastlake, organized the meeting and gave an overview of IOTPs, the
history and future. An presentation on DRT was given by Mr. Ko Fujimura
from NTT.

Here is both the good news and bad news for IOTP. The good news is it
will soon become an informational RFC; the bad news is, then it will be
the longest RFC document in IETF, according to Patrik, one of the ADs in
Applications Area.

Could I said boldly that as there isnt any standardized interoperable
framework for EC on Internet except IOTP, I do hope that it can be a
robust architecure for EC with world-wide popularity in the future.

Thanks a lot to Yoshiaki and Andrew from Hitachi for the very nice talk
with them on IOTP. Hopefully to have more discussion with the people
interested in IOTP, EC or related issues in the future. Furthermore, it
couldnt be better if some gurus can give their advice to me, in my
future work on IOTP.

PS: 1. IOTP transport and IOTP v2.0 will be submit to IESG soon.
       2. xml dsig and b2b xml were also discussed in this IETF meeting.

Thanks,

Chun

Date: Wed, 29 Mar 2000 09:11:59 +0100
From: Russell Perry <[email-masked]>
Subject: Document changes Oct 99 - March 2000
To: [email-masked]

Hi,

I'm looking for some help to clarify some of the apparent discrepancies
between the following documents:
draft-ietf-trade-iotp-v1.0-protocol-07.txt (Oct '99) and
draft-ietf-trade-iotp-v1.0-papi-00.txt (March 2000).  For example,
several element tags are not specified in the latter document.  Is this
because both documents should be read together, or does it reflect the
evolution of the protocol?  

Also, am I right in assuming that the running footer of "*papi-00.txt"
(SET supplement...) is a typo, or is there a more sinister explanation
:)  Thanks.

Regards,

Russ.

Content-return: allowed
Date: Tue, 28 Mar 2000 17:02:30 -0800
From: David Burdett <[email-masked]>
Subject: RE: Some questions on "draft-ietf-trade-xmlmsg-requirements-00.tx	t"
To: 'Shinji Kikuchi' <[email-masked]>, [email-masked]

Comments inline marked with ## ...

David

-----Original Message-----
From: Shinji Kikuchi [mailto:[email-masked]]
Sent: Thursday, March 23, 2000 3:33 AM
To: [email-masked]
Subject: Some questions on "draft-ietf-trade-xmlmsg-requirements-00.txt"

Dear Sirs

  I'm just a new commer to this mailing list. Actually, I have several
questions on the document of 

 "draft-ietf-trade-xmlmsg-requirements-00.txt" .

Could anyone let me know the right ideas to below items, please ?

1)First, according to the description in the document,  around
   "2.2.4 Document Choreography", we MUST(?) set some descriptions
   regarding controling sequence or selection,  inside of Messages, 
   in particular, in the case of "Explicit".

    The most suitable part for it or associated with it inside messages
   seems to be "Message Routing Information" part , I guess.

   However, according to the description around
  "2.1.7 Message Routing Information",  I feel a little bits difference 
  due to below . By the only description with " Each 'hop' results in 
  another entry.." seems to result in eventually "Peer to Peer" in 
  each interaction  in "Hub" way.

    Therefore, still hard to get idea regarding relationship between
   Routing matter and Document Choreography clearly,  unfortunetely.
   If there were more details of it, it would be more clear, I think.

   Anyway, is it right idea, or misunderstanding absolutely ?
##In my view, choreography, is one of the hardest areas to do. Also by using
implicit choreography, then typcially these days the choreography is hard
coded into the applications that send/receive the messages.##

2)Next, please suggest the future plan or current status regarding other
   parts of this series. According to this specification document,  Other
   7 parts have been planned.   Actually, I am interesting in Secure
   Messaging Part  [XMLMSG-SM].  I am minding that status, now.
   So,  please let me know it, if possible.
##Much of the work on XML messaging is currently being done within the
auspices of ebXML. See http://www.ebxml.org/project_teams/transport.htm for
more details.##

Thanks, S.Kikuchi.

Regards
----------------------------------------------------------
Shinji Kikuchi @ NEC Corp.
Client-Server Software Labs. Development Environment Lab.
Tel:+81-3-5476-1085(JPN), Fax:+81-3-5476-1084(JPN)

Resent-date: Thu, 23 Mar 2000 07:33:00 -0500 (EST)
Date: Thu, 23 Mar 2000 20:33:03 +0900
From: Shinji Kikuchi <[email-masked]>
Subject: Some questions on "draft-ietf-trade-xmlmsg-requirements-00.txt"
Sender: [email-masked]
To: [email-masked]
Resent-message-id: <[email-masked]>

Dear Sirs

  I'm just a new commer to this mailing list. Actually, I have several
questions on the document of 

 "draft-ietf-trade-xmlmsg-requirements-00.txt" .

Could anyone let me know the right ideas to below items, please ?

1)First, according to the description in the document,  around
   "2.2.4 Document Choreography", we MUST(?) set some descriptions
   regarding controling sequence or selection,  inside of Messages, 
   in particular, in the case of "Explicit".

    The most suitable part for it or associated with it inside messages
   seems to be "Message Routing Information" part , I guess.

   However, according to the description around
  "2.1.7 Message Routing Information",  I feel a little bits difference 
  due to below . By the only description with " Each 'hop' results in 
  another entry.." seems to result in eventually "Peer to Peer" in 
  each interaction  in "Hub" way.

    Therefore, still hard to get idea regarding relationship between
   Routing matter and Document Choreography clearly,  unfortunetely.
   If there were more details of it, it would be more clear, I think.

   Anyway, is it right idea, or misunderstanding absolutely ?

2)Next, please suggest the future plan or current status regarding other
   parts of this series. According to this specification document,  Other
   7 parts have been planned.   Actually, I am interesting in Secure
   Messaging Part  [XMLMSG-SM].  I am minding that status, now.
   So,  please let me know it, if possible.

Thanks, S.Kikuchi.

Regards
----------------------------------------------------------
Shinji Kikuchi @ NEC Corp.
Client-Server Software Labs. Development Environment Lab.
Tel:+81-3-5476-1085(JPN), Fax:+81-3-5476-1084(JPN)

Date: Tue, 21 Mar 2000 13:55:04 -0500
From: "Smith, Chris " <[email-masked]>
Subject: RE: Yet more on APPLICATION/IOTP
To: "'Donald E. Eastlake 3rd'" <[email-masked]>, [email-masked]

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

--Boundary_(ID_Y8q/uz8A+m6FwW7R+qgpHg)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

Call me conservative on this one - since there was not yet a formal
decision on the matter, we have continued to use APPLICATION/X-IOTP
even for IOTP 1.0 (which also is not returned from the editor's desk
with an RFC number).

I realize that I should probably join the ietf-types mailing list
to find this out, but ... is there any ideas on an alternate way
besides modifying the actual MIME type to indicate that XML is in
use?

If there were, I would prefer...

   APPLICATION/IOTP
   ...with a charset parameter
   ...with an encoding or markup parameter

The other alternative - a really big one, at that - would be
to use:

   XML/IOTP
   ...with a charset parameter

..to my mind, this better captures the actual idea of what is
happening here. This is much the same as using IMAGE/ or TEXT/
where the /xxx "sub-describes" the higher level item.

------------------------------------------------------------=20
=A0Chris =
Smith=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 +1.416.348.6090=20
=A0Royal =
Bank=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
[email-masked]=20

  =20

> -----Original Message-----
> From: Donald E. Eastlake 3rd [mailto:[email-masked]]
> Sent: March 21, 2000 09:34 AM
> To: [email-masked]
> Subject: Yet more on APPLICATION/IOTP
>=20
>=20
>=20
> There continues to be an incredible blizzard of messages on the
> ietf-types mailing list about whether "-xml" suffixes or the like on
> MIME types is good or bad, etc.  In general, the weight of the
> argument seems to be in favor of this...  So the question is would
> changing to application/iotp-xml be a hardship on current
> implementations and implementation efforts?  (Early efforts used
> APPLICATION/X-IOTP.)
>=20
> Also, it turns out that Section F of the XML spec has been changed.
> External charset indications, such as an optional charset =
Content-Type
> parameter, if present, over-ride and internal indication of character
> encoding in XML, as specified in Informational RFC 2376.  So if there
> is an optional charset option, which is probably a good idea, then
> when present, it should over-riode any encoding specification
> appearing before the XML document unless we wnat to be =
non-standard...
>=20
> Donald
>=20
>=20
> ------- Forwarded Message
>=20
> Date:  Thu, 09 Mar 2000 23:49:47 -0500
> From:  "Donald E. Eastlake 3rd" <[email-masked]>
> Subject:  More on APPLICATION/IOTP
> To:  [email-masked]
> Message-id:  <[email-masked]>
>=20
> The MIME type registartion template I posted to the ietf-types list
> has caused a lot of comment.  None of it is really about IOTP, it
> is all about two issues:
> (1) should it really be APPLICATION/IOTP-XML
> and
> (2) should it allow/require a charset parameter
>=20
> That is, people are arguing about whether all new XML content MIME
> types should have a subtype with a "-xml" on the end.  I would
> assume we don't want to change due to existing implementations.
>=20
> On the charset paramter issue, I think I should add it as an
> optional parameter.  Section F of the XML 1.0 specification makes
> it clear that the charset as indicated by the actual data
> including any byte order mark and encoding declaration and that
> any "external" charset, as the charset parameter would be, is
> "solely for error recovery."
>=20
> Thanks,
> donald
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>  Donald E. Eastlake 3rd                      [email-masked]
>  65 Shindegan Hill Road, RR#1                     +1 914-276-2668(h)
>  Carmel, NY 10512 USA                             +1 508-261-5434(w)
>=20
> ------- End of Forwarded Message
>=20
>=20
> --JAA02481.953649127/torque.pothole.com--
>=20
>=20
> ------- End of Forwarded Message
>=20
>=20

--Boundary_(ID_Y8q/uz8A+m6FwW7R+qgpHg)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: Yet more on APPLICATION/IOTP</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>Call me conservative on this one - since there was =
not yet a formal</FONT>
<BR><FONT SIZE=3D2>decision on the matter, we have continued to use =
APPLICATION/X-IOTP</FONT>
<BR><FONT SIZE=3D2>even for IOTP 1.0 (which also is not returned from =
the editor's desk</FONT>
<BR><FONT SIZE=3D2>with an RFC number).</FONT>
</P>

<P><FONT SIZE=3D2>I realize that I should probably join the ietf-types =
mailing list</FONT>
<BR><FONT SIZE=3D2>to find this out, but ... is there any ideas on an =
alternate way</FONT>
<BR><FONT SIZE=3D2>besides modifying the actual MIME type to indicate =
that XML is in</FONT>
<BR><FONT SIZE=3D2>use?</FONT>
</P>

<P><FONT SIZE=3D2>If there were, I would prefer...</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; APPLICATION/IOTP</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; ...with a charset parameter</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; ...with an encoding or markup =
parameter</FONT>
</P>

<P><FONT SIZE=3D2>The other alternative - a really big one, at that - =
would be</FONT>
<BR><FONT SIZE=3D2>to use:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; XML/IOTP</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; ...with a charset parameter</FONT>
</P>

<P><FONT SIZE=3D2>..to my mind, this better captures the actual idea of =
what is</FONT>
<BR><FONT SIZE=3D2>happening here. This is much the same as using =
IMAGE/ or TEXT/</FONT>
<BR><FONT SIZE=3D2>where the /xxx &quot;sub-describes&quot; the higher =
level item.</FONT>
</P>

<P><FONT =
SIZE=3D2>------------------------------------------------------------ =
</FONT>
<BR><FONT SIZE=3D2>=A0Chris =
Smith=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 +1.416.348.6090 </FONT>
<BR><FONT SIZE=3D2>=A0Royal =
Bank=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
[email-masked] </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&nbsp;&nbsp; </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Donald E. Eastlake 3rd [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: March 21, 2000 09:34 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Yet more on APPLICATION/IOTP</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; There continues to be an incredible blizzard of =
messages on the</FONT>
<BR><FONT SIZE=3D2>&gt; ietf-types mailing list about whether =
&quot;-xml&quot; suffixes or the like on</FONT>
<BR><FONT SIZE=3D2>&gt; MIME types is good or bad, etc.&nbsp; In =
general, the weight of the</FONT>
<BR><FONT SIZE=3D2>&gt; argument seems to be in favor of this...&nbsp; =
So the question is would</FONT>
<BR><FONT SIZE=3D2>&gt; changing to application/iotp-xml be a hardship =
on current</FONT>
<BR><FONT SIZE=3D2>&gt; implementations and implementation =
efforts?&nbsp; (Early efforts used</FONT>
<BR><FONT SIZE=3D2>&gt; APPLICATION/X-IOTP.)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Also, it turns out that Section F of the XML =
spec has been changed.</FONT>
<BR><FONT SIZE=3D2>&gt; External charset indications, such as an =
optional charset Content-Type</FONT>
<BR><FONT SIZE=3D2>&gt; parameter, if present, over-ride and internal =
indication of character</FONT>
<BR><FONT SIZE=3D2>&gt; encoding in XML, as specified in Informational =
RFC 2376.&nbsp; So if there</FONT>
<BR><FONT SIZE=3D2>&gt; is an optional charset option, which is =
probably a good idea, then</FONT>
<BR><FONT SIZE=3D2>&gt; when present, it should over-riode any encoding =
specification</FONT>
<BR><FONT SIZE=3D2>&gt; appearing before the XML document unless we =
wnat to be non-standard...</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Donald</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; ------- Forwarded Message</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Date:&nbsp; Thu, 09 Mar 2000 23:49:47 =
-0500</FONT>
<BR><FONT SIZE=3D2>&gt; From:&nbsp; &quot;Donald E. Eastlake 3rd&quot; =
&lt;[email-masked]&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Subject:&nbsp; More on APPLICATION/IOTP</FONT>
<BR><FONT SIZE=3D2>&gt; To:&nbsp; [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Message-id:&nbsp; =
&lt;[email-masked]&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The MIME type registartion template I posted to =
the ietf-types list</FONT>
<BR><FONT SIZE=3D2>&gt; has caused a lot of comment.&nbsp; None of it =
is really about IOTP, it</FONT>
<BR><FONT SIZE=3D2>&gt; is all about two issues:</FONT>
<BR><FONT SIZE=3D2>&gt; (1) should it really be =
APPLICATION/IOTP-XML</FONT>
<BR><FONT SIZE=3D2>&gt; and</FONT>
<BR><FONT SIZE=3D2>&gt; (2) should it allow/require a charset =
parameter</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; That is, people are arguing about whether all =
new XML content MIME</FONT>
<BR><FONT SIZE=3D2>&gt; types should have a subtype with a =
&quot;-xml&quot; on the end.&nbsp; I would</FONT>
<BR><FONT SIZE=3D2>&gt; assume we don't want to change due to existing =
implementations.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; On the charset paramter issue, I think I should =
add it as an</FONT>
<BR><FONT SIZE=3D2>&gt; optional parameter.&nbsp; Section F of the XML =
1.0 specification makes</FONT>
<BR><FONT SIZE=3D2>&gt; it clear that the charset as indicated by the =
actual data</FONT>
<BR><FONT SIZE=3D2>&gt; including any byte order mark and encoding =
declaration and that</FONT>
<BR><FONT SIZE=3D2>&gt; any &quot;external&quot; charset, as the =
charset parameter would be, is</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;solely for error recovery.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks,</FONT>
<BR><FONT SIZE=3D2>&gt; donald</FONT>
<BR><FONT SIZE=3D2>&gt; =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; Donald E. Eastlake =
3rd&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; 65 Shindegan Hill Road, =
RR#1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +1 =
914-276-2668(h)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; Carmel, NY 10512 =
USA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; +1 508-261-5434(w)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; ------- End of Forwarded Message</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
--JAA02481.953649127/torque.pothole.com--</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; ------- End of Forwarded Message</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>

--Boundary_(ID_Y8q/uz8A+m6FwW7R+qgpHg)--

Date: Tue, 21 Mar 2000 09:34:15 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Yet more on APPLICATION/IOTP
To: [email-masked]

There continues to be an incredible blizzard of messages on the
ietf-types mailing list about whether "-xml" suffixes or the like on
MIME types is good or bad, etc.  In general, the weight of the
argument seems to be in favor of this...  So the question is would
changing to application/iotp-xml be a hardship on current
implementations and implementation efforts?  (Early efforts used
APPLICATION/X-IOTP.)

Also, it turns out that Section F of the XML spec has been changed.
External charset indications, such as an optional charset Content-Type
parameter, if present, over-ride and internal indication of character
encoding in XML, as specified in Informational RFC 2376.  So if there
is an optional charset option, which is probably a good idea, then
when present, it should over-riode any encoding specification
appearing before the XML document unless we wnat to be non-standard...

Donald

------- Forwarded Message

Date:  Thu, 09 Mar 2000 23:49:47 -0500
From:  "Donald E. Eastlake 3rd" <[email-masked]>
Subject:  More on APPLICATION/IOTP
To:  [email-masked]
Message-id:  <[email-masked]>

The MIME type registartion template I posted to the ietf-types list
has caused a lot of comment.  None of it is really about IOTP, it
is all about two issues:
(1) should it really be APPLICATION/IOTP-XML
and
(2) should it allow/require a charset parameter

That is, people are arguing about whether all new XML content MIME
types should have a subtype with a "-xml" on the end.  I would
assume we don't want to change due to existing implementations.

On the charset paramter issue, I think I should add it as an
optional parameter.  Section F of the XML 1.0 specification makes
it clear that the charset as indicated by the actual data
including any byte order mark and encoding declaration and that
any "external" charset, as the charset parameter would be, is
"solely for error recovery."

Thanks,
donald
=====================================================================
 Donald E. Eastlake 3rd                      [email-masked]
 65 Shindegan Hill Road, RR#1                     +1 914-276-2668(h)
 Carmel, NY 10512 USA                             +1 508-261-5434(w)

------- End of Forwarded Message

--JAA02481.953649127/torque.pothole.com--

------- End of Forwarded Message

Date: Mon, 13 Mar 2000 06:20:18 -0500
From: [email-masked]
Subject: I-D ACTION:draft-ietf-trade-iotp-v1.0-set-00.txt
Sender: [email-masked]
To: IETF-Announce: ;
Cc: [email-masked]
Reply-to: [email-masked]

--Boundary_(ID_SaHN2PKUmiWfFWlnj/GItg)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF.

	Title		: SET Supplement for the v1.0 Internet Open Trading 
                          Protocol (IOTP)
	Author(s)	: Y. Kawatsura
	Filename	: draft-ietf-trade-iotp-v1.0-set-00.txt
	Pages		: 58
	Date		: 10-Mar-00
	
This document describes detailed Input/Output parameter for the IOTP
Payment API and a procedure in the Payment Bridge for use SET as the
payment protocol within Version 1.0 of the Internet Open Trading
Protocol (IOTP).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-set-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-trade-iotp-v1.0-set-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-set-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--Boundary_(ID_SaHN2PKUmiWfFWlnj/GItg)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_Y1VfW+E0QDgODMiFIAVTPA)"

--Boundary_(ID_Y1VfW+E0QDgODMiFIAVTPA)
Content-type: Message/External-body; access-type="mail-server";
 server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-set-00.txt

--Boundary_(ID_Y1VfW+E0QDgODMiFIAVTPA)
Content-type: Message/External-body;
 name="draft-ietf-trade-iotp-v1.0-set-00.txt"; site="ftp.ietf.org";
 access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--Boundary_(ID_Y1VfW+E0QDgODMiFIAVTPA)--

--Boundary_(ID_SaHN2PKUmiWfFWlnj/GItg)--

Date: Mon, 13 Mar 2000 06:20:13 -0500
From: [email-masked]
Subject: I-D ACTION:draft-ietf-trade-iotp-v1.0-papi-00.txt
Sender: [email-masked]
To: IETF-Announce: ;
Cc: [email-masked]
Reply-to: [email-masked]

--Boundary_(ID_t2R19dfjPsS4VmDnaKpQ3Q)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF.

	Title		: Architecture and Payment API for Internet Open Trading
                          Protocol (IOTP)
	Author(s)	: W. Hans, H. Beykirch, M. Hiroya, Y. Kawatsura
	Filename	: draft-ietf-trade-iotp-v1.0-papi-00.txt
	Pages		: 143
	Date		: 10-Mar-00
	
The Trading Architecture proposes an abstract layered model of the
IOTP based trading environment. Its description sketches the
essential functional and data modules and their interfaces at each
trading role's installation. This abstract view deals as a guideline
for the modules' mapping to actual software modules.
The second part of this document focuses on the Payment API that
improves the essential interface that relates to payment
transactions. Such interface exists at the Consumers', the Merchants'
and the Payment Handlers' installations connecting the actual payment
software components/legacy systems and the generic IOTP aware front
end application.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-papi-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-trade-iotp-v1.0-papi-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-papi-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--Boundary_(ID_t2R19dfjPsS4VmDnaKpQ3Q)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_DrNEC/duxiY9uA42MMTqGA)"

--Boundary_(ID_DrNEC/duxiY9uA42MMTqGA)
Content-type: Message/External-body; access-type="mail-server";
 server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-papi-00.txt

--Boundary_(ID_DrNEC/duxiY9uA42MMTqGA)
Content-type: Message/External-body;
 name="draft-ietf-trade-iotp-v1.0-papi-00.txt"; site="ftp.ietf.org";
 access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--Boundary_(ID_DrNEC/duxiY9uA42MMTqGA)--

--Boundary_(ID_t2R19dfjPsS4VmDnaKpQ3Q)--

Date: Mon, 13 Mar 2000 15:45:27 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: IOTP and Coupons (was RE: future OTP transactions)
To: [email-masked]
Cc: [email-masked]

Hi,

At Fri, 10 Mar 2000 14:35:34 -0500,
Smith, Chris  <[email-masked]> wrote:
> 
> [1  <text/plain; iso-8859-1 (7bit)>]
> Because the blocks in a PaymentRequest (the included
> payment system data) have names, it would be possible
> to add additional out-ot-payment-protocol blocks that
> contained the needed information.
> 
> This would be fine for IOTP, but some payment systems
> might consider these additional blocks to be non-standard.
> 
> In a more general case, you could take advantage of a
> couple of other features:
> 
> 1) IOTP allows Authentication transactions prior to
>    any other transaction. Also, the final version
>    provided a way to send several Authentication
>    types in the same request.
> 
>    A coupon is a form of authorization/authentication,
>    so a special Authentication Supplement could be
>    created to handle them.
> 
>    Thus a single Auth up front could be the equivalent
>    of the merchant asking "Do you have AirMiles", "Do
>    you have coupons", "Are you a club member" - all in
>    one step.
> 
>    Since the AUth precedes the OfferResponse generation,
>    any information returned on the Auth can be used to
>    make changes in pricing.
> 
> 2) IOTP does allow for brand-dependent offers as well,
>    where the payment brand selection precedes the final
>    generation of the OfferResponse.

Yes, the current IOTP spec allows several ways to process coupons,
gift certificates, or loyality points. 

Redemption of a coupon, for example, can be implemented as the Offer,
Payment, and/or Authentication Exchanges depending on the Merchant
decision as Chris pointed out. Issuance of a coupon can also be
implemented as the Delivery Exchanges. 

I would like to mention my understanding of the relationship between
the Digital-Right Trading (DRT) and IOTP model. In short, I think
that DRT is a component which can be commonly used within the IOTP
Exchanges. In other words, I think that the DRT is layered under the
IOTP Exchanges.  

> > -----Original Message-----
> > From: David Bourget [mailto:[email-masked]]
> > Sent: January 6, 1998 09:15 AM
> > To: [email-masked]
> > Subject: future OTP transactions
> > 
> > 
> > Hi,
> > 
> > First question:
> > I'd like to know if there is plans for future OTP transactions
> > supporting negociation of promotional offers and prices. 
> > Example : I've
> > got a gift certificate, which is only a reference number, and I'd like
> > to know its real value. This kind of interaction would allow current
> > web-based promotional offers to be used in an OTP context.

Since one of the goals of the Digital-Right Trading is to provide a
common language to exchange such a promotional offer information
needed in the IOTP exchanges, such kind of gift certificates should/can
be covered in the DRT model and language. Using the language, it might
be roughly defined as below, although the protocols might be left
vendor-specific.  

<DigitalRight>
  <Issuer ...>
  <Promise ReferenceNumber=00001>
  <Holder AuthenticateInfo=...>
</DigitalRight>

Thanks,

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-8329
Email: [email-masked]

Date: Fri, 10 Mar 2000 14:35:34 -0500
From: "Smith, Chris " <[email-masked]>
Subject: IOTP and Coupons (was RE: future OTP transactions)
To: [email-masked]

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

--Boundary_(ID_/CwfSxjx7lLcoUJQloRL4g)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit

Because the blocks in a PaymentRequest (the included
payment system data) have names, it would be possible
to add additional out-ot-payment-protocol blocks that
contained the needed information.

This would be fine for IOTP, but some payment systems
might consider these additional blocks to be non-standard.

In a more general case, you could take advantage of a
couple of other features:

1) IOTP allows Authentication transactions prior to
   any other transaction. Also, the final version
   provided a way to send several Authentication
   types in the same request.

   A coupon is a form of authorization/authentication,
   so a special Authentication Supplement could be
   created to handle them.

   Thus a single Auth up front could be the equivalent
   of the merchant asking "Do you have AirMiles", "Do
   you have coupons", "Are you a club member" - all in
   one step.

   Since the AUth precedes the OfferResponse generation,
   any information returned on the Auth can be used to
   make changes in pricing.

2) IOTP does allow for brand-dependent offers as well,
   where the payment brand selection precedes the final
   generation of the OfferResponse.

------------------------------------------------------------ 
 Chris Smith                                +1.416.348.6090 
 Royal Bank                       [email-masked] 

P.S. Unless you have some psychic ability that allowed you
to phrase such coherent questions over two years ago, you
need to reset the clock on your system -- see the Sent:
line below.

> -----Original Message-----
> From: David Bourget [mailto:[email-masked]]
> Sent: January 6, 1998 09:15 AM
> To: [email-masked]
> Subject: future OTP transactions
> 
> 
> Hi,
> 
> First question:
> I'd like to know if there is plans for future OTP transactions
> supporting negociation of promotional offers and prices. 
> Example : I've
> got a gift certificate, which is only a reference number, and I'd like
> to know its real value. This kind of interaction would allow current
> web-based promotional offers to be used in an OTP context.
> 
> Second question:
> Where can I find information about the current work related 
> to SCCD ? I
> can't find anything on the web or the working group site.
> 
> 
> 
> 
> 
> 
> 

--Boundary_(ID_/CwfSxjx7lLcoUJQloRL4g)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>IOTP and Coupons (was RE: future OTP transactions)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Because the blocks in a PaymentRequest (the =
included</FONT>
<BR><FONT SIZE=3D2>payment system data) have names, it would be =
possible</FONT>
<BR><FONT SIZE=3D2>to add additional out-ot-payment-protocol blocks =
that</FONT>
<BR><FONT SIZE=3D2>contained the needed information.</FONT>
</P>

<P><FONT SIZE=3D2>This would be fine for IOTP, but some payment =
systems</FONT>
<BR><FONT SIZE=3D2>might consider these additional blocks to be =
non-standard.</FONT>
</P>

<P><FONT SIZE=3D2>In a more general case, you could take advantage of =
a</FONT>
<BR><FONT SIZE=3D2>couple of other features:</FONT>
</P>

<P><FONT SIZE=3D2>1) IOTP allows Authentication transactions prior =
to</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; any other transaction. Also, the final =
version</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; provided a way to send several =
Authentication</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; types in the same request.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; A coupon is a form of =
authorization/authentication,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; so a special Authentication Supplement =
could be</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; created to handle them.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; Thus a single Auth up front could be the =
equivalent</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; of the merchant asking &quot;Do you =
have AirMiles&quot;, &quot;Do</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; you have coupons&quot;, &quot;Are you a =
club member&quot; - all in</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; one step.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; Since the AUth precedes the =
OfferResponse generation,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; any information returned on the Auth =
can be used to</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; make changes in pricing.</FONT>
</P>

<P><FONT SIZE=3D2>2) IOTP does allow for brand-dependent offers as =
well,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; where the payment brand selection =
precedes the final</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; generation of the OfferResponse.</FONT>
</P>

<P><FONT =
SIZE=3D2>------------------------------------------------------------ =
</FONT>
<BR><FONT SIZE=3D2>=A0Chris =
Smith=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 +1.416.348.6090 </FONT>
<BR><FONT SIZE=3D2>=A0Royal =
Bank=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
[email-masked] </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>P.S. Unless you have some psychic ability that =
allowed you</FONT>
<BR><FONT SIZE=3D2>to phrase such coherent questions over two years =
ago, you</FONT>
<BR><FONT SIZE=3D2>need to reset the clock on your system -- see the =
Sent:</FONT>
<BR><FONT SIZE=3D2>line below.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: David Bourget [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: January 6, 1998 09:15 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: future OTP transactions</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; First question:</FONT>
<BR><FONT SIZE=3D2>&gt; I'd like to know if there is plans for future =
OTP transactions</FONT>
<BR><FONT SIZE=3D2>&gt; supporting negociation of promotional offers =
and prices. </FONT>
<BR><FONT SIZE=3D2>&gt; Example : I've</FONT>
<BR><FONT SIZE=3D2>&gt; got a gift certificate, which is only a =
reference number, and I'd like</FONT>
<BR><FONT SIZE=3D2>&gt; to know its real value. This kind of =
interaction would allow current</FONT>
<BR><FONT SIZE=3D2>&gt; web-based promotional offers to be used in an =
OTP context.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Second question:</FONT>
<BR><FONT SIZE=3D2>&gt; Where can I find information about the current =
work related </FONT>
<BR><FONT SIZE=3D2>&gt; to SCCD ? I</FONT>
<BR><FONT SIZE=3D2>&gt; can't find anything on the web or the working =
group site.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>

--Boundary_(ID_/CwfSxjx7lLcoUJQloRL4g)--

Date: Fri, 10 Mar 2000 14:23:26 -0500
From: "Smith, Chris " <[email-masked]>
Subject: Adopting IOTP (was RE: future OTP transactions)
To: [email-masked]

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

--Boundary_(ID_KIrvwjciVZhzAJQI4FVOPw)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit

One question at a time...

In my opinion, Version 1 of IOTP satisfies the requirements
of the vast majority of e-retailing sites, as far as the 
customer side is concerned.

Adoption is subject to the chicken-and-egg problem.
Merchants won't jump in large numbers to a protocol (or 
even a full standard) unless their customers are using 
it. Customers won't jump in huge numbers unless they 
see merchants offering it.

That said - IOTP is structured to make it's adoption 
relatively easy. For the simplest setup, the merchant will 
simply issue an OfferResponse, and then be prepared to 
accept a DeliveryRequest. The working idea is that the 
PaymentHandler is operated by one (or more - competition) 
agencies, much the way credit card processors operate today.
The merchant's task is made considerably simpler if they 
don't have to handle the payment steps, just deliver when
notified of successful payments. In a dedicated 
implementation, even if SCCD is used (which is roughly 
equivalent to SSL today) the merchant no longer carries the
credit card info with its attendant risks. The risks are 
now transferred to the PaymentHandler - however, ensuring 
that relatively few PaymentHandlers are properly secured
and defended is easier than ensuring that a relatively 
large number of Merchants are secured and defended.

Interestingly, IOTP, if adopted, makes the addition of
additional payment systems much easier. The merchant simply
updates their offer to indicate the acceptance of the added
payment system and the details of the PaymentHandler for
that system.

------------------------------------------------------------ 
 Chris Smith                                +1.416.348.6090 
 Royal Bank                       [email-masked] 

> -----Original Message-----
> From: David Bourget [mailto:[email-masked]]
> Subject: Re: future OTP transactions

> - Second, the real one: What are the expectations of the WG 
> about merchants
> adoption of the protocol ? I'm talking about e-retailing 
> sites like Amazon, Cdnow
> etc. Do you consider "baseline" OTP to fullfil most of their 
> requirements, i.e will
> they have to wait until v2 ?

--Boundary_(ID_KIrvwjciVZhzAJQI4FVOPw)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>Adopting IOTP (was RE: future OTP transactions)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>One question at a time...</FONT>
</P>

<P><FONT SIZE=3D2>In my opinion, Version 1 of IOTP satisfies the =
requirements</FONT>
<BR><FONT SIZE=3D2>of the vast majority of e-retailing sites, as far as =
the </FONT>
<BR><FONT SIZE=3D2>customer side is concerned.</FONT>
</P>

<P><FONT SIZE=3D2>Adoption is subject to the chicken-and-egg =
problem.</FONT>
<BR><FONT SIZE=3D2>Merchants won't jump in large numbers to a protocol =
(or </FONT>
<BR><FONT SIZE=3D2>even a full standard) unless their customers are =
using </FONT>
<BR><FONT SIZE=3D2>it. Customers won't jump in huge numbers unless they =
</FONT>
<BR><FONT SIZE=3D2>see merchants offering it.</FONT>
</P>

<P><FONT SIZE=3D2>That said - IOTP is structured to make it's adoption =
</FONT>
<BR><FONT SIZE=3D2>relatively easy. For the simplest setup, the =
merchant will </FONT>
<BR><FONT SIZE=3D2>simply issue an OfferResponse, and then be prepared =
to </FONT>
<BR><FONT SIZE=3D2>accept a DeliveryRequest. The working idea is that =
the </FONT>
<BR><FONT SIZE=3D2>PaymentHandler is operated by one (or more - =
competition) </FONT>
<BR><FONT SIZE=3D2>agencies, much the way credit card processors =
operate today.</FONT>
<BR><FONT SIZE=3D2>The merchant's task is made considerably simpler if =
they </FONT>
<BR><FONT SIZE=3D2>don't have to handle the payment steps, just deliver =
when</FONT>
<BR><FONT SIZE=3D2>notified of successful payments. In a dedicated =
</FONT>
<BR><FONT SIZE=3D2>implementation, even if SCCD is used (which is =
roughly </FONT>
<BR><FONT SIZE=3D2>equivalent to SSL today) the merchant no longer =
carries the</FONT>
<BR><FONT SIZE=3D2>credit card info with its attendant risks. The risks =
are </FONT>
<BR><FONT SIZE=3D2>now transferred to the PaymentHandler - however, =
ensuring </FONT>
<BR><FONT SIZE=3D2>that relatively few PaymentHandlers are properly =
secured</FONT>
<BR><FONT SIZE=3D2>and defended is easier than ensuring that a =
relatively </FONT>
<BR><FONT SIZE=3D2>large number of Merchants are secured and =
defended.</FONT>
</P>

<P><FONT SIZE=3D2>Interestingly, IOTP, if adopted, makes the addition =
of</FONT>
<BR><FONT SIZE=3D2>additional payment systems much easier. The merchant =
simply</FONT>
<BR><FONT SIZE=3D2>updates their offer to indicate the acceptance of =
the added</FONT>
<BR><FONT SIZE=3D2>payment system and the details of the PaymentHandler =
for</FONT>
<BR><FONT SIZE=3D2>that system.</FONT>
</P>

<P><FONT =
SIZE=3D2>------------------------------------------------------------ =
</FONT>
<BR><FONT SIZE=3D2>=A0Chris =
Smith=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 +1.416.348.6090 </FONT>
<BR><FONT SIZE=3D2>=A0Royal =
Bank=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
[email-masked] </FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: David Bourget [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: future OTP transactions</FONT>
</P>

<P><FONT SIZE=3D2>&gt; - Second, the real one: What are the =
expectations of the WG </FONT>
<BR><FONT SIZE=3D2>&gt; about merchants</FONT>
<BR><FONT SIZE=3D2>&gt; adoption of the protocol ? I'm talking about =
e-retailing </FONT>
<BR><FONT SIZE=3D2>&gt; sites like Amazon, Cdnow</FONT>
<BR><FONT SIZE=3D2>&gt; etc. Do you consider &quot;baseline&quot; OTP =
to fullfil most of their </FONT>
<BR><FONT SIZE=3D2>&gt; requirements, i.e will</FONT>
<BR><FONT SIZE=3D2>&gt; they have to wait until v2 ?</FONT>
</P>

</BODY>
</HTML>

--Boundary_(ID_KIrvwjciVZhzAJQI4FVOPw)--

Date: Fri, 10 Mar 2000 14:08:02 -0500
From: "Smith, Chris " <[email-masked]>
Subject: RE: error handling
To: [email-masked]

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

--Boundary_(ID_zth3wilshPvLHxAEHc2xoQ)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit

At some point, the client will determine that there is a problem,
either because some evidence of an unacceptable reply exists, or
because a timeout expires.

In both cases, the client is permitted to resubmit the original
request. (Keep in mind that the client does not know whether or
not the original was even received by the server.)

At the server side, the receipt of identical requests is supposed
to result in the return of the original corresponding reply. Thus,
even if the server has processed the request once already, the
response can be retrieved a second time without difficulty. (A
corollary to this is that the server is expected to check all
inbound requests to see if they are duplicates of previous requests.)

Over the most common transport, HTTP, there are no sessions held open.
As a result, the client can even become disconnected from the network,
but if the client has done a proper job of retaining state on its
end, the final request can be re-sent, and the transaction completed,
once the network reconnects.

------------------------------------------------------------ 
 Chris Smith                                +1.416.348.6090 
 Royal Bank                       [email-masked] 

> -----Original Message-----
> From: David Bourget [mailto:[email-masked]]
> Subject: error handling

> What happen if there is an error in the last message of a transaction
> happing over HTTP ? The last message, maybe a delivery note, 
> is supposed
> to close the transaction so the server will not be waiting for a
> confirmation before commiting the changes made in the 
> transaction. This
> mean that at this point the transaction cannot be rolled back. But if
> the last message is all garbage, then our customer is in trouble. What
> is the solution provided by the OTP to this problem ?

--Boundary_(ID_zth3wilshPvLHxAEHc2xoQ)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>RE: error handling</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>At some point, the client will determine that there =
is a problem,</FONT>
<BR><FONT SIZE=3D2>either because some evidence of an unacceptable =
reply exists, or</FONT>
<BR><FONT SIZE=3D2>because a timeout expires.</FONT>
</P>

<P><FONT SIZE=3D2>In both cases, the client is permitted to resubmit =
the original</FONT>
<BR><FONT SIZE=3D2>request. (Keep in mind that the client does not know =
whether or</FONT>
<BR><FONT SIZE=3D2>not the original was even received by the =
server.)</FONT>
</P>

<P><FONT SIZE=3D2>At the server side, the receipt of identical requests =
is supposed</FONT>
<BR><FONT SIZE=3D2>to result in the return of the original =
corresponding reply. Thus,</FONT>
<BR><FONT SIZE=3D2>even if the server has processed the request once =
already, the</FONT>
<BR><FONT SIZE=3D2>response can be retrieved a second time without =
difficulty. (A</FONT>
<BR><FONT SIZE=3D2>corollary to this is that the server is expected to =
check all</FONT>
<BR><FONT SIZE=3D2>inbound requests to see if they are duplicates of =
previous requests.)</FONT>
</P>

<P><FONT SIZE=3D2>Over the most common transport, HTTP, there are no =
sessions held open.</FONT>
<BR><FONT SIZE=3D2>As a result, the client can even become disconnected =
from the network,</FONT>
<BR><FONT SIZE=3D2>but if the client has done a proper job of retaining =
state on its</FONT>
<BR><FONT SIZE=3D2>end, the final request can be re-sent, and the =
transaction completed,</FONT>
<BR><FONT SIZE=3D2>once the network reconnects.</FONT>
</P>

<P><FONT =
SIZE=3D2>------------------------------------------------------------ =
</FONT>
<BR><FONT SIZE=3D2>=A0Chris =
Smith=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 +1.416.348.6090 </FONT>
<BR><FONT SIZE=3D2>=A0Royal =
Bank=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
[email-masked] </FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: David Bourget [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Subject: error handling</FONT>
</P>

<P><FONT SIZE=3D2>&gt; What happen if there is an error in the last =
message of a transaction</FONT>
<BR><FONT SIZE=3D2>&gt; happing over HTTP ? The last message, maybe a =
delivery note, </FONT>
<BR><FONT SIZE=3D2>&gt; is supposed</FONT>
<BR><FONT SIZE=3D2>&gt; to close the transaction so the server will not =
be waiting for a</FONT>
<BR><FONT SIZE=3D2>&gt; confirmation before commiting the changes made =
in the </FONT>
<BR><FONT SIZE=3D2>&gt; transaction. This</FONT>
<BR><FONT SIZE=3D2>&gt; mean that at this point the transaction cannot =
be rolled back. But if</FONT>
<BR><FONT SIZE=3D2>&gt; the last message is all garbage, then our =
customer is in trouble. What</FONT>
<BR><FONT SIZE=3D2>&gt; is the solution provided by the OTP to this =
problem ?</FONT>
</P>

</BODY>
</HTML>

--Boundary_(ID_zth3wilshPvLHxAEHc2xoQ)--

Resent-date: Fri, 10 Mar 2000 09:15:03 -0500 (EST)
Date: Tue, 03 Mar 1998 17:48:35 -0500
From: David Bourget <[email-masked]>
Subject: error handling
Sender: [email-masked]
To: [email-masked]
Reply-to: [email-masked]
Resent-message-id: <[email-masked]>

Hi,

I'm almost flooding this mailing list these days, but I've got a
puzzling question :

What happen if there is an error in the last message of a transaction
happing over HTTP ? The last message, maybe a delivery note, is supposed
to close the transaction so the server will not be waiting for a
confirmation before commiting the changes made in the transaction. This
mean that at this point the transaction cannot be rolled back. But if
the last message is all garbage, then our customer is in trouble. What
is the solution provided by the OTP to this problem ?

thank you,
David

Resent-date: Fri, 10 Mar 2000 09:14:09 -0500 (EST)
Date: Wed, 07 Jan 1998 17:13:50 -0500
From: David Bourget <[email-masked]>
Subject: Re: future OTP transactions
Sender: [email-masked]
To: "Donald E. Eastlake 3rd" <[email-masked]>
Cc: [email-masked]
Reply-to: [email-masked]
Resent-message-id: <[email-masked]>

Hi,

Thank you for the information Donald.

I'm presently studying the specification and two other questions arises that you or
other people on this mailing list might be able to answer :

- First, trivial question: is there a version of the 1.0 draft in word, html or any
kind of browsable format that would make the experience more enjoyable than
scrolling in a 200 pages ASCII file ? I can't find any. That is, can I have the
source ? (I have found the version on otp.org to be not enaught current)

- Second, the real one: What are the expectations of the WG about merchants
adoption of the protocol ? I'm talking about e-retailing sites like Amazon, Cdnow
etc. Do you consider "baseline" OTP to fullfil most of their requirements, i.e will
they have to wait until v2 ?

- Finaly, a third question : I'm trying to fit the baseline purchase transaction on
current .com merchants purchase transaction model and the following questions arise
:
    - Can a baseline purchase transaction happen as follow  :
    [ client
]
[ merchant ]
    shop
    select shipping     --- I wanna
buy-->                                              start transaction here
                               <-----order,brandslist
etc----                                prepare order
    select payment    -------(
                                very simple
payment                                         process payment, generate delivery
note
                                protocol, that is : here's my card number
                                )----->
    happy customer     <---------delivery note--------

In fact, I'm trying to figure out what is the simplest form of a purchase
transaction supported by an OTP agent.
It seems to me that being able to do such simples transactions is a priority for
online merchants who wants to save bandwidth and streamline the buying process.

regards,
David

Date: Thu, 09 Mar 2000 23:49:47 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: More on APPLICATION/IOTP
To: [email-masked]

The MIME type registartion template I posted to the ietf-types list
has caused a lot of comment.  None of it is really about IOTP, it
is all about two issues:
(1) should it really be APPLICATION/IOTP-XML
and
(2) should it allow/require a charset parameter

That is, people are arguing about whether all new XML content MIME
types should have a subtype with a "-xml" on the end.  I would
assume we don't want to change due to existing implementations.

On the charset paramter issue, I think I should add it as an
optional parameter.  Section F of the XML 1.0 specification makes
it clear that the charset as indicated by the actual data
including any byte order mark and encoding declaration and that
any "external" charset, as the charset parameter would be, is
"solely for error recovery."

Thanks,
donald
=====================================================================
 Donald E. Eastlake 3rd                      [email-masked]
 65 Shindegan Hill Road, RR#1                     +1 914-276-2668(h)
 Carmel, NY 10512 USA                             +1 508-261-5434(w)

Date: Thu, 09 Mar 2000 23:13:33 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Re: question about IotpSignature..!
To: Andre Chan <[email-masked]>
Cc: IOTP Group <[email-masked]>

It's just the declaration of three algorithms.  Each is identified by
an ID.  All of them but algorithm A2 take as an explicit parameter or
argument another algorithm identified by an ID.

I don't know what you mean by "using sha1 first".  It is dom-hash
which produces a serialization of the DOM which is fed to sha1.

Donald

From:  Andre Chan <[email-masked]>
Date:  Thu, 09 Mar 2000 14:44:17 +0800
To:  IOTP Group <[email-masked]>
Resent-message-id:  <[email-masked]>
Message-id:  <[email-masked]>

>	I would like to ask what is the meaning of the Element "Parameter". From
>the example below (which I copy for the doc
>"draft-ietf-trade-iotp-v1.0-dsig-05.txt" page 15), I will guess the
>signature are generated by the following sequence A2, A1, A3. That means I
>will use sha1 first, then dom-hash and finally use the rsa to sign it. But,
>the right sequence should be A1, A2, A3. How do I interpret the meaning of
>the below example?
>
>   <Algorithm ID='A1' type='digest' name='urn:ibm-com:dom-hash'>
>           <Parameter type='AlgorithmRef'>A2</Parameter>
>   </Algorithm>
>   <Algorithm ID='A2' type='digest' name='urn:nist-gov:sha1'>
>   </Algorithm>
>   <Algorithm ID='A3' type='signature' name='urn:rsasdi-com:rsa-encryption'>
>           <Parameter type='AlgorithmRef'>A1</Parameter>
>   </Algorithm>
>
>Thanks
>
>Andre
>

Date: Thu, 09 Mar 2000 23:06:06 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Re: future OTP transactions
To: [email-masked]
Cc: [email-masked]

Truly different structured transactions will probably wait until IOTP
v2.

Digital Right such as promotional offers are also being a topic which
has been discussed at TRADE WG meetings.  See
<ftp://ftp.ietf.org//internet-drafts/draft-ietf-trade-drt-requirements-00.txt>.

I post an additonal response on SCCD shortly.

Donald

From:  David Bourget <[email-masked]>
Resent-From:  [email-masked]
Resent-date:  Thu, 09 Mar 2000 08:15:40 -0500 (EST)
Date:  Tue, 06 Jan 1998 09:15:22 -0500
Sender:  [email-masked]
To:  [email-masked]
Reply-to:  [email-masked]
Resent-message-id:  <[email-masked]>
Message-id:  <[email-masked]>

>Hi,
>
>First question:
>I'd like to know if there is plans for future OTP transactions
>supporting negociation of promotional offers and prices. Example : I've
>got a gift certificate, which is only a reference number, and I'd like
>to know its real value. This kind of interaction would allow current
>web-based promotional offers to be used in an OTP context.
>
>Second question:
>Where can I find information about the current work related to SCCD ? I
>can't find anything on the web or the working group site.

Resent-date: Thu, 09 Mar 2000 08:17:02 -0500 (EST)
Date: Thu, 09 Mar 2000 14:44:17 +0800
From: Andre Chan <[email-masked]>
Subject: question about IotpSignature..!
Sender: [email-masked]
To: IOTP Group <[email-masked]>
Resent-message-id: <[email-masked]>
Importance: Normal

	I would like to ask what is the meaning of the Element "Parameter". From
the example below (which I copy for the doc
"draft-ietf-trade-iotp-v1.0-dsig-05.txt" page 15), I will guess the
signature are generated by the following sequence A2, A1, A3. That means I
will use sha1 first, then dom-hash and finally use the rsa to sign it. But,
the right sequence should be A1, A2, A3. How do I interpret the meaning of
the below example?

   <Algorithm ID='A1' type='digest' name='urn:ibm-com:dom-hash'>
           <Parameter type='AlgorithmRef'>A2</Parameter>
   </Algorithm>
   <Algorithm ID='A2' type='digest' name='urn:nist-gov:sha1'>
   </Algorithm>
   <Algorithm ID='A3' type='signature' name='urn:rsasdi-com:rsa-encryption'>
           <Parameter type='AlgorithmRef'>A1</Parameter>
   </Algorithm>

Thanks

Andre

Resent-date: Thu, 09 Mar 2000 08:15:40 -0500 (EST)
Date: Tue, 06 Jan 1998 09:15:22 -0500
From: David Bourget <[email-masked]>
Subject: future OTP transactions
Sender: [email-masked]
To: [email-masked]
Reply-to: [email-masked]
Resent-message-id: <[email-masked]>

Hi,

First question:
I'd like to know if there is plans for future OTP transactions
supporting negociation of promotional offers and prices. Example : I've
got a gift certificate, which is only a reference number, and I'd like
to know its real value. This kind of interaction would allow current
web-based promotional offers to be used in an OTP context.

Second question:
Where can I find information about the current work related to SCCD ? I
can't find anything on the web or the working group site.

Date: Thu, 09 Mar 2000 06:29:31 -0500
From: [email-masked]
Subject: I-D ACTION:draft-ietf-trade-mime-detector-02.txt
Sender: [email-masked]
To: IETF-Announce: ;
Cc: [email-masked]
Reply-to: [email-masked]

--Boundary_(ID_oFE9mjUlnUmpmdC0YiWKAQ)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF.

	Title		: HTTP MIME Type Handler Detection
	Author(s)	: D. Eastlake 3rd, C. Smith, D. Soroka
	Filename	: draft-ietf-trade-mime-detector-02.txt
	Pages		: 13
	Date		: 08-Mar-00
	
Entities composing web pages to provide services over HTTP frequently
have the problem of not knowing what MIME types have handlers
installed at a user's browser.  For example, whether an IOTP or VRML
or SET or some streaming media handler is available.  In many cases
they would want to display different web pages or content depending
on a MIME handler's availability.  This document summarizes a
reasonable technique to solve this problem for most of the browsers
actually deployed on the Internet as of August 1999.  It is intended
to be of practical use to implementors during the period before the
wide deployment of superior standards based techniques which may be
developed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trade-mime-detector-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-trade-mime-detector-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-trade-mime-detector-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--Boundary_(ID_oFE9mjUlnUmpmdC0YiWKAQ)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_pxaAQiXC0L/Q5UTYnWFEdg)"

--Boundary_(ID_pxaAQiXC0L/Q5UTYnWFEdg)
Content-type: Message/External-body; access-type="mail-server";
 server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-trade-mime-detector-02.txt

--Boundary_(ID_pxaAQiXC0L/Q5UTYnWFEdg)
Content-type: Message/External-body;
 name="draft-ietf-trade-mime-detector-02.txt"; site="ftp.ietf.org";
 access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--Boundary_(ID_pxaAQiXC0L/Q5UTYnWFEdg)--

--Boundary_(ID_oFE9mjUlnUmpmdC0YiWKAQ)--

Date: Thu, 09 Mar 2000 09:22:16 +0100
From: Rudolf Hornig <[email-masked]>
Subject: RE: IOTP implementations
To: "'Donald E. Eastlake 3rd'" <[email-masked]>
Cc: [email-masked]
Reply-to: [email-masked]
Importance: Normal

This is a multi-part message in MIME format.

--Boundary_(ID_yEDJ9rCPde7Fdt+QFI1kGg)
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: 7bit

> As far as I know, IOTP 0.9 was implemented by Hitachi and the Royal
> Bank of Canada.
> 
> The following have said they are implementing IOTP 1.0:
> 	Hitachi (SMILE Project)
> 	Royal Bank of Canada
> 	SIZ
> 	CyberSource
> 	Differential
> 	Xenosys Corporation
> 
> Donald
We have also an 1.0 implementation here at Brokat...

Rudolf
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rudolf Hornig ([email-masked]), Project Leader 
MeTechnology Ltd. Hungary - a Brokat Company
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

--Boundary_(ID_yEDJ9rCPde7Fdt+QFI1kGg)
Content-type: text/x-vcard; name="Rudolf Hornig (E-mail).vcf"
Content-disposition: attachment; filename="Rudolf Hornig (E-mail).vcf"
Content-transfer-encoding: 7bit

BEGIN:VCARD
VERSION:2.1
N:Hornig;Rudolf
FN:Rudolf Hornig (E-mail)
ORG:MeTechnology Ltd. (Hungary) - a Brokat Company;Research&Development
TITLE:Project Manager
TEL;WORK;VOICE:+36 (1) 437 04 13
TEL;WORK;FAX:+36 (1) 387 37 98
ADR;WORK:;;Kunigunda utca 58.;Budapest;;H1037;Hungary
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Kunigunda utca 58.=0D=0ABudapest H1037=0D=0AHungary
KEY;X509;ENCODING=BASE64:
    MIICjDCCAfWgAwIBAgIDAUf1MA0GCSqGSIb3DQEBBAUAMIG5MQswCQYDVQQGEwJaQTEVMBMG
    A1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEaMBgGA1UEChMRVGhh
    d3RlIENvbnN1bHRpbmcxKTAnBgNVBAsTIFRoYXd0ZSBQRiBSU0EgSUsgMTk5OC45LjE2IDE3
    OjU1MTYwNAYDVQQDEy1UaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgUlNBIElzc3VlciAxOTk4
    LjkuMTYwHhcNOTkwODI0MDg0MDA3WhcNMDAwODIzMDg0MDA3WjBJMR8wHQYDVQQDExZUaGF3
    dGUgRnJlZW1haWwgTWVtYmVyMSYwJAYJKoZIhvcNAQkBFhdydWRvbGZATWVUZWNobm9sb2d5
    LmNvbTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDH8coNT3BGTG4HGqz08KaFHSjONYQ6BLta
    HwjWmfH0j+M/hQp86tPpLB73RQjDt5lsbb/EkzGA6QShkabMQyBLAgMBAAGjVTBTMCIGA1Ud
    EQQbMBmBF3J1ZG9sZkBNZVRlY2hub2xvZ3kuY29tMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgw
    FoAU/j5gnGuMD7DYM8bKxh5YsHE4teAwDQYJKoZIhvcNAQEEBQADgYEACHlsv89kEhISAVFs
    1TdW9KKW8kluUJDjC7DDnAEgiCLw6mlm2kvHW3NzYONaefEsCBOsYVOIOBg4RW15HCR4+eay
    dEuGJXi510jSc2DN/uyYjNB4okvGKYl/zEbgTqJFEUEjwHtSFDIspCbufD1bj4I0/GQc1+fP
    Vv/VePfpVqo=

EMAIL;PREF;INTERNET:[email-masked]
REV:19990830T133416Z
END:VCARD

--Boundary_(ID_yEDJ9rCPde7Fdt+QFI1kGg)--

Date: Wed, 08 Mar 2000 18:37:16 -0800
From: Ron Ehli <[email-masked]>
Subject: RE: IOTP implementations
To: [email-masked]
Importance: Normal

PayByCheck.com is also implementing IOTP 1.0 for select services.

> -----Original Message-----
> From: Donald E. Eastlake 3rd [mailto:[email-masked]]
> Sent: Wednesday, March 08, 2000 4:31 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: IOTP implementations
> 
> 
> 
> As far as I know, IOTP 0.9 was implemented by Hitachi and the Royal
> Bank of Canada.
> 
> The following have said they are implementing IOTP 1.0:
> 	Hitachi (SMILE Project)
> 	Royal Bank of Canada
> 	SIZ
> 	CyberSource
> 	Differential
> 	Xenosys Corporation
> 
> Donald
> 
> From:  David Bourget <[email-masked]>
> Resent-From:  [email-masked]
> Resent-date:  Wed, 08 Mar 2000 16:15:49 -0500 (EST)
> Date:  Wed, 08 Mar 2000 15:44:07 -0500
> Sender:  [email-masked]
> To:  [email-masked]
> Reply-to:  [email-masked]
> Resent-message-id:  <[email-masked]>
> Message-id:  <[email-masked]>
> 
> >Hi,
> >
> >Could someone give me some pointers on early IOTP 
> implementations ? Is there any ?
> >
> >/David
> 

Date: Wed, 08 Mar 2000 19:30:59 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Re: IOTP implementations
To: [email-masked]
Cc: [email-masked]

As far as I know, IOTP 0.9 was implemented by Hitachi and the Royal
Bank of Canada.

The following have said they are implementing IOTP 1.0:
	Hitachi (SMILE Project)
	Royal Bank of Canada
	SIZ
	CyberSource
	Differential
	Xenosys Corporation

Donald

From:  David Bourget <[email-masked]>
Resent-From:  [email-masked]
Resent-date:  Wed, 08 Mar 2000 16:15:49 -0500 (EST)
Date:  Wed, 08 Mar 2000 15:44:07 -0500
Sender:  [email-masked]
To:  [email-masked]
Reply-to:  [email-masked]
Resent-message-id:  <[email-masked]>
Message-id:  <[email-masked]>

>Hi,
>
>Could someone give me some pointers on early IOTP implementations ? Is there any ?
>
>/David

Resent-date: Wed, 08 Mar 2000 16:15:49 -0500 (EST)
Date: Wed, 08 Mar 2000 15:44:07 -0500
From: David Bourget <[email-masked]>
Subject: IOTP implementations
Sender: [email-masked]
To: [email-masked]
Reply-to: [email-masked]
Resent-message-id: <[email-masked]>

Hi,

Could someone give me some pointers on early IOTP implementations ? Is there any ?

/David

Date: Wed, 08 Mar 2000 15:21:45 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: APPLICATION/IOTP
To: [email-masked]

I went ahead and sent APPLICATION/IOTP to the IETF-Types list, like
you are supposed to for new MIME types, and Ned Freed, who is the type
czar, thinks its OK.  draft-ietf-trade-iotp-http-04.txt still needs to
be approved by the IESG.

Donald

------- Forwarded Message

From:  [email-masked]
Date:  Wed, 08 Mar 2000 12:09:27 -0800 (PST)
Subject:  Re: Registration of MIME media type APPLICATION/IOTP
In-reply-to:  "Your message dated Wed, 08 Mar 2000 14:59:59 -0500"
	      <[email-masked]>
To:  "Donald E. Eastlake 3rd" <[email-masked]>
Cc:  [email-masked], [email-masked]
Message-id:  <[email-masked]>

This registration looks fine to me.

				Ned

> [See also draft-ietf-trade-iotp-http-04.txt]

>       MIME media type name: APPLICATION

>       MIME subtype name: IOTP

>       Required parameters: (none)

>       Optional parameters: (none)

>       Encoding considerations: Content is XML and may in some cases
>       require quoted printable or base64 encoding.  However, no encoding
>       is required for HTTP transport which is expected to be common.

>       Security considerations: IOTP includes provisions for digital
>       authentication but for confidentiality, other mechanisms such as
>       TLS should be used.  See Security Consideration section of
>       draft-ietf-trade-iotp-v1.0-protocol-07.txt in RFC Editor's queue.

>       Interoperability considerations:  See draft-ietf-trade-iotp-v1.0-
>       protocol-07.txt in RFC Editor's queue.

>       Published specification: See draft-ietf-trade-iotp-v1.0-protocol-
>       07.txt in RFC Editor's queue.

>       Applications which use this media type:  Internet Open Trading
>       Protocol applications.

>       Additional information: (none)

>       Person & email address to contact for further information:
>          Name: Donald E. Eastlake 3rd
>          Email: [email-masked]

>       Intended usage: COMMON

>       Author/Change controller: IETF

> =====================================================================
>  Donald E. Eastlake 3rd                      [email-masked]
>  65 Shindegan Hill Road, RR#1                     +1 914-276-2668(h)
>  Carmel, NY 10512 USA                             +1 508-261-5434(w)

------- End of Forwarded Message

Date: Tue, 07 Mar 2000 06:29:35 -0500
From: [email-masked]
Subject: I-D ACTION:draft-ietf-trade-iotp-http-04.txt
Sender: [email-masked]
To: IETF-Announce: ;
Cc: [email-masked]
Reply-to: [email-masked]

--Boundary_(ID_QkGemhOeIA11z+6ONPAmBw)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF.

	Title		: Internet Open Trading Protocol (IOTP) HTTP Supplement
	Author(s)	: D. Eastlake 3rd,  C. Smith
	Filename	: draft-ietf-trade-iotp-http-04.txt
	Pages		: 9
	Date		: 06-Mar-00
	
Internet Open Trading Protocol (IOTP [draft-ietf-trade-iotp-v1.0-
protocol-*.txt]) 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.
This documents describes that mapping for the Hyper Text Transport
Protocol (HTTP), Versions 1.0 and 1.1.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-http-04.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-trade-iotp-http-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-trade-iotp-http-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--Boundary_(ID_QkGemhOeIA11z+6ONPAmBw)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_up69Rd8G4GVU3LoZW/LS6w)"

--Boundary_(ID_up69Rd8G4GVU3LoZW/LS6w)
Content-type: Message/External-body; access-type="mail-server";
 server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-trade-iotp-http-04.txt

--Boundary_(ID_up69Rd8G4GVU3LoZW/LS6w)
Content-type: Message/External-body; name="draft-ietf-trade-iotp-http-04.txt";
 site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--Boundary_(ID_up69Rd8G4GVU3LoZW/LS6w)--

--Boundary_(ID_QkGemhOeIA11z+6ONPAmBw)--

Date: Fri, 03 Mar 2000 14:12:08 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: Has any agenda come out
To: [email-masked]
Cc: [email-masked]

At Wed, 01 Mar 2000 22:03:24 -0500,
Donald E. Eastlake 3rd <[email-masked]> wrote:
> 
> Nope.  I'll try to get a preliminary one out soon.  People are welcom
> to send me suggestions.

I would like to have time to talk about the objective of digital-right
trading briefly again, and discuss on the major requirements, e.g.,
necessity of transferability, introduction of a parameter in the
digital-right definition language to select digital-right trading
protocol. I think it will need about 20 minute.

Is there anyone else who would like to talk about on digital-right
trading? 

I'm also very interested in the requirements for ECML version 2. I'm
looking forward to see the draft.

Regards,

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-8329
Email: [email-masked]

Date: Wed, 01 Mar 2000 22:03:24 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Re: Has any agenda come out
To: Chun OUYANG <[email-masked]>
Cc: [email-masked]

Nope.  I'll try to get a preliminary one out soon.  People are welcom
to send me suggestions.

Thanks,
Donald

From:  Chun OUYANG <[email-masked]>
Date:  Thu, 02 Mar 2000 13:12:25 +1030
Sender:  [email-masked]
To:  [email-masked]
Message-id:  <[email-masked]>
Organization:  ITR

>Has any agenda of trade WG in the coming IETF come out?
>
>Chun Ouyang
>

Date: Thu, 02 Mar 2000 13:12:25 +1030
From: Chun OUYANG <[email-masked]>
Subject: Has any agenda come out
Sender: [email-masked]
To: [email-masked]
Organization: ITR

Has any agenda of trade WG in the coming IETF come out?

Chun Ouyang

Date: Wed, 01 Mar 2000 17:46:26 -0800
From: David Blondeau <[email-masked]>
Subject: [ietf-trade] OT: This is a test
To: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_CRAhbweGdzIRTlQc3TmUwQ)
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: quoted-printable

As I didn't receive any mail since I have subscribed (5 days), I make a =
test=20
David Blondeau

--Boundary_(ID_CRAhbweGdzIRTlQc3TmUwQ)
Content-type: text/html; charset="iso-8859-1"
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>As I didn't receive any mail since I =
have=20
subscribed (5 days), I make a test </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>David =
Blondeau</FONT></DIV></BODY></HTML>

--Boundary_(ID_CRAhbweGdzIRTlQc3TmUwQ)--