Skip to main content

Registration of Military Message Handling System (MMHS) Header Fields for Use in Internet Mail
RFC 6477

Revision differences

Document history

Date Rev. By Action
2015-10-14
08 (System) Notify list changed from BonattiC@ieca.com, alexey.melnikov@isode.com, graeme.lunt@smhs.co.uk, draft-melnikov-mmhs-header-fields@ietf.org to BonattiC@ieca.com
2012-08-22
08 (System) post-migration administrative database adjustment to the No Objection position for Sean Turner
2012-08-22
08 (System) post-migration administrative database adjustment to the No Objection position for Stephen Farrell
2012-01-17
08 Cindy Morgan State changed to RFC Published from RFC Ed Queue.
2012-01-17
08 (System) RFC published
2011-12-20
08 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2011-12-20
08 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2011-12-19
08 (System) IANA Action state changed to Waiting on Authors from In Progress
2011-12-19
08 (System) IANA Action state changed to In Progress from Waiting on Authors
2011-12-19
08 (System) IANA Action state changed to Waiting on Authors from In Progress
2011-12-05
08 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent.
2011-12-05
08 (System) IANA Action state changed to In Progress
2011-12-05
08 Amy Vezza IESG state changed to Approved-announcement sent
2011-12-05
08 Amy Vezza IESG has approved the document
2011-12-05
08 Amy Vezza Closed "Approve" ballot
2011-12-05
08 Pete Resnick Approval announcement text changed
2011-12-05
08 Pete Resnick Approval announcement text regenerated
2011-11-30
08 Pete Resnick State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation::AD Followup.
2011-11-22
08 (System) New version available: draft-melnikov-mmhs-header-fields-08.txt
2011-11-13
08 Stephen Farrell
[Ballot comment]
- It seems a bit odd that this is informational - I'd have
expected the consumers of this to require a standards track …
[Ballot comment]
- 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.
2011-11-13
08 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2011-11-13
07 (System) New version available: draft-melnikov-mmhs-header-fields-07.txt
2011-10-31
08 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss
2011-10-28
06 (System) New version available: draft-melnikov-mmhs-header-fields-06.txt
2011-10-24
08 Sean Turner
[Ballot comment]
This is updated based on -05.

#0) Summarized from my discuss #2: I believe it would be much clearer to talk about MM-header …
[Ballot comment]
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.
2011-10-24
08 Sean Turner
[Ballot discuss]
This is further updated discuss based on -05.

Despite the length of these I believe a draft that translates MM-header fields to RFC5322 …
[Ballot discuss]
This is further updated discuss based on -05.

Despite the length of these I believe a draft that translates MM-header fields to RFC5322-header fields is publishable.

#1) I appreciate trying to do a straight replace of STANAG with ACP, but I think there's a couple you need to fix:

s1:

  to enable inter-conversion in a MIXER gateway with the X.400 IPMS
  heading extensions defined in STANAG 4406 Annex A.

to:

  to enable inter-conversion in a MIXER gateway with the X.400 IPMS
  heading extensions defined in ACP 123/STANAG 4406 Annex A.

s6: When switching to ACP from STANAG reference probably need to tweak this too because Annex G is about message store attributes.  ACP 123 doesn't include a profile for PCT, but it is included by reference.

  The X.400 message MAY be signed according to ACP
  123 Annex B and Annex G.

So maybe it has to be left off:

  The X.400 message MAY be signed according to ACP
  123 Annex B.

or not use MAY maybe r/MAY/might and then you could do:

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

s7: ACP 123 doesn't have an APS/MMHS Annex D.  I think you need to remove the following:

  In the absence of this mapping, it is recommended that these
  heading should be mapped to ACP 123 and hence into ACP 127 following
  the Annex D (Gateway Translation) of [ACP123].

Also if you don't have this does the last sentence of the abstract need to be removed?
2011-10-22
08 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-10-22
05 (System) New version available: draft-melnikov-mmhs-header-fields-05.txt
2011-10-20
08 Cindy Morgan Removed from agenda for telechat
2011-10-20
08 Cindy Morgan State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation.
2011-10-20
08 Sean Turner
[Ballot discuss]
This is further updated discuss.

Despite the length of these I believe a draft that translates MM-header fields to RFC5322-header fields is …
[Ballot discuss]
This is further updated discuss.

