Subject: draft-ietf-trade-iotp-http-01.txt
From: "Donald E. Eastlake 3rd" <[email-masked]>
To: [email-masked]
Date: Fri, 26 Feb 1999 16:50:00 -0500

A revised version of the HTTP transport supplement draft is available.
Although it is an improvement on the previous version, I think it
needs further review and work.

It has been submitted to internet-drafts and is available at
<ftp://ftp.pothole.com/pub/dee3/draft-ietf-trade-iotp-http-01.txt>.

Thanks,
Donald

=====================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668     [email-masked]
 65 Shindegan Hill Road, RR#1  +1 914-784-7913(work)  [email-masked]
 Carmel, NY 10512 USA
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
Subject: draft-ietf-trade-iotp-v1.0-dsig-00.txt
Date: Fri, 26 Feb 1999 15:31:00 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

IOTP v1.0 needs digital signatures.  There is an effort underway to
standardize general XML digital signatures as per the message posted
earlier today about a BoF on that subject at the March IETF meeting
and numerous other messages here.  However, it is not clear when that
effort will produce its final result.  Thus a much narrower
specification has been separately documented by Kent Davidson to
complete the IOTP V1.0 specification.  It is anticipated that later
versions of IOTP will change to just refer to a general XML signature
standard.

This narrower specification has been submitted to internet-drafts and
is available at
<ftp://ftp.pothole.com/pub/dee3/draft-ietf-trade-iotp-v1.0-dsig-00.txt>.

Thanks
Donald

=====================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668     [email-masked]
 65 Shindegan Hill Road, RR#1  +1 914-784-7913(work)  [email-masked]
 Carmel, NY 10512 USA
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
cc: [email-masked]
Subject: XMLDSIG BoF Scheduled at March IETF meeting
Date: Fri, 26 Feb 1999 14:05:31 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

XMLDSIG at the March 1999 IETF meeting is tentatively scheduled as follows:

	Tuesday, March 16 at 0900-1115.
		other groups scheduled at that time: sieve, rps,
ngtrans, megaco, malloc, mobileip

Thanks,
Donald
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
Subject: iotp-v1.0-protocol-03.dtd
Date: Fri, 26 Feb 1999 00:44:43 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

In addition, if you just want the DTD without page breaks, see
<ftp://ftp.pothole.com/pub/dee3/iotp-v1.0-protocol-03.dtd>.

Thanks,
Donald

=====================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668     [email-masked]
 65 Shindegan Hill Road, RR#1  +1 914-784-7913(work)  [email-masked]
 Carmel, NY 10512 USA
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
Subject: draft-ietf-trade-iotp-v1.0-protocol-03.txt
Date: Fri, 26 Feb 1999 00:17:15 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

An updated version of the main Informational draft is available at
<ftp://ftp.pothole.com/pub/dee3/draft-ietf-trade-iotp-v1.0-protocol-03.txt>.
It's been submitted to Internet-Drafts but I don't know how soon it
will get officially posted, what with the pre meeting rush..

Thanks,
Donald

=====================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668     [email-masked]
 65 Shindegan Hill Road, RR#1  +1 914-784-7913(work)  [email-masked]
 Carmel, NY 10512 USA
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
Subject: general XML digital signature stuff
Date: Thu, 25 Feb 1999 13:37:05 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

While we are nailing down a limited version for IOTP v1.0, parallel
work continues on general digital signatures for XML.  There is a
mailing list you can subscribe to at [email-masked].
There will be a BoF at the upcoming IETF meeting in March.  And Joseph
Reagle of the W3C has requested that I forward the following to this
list:
        
Forwarded Text ----
 
 Call for Participation:
 
 XML-DSig '99: The W3C Signed XML Workshop
 
 April 15th and 16th, 1999
 Boston, Massachusetts
 
 * Workshop Scope
 * Expected Audience
 * Position Papers
 * Registration
 * Workshop Organization
 
 See the following for the complete call for participation:
         [1] http://www.w3.org/1999/02/ds-xml-cfp-19990218.html
 _________________________________________________________________
 
 Workshop Scope
 
 Structured information permits data to be easily read, exchanged, and
 acted upon by Web agents. The scope of such information often includes
 media-independent data for electronic publishing, electronic commerce
 and -- critically -- information about other information (metadata).
 The W3C's Extensible Markup Language (XML) Recommendation
 specifies a standard syntax for structuring Web documents. The content
 of the document structure is arbitrary; anyone can create a XML data
 structure (be it a bibliographic format or cooking recipe) as long as
 it is well formed. One can also associate (through RDF or
 Xlink) the meaning of the structured information to a Web
 resource. For example, "The resource at http://foo.com/~bar.html
 has a bibliographic entry as follows ...." This is very powerful!
 
 However, the usefulness of structured information is dependent on how
 trustworthy it is. Is the authenticity of an assertion or the
 integrity of a price list assured? The goal of the XML-DSig workshop
 is to explore current work on XML, metadata, and machine readable
 semantics in the context of digital signatures. A result of this
 workshop may be a W3C activity that produces a specification for
 assuring the authenticity and integrity of Web data.
 
 Further information on the character of W3C workshops can be seen in
 the W3C process document.
 _________________________________________________________________
 
 Expected Audience
 
 We expect several groups to contribute to the workshop:
 * Members of W3C working groups that are concerned about the
 integrity and authenticity of metadata structures and
 applications, such as the XML, RDF, and P3P working groups.
 * Organizations addressing Web information and capability
 management.
 * Organizations addressing trust management on the Web.
 
 The workshop is an open event; space is limited and preference will be
 given to (1) W3C members and (2) experts in the field of metadata and
 digital signatures.
 _________________________________________________________________
 
 Position Papers
 
 Position papers are the basis for the discussion at the workshop. A
 position paper is usually short, around 1 to 4 pages and summarizes:
 * What are the needs of your company/organization in the signed XML
 area that you would like to have addressed in the Workshop.
 * What are your general expectations on the final outputs of the
 workshop
 * Optionally, what can be your potential contributions to the
 discussion, related ideas, suggested solutions. In the case of a
 well-defined technical contribution, this may be accompanied to
 the position paper as a separate paper, that may exceed the 5
 pages limit.
 
 Example topics:
 * The canonicalization of XML syntax; the canonicalization of
 XML/DOM or RDF semantics.
 * A schema definition (XML/RDF) or link type definition
 (XLink) that captures common semantics relevant to signed
 assertions about Web resources and their relationships.
 * Methods for processing composite/compound documents consisting of
 XML and non-XML data as well as for processing external signature
 blocks and assertions.
 * Reports of cryptographic implementations that are used to sign Web
 information today; reports of real world experiences in satisfying
 the business and legal requirements for binding agreements in
 digital form.
 * Requirements for digital signatures over international
 cryptographic and content formats.
 * Methods of achieving interoperability and extensibility over a
 variety encoding methods, algorithms and trust management systems.
 * Requirements for applying signed-XML to HTML, particularly to the
 HTML <HEAD> element so as to help alleviate problems of
 "header-spam" that results in biased or poor query results at
 search engines.
 * Survey of Web applications requiring signatures: XML-EDI, payment,
 P3P, workflow processing, etc.
 * The relationship of trust languages or logic to metadata (XML)
 query languages. (Trust and permissions questions might be
 represented as a query over structured permissions, see the recent
 Query Language Workshop.)
 
 Position papers must be sent via e-mail to the Workshop Chair
 ([email-masked]) by the March 29 1999. Allowed formats are HTML and
 ASCII. Good examples of position papers can be seen from the QL'98
 workshop.
 
 Position papers will be published on the public web pages (unless the
 author requests otherwise) and distributed as printed notes to all the
 participants. The Chair can ask the authors of particularly
 representative position papers to explicitly present their position at
 the workshop to foster discussion. In this case, the authors are also
 invited to make the slides of the presentation available on the
 workshop web site. Note that it is not required that every member or
 organization represented at the workshop submit a position paper.
 However, everyone is requested to submit some statement of their
 interest in the topic to the Workshop Chair.
 
 _________________________________________________________________
 
 Registration and Information to Expected Participants
 
 There will be a limit of 40 participants. ALL participants must
 register. More than two participants from any single organization is
 discouraged.
 
 There is no registration fee for W3C members. Others are required to
 pay a fee of $200 to help cover W3C's costs in running the workshop.
 The attendence limit may be exceeded or the fee may be waived at the
 discretion of the Workshop Chair for participants with compelling
 position papers. Registration is handled on a first-come first-served
 basis, so if you plan to attend the workshop please register as soon
 as possible. If you would like to attend the workshop, please fill out
 the registration form before March 29 1999. Registration is
 required! The payment can be made on-site at the workshop; accepted
 forms of payment are MasterCard, Visa, or a check in US dollars made
 payable to MIT/W3C. If you have trouble with these forms of payment,
 please contact the chair ([email-masked]).
 _________________________________________________________________
 
 Workshop Organization
 
 W3C Signed-XML Contact and Workshop Chair:
 
         Joseph M. Reagle Jr. (W3C)
 
         <[email-masked]> + 1.617.258.7621
         Massachusetts Institute of Technology
         Laboratory for Computer Science
         W3C, NE43-350
         545 Technology Square
         Cambridge, MA 02139 USA
 
 W3C Meeting Planner:
 
         Susan Hardy (W3C)
 
         Email: [email-masked]
         Tel.: +1 617 253 2613
         The World Wide Web Consortium
         MIT Lab for Computer Science
         545 Technology Square
         Cambridge MA 02139 USA
 
