Subject: [Uri-review] Provisional URI registrations (was: draft-melnikov-mailserver-uri-to-historic-00.txt)

From: John C Klensin <[email-masked]>
Date: Fri, 19 Nov 2010 14:25:38 -0500

Alexey,

It seems to me that the TN3270 discussion has started to
conflate two separate issues and that we might derive something
useful from that discussion:

	(1) Whether the URI scheme is properly specified and in
	use
	
	(2) Whether the underlying applications protocol is
	well-specified, in use, and still useful.

For TN3270, the answer to "properly specified" is clearly "no"
because, as several people have pointed out, there really is no
spec, just a reservation.  It may still be in use, and several
people have made credible suggestions that is actually the case.
Certainly the answer to (2) is "yes".  

Having a tn3270 URI in use without a spec is actually troubling
because there is no way to tell whether all uses of the keyword
are consistent.   However, deprecating the keyword or dropping
it from the registry is not a solution to that problem.  Either
getting a spec or warning people off would be a superior
approach.

That situation is very different from the "mailserver" case,
where there really isn't an underlying application protocol in
active use, at least as far as I know.

Perhaps that difference is a useful differentiating factor.  For
some years, we had the implicit assumption that every
application protocol deserved a URI.  I've personally always
felt that was a bad assumption because of mismatches between the
operational model of some protocols and the URI model, but I
lost that argument.  Looking at the situation from the
perspective of today's environment, I suggest that:

(1) We move URI schemes to Historic only if we are justified and
willing to move the underlying applications protocol
specifications to Historic -or- if no such protocol spec exists
and there is no reasonable prospect of getting one.

I note that, using that criterion, "mailserver" would go to
Historic and "tn3270" would not.  I haven't done enough research
to have an opinion about "afs", but see below.

(2) We instruct IANA to separate the "Provisional" category of
the URI Scheme registry into two categories: 

	* Provisional (defined more or less as work in progress)
	and
	
	* Reserved keyword

and move any of the now-provisional keywords for which there are
adequate protocol specs but no adequate URI spec (existing or in
active progress) into it.  I note that RFC 1738 describes the
keywords it lists as "proposed at various times" with
"...suggested that IANA reserve...", not "Provisional".  After a
quick search, I haven't been able to discover any instructions
to IANA to identify them as Provisional.  Unless such
instructions exist, one could sensibly interpret the separation
suggested here as correcting an error.

It seems to me that, until and unless the IETF takes a strong
position against the "all application protocols can reasonably
be associated with a URI" model, having a facility to reserve
application-associated keywords for applications that are
well-defined and URI schemes that might be developed in the
future would promote interoperability by providing a warning
that the keyword should not be generally used until (and unless)
a spec is produced.

If we took that approach, we could safely put both tn3270 and
afs into "Reserved" if only because it is not clear to me that
making a more careful decision about the latter would be worth
the effort it would take.   We could similarly move anything
else in the Provisional list that is associated with an expired
I-D to Reserved.

If there is sympathy for this approach and an I-D is needed to
establish rules for adding new entries to the "Reserved"
category, I guess I'm willing to quickly turn out a first draft.
That draft could also formally create the category if needed
but, as noted above, I think its absence is an error on IANA's
part.

    john

---

From: Graham Klyne <[email-masked]>
Date: Sun, 21 Nov 2010 22:25:33 +0000

John,

With reference to your suggestions about the registry (and in no way intending 
to challenge what you say about tn3270)

We have "permanent", "provisional" and "historical" registration classes for URI 
schemes.  For practical purposes, I think the "provisional" registry serves the 
same role as the "reserved" one you suggest [1].  I think the additional 
bureaucracy incurred to create a new registry class is not justified by 
practical benefit.  It's easy enough to add some commentary to the registration 
template

(For message headers, this is not quite true, as provisional registration is not 
required to be unique, but in all the time it's been running, in my role as 
reviewer I've never seen a request to register a new name that is already 
present in the provisional registry.)

#g
--

[1] http://tools.ietf.org/html/rfc4395 (sections 3 and 5.2)

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

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 22 Nov 2010 09:48:10 +0900

On 2010/11/22 7:25, Graham Klyne wrote:

> We have "permanent", "provisional" and "historical" registration classes
> for URI schemes. For practical purposes, I think the "provisional"
> registry serves the same role as the "reserved" one you suggest [1]. I
> think the additional bureaucracy incurred to create a new registry class
> is not justified by practical benefit.

+1.

Regards,   Martin.

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

---

From: John C Klensin <[email-masked]>
Date: Sun, 21 Nov 2010 22:41:08 -0500

--On Monday, November 22, 2010 09:48 +0900 "\"Martin J.
Dürst\"" <[email-masked]> wrote:

>> We have "permanent", "provisional" and "historical"
>> registration classes for URI schemes. For practical purposes,
>> I think the "provisional" registry serves the same role as
>> the "reserved" one you suggest [1]. I think the additional
>> bureaucracy incurred to create a new registry class is not
>> justified by practical benefit.
> 
> +1.

I would agree, except that:

