Subject: [Gen-art] Review of draft-westerlund-mime-dls-01

From: "Tom-PT Taylor" <[email-masked]>
Date: Sat, 25 Mar 2006 12:13:16 -0500

The subject draft is a reasonable contribution to the are of Internet 
engineering which it covers. It has editorial issues which should be 
fixed before it is approved.

The major issue is that, despite the presence of an acceptable Security 
Considerations section (section 2), the registration in section 3.1 
points to the Security Considerations section of RFC XXXX. Section 4 is 
an RFC Editor's note requesting the substitution of the proper number 
for RFC XXXX. There is no RFC XXXX in the references. Undoubtedly this 
was the result of a change of plan.

I had two minor editorial comments:

In section 2, third paragraph, third line, the phrase "it is stressed" 
caused a momentary glitch in my mind: "Where is it stressed?". Perhaps 
the sentence might read better if it were phrased:

"A key point is that conditional chunks are optional, that is to say a 
parser does not have to execute a conditional chunk."

The other item is an extra "the" in the first line of "Interoperability 
Considerations" in section 3.1.

Tom Taylor

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Magnus Westerlund <[email-masked]>
Date: Sun, 26 Mar 2006 07:55:57 +0200

Hi,

Thanks for the review, my comments as an author.

> was the result of a change of plan.

Sorry, the RFC XXXX is the number the document under review will 
receive. We clearly screwed up the clarity of the RFC-editor note. In 
addition there is the wrong section reference in the template. I propose 
that this is fixed with the following RFC-editor note. The reasons for 
the use of XXXX is to enable the cut and paste of the template to 
somewhere else if needed.

Section 3.1:
OLD:
    Security considerations:           see the security considerations
                                       in section 3 of RFC XXXX.

NEW:

    Security considerations:           see the security considerations
                                       in section 2 of RFC XXXX.
                                                  ^

Section 4:

OLD:
    The references to RFC XXXX in the media type registration need to
    be replaced with the actual RFC number when it is issued.

NEW:
    The references to RFC XXXX in the media type registration need to
    be replaced with the actual RFC number this document receives when
    it is issued.

> parser does not have to execute a conditional chunk."

Good proposal.

Section 2, third paragraph::

OLD:
    For DLS content containing
    conditional chunks it is stressed that the chunk in question is
    optional, that is to say a parser does not have to execute the
    chunk.

NEW:
    A key point is that conditional chunks are optional, that is to say a
    parser does not have to execute a conditional chunk.

> Considerations" in section 3.1.

Section 3.1, Interoperability Considerations

OLD:
    Interoperability considerations:   This media type is for the
                                       consumption by a MIDI player

NEW:
    Interoperability considerations:   This media type is for
                                       consumption by a MIDI player

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Mon, 27 Mar 2006 14:06:15 -0800

I have the added the RFC Editor notes Magnus proposed to the ballot, so
that they will be considered by the IESG during Thursday's telechat.
			regards,
				Ted Hardie

At 7:55 AM +0200 3/26/06, Magnus Westerlund wrote:
>>The subject draft is a reasonable contribution to the are of Internet engineering which it covers. It has editorial issues which should be fixed before it is approved.
>>
>>The major issue is that, despite the presence of an acceptable Security Considerations section (section 2), the registration in section 3.1 points to the Security Considerations section of RFC XXXX. Section 4 is an RFC Editor's note requesting the substitution of the proper number for RFC XXXX. There is no RFC XXXX in the references. Undoubtedly this was the result of a change of plan.
>
>Sorry, the RFC XXXX is the number the document under review will receive. We clearly screwed up the clarity of the RFC-editor note. In addition there is the wrong section reference in the template. I propose that this is fixed with the following RFC-editor note. The reasons for the use of XXXX is to enable the cut and paste of the template to somewhere else if needed.
>
>Section 3.1:
>OLD:
>>In section 2, third paragraph, third line, the phrase "it is stressed" caused a momentary glitch in my mind: "Where is it stressed?". Perhaps the sentence might read better if it were phrased:
>>
>>"A key point is that conditional chunks are optional, that is to say a parser does not have to execute a conditional chunk."
>
>Good proposal.
>
>>The other item is an extra "the" in the first line of "Interoperability Considerations" in section 3.1.
>