End Forwarded Text ----
_______________________     
Regards,          http://web.mit.edu/reagle/www/
Joseph Reagle     E0 D5 B2 05 B6 12 DA 65  BE 4D E3 C1 6A 66 25 4E
independent research account

------- End of Forwarded Message

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: ' 'Don Eastlake' ' <[email-masked]>,  'Chris Smith' <[email-masked]>
Cc: ' 'Ietf Trade WG' ' <[email-masked]>
Subject: RE: Support for HTML in packaged content.
Date: Thu, 25 Feb 1999 18:41:15 -0000
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

A few comments below.

David

>----------
>From: 	Smith, Chris[SMTP:[email-masked]]
>Sent: 	25 February 1999 09:39
>To: 	David Burdett; "'Don Eastlake'" 
>Cc: 	"'Ietf Trade WG'" 
>Subject: 	RE: Support for HTML in packaged content.
>
>
>The only minor quibble is that requiring the most important one to be 
>set to 'main'  potentially interferes with the relative references. It 
>makes it illegal to have a relative reference of the form <img 
>src="main"> because that would require a packaged content with the name 
>'main' - oops, see the problem? And, yes, you can get by without the 
>extensions - see below.
*** The whole idea is that the the packaged content with name="main"
should not be referred to by the HTML in any other packaged content
within the same parent element since it is effectively the "top level"
packaged content from which all others are derived.***
>
>I'd be more in favor of requiring that the initial one be <Name=""> - 
>that allows all relative references to have a name - and since any name 
>is different than no name, there are no collisions.
>
>There is an additional small problem. The packaged contents should 
>likely be marked as "MIME" or "MIME:something", since it isn't really 
>platform independent to determine types solely by file extension. The 
>proper way is always by using the MIME type - some sites function 
>without any extensions at all, and just report mime types. This is not 
>essential, though. As long as the refs are to names, they should be OK.
*** I agree that requiring all contents to be MIME is a good idea ...
I'll include it ***
>
>(As I see it, the likely implementation would be:
>    create a temporary directory or folder, and in it:
>    save Name=""    Content="HTML"  as H992543  (a temporary name)
>    save Name="one" Content="MIME:image/gif" as   one
>    start a browser or browse component pointing to H992543 
>
>Even without any extensions, this should work. I've done one simply test 
>so far.)
>
>There are still some oddities - it makes sense to warn implementors that 
>there should be no *required* external components. In addition, a really 
>conservative implementation would actually add the extensions, and 
>rewrite the HTML to include them. (It's a lot of work, but a really 
>friendly wallet might do it). Of course, such a wallet could also 
>eliminate or warn about external content. (Sounds like an opportunity 
>for differentiation....)
>
>In general, we should likely make some comment about references outside 
>the overall packaged content. I can see some holes where what is given 
>is HTML - with a <META> tag specifying Refresh, that takes the user's 
>browser off to somewhere completely different. If it's a clickable link, 
>then you really can't completely restrict it, because that is a 
>legitimate use - the Offer Response may include a definitive name for a 
>product, and include a link to detailed product specifications.
>
>Once inside the HTML, things like this will be very hard to restrict.
*** I agree so perhaps we recommend that software generates warnings ***
>
>
>
>______________________________ Reply Separator
>_________________________________
>Subject: RE: Support for HTML in packaged content.
>Author:  "David Burdett" [SMTP:[email-masked]] at Internet
>Date:    1999-02-25 04:39
>
>
>I've taken Don's comments on board and updated text is included below.
>
>David
>UPDATED TEXT
>============
>The packaged content may contain HTML. In this case the following 
>conventions are followed:
>*     references to any documents, images or other things, such as sounds or
>
>web pages, which can affect the recipient's understanding of the data
>which is being packaged must refer to other Packaged Elements contained 
>within the same parent element, e.g. an Order Description
>*     if more than one Packaged Content element is included within a parent 
>element in order to meet the previous requirement, then the Name
>attribute of the top level Packaged Content from which references to all 
>other Packaged Elements can be determined, should have a value of Main
>*     relative references to other documents, images, etc. from one Packaged
>
>Content element to another are realised by setting the value of the
>relative reference to the Name attribute of another Packaged Content 
>element at the same level and within the same parent element
>
>If the above conventions are not followed by, for example, including 
>external references, then the recipient of the HTML should be informed.
>
>[Note]     As an implementation guideline the values of the Name Attributes 
>allocated to Packaged Content elements should make it possible to
>extract each Packaged Content into a directory and then display the HTML 
>directly
>[Note End]
>
>
>>----------
>>From:      Donald E. Eastlake 3rd[SMTP:[email-masked]] 
>>Sent:      24 February 1999 13:32
>>To:      David Burdett
>>Cc:      'Ietf Trade WG'
>>Subject:      Re: Support for HTML in packaged content. 
>>
>>I think something like this is a good idea.  Sorry I forgot to mention it
>in 
>>my note about Florida.  See comments below.
>>
>>From:  David Burdett <[email-masked]> 
>>Message-ID:
>><c=GB%a=_%p=Mondex_Internati%l=[email-masked] 
>>ndex.com>
>>To:  "'Ietf Trade WG'" <[email-masked]> 
>>Date:  Tue, 23 Feb 1999 18:57:52 -0000
>>
>>>One of the suggestions which came out of the meeting in Florida, was the 
>>>support for HTML for use with Order Descriptions, Payment Notes and 
>>>Delivery Notes, particularly since the both Hitachi and RBC had used 
>>>HTML rather than Plain Text. It this therefore proposed that the 
>>>following is included in the spec.
>>>
>>>Comments?
>>>
>>>David
>>>Support for HTML in Packaged Content 
>>>============================
>>>The packaged content may contain HTML. In this case the following 
>>>conventions are followed:
>>>*     there should be only one top level Packaged Content element
>containing 
>> HTML
>>>with its Name attribute set to Main. This document should contain either 
>>>text, or references to images.
>>
>>While it is best for the main packaged content to have the name Main, if 
>>there is only one packaged content, the recevier should interpret that 
>>as the main one.
>>
>>The document should contain HTML and may have external references to 
>>images or other things (sounds, web pages).  But if those things 
>>effect what the user is agreeing to, then they must be in other 
>>packaged contents in the same component and referenced with relative 
>>URLs or the like.
>>
>>>*     images are incorporated in a document using links using relative 
>>>references of the form "img source=xxxx.gif" where "xxxx.gif" matches 
>>>the Name attribute of another Packaged Content element at the same level 
>>>and within the same parent element, e.g. an Order Description
>>
>>Well, .jpg should be acceptable also.  In fact, I'm not sure why we 
>>would want to police the suffixes.  The point is that it should be a 
>>workable implementation to write the other packaged contents out as 
>>temporary files and then run the HTML, with some safety checks, in 
>>the context of that directory.
>>
>>>*     no text should be included as images for any information which is 
>>>important to the user's understanding of the document, e.g. text in 
>>>logos would be allowable
>>
>>If the images are included locally in other packaged contents than the 
>>HTML, I don't see a need for this restrction.  And, in any case, there
>>is no way to automatically enfore it making it impossible to warn the user 
>>if it has been violated.
>>
>>>If the above conventions are not followed by, for example, including 
>>>external references, then the recipient of the HTML should be informed. 
>>
>>>>Mondex International Limited
>>>mailto:<[email-masked]>
>>>>US Advanced Technology Office: 111 Pine St, 6th Floor, San Francisco, CA 
>>>>94111
>>>Tel/Voicemail: +1 415 645 6973     Fax: +1 415 956 9370 
>>
>>Thanks,
>>Donald
>>
>>----------------------------------------------------------------------- 
>>Message addressed to: [email-masked]
>>Archive available at: http://www.elistx.com/archives/ietf-trade/
>>To (un)subscribe send a message with "subscribe" or "unsubscribe" in the 
>>body to: [email-masked]
>>
>----------------------------------------------------------------------- 
>Message addressed to: [email-masked]
>Archive available at: http://www.elistx.com/archives/ietf-trade/
>To (un)subscribe send a message with "subscribe" or "unsubscribe" in the 
>body to: [email-masked]
>
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: "Smith, Chris" <[email-masked]>
To: 'Don Eastlake' <[email-masked]>,  David Burdett <[email-masked]>
Cc: 'Ietf Trade WG' <[email-masked]>
Subject: RE: Support for HTML in packaged content.
Date: Thu, 25 Feb 1999 12:39:00 -0500
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