Despite the length of these I believe a draft that translates MM-header fields to RFC5322-header fields is publishable.

#1) STANAG 4006 is listed as a normative reference.  It's not available on the NATO site (http://www.nato.int/cps/en/SID-8BF0F167-D3248540/natolive/stanag.htm).  It was on Graeme's company site, but the link doesn't seem to work.  I couldn't find it on other publicly available sites (maybe I didn't look hard enough).  I have two questions that I think go to the need for normative references to be publicly available:

a) Is this document actually publicly/widely available?  Assuming it can't be had on the Internet, I know that you can get hard copies IF you contact your NATO-member national body (e.g., UK MoD, USA DoD) (kind of like asking a publisher to give you a copy of a book/article they published - but I don't think these publishers will charge you - not sure about this though).  However, how is somebody who lives in a country that is not part of NATO going to get a hard copy?  Will NATO respond to queries for STANAG's from people who have non-NATO nationalities or who don't live in NATO member states?  I've got not idea - just asking.

b) Is the version on Graeme's company site official and final?  If not shouldn't "draft" appear in the reference?

If Graeme's site doesn't have active links and NATO won't give it to folks who live in non-NATO countries - is STANAG 4406 really available?

If STANAG 4406 doesn't seem like a viable reference you could switch the whole thing around to refer to ACP 123 - it's available online.

#2) 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: *=primary or copy (note there's a related comment about the second part, but I thought I'd give it all to you here):
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 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].

#3) I pulled out my handy-dandy copy of ACP 123 and noted that the value range for precedence (primary and copy) as well as message type are entirely reserved for NATO and national use.  How will additions be handled?  Is the IESG or IANA going to tell non-NATO national entities they can't define values in that space?  For example, New Zealand comes along and wants to add "faster than sheep" as a precedence as 6 - what happens?

More specifically:

I think you to say that the values for those fields are assigned by NATO and Nations.  The ACP has the following text about these extensions:

Precedence:

  Note: Values 0 to 15 are reserved for NATO defined precedence
  levels.  Values 16 to 31 are reserved for national user.

Message Type:

  Note: Values 0 to 127 are reserved for NATO defined Message Type
  identifiers. Values above 128 to 255 are not defined by NATO and
  may be used nationally or bilaterally.

Should this be included in this document?  Maybe something along the lines of:

  Additional NATO defined precedence values (6-15) and nationally
  defined precedence values (16-31) are not supported, and their use is
  considered to be out of scope.

ditto for message type.

#4) cleared

#5) s5 contains the following text:

  A few capabilities have been left out which would
  have significantly increased the complexity of this specification,
  and do not appear to be of significant benefit.

I'm not entirely sure you can say the last bit without an additional qualifier like: (in the eyes of the authors who don't speak for NATO or any nation that's a part of NATO).  Unless of course you are?  Maybe you can just delete the last bit.

There's also the second sentences for distribution codes and pilot forwarding info:

  Distribution
  extensions are not widely used, and encoding ANY DEFINED BY in this
  specification would be difficult.

  This complex
  extension is only for ACP 127 transition, and is not widely used.

You know this for absolutely sure?  This sounds like you're speaking authoritatively for NATO and I'm not sure you can.  You could just list the ones you didn't map and leave it at that.
2011-10-20
08 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2011-10-20
08 Russ Housley
[Ballot comment]
I think the tone of the Abstract sends the wrong message to the
  reader.  I suggest the following re-write:

  OLD:

  …
[Ballot comment]
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.
2011-10-20
08 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded
2011-10-20
08 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2011-10-20
08 Jari Arkko
[Ballot comment]
I agree with the issues raised on the normative reference. These should be available. Also, the document says:

> Note: There is no …
[Ballot comment]
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....
2011-10-20
08 Jari Arkko
[Ballot comment]
I agree with the issues raised on the normative reference. These should be available. Also, the document says:

> Note: There is no …
[Ballot comment]
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 its not my army, so....
2011-10-20
08 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded
2011-10-20
08 Sean Turner
[Ballot comment]
#1) a/s1: Expand STANAG: Standardization Agreement (STANAG)

#2) s1: Pretty sure STANAG 4406 never uses the term "military mail". Suggest "military messaging (MM)" …
[Ballot comment]
#1) a/s1: Expand STANAG: Standardization Agreement (STANAG)

