Subject: [apps-discuss] Possible IESG statement on IESG processing of MIME type registrations from other SDOs

From: Alexey Melnikov <[email-masked]>
Date: Thu, 03 Mar 2011 16:14:05 +0000

I am working with the rest of IESG on issuing the following IESG statement:

------------------------

BCP 13 (currently RFC 4288) specifies that Media Type registrations
from other Standards Organizations (SDOs) can be submitted directly to
IESG for approval, without a need to submit an Internet Draft and to ask
an Area Director to shepherd its publication.

While this IESG statement doesn't change that, IESG would like to
encourage other SDOs to submit their registriation as Internet Drafts,
as this tends to improve quality of final registrations, and sometimes
even improves quality of the underlying format itself.

IESG would also like to remind that as per BCP 13, other SDOs are not
excluded from the requirement to post their Media Type registrations
for 2 weeks review on the [email-masked] mailing list.

When reviewing Media Type registrations IESG checks that the Media
Type registration template is correct and reasonably complete.

When reviewing Media Type registrations (including those from other SDOs) IESG also
checks that references to documents describing details of the Media
Type format are stable, i.e.
- a) the references are reasonably long lived

and

- b1) the document pointed to by the reference is either immutable
(i.e. if an updated document is approved for publication by the SDO,
then it will be posted at a different URI) or can only change in
insignificant ways (e.g. to correct typos, clarify text without
changing the media type format, etc.)

- b2) the media type format contains some internal fields for
versioning that can be used to distingiush 2 incompatible versions of
the Media Type format

- b3) there is some guaranty that future revisions of the format are
going to be backward compatible

Note that the choices b1, b2 and b3 are not mutually exclusive.

If the Media Type format specification has licensing restrictions, the
Internet Assigned Numbers Authority (IANA) must be granted express
permission to make archival copies of the Media Type format
specification, and to redistribute such a copy in the event that the
link to the format specification becomes inoperative and it is
determined that it will not be repaired.

------------------------

Please let me know if you have any corrections or major objections to 
this before March 17th.

Thanks,
Alexey

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 07 Mar 2011 00:58:12 +0100

>I am working with the rest of IESG on issuing the following IESG statement:

It would probably be a good idea to point ietf-types subscribers to your
message, they are the most likely to have opinions on this matter.

>even improves quality of the underlying format itself.

The IESG's workflow is probably optimized for Internet-Drafts, so it's
easy to see how this might improve things for the IESG, with requests
ending up in the right tracking systems and such, but it would seem the
idea would be to actually advance these Internet-Drafts to RFC status,
but RFCs that contain little more than the media type registration tem-
plates are not very useful. Nobody would look at the text/css RFC for
instance to learn about CSS syntax, character encodings in CSS, or re-
lated issues, for instance.

So if you really mean they should go the I-D -> RFC route, then I'm not
sure this is a good idea. If the idea is just to have something better
on record than, say, review requests in the ietf-types list archives,
then I doubt a bit that this would really help quality, even if you post
an I-D you'd still request ietf-types review and as far as I can tell
the "quality" issues usually get fixed there, if they get fixed at all.

A bigger problem to me is that there are many entry points. If you want
to register a type, do you contact IANA, do you contact ietf-types, do
you contact the IESG, or someone else, in what order, and so on. If the
process was "post registration information to ietf-types, fix issues
raised there, then the media type reviewers will guide you through the
next steps" that would be much simpler. Some people for instance think
by posting to ietf-types they are asking the IESG to register a type.

Another problem seems to be that after ietf-types review the process is
intransparent. It seems to me that people are to contact the IESG se-
parately and then the IESG may announce a decision sooner or later, but
what happens inbetween does not seem to be easily publically accessible.

Those two problems would be addressed by using I-Ds, but see above.

As for the points on format evolution and licensing, instead of listing
rather onerous requirements that I am not sure are fully supported by
RFC 4288, it might be better to say that, if a format does not meet some
reasonable stability and availability requirements, it is better to re-
gister types in other trees than the standards tree. OASIS registering
types under vnd.oasis rather than in the standards tree seems quite okay
indeed.

Personally, I think we might do just fine having just a "specification
available" policy for media types with little regard for immutability or
availability of specifications, or whether registrations use one version
of the registration template or another, or getting some weird "Mac"
codes right. We have more of a problem with many dozens of common types
that are not registered at all.
-- 
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/

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 08 Mar 2011 17:04:21 +0900

Hello Alex,

I support most of the comments from Björn. Some additional comments below.

> I am working with the rest of IESG on issuing the following IESG statement:

First, I'm worried that an IESG statement (of whatever content) will 
only complicate things for applicants and reviewers/commenters. IESG 
statements seem to work well for things that affect people who are 
already in the know, insiders,..., but not for outsiders.

I don't understand what's the purpose of this. One of the main changes 
in RFC 4288 was to get away from the fact that every type in the 
standards tree had to be an RFC. This was discussed e.g. with W3C, and 
made it considerably more straightforward to register types from W3C.
For details, please see http://www.w3.org/2002/06/registering-mediatype.
It could easily be seen as a step back.

