Registration of Military Message Handling System (MMHS) Header Fields for Use in Internet Mail
draft-melnikov-mmhs-header-fields-08

Section 1

   This document enables the provision of most of the elements of
   service defined in STANAG 4406 [STANAG-4406] for Internet Email.

It would be nice to have a forward pointer to section 5.

---

Section 3

   Any header field specified in this document MUST NOT appear more than
   once in message headers.

It would be usual to state what a receiver does if this rule is broken,
even if the statement is simply a reference to normal behaviour in a
specific RFC.

---

The anchors seem to be broken.
  Specification document(s): [[anchor4: this document]]
  Specification document(s): [[anchor6: this document]]
  Specification document(s): [[anchor8: this document]]
etc.

---

Section 3.2

   This header field SHOULD always be present in an email message which
   complies with this specification.

Since we are talking about "compliance" you probably need to set out the
conditions under which the field MAY be absent.

---

Section 3.6

   If this header field is
   absent the message will be considered received without the Codress
   format.

s/will/MUST/ ?

Actually, I find a number of uses of "will", "should" etc. throughout
the document and I am unclear when you mean to use 2119 language and
when not.

---

Section 3.7

   Note: trailing and leading spaces in an originator reference are not
   allowed.  Any leading or trailing spaces would be stripped.

"would be" under what circumstances? :-)
I think you need to replace "are not allowed" and "would be" with 
RFC 2119 language.

---

Section 3.8

   The MMHS Primary Precedence Element of Service indicates the relative
   order in which Military Messages are to be handled for primary
   (action) recipients, i.e. a Military Message with higher MMHS-
   Primary-Precedence header field value should be handled before a
   Military Message with a lower MMHS-Primary-Precedence header field
   value.

s/should/SHOULD/ ?

Ditto section 3.9

---

Section 3.8

   Example 1:
   MMHS-Primary-Precedence: 0 (Deferred)

The previous text said:

   The header field value is an integer, or one of the 6 predefined
   case-insensitive labels: "deferred" (same as "0"), "routine" (same as
   "1"), "priority" (same as "2"), "immediate" (same as "3"), "flash"
   (same as "4"), or "override" (same as "5").

So the example appears not to be conformant.

Ditto section 3.9

   Example 1:
   MMHS-Copy-Precedence: 4 (flash)

This is explained at the foot of 3.10 by...

   Note that some of the examples above demonstrate use of optional
   comments.  See Section 4 for the exact syntax of this header field.

Which is a little late to be convenient.

---

Section 3.14

   The originator Plain Language Address Designators (PLAD) header
   field, by its presence indicates the plain language address
   associated with an originator for cross reference purposes.

Please explain why the reference is cross. What upset it? Does it 
always get angry when its hyphen is left out?

---

Section 8

For clarity, I always think it is nice to give detailed and specific
instructions to IANA. OTOH they are clever and will work it out.

---

Section 9.

Given that the Security ADs are all over this document, I will not
comment more than saying that the Gateway function described in this
document seems to raise interesting security concerns in that it 
provides a mechanism to transfer a security breach in one mail system
into the other mail system. Thus, the combination is only as strong
as its weakest component.

I agree with the issues raised on the normative reference. These should be available. Also, the document says:

> Note: There is no guarantee that the exempted
> addresses will not receive the message as the result of redirection,
> Distribution List (DL) expansion, etc.

This is pretty weak language for a military spec. But it is not my army, so....

Several reviewers have provided very detailed feedback, so I am restricting my comments to a few small points in the text.

1. Is MMHS / STANAG 4406 only for communication among NATO member countries? If so, the text in the Abstract and the Introduction over-promises.

2. Section 1 states: 'The RFC 5322 header fields defined are prefixed with the string "MMHS-" to distinguish them from any other header fields.' Can the "MMHS-" prefix be used in any other header fields, or is the intent that it is being locked down by this specification? For the record, I think the latter approach would be a bad idea and not enforceable by IANA.

3. In Section 3.8, "MMHS-Primary-Precedence: 7" appears to use a disallowed label.

4. Section 3.10 has a typo: "MMHS-Message-Type: 2 (projet)"

