Registration of Military Message Handling System (MMHS) Header Fields for Use in Internet Mail
draft-melnikov-mmhs-header-fields-08
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
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 |
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 |