Re: [apps-discuss] Comments on draft-ietf-appsawg-xml-mediatypes-06

[[e-mail] (Henry S. Thompson)]

S Moonesamy writes:

> I have a few comments on draft-ietf-appsawg-xml-mediatypes-06.

Sorry I missed these in my review for draft -07!

> In Section 3.1:
>
>   "XML-unaware MIME producers MUST NOT supply a charset parameter with
>    an XML MIME entity unless the entity's character encoding is reliably
>    known."
>
> The title of that section is "XML MIME producers".  The above states a
> (RFC 2119) requirement for a "XML-unaware MIME producer".  Can an
> agent which is not capable of processing XML MIME entities and
> detecting the XML encoding declaration follow the requirement, and
> does the requirement even apply given that the requirements being
> specified are for XML MIME producers?

So, good point -- There's a subtle issue here which I should try to
clarify.  We have

 MIME agents (producers or consumers)
  1) Which are also XML processors, i.e. XML-aware
  2) Which are not XML processors, i.e. not XML-aware
     2a) Which are none-the-less good MIME citizens, i.e. they try to
         conform to _all_ media-type registrations to the extent that
         they can, and they are therefore trying to conform to this one.
     2b) The real ignorant remnant, for whom by definition nothing
          here is relevant.

How much detail is needed in this regard in the spec?

> As a nit, the unless clause in the requirement (sentence) seems odd.
> It may be simpler to set requirements for "XML-aware" MIME producers
> only.

Maybe, as for the following para., this is just too much of an
in-crowd thing.  What it _means_ to those of us who have struggled
with this situation for the last 10 years is "Sysadmins: do _not_
configure your apache servers to serve XML and/or XHTML with a charset
param of iso-8859-1 by default unless you _really_ know what your
users are shipping"

>   "XML MIME producers are RECOMMENDED to provide means for XML MIME
>    entity authors to determine what value, if any, is given to charset
>    parameters for their entities, for example by enabling user-level
>    configuration of filename-to-Content-Type-header mappings on a file-
>    by-file or suffix basis."
>
> The "entity authors" in the above is not clear.  Is it a person or an agent?

Person, but see reply to Tim Bray and above.

>   "The use of UTF-32 is NOT RECOMMENDED for XML MIME entities."
>
> I suggest having a short explanation about why the use of UTF-32 is
> not recommended instead of only saying that it is not recommended.

Care to suggest some wording?  Seriously, my understanding is that the
main reason is that most (all?) of the major browsers have removed
support for UTF-32, often citing security considerations which I don't
fully understand. . .  So, is something along the following lines
sufficient?

  UTF-32 is not widely supported, and security concerns about its use
  have been raised.  Accordingly, the use of [as before].

>   "XML-aware consumers MUST follow the requirements in section 4.3.3
>    of [XML] that directly address this case."
>
> This is a requirement by reference to an external specification.  I am
> listing this as it is unusual.

I could repeat it, but I hate duplicating normative prose. . .

>   "XML-unaware MIME consumers SHOULD NOT assume a default encoding in
>   this case."
>
> Would a XML-unaware MIME consumer be following this specification?

I hope so, see above.

> In Section 4.2:
>
>   'Interoperability considerations:  XML has proven to be interoperable
>       across both generic and task-specific applications and for import
>       and export from multiple XML authoring and editing tools.
>       Validating processors provide maximum interoperability.  Although
>       non-validating processors may be more efficient, they are not
>       required to handle all features of XML.  For further information,
>       see sub-section 2.9 "Standalone Document Declaration" and section
>       5 "Conformance" of [XML].'
>
> The paragraph is about interoperability considerations.  The text
> comes out as saying that "XML is great". :-)  Are there any
> interoperability issues to consider?  That's what the reader might
> wish to know.

Fair enough.  This is very old prose, which I hadn't touched.  At
least the UTF-8 advice should be repeated.

> In Section 8.1:
>
>   "Media subtypes that do not represent XML MIME entities
>    MUST NOT be allowed to register with a '+xml' suffix."
>
> It would be easier to say that the "+xml" suffix can only be
> registered for media subtypes that represent XML MIME entities.

I'll get rid of the double negation.

> Section 8.1 is about IANA registrations.  I would read it as guidance
> for IANA and people requesting a registration.  I suggest phrasing the
> relevant text from that perspective and moving that text into the IANA
> Considerations section.

Good idea -- I'll leave an introductory bit, so the 8.2 doesn't come
completely out of the blue.

> In Section 8.3:
>
>   'Registrations for new XML-based media types which do _not_ use the
>    '+xml' suffix SHOULD, in specifying the charset parameter and
>    encoding considerations, define them as: "Same as [charset parameter
>    / encoding considerations] of application/xml as specified in RFC
>    XXXX."'
>
> Why is this a RFC 2119 "should"?
>
>   "These registrations SHOULD also make reference to RFC XXXX in
>    specifying magic numbers, base URIs, and use of the BOM."
>
> I suggest rephrasing this as guidance and not as a RFC 2119
> recommendation.  Please note that I do not have a strong opinion about
> this as it may be a matter of style.

You're probably right, in both cases.

>   "These registrations MAY reference the application/xml registration in
>    RFC XXXX in specifying interoperability and fragment identifier
>    considerations, if these considerations are not overridden by issues
>    specific to that media type."
>
> Why is this a RFC 2119 "may"?

And this one.

> I suggest moving the examples in Section 9 to an appendix.

They were in a main section in 3023, and I'd rather not -- do you feel
strongly?  Does anyone else, either way?

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: [phone], e-mail: [e-mail]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]