IPP Mail Archive: RE: IPP> possible compromise?

IPP Mail Archive: RE: IPP> possible compromise?

RE: IPP> possible compromise?

Larry Masinter (masinter@parc.xerox.com)
Wed, 15 Jul 1998 02:05:09 PDT

Robert, Herriot wrote:

# I would also like to see an IETF document that describes the intent
# and goals of this differentiation of schemes, as well as the infrastructure
# needed to support it.
primarily:
draft-ietf-urlreg-guide-02.txt

but also:
RFC 1630 (URI in WWW)
RFC 1738 (URL)
draft-fielding-uri-syntax-03.txt
RFC 2068 (HTTP)

The first document that describes the intent and goals of schemes
was RFC 1630 "Universal Resource Identifiers in WWW". This is an
Informational document, which was then followed by RFC 1738, "Uniform
Resource Locators" Soon after that document was released, there
was a lengthy debate over the issue of the use of the 'gopher:'
URL scheme for implementing the 'finger' protocol, and a belief
that -- even though you could think of 'finger' being a gopher
call on a different port, and restricted to a subset of gopher
syntax -- that it was an inappropriate use, and that finger should
have its own scheme.

After the publication of RFC 1738, a set of guidelines for registration
of new schemes arose in notes on the URI mailing list and
a web page maintained by Harald Alvestraad. Eventually, we formed a
working group (URLREG), which is developing guidelines for new URL schemes;
draft-ietf-urlreg-guide-02.txt is the latest document. The document is
primarily focused on the converse issue to that at hand in IPP: the problem
of people trying to register schemes that are inappropriate, rather than
that of people trying to use existing schemes inappropriately.

But, for example, section 2.2.5 seems to allude to the fact that the "http"
scheme is mostly used as a mechanism to access a data resource.

In general, if a URL scheme is registered for one purpose, a new standards
track document should not (without review) usurp that scheme for a different
purpose.

# I would like to know how a protocol designer decides if a new service
# is different enough to warrant a new scheme.

There are guidelines, and then there is process. We can write better guidelines,
I hope, but coming up with a deterministic process may be hard.

Giving an effective decision procedure for when new schemes are appropriate
has been a thorny problem for the URL registration group, and the converse
(when is a new scheme REQUIRED) is likely to have the same difficulties.
In the end, it is a matter of judgement. The current process is that the
IESG is the authority for that judgement, and that IESG approval is required
for new registered schemes. One might imagine that the converse would hold:
that IESG judgement is required ultimately to decide on when it is appropriate
to reuse an old scheme for a new purpose.

Larry