RE: IPP> possible compromise?
"Larry Masinter" <masinter@parc.xerox.com> Wed, 15 July 1998 09:16 UTC
Delivery-Date: Wed, 15 Jul 1998 05:16:53 -0400
Return-Path: ipp-owner@pwg.org
Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id FAA08850 for <ietf-archive@ietf.org>; Wed, 15 Jul 1998 05:16:31 -0400 (EDT)
Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id FAA13316 for <ietf-archive@cnri.reston.va.us>; Wed, 15 Jul 1998 05:16:29 -0400 (EDT)
Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id FAA17038 for <ietf-archive@cnri.reston.va.us>; Wed, 15 Jul 1998 05:16:31 -0400 (EDT)
Received: by pwg.org (bulk_mailer v1.5); Wed, 15 Jul 1998 05:10:36 -0400
Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id FAA16022 for ipp-outgoing; Wed, 15 Jul 1998 05:05:47 -0400 (EDT)
From: Larry Masinter <masinter@parc.xerox.com>
To: Robert Herriot <robert.herriot@eng.sun.com>, Keith Moore <moore@cs.utk.edu>, ipp@pwg.org
Cc: moore@cs.utk.edu
Subject: RE: IPP> possible compromise?
Date: Wed, 15 Jul 1998 02:05:09 -0700
Message-ID: <000c01bdafcf$ab0ba4c0$15d0000d@copper-208.parc.xerox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <199807150207.TAA21443@woden.eng.sun.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-ipp@pwg.org
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
- IPP> possible compromise? Keith Moore
- Re: IPP> possible compromise? Robert Herriot
- Re: IPP> possible compromise? Keith Moore
- RE: IPP> possible compromise? Larry Masinter
- Re: IPP> possible compromise? Harry Lewis
- Re: IPP> possible compromise? Keith Moore
- Re: IPP> possible compromise? Ira Mcdonald x10962
- Re: IPP> possible compromise? Keith Moore
- Re: IPP> possible compromise? Harry Lewis