Subject: Re: [Uri-review] The state of 'afs' URi scheme

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 01 Feb 2011 12:22:14 +0200

31.01.2011 21:32, Roy T. Fielding wrote:
> On Jan 31, 2011, at 3:20 AM, Mykyta Yevstifeyev wrote:
>> Since these schemes are in Provisional category, it means that they are 'waiting for specification'.  If no-one specifies them, they should be moved to Historical.  That's clear, IMO.
> No, they should be removed from the registry and allowed to be
> defined by some other spec in the future.  There is no need to
> reserve the schemes of unimplemented identifier mechanisms.
Roy,

Firstly, are there any procedures for de-assignment of URI schemes 
registration, as you propose.  Moreover, Provisional category provides 
the state 'waiting for proper specification'.  Finally, re-read the 
definition of Historical category and the definition of Provisional 
category.  And then make the conclusions.

Mykyta
> ....Roy

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 01 Feb 2011 17:02:09 +0200

01.02.2011 13:23, Ben Niven-Jenkins wrote:
> Mykyta,
>
> On 1 Feb 2011, at 10:15, Mykyta Yevstifeyev wrote:
>
>> 31.01.2011 16:59, Paul Hoffman wrote:
>>> On 1/31/11 12:28 AM, Roy T. Fielding wrote:
>>>> No, there is no reason to have that document either.  We don't need
>>>> these useless exercises in bit pushing -- there are plenty of other
>>>> drafts that need writing about actual protocols that were (and are)
>>>> used on the Web as identifiers.  afs, nfs, tn3270, and mailserver are
>>>> all examples of schemes that someone once thought might be a good idea,
>>>> but were in fact never used on the Internet.  They are obsolete.
>>> +1
>>>
>>> On 1/31/11 3:20 AM, Mykyta Yevstifeyev wrote:
>>>> Since these schemes are in Provisional category, it means that they are
>>>> 'waiting for specification'. If no-one specifies them, they should be
>>>> moved to Historical. That's clear, IMO.
>>> -1
>>>
>>> Mykyta, you are approximately the only person who seems to have a problem understanding that standards organizations like the IETF sometimes don't follow through on what they thought were good ideas and sometimes don't document that. Your response is to generate many useless efforts to clean up the IETF specs instead of just doing what everyone else does, which is to ask a question, find the answer, and move on. It feels like you are wasting lots of people's time for the benefit of no one other than maybe yourself. (If there are others who feel that Mykyta's efforts are worth our time, by all means speak up and I'm happy to back down here.)
>> Paul, Roy, and all,
>>
>> What RFC 4395 says is that all URI schemes ever registered fall into three categories: Permanent, Provisional and Historical.  There are no other cases the URI scheme may be classified as.
>>
>> RFC 1738, in its Section 4 mentioned the 'afs' URI scheme as reserved for further specifying.  Following the creation of URI schemes registry the scheme was added to Provisional category, since it does not appear to appropriate for registration as Permanent or Historical.
>>
>> RFC 4395 sets clear criteria for all the categories.  The 'afs' URI scheme may not be classified as Permanent, because of the lack of what mentioned in Section 2.1, 2.3, 2.4, 2.6 and 2.7 of RFC 4395.  This scheme is not appropriate for Provisional because of the points described in Section 3 of this document, especially the cited below:
>>
> I think the exact category these schemes are recorded under is not the key issue here.
>
> These schemes were registered because it was believed they would be used but no-one has actually used them.
>
> What is the real value and benefit in doing all the work to move them to historic? No one uses them so no one benefits from tweaking the category they are placed in IMO.
>
> One could argue that it is good housekeeping etc. but given the effort to write a draft, have it reviewed and taken through the IESG to become an RFC that no-one will read (because no-one uses the scheme in the first place) just doesn't seem a good use of the community's time and resources IMO.
Ben,

Such action might be performed by simple request of IESG.  RFC 4395 says:

Transition from 'provisional' to 'historical' may be
    requested by anyone authorized to update the provisional
    registration.

