Comments on 3023bis [all editorial]

On 2013-09-18 10:59, Paul Grosso wrote:
>
>>
>> 5.  XML Media types (3023bis)
>>
> The latest draft is at
> https://datatracker.ietf.org/doc/draft-ietf-appsawg-xml-mediatypes/
>
> Henry says that this draft needs positive feedback to proceed
> to the next step.  Henry asks that the XML Core WG send an official
> endorsement, perhaps with some minor suggestions.
>
> ACTION to Paul:  Review 3023-bis.


I have reviewed it (again).  I have no substantive comments,
but many editorial comments, given below.

Henry, is this level of detail appropriate to send in to
the IETF, or is this just something you, as editor, will
handle?

paul

======================


Section 3, first para on page 6, it reads:

  ...In particular, for transports other than HTTP [RFC2616] or HTTPS
  (which uses a MIME-like mechanism).  the UTF-16 family, UCS-4, and
  UTF-32 are not allowed However, ...

I'm guessing the period should be a comma and there should be a
period (full stop) added before "However".

----

Section 3.1, Interoperability considerations (page 7)

There is a use of the word "recommended" that is not
capitalized.  I don't know if this is a 2119 use and
if so if it should be capitalized.

----

Section 3.1, Change controller (page 8) reads:

  The XML specification is a work product of the
  World Wide Web Consortium's XML Working Group

If we were referring to the February 1998 version, the WG at
that time was called the XML Working Group (though the document
itself says the spec was a product of the XML Activity).  But
given that the reference to the XML spec is to the 5th Edition,
and that we are talking about the (supposedly current) change
controller, I think you want to refer to the "XML Core Working
Group" here.

----

Section 3.3, Change controller (page 9)

Ibid.

----

Section 3.5, Change controller (page 10)

Ibid.

----

Section 3.6 Charset considerations, second para (page 10)

There is a use of the word "recommended" that is not
capitalized.  I don't know if this is a 2119 use and
if so if it should be capitalized.

----

Section 5 Fragment Identifiers, second para, penultimate
sentence (page 12) reads in part:

  conformant applications MUST
  interpret such fragment identifiers as designating that part of the
  retrieved representation specified by [XPointerFramework] and
  whatever other specifications define any XPointer schemes used.

Maybe it's just me, but I cannot parse the last part of that sentence.

----

Section 8.2, Change controller (page 16)

Op. Cit. previous comment on Change controller.

----

Section 9 Examples, last sentence before section 9.1 reads in part:

  ...reproduces or summarizes the consequences of normative
  statement already made above...

Either pluralize "statement" or insert "a" before "normative".

----

Section 9.4, last para contains "---".  I'm not sure what
a triple dash means, nor am I convinced this is a place for
an emdash (aka double dash).  I would probably use a semi-colon
here.

----

Section 9.5, first sentence of the "In this example" para:
s/the is no/there is no/

----

Section 9.9 INCONSISTENT EXAMPLE.

I don't know why the title of this section is not bold.
I don't suppose it matters, but it looks odd.  (It is,
intriguingly self-referentially, inconsistent.)

----

Section 11, Security Considerations, first para, second
sentence would be easier to parse with appropriately
added punctuation, to wit:

  These entities may contain--and such systems may
  permit--explicit system level commands to be
  executed while processing the data.

----

Section 11, Security Considerations, very last "sentence"
is not a sentence and does not contain a period (full stop).

Perhaps insert at the start of the parenthesized text the
phrase "Consider the case where" and insert a period before
the close parenthesis.


----

Section 12.1 Normative References, the [XptrReg] (last) reference.

This refers to the web page
http://www.w3.org/2005/04/xpointer-schemes/
which is not an RFC, standard, or W3C Recommendation,
so I question if this can be a normative reference.

What are the rules for what can be a normative reference
in an IETF RFC?  Perhaps this should be moved to the
informative references section.

----

Appendix B. Changes from RFC 3023, second para, first sentence

missing close paren

----

paul