Subject: Re: comments on as2

From: "Dale Moberg" <[email-masked]>
Date: Sun, 31 Oct 1999 10:33:06 -0500

Discussion noted in-line. Some editing of original comments
done also. Dale Moberg

>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.

In the first section 1.1, GISB is mentioned as revealing a need for two new
additions to earlier AS2 discussions. First, it showed a need to generalize
the acknowledgement structure beyond the MDN  multipart/report format.
Second, it showed a need to add multipart/form-data. These points could
be expanded a bit, but that is "technically" the main upshot. An updated version
of a future GISB specification also is used to illustrate how to make use
of these new extensibility mechanisms. Can you suggest a sentence or two
 to insert in section 1.1 that adds what else you would like to include?

>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.

In section 1.1 the term "overloaded" is used to discuss the "From" header
in HTTP and SMTP usage. Each specification provides its own discussion
of how the same term is used. The word "overloaded" is pretty common in
technical writing (especially object oriented design and implementation) to
indicate a term (say the addition operator "+") that has different (but related)
uses in say integer addition and complex number addition. In the sentence
you mention, the topic is being revisited. It can certainly be replaced if the
consensus is that it is confusing. The basic idea is that there are at least two
distinct technical "meanings" for the term. (I do not want to use "ambiguous"
because that carries negative connotations. Suggestion?)

>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].

I am looking for a word that abstracts away from the "header"  implementation to
indicate that we are talking some information about our data. For example,
"content-type"
and "content-length" both give information about data (as does who authored it,
who
it is sent to, etc etc). Data that is about data is often called metadata.
Suggest something
you think is better that:

 1. gives clear summary of the role of the information as not literally
part of the business data exchanged but aiding in its tracking, its application
level routing, and so on
  and
2. is not tied to a specific implentation mechanism.

The term "metadata" worked for me. But give me another one (or a phrase) and I
will change it.

>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?

Yes. I think that Carl Hage suggested it be the default mode of operation and
it is explicitly mentioned as the default mode somewhere.

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

Maybe some people want to exchange using either PGP or SMIME encryption. Maybe
they
don't want to have the overhead of TLS in that case. So it was strongly
encouraged.

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

Yes It is explicitly stated to be the default.
 It was requested that there be a note encouraging implementors
to support opaque signatures. Maybe I should repeat that
detached is of course still the default? Probably
worth it if you got confused here so will add it later.

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

Agree. Thanks. Will get that in soon.