Also, please very strongly consider that while for somebody on the IESG, 
writing an ID, in particular if it only contains the template, is 
something they can easily do before breakfast, for people from the 
outside, it's something where they have no idea where to start, which 
often means they don't start at all.

> as this tends to improve quality of final registrations,

Can you give any examples? I don't say there are none, but I couldn't 
come up with one myself.

> and sometimes

Does that imply that the underlying format should be included in the ID? 
That would definitely deviate from BCP 13.

Anyway, giving clearer explanations (and probably discussion) about when 
exactly and what for an ID makes sense seems to be much needed,
and the actual need should not be just because the datatracker cannot 
handle anything else than drafts.

> for 2 weeks review on the [email-masked] mailing list.

That's true, and doesn't hurt mentioning. If we say something about 
this, please include a line or so saying that the post should contain an 
actual copy of the registration template (not just "it's over there") 
because that makes it much easier to comment.

Regards,   Martin.

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: SM <[email-masked]>
Date: Tue, 08 Mar 2011 17:13:37 -0800

Hi Alexey,
>I am working with the rest of IESG on issuing the following IESG statement:

The above sounds fine from an IETF point of view.

According to BCP 13:

   "The standards tree is intended for types of general interest to the
    Internet community.  Registrations in the standards tree MUST be
    approved by the IESG and MUST correspond to a formal publication by a
    recognized standards body.  In the case of registration for the IETF
    itself, the registration proposal MUST be published as an RFC."

   "The media type registration procedure is not a formal standards
    process, but rather an administrative procedure intended to allow
    community comment and sanity checking without excessive time delay."

The proposed IESG statement will end up turning 
"the posting of an Internet Draft [into] a 
necessary first step".  Martin Dürst mentioned 
that it is not always easy for people outside the 
IETF to write an I-D [1].  "The IESG's workflow 
is probably optimized for Internet-Drafts, so 
it's easy to see how this might improve things 
for the IESG, with requests ending up in the 
right tracking systems" [2].  This has the 
makings of turning the registration procedure into a formal standards process.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02319.html
2. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02315.html

---

From: Ted Hardie <[email-masked]>
Date: Tue, 8 Mar 2011 17:34:13 -0800

>> even improves quality of the underlying format itself.
<snip>

> The proposed IESG statement will end up turning "the posting of an Internet
> Draft [into] a necessary first step".  Martin Dürst mentioned that it is not
> always easy for people outside the IETF to write an I-D [1].  "The IESG's
> workflow is probably optimized for Internet-Drafts, so it's easy to see how
> this might improve things for the IESG, with requests ending up in the right
> tracking systems" [2].  This has the makings of turning the registration
> procedure into a formal standards process.
>

I'm not sure I agree that it turns into a formal standards process,
but I definitely agree that it's going to be very hard for outsiders
to find this statement and do the right thing, absent additional clue.
 The BCP will say "not needed" and the IESG statement will say
"encouraged".  I'd say if the IESG ever plans to point to the
statement after receiving one in another format, it should update the
BCP instead.

regards,

Ted Hardie

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 08 Mar 2011 20:59:20 -0700

> to find this statement and do the right thing, absent additional clue.

Currently folks working within other SDOs ping one or both of the
Applications Area Directors, who usually say "we know it's not
mandatory, but it would be helpful if you could write a brief
Internet-Draft defining your registration request". So outsiders don't
need to find this statement and do the right thing from the start, and I
don't think the Apps ADs (or IESG in general) expect that they would.

> statement after receiving one in another format, it should update the

Yes, it's always good to align our procedural BCPs with the practices we
actually follow (if they're "best", at least).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 09 Mar 2011 16:44:22 +0900

Hello Peter,

> don't think the Apps ADs (or IESG in general) expect that they would.

[Assuming the above also applies to W3C] I'm no longer working for W3C, 
but if I still did, and in particular if I still was in charge of 
coordinating these registration requests, I'd very clearly and 
explicitly not be happy with this. In my view, one of the main points of 
RFC 4288 was exactly to get away from the need to have things in two 
places, and to get away from the need for people who never before and 
never after wrote Internet Drafts to get familiar with all the details.

If we think RFC 4288 has failed, we should fix it. (I for my part don't 
think it has failed, at least not in this respect.)

Also, while the above solves the "find the Statement" problem, it won't 
avoid the problem that outsiders get told different things at different 
stages: First, they get told to follow RFC 4288 (or they might even find 
it themselves), then once they are through review on ietf-types, they 
get told something else.

And the above "it would be helpful" still doesn't answer the question 
why. The assumption from non-IESG people including me is that the main 
or only reason is because the datatracker can only handle IDs. It would 
be helpful (sic) if you and Alex could be clear and frank about this.

Regards,   Martin.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 09 Mar 2011 11:42:37 +0000

Hi Bjoern,

>message, they are the most likely to have opinions on this matter.
Yes, good point. I will do.

>lated issues, for instance.
It dependends on how much extra information such document provides. 
Collecting all references in one place is a good thing as well.
But YMMV.

>the "quality" issues usually get fixed there, if they get fixed at all.
I should have pointed out earlier that the paragraph recommending 
Internet Drafts is non normative (it is expressing the opinion of the 
current IESG, but this can change over time).

I am still thinking about what you, Martin, Ted and others said about 
this paragraph and maybe the best way forward is actually to delete it. 
The main purpose of this proposed IESG statement is to clarify stability 
of references and licensing.

>you contact the IESG, or someone else, in what order, and so on.
>
Right.
I think IANA is doing the right thing by always redirecting to either 
IESG (for registrations in the standars tree) or to the Expert Reviewer 
(for vendor specific registrations). But I can see how the process can 
confuse people.

>If the
Right. I am open to suggestion how to improve this. This probably 
doesn't need an IESG statement of any sort.

>what happens inbetween does not seem to be easily publically accessible.
Yes. IESG and interested parties in W3C are actively discussing how to 
improve this. I think IESG will end up using a public trac system or the 
like.

>RFC 4288,
It isn't, that is why IESG is proposing a statement.

>it might be better to say that, if a format does not meet some
Right. Let me think about this a bit more.

>that are not registered at all.
Best Regards,
Alexey

-- 
IETF Application Area Director, <http://www.ietf.org/iesg/members.html>
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 10 Mar 2011 01:55:35 +0100

>think it has failed, at least not in this respect.)

