IPP> Need an I-D to register 'ipp:' URL scheme with IANA

IPP> Need an I-D to register 'ipp:' URL scheme with IANA

IPP> Need an I-D to register 'ipp:' URL scheme with IANA

McDonald, Ira imcdonald at sharplabs.com
Mon Nov 13 17:21:27 EST 2000

Hi folks,                                      Monday (13 November 2000)

I have just discovered that the 'ipp:' URL scheme was never registered
with IANA.  Bob Herriot and I plan to write an Internet-Draft which
conforms to RFC 2717.  Each IANA registered URL scheme MUST be published
in a 'standards track' RFC.

The IPP/1.1 Protocol (RFC 2910) and the 'indp:' notification delivery
method I-D do NOT meet the RFC 2717 requirements.

The RFCs about URL scheme registration:

  2717 Registration Procedures for URL Scheme Names. R. Petke, I. King.
       November 1999. (Format: TXT=19780 bytes) (Also BCP0035) (Status:
  2718 Guidelines for new URL Schemes. L. Masinter, H. Alvestrand, D.
       Zigmond, R. Petke. November 1999. (Format: TXT=19208 bytes)
       (Status: INFORMATIONAL)

A recent RFC that conforms to RFC 2717 (and was registered):

  2806 URLs for Telephone Calls. A. Vaha-Sipila. April 2000. (Format:
       TXT=50647 bytes) (Status: PROPOSED STANDARD)

The IANA registry of URL schemes:


- Ira McDonald, consulting architect at Xerox and Sharp
  High North Inc

[excerpts from RFC 2717]

3.2 The IETF Tree

   Registration in the IETF tree requires publication of the URL scheme
   syntax and semantics in either an Informational or Standards Track
>> RFC. In general, the creation of a new URL scheme requires a
>> Standards Track RFC.  An Informational RFC may be employed for
>> registration only in the case of a URL scheme which is already in
>> wide usage and meets other standards set forth in RFC 2718, such as
>> "demonstrated utility" within the Internet Architecture; the IESG
   shall have broad discretion in determining whether an Informational
   RFC is suitable in any given case, and may either recommend changes
   to such document prior to publication, or reject it for publication.
   An Informational RFC purporting to describe a URL scheme shall not be
   published without IESG approval.  This is a departure from practice
   for Informational RFCs as set forth in RFC 2026, for the purpose of
   ensuring that the registration of URL schemes shall serve the best
   interests of the Internet community.

   The NAMES of schemes registered in the IETF tree MUST NOT contain the
   dash (also known as the hyphen and minus sign) character ('-')
   USASCII value 2Dh.  Use of this character can cause confusion with
   schemes registered in alternative trees (see section 3.3).

>> An analysis of the security issues inherent in the new URL scheme is
>> REQUIRED. (This is in accordance with the basic requirements for all
>> IETF protocols.) URL schemes registered in the IETF tree should not
>> introduce additional security risks into the Internet Architecture.
   For example, URLs should not embed information which should remain
   confidential, such as passwords, nor should new schemes subvert the
   security of existing schemes or protocols (i.e. by layering or

   The "owner" of a URL scheme name registered in the IETF tree is
   assumed to be the IETF itself.  Modification or alteration of the
   specification requires the same level of processing (e.g.
   Informational or Standards Track RFC) as used for the initial
   registration.  Schemes originally defined via an Informational RFC
   may, however, be replaced with Standards Track documents.

6.0  Registration Template

   The following issues should be addressed when documenting a new URL

      URL scheme name.

>>    URL scheme syntax.  This should be expressed in a clear and
>>    concise manner.  The use of ABNF is encouraged.  Please refer to
>>    RFC 2718 for guidance on designing and explaining your scheme's
>>    syntax.

      Character encoding considerations.  It is important to identify
      what your scheme supports in this regard.  It is obvious that for
      interoperability, it is best if there is a means to support
      character sets beyond USASCII, but especially for private schemes,
      this may not be the case.

      Intended usage.  What sort of resource is being identified?  If
      this is not a 'resource' type of URL (e.g. mailto:), explain the
      action that should be initiated by the consumer of the URL.  If
      there is a MIME type associated with this resource, please
      identify it.

      Applications and/or protocols which use this URL scheme name.
      Including references to documentation which defines the
      applications and/or protocols cited is especially useful.

      Interoperability considerations.  If you are aware of any details
      regarding your scheme which might impact interoperability, please
      identify them here.  For example: proprietary or uncommon encoding
      method; inability to support multibyte character sets;
      incompatibility with types or versions of underlying protocol (if
      scheme is tunneled over another protocol).

      Security considerations.

      Relevant publications.

      Person & email address to contact for further information.

      Author/Change controller.

   Applications and/or protocols which use this URL scheme name.

7.0 Security Considerations

   Information that creates or updates a registration needs to be

   Information concerning possible security vulnerabilities of a
   protocol may change over time.  Consequently, claims as to the
   security properties of a registered URL scheme may change as well.
   As new vulnerabilities are discovered, information about such
   vulnerabilities may need to be attached to existing documentation, so
   that users are not misled as to the true security properties of a
   registered URL scheme.


More information about the Ipp mailing list