Message-Id: <9411041533.AA08588@mocha.bunyip.com>
To: dcrocker@mordor.stanford.edu (Dave Crocker)
Subject: Re: generic IESG comments
In-Reply-To: Your message of Fri, 04 Nov 1994 07:25:02 -0800. <v03000503aadfff0a8084@[128.102.17.23]>
Date: Fri, 04 Nov 1994 16:33:06 +0100
From: "Erik Huizer (SURFnet BV)" <Erik.Huizer@surfnet.nl>
Dave,
==> From: Dave Crocker
> It appears that the IESG is approving publication of documents which the
> IESG deems incomplete.
Correction. The URL spec is not deemed incomplete. What the IESG worries
about is that these issues are not addressed neither in the URL spec nor in
the informational document the URN requirements. The IESG argumentation went
along the lines:
> p.s. It also seems that the scaling & replication, and the protocol
> dependence concerns are best addressed (pun...) by URNs and not URLs. URLs
> -- in their current form and with the major deficiencies you cite -- have
> already proved massively useful. There is long IETF history of blessing
> accepted practise, no matter how much better one might wish that practise.
> Worse, the concerns you cite have been present for quite some time and
> clearly are not proving to be easily remedied. It therefore is unlikely
> that some magic wand is going to solve them in the next 6 months.
>
> To re-state the URL/URN issue, I note that the domain name lookup service
> has the feature you cite but that IP addresses do not. URLs are roughly
> equivalent to URLs. URNs should be able to map to multiple machine
> instantiations and multiple protocol accesses. URLs should not.
Therefore it seemed to make sense to advance the URL spec (deemed complete,
if these issues are addressed in the URN spec), and revisit the issues when
the URL is up for Draft.
>
> In particular, modification of the base technology to any significant
> extent is required to re-set the clock on a standards track specification,
> re-entering it as a new Proposed standard. I.e., it may not advance to
> Draft.
If by then we find that the URN spec fixes the issues, and that the URL can
remain largely unchanged that will move to Draft status. If however it turns
out that the URL needs changing, it will indeed have to be recycled.
>
> Please explain this apparent deviation from long- and well-established IETF
> practise.
No deviation I think, just lack of clearness on my part.
Erik