#2) s1: Pretty sure STANAG 4406 never uses the term "military mail". Suggest "military messaging (MM)" instead.

#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) s1: If there are other aims where are they listed?  Maybe just remove the word "primary" from the 1st sentence in the 3rd para.

#6) s2: Contains the following:

  The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC5234]
  notation including the core rules defined in Appendix B of RFC 5234
  [RFC5234].

Maybe r/use/uses

#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) 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) s3.7: I'm not sure you got the example right (though I could be wrong).  I don't think UNCLAS should be there.  That's part of the rest of the format line/message, but it's not part of the reference.

#11) s3.8 and s3.9: r/should/SHOULD in the following?:

  i.e. a Military Message with higher MMHS-
  *-Precedence header field value should be handled before a
  Military Message with a lower MMHS-*-Precedence header field
  value.

#12) s3.8 and s3.9: r/shall/SHALL in the following?:

  The message originating domain shall ensure that ...

Kind of like the should for the extended authorization information?


#13) s3.8 and 3.9: Why add the unnecessary complexity of allowing integers or the string?  Why not just pick one?  4406 is an integer ;)

#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) s3.13: I know a lot of these got copied, but this one doesn't make sense:

  The ACP127 message identifier header field, by its presence indicates
  an ACP 127 message identifier [ACP127] which originated from an ACP
  127 domain.  If this extension is absent, then the message did not
  encounter an ACP 127 domain.

This is a little confusing to me.  Maybe:

  The ACP127 message identifier header field, by its presence, indicates
  an ACP 127 message identifier [ACP127] for a message that originated
  from an ACP 127 domain.  If this extension is absent, then the message
  did not encounter in an ACP 127 domain.

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

#17) s3.14: 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) s4: The following appears in the ABNF, but I'm not sure it's used:

  DesignatorType = "primary" / "copy"

#20) s5: What no discussing about the clear EoS? :)

#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) s6: r/should/SHOULD in the following (or is it in 2156?):

  OR Names should be
  mapped with Internet Email addresses according to [RFC2156].

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


#24) s10.1 and s10.2: Should probably add (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.
2011-10-20
08 Sean Turner
[Ballot discuss]
This is an updated discuss.

Despite the length of these I believe a draft that translates MM-header fields to RFC5322-header fields is …
[Ballot discuss]
This is an updated discuss.

Despite the length of these I believe a draft that translates MM-header fields to RFC5322-header fields is publishable.

#1) STANAG 4006 is listed as a normative reference.  It's not available on the NATO site (http://www.nato.int/cps/en/SID-8BF0F167-D3248540/natolive/stanag.htm).  It was on Graeme's company site, but the link doesn't seem to work.  I couldn't find it on other publicly available sites (maybe I didn't look hard enough).  I have two questions that I think go to the need for normative references to be publicly available:

a) Is this document actually publicly/widely available?  Assuming it can't be had on the Internet, I know that you can get hard copies IF you contact your NATO-member national body (e.g., UK MoD, USA DoD) (kind of like asking a publisher to give you a copy of a book/article they published - but I don't think these publishers will charge you - not sure about this though).  However, how is somebody who lives in a country that is not part of NATO going to get a hard copy?  Will NATO respond to queries for STANAG's from people who have non-NATO nationalities or who don't live in NATO member states?  I've got not idea - just asking.

b) Is the version on Graeme's company site official and final?  If not shouldn't "draft" appear in the reference?

If Graeme's site doesn't have active links and NATO won't give it to folks who live in non-NATO countries - is STANAG 4406 really available?

If STANAG 4406 doesn't seem like a viable reference you could switch the whole thing around to refer to ACP 123 - it's available online.

#2) 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: *=primary or copy (note there's a related comment about the second part, but I thought I'd give it all to you here):
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 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].

#3) I pulled out my handy-dandy copy of ACP 123 and noted that the value range for precedence (primary and copy) as well as message type are entirely reserved for NATO and national use.  How will additions be handled?  Is the IESG or IANA going to tell non-NATO national entities they can't define values in that space?  For example, New Zealand comes along and wants to add "faster than sheep" as a precedence as 6 - what happens?

#4) cleared