I am not sure whether RFC 4288 has failed in this respect generally, but
it seems pretty clear that the W3C has been largely unable to follow the
much simpler process here. If you look at the not-very-well-maintained
index at http://www.w3.org/2002/06/registering-mediatype.html you have
entries there like "Check in November 2009" under "Plans". It's not a
total failure, but W3C staff obviously can't do so much as check, say, a
review request to ietf-types goes out along with a Last Call or that the
types have actually been registered when a document is to move to CR, PR
REC, "Second Edition" levels.

Putting this around, a bit of a summary of the problems the IESG has en-
countered with registration requests from other standards organizations
that don't come as I-Ds would help in making suggestions.
-- 
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/

---

From: Larry Masinter <[email-masked]>
Date: Sun, 20 Mar 2011 07:36:04 -0700

This proposed IESG statement fails to address any of the significant difficulties:

Registering MIME types is an activity that has high cost and little benefit.  Cost in terms of learning the process (poorly documented, inconsistent, hard to follow) and following it (responding to reviewer comments). Little benefit, in that the registry plays little or no role in the actual implementation and deployment cycle for new values. 

This issue applies also to URI schemes, and to some degree to other (web-) and perhaps (application-level) parameters.

The high cost and low benefit holds in general for any organization deploying a new or updated content type. While it is also true for other SDOs, the proposed statement does not address the general problem, and might even make the situation worse, by making the SDO process even more different from the non-SDO problem.  

(It does not address the cost/benefit tradeoff for SDOs either, except perhaps to trade off one cost -- cost of learning a cumbersome and poorly documented process -- with another.)

With MIME types and charset values, there are additional consequences:

Because some organizations and implementations originally did not supply the correct registered values, many implementations override the provided MIME types and character encoding assertions (use of registered values) by "sniffing" https://tools.ietf.org/html/draft-ietf-websec-mime-sniff  see also
 http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#mime-types
http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#determining-the-character-encoding .

More problematic is when the "ownership" of a MIME registration is in dispute, for example when there are multiple, different specifications which claim to be the authority on a registered value, e.g., the two registries for the same MIME value http://www.whatwg.org/specs/web-apps/current-work/multipage/iana.html vs. http://dev.w3.org/html5/spec/iana.html  pointing to substantially different specifications. 

The proposed IESG statement does not address this issue, and, in fact might exacerbate it, by making the registration process for SDOs more difficult than the non-registration-process for non-SDOs.

 (Too bad the IAB document on "Design Considerations for Protocol Extensions" http://tools.ietf.org/html/draft-iab-extension-recs#section-3.6   doesn't take on these issues). 

Larry

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 20 Mar 2011 15:28:02 +0000

Hi Larry,

>This proposed IESG statement fails to address any of the significant difficulties:
...because it was not planning to address them. There are multiple 
related discussions going on at the moment. This particular statement 
proposal originated from an internal IESG discussion about stability of 
references in registrations from other SDOs.

>Registering MIME types is an activity that has high cost and little benefit.  Cost in terms of learning the process (poorly documented, inconsistent, hard to follow) and following it (responding to…
Ack.

>The high cost and low benefit holds in general for any organization deploying a new or updated content type. While it is also true for other SDOs, the proposed statement does not address the general…
I don't think it does, but I am happy to discuss.

>http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#determining-the-character-encoding .
I agree that this is worth addressing, but addressing this particular 
problem wasn't a goal.

>More problematic is when the "ownership" of a MIME registration is in dispute, for example when there are multiple, different specifications which claim to be the authority on a registered value, e.…
What is your proposal here?
I think this issue is quite rare and the only cases I've seen all 
originate from WHATWG/W3C.

As far as IANA (or IESG) is concerned, there is only one true 
registration in each case, so there is no dispute.