IPP Mail Archive: IPP> Need an I-D to register 'ipp:' URL sc

IPP Mail Archive: IPP> Need an I-D to register 'ipp:' URL sc

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

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Mon Nov 13 2000 - 17:21:27 EST

  • Next message: Vanessa Andrew: "IPP> WWW.PWG.ORG"

    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:
           BEST CURRENT PRACTICE)
      
      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:

      ftp://ftp.isi.edu/in-notes/iana/assignments/url-schemes

    Cheers,
    - 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
       tunneling).

       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
       scheme:

          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
       authenticated.

       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.

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



    This archive was generated by hypermail 2b29 : Mon Nov 13 2000 - 17:32:05 EST