#5) s5 contains the following text:

  A few capabilities have been left out which would
  have significantly increased the complexity of this specification,
  and do not appear to be of significant benefit.

I'm not entirely sure you can say the last bit without an additional qualifier like: (in the eyes of the authors who don't speak for NATO or any nation that's a part of NATO).  Unless of course you are?  Maybe you can just delete the last bit.

There's also the second sentences for distribution codes and pilot forwarding info:

  Distribution
  extensions are not widely used, and encoding ANY DEFINED BY in this
  specification would be difficult.

  This complex
  extension is only for ACP 127 transition, and is not widely used.

You know this for absolutely sure?  This sounds like you're speaking authoritatively for NATO and I'm not sure you can.  You could just list the ones you didn't map and leave it at that.
2011-10-20
08 Jari Arkko
[Ballot comment]
> Note: There is no guarantee that the exempted
> addresses will not receive the message as the result of redirection,
> Distribution …
[Ballot comment]
> 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 its not my army, so....
2011-10-19
08 Peter Saint-Andre
[Ballot comment]
Several reviewers have provided very detailed feedback, so I am restricting my comments to a few small points in the text.

1. Is …
[Ballot comment]
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?
2011-10-19
08 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded
2011-10-18
08 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded
2011-10-17
08 Adrian Farrel
[Ballot comment]
Section 1

  This document enables the provision of most of the elements of
  service defined in STANAG 4406 [STANAG-4406] for Internet …
[Ballot comment]
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.
2011-10-17
08 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded
2011-10-16
08 Sean Turner
[Ballot comment]
#1) a/s1: Expand STANAG: Standardization Agreement (STANAG)

#2) s1: Pretty sure STANAG 4406 never uses the term "military mail". Suggest "military messaging (MM)" …
[Ballot comment]
#1) a/s1: Expand STANAG: Standardization Agreement (STANAG)

#2) s1: Pretty sure STANAG 4406 never uses the term "military mail". Suggest "military messaging (MM)" instead.

#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 SMTP-header fields?

#4) s1: expand IPMS

#5) s1: If there are other aims where are they listed?  Maybe just remove the word "primary" from the 1st sentence in the 3rd para.

#6) s2: Contains the following:

  The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC5234]
  notation including the core rules defined in Appendix B of RFC 5234
  [RFC5234].

Maybe r/use/uses

#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) 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) s3.7: I'm not sure you got the example right (though I could be wrong).  I don't think UNCLAS should be there.  That's part of the rest of the format line/message, but it's not part of the reference.

#11) s3.8 and s3.9: r/should/SHOULD in the following?:

  i.e. a Military Message with higher MMHS-
  *-Precedence header field value should be handled before a
  Military Message with a lower MMHS-*-Precedence header field
  value.

#12) s3.8 and s3.9: r/shall/SHALL in the following?:

  The message originating domain shall ensure that ...

Kind of like the should for the extended authorization information?


#13) s3.8 and 3.9: Why add the unnecessary complexity of allowing integers or the string?  Why not just pick one?  4406 is an integer ;)

#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) s3.13: I know a lot of these got copied, but this one doesn't make sense:

  The ACP127 message identifier header field, by its presence indicates
  an ACP 127 message identifier [ACP127] which originated from an ACP
  127 domain.  If this extension is absent, then the message did not
  encounter an ACP 127 domain.

This is a little confusing to me.  Maybe:

  The ACP127 message identifier header field, by its presence, indicates
  an ACP 127 message identifier [ACP127] for a message that originated
  from an ACP 127 domain.  If this extension is absent, then the message
  did not encounter in an ACP 127 domain.

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

#17) s3.14: 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) s4: The following appears in the ABNF, but I'm not sure it's used:

  DesignatorType = "primary" / "copy"

#20) s5: What no discussing about the clear EoS? :)

#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) s6: r/should/SHOULD in the following (or is it in 2156?):

  OR Names should be
  mapped with Internet Email addresses according to [RFC2156].

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


#24) s10.1 and s10.2: Should probably add (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.
2011-10-16
08 Sean Turner
[Ballot discuss]
Despite the length of these I believe a draft that translates MM-header fields to RFC5322-header fields is publishable.

#1) STANAG 4006 is …
[Ballot discuss]
Despite the length of these I believe a draft that translates MM-header fields to RFC5322-header fields is publishable.

