Subject: [apps-discuss] WGLC for draft-ietf-appsawg-mime-default-charset

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 Apr 2012 18:32:15 +0000

This message starts Working Group Last Call for draft-ietf-appsawg-mime-default-charset.  Please review the document and provide comments to the list, the co-chairs, or the authors by Friday, April 20th.

The datatracker link is https://datatracker.ietf.org/doc/draft-ietf-appsawg-mime-default-charset/.

-MSK, APPSAWG co-chair

---

From: Ned Freed <[email-masked]>
Date: Sun, 08 Apr 2012 14:08:23 -0700 (PDT)

> -MSK, APPSAWG co-chair

I just reviewed this document and it's looking good to me.

You'll probably want to remove the anchor2 bit at the end of the WGLC.

There also one very minor typo:

OLD: "including absence of any default." 
NEW: "including the absence of any default."

				Ned

---

From: Julian Reschke <[email-masked]>
Date: Mon, 09 Apr 2012 12:12:06 +0200

> You'll probably want to remove the anchor2 bit at the end of the WGLC.

Of course.

I'm also not totally convinced that HTTPbis actually needs to reference 
this document at all; any opinions on this?

> NEW: "including the absence of any default."

Done.

Best regards, Julian

---

From: Ned Freed <[email-masked]>
Date: Mon, 09 Apr 2012 07:28:17 -0700 (PDT)

> this document at all; any opinions on this?

Really ard to say without knowing how they deal with the iso-8859-1. I can see
it being done in a way that doesn't need a reference. Or it could be done in a
way where a reference would be helpful.

Not sure I see any need for a normative reference though.

				Ned

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 9 Apr 2012 18:57:20 +0200

* Technical summary

This is the right thing to do, and should have been done right after the end of the UTF wars.

* Editorial issues

The document appears to spell out a SHOULD for "text/html" and "text/xml".
Does it change the meaning of text/html and text/xml?
Reading more closely, this apparently isn't meant, but there is a potential misunderstanding.

More generally:
When looking at a random media type three years from now, how do I find out whether this sentence does apply:
   It does not change the
   defaults for any currently registered media type.

Even more generally: 
Who is affected by (needs to read) this specification?
Who are the targets of the SHOULDs and MUSTs?
How do I find out whether an implementation complies?  interoperates?

And meta^3:
What is the IETF name for specifications that are exclusively intended to remind us not to make a certain class of mistake again when generating future specifications?  Which specification wins when such a meta-specification is neglected in a specific specification?

Grüße, Carsten

---

From: Ned Freed <[email-masked]>
Date: Mon, 09 Apr 2012 11:29:28 -0700 (PDT)

> This is the right thing to do, and should have been done right after the end of the UTF wars.

Not entirely sure we had the necessary understanding of the issues at that
point, but it's water under the bridge in any case.

> Reading more closely, this apparently isn't meant, but there is a potential misunderstanding.

There are a total of three places where there are references to these media
types. There's no compliance language at all in the first two locations, and
the third location is inside of a parenthetical phrase that also contains no
compliance language. Unless you manage to miss th=ose parentheses there's
simply no way these references can be conflated with compliance language.

And if we're to the point where we're trying to write prose that's consistent
even when basic punctuation cues are missed, well, all I can say is that we've
got a lot of work ahead of us.