The only minor quibble is that requiring the most important one to be 
set to 'main'  potentially interferes with the relative references. It 
makes it illegal to have a relative reference of the form <img 
src="main"> because that would require a packaged content with the name 
'main' - oops, see the problem? And, yes, you can get by without the 
extensions - see below.

I'd be more in favor of requiring that the initial one be <Name=""> - 
that allows all relative references to have a name - and since any name 
is different than no name, there are no collisions.

There is an additional small problem. The packaged contents should 
likely be marked as "MIME" or "MIME:something", since it isn't really 
platform independent to determine types solely by file extension. The 
proper way is always by using the MIME type - some sites function 
without any extensions at all, and just report mime types. This is not 
essential, though. As long as the refs are to names, they should be OK.

(As I see it, the likely implementation would be:
    create a temporary directory or folder, and in it:
    save Name=""    Content="HTML"  as H992543  (a temporary name)
    save Name="one" Content="MIME:image/gif" as   one
    start a browser or browse component pointing to H992543 

Even without any extensions, this should work. I've done one simply test 
so far.)

There are still some oddities - it makes sense to warn implementors that 
there should be no *required* external components. In addition, a really 
conservative implementation would actually add the extensions, and 
rewrite the HTML to include them. (It's a lot of work, but a really 
friendly wallet might do it). Of course, such a wallet could also 
eliminate or warn about external content. (Sounds like an opportunity 
for differentiation....)

In general, we should likely make some comment about references outside 
the overall packaged content. I can see some holes where what is given 
is HTML - with a <META> tag specifying Refresh, that takes the user's 
browser off to somewhere completely different. If it's a clickable link, 
then you really can't completely restrict it, because that is a 
legitimate use - the Offer Response may include a definitive name for a 
product, and include a link to detailed product specifications.

Once inside the HTML, things like this will be very hard to restrict.

______________________________ Reply Separator
_________________________________
Subject: RE: Support for HTML in packaged content.
Author:  "David Burdett" [SMTP:[email-masked]] at Internet
Date:    1999-02-25 04:39

I've taken Don's comments on board and updated text is included below.

David
UPDATED TEXT
============
The packaged content may contain HTML. In this case the following 
conventions are followed:
*     references to any documents, images or other things, such as sounds or

web pages, which can affect the recipient's understanding of the data
which is being packaged must refer to other Packaged Elements contained 
within the same parent element, e.g. an Order Description
*     if more than one Packaged Content element is included within a parent 
element in order to meet the previous requirement, then the Name
attribute of the top level Packaged Content from which references to all 
other Packaged Elements can be determined, should have a value of Main
*     relative references to other documents, images, etc. from one Packaged

Content element to another are realised by setting the value of the
relative reference to the Name attribute of another Packaged Content 
element at the same level and within the same parent element

If the above conventions are not followed by, for example, including 
external references, then the recipient of the HTML should be informed.

[Note]     As an implementation guideline the values of the Name Attributes 
allocated to Packaged Content elements should make it possible to
extract each Packaged Content into a directory and then display the HTML 
directly
[Note End]

>----------
>From:      Donald E. Eastlake 3rd[SMTP:[email-masked]] 
>Sent:      24 February 1999 13:32
>To:      David Burdett
>Cc:      'Ietf Trade WG'
>Subject:      Re: Support for HTML in packaged content. 
>
>I think something like this is a good idea.  Sorry I forgot to mention it
in 
>my note about Florida.  See comments below.
>
>From:  David Burdett <[email-masked]> 
>Message-ID:
><c=GB%a=_%p=Mondex_Internati%l=[email-masked] 
>ndex.com>
>To:  "'Ietf Trade WG'" <[email-masked]> 
>Date:  Tue, 23 Feb 1999 18:57:52 -0000
>
>>One of the suggestions which came out of the meeting in Florida, was the 
>>support for HTML for use with Order Descriptions, Payment Notes and 
>>Delivery Notes, particularly since the both Hitachi and RBC had used 
>>HTML rather than Plain Text. It this therefore proposed that the 
>>following is included in the spec.
>>
>>Comments?
>>
>>David
>>Support for HTML in Packaged Content 
>>============================
>>The packaged content may contain HTML. In this case the following 
>>conventions are followed:
>>*     there should be only one top level Packaged Content element
containing 
> HTML
>>with its Name attribute set to Main. This document should contain either 
>>text, or references to images.
>
>While it is best for the main packaged content to have the name Main, if 
>there is only one packaged content, the recevier should interpret that 
>as the main one.
>
>The document should contain HTML and may have external references to 
>images or other things (sounds, web pages).  But if those things 
>effect what the user is agreeing to, then they must be in other 
>packaged contents in the same component and referenced with relative 
>URLs or the like.
>
>>*     images are incorporated in a document using links using relative 
>>references of the form "img source=xxxx.gif" where "xxxx.gif" matches 
>>the Name attribute of another Packaged Content element at the same level 
>>and within the same parent element, e.g. an Order Description
>
>Well, .jpg should be acceptable also.  In fact, I'm not sure why we 
>would want to police the suffixes.  The point is that it should be a 
>workable implementation to write the other packaged contents out as 
>temporary files and then run the HTML, with some safety checks, in 
>the context of that directory.
>
>>*     no text should be included as images for any information which is 
>>important to the user's understanding of the document, e.g. text in 
>>logos would be allowable
>
>If the images are included locally in other packaged contents than the 
>HTML, I don't see a need for this restrction.  And, in any case, there
>is no way to automatically enfore it making it impossible to warn the user 
>if it has been violated.
>
>>If the above conventions are not followed by, for example, including 
>>external references, then the recipient of the HTML should be informed. 
>
>>>Mondex International Limited
>>mailto:<[email-masked]>
>>>US Advanced Technology Office: 111 Pine St, 6th Floor, San Francisco, CA 
>>>94111
>>Tel/Voicemail: +1 415 645 6973     Fax: +1 415 956 9370 
>
>Thanks,
>Donald
>
>----------------------------------------------------------------------- 
>Message addressed to: [email-masked]
>Archive available at: http://www.elistx.com/archives/ietf-trade/
>To (un)subscribe send a message with "subscribe" or "unsubscribe" in the 
>body to: [email-masked]
>
----------------------------------------------------------------------- 
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the 
body to: [email-masked]
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: 'Ietf Trade WG' <[email-masked]>
Subject: RE: IOTP Digital Signatures and authentication
Date: Thu, 25 Feb 1999 16:38:21 -0000
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

There is a need for authentication to make use of digital signatures.
Therefore I propose that we add a Algorithm elements to the AuthData
component. The AuthData component now looks like:

<!ELEMENT AuthData (PackagedContent+, Algorithm+)>
<!ATTLIST AuthData
 ID                 ID      #REQUIRED
 AuthenticationId   CDATA   #REQUIRED
 TradingRoleList    NMTOKEN #IMPLIED
 AlgorithmRefs      IDREFS  #REQUIRED
 ContentSoftwareId  CDATA   #IMPLIED >

The Algorithm element is the same element as is used in Digital
signatures. The AlgorithmRefs attribute lists the element references of
the Algorithms from which the recipient of the AuthData component can
make a selection to use when generating the response. This means that
the Authentication Response Component now looks like:

<!ELEMENT AuthResp (PackagedContent*) >
<!ATTLIST AuthResp
 ID                 ID      #REQUIRED
 SelectedAlgorithmRef NMTOKEN #REQUIRED
 ContentSoftwareId  CDATA   #IMPLIED >

The Selected AlgorithmRef now points to the Algorithm that was selected
by the receipient of the Authentication Request.

If the Algorithm is a standard one used when generating a Signature then
the result of the Authentication is a Signature Component and the
Packaged Content is omitted. Alternatively, if the authentication is
none-standard, for example using an authentication method associated
with a particular payment method, then there is no signature Component
in the response and instead the result is recorded in the Packagted
Content.

Thoughts?

David