5. Given the definition of "integer" in Section 4, +0 and -0 seem to be allowed. Is that correct?

  I think the tone of the Abstract sends the wrong message to the
  reader.  I suggest the following re-write:

  OLD:

   A Miltary Message Handling System (MMHS) processes formal messages
   ensuring release, distribution, security, and timely delivery across
   national and international strategic and tactical networks.  The MMHS
   Elements of Service are defined as a set of extensions to the ITU-T
   X.400 (1992) international standards and are specified in STANAG 4406
   Edition 2.  This document describes a method for enabling those MMHS
   Elements of Service that are defined as Heading Extension to be
   encoded as RFC 5322 (Internet Email) message header fields.  These
   header field definitions support the provision of a STANAG 4406 MMHS
   over Internet Email, and also provides for a STANAG 4406 / Internet
   Email Gateway supporting message conversion compliant to this
   specification.

  NEW:

   A Miltary Message Handling System (MMHS) processes formal messages
   ensuring release, distribution, security, and timely delivery across
   national and international strategic and tactical networks.  The MMHS
   Elements of Service are defined as a set of extensions to the ITU-T
   X.400 (1992) international standards and are specified in STANAG 4406
   Edition 2.  This document specifies message header fields and
   associated processing for RFC 5322 (Internet Email) to provide a
   comparable messaging service.  In addition, this document provides
   for a STANAG 4406 / Internet Email Gateway that supports message
   conversion.

This is updated based on -05.

#0) Summarized from my discuss #2: I believe it would be much clearer to talk about MM-header fields and skip the whole Element of Service abstraction.  That way we know you're converting headers to headers not EoS to headers to headers.

I think I might be reading way more in to this than I should, but I think you can't say that by translating these services you're enabling MMHS services in Internet mail.  To me that sounds like advertising and I think if that statement was to be made somebody who works for NATO (or maybe a NATO-member nation) would would need to say it.  It's like when a draft author claims their draft is Suite B compliant - somebody from the NSA would have to say that not the author (unless they worked at NSA).  I think if you're clinical about it - i.e., this document translates from this to this - then you're okay.  What follows are the tweak I think you need to make.  My intent with the suggested changes is to ensure the information necessary for implementers to implement is still there - and I hope I've done that.

title:
 OLD:
  Registration of Military Message Handling System (MMHS) header fields
                        for use in Internet Mail
 NEW:
  Registration of SMTP header fields for Military Messages

abstract:
 OLD:
   The MMHS
   Elements of Service are defined as a set of extensions to the ITU-T
   X.400 (1992) international standards and are specified in STANAG 4406
   Edition 2.   This document describes a method for enabling those MMHS
   Elements of Service that are defined as Heading Extension to be
   encoded as RFC 5322 (Internet Email) message header fields.  These
   header field definitions support the provision of a STANAG 4406 MMHS
   over Internet Email, and also provides for a STANAG 4406 / Internet
   Email Gateway supporting message conversion compliant to this
   specification.

 NEW:
   The MMHS
   Elements of Service are realized as a set of extensions to the ITU-T
   X.400 (1992) international standards, which are referred to as Military
   Messaging (MM) header fields, and are specified in STANAG 4406
   Edition 2.   This document describes a method for translating Military
   Message (MM) header fields, which are defined as X.400 Heading
   Extension and that realize the MMHS elements of service,
   to RFC 5322 (Internet Email) message header fields.  These
   header field definitions provide for a STANAG 4406 / Internet
   Email Gateway.

s1:
 OLD:
   This document enables the provision of most of the elements of
   service defined in STANAG 4406 [STANAG-4406] for Internet Email.

 NEW:
   This document supports translating most of the MM-message header fields
   defined in STANAG 4406 [STANAG-4406] to Internet message header fields.

s3.3:
 OLD:
   [STANAG-4406] specifies two optional components of the Distribution
   Code Element of Service.

 NEW:
   [STANAG-4406] specifies two optional components of the Distribution
   Codes header.