#1) STANAG 4006 is listed as a normative reference.  It's not available on the NATO site (http://www.nato.int/cps/en/SID-8BF0F167-D3248540/natolive/stanag.htm).  It was on Graeme's company site, but the link doesn't seem to work.  I couldn't find it on other publicly available sites (maybe I didn't look hard enough).  I have two questions that I think go to the need for normative references to be publicly available:

a) Is this document actually publicly/widely available?  Assuming it can't be had on the Internet, I know that you can get hard copies IF you contact your NATO-member national body (e.g., UK MoD, USA DoD) (kind of like asking a publisher to give you a copy of a book/article they published - but I don't think these publishers will charge you - not sure about this though).  However, how is somebody who lives in a country that is not part of NATO going to get a hard copy?  Will NATO respond to queries for STANAG's from people who have non-NATO nationalities or who don't live in NATO member states?  I've got not idea - just asking.

b) Is the version on Graeme's company site official and final?  If not shouldn't "draft" appear in the reference?

If Graeme's site doesn't have active links and NATO won't give it to folks who live in non-NATO countries - is STANAG 4406 really available?

If STANAG 4406 doesn't seem like a viable reference you could switch the whole thing around to refer to ACP 123 - it's available online.

#2) 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 SMTP-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: *=primary or copy (note there's a related comment about the second part, but I thought I'd give it all to you here):
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 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].

#3) I pulled out my handy-dandy copy of ACP 123 and noted that the value range for precedence (primary and copy) as well as message type are entirely reserved for NATO and national use.  How will additions be handled?  Is the IESG or IANA going to tell non-NATO national entities they can't define values in that space?  For example, New Zealand comes along and wants to add "faster than sheep" as a precedence as 6 - what happens?

#4) I expect this one ought to be cleared on or before the call.  s3: I was expecting the header names in the table to match the MM-header fields.

a) It might not be required but would it just make more sense?  For example why wouldn't name MMHS-Subject-Indicator-Codes MMHS-Distribution-Codes and then say in that header's section: we only do SICs?

b) (I expect there's a really good reason for this one and I just don't know it) Wouldn't it be clearer to just have MMHS-Other-Recipient-Indicator as opposed to splitting it in to MMHS-Other-Recipients-Indicator-To/MMHS-Other-Recipients-Indicator-Cc.

#5) s5 contains the following text:

  A few capabilities have been left out which would
  have significantly increased the complexity of this specification,
  and do not appear to be of significant benefit.

I'm not entirely sure you can say the last bit without an additional qualifier like: (in the eyes of the authors who don't speak for NATO or any nation that's a part of NATO).  Unless of course you are?  Maybe you can just delete the last bit.

There's also the second sentences for distribution codes and pilot forwarding info:

  Distribution
  extensions are not widely used, and encoding ANY DEFINED BY in this
  specification would be difficult.

  This complex
  extension is only for ACP 127 transition, and is not widely used.

You know this for absolutely sure?  This sounds like you're speaking authoritatively for NATO and I'm not sure you can.  You could just list the ones you didn't map and leave it at that.
2011-10-16
08 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded
2011-10-13
08 Stephen Farrell
[Ballot comment]
- It seems a bit odd that this is informational - I'd have
expected the consumers of this to require a standards track …
[Ballot comment]
- 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.
2011-10-13
08 Stephen Farrell
[Ballot discuss]
I'm not sure I agree there are no new security considerations here
given that these header fields are not protected by S/MIME but …
[Ballot discuss]
I'm not sure I agree there are no new security considerations here
given that these header fields are not protected by S/MIME but are
(I think, maybe I remember wrong) signed in X.400 MMHS or
ACP .  Am I right there?

If so with a message like this I could for example delete the
MMHS-Exempted-Address header field for example and bad stuff
might happen. In that case, you probably need to include some
analysis of the potential bad things and might want to RECOMMEND
signing with DKIM perhaps.

If I'm wrong and the equivalent 4406 extensions cannot be
signed then I agree there's nothing much new here and will
clear.
2011-10-13
08 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded
2011-10-12
08 Pete Resnick State changed to IESG Evaluation from Waiting for AD Go-Ahead.
2011-10-12
08 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-10-10
08 Samuel Weiler Request for Last Call review by SECDIR is assigned to Sam Hartman
2011-10-10
08 Samuel Weiler Request for Last Call review by SECDIR is assigned to Sam Hartman
2011-09-23
08 Amanda Baber

