Subject: comments on as2

From: "Rik Drummond" <[email-masked]>
Date: Wed, 27 Oct 1999 10:41:04 -0500

Generally, the document look fine if one is familiar with the reasons we are
doing it. It is appropriate to add a single paragraph which describes why
gisb and why as2 are being combined from a technical point of view.

Specifically, my comments are below. Looks nice.... Any discussion or other
comments on the as2 document?

best regards, Rik Drummond
			chair IETF's ediint wg

What does the word "overloaded" mean in the below?

    One way to convey this information within the HTTP transport context is
    to use either HTTP entity-headers or extension-headers
    [11, section 7.1] that have the syntax of  SMTP headers. Only the "From"
    header is overloaded by possibly different usages in the
    SMTP and HTTP contexts.

The word "metadata" usage is not clear to me in the following paragraph.

    Also, it is currently difficult to make use of HTML [HTML]
    and simple scripting
    to send HTTP entity-headers as part of the HTML FORM tag construct.
    For HTML-based POST situations [GISB], it is useful to specify
    ways to convey 'metadata' needed for the secure transmission loop that
    do not make use of HTTP headers. One way to specify this data is
    by using the MIME multipart/form-data packaging specified in [FORMDATA].

In section " 1.2 Overall operation" it is not clear that the intent is to
have all of this happen if possible during the same session. is this still
you current thinking?

Why don't we require TLS usage for server to server edi movement? See
paragraph...

    An EDI data file or stream is first structured into one of the
    message templates described in [AS1], sections 4.2.1 to 4.2.4 or
    4.3.1 to 4.3.4 for PGP/MIME or S/MIME security. If TLS is to be used,
    the typical packaging will be that provided in 4.2.2 or 4.3.2;
    that is, a multipart/signed message will be created with no
    encryption in the message. Otherwise, if privacy
    is desired, message templates 4.2.4 or 4.3.4 are used.
    Content transfer encoding is not used and a content-length
    field is to be provided.

It is not clear from below that you assume detached signatures are the
default. Is this still true?

    Finally, several industry groups currently make use of "encapsulated"
    (or opaque) signatures within encrypted or signed objects.
    Encapsulated signatures should be supported in order to
    accommodate these existing practices. Objects containing encapsulated
    signatures must be prepared according to the specifications contained in
    section 3.4.2 of RFC 2311[SMIMEV2] or, in the case of PGP, according to
the
    specifications contained in section 6.2 of "MIME Security with Pretty
Good
    Privacy (PGP)" [MIMEPGP] and "OpenPGP Message Format" [RFC2440].

The To should be in quotes, such as "To"

     The To name contains an identifier identifying the
     intended recipient of a data exchange and may be
     D&B D-U-N-S number [DUNS]  or other agreed upon
     identifier system. Applications should allow users to
     configure these elements in the automated HTTP agents
     processing these values. For example, the body
     part MIME header line looks like the following line:

Chuck Shih's name should be removed from the document

What does this mean? I don't think it is clear.

	Example A.1

	Sending a multipart signed for trading partner 1 back to
	trading partner 2. "#" indicates a comment line.

---

From: "Dick Brooks - TC" <[email-masked]>
Date: Sat, 30 Oct 1999 21:32:00 -0700

Rik, I'd be happy to provide a BRIEF overview describing the reasons why
GISB, AIAG and GISB are bing combined. Will this be needed before the
Washington meeting?

Regarding use of detached signatures as default; I believe detached
signatures are the preferred way to sign documents and encapsulated
signatures are optional.

Dick

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Rik Drummond
Sent: Wednesday, October 27, 1999 8:41 AM
To: [email-masked]
Subject: comments on as2

	Example A.1