Subject: [apps-discuss] draft-ietf-appsawg-media-type-regs and "provisional"

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 10 Jun 2012 00:02:30 -0700

Hi all,

Barry asked me to review the IETF Last Call comments on the above draft
before it gets scheduled for a telechat, to make sure there's nothing
outstanding that needs to be addressed in the document.  I just spent a
chunk of time reviewing the debate about "provisional", which I think is
the only unresolved issue before we move forward with it.

I think we should proceed with it as-is.  I recognize that Mark and PSA
both don't like what's there on this point, but ultimately I agree with Ned
and John that this isn't introducing a new problem, nor is it introducing a
terminology change, and the "problem" that already exists since RFC3864
hasn't caused any detectable harm.

Mark could address this if he feels so moved in his happiana efforts, but I
don't think it's a showstopper for this particular document.

-MSK, as document shepherd

---

From: Ned Freed <[email-masked]>
Date: Sun, 10 Jun 2012 12:33:14 -0700 (PDT)

> the only unresolved issue before we move forward with it.

Sorry you felt you had to do that.

Anyway, in regards to the "provisional" issue, I do not regard it as unresolved
in any way.

> hasn't caused any detectable harm.

OK, maybe I'm missing something here, but ...

As I understand it the issue Mark raised was the separation of provisional
entries from the main registry. This was because he misunderstood the semantics
of these entries. Such entries are NOT intended to be in active use - they
don't contain anything approaching enough information to be used. As such, it
is entirely inappropriate for them to be on the same page as approved entries..
When this was pointed out to him, he fell back on the argument that this isn't
how other provisional registries in the IETF work, specifically referring to
RFC 3864. And  he called this the "underlying problem". But he never actually
objected to the nature of the media types registry once it was explained why it
was structured this way, possibly because the registry was added specifically
at the request of the W3C and it has exactly the characteristics they wanted it
to have.

As for the terminology issue, there are two problems with that. First, what RFC
3864 calls a "provisional" registry is in fact nothing of the sort. It's a
permanent registry - entries, one made, are never removed. The most you can do
is move them from provisional to permanent status.

Of course this usage directly contradicts what the word "provisional" actually
means. We're using the term correctly, RFC 3864 is not. If this actually an
issue for the IESG we'll switch to "pro tem". But that won't fix the
mistake in RFC 3864.

And when I pointed this out, AFAIK there was no response.

The second problem is funnier. Guess how the RFC 3864 registry, which has been
held up as a model, is structured. That's right, two separate pages. In the
case of RFC 3864 separate pages are actually totally inappropriate, but they
are not only appropriate, they are essential, here.

Anyway, after all this is over I have every intention of filing an errata on
RFC 3864 pointing out that it's misusing the term "provisional". And just for
the lutz, I may also point out that the separate pages is also an error.

> don't think it's a showstopper for this particular document.

I don't see how. Happiana is about, well, I'm not entirely sure what it's about
any more. But one thing it cannot do is make fundamental changes to how IANA
registries are structured. If there's any attempt to do that, I for one will
strongly object, and if necessary, appeal.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sun, 10 Jun 2012 15:59:41 -0700 (PDT)

One additional point. I've summarized Mark's position as best I could from the
existing traffic. If he feels I have done so in error, he should feel free to
correct me.

				Ned

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 11 Jun 2012 22:16:03 +1000

You know, there's such a thing as a CC: header, guys...

Anyway, a few comments below:

> at the request of the W3C and it has exactly the characteristics they wanted it

Agreed.

> is move them from provisional to permanent status.

Agreed; I think I said before that its use of the term is unfortunate.

> issue for the IESG we'll switch to "pro tem". But that won't fix the

In principle, agreed, although who knows when. 

> held up as a model

Not true.

> is structured. That's right, two separate pages. In the

Yep, we've asked IANA to change this, no response yet...

> the lutz, I may also point out that the separate pages is also an error.

I think the term that the kids use is "lulz." 

> any more.

You had that information previously? A pity, it would have been useful...

> But one thing it cannot do is make fundamental changes to how IANA

Agreed.

Perhaps the most straightforward thing to do at this point is put a sentence on the IANA registry page to the effect that the sense of "provisional" in this registry is different than that used for headers (I don't think it's a good idea to put that sentence in the spec, because as Ned says, hopefully we can fix the header registry one day).

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Ned Freed <[email-masked]>
Date: Mon, 11 Jun 2012 11:43:37 -0700 (PDT)

> You know, there's such a thing as a CC: header, guys...

By that you mean I could have cc'ed you on my original response? Very true, but
please be aware that there are plenty of people out there who yell at me when I
do that: "I'm already on the freakin list, stop sending me extra mail."

I figure I can't win so I usually do a reply-all and hope for the best...

> ...

> Not true.

OK, sorry for assuming that.

> Yep, we've asked IANA to change this, no response yet...

Good idea, although it may be difficult given the language in RFC 3864's IANA
Considerations - pretty clearly calls for a separation there. IANA may be
balking because of that. And while an errata could be filed, it would probably
end up as "for future version". 

