The 'go' URI Scheme for the Common Name Resolution Protocol
RFC 3368

Document Type RFC - Proposed Standard (August 2002; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html
Stream Legacy state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3368 (Proposed Standard)
Telechat date
Responsible AD Patrik Fältström
IESG note Responsible: RFC Editor
Send notices to <leslie@thinkingcat.com>
Network Working Group                                        M. Mealling
Request for Comments: 3368                                VeriSign, Inc.
Category: Standards Track                                    August 2002

      The 'go' URI Scheme for the Common Name Resolution Protocol

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document defines a URI scheme, 'go:' to be used with the Common
   Name Resolution Protocol.  Specifically it lays out the syntactic
   components and how those components are used by URI Resolution to
   find the available transports for a CNRP service.  Care should be
   taken with several of the URI components because, while they may look
   like components found in other URI schemes, they often do not act
   like them.  The "go" scheme has more in common with the location
   independent "news" scheme than any other URI scheme.

Mealling                    Standards Track                     [Page 1]
RFC 3368                CNRP URI Specification               August 2002

Table of Contents

   1.    Goals  . . . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.    Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  2
   3.    Syntax Rules . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.1   General Syntax . . . . . . . . . . . . . . . . . . . . . . .  3
   3.2   ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.3   Special Cases and Default Values . . . . . . . . . . . . . .  4
   3.3.1 If There is Only a Server  . . . . . . . . . . . . . . . . .  4
   3.3.2 If Server is Empty Then server=localhost . . . . . . . . . .  4
   3.3.3 Default Port . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.4   Encoding Rules . . . . . . . . . . . . . . . . . . . . . . .  4
   4.    Transport Independence . . . . . . . . . . . . . . . . . . .  4
   5.    Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   6.    Security Considerations  . . . . . . . . . . . . . . . . . .  5
   7.    IANA Considerations  . . . . . . . . . . . . . . . . . . . .  5
         References . . . . . . . . . . . . . . . . . . . . . . . . .  6
   A.    Registration Template  . . . . . . . . . . . . . . . . . . .  7
         Author's Address . . . . . . . . . . . . . . . . . . . . . .  7
         Full Copyright Statement . . . . . . . . . . . . . . . . . .  8

1. Goals

   The two goals of the CNRP [3] URI [1] are to identify both a specific
   common-name record at a specific server and to identify a possibly
   dynamic query or entry point into the query process.  Since CNRP
   requires that the ID be a core query term, these two cases can be
   generalized down to simply specifying a query that contains only the
   ID of the item.

   On first glance it would seem a simple enough exercise to
   canonicalize the XML encoded query and then insert it into the query
   portion of the URL.  The problem here is that, due to the encoding
   rules, any remotely complex query will quickly blow out the URI
   length limitations.  The suggested solution is to provide a
   simplified query syntax that is a subset of what is available via the
   XML.

2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [4].

Mealling                    Standards Track                     [Page 2]
RFC 3368                CNRP URI Specification               August 2002

3. Syntax Rules

3.1 General Syntax

   The CNRP URI comes in two forms.  The first form is for talking to a
   specific server.  The second form is for expressing a query that is
   meant to be sent to several different CNRP services.  The following
   two examples are for pedagogical purposes only.  The complete ABNF
   grammar in Section 3.2 is the only authoritative syntax definition.

   go://[<host>]?[<common-name>]*[;<attribute>=[<type>,]<value>]

   and

   go:<common-name>*[;<attribute>=[<type>,]<value>]

3.2 ABNF Grammar
Show full document text