Multiple Attachments for Electronic Data Interchange - Internet Integration (EDIINT)
draft-meadors-multiple-attachments-ediint-14

[Ballot comment]
Even though this has enough positions to go ahead, Pete
asked if newbies like me were ok with that, so since I'd not
seen this before, I took a look. I've no problem if these are
ignored really, but fwiw:

(1) The draft says that people "began" doing stuff, which is
fine, but would be even better with some references to that
(if some exist) so the reader could understand better.

(2) s/this body is covered/this body are covered/

(3) It says the attachments "should" be inter-related - is that
meant to be a 2119 SHOULD? I'm also unclear as to what
inter-related means, but I guess that's really a higher
layer issue (in which case do you really need to impose
the constraint at this level?). If that was a 2119 SHOULD
then under which conditions is it ok to ignore the
rule? (maybe easiest is s/should/ought/ just to avoid
potential 2119 confusion)

(4) I think 2.3 says that for an encrypted message the MIC
is calculated over the plaintext but is sent outside the
encryption. If so, that's less common than also encrypting
the MIC and is usually specifically justified, but maybe
I'm misreading it (and I didn't go read the references to
check sorry;-)

(5) Section 4 mentions "the three EDI-INT transport
standards" but doesn't include the references at that
point - I think it'd be good to repeat those for clarity.

[Ballot comment]
This is an individual submission of an Informational document I picked up from Alexey, so I don't know the full history. Sean's discuss (the only one) has been cleared, so I could approve it, but since half of the IESG hasn't entered a position, I'd like to double-check and have people give it a gander before sending it on its merry way.

[Ballot discuss]
update based on Alexey's RFC editor note.

#1) In Sec 2.3, need a normative reference to the canonicalization method.

#2) need references for or need to remove application/x-vnd.ms-excel and image/bmp.  They aren't on the/a list.

[Ballot discuss]
update based on Alexey's RFC editor note.

#1) In Sec 2.3, need a normative reference to the canonicalization method.

#2) In Sec 2.5, need normative references for each content types list.

[Ballot comment]
Sec 2.3 says:

  If the expected MIC value differs from the calculated MIC value, all
  attachments MUST be considered invalid and retransmitted.


Isn't telling the initiator that they didn't match and asking for the retransmission missing?

[Ballot discuss]
#1) In Sec 2.3, need a normative reference to the canonicalization method.

#2) In Sec 2.5, need normative references for each content types list.

#3) In Sec 3, the micalg example doesn't match the Hash Functional Textual Names registry (http://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xml) or RFC 5751.  It shows:

micalg=sha1;

and should be:

micalg=sha-1;

[Ballot comment]
In the Gen-ART Review by Pete McCann on 15-Mar-2011, a concern is
  raised.  Please consider it:

  There is a space in the declaration of boundary=" INNER-BOUNDARY";
  in the example in section 3.  I am not sure whether this was
  intentional or whether it will mess up a standard MIME parser, but
  you may want to remove it.

[Ballot comment]
There are a number of id-nits that need be fixed before the document considered ready for publication (IANA section and RFC2119 language). Also the editor should confirm that all of the lower case "should" instances are correctly set.

IANA notes that this document does not contain a standard IANA
Considerations section. After examining the draft, IANA understands
that, upon approval of this document, there are no IANA Actions that
need completion.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Multiple Attachments for EDIINT) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Multiple Attachments for EDIINT'
  as an Informational
RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-02-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-meadors-multiple-attachments-ediint/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-meadors-multiple-attachments-ediint/

AD review comments:

>2.  Using Multiple-Attachments in EDI-INT
>
>2.1.  Multipart/Related Structure
>
>  Multiple payload attachments for EDI-INT messages are stored within a
>  multipart/related MIME envelope [RFC2387].  The multipart/related
>  structure allows an unlimited number of attachments, but the
>  attachments MUST be inter-related to complete a transaction.

How can the above MUST be tested for compliance? If it can't, I suggest changing this to a non normative verb, e.g. "have to be" or such.

>2.2.  EDINT Features Header

>  For applications implementing certification exchange, the MA-Feature-
>  Name MUST be used within the EDIINT Features header:
>
>      MA-Feature-Name = "multiple-attachments"
>
Strictly speaking this still needs a reference to ABNF [RFC5234].


>2.3.  MIC Calculation

[...]
>  For an encrypted but unsigned and uncompressed message, the MIC is
>  calculated on the decrypted multipart/related envelope, including
>  header and all attached documents.  The envelope MUST be
>  canonicalized before the MIC is calculated.
>
>  For an unsigned and unencrypted message, the MIC is calculated over
>  the data inside the multipart/related boundaries prior to Content-
>  Transfer-Encoding.
>
Is different procedure needed in this case?

[...]

>2.5.  Content-Types to Support
>
>  Documents of the following MIME media types MAY be found in a
>  multipart/related envelop and MUST be accepted by the user agent.
>  Other media types MAY be accepted depending upon trading partner
>  agreement.
>
>      application/xml
>
>      application/pdf
>
>      application/msword
>
>      application/vnd.ms-excel, application/x-msexcel
>
>      application/rtf
>
>      application/octet-string
>
This should be application/octet-stream

>      application/zip
>
>      image/bmp
>
>      image/gif
>
>      image/tiff
>
>      image/jpeg

What about image/svg+xml ? :-)

[...]

>4.  Security Considerations
>
>  Multiple attachments have very similar security concerns to what is
>  described in the three EDI-INT transport standards.  Please refer to
>  these standards for their security considerations.

I think repeating the relevant references here would be a good idea.