>----------
>From: 	David Burdett
>Sent: 	24 February 1999 12:13
>To: 	'Ietf Trade WG'
>Subject: 	IOTP Digital Signatures - more changes
>
>Further to my last e-mail a couple of additional problems have been
>identified which I think need to be fixed:
>*	including a separate IOTP Signature Type element doesn't seem to make
>sens it is really just a particular mandatory attribute with a required
>value, so suggest removing IOTPSignatureType element and replacing by a
>normal "Attribute" element with a type attribute set to "IOTP
>SignatureType" and the content set to OfferResponse, PaymentResponse, or
>DeliveryResponse, Ping or AuthenticationResponse
>*	there is no explicit way of identifying which certificate should be
>used with a particular signature value. I therefore propose that we add
>to the RecipientInfo element another attribute called SignatureCertRef
>that identifies the Certificate Element that applies.
>
>David
>>Mondex International Limited
>mailto:<[email-masked]>
>>US Advanced Technology Office: 111 Pine St, 6th Floor, San Francisco, CA
>>94111
>Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
>
>-----------------------------------------------------------------------
>Message addressed to: [email-masked]
>Archive available at: http://www.elistx.com/archives/ietf-trade/
>To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
>body to: [email-masked]
>
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  'Andrew Drapp' <[email-masked]>
Subject: RE: Authentication
Date: Thu, 25 Feb 1999 16:32:15 -0000
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Authentication can be done by the Consumer, Payment Handler or Delivery
Handler.

Effectively the Consumer, Payment Handler or Delivery Handler does a
stand-alone authentication transaction after interrupting whatever other
transaction is going on and then restarts the original transaction and
finishes it if the authentication was OK and cancels it if it was not.

I agree though that the specification is specifically state that this is
possible and I will add some further explanation.

David

>----------
>From: 	Andrew Drapp[SMTP:[email-masked]]
>Sent: 	24 February 1999 22:22
>To: 	[email-masked]'
>Subject: 	Authentication
>
>
>I've been going over chapter 8 in the 1.0.1 version of the
>spec and I have a couple of comments.
>
>From reading the document, it appears that Authentication can
>only be performed by the Merchant, authenticating the consumer.
>Each of the examples seems to support that conclusion.
>
>From discussions in Tokyo and Ft. Lauderdale, it was generally
>decided that Authentication could be done at any time, and by
>any party.  Can we add something to the spec to make that a 
>little bit more clear? 
>
>Also, it would be nice if we added the following examples:
>
>1.  Consumer authenticates payment handler before starting the
>payment exchange.
>
>2.  Payment handler authenticates the consumer during the 
>payment exchange.
>
>Regards,
>
>Andrew Drapp
>
>--
>Andrew Drapp
>[email-masked]
>Systems Development Laboratory, Hitachi Ltd.
>Ozenji 1099, Asao, Kawasaki, 215-0013 JAPAN
>TEL:+81-44-966-9111   FAX:+81-44-966-1796
>PGP Fingerprint: 84D8 3D19 018E 9385 6581  0081 C89C D2AD F06A 565F
>
>-----------------------------------------------------------------------
>Message addressed to: [email-masked]
>Archive available at: http://www.elistx.com/archives/ietf-trade/
>To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
>body to: [email-masked]
>
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: [email-masked]
To: David Burdett <[email-masked]>
cc: 'Ietf Trade WG' <[email-masked]>
Date: Thu, 25 Feb 1999 11:12:04 -0500
Subject: RE: Support for HTML in packaged content.
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Looks good to me.

Thanks,
Donald

