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:
>Hi,
>
>Thanks for the review, my comments as an author.
>
>Tom-PT Taylor 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:
> 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.
>
>
>>
>>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."
>
>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.
>
>
>>
>>The other item is an extra "the" in the first line of "Interoperability
>>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 PROTECTED]
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