(1) We now have proposals to remove things from Provisional that
have well-defined protocol specs and evidence of use because
they have been Provisional too long.  Fighting battles of that
sort is lots more painful than setting up a new registry
category, especially since...

(2) Not having a Reserved category from the beginning appears to
be an error on IANA's part, not something the IETF specified in
any way.   If that is correct, it should be possible to deal
with it as correcting an error, which is (or should be) an
extremely lightweight procedure.

   john

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 22 Nov 2010 15:51:37 +0900

Hello John, others,

(cc'ing the IRI WG mailing list, because it is chartered to work on an 
update of RFC 4395 (Guidelines and Registration Procedures for New URI 
Schemes); please reduce cc list in replies whenever possible)

On 2010/11/22 12:41, John C Klensin wrote:
> Dürst\""<[email-masked]>  wrote:
>

I don't think fighting such battles should be painful. If A says a 
scheme (or protocol) is no longer in use, and B say it's in use, then B 
just wins. Having to say "the scheme (or protocol) is still in use" 
every two years or so may indeed some pain, but not too much.

> any way.

In what way is it IANA's error? RFC 4395 
(http://tools.ietf.org/html/rfc4395) is pretty clear (as Graham has 
already explained) that there are three categories: Permanent, 
Provisional, and Historical.

> If that is correct, it should be possible to deal

I don't understand how it could be correct, but maybe I'm missing 
something. Anyway, I encourage everybody who thinks an additional 
Reserved category is needed, or some other clarifications could help, to 
submit their proposal as an issue on draft-ietf-iri-4395bis-irireg 
(http://tools.ietf.org/html/draft-ietf-iri-4395bis-irireg (Guidelines 
and Registration Procedures for New URI/IRI Schemes)) to the IRI WG 
(mailing list address: [email-masked]). The current list of active 
issues of the WG can be found at 
http://trac.tools.ietf.org/wg/iri/trac/report/1.

Regards,   Martin.

---

From: Graham Klyne <[email-masked]>
Date: Mon, 22 Nov 2010 10:09:03 +0000

> category, especially since...

Having made a very quick review of that discussion (w.r.t. tn3270), I feel there 
is a consensus that the appropriate response to to say "that's fine, it has a 
definition, let's leave it there".  There is no explicit provision for time-out 
of provisional registrations - the general idea (at least in the formulation of 
the header registry, from which I believe this registry was derived) was to 
provide a place where schemes could be documented for the community without 
having to meet the properly high standards of IETF consensus.

One option in this case would be to move the tn3270 scheme to historic - I'm not 
sure if that's been suggested.  That's something I would support in this case.

You say "Fighting battles of that sort is lots more painful...".  My sense is 
that the more choices there are, the more painful the battles may be.  My 
reference to "bureaucracy" was intended to allude as much to the choices to be 
made on an ongoing basis as to the setting up of a new registry.  As scheme 
reviewer, I would find it harder to make a reasonable decisions if "reserved" 
were also an option, since that would require more detailed knowledge of the 
protocol's history than I can generally bring to bear.

> extremely lightweight procedure.

Well, as Martin says, if it's an error it's not one on IANA's part.  In this 
case, they follow what we (the IETF) asked of them.  So I suppose we should be 
careful what we ask for :)

#g

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 22 Nov 2010 16:24:21 +0200

22.11.2010 0:25, Graham Klyne wrote:
> We have "permanent", "provisional" and "historical" registration 
> classes for URI schemes.  For practical purposes, I think the 
> "provisional" registry serves the same role as the "reserved" one you 
> suggest [1].  I think the additional bureaucracy incurred to create a 
> new registry class is not justified by practical benefit.  It's easy 
> enough to add some commentary to the registration template
I can't agree with that. 'Provisional' means
'not to be used as not specified' while
'Reserved' means 'not to be used NOW and
not to be specified NOW (wait until are moved
to 'Provisional')'. We have difference between
these two terms.

Mykyta Yevstifeyev

---

From: Graham Klyne <[email-masked]>
Date: Mon, 22 Nov 2010 22:47:12 +0000

> 'not to be used as not specified'

Well, that's not what I read in RFC4395 regarding "provisional":

[[
Within that namespace, there are values that are
approved as meeting a set of criteria for URI schemes.  Other scheme
names may also be registered provisionally, without necessarily
meeting those criteria.
]]
-- http://tools.ietf.org/html/rfc4395#section-1

[[
    o  encourage registration by setting a low barrier for provisional
       registrations.
]]
-- (ibid)

My interpretation of "reserved" was based on my reading of the criteria outlined 
in John Klensin's email to which I was responding.

And my response clearly stated "for practical purposes", which is not the same 
as claiming the words mean the same thing.  That is, for practical purposes, I 
don't think that having a "reserved" category adds any value to the process.

Further, I don't think that allowing registration without some level of 
specification, or registration of a scheme that is "not to be used now" would 
serve any useful purpose.  The main point of provisional registration here is to 
allow developers to experiment with a tentatively specified URI scheme without 
meeting all of the requirements for permanent registration, while allowing that 
permanent registration may follow if the experiments show value, and to provide 
a place where some information can be found about any registered scheme that 
might show up in the wild.

#g
--