IANA understands that, upon approval of this document, there is a single
IANA action which must be completed.

In the Permanent Message Header Field Names …

IANA understands that, upon approval of this document, there is a single
IANA action which must be completed.

In the Permanent Message Header Field Names registry located at:

http://www.iana.org/assignments/message-headers/perm-headers.html

fourteen new registrations need to be added as follows:

Header Field Name Protocol Status Reference
------------------------------- --------- ------------- --------------
MMHS-Exempted-Address mail informational [ RFC-to-be ]
MMHS-Extended-Authorisation-Info mail informational [ RFC-to-be ]
MMHS-Subject-Indicator-Codes mail informational [ RFC-to-be ]
MMHS-Handling-Instructions mail informational [ RFC-to-be ]
MMHS-Message-Instructions mail informational [ RFC-to-be ]
MMHS-Codress-Message-Indicator mail informational [ RFC-to-be ]
MMHS-Originator-Reference mail informational [ RFC-to-be ]
MMHS-Primary-Precedence mail informational [ RFC-to-be ]
MMHS-Copy-Precedence mail informational [ RFC-to-be ]
MMHS-Message-Type mail informational [ RFC-to-be ]
MMHS-Other-Recipients-Indicator-To mail informational [ RFC-to-be ]
MMHS-Other-Recipients-Indicator-Cc mail informational [ RFC-to-be ]
MMHS-Acp127-Message-Identifier mail informational [ RFC-to-be ]
MMHS-Originator-PLAD mail informational [ RFC-to-be ]

IANAN understands that, upon approval of this document, registration of
these fourteen header field names is the only IANA Action required.
2011-09-14
08 Amy Vezza Last call sent
2011-09-14
08 Amy Vezza
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 …
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:  (Registration of Military Message Handling System (MMHS) header fields for use in Internet Mail) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Registration of Military Message Handling System (MMHS) header fields
  for use in Internet Mail'
  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-10-12. 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.

Abstract


  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.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-melnikov-mmhs-header-fields/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-melnikov-mmhs-header-fields/


No IPR declarations have been submitted directly on this I-D.


2011-09-14
08 Pete Resnick Placed on agenda for telechat - 2011-10-20
2011-09-14
08 Pete Resnick [Ballot Position Update] New position, Yes, has been recorded for Pete Resnick
2011-09-14
08 Pete Resnick Ballot has been issued
2011-09-14
08 Pete Resnick Created "Approve" ballot
2011-09-14
08 Pete Resnick State Change Notice email list has been changed to BonattiC@ieca.com, alexey.melnikov@isode.com, graeme.lunt@smhs.co.uk, draft-melnikov-mmhs-header-fields@tools.ietf.org from alexey.melnikov@isode.com, graeme.lunt@smhs.co.uk, draft-melnikov-mmhs-header-fields@tools.ietf.org
2011-09-14
08 Pete Resnick Last Call was requested
2011-09-14
08 Pete Resnick State changed to Last Call Requested from Waiting for Writeup.
2011-09-14
08 Pete Resnick Last Call text changed
2011-09-14
08 (System) Ballot writeup text was added
2011-09-14
08 (System) Last call text was added
2011-09-14
08 (System) Ballot approval text was added
2011-09-14
08 Pete Resnick Approval announcement text regenerated
2011-09-14
08 Pete Resnick Ballot writeup text changed
2011-09-14
08 Pete Resnick
  Document Shepherd Statement for draft-melnikov-mmhs-header-fields

(1.a) Chris Bonatti is the Document Shepherd for the document. He is a
co-author of several different military messaging …
  Document Shepherd Statement for draft-melnikov-mmhs-header-fields

(1.a) Chris Bonatti is the Document Shepherd for the document. He is a
co-author of several different military messaging standards outside the
IETF including STANAG 4406, and is therefore highly knowledgable in this
problem space. He has reviewed the -02 version of this document, and
confirmed the changes to the latest version (-04) addresed the
outstanding nit problems.

(1.b) The document has had sufficient review both within the IETF and
in external military messaging circles. Individual reviewers represented
a cross section of SMTP and military messaging product vendors.

