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

[Alexey Melnikov <[e-mail]>]

Hi Bjoern,

Bjoern Hoehrmann wrote:

>* Alexey Melnikov wrote:
>
>>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.
>
Yes, good point. I will do.

>>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.
>>    
>>
>
>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.
>
It dependends on how much extra information such document provides. 
Collecting all references in one place is a good thing as well.
But YMMV.

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

>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.
>
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
>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.
>
Right. I am open to suggestion how to improve this. This probably 
doesn't need an IESG statement of any sort.

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

>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 isn't, that is why IESG is proposing a statement.

>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.
>
Right. Let me think about this a bit more.

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