Subject: Re: Last Call: <draft-melnikov-mmhs-header-fields-04.txt> (Registrationof Military Message Handling System (MMHS) header fields foruse in Internet Mail) to Informational RFC

From: "t.petch" <[email-masked]>
Date: Thu, 15 Sep 2011 09:47:34 +0200

I notice that section 3, to which IANA are directed, contains many formulations
such as
"   Specification document(s): [[anchor14: this document]]"

Would I be right in thinking that this is what other documents would refer to as
" RFCXXXX
-- Note to RFC-Editor - replace RFCXXXX by the RFC Number assigned to this
document"
?

Tom Petch

----- Original Message -----
From: "The IESG" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Sent: Wednesday, September 14, 2011 9:53 PM
Subject: Last Call: <draft-melnikov-mmhs-header-fields-04.txt> (Registrationof
Military Message Handling System (MMHS) header fields foruse 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'
>   <draft-melnikov-mmhs-header-fields-04.txt> 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
> [email-masked] mailing lists by 2011-10-12. Exceptionally, comments may be
> sent to [email-masked] 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.
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 15 Sep 2011 09:59:30 +0100

>-- Note to RFC-Editor - replace RFCXXXX by the RFC Number assigned to this
Yes, that was the intent.

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 15 Sep 2011 18:18:07 +0300

>> -- Note to RFC-Editor - replace RFCXXXX by the RFC Number assigned to 

There is no significant difference between these forms.  I don't think 
this is an issue which we need to care about.

Mykyta

> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 15 Sep 2011 17:18:28 +0100

> this is an issue which we need to care about.

Agreed. I think RFC Editor can figure this out.

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 15 Sep 2011 19:46:49 +0300

So some small comments:

1) A nit in Change controller field for all the header fields: you 
should either change it to IESG ([email-masked]) or IETF with subsequent 
address [email-masked].

2) Also, it might be useful to point out in the sub-sections of Section 
3 which ABNF productions do the header fields match.

3) Section 4:

>   Terms not defined here are taken from [RFC5322] and [RFC2156].

You probably missed RFC 5234 (with e. g. <DQUOTE>) here.

Some ABNF nits:

4)

>      military-string = 1*69( ps-char )

No harm to change it to "1*69ps-char"

5)

>      std-precedence = "deferred" / "routine" / "priority" /
>                       "immediate" / "flash" / "override"
>      std-message-type = "exercise" / "operation" / "project" /  "drill"

Is there an ability to extend the allowed range of parameters here?

6)

>      nonneg-integer = "0" / (NZ-DIGIT *DIGIT)

Should this be

>      nonneg-integer = "0" / ( [ "+" ] NZ-DIGIT *DIGIT)

as non-negative integer implies that it may be prepended by "+" (as well 
as zero - I don't know exactly).

7)

>      military-string-sequence = military-string
>                          [ [FWS] ";" [FWS] military-string-sequence ]

I think

>      military-string-sequence = military-string
>                          [ [FWS] ";" [FWS] military-string ]

is just the same but improves readability (unless you make this 
intentionally, but I see no reason).

8)

>      Subject-Indicator-Codes = "MMHS-Subject-Indicator-Codes:"
>                                [FWS] [sic-sequence] [FWS] CRLF

Can the header field appear to be:

>      MMHS-Subject-Indicator-Codes:

as you allow.  Maybe removing [] around sic-sequence?

9) I'd like you hereby disallowed further registration of header fields 
beginning with "MMHS", likewise RFC 5504 "Downgraded" prefix 
(http://tools.ietf.org/html/rfc5504#page-18).

Mykyta Yevstifeyev

---

From: Julian Reschke <[email-masked]>
Date: Thu, 15 Sep 2011 19:11:45 +0200

On 2011-09-15 18:46, Mykyta Yevstifeyev wrote:
> ...
> ...

No. It's a bad idea in RFC 5504, and it would be a bad idea here.

Best regards, Julian

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 15 Sep 2011 14:47:25 -0600

> No. It's a bad idea in RFC 5504, and it would be a bad idea here.

+1 to that!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: [email-masked]
Date: Fri, 16 Sep 2011 06:53:08 -0700 (PDT)

> No. It's a bad idea in RFC 5504, and it would be a bad idea here.

Agreed. Bad idea.

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 17 Sep 2011 15:44:41 +0100

Hi Mykyta,
Thank you for the review. My answers are below.

Mykyta Yevstifeyev wrote:

> should either change it to IESG ([email-masked]) or IETF with 
> subsequent address [email-masked].

I don't think this is a big deal either way, but I've changed to IESG.

> 2) Also, it might be useful to point out in the sub-sections of 
> Section 3 which ABNF productions do the header fields match.
>
> 3) Section 4:
>

Right.

> No harm to change it to "1*69ps-char"

No, but the original is a bit more readable.

> Is there an ability to extend the allowed range of parameters here?

No. Numeric values are for extensibility.

> as non-negative integer implies that it may be prepended by "+" (as 
> well as zero - I don't know exactly).

I would rather leave this as is, there is no need for "+" and some 
people already implemented the currect ABNF.

> intentionally, but I see no reason).

The original definition is recursive. What you've suggested is 
incorrect, because it only allowes 2 values (with optional FWS, etc. in 
between).

So the correct form would be:

military-string-sequence = military-string
                         *( [FWS] ";" [FWS] military-string )

> as you allow.  Maybe removing [] around sic-sequence?

Yes, good point. Another person also pointed this out.

> 9) I'd like you hereby disallowed further registration of header 
> fields beginning with "MMHS", likewise RFC 5504 "Downgraded" prefix 

I think other people already commented on this. So no change.

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 17 Sep 2011 17:48:41 +0300

I'm fine with your judgment of what to incorporate or not.  Mykyta

17.09.2011 17:44, Alexey Melnikov wrote:
> incorrect, because it only allowes 2 values (with optional FWS, etc. 
> in between).
>