And to clarify, vs. 16 is NOT out yet. IETF has made a few recent changes in
regards to draft submission and we are double checking it before it is
distributed to the EDIINT WG. Should come out at the end of July or first of
August.
Kyle Meadors
DGI
-----Original Message-----
From: owner-ietf-ediint@xxxxxxxxxxxx [mailto:owner-ietf-ediint@xxxxxxxxxxxx]
On Behalf Of Kyle Meadors
Sent: Monday, July 19, 2004 3:04 PM
To: ietf-ediint@xxxxxxx
Subject: RE: EDIINT AS2 Status
Scott,
Those comments were handled off-line. Below is the list of his comments plus
my remarks in terms of accepting or rejecting them. I did initially reject a
comment on "MUST" vs. "SHOULD" in sections 7.5 which I reversed after
further correspondence with Sean. Dale added a couple of lines for the ESS
issue. Sean was OK with the revisions, and both Dale and Rik approved them.
Everyone will be able to see them in vs. 16 of the draft.
Kyle Meadors
DGI
REJECTED: Already covered in later MDN sections - Section 7.1 - Required
support for signed receipts - should there be requirements for the errors in
processing?
REJECTED: Not necessary - Section 7.1 - trading partner UA's requirements #3
- I guess I'd like to see more about verifying the signer's certificate up
to a trust point. Sounds like all you MUST do is verify the math on the
cert.
ACCEPTED: Changed "WILL" to "SHOULD" - Section 7.3 - 2nd para - "WILL BE" is
not keyword ... replace with "MUST be"?
ACCEPTED: Section 7.3 - para after micalgs - "NOT" is not a keyword replace
with "MUST not be".
REJECTED: The signed receipt is a best attempt with whatever algorithm the
recipient can support. - Section 7.3.1 - Rule #2 - If the recipient can't
support the protocol or micalg how is it going to be able to send a receipt
back? Seems like it shouldn't be a "SHOULD".
REJECTED: Section 7.3.1 - Rules - I think it would be clearer if you had one
rule for each case.
REJECTED: Concept understand by majority of audience. - Section 7.3.1 -
Error processing - I do not understand how you can claim that a returned
signed receipt gives you all these services in 7.1 but then say if there's a
error in processing you still have to send back a signed receipt - this
strikes me as wrong. I think 7.1 ought to at least say assuming the MDN is
not received with a disposition-notification of failed (or whatever it is).
ACCEPTED: Changed to MUST NOT - Section 7.4.4 - #9 - "MAY NOT" is not a
valid combination for keywords.
ACCEPTED: Section 7.5.2 - 2nd para 2nd sentence - r MUST not/MUST NOT/
ACCEPTED: Section 7.5.3 - There are lots of "shoulds" that sound like they
should be "SHOULD"s.
REJECTED: Sections appear to be consistent and understood. - Section 7.5.3-4
- There seems to be an inconsistency between 7.3.1 and 7.5.3-4. &.3.1 says
that reason for processing the contents could not be processed MUST be
included. Then 7.5.3 and 7.5.4 say that they "should" be included. I
believe that the "should"s ought to be "MUST"s.
ACCEPTED: Section 9 - S/MIMEv2 security considerations - Since the RFC you
reference are the version 3 specs I'd suggest pointing to the S/MIMEv3
security considerations.
REJECTED: A noticable change to a document of this maturity is not necessary
given its widespread implementation. - Section 9 - I think you have to add
that signed receipts may be returned even though processing failed - to me
this is a huge omission.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.719 / Virus Database: 475 - Release Date: 7/12/2004
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.719 / Virus Database: 475 - Release Date: 7/12/2004
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.719 / Virus Database: 475 - Release Date: 7/12/2004
|