s3.8 and s3.9: 
 OLD:
   The MMHS Primary/Copy Precedence Element of Service indicates the
   relative order in order in which Military Messages ...

 NEW:
   The primary/copy precedence header indicates the relative order
   in which messages ...

s3.11 and 3.12: I guess I'm not making myself clear on this one.  The clauses currently contain the exact same text and it's ambiguous and therefore not entirely clear that it's true.  On ambiguity, the clauses say:

   This MMHS Element of Service enables an MMHS recipient to determine
   all recipients of a Military Message.

It's unclear what "this" refers to.  Is it the MMHS Other Recipients Indicator EoS or something else?  Because reading this would lead me to believe that there's an EoS called "MMHS Other Recipients Indicator To" and "MMHS Other Recipients Indicator CC" and there isn't one.

If you're talking about the "MMHS Other Recipients Indicator" header then I can see your point about it being helpful to figure out "all" the recipients, but if it's some made up EoS about the To or CC recipients then it's not true.  It would be much better if you were clear about what you were talking about.  I suggest the following:

*=primary or copy (primary goes in s3.11 and copy goes in s3.12) and 
**= to or cc (to goes in s3.11 and cc goes in s3.12):

 OLD:
   The other * recipients indicator header field, by its presence
   indicates the names of * recipients that are intended to
   receive or have received the message via means other than MMHS.  The
   absence of this element does not guarantee that all recipients are
   within the MMHS.

   This MMHS Element of Service enables an MMHS recipient to determine
   all recipients of a Military Message.  There are several reasons as
   to why a recipient of a Military Message may be identified by this
   header:

   1.  The recipient is not part of the MMHS

   2.  The path to the recipient through the MMHS may not be secure,
       therefore, the originator has used alternative mechanisms to
       distribute the Military Message

   3.  The recipient was already in receipt of the Military Message
       prior to it being inserted into the MMHS

 NEW:
  The other recipients indicator to/cc header field, by its presence
  indicates the names of * recipients that are intended to
  receive or have received the message via other means.  It enables
  a recipient to determine all action/information recipients of a
  message.  This header field is derived from the MM-header Other
  Recipient Info.

s3.13: (actually the part I deleted isn't in 4406)
 OLD:
   This header field is used only to support interoperability with ACP
   127 systems, it should be treated as opaque by a pure MMHS system.
 NEW:
   This header field is used only to support interoperability with ACP
   127 systems.

s3.14
 OLD:
   This MMHS header field and the Extended Authorisation Info header ...
 NEW:
   This header field and the Extended Authorisation Info header ...

s5:
 OLD:
   The service specified in this document is a subset of the
   functionality set out in Annex A1 "Military Heading Extensions" of
   [STANAG-4406].
 NEW:
   The headers specified in this document are a subset of the
   headers set out in Annex A1 "Military Heading Extensions" of
   [STANAG-4406].

s7:
 OLD:
   The header fields defined in this specification include fields to
   carry ACP 127 specific elements of service [ACP127]. 
 NEW:
   The header fields defined in this specification include fields to
   carry ACP 127 specific values [ACP127]. 

#1) a/s1: Expand STANAG: Standardization Agreement (STANAG)

#2) incorporated

#3) s1: (This is kind of linked to discuss #2.) Contains the following:

   This document enables the provision of most of the elements of
   service defined in STANAG 4406 [STANAG-4406] for Internet Email.

Something wrong - maybe provisioning?  Maybe:

   This document supports translating most of the MM-message header fields
   defined in STANAG 4406 [STANAG-4406] to Internet message header fields?

#4) s1: expand IPMS

#5) incorporated

#6) incorporated

#7) s3.*: I know a lot of this was copied from 4406 and you'll want to maintain alignment, but maybe these could be fixed:

a) (Fixed in 3.1 not in : 3.2, 3.4, 3.5, 3.6, 3.7, 3.8, 3.9, 3.10, 3.11, 3.12, 3.13, 3.14) Contains:

  header field, by its presence indicates ...

I think maybe there should be a comma:

  header field, by its presence, indicates ...

b) s3.1, s3.4, 3.5, s3.6, s3.7, s3.8, s3.13, s3.14: Contains phrases like:

  If this header field is absent, then then the message will
  be considered to ... not have, to have no ... 