Since that is not clear who is authorized to change it, IESG should be 
considered for such action (there is not this in the document, this is 
my opinion).  So IMO IESG should issue the community call on 
reclassification and then request this action from IANA.

And in this way there won't be what you say - unnecessary docs.

All the best,
Mykyta Yevstifeyev
> Ben

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 01 Feb 2011 17:27:54 +0200

01.02.2011 17:23, Ben Niven-Jenkins wrote:
> Mykyta,
>
> On 1 Feb 2011, at 15:02, Mykyta Yevstifeyev wrote:
>> Ben,
>>
>> Since that is not clear who is authorized to change it, IESG should be considered for such action (there is not this in the document, this is my opinion).  So IMO IESG should issue the community call on reclassification and then request this action from IANA.
>>
> So you've saved an I-D being written but still used IESG time which could be much better spent on other things that actually provide value to the community.
I really do not consider the action I propose as that 'requires great 
amount of time'.  Moreover, there is a strong consensus it is not used 
and will not be used so no problems will appear, IMO.
> Also, you failed to answer the question I asked though, namely:
> Unless there is a good answer to that question to justify changing their classification, I don't see any point in spending time discussing how one might go about reclassifying them.
You should better ask the authors of RFC 4395 this, but not me.  If this 
wasn't needed, it wouldn't appear here.

Mykyta Yevstifeyev

---

From: "t.petch" <[email-masked]>
Date: Tue, 1 Feb 2011 15:37:12 +0100

----- Original Message -----
From: "Mykyta Yevstifeyev" <[email-masked]>
To: "Ben Niven-Jenkins" <[email-masked]>
Cc: <[email-masked]>; "URI" <[email-masked]>; <[email-masked]>
Sent: Tuesday, February 01, 2011 4:27 PM

 >> Since that is not clear who is authorized to change it, IESG should be
considered for such action (there is not this in the document, this is my
opinion).  So IMO IESG should issue the community call on reclassification and
then request this action from IANA.
> > So you've saved an I-D being written but still used IESG time which could be
much better spent on other things that actually provide value to the community.

> and will not be used so no problems will appear, IMO.

I have said it before, and I will go on saying it.

The time of an AD is precious, we depend on them for the IETF to happen,
so creating unnecessary work for them, by requests, by unproductive I-Ds
or any means is detrimental to the whole of the IETF.

Doing that to the IESG simply magnifies the effect by an order of magnitude.

Tom Petch

> >>> What is the real value and benefit in doing all the work to move them to
historic? No one uses them so no one benefits from tweaking the category they
are placed in IMO.
> > Unless there is a good answer to that question to justify changing their
classification, I don't see any point in spending time discussing how one might
go about reclassifying them.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 1 Feb 2011 10:40:59 -0500

On Tue, Feb 1, 2011 at 10:27 AM, Mykyta Yevstifeyev <[email-masked]> wrote:
>> So you've saved an I-D being written but still used IESG time which could
>> be much better spent on other things that actually provide value to the
>> community.
>
> I really do not consider the action I propose as that 'requires great amount
> of time'.  Moreover, there is a strong consensus it is not used and will not
> be used so no problems will appear, IMO.

It could be done as an IESG management item.  So... An AD has to
request it by putting it on a telechat agenda.  The IESG secretary has
to track it.  The IESG has to discuss it on the telechat (and the
scribe has to transcribe the discussion).  The secretary has to put it
in the minutes, and the IESG has to review the minutes.  IANA has to
make the change, and ensure that they do it right, which probably
means double-checking with the AD, who will review the IANA action.  A
notice has to be sent out.

No, that's not a *huge* amount of work.  But it *is* work and time,
spent by volunteers who are already working nights and weekends to get
their volunteer jobs done in addition to what their employers are
paying them for.

I don't know how the government works in Ukraine, but here in the U.S.
our Congress often comes out with silly "resolutions".  A few years
ago, they voted on and passed a resolution stating that Christmas is
important, for example.  Someone has to draft the resolution, it has
to be read at the meeting, someone has to speak in support of it --
sometimes multiple someones -- and a vote has to be taken.  Of course,
it passes.  But it accomplishes nothing, and it's wasted everyone's
time.