That said, if this really is a valid concern (I'm extremely skeptical myself),
one way to address is would be to omit the third reference entirely (maybe
mention  text/html in the second along with text/xml). If that isn't
sufficient, my only other suggestion would be to say something like "XML and
HTML based media types" instead of referring to those types specificaly. But
that last seems like serious overkill.

>    defaults for any currently registered media type.

Um, the absence of any sort change to a specific subset of the types
necessarily applies universally. More specifically, since this specification
doesn't change any default anywhere, it doesn't matter in the slightest when
the type was registered. New types are supposed to either make charset
mandatory or not allow it at all. And you can tell that the case by, well,
reading the registration and seeing whether or not they did that.

The only way there would be some sort of flag day problem here is if some sort
of default was changed. But this document does not do that, and Section 4 is
already quite explicit about this. (HTTPbis may do this for text/html, but
that's an issue for that set of documents to deal with.)

> Who is affected by (needs to read) this specification?

Since this document specifies how registrations for types that allow for
multiple characters and which might employ charset parameters, anyone creating
registrations subject to those issues should read it. This is why there's a
normative reference in the revised media type registrations procedures  to this
document.

> Who are the targets of the SHOULDs and MUSTs?

See above.

> How do I find out whether an implementation complies?  interoperates?

I assume this is intended to become a BCP. (The IESG makes the final
determination on that, and has from time to time had what I regard as screwy
notions about the correct track for some documents, but in this case BCP  seems
rather obvious.)

BCP aren't necessarily about implementations or interoperability. In this
particular case we're talking about registration compliance. This will become
part of the media type registration review process once it is approved.

> What is the IETF name for specifications that are exclusively intended to
> remind us not to make a certain class of mistake again when generating future
> specifications?

I have no idea. But since that's not what this specification is doing, I fail
to see the relevance.

>  Which specification wins when such a meta-specification is neglected in a
> specific specification?

This is tantamount to asking, "What happens if the IESG and/or media type
reviwer screw up and fail to properly apply these new rules to some
registration." The answer is we handle it like any other screwup using
processes we already have in place for such things.

				Ned

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Apr 2012 10:25:35 +0200

On 2012-04-09 16:28, Ned Freed wrote:
> ...

HTTPbis simply has stopped having a custom rule; it just delegates to 
the applicable MIME specs. -> 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/20>

> ...

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Apr 2012 10:29:42 +0200

> Does it change the meaning of text/html and text/xml?

No. But it licenses future revisions of these specs to do the right thing.

> Reading more closely, this apparently isn't meant, but there is a potential misunderstanding.

We tried to clarify this in the latest draft. Can you suggest changes?

>     defaults for any currently registered media type.

The media type definition will have to state the default.

> How do I find out whether an implementation complies?  interoperates?

The audience is people registering media types.

And yes, one could argue this spec needs to RFC2119 keywords.

> What is the IETF name for specifications that are exclusively intended to remind us not to make a certain class of mistake again when generating future specifications?  Which specification wins whe…

This document updates RFC 2046, I don't think more needs to be done here...

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 10 Apr 2012 10:54:08 +0200

> We tried to clarify this in the latest draft. Can you suggest changes?

(such as "text/html" and "text/xml") 
->
(such as "text/html" and "text/xml" are able to) 

And in the start of that paragraph:

registrations
->
future registrations

> The media type definition will have to state the default.

Yes.

s/currently//

Again. maybe 

for text/* media types
->
for future registrations of text/* media types

in the same paragraph.

> And yes, one could argue this spec needs to RFC2119 keywords.

I can't parse that last sentence.

The MUST and the MUST NOT at the end of 3 are clearly meta-specs, and not for registrations either, but for "protocols".
They generate a conflict for existing specs such as RFC 2616 without indication how to resolve that conflict.
I know (the draft is mute about that) that we are fixing 2616, but this draft says nothing about how to handle that kind of conflict.

Again, adding little words such as "future" might help.
Or maybe the indication that these existing conflicting protocols are unbearable and will all need to be fixed (!?).

> This document updates RFC 2046, I don't think more needs to be done here...

I'm fine with that, I'm just not fine with the ambiguity resulting from retroactively changing meta-specs that have conflicting specs in force.
I think with the above clarifications in place we might be reaching the point of diminishing returns in managing this specific conflict.
I'm just trying to make the more general point here that you have to be careful in how you rewrite history.

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Apr 2012 11:03:09 +0200

> And in the start of that paragraph:

Thanks for the suggestions. I will consider these...

> I can't parse that last sentence.

I meant to say "does not need".

> They generate a conflict for existing specs such as RFC 2616 without indication how to resolve that conflict.

Good point. Note it has been resolved for httpbis a long time ago.

> I'm just trying to make the more general point here that you have to be careful in how you rewrite history.

Understood.

I don't think we *are* rewriting history, though.

Best regards, Julian

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Apr 2012 14:18:42 +0100

On 09/04/2012 15:28, Ned Freed wrote:
>> >> This message starts Working Group Last Call for 
>> draft-ietf-appsawg-mime-default-charset.  Please review the document 
>> and provide comments to the list, the co-chairs, or the authors by 
>> Friday, April 20th.
>> >
>> >> The datatracker link is 
>> https://datatracker.ietf.org/doc/draft-ietf-appsawg-mime-default-charset/.
>> >
>> >> -MSK, APPSAWG co-chair
>> >

(I've mentioned my opinion to Julian, but I would like to state it for 
the record.)
I think an update to RFC 2616 should have a reference to 
draft-ietf-appsawg-mime-default-charset and make it clear that the 
previous default was removed. An Informative reference to 
draft-ietf-appsawg-mime-default-charset should be fine.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Apr 2012 15:38:47 +0200

> draft-ietf-appsawg-mime-default-charset should be fine.

HTTPbis *does* make it clear that the default (overriding the base spec) 
was removed.

What's not clear to me is why it would need to reference 
draft-ietf-appsawg-mime-default-charset.

Best regards, Julian

---

From: Ned Freed <[email-masked]>
Date: Tue, 10 Apr 2012 07:26:47 -0700 (PDT)

> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/20>

Well, the change certainly needs to be noted as a change somewhere, don't
you think? Otherwise people could easily assume that the rule is in there
(and there's a lot of "there") somewhere.

				Ned

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Apr 2012 16:33:44 +0200

> (and there's a lot of "there") somewhere.

<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p3-payload-19.html#rfc.section.C.p.3>

Best regards, Julian

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 13 Apr 2012 00:09:37 +0000

Well, since a "last day" reminder brought a flurry of activity on the other draft, let's see if this helps this one:

A reminder that WGLC for this document ends a week from today.  If anyone has any reviews to report or comments to provide, please do so sooner rather than later.

-MSK

From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Wednesday, April 04, 2012 11:32 AM
To: [email-masked]
Subject: [apps-discuss] WGLC for draft-ietf-appsawg-mime-default-charset

-MSK, APPSAWG co-chair

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 13 Apr 2012 19:52:01 +0100

On 10/04/2012 14:38, Julian Reschke wrote:
> HTTPbis *does* make it clear that the default (overriding the base 
> spec) was removed.
>
People who only read/implemented RFC 2616 need to be told that the rules 
changed. Similarly for people who read/implemented RFC 2046. Navigating 
through the maze of RFCs obsoleting each other is difficult for people 
who don't deal with them on a daily basis (and it is non trivial even 
for people who do). A reference to 
draft-ietf-appsawg-mime-default-charset would help with that.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 13 Apr 2012 21:18:52 +0200

> draft-ietf-appsawg-mime-default-charset would help with that.

I'm still not convinced.

HTTPbis removes the default, and states so in the "Changes from RFC 
2616" section. How does a reference to 
draft-ietf-appsawg-mime-default-charset make things better?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 18 Apr 2012 18:57:57 +0200

> draft-ietf-appsawg-mime-default-charset make things better?

Proposal: remove the comment in draft-ietf-appsawg-mime-default-charset. 
People who feel strongly about httpbis citing 
draft-ietf-appsawg-mime-default-charset should actually raise this in 
the HTTPbis WG (I'm editor of both documents so I don't have a *problem* 
adding the reference, I just don't see what it's good for :-).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 18 Apr 2012 20:26:42 +0200

Done.

> And in the start of that paragraph:

Not convinced. This document changes the rules; I think it's pretty 
clear that it doesn't apply to past registrations.

>> The media type definition will have to state the default.

Again not convinced.

> for future registrations of text/* media types

See above :-)

> Or maybe the indication that these existing conflicting protocols are unbearable and will all need to be fixed (!?).

That's a good question.

As we already fixed it in HTTP, is there anything else we need to worry 
about`?

Best regards, Julian