Do you really need to say if the extension isn't there then the message should be like the extension isn't there?  I know that some specs are written for vendors who might do really silly things, but these sentences seem completely unnecessary.

#8) s3.5: Good that you mention ACP 123 ;)  ACP 123 indicates that message instructions:

  They are used for informational purposes at the end points.

Might be worth adding this so that implementers know they're not supposed to do anything with them.

#9) s3.5: Should you also add the message instructions are sometimes called "remarks"?

#10) incorporated

#11) incorporated

#12) incorporated

#13) answered

#14) (final outcome in discuss #2) s3.11 and s3.12: Contains the following phrase:

   This MMHS Element of Service enables an MMHS recipient to determine
   all recipients of a Military Message.

Two things:

1) There's no MMHS EoS called Other Recipient Info To/CC.  Maybe something like:

  This header field is derived from the MM-header Other Recipient Info.
  It enables an MMHS recipient to determine all recipients of a Military Message.

2) These extensions combined would allow you to determine the other recipients, but one alone can't.  So I think you have to say something like (action/info depends on whether it's primary/copy):

  The other * recipients indicator header field, by its presence
  indicates the names of * recipients that are intended to
  receive or have received the message via other means.  It enables
  a recipient to determine all action/information recipients of a
  message.  This header field is derived from the MM-header Other
  Recipient Info.

#15) incorporated

#16) s3.13: I searched ACP 127 and couldn't find the acronyms for DERI, SSN, or JFT.  Did these come from someplace else?

#17) s3.13: The last bit isn't in STANAG 4406 maybe delete it:
 OLD:
   This header field is used only to support interoperability with ACP
   127 systems, it should be treated as opaque by a pure MMHS system.
 NEW:
   This header field is used only to support interoperability with ACP
   127 systems.

or should this be added to every other paragraph that says a header is only used for interop?

#18) s4: Contains date-time.  Should you also have a pointer to where it is defined like address-list?

#19) incorporated

#20) answered ;)

#21) s5: Contains the following:

   This
   extension is deprecated in favour of Annex A, 

Annex A of ?  I assume STANAG 4406, but I'm not entirely sure.

#22) incorporated

#23) s6: r/and/or - would ever sign the message both ways?

   The X.400 message MAY be signed according to
   STANAG 4406 Annex B and Annex G.

#24) s9: I tend to agree with Stephen and his discuss about the security considerations.

#25) s10.1 and s10.2: Should probably add the edition (G) to ACP127 reference and (B) for the version of ACP123 to match what is in the main body.  Likewise the version for ACPs 121 and 131 should be added.

#25) The references in the in s3 are not quite right.  ACP has Annexes that include Appendices.  But, I think the references ought to be to Annexes. 

- It seems a bit odd that this is informational - I'd have
expected the consumers of this to require a standards track
document for it to be really useful to them. But I guess
the authors know better.

- IPMS is used without expansion

- The ACP 127 reference would be better provided where its
first mentioned.

- What is "the Extensions heading field" in 3.1 and why is the
header field called "this extension" here? Is that text leakage from
4406?

- in 3.2 would s/was submitted/was initially submitted/ be more
correct? 

- 3.2 says this one SHOULD be included, might be useful to say
these are all OPTIONAL unless otherwise stated?

- For values like the SIC codes, and others, can you give a 
reference to relevant registries? That should help someone
trying to write code from this.

- 3.4 says this is "human readable" but the example "ZNY; RRRR"
doesn't strike me as Shakespear-like:-) And is there an (open)
registry of codes for this?

- Should you have a reference to how to encode ACP127 in a MIME
body in 3.6?

- In 3.7 what does "would be stripped" mean? Is that really a 
MUST and if so, for whom?

- In 3.8 s/shall ensure/MUST ensure/ ?

- 3.10 calls this one a "heading extension" which seems wrong

- 3.10 s/may includes/may include/

- I assume there are no I18N problems with the values that are
allowed in all of these fields - is that right?

- I think you could mention that DKIM could be used to sign these
header fields at least.