This is like that.  Let's not waste everyone's time.
In fact, let's not waste any more time discussing it.
(I'll point out, Mykyta, that you do not appear to have rough
consensus to do this, and there seems to be strong consensus NOT to.
Please accept that; it's how the IETF works.)

Barry

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 03 Feb 2011 17:22:52 +0200

31.01.2011 21:31, Alexey Melnikov wrote:
> Julian Reschke wrote:
>
>> On 31.01.2011 15:59, Paul Hoffman wrote:
>>
>>> ...
>>> Mykyta, you are approximately the only person who seems to have a
>>> problem understanding that standards organizations like the IETF
>>> sometimes don't follow through on what they thought were good ideas and
>>> sometimes don't document that. Your response is to generate many 
>>> useless
>>> efforts to clean up the IETF specs instead of just doing what everyone
>>> else does, which is to ask a question, find the answer, and move on. It
>>> feels like you are wasting lots of people's time for the benefit of no
>>> one other than maybe yourself. (If there are others who feel that
>>> Mykyta's efforts are worth our time, by all means speak up and I'm 
>>> happy
>>> to back down here.)
>>> ...
>>
>> +1
>>
>> Speaking of which: there are URI schemes that *are* in use and should 
>> be registered (independently how "bad" we think they are); candidates 
>> are "itms" and "ical", which will probably require collaboration from 
>> Apple.
>
> As well as imaps:, pops: and possibly even smtp:
I may see that the 'smtp:' URI scheme's functionality is fully covered 
by 'mailto:' one.  They are used to provide the same functionality.

Mykyta

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 08 Feb 2011 17:46:25 +0200

08.02.2011 13:16, t.petch пишет:
> From: "Larry Masinter"<[email-masked]>
> To: "Ben Niven-Jenkins"<[email-masked]>; "Mykyta Yevstifeyev"
> <[email-masked]>
> Cc:<[email-masked]>
> Sent: Tuesday, February 08, 2011 5:46 AM
>
>> I think in general the overhead in maintaining current information about old
> registered values is too high, and that it *is* worth time thinking about how we
> could lower the overhead for registry maintenance.
>> There are a number of related issues raised about various registered values,
> including MIME type, charset, and URI schemes.
>> Ideally a registry is a place where a new implementor can go to discover both
> the theory and current practice for use of registered values on the internet. I
> think the current processes cope OK with theory (although the overhead of
> updating the registry when there is a new spec is high, it might be acceptable)
> but not with practice (where implementation and deployment sometimes is in
> advance of, or divergent from, the formal specs).
>> The situation is more acute in areas where protocols and formats are
> undergoing rapid development.
>> So I agree that writing a document marking 'afs' as 'obsolete' is make-work
> and not-worth anyone's time, but how could we make it easier (light-weight
> annotation) without subjecting ourselves to DOS of unreliable annotation?
>
> The problem, at least for URI, is RFC4395, which gives the procedures for new
> schemes
> and failed to consider old schemes.  RFC1738 did not make afs: provisional or
> historic,
> it merely asked that the name be reserved.  IANA, arguably incorrectly, places
> afs: under
> Provisional citing RFC1738 as its source.  But RFC1738 does not tell them to do
> that!
Maybe IANA was guided by the following fact. While RFC 4395 mentions the 
Provisional category, it does not give full definition of its purpose. 
This might cause misunderstanding of community and other interesting 
parties. IANA, due to lack of precise definition decided that RFC 1738 
reserves these names via their provisional registration. Therefore they 
put it into corresponding category.

But we should note that RFC 4395 says:

>   To transition to the new registry, all URL name schemes in the
>     existing table should be entered as URI schemes, with 'permanent'
>     status.
and says nothing about filling the Provisional registry. This should 
have caused this problem.
> So, arguably, we could tell IANA to create a provisional registry as RFC1738
> told them to
> and make it light weight, no need for IETF/IESG involvement unless and until a
> move
> to Provisional or Permanent is envisaged, using Expert Review in other cases of
> change.
> (I know of no other way of changing things in the IETF, which is what I see as a
> constraint
> we have to accept).
Such proposal is not very clear. What do you mean while saying 'registry 
per RFC1738'. Such registry is now replaced by what created by RFC4395. 
Moreover, since you propose to make it almost not controlled, possibly 
with the 'First Come First Served' policies will create great confusion. 
I do not think such idea is good.
> Or we could write a just-once catch-all RFC that picks up all these old ones,
> and defines
> a procedure for them (ie not a registration, but a procedure for registration,
> such as
> reinforcing the need for a Reserved category and placing those in it that should
> always have
> been in it).
During the discussion of this topic in December there was such a 
proposal - to create the special Reserved category, but this did not 
gain the support. Such category's scope is very contiguous with that for 
Provisional one.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 09 Feb 2011 09:01:55 +0000

Tony Hansen wrote:

> On 2/8/2011 10:46 AM, Mykyta Yevstifeyev wrote:
>
>> Maybe IANA was guided by the following fact. While RFC 4395 mentions 
>> the Provisional category, it does not give full definition of its 
>> purpose. This might cause misunderstanding of community and other 
>> interesting parties. IANA, due to lack of precise definition decided 
>> that RFC 1738 reserves these names via their provisional 
>> registration. Therefore they put it into corresponding category.
>>
>> Such proposal is not very clear. What do you mean while saying 
>> 'registry per RFC1738'. Such registry is now replaced by what created 
>> by RFC4395. Moreover, since you propose to make it almost not 
>> controlled, possibly with the 'First Come First Served' policies will 
>> create great confusion. I do not think such idea is good.
>>
>> gain the support. Such category's scope is very contiguous with that 
>> for Provisional one.
>
> I'm wondering if the authors of RFC 4395 (of which I'm one) should 
> send a note to IANA saying that "afs" and "tn3270" should have been 
> entered into the "Permanent" portion of the URI registry instead of 
> the "Provisional" portion. (And then be done with the topic.)

While I personally like to be done with this topic, I don't think just 
declaring "afs"/"tn3270" permanent is Ok without having proper syntax 
specificications.

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 9 Feb 2011 12:03:27 +0200

Hello all,

Let me cite the URI schmes regsitry from 28 November 2005

--- Citations starts----

Uniform Resource Identifier (URI) SCHEMES

(last updated 28 November 2005)

This is the Official IANA Registry of URI Schemes

In the Uniform Resource Identifier (URI) definition [RFC3986,RFC1738]
there is a field, called "scheme", to identify the type of resource
and access method.

[....]

Reserved URI Scheme Names:

   afs              Andrew File System global file names
   tn3270           Interactive 3270 emulation sessions
   mailserver       Access to data available from mail servers

---Citations ends---

And then from February 2007, provisional category:

---Ctation starts---

Index of /assignments/uri-schemes/prov
 Name                    Last modified       Size  Description
--------------------------------------------------------------------------------
 Parent Directory        23-Feb-2007 11:55      -
 iax2                    23-Feb-2007 11:54     3k

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

Apache/1.3.27 Server at www.iana.org Port 80

---Citation ends----

The same is for Sepember 2007 and the latest archival entry from 23
October 2007 here:
http://web.archive.org/web/*/http://iana.org/assignments/uri-schemes

The question is - who added the sheme to the regsitry?

Mykyta Yevstifeyev

---

From: Tony Hansen <[email-masked]>
Date: Tue, 08 Feb 2011 16:29:31 -0500

On 2/8/2011 10:46 AM, Mykyta Yevstifeyev wrote:
> that RFC 1738 reserves these names via their provisional registration. 
> Therefore they put it into corresponding category.
>

I'm wondering if the authors of RFC 4395 (of which I'm one) should send 
a note to IANA saying that "afs" and "tn3270" should have been entered 
into the "Permanent" portion of the URI registry instead of the 
"Provisional" portion. (And then be done with the topic.)

     Tony Hansen
     [email-masked]