RE: AD review of EDIINT documents (was RE: Status and Future of EDIINT)

["Rik Drummond" <rvd2@xxxxxxxxxxxxxxxx>]

ned we are working on the edits... should have something back to you in a
couple of weeks.... one of the editors is buried in a as2 test.... best
regards, rik

-----Original Message-----
From: ned.freed@xxxxxxxxxxxx [mailto:ned.freed@xxxxxxxxxxxx]
Sent: Friday, November 03, 2000 1:20 AM
To: Rik Drummond
Cc: ietf-ediint@xxxxxxx
Subject: AD review of EDIINT documents (was RE: Status and Future of
EDIINT)


> well it is not dead. the spec is in the loop for rfc approval... and we
now
> have 12 vendors supporting as1 and 9 supporting as2. these are all
> interoperable. if we don't get something back from the ietf shortly it
might
> be wise to go the ansi route... rik

Well, as it happens I've been working on the AD review of these documents. I
just completed that review today. I've attached my review comments below.

Sorry it took so long.

				Ned

------

AD review of draft-ietf-ediint-req-08.txt:

I started to write a bunch of comments on this document, but then decided
against it. The basic problem is that due to the substantial amount of time
that has passed since this text was written (through no fault of the authors
or
the WG, I hasten to add), quite a bit of it seems dated. For example, a
discussion of the use of VPNs in contrast to VANs would seem appropriate.
Some
of the symmetric cipher discussion is likely dated as well. But given that
it
is informational I see little harm in publishing it as-is. Note that it may
end
up with an IESG note pointing out the timing issue, however.

AD review of draft-ietf-ediint-as1-11.txt:

This is where the issues are. Some are very minor, but a couple must
be addressed.

Security considerations section. The word "Technologies" is
capitalized when it should not be.

The security considerations section is normally at the end of the
document. It also should cover actual considerations rather than
restating what the document is about.

1.0 Introduction, first paragraph. The impression is given here
that this is purely an Applicability Statement. However, the
very next paragraph then indicates otherwise. I suggest that
this be clarified by referring to "the bulk of this document
is an Applicability Statement", or something similar.

1.0 Introduction, second paragraph. There's a reference to section
3.1.8, which does not exist in the current document. I believe this
is supposed to be 5.3.1.

1.0 Introduction, third paragraph. "Used" -> "used".

2.1. Reference to "standard" is premature. I suggest saying
"document" instead.

2.2.2, first paragraph. "The functional requirements document, [9]
"Requirements for Inter-operable Internet EDI" (can be found at
www.ietf.org)," needs to be rewritten as a reference to an RFC-to-be.

2.2.2, first paragraph, "Provides" -> "provides".

2.2.2, second paragraph. Use of the term "transport" here is
confusing. I suggest "environment" or something similar
instead.

2.2.2, last paragraph. "Satisfy" -> "satisfy".

2.2.3, first bullet item. This section doesn't identify RFC 2298 as
the mechanism being used to request EDI receipts. Suggest making it
clear here rather than having to get further into the document to find
out.

2.3.2, fourth bullet item. Now that PGP itself is an IETF standard,
should reference RFC 2440 as well as RFC 2015 here and elsewhere in
the document.

2.3.2, fourth bullet item. REQUIRES is not a keyword on the 2119 list;
suggest rewording to use REQUIRED instead.

5.4.1, first paragraph. The phrase

   Using message, "partial",

should be

   Using message/partial

5.4.1, second paragraph. The phrase "so that if fragmentation does occur,"
isn't right in this context. I suggest "so that if fragmentation is needed"
instead.

5.4.1. Recommending that partial be used but saying that support for it
is optional could lead to interoperability issues. I suggest that you
add that in the absence of knowledge that the recipient supports partial
it SHOULD NOT be used.

5.4.1, last paragraph. This is the biggie. Saying it is OK to use
content-encoding in email even as an option just isn't acceptable. The
problem is one of interoperability: An unextended agent that receives
a message with, say, a content-encoding of gzip won't recognize the
field for what it is and will cheerfully decode the base64 expecting to
find text or whatever. Instead it will find garbage.

Unfortunately, the only way to add compression to email in a backwards
compatible way is to define new content-transfer-encodings. If this is a
real issue this is the mechanism that needs to be pursued.

Note that it is fine to recommend use of content-encoding if the
transport is HTTP. Content-encoding is well-defined there and agents
are required to check for it and handle it.

Finally, this document defines new disposition-notification-options
and a new MDN field received-content-mic. Both of these things
require IANA registration. It is customary in standards track documents
to do this with an appendix containing the appropriate registration
forms. This needs to be done per sections 10.2 and 10.3 of RFC 2298.

That's it!