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

[S Moonesamy <[e-mail]>]

Hi Henry,
At 07:23 11-02-2014, Henry S. Thompson wrote:
> > In Section 3.1:
>
>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?

A good MIME citizen (2a) can try to conform to all media-type 
registrations.  It is not possible to do that in practice as there 
can be new media-type registrations after the code is deployed.  It 
is also more work for the implementer as he or she would have to read 
a lot of specifications to identify the requirements to be 
followed.  Some of these implementations might be like 2b.

I'll quote the requirement:

   "XML-unaware MIME producers MUST NOT supply a charset parameter with
    an XML MIME entity unless the entity's character encoding is reliably
    known."

What happens when that producer supplies a charset parameter with XML 
entity when the entity's character encoding is not reliably 
known?  That's the angle I would look at.

I think that it is better not to get into that level of detail (see 
Point 1 and 2).

>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"

Ok.

>Person, but see reply to Tim Bray and above.

Ok.


> >   "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].

The above text looks good.  I'll try and suggest alternate wording if 
it is needed.  The reason I flagged this is it can come up as an 
issue during IESG Evaluation.

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

Ok.

> > Would a XML-unaware MIME consumer be following this specification?
>
>I hope so, see above.

I don't feel strongly about this.  I suggest getting other people to 
weight in (if they have not done so) and choose whatever has agreement.

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

Ok.

>I'll get rid of the double negation.

Ok.

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

Ok.

> > 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?

I do not feel strongly about that.

Regards,
S. Moonesamy