Subject: Re: [apps-discuss] Working Group Last Call:draft-ietf-appsawg-xml-mediatypes

From: t.petch <[email-masked]>
Date: Fri, 15 Nov 2013 15:40:46 +0000

On 2013-11-14 19:32, t.petch wrote:

>Sigh
>
>The point I raised has been addressed, which is good.
>
>But, doing the homework I should have done earlier, how does this I-D
>interact with RFC6657 which says
>"registrations for "text/*" media
>    types that can transport charset information inside the
corresponding
>   payloads (such as "text/html" and "text/xml") SHOULD NOT specify the
>  use of a "charset" parameter, nor any default value, in order to
>    avoid conflicting interpretations should the "charset" parameter
>    value and the value specified in the payload disagree"
>
>Seems to me that this RFC text is being updated and that that should
>appear both in rfc-index (and on the IANA website).
>

Um, no. That RFC is not updated-

The intent of the sentence you quote was of course to apply to *new*
registrations. It was not a goal to force a change on existing ones.

>And, what about all the application/*+xml registrations in existence,
>along with a few message/*+xml and model/*+xml?  How will anyone
looking
>up these have any idea that this I-D provides guidance for them (which
>is what this I-D is claiming)?

Is it? What specifically? (Or is this again about new registrations?)

<tp>

Julian

What is the purpose of this I-D?  s.8 says
"When a new media type is introduced for an XML-based format,"
so I think that this I-D is talking about new registrations, as RFC6657
does.

And it goes on to say
" Media types following the naming convention '+xml' SHOULD introduce
   the charset parameter for consistency"

When I go to
http://www.iana.org/assignments/media-types/text
I see

"See [RFC6657] for information about 'charset' parameter handling for
text media types."

and RFC6657 says

"registrations for "text/*" media
    types that can transport charset information inside the
corresponding
   payloads (such as "text/html" and "text/xml") SHOULD NOT specify the
  use of a "charset" parameter, nor any default value, in order to
    avoid conflicting interpretations should the "charset" parameter
    value and the value specified in the payload disagree"

So from this I-D - SHOULD.

>From the IANA website - SHOULD NOT.

Which all seems very clear and logical

With the advent of this I-D, perhaps that statement on the IANA
website needs to be updated, which I cannot see the I-D in its current
form making happen.

Tom Petch

</tp>
I think that you are giving IANA too big a challenge and that more
specific guidance is needed in section 10.

Tom Petch

Best regards, Julian

Tom Petch

----- Original Message -----
From: "t.petch" <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>; "Erik Wilde"
<[email-masked]>; "Dave Cridland" <[email-masked]>
Cc: "Julian Reschke" <[email-masked]>; "Henry S. Thompson"
<[email-masked]>; "Bjoern Hoehrmann" <[email-masked]>; "IETF Apps
Discuss" <[email-masked]>
Sent: Thursday, November 14, 2013 6:32 PM
Subject: Re: [apps-discuss] Working Group Last
Call:draft-ietf-appsawg-xml-mediatypes

> Sigh
>
> The point I raised has been addressed, which is good.
>
> But, doing the homework I should have done earlier, how does this I-D
> interact with RFC6657 which says
> "registrations for "text/*" media
>    types that can transport charset information inside the
corresponding
>    payloads (such as "text/html" and "text/xml") SHOULD NOT specify
the
>    use of a "charset" parameter, nor any default value, in order to
>    avoid conflicting interpretations should the "charset" parameter
>    value and the value specified in the payload disagree"
>
> Seems to me that this RFC text is being updated and that that should
> appear both in rfc-index (and on the IANA website).
>
> And, what about all the application/*+xml registrations in existence,
> along with a few message/*+xml and model/*+xml?  How will anyone
looking
> up these have any idea that this I-D provides guidance for them (which
> is what this I-D is claiming)?
>
> I think that you are giving IANA too big a challenge and that more
> specific guidance is needed in section 10.
>
> Tom Petch
>
> ----- Original Message -----
> From: "Murray S. Kucherawy" <[email-masked]>
> To: "t.petch" <[email-masked]>; "Erik Wilde" <[email-masked]>;
> "Dave Cridland" <[email-masked]>
> Cc: "Julian Reschke" <[email-masked]>; "Henry S. Thompson"
> <[email-masked]>; "Bjoern Hoehrmann" <[email-masked]>; "IETF Apps
> Discuss" <[email-masked]>
> Sent: Thursday, November 07, 2013 9:44 PM
> > Colleagues, but specifically Tom, Erik, Dave, Julian and Bjoern:
> >
> > Can you have a look at the latest version of this draft (or the
diffs,
> > available via the tracker) and let us know if you think it's ready
to
> go in
> > its latest form?
> >
> > Thanks,
> > -MSK, APPSAWG co-chair
> >
> > On Thu, Oct 17, 2013 at 9:23 AM, t.petch <[email-masked]>
wrote:
> >
> > > ----- Original Message -----
> > > From: "Julian Reschke" <[email-masked]>
> > > To: "Henry S. Thompson" <[email-masked]>
> > > Cc: "Bjoern Hoehrmann" <[email-masked]>;
<[email-masked]>
> > > Sent: Tuesday, October 15, 2013 6:16 PM
> > > > On 2013-10-15 19:08, Henry S. Thompson wrote:
> > > > > Julian Reschke writes:
> > > > >
> > > > >> The point I was trying to make is that we now have a
registry.
> The
> > > > >> registry is authoritative; if we move the definition of
"+xml",
> > > it's
> > > > >> sufficient to simply update the registry.
> > > > >
> > > > > I don't agree.  If we don't include 'Updates: 6839', then 6839
> will
> > > > > not get an 'Updated by [3023bis]', and anyone reading 6839
will
> be
> > > > > free to conclude that it defines +xml, which would be false.
> > > >
> > > > Anyone reading it that way would be reading it incorrectly :-)
> > > >
> > > > But anyway, that's something the IESG can worry about.
> > >
> > > Having just read about the difficulty in finding potential members
> of
> > > the IESG, I think we should do what we can as a WG to make the
task
> of
> > > the IESG simpler, in this case by putting forward a rough
consensus
> from
> > > the WG.
> > >
> > > I am with Henry on this one.  It is true that if your world
revolves
> > > around web pages, then the IANA web page will take you to the
> current
> > > definition whereever that is.  But if you start with RFC, for
> example
> > > with the rfc-index, and that does not mention an update to an RFC,
> then
> > > you will go astray.
> > >
> > > Comparing the two definitions, in RFC6839 and this I-D, they seem
to
> me
> > > like chalk and cheese, as for example in who has change control
and
> who
> > > the contact is, so that the RFC6839 one will be wiped from the
face
> of
> > > the earth; specifying 'Updates' seems the least we can do.
> > >
> > > Tom Petch
> > >
> > > > Best regards, Julian
> > > >
>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 15 Nov 2013 16:58:11 +0100

On 2013-11-15 16:40, t.petch wrote:
> ...

Tom,

could you please be specific about what part of the I-D you think is in 
conflict with RFC6657?

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 15 Nov 2013 17:56:50 +0100

>could you please be specific about what part of the I-D you think is in 

The draft recommends specifying a charset parameter for new text/*+xml
types. RFC 6657 recommends against that. There is no conflict between
the two, the whole idea behind the `+xml` convention is that software
does not need to be updated every time a new `+xml` type is registered,
so existing software will look at the charset parameter of unrecognised
types, which practically means all `+xml` types define the parameter,
and the RFC 6657 recommendation cannot apply retroactively.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/