Donald E. Eastlake, 3rd
17 Skyline Drive, Hawthorne, NY 10532 USA
[email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833
Notes: Donald Eastlake/Hawthorne/IBM@IBMUS

home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
[email-masked]   tel: 1-914-276-2668

David Burdett <[email-masked]> on 02/25/99 04:39:23 AM

To:   "'Don Eastlake'" <[email-masked]>
cc:   "'Ietf Trade WG'" <[email-masked]> (bcc: Donald
      Eastlake/Hawthorne/IBM)
Subject:  RE: Support for HTML in packaged content.

I've taken Don's comments on board and updated text is included below.

David
UPDATED TEXT
============
The packaged content may contain HTML. In this case the following
conventions are followed:
*    references to any documents, images or other things, such as sounds or
web pages, which can affect the recipient's understanding of the data
which is being packaged must refer to other Packaged Elements contained
within the same parent element, e.g. an Order Description
*    if more than one Packaged Content element is included within a parent
element in order to meet the previous requirement, then the Name
attribute of the top level Packaged Content from which references to all
other Packaged Elements can be determined, should have a value of Main
*    relative references to other documents, images, etc. from one Packaged
Content element to another are realised by setting the value of the
relative reference to the Name attribute of another Packaged Content
element at the same level and within the same parent element

If the above conventions are not followed by, for example, including
external references, then the recipient of the HTML should be informed.

[Note]    As an implementation guideline the values of the Name Attributes
allocated to Packaged Content elements should make it possible to
extract each Packaged Content into a directory and then display the HTML
directly
[Note End]

>----------
>From:    Donald E. Eastlake 3rd[SMTP:[email-masked]]
>Sent:    24 February 1999 13:32
>To:      David Burdett
>Cc:      'Ietf Trade WG'
>Subject:      Re: Support for HTML in packaged content.
>
>I think something like this is a good idea.  Sorry I forgot to mention it
in
>my note about Florida.  See comments below.
>
>From:  David Burdett <[email-masked]>
>Message-ID:
><c=GB%a=_%p=Mondex_Internati%l=[email-masked]
>ndex.com>
>To:  "'Ietf Trade WG'" <[email-masked]>
>Date:  Tue, 23 Feb 1999 18:57:52 -0000
>
>>One of the suggestions which came out of the meeting in Florida, was the
>>support for HTML for use with Order Descriptions, Payment Notes and
>>Delivery Notes, particularly since the both Hitachi and RBC had used
>>HTML rather than Plain Text. It this therefore proposed that the
>>following is included in the spec.
>>
>>Comments?
>>
>>David
>>Support for HTML in Packaged Content
>>============================
>>The packaged content may contain HTML. In this case the following
>>conventions are followed:
>>*  there should be only one top level Packaged Content element containing
> HTML
>>with its Name attribute set to Main. This document should contain either
>>text, or references to images.
>
>While it is best for the main packaged content to have the name Main, if
>there is only one packaged content, the recevier should interpret that
>as the main one.
>
>The document should contain HTML and may have external references to
>images or other things (sounds, web pages).  But if those things
>effect what the user is agreeing to, then they must be in other
>packaged contents in the same component and referenced with relative
>URLs or the like.
>
>>*  images are incorporated in a document using links using relative
>>references of the form "img source=xxxx.gif" where "xxxx.gif" matches
>>the Name attribute of another Packaged Content element at the same level
>>and within the same parent element, e.g. an Order Description
>
>Well, .jpg should be acceptable also.  In fact, I'm not sure why we
>would want to police the suffixes.  The point is that it should be a
>workable implementation to write the other packaged contents out as
>temporary files and then run the HTML, with some safety checks, in
>the context of that directory.
>
>>*  no text should be included as images for any information which is
>>important to the user's understanding of the document, e.g. text in
>>logos would be allowable
>
>If the images are included locally in other packaged contents than the
>HTML, I don't see a need for this restrction.  And, in any case, there
>is no way to automatically enfore it making it impossible to warn the user
>if it has been violated.
>
>>If the above conventions are not followed by, for example, including
>>external references, then the recipient of the HTML should be informed.
>
>>>Mondex International Limited
>>mailto:<[email-masked]>
>>>US Advanced Technology Office: 111 Pine St, 6th Floor, San Francisco, CA
>>>94111
>>Tel/Voicemail: +1 415 645 6973   Fax: +1 415 956 9370
>
>Thanks,
>Donald
>
>-----------------------------------------------------------------------
>Message addressed to: [email-masked]
>Archive available at: http://www.elistx.com/archives/ietf-trade/
>To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
>body to: [email-masked]
>
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: 'Don Eastlake' <[email-masked]>
Cc: 'Ietf Trade WG' <[email-masked]>
Subject: RE: Support for HTML in packaged content. 
Date: Thu, 25 Feb 1999 09:39:23 -0000
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I've taken Don's comments on board and updated text is included below.

David
UPDATED TEXT
============
The packaged content may contain HTML. In this case the following
conventions are followed:
*	references to any documents, images or other things, such as sounds or
web pages, which can affect the recipient's understanding of the data
which is being packaged must refer to other Packaged Elements contained
within the same parent element, e.g. an Order Description
*	if more than one Packaged Content element is included within a parent
element in order to meet the previous requirement, then the Name
attribute of the top level Packaged Content from which references to all
other Packaged Elements can be determined, should have a value of Main
*	relative references to other documents, images, etc. from one Packaged
Content element to another are realised by setting the value of the
relative reference to the Name attribute of another Packaged Content
element at the same level and within the same parent element

If the above conventions are not followed by, for example, including
external references, then the recipient of the HTML should be informed.

[Note]	As an implementation guideline the values of the Name Attributes
allocated to Packaged Content elements should make it possible to
extract each Packaged Content into a directory and then display the HTML
directly
[Note End]	 

>----------
>From: 	Donald E. Eastlake 3rd[SMTP:[email-masked]]
>Sent: 	24 February 1999 13:32
>To: 	David Burdett
>Cc: 	'Ietf Trade WG'
>Subject: 	Re: Support for HTML in packaged content. 
>
>I think something like this is a good idea.  Sorry I forgot to mention it in
>my note about Florida.  See comments below.
>
>From:  David Burdett <[email-masked]>
>Message-ID:
><c=GB%a=_%p=Mondex_Internati%l=[email-masked]
>ndex.com>
>To:  "'Ietf Trade WG'" <[email-masked]>
>Date:  Tue, 23 Feb 1999 18:57:52 -0000
>
>>One of the suggestions which came out of the meeting in Florida, was the
>>support for HTML for use with Order Descriptions, Payment Notes and
>>Delivery Notes, particularly since the both Hitachi and RBC had used
>>HTML rather than Plain Text. It this therefore proposed that the
>>following is included in the spec.
>>
>>Comments?
>>
>>David
>>Support for HTML in Packaged Content
>>============================
>>The packaged content may contain HTML. In this case the following
>>conventions are followed:
>>*	there should be only one top level Packaged Content element containing
> HTML
>>with its Name attribute set to Main. This document should contain either
>>text, or references to images.
>
>While it is best for the main packaged content to have the name Main, if
>there is only one packaged content, the recevier should interpret that
>as the main one.
>
>The document should contain HTML and may have external references to
>images or other things (sounds, web pages).  But if those things
>effect what the user is agreeing to, then they must be in other
>packaged contents in the same component and referenced with relative
>URLs or the like.
>
>>*	images are incorporated in a document using links using relative
>>references of the form "img source=xxxx.gif" where "xxxx.gif" matches
>>the Name attribute of another Packaged Content element at the same level
>>and within the same parent element, e.g. an Order Description
>
>Well, .jpg should be acceptable also.  In fact, I'm not sure why we
>would want to police the suffixes.  The point is that it should be a 
>workable implementation to write the other packaged contents out as
>temporary files and then run the HTML, with some safety checks, in
>the context of that directory.
>
>>*	no text should be included as images for any information which is
>>important to the user's understanding of the document, e.g. text in
>>logos would be allowable 
>
>If the images are included locally in other packaged contents than the
>HTML, I don't see a need for this restrction.  And, in any case, there
>is no way to automatically enfore it making it impossible to warn the user
>if it has been violated.
>
>>If the above conventions are not followed by, for example, including
>>external references, then the recipient of the HTML should be informed.
>
>>>Mondex International Limited
>>mailto:<[email-masked]>
>>>US Advanced Technology Office: 111 Pine St, 6th Floor, San Francisco, CA
>>>94111
>>Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
>
>Thanks,
>Donald
>
>-----------------------------------------------------------------------
>Message addressed to: [email-masked]
>Archive available at: http://www.elistx.com/archives/ietf-trade/
>To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
>body to: [email-masked]
>
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: Andrew Drapp <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Authentication
Date: Thu, 25 Feb 1999 15:22:11 +0900
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I've been going over chapter 8 in the 1.0.1 version of the
spec and I have a couple of comments.

>From reading the document, it appears that Authentication can
only be performed by the Merchant, authenticating the consumer.
Each of the examples seems to support that conclusion.

>From discussions in Tokyo and Ft. Lauderdale, it was generally
decided that Authentication could be done at any time, and by
any party.  Can we add something to the spec to make that a 
little bit more clear? 

Also, it would be nice if we added the following examples:

1.  Consumer authenticates payment handler before starting the
payment exchange.

2.  Payment handler authenticates the consumer during the 
payment exchange.

Regards,

Andrew Drapp

--
Andrew Drapp
[email-masked]
Systems Development Laboratory, Hitachi Ltd.
Ozenji 1099, Asao, Kawasaki, 215-0013 JAPAN
TEL:+81-44-966-9111   FAX:+81-44-966-1796
PGP Fingerprint: 84D8 3D19 018E 9385 6581  0081 C89C D2AD F06A 565F

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: David Burdett <[email-masked]>
cc: 'Ietf Trade WG' <[email-masked]>
Subject: Re: Support for HTML in packaged content. 
Date: Wed, 24 Feb 1999 16:32:34 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I think something like this is a good idea.  Sorry I forgot to mention it in
my note about Florida.  See comments below.

From:  David Burdett <[email-masked]>
Message-ID:  <c=GB%a=_%p=Mondex_Internati%l=[email-masked]
ndex.com>
To:  "'Ietf Trade WG'" <[email-masked]>
Date:  Tue, 23 Feb 1999 18:57:52 -0000

>One of the suggestions which came out of the meeting in Florida, was the
>support for HTML for use with Order Descriptions, Payment Notes and
>Delivery Notes, particularly since the both Hitachi and RBC had used
>HTML rather than Plain Text. It this therefore proposed that the
>following is included in the spec.
>
>Comments?
>
>David
>Support for HTML in Packaged Content
>============================
>The packaged content may contain HTML. In this case the following
>conventions are followed:
>*	there should be only one top level Packaged Content element containing
 HTML
>with its Name attribute set to Main. This document should contain either
>text, or references to images.

While it is best for the main packaged content to have the name Main, if
there is only one packaged content, the recevier should interpret that
as the main one.

The document should contain HTML and may have external references to
images or other things (sounds, web pages).  But if those things
effect what the user is agreeing to, then they must be in other
packaged contents in the same component and referenced with relative
URLs or the like.

>*	images are incorporated in a document using links using relative
>references of the form "img source=xxxx.gif" where "xxxx.gif" matches
>the Name attribute of another Packaged Content element at the same level
>and within the same parent element, e.g. an Order Description

Well, .jpg should be acceptable also.  In fact, I'm not sure why we
would want to police the suffixes.  The point is that it should be a 
workable implementation to write the other packaged contents out as
temporary files and then run the HTML, with some safety checks, in
the context of that directory.

>*	no text should be included as images for any information which is
>important to the user's understanding of the document, e.g. text in
>logos would be allowable 

If the images are included locally in other packaged contents than the
HTML, I don't see a need for this restrction.  And, in any case, there
is no way to automatically enfore it making it impossible to warn the user
if it has been violated.

>If the above conventions are not followed by, for example, including
>external references, then the recipient of the HTML should be informed.

>>Mondex International Limited
>mailto:<[email-masked]>
>>US Advanced Technology Office: 111 Pine St, 6th Floor, San Francisco, CA
>>94111
>Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370

Thanks,
Donald

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: David Burdett <[email-masked]>
cc: 'Ietf Trade WG' <[email-masked]>
Subject: Re: IOTP Digital Signatures - more changes 
Date: Wed, 24 Feb 1999 16:04:18 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

These seem like reasonable changes although the SignatureCertRef must be
optional since certificates are not relevant to all signatures.

Thanks,
Donald

From:  David Burdett <[email-masked]>
Message-ID:  <c=GB%a=_%p=Mondex_Internati%l=[email-masked]
ndex.com>
To:  "'Ietf Trade WG'" <[email-masked]>
Date:  Wed, 24 Feb 1999 20:13:44 -0000

>Further to my last e-mail a couple of additional problems have been
>identified which I think need to be fixed:
>*	including a separate IOTP Signature Type element doesn't seem to make
>sens it is really just a particular mandatory attribute with a required
>value, so suggest removing IOTPSignatureType element and replacing by a
>normal "Attribute" element with a type attribute set to "IOTP
>SignatureType" and the content set to OfferResponse, PaymentResponse, or
>DeliveryResponse, Ping or AuthenticationResponse
>*	there is no explicit way of identifying which certificate should be
>used with a particular signature value. I therefore propose that we add
>to the RecipientInfo element another attribute called SignatureCertRef
>that identifies the Certificate Element that applies.
>
>David
>>Mondex International Limited
>mailto:<[email-masked]>
>>US Advanced Technology Office: 111 Pine St, 6th Floor, San Francisco, CA
>>94111
>Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370
>
>-----------------------------------------------------------------------
>Message addressed to: [email-masked]
>Archive available at: http://www.elistx.com/archives/ietf-trade/
>To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
>body to: [email-masked]
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: 'Ietf Trade WG' <[email-masked]>
Subject: IOTP Digital Signatures - more changes
Date: Wed, 24 Feb 1999 20:13:44 -0000
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Further to my last e-mail a couple of additional problems have been
identified which I think need to be fixed:
*	including a separate IOTP Signature Type element doesn't seem to make
sens it is really just a particular mandatory attribute with a required
value, so suggest removing IOTPSignatureType element and replacing by a
normal "Attribute" element with a type attribute set to "IOTP
SignatureType" and the content set to OfferResponse, PaymentResponse, or
DeliveryResponse, Ping or AuthenticationResponse
*	there is no explicit way of identifying which certificate should be
used with a particular signature value. I therefore propose that we add
to the RecipientInfo element another attribute called SignatureCertRef
that identifies the Certificate Element that applies.

David
>Mondex International Limited
mailto:<[email-masked]>
>US Advanced Technology Office: 111 Pine St, 6th Floor, San Francisco, CA
>94111
Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  'Ietf Trade WG' <[email-masked]>
Subject: RE: Signature DTD
Date: Wed, 24 Feb 1999 13:30:57 -0000
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

I've reviewed Don's version of the dsig DTD and spotted a few problems.
So I've revised the DTD and included the revisions and details of the
changes made below. If anybody can spot any more problems please let me
know.

David
REVISED IOTP/DSIG DTD
=====================
Changes:
- added optional ID attributes to IOTPSignatures, Signature and
Certicicate elemens to conform with IOTP requirement for blocks and
componenents to have ID attributes so that they can be referenced
- added #REQUIRED to a number of elements: Algorithm/ID,
Digest/LocatorHREF, Digest/DigestAlgorithmRef
- removed 'false' from Attribute/critical, and 'none' from
Value/encoding as invalid XML
- made IOTPSignatureType element optional as this will allow Signature
definition to potentially be reused
- changed IOTPSignatureType/SigType allowable values to NMTOKEN and will
enumerate valid values in the IOTP specification to allow extensibility
to new types of IOTP signatures
- Changed OriginatorInfo/OriginatorRef from NMTOKENS to NMTOKEN as there
can only be one originator
- Changed RecipientInfo/RecipientRef to 'RecipientRefs' as there may be
more than one recipient
- moved Alghorithm/Id to first attribute of Algorithm element
- added Locator element definition as it was missing

<!--
******************************************************
* IOTP SIGNATURES BLOCK DEFINITION                   *
******************************************************
 -->

<!ELEMENT IOTPSignatures (Signature+, Certificate*) >
<!ATTLIST IOTPSignatures
  ID                ID      #IMPLIED >

<!--
******************************************************
* IOTP SIGNAUTRE COMPPONENT DEFINITION               *
******************************************************
 -->

<!ELEMENT Signature (Manifest, Value+) >
<!ATTLIST Signature
  ID                ID      #IMPLIED >

<!ELEMENT Manifest 
  (Algorithm+,
   Digest+,
   Attributes?,
   OriginatorInfo,
   RecipientInfo+,
  )
<!ATTLIST Manifest
  LocatorHRefBase   CDATA   #IMPLIED >

<!ELEMENT Algorithm (Parameter*) >
<!ATTRLIST Algorithm
 ID                 ID      #REQUIRED
 type  (digest|signature|keyagreement) #IMPLIED
 name               NMTOKEN #REQUIRED >

<!ELEMENT Digest (Value) >
<!ATTLIST Digest
 LocatorHREF        NMTOKEN #REQUIRED
 DigestAlgorithmRef IDREF   #REQUIRED >

<!ELEMENT Attributes (Attribute+) >

<!ELEMENT Attribute ( #PCDATA, IOTPSignatureType? ) >
<!ATTLIST Attribute
 type               NMTOKEN #REQUIRED
 critical  ( true | false ) #REQUIRED >

<!ELEMENT IOTPSignatureType EMPTY >
<!ATTLIST IOTPSignatureType
 SigType            NMTOKEN #REQUIRED >

<!ELEMENT OriginatorInfo ANY >
<!ATTLIST OriginatorInfo
 OriginatorRef      NMTOKEN #IMPLIED >

<!ELEMENT RecipientInfo ANY >
<!ATTLIST RecipientInfo
 SignatureAlgorithmRef IDREF #REQUIRED
 SignatureValueRef  IDREF    #REQUIRED
 RecipientRefs      NMTOKENS #IMPLIED >

<!ELEMENT Parameter ANY >
<!ATTLIST Parameter
 type               PCDATA  #REQUIRED >

<!ELEMENT Certificate (
  IssuerAndSerialNumber 
  ( Value | Locator ) )>
<!ATTLIST Certificate
 type               NMTOKEN #REQUIRED >

<!ELEMENT IssuerAndSerialNumber EMPTY >
<!ATTLIST IssuerAndSerialNumber
 issuer             CDATA   #REQUIRED
 number             CDATA   #REQUIRED >

<!ELEMENT Value ( #PCDATA ) >
<!ATTLIST Value
 id                 ID      #IMPLIED
 encoding ( base64 | none ) #REQUIRED >

<!ELEMENT Locator EMPTY>
<!ATTLIST Locator
 href               CDATA   #REQUIRED >

>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	23 February 1999 12:17
>To: 	[email-masked]
>Subject: 	Signature DTD
>
>Here is the result of a pass over the material the Kent Davidson provided.
>I have re-instituted Value with an optional ID and elminated the namespace
>stuff, etc.  In order to get drafts in by the deadline, which is this week,
>I don't think we have time for any significant further changes.
>
><!ELEMENT IOTPSignatures (Signature+,Certificate*)>
>    <!ELEMENT Signature (Manifest, Value+) >
>        <!ELEMENT Manifest (
>            Algorithm+,
>            Digest+,
>            Attributes?,
>            OriginatorInfo,
>            RecipientInfo+,
>        )
>        <!ATTLIST Manifest
>            LocatorHRefBase     CDATA          #IMPLIED
>        >
>            <!ELEMENT Algorithm (Parameter*)>
>            <!ATTRLIST Algorithm
>                type            (digest|signature|keyagreement)   #IMPLIED
>                name            NMTOKEN                         #REQUIRED
>                ID              ID
>            >
>            <!ELEMENT Digest (Value)>
>            <!ATTLIST Digest
>                LocatorHREF         NMTOKEN
>                DigestAlgorithmRef  IDREF
>            >
>            <!ELEMENT Attributes (Attribute+)>
>            <!ELEMENT Attribute ( #PCDATA, IOTPSignatureType )>
>            <!ATTLIST Attribute
>                type          NMTOKEN     #REQUIRED
>                critical ( true | false ) #REQUIRED    'false'
>            >
>            <!ELEMENT IOTPSignatureType EMPTY>
>            <!ATTLIST IOTPSignatureType
>                SigType (Other|Payment|Delivery)    #REQUIRED
>            <!ELEMENT OriginatorInfo ANY>
>            <!ATTLIST OriginatorInfo
>                OriginatorRef           NMTOKENS    #IMPLIED
>            >
>            <!ELEMENT RecipientInfo ANY>
>            <!ATTLIST RecipientInfo
>                SignatureAlgorithmRef   IDREF       #REQUIRED
>                SignatureValueRef       IDREF       #REQUIRED
>                RecipientRef            NMTOKENS    #IMPLIED
>            >
>            <!ELEMENT Parameter ANY>
>            <!ATTLIST Parameter
>                type          PCDATA    #REQUIRED
>            >
>            <!ELEMENT Certificate (
>                IssuerAndSerialNumber,
>                ( Value | Locator )
>            )>
>            <!ATTLIST Certificate
>                type          NMTOKEN    #REQUIRED
>            >
>            <!ELEMENT IssuerAndSerialNumber EMPTY >
>            <!ATTLIST IssuerAndSerialNumber
>                issuer        CDATA    #REQUIRED
>                number        CDATA    #REQUIRED
>            >
>            <!ELEMENT Value ( #PCDATA )>
>            <!ATTLIST Value
>                id            ID       #IMPLIED
>                encoding ( base64 | none ) #REQUIRED 'none'
>            >
>
>Algorithm type='digest' (all mandatory to implement):
>- "urn:ibm:dom-hash"
>- "urn:fips:sha1"
>- "urn:rsa:md5"
>
>ParameterType="AlgorithmRef"
>
>Algorithms type='signature' (dsa & hmac mandatory to implment, rsa
>recommended):
>- "urn:us.gov:dsa"
>- "urn:ibm:hmac"
>- "urn:rsa:rsa"
>
>e.g.
><Algorithm ID=A1 type="digest" name="urn:ibm:dom-hash">
>    <Parameter type='AlgorithmRef'>A2</Parameter>
></Algorithm>
><Algorithm ID=A2 type="digest" name="urn:fips:sha1">
></Algorithm>
><Algorithm ID=A3 type="signature" name="urn:ibm:hmac">
>    <Parameter type='AlgorithmRef'>A1</Parameter>
></Algorithm>
>
>TODO:
>- Parameters within all algorithms to point to "sub" algorithms
>- Other parameters specific to digest and signature algorithms
>
>990210
>------
>Discussions:
>- Moving all algorithms to one place
>- Having multiple signatures for multiple recipients
>- Cases sensitivity of example above where 'case-sensitive' ID=A2 and
><Param>a2</Param>
>    may be parsed by different parts of the application.
>- Some wants algorithm references to be an IDREFs attribute within
>Algorithm
>
>
>Donald E. Eastlake, 3rd
>17 Skyline Drive, Hawthorne, NY 10532 USA
>[email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833
>Notes: Donald Eastlake/Hawthorne/IBM@IBMUS
>
>home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
>[email-masked]   tel: 1-914-276-2668
>
>
>-----------------------------------------------------------------------
>Message addressed to: [email-masked]
>Archive available at: http://www.elistx.com/archives/ietf-trade/
>To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
>body to: [email-masked]
>
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: [email-masked]
To: [email-masked]
Date: Tue, 23 Feb 1999 15:17:13 -0500
Subject: Signature DTD
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Here is the result of a pass over the material the Kent Davidson provided.
I have re-instituted Value with an optional ID and elminated the namespace
stuff, etc.  In order to get drafts in by the deadline, which is this week,
I don't think we have time for any significant further changes.

<!ELEMENT IOTPSignatures (Signature+,Certificate*)>
    <!ELEMENT Signature (Manifest, Value+) >
        <!ELEMENT Manifest (
            Algorithm+,
            Digest+,
            Attributes?,
            OriginatorInfo,
            RecipientInfo+,
        )
        <!ATTLIST Manifest
            LocatorHRefBase     CDATA          #IMPLIED
        >
            <!ELEMENT Algorithm (Parameter*)>
            <!ATTRLIST Algorithm
                type            (digest|signature|keyagreement)   #IMPLIED
                name            NMTOKEN                         #REQUIRED
                ID              ID
            >
            <!ELEMENT Digest (Value)>
            <!ATTLIST Digest
                LocatorHREF         NMTOKEN
                DigestAlgorithmRef  IDREF
            >
            <!ELEMENT Attributes (Attribute+)>
            <!ELEMENT Attribute ( #PCDATA, IOTPSignatureType )>
            <!ATTLIST Attribute
                type          NMTOKEN     #REQUIRED
                critical ( true | false ) #REQUIRED    'false'
            >
            <!ELEMENT IOTPSignatureType EMPTY>
            <!ATTLIST IOTPSignatureType
                SigType (Other|Payment|Delivery)    #REQUIRED
            <!ELEMENT OriginatorInfo ANY>
            <!ATTLIST OriginatorInfo
                OriginatorRef           NMTOKENS    #IMPLIED
            >
            <!ELEMENT RecipientInfo ANY>
            <!ATTLIST RecipientInfo
                SignatureAlgorithmRef   IDREF       #REQUIRED
                SignatureValueRef       IDREF       #REQUIRED
                RecipientRef            NMTOKENS    #IMPLIED
            >
            <!ELEMENT Parameter ANY>
            <!ATTLIST Parameter
                type          PCDATA    #REQUIRED
            >
            <!ELEMENT Certificate (
                IssuerAndSerialNumber,
                ( Value | Locator )
            )>
            <!ATTLIST Certificate
                type          NMTOKEN    #REQUIRED
            >
            <!ELEMENT IssuerAndSerialNumber EMPTY >
            <!ATTLIST IssuerAndSerialNumber
                issuer        CDATA    #REQUIRED
                number        CDATA    #REQUIRED
            >
            <!ELEMENT Value ( #PCDATA )>
            <!ATTLIST Value
                id            ID       #IMPLIED
                encoding ( base64 | none ) #REQUIRED 'none'
            >

Algorithm type='digest' (all mandatory to implement):
- "urn:ibm:dom-hash"
- "urn:fips:sha1"
- "urn:rsa:md5"

ParameterType="AlgorithmRef"

Algorithms type='signature' (dsa & hmac mandatory to implment, rsa
recommended):
- "urn:us.gov:dsa"
- "urn:ibm:hmac"
- "urn:rsa:rsa"

e.g.
<Algorithm ID=A1 type="digest" name="urn:ibm:dom-hash">
    <Parameter type='AlgorithmRef'>A2</Parameter>
</Algorithm>
<Algorithm ID=A2 type="digest" name="urn:fips:sha1">
</Algorithm>
<Algorithm ID=A3 type="signature" name="urn:ibm:hmac">
    <Parameter type='AlgorithmRef'>A1</Parameter>
</Algorithm>

TODO:
- Parameters within all algorithms to point to "sub" algorithms
- Other parameters specific to digest and signature algorithms

990210
------
Discussions:
- Moving all algorithms to one place
- Having multiple signatures for multiple recipients
- Cases sensitivity of example above where 'case-sensitive' ID=A2 and
<Param>a2</Param>
    may be parsed by different parts of the application.
- Some wants algorithm references to be an IDREFs attribute within
Algorithm

Donald E. Eastlake, 3rd
17 Skyline Drive, Hawthorne, NY 10532 USA
[email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833
Notes: Donald Eastlake/Hawthorne/IBM@IBMUS

home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
[email-masked]   tel: 1-914-276-2668

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: [email-masked]
To: [email-masked]
Date: Tue, 23 Feb 1999 14:03:34 -0500
Subject: Brief summary of Ft. Lauderdale workshop
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

This a brief summary of what happened in Ft. Lauderdale.

Tuesday was the payment scheme day.  There was actually quite limited
discussion of the IOTP SET Supplement draft which is in pretty good shape.
The people at the meeting thought it should be issued as an Informational
RFC but only after the main document is out.  The SCCD (Secure Channel
Credit Debit) draft is still stuck with its current author.  SCCD is how to
do more or less the equivalent of SSL form credit card input inside IOTP.
Hopefully the current state of this draft can be retrieved from its current
author in not too many weeks.  Otherwise, it may be necessary to start a
new verison of the IOTP SCCD supplement.  Because payment scheme
disucssions did not take up the entire day, there was considerable
discussion of IOTP signatures on Tuesday

Wednesday the primary topic was signatures.  A fairly large number of
changes were made from Richard Brown's current draft for general XML
digital signatures <draft-brown-xml-dsig-00.txt> all of which were
motivated in some way by the IOTP requirements.  (Unfortunately Richard was
not there so we did not have the benefit of his understanding of why he did
certain things in certain ways or how he would solve some of the IOTP
requirements.)  The results of this have been posted separately and have
been discussed, mostly on the [email-masked] mailing list.

We also reviewed the other drafts being worked on.  The Architecture draft
is in reasonable shape but needs to be updated a bit.  Any comments,
particularly on implementation experience with the suggestions in that
draft would be appreciated.  The HTTP supplement needs to have previously
agreed changes incorporated into it and be reviewed again by the working
group.

Thursday, we finished up discussions on signatures and worked primarily on
the best structure for modularized documents.  The resulsts of this will be
posted separately.  There was a strong feeling that IOTP Messaging would be
suitable protocol to advance separately as a substrate for a wide variety
of XML communications, not just trading.

On getting V1.0 out in complete form for working group review, Kent
Davidson will produce a signature draft including the signature DTD.  Dave
Burdett will incorporate that DTD in the main draft DTD also.  The main
draft will talk about how to use signatures but Kent Davidson's draft will
give the specifics of constructing them.  Other changes to the main draft
to be done by Dave Burdett: remove tutorial section on XML, remove material
on Payment Instrument Customer Care communications as it is not complete
(definition of role can be left in), make any update needed to
authentication based on signature changes, and permit signatures on
delivery response.

On future workshops outside IETF meeting, the next one would logically by
in late May but there was no consensu among the attendees as to whether it
should occur.

Thanks,
Donald

PS: On general XML Digital Signatures, a BoF is being scheduled aimed at
the formation of an IETF Working Group in this area.  See
draft-brown-xml-dsig-00.txt and draft-hirosi-dom-hash-00.txt.  In
additional, a limited attendance W3C workshop on the topic has just been
announced for April.  See <
http://www.w3.org/1999/02/ds-xml-cfp-19990218.html>

Donald E. Eastlake, 3rd
17 Skyline Drive, Hawthorne, NY 10532 USA
[email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833
Notes: Donald Eastlake/Hawthorne/IBM@IBMUS

home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
[email-masked]   tel: 1-914-276-2668

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: David Burdett <[email-masked]>
To: 'Ietf Trade WG' <[email-masked]>
Subject: Support for HTML in packaged content.
Date: Tue, 23 Feb 1999 18:57:52 -0000
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

One of the suggestions which came out of the meeting in Florida, was the
support for HTML for use with Order Descriptions, Payment Notes and
Delivery Notes, particularly since the both Hitachi and RBC had used
HTML rather than Plain Text. It this therefore proposed that the
following is included in the spec.

Comments?

David
Support for HTML in Packaged Content
============================
The packaged content may contain HTML. In this case the following
conventions are followed:
*	there should be only one top level Packaged Content element containing
with its Name attribute set to Main. This document should contain either
text, or references to images.
*	images are incorporated in a document using links using relative
references of the form "img source=xxxx.gif" where "xxxx.gif" matches
the Name attribute of another Packaged Content element at the same level
and within the same parent element, e.g. an Order Description
*	no text should be included as images for any information which is
important to the user's understanding of the document, e.g. text in
logos would be allowable 
If the above conventions are not followed by, for example, including
external references, then the recipient of the HTML should be informed.

>Mondex International Limited
mailto:<[email-masked]>
>US Advanced Technology Office: 111 Pine St, 6th Floor, San Francisco, CA
>94111
Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

Date: Mon, 15 Feb 1999 15:10:14 -0800
To: [email-masked]
From: "Kent M. Davidson" <[email-masked]>
Subject: XML Signing notes from Ft. Lauderdale
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Enclosed is the notes I took in Ft. Lauderdale re: the XML signing changes we discussed. I'm working with Richard Brown to finalize the changes and start working on the addendum for IOTP.

-Kent.

P.S. There are various notes within the notes marked by ### as possible changes...
---
<!ELEMENT OTPSignatures (Signature+,Certificate*)>
    <!ELEMENT Signature (Manifest, SignatureValue+) >
    <!ELEMENT SignatureValue (#PCDATA)>
    <!ATTLIST SignatureValue
        encoding    (none | base64) #IMPLIED 'none'
        ID          ID              #REQUIRED
    >
        <!ELEMENT dsig:Manifest (
            dsig:Algorithm+,
            dsig:Digest+, 
            dsig:Attributes?, 
            dsig:OriginatorInfo,
            dsig:RecipientInfo+,
        )
        <!ATTLIST dsig:Manifest
            LocatorHRefBase     CDATA   #IMPLIED
        >
            <!ELEMENT dsig:Algorithm (dsig:Parameter*)>
            <!ATTRLIST dsig:Algorithm
                xmlns:dsig      PCDATA                          #FIXED    %xmldsig.dtd;
                type            (digest|signature|keyagreement)   #OPTIONAL
                name            NMTOKEN                         #REQUIRED
                ID              ID
            >
            <!ELEMENT dsig:Digest (#PCDATA)>
            <!ATTLIST dsig:Digest   
                LocatorHREF         NMTOKEN
                DigestAlgorithmRef  CDATA
                encoding            (none | base64)
            > 
            <!ELEMENT dsig:Attributes (Attribute+)> 
            <!ATTLIST dsig:Attribute
                xmlns:disg    CDATA       #FIXED        %xmldsig.dtd;
                type          NMTOKEN     #REQUIRED
                critical ( true | false ) #REQUIRED    'false'
            >
###         <!ELEMENT dsig:IOTPSignatureType EMPTY> 
###                 IOTP SigType = Other, Payment, Delivery
            <!ELEMENT dsig:OriginatorInfo ANY>
            <!ATTLIST dsig:OriginatorInfo 
                OriginatorRef           NMTOKENS    #OPTIONAL
            >
            <!ELEMENT dsig:RecipientInfo ANY>
            <!ATTLIST dsig:RecipientInfo 
                SignatureAlgorithmRef   IDREF       #REQUIRED
                SignatureValueRef       IDREF       #REQUIRED
###             RecipientRef            NMTOKENS    #OPTIONAL
            >
            <!ELEMENT dsig:Parameter ANY>
            <!ATTLIST dsig:Parameter
                xmlns:dsig    PCDATA    #FIXED    %xmldsig.dtd;
                type          PCDATA    #REQUIRED
            >
            <!ELEMENT dsig:Certificate (
                dsig:IssuerAndSerialNumber,
                ( dsig:Value | dsig:Locator )
            )>
            <!ATTLIST dsig:Certificate
                xmlns:disg    CDATA      #FIXED    %xmldsig.dtd;
                type          NMTOKEN    #REQUIRED
            >
            <!ELEMENT dsig:IssuerAndSerialNumber EMPTY >
            <!ATTLIST dsig:IssuerAndSerialNumber
                xmlns:disg    CDATA    #FIXED    %xmldsig.dtd;
                issuer        CDATA    #REQUIRED
                number        CDATA    #REQUIRED
            >
            <!ELEMENT dsig:Value ( #PCDATA )>
            <!ATTLIST dsig:Value
                xmlns:disg      CDATA      #FIXED    %xmldsig.dtd;
                encoding ( base64 | none ) #REQUIRED 'none'
            >

Algorithm type='digest':
- "urn:ibm:dom-hash"
- "urn:fips:sha1"
- "urn:rsa:md5"

- "urn:rsa:md4"
- "urn:rsa:md2"
- RIPE?

ParameterType="AlgorithmRef"

Algorithms type='signature':
- "urn:us.gov:dsa"
- "urn:ibm:hmac"
- "urn:rsa:rsa"

e.g.
<dsig:Algorithm ID=A1 type="digest" name="urn:ibm:dom-hash">
    <dsig:Parameter type='AlgorithmRef'>A2</Parameter>
</dsig:Algorithm>
<dsig:Algorithm ID=A2 type="digest" name="urn:fips:sha1">
</dsig:Algorithm>
<dsig:Algorithm ID=A3 type="signature" name="urn:???:hmac">
    <dsig:Parameter type='AlgorithmRef'>A1</Parameter>
</dsig:Algorithm>

TODO:
- Resolve URNs names...
- Parameters within all algorithms to point to "sub" algorithms
- Other parameters specific to digest and signature algorithms

Changes:                
- Issue of removing "Digest" completely?
- How affects Authentication in IOTP
- Locator removal -> HREF within Resource
- Resource+, eliminates Resources
- HREFBASE added in ATTLIST in Manifest
- Eliminate Date, KeyAgreement, Package, DigestAlg, ContentType
- Certificates moved to beneath Signatures?

- Removal of repetition of digest algorithms within digest
- Multiple signature values for a single manifest
- Once you remove DigestAlgorithm
- Locator has 1 useful attribute, not really needed
- ContentType optional as well
- KeyAgreement not "removed", just arranged, commonality among all algs

990210
------
Discussions:
- Moving all algorithms to one place
- Having multiple signatures for multiple recipients
- Cases sensitivity of example above where 'case-sensitive' ID=A2 and <Param>a2</Param> 
    may be parsed by different parts of the application.
- Hitachi wants references to be IDREFs within Algorithm

___________________________________________
Kent M. Davidson, VP of Advanced Technology
Differential, Inc.
direct (408)864-0604 
fax    (408)864-0601             
mailto:[email-masked]
http://www.differential.com

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
cc: [email-masked]
Subject: calling in to workship
Date: Wed, 10 Feb 1999 09:00:19 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

If people would like to call into the Ft. Lauderdale workshop today, you
can call 1-712-271-0059, passcode 46082 from 9:30 am to noon and/or
1-630-395-0495, passcode 13342 from 1pm to 5pm.

Thanks,
Donald

=====================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668     [email-masked]
 65 Shindegan Hill Road, RR#1  +1 914-784-7913(work)  [email-masked]
 Carmel, NY 10512 USA
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

From: [email-masked]
To: [email-masked]
Date: Mon, 8 Feb 1999 17:16:06 -0500
Subject: Ft. Lauderdale workshop
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

The meetings for the next three days will be in room 201B at the IBM Ft.
Lauderdale facility, 6301 N.W. 5th Way,
Ft. Lauderdale, FL 33309.  The IBM receptionist is on the 2nd floor.  See
<http://www.elistx.com/archives/ietf-trade/199901/msg00014.html>.  I'll try
to arrange dial in access for Wednesday and Thursday.

Thanks,
Donald

Donald E. Eastlake, 3rd
17 Skyline Drive, Hawthorne, NY 10532 USA
[email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833
Notes: Donald Eastlake/Hawthorne/IBM@IBMUS

home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
[email-masked]   tel: 1-914-276-2668

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

To: [email-masked]
cc: [email-masked]
Subject: RSVPs
Date: Fri, 05 Feb 1999 00:47:11 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]
Source-Info:  From (or Sender) name not authenticated.

Hi,

I like to get a rough idea of how many people will be at the meeting
in Ft. Lauderdale next week.  See logistics at
<http://www.elistx.com/archives/ietf-trade/199901/msg00014.html>.
Please send me mail and indicate if you also plan to be there for
the first day which will be primarily devoted to payment systems,
as well as the 2nd and 3rd which will be about the overall IOTP
protocol and supplemental HTTP document.

Thanks,
Donald
=====================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668     [email-masked]
 65 Shindegan Hill Road, RR#1  +1 914-784-7913(work)  [email-masked]
 Carmel, NY 10512 USA
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]