(1.c) There are no specific outstanding concerns. Several possible
implementation considerations exist, but they are adequately covered by
the document. Integrity is not provided for the new headers, but as
noted in section 6 this is difficult in a MIXER gateway scenario. The
draft does not introduce any new security considerations beyond those
inherent in the use of the MMHS header fields. The described headers
have limited potential for internationalization, as the desire for
gateway interoperability with STANAG 4406 limits the supportable
character set. There are also some differences between this draft and
MMHS standards in the representation of some header values (addresses).
However, the approach of this draft is consistent with MIXER and
represents the best that can be done to bridge the two dissimilar
environments.

(1.d) There is a potential concern that definition of these headers is
coming rather late in the life cycle of MMHS. MMHS deployments based on
STANAG 4406 appear to be nearing the end of their useful life. This is
primarily issue of whether there will be a sufficient demand for
products based on these definitions. However, this is a concern that is
beyond the scope of the proposed RFC. Existance of this RFC may serve to
hasten migration of military systems from STANAG 4406 to SMTP-based
products. It may also forestall creation of a potential myriad of
non-interoperable private mail headers. So the potential benefits
strongly outweigh any concerns.

(1.e) The universe of experts in military messaging is quite small.
Nevertheless, this draft has been reviewed by several specialists
involved with MMHS. I would characterize the level of consensus as
strong among a few individuals. The wider MMHS community does not appear
to be interested in the draft at present. However, this level of
consensus seems consistent with an information RFC. A wider review is
welcomed, but the appropriate venue for this isn't apparent to the
authors.

(1.f) There has been no dissension on this document.

(1.g) The latest version of the draft (-04) addresses all known nits.

(1.h) The document splits references into normative and informative.
All of the normative references specify documents that are BCPs or on
the standards track. The least mature of these is RFC 2156 (MIXER),
which is only a Proposed Standard. The referenced external standards
STANAG 4406 and ACP 127 are also fully approved and stable. Given that
MIXER has been stable since 1998, the references are considered
sufficient to support an informational RFC.

(1.i) Section 8 describes IANA considerations. It describes the need
to register the defined message header names in the IANA registry. This
is a one-time operation that requires no ongoing IANA support or
registration. None of the proposed new header names are taken in the
existing IANA registry.

(1.j) The ABNF for the headers has been reviewed by the authors, at
least a couple email product vendors, and the document Shepherd. It
appears to correct. The syntax also parsed successfully on Bill Fenner's
ABNF parsing tool.

(1.k)

Technical Summary

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.

Working Group Summary

The substance of the definitions in this draft is derived from the
military messaging heading elements defined in STANAG 4406. The comments
to date have consisted of corrections and minor amendments only.

The decision was made by the authors to exclude support for the
distribution extensions form of the Distribution-Codes heading
extension. This is noted in sections 3.3 and 6. However, this MMHS
feature is sparsely implemented and is not known to be in use within any
major military organization.

The decision was taken after the -01 draft to split the
MMHS-Other-Recipients-Indicator header into two separate headers
containing primary (to:) and copy (cc:) other recipients. This approach
varies from the approach in STANAG 4406, but is more consistent with the
RFC 822 style of address headers, and should be simpler for
implementations to process. It is not expected to create a significant
problem for gateway implementations.

Document Quality

At least three client implementations of this specification and one
server implementation exist. One client implementation is the open
source Thunderbird plugin. Another implementation is an Outlook plug-in
that was prepared by one of the authors.

Reviewers of the document are cited in Appendix A.
2011-09-07
08 Pete Resnick State changed to Waiting for Writeup from AD Evaluation.
2011-09-02
04 (System) New version available: draft-melnikov-mmhs-header-fields-04.txt
2011-08-26
08 Pete Resnick State changed to AD Evaluation from Publication Requested.
2011-08-25
03 (System) New version available: draft-melnikov-mmhs-header-fields-03.txt
2011-08-11
08 Pete Resnick Draft added in state Publication Requested
2011-07-11
02 (System) New version available: draft-melnikov-mmhs-header-fields-02.txt
2011-04-15
01 (System) New version available: draft-melnikov-mmhs-header-fields-01.txt
2011-03-07
00 (System) New version available: draft-melnikov-mmhs-header-fields-00.txt