Processes can be irritating sometimes.

> I think the term that the kids use is "lulz."

My bad.

> You had that information previously? A pity, it would have been useful...

;-) I see we're pretty much in agreement here, and that's actually kind of
unfortunate. I should add that I view your draft as having captured what could
be reasonably captured out of all that. (I think I already mentioned that I
tried to  address all the points you raised in the media types work, but I
stopped short of a reference because I was unsure of the ultimate fate of the
draft.)

> Perhaps the most straightforward thing to do at this point is put a sentence
> on the IANA registry page to the effect that the sense of "provisional" in this
> registry is different than that used for headers (I don't think it's a good
> idea to put that sentence in the spec, because as Ned says, hopefully we can
> fix the header registry one day).

Works for me. Do you think this deserves a mention in the IANA Considerations?
Personally, I think adding it would be a good idea, but I could be convinced
otherwise.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Mon, 11 Jun 2012 15:35:03 -0400

--On Monday, June 11, 2012 11:43 -0700 Ned Freed
<[email-masked]> wrote:

>> Perhaps the most straightforward thing to do at this point is
>> put a sentence on the IANA registry page to the effect that
>> the sense of "provisional" in this registry is different than
>> that used for headers (I don't think it's a good idea to put
>> that sentence in the spec, because as Ned says, hopefully we
>> can fix the header registry one day).
> 
> Works for me. Do you think this deserves a mention in the IANA
> Considerations? Personally, I think adding it would be a good
> idea, but I could be convinced otherwise.

I don't see any downside, especially (given the separation
problem with the RFC 3864 registry that you point out) if we can
specifically instruct IANA that that are likely to be asked to
remove the comment with 3864 or its registries are updated.
Let's not put it in and have trouble getting rid of it because
this document said so.

Sometimes I really wish for the days when IANA had more than
enough authority for independent action and was able to consider
"good sense" as a more important criterion than rigid
procedure-following.  Actually, most days.

    john

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 12 Jun 2012 10:06:51 +0900

> Agreed; I think I said before that its use of the term is unfortunate.

I think it's actually not too bad. From the point of view of the 
registry, the entry definitely can't be removed anymore. But from the 
point of view of the consumers of the registry, i.e. the users, I very 
much think that "provisional" sends the right message. It clearly sends 
a signal that maybe the exact definition may change, maybe more definite 
information will be available in the future, maybe it's not yet a good 
idea to use the code/label in production systems, and so on and so forth.

Assuming that there are quite a bit more consumers than registrants and 
administrators, and that the later category can be informed better, 
having terminology optimized towards consumers shouldn't be such a bad idea.

Regards,   Martin.

---

From: Ned Freed <[email-masked]>
Date: Tue, 12 Jun 2012 07:42:29 -0700 (PDT)

> Let's not put it in and have trouble getting rid of it because

OK, so how about:

  IANA is also request to add the following note at the beginning of the
  provisional registry:

    This registry, unlike some other provisional IANA registries,
    is only for temporary use. Entries in this registry are either
    finalized and move to the main media types registries, or are
    abandoned and deleted. Entries in this regisry are suitable
    for use for test purposes only.

This would become the third paragraph of the IANA considerations section.

As I wrote this I realized it could be done in a way that provides useful
information about the registry content in addition to clarifying the
discrepancy with other provisional registries.

> procedure-following.  Actually, most days.

+1

				Ned

---

From: John C Klensin <[email-masked]>
Date: Tue, 12 Jun 2012 11:49:06 -0400

Sounds about right.  Editorial bits/nits below

 
>...
>> > Works for me. Do you think this deserves a mention in the
>> > IANA Considerations? Personally, I think adding it would be
>> > a good idea, but I could be convinced otherwise.
> 
>> problem with the RFC 3864 registry that you point out) if we
>> can specifically instruct IANA that that are likely to be
>> asked to remove the comment with 3864 or its registries are
>> updated. Let's not put it in and have trouble getting rid of
>> it because this document said so.
> 
> OK, so how about:
> 
>   IANA is also request to add the following note at the
s/request/requested/
> beginning of the   provisional registry:
> 
>     This registry, unlike some other provisional IANA
> registries,     is only for temporary use. Entries in this
> registry are either     finalized and move to the main media
s/move/moved/
> types registries, or are     abandoned and deleted. Entries in
> this regisry are suitable     for use for test purposes only.
s/regisry/registry/

And you might say "for use for test purposes and to alert others
that the entry name is likely to be in use only" or words to
that effect.

> As I wrote this I realized it could be done in a way that
> provides useful information about the registry content in
> addition to clarifying the discrepancy with other provisional
> registries.

Agreed.  If we have to put text in, let's maximize its utility.

    john

---

From: Ned Freed <[email-masked]>
Date: Tue, 12 Jun 2012 11:15:43 -0700 (PDT)

> Sounds about right.  Editorial bits/nits below

I've updated the text accordingly.

				Ned

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 13 Jun 2012 08:03:41 +1000

Looks about right. And a big +1 to untying at least one of IANA's hands.