<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
    There has to be one entity for each item to be referenced.
    An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC5226 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC3986 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC3987 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3987.xml">
<!ENTITY RFC5234 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml">

]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
    please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
    (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
    (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="no" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->

<?rfc private="" ?>

<rfc category="exp" docName="draft-mosko-icnrg-ccnxurischeme-01" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
       or pre5378Trust200902
    you can add the attributes updates="NNNN" and obsoletes="NNNN"
    they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the
        full title is longer than 39 characters -->

    <title abbrev="CCNxScheme">The CCNx URI Scheme</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Marc Mosko" initials="M.E." surname="Mosko">
      <organization>PARC, Inc.</organization>

      <address>
       <postal>
         <street/>

         <!-- Reorder these if your country does things differently -->

         <city>Palo Alto</city>

         <region>California</region>

         <code>94304</code>

         <country>USA</country>
       </postal>

       <phone>+01 650-812-4405</phone>

       <email>marc.mosko@parc.com</email>

       <!-- uri and facsimile elements may also be added -->
     </address>
    </author>

    <author fullname="Christopher A. Wood" initials="C.A.W." surname="Wood">
      <organization>PARC, Inc.</organization>

      <address>
       <postal>
         <street/>

         <!-- Reorder these if your country does things differently -->

         <city>Palo Alto</city>

         <region>California</region>

         <code>94304</code>

         <country>USA</country>
       </postal>

       <phone>+01 650-812-4421</phone>

       <email>christopher.wood@parc.com</email>

       <!-- uri and facsimile elements may also be added -->
     </address>
    </author>

    <date year="2016"/>

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill
        in the current day for you. If only the current year is specified, xml2rfc will fill
	 in the current day and month for you. If the year is not the current one, it is
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>ICNRG</workgroup>

    <!-- WG name at the upperleft corner of the doc,
        IETF is fine for individual submissions.
	 If this element is not present, the default is "Network Working Group",
        which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>Content Centric Networking, Information Centric Networking</keyword>

    <!-- Keywords will be incorporated into HTML output
        files in a meta tag but they have no effect on text or nroff
        output. If you submit your draft to the RFC Editor, the
        keywords will be used for the search engine. -->

    <abstract>
      <t>
        This document defines an RFC3986 URI compliant identifier called a Labeled
        Segment URI in which name segments carry a label. This allows differentiation
        between unrelated resources with similar identifiers. This document also
        specifies the CCNx URI scheme, called "ccnx:," which conforms to the
        labeled segment encoding rules presented here. The CCNx URI scheme
        applies specific labels to each name segment of a URI to disambiguate between
        resources with similar names. This document defines a specific set of
        segment labels with label semantics.
        </t>
    </abstract>
  </front>

  <middle>

    <section title="Introduction">
      <t>A Labeled Segment is an <xref target="RFC3986">URI</xref> compliant convention
        that allows an application or protocol to embed labels in name segments, thus disambiguating
        the resource identified by the path.  Labeled Segment URIs also allow for
        query and fragment components to follow the Labeled Segment form.
      </t>

      <t>Some protocols may wish to disambiguate name segments between different identifier
        spaces, such as "version" and "page".  Other protocols may wish to use a type system
        such as "/str=parc/int=7" and "/str=parc/str=7".  Labeled Segment URIs provide an unambiguous
        and flexible representation in systems that allow resources with otherwise similar names.</t>

      <t>It is not sufficient to leave the determination of type to application-specific
        conventions.  In a networked system with multiple applications accessing resources
        generated by other applications, there needs to be a set of common
        conventions.  For example, if one application uses a base 64 encoding of a frame number,
        e.g. base64(0xbdea), and another uses "ver=" to represent a document version,
        there is an ambiguity because base64(0xbdea) is the string "ver=".</t>

      <t>Labeled Segments defines "ls-segment" as "label[:param]=value", where the
        value only contains unreserved, percent-encoded, or certain sub-delim
        characters.  In the previous example, one application would say "/frame=%BD%EA"
        and the other would say "/ver=".</t>
      <t>In this document, we use <xref target="RFC3986">URI</xref> terminology, therefore a URI
      and CCNx Name are both composed of a URI path, which is a collection  of name segments.
      We do not use the term "name component" as was common in old CCNx. In this document,
      the word "segment" alone means "name segment."</t>

      <t>URIs conforming to the CCNx URI scheme carry a label for each name segment.
          The contents of each name segment must conform to the label semantics.
          Example segment types are "Binary Segment", "Name", and "KeyId".</t>

      <t>We use Labeled Segment URIs as the canonical, human-readable representation.
        There is an unambiguous, one-to-one correspondence between
      an absolute LS-URI path and a Labeled Name.  Relative URI representations
      are removed during encoding, so no relative name ends up in wire format.
      Some labels are URIs that are <xref target="RFC3987">IRI</xref> compatible.</t>

      <t>Labeled Names shall be used everywhere a Name is used in CCNx, such as
      in the Name of an Interest or Content Object.  They are also used in Links,
      KeyLocators, or any other place requiring a name.  When encoded for the wire, a binary
      representation is used, depending on the specific wire format codec, which
      is outside the scope of this document.
      </t>

      <t>This document specifies:
        <list style="symbols">
          <t>the ccnx scheme.</t>
          <t>a canonical URI representation.</t>
        </list>
      </t>

      <t>Formal grammars use the <xref target="RFC5234">ABNF</xref> notation.</t>
      <t>TODO: We have not adopted Requirements Language yet.</t>

      <section title="Requirements Language">
        <t>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 <xref target="RFC2119">RFC 2119</xref>.</t>
      </section>
    </section>

    <section anchor="LSU" title="URI path segment grammar for label=value pairs">
      <section anchor="segments" title="Labeled Segments">
        <t>This section describes the formal grammar for Labeled Segments
          using <xref target="RFC5234">ABNF</xref> notation.  We do not impose restrictions on the length
          of labels or values.  The semantics of values are URI scheme specific, here we only describe the
          meta-structure of Labeled Segments.  We begin by reviewing some definitions from
          <xref target="RFC3986"/> that define an absolute path URI.</t>

        <figure>
          <artwork align="left"><![CDATA[
URI           = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
hier-part     = "//" authority path-abempty
                / path-absolute
                / <other path types>
path-absolute = "/" [ segment-nz *( "/" segment ) ]
segment       = *pchar
segment-nz    = 1*pchar
pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
query         = *( pchar / "/" / "?" )
fragment      = *( pchar / "/" / "?" )
pct-encoded   = "%" HEXDIG HEXDIG
unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
reserved      = gen-delims / sub-delims
gen-delims    = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
                    / "*" / "+" / "," / ";" / "="
]]></artwork>
        </figure>

        <t>Labeled Segments defines a new segment type that provides unambiguous representation
          of a segment's label and its value.  We define the top-level LS-URI as the same
          form as a URI, wherein each part conforms to the Label Segment grammar, which is
          a subset of the URI grammar.</t>

        <figure>
          <artwork align="left"><![CDATA[
LS-URI           = scheme ":" ls-hier-part ["?" ls-query]
                   ["#" fragment]
ls-hier-part     = ["//" authority] ls-path-absolute
ls-path-absolute = "/" [ first-segment *( "/" ls-segment ) ]
first-segment    = ls-segment-nz
ls-segment       = lpv-segment / v-segment
lpv-segment      = label [":" param] "=" *s-value-nz
v-segment        = *s-value-nz
ls-segment-nz    = lpv-segment-nz / v-segment-nz
lpv-segment-nz   = label [":" param] "=" s-value-nz
v-segment-nz     = s-value-nz
label            = alpha-t / num-t
param            = alpha-t / num-t
s-value-nz       = 1*(s-pchar)

ls-query         = *1 ( lpv-component / v-component
                        *( "&" (lpv-component / v-component) ) )
lpv-component    = label [":" param] "=" q-value
v-component      = q-value
q-value          = *(q-pchar)

alpha-t          = ALPHA *(ALPHA / DIGIT)
num-t            = dec-t / hex-t
dec-t            = 1*(DIGIT)
hex-t            = "0x" 1*(HEXDIG)
ls-pchar         =  unreserved / pct-encoded / ls-sub-delims
s-pchar          = ls-pchar / ":" / "@" / "&"
q-pchar          = ls-pchar / ":" / "@" / "/"
ls-sub-delims    = "!" / "$" / "'" / "(" / ")"
                       / "*" / "+" / "," / ";"
]]></artwork>
        </figure>

        <t>A Labeled Segment URI (LS-URI) contains a scheme that uses Labeled Segments,
          an optional authority, a labeled segment absolute path (ls-path-aboslute),
          an optional labeled segment query (ls-query), and a fragment.  The authority
          is URI scheme specific and the fragment is independent of the URI scheme.</t>

        <t>the ls-path-aboslute is a first-segment followed by zero or more "/" ls-segment.
            The first-segment may be empty or a non-zero ls-segment (ls-segment-nz).
            If it is empty, it corresponds to a 0-lenght name which typically is a default
            route.  It is distinct from a 1-segment name with no value (which is not allowed).  
			The first-segment
            MUST either be empty (the 0-lenght name) or MUST have a value.
            If the first-segment is an ls-segment-nz, then it will have a value.</t>

        <t>An ls-segment may (lpv-segment) or may not (v-segment) have a label.
            A particular LS-URI scheme MUST define how unlabeled segments are processed, and MAY
            disallow them.  A v-segment is an implied type.  Once the implied type is resolved,
            it functions like an lpv-segment.</t>

        <t>An lpv-segment has a label, optional parameter, and optional value (s-value-nz).
            An empty value is a 0-length name segment with a defined type.  This is distinct
            from a 0-length first-segment, which has neither type nor value.</t>

        <t>lpv-segment values come from the s-pchar set, which excludes the "=" equal
          sign.  This means that the only equal sign in a name segment must be the
          delimiter between the label:param and the value.  Within the value, an equal
          sign must be percent encoded.</t>

        <t>lpv-segment labels and values may be alpha-numeric identifiers or numbers
          (decimal or hexadecimal).  For example, one scheme may define the labels "name",
          "version", and "frame".  A version may be of types "date" or "serial", meaning
          that the version is either a date or a monotonic serial number.  Some examples
          of resulting LS-URIs are: "/name=parc/name=csl/version:date=20130930" or
          "/name=alice_smith/version:serial=299".  The parameters may also indicate
          an instance of a label, such as "/name=books/year:1=1920/year:3=1940",
          where there are scheme or application semantics associated with "year:1" and "year:3".</t>

        <t>lpv-segment labels and parameters may also be numbers.  For example, a
          protocol with a binary and URI representation may not have pre-defined
          all possible labels. In such cases, it could render unknown labels as
          their binary value, such as "/name=marc/x2003=green".</t>

        <t>The ls-query component is a non-hierarchical set of components
          separated by "&amp;".  Each ls-query component is either a lpv-component
          or a v-component, similar to segments.  They are based on q-value, which
          uses q-pchar that excludes "&amp;", but includes "/".  This allows
          an LS-URI scheme to use type query parameters.</t>

        <t>Labeled Segments allow for dot-segments "." and ".." in a v-segment.  They operate as normal.
          A single dot "." refers to the current hierarchy level and may be elided when the URI
          is resolved.  Double dot ".." segments pop off the previous non-dot segment.
          An lpv-segment with a value of "." or ".." is not a dot-segment.  It means that the
          value of the given label is "." or "..".  For example /a=parc/b=csl/.. is equivalent
          to "/a=parc/b=csl", but the LS-URI "/a=parc/b=csl/c=.." does not contain a dot-segment.</t>
      </section>

      <section anchor="compare" title="URI comparison">
        <t>An LS-URI scheme MUST specify the normalization rules
          to be used, following the methods of <xref target="RFC3986">Section 6</xref>.
          At minimum, an LS-URI scheme SHOULD do the following:
          <list style="symbols">
            <t>Normalize unrestricted percent-encodings to the unrestricted form.</t>
            <t>Normalize num-t to either dec-t or hex-t.</t>
            <t>If the scheme allows for value-only segments or query components and
              interprets them as a default type, they should be normalized to having
              the type specified.</t>
            <t>If the scheme allows for undefined labels and represents them,
              for example, as num-t, then it should normalize all labels to their
              corresponding num-t.  If "name", for example, is known to be %x50 in
              a binary encoding of the URI, then all labels should be compared using
              their numeric value.</t>
          </list>
        </t>
      </section>
</section>
    <section anchor="CCNx" title="Application to CCNx Names">
    <section anchor="labels" title="The ccnx Scheme">
      <t>This section describes the CCNx URI scheme "ccnx:" for Labeled Names.
        A Labeled Name assigns a semantic type or label to each segment of
        the hierarchical content Name.</t>

      <t>Unless otherwise specified, a name segment is an arbitrary sequence of octets.</t>

      <t>Several name segment labels are binary unsigned integers.  These are always encoded as variable length
      sequences of 1 or more octets in network byte order using the shortest representation (i.e. no leading %x00).
      The value of "0" is encoded as the single byte of "%x00".  A zero-length sequence must be interpreted
      as "not present."</t>

      <t>
      The CCNx Name segment types are:
        <list style="symbols">
          <t>Name Segment: A generic name segment that includes arbitrary octets.</t>
          <t>Application Type N: An application may use application-specific parameters, numbered
          as integers, where N is from 0 to a system-specific maximum, not less than 255.  These
          are represented as "App:1=value", for example.</t>
         </list>
      </t>

       <t>It is common for an information centric networking protocol, such as CCNx or NDN, to
       use a binary on-the-wire representation for messages.  Such protocols, if they use the
       ccnx: scheme, must have an appropriate codec that unambiguously represents Labeled
       Content Information in the chosen wire format.  Relative dot-segments should not
       occur in the wire format, they should be resolved before encoding.</t>
     </section>

    <section anchor="URI" title="URI Representation">
      <t>Typed Names use a standard RFC 3986 representation following the LS-URI convention.
        A name segment consists of any
        "unreserved" characters plus percent-encoded characters.  Reserved characters must be
         percent encoded.</t>

      <t>Within an absolute path, each segment consists of an "ls-segment" (c.f. LS-URI).
      A labeled segment is a type and a name component value, with a URI representation
      of "type=value".  The "type=" portion may be omitted if it is type Name.</t>

      <t>Some name types take a parameter, such as the Application types.  They are represented
      as "A:nnn=value", where the "nnn" is the application type number and value is the name
      component.</t>

      <t>A CCNx URI MUST NOT include an Authority, Query, or Fragment.  It is an error
      to include them.</t>

      <t>Dot-segments (relative name components) are resolved when the URI is converted to
      a Typed Name.  The "." dot-segment is removed.  The ".." dot-segment is removed along
      with the previous non-dot-segment.</t>

      <texttable anchor="message_type" title="The CCNx URI Scheme Types">
        <ttcol align="center">Type</ttcol>
        <ttcol align="center">Display</ttcol>
        <ttcol align="center">Name</ttcol>


        <c>'Name'</c>
        <c>Hexadecimal</c>
        <c>Name Segment</c>

        <c>'IPID'</c>
        <c>Hexadecimal</c>
        <c>Interest Payload Identifier segment</c>

        <c>'App:0' - 'App:255'</c>
        <c>Hexadecimal</c>
        <c>Application Component</c>
      </texttable>

      <section anchor="Examples" title="Examples">
        <figure>
          <artwork align="left"><![CDATA[
A name / is
    ccnx:/ and is a 0-length name.

A name /Name= is
    ccnx:/Name= and is a 1-segment name of 0-length.

A name /foo/bar.
   ccnx:/Name=foo/Name=bar
   ccnx:/foo/Name=bar
   ccnx:/foo/bar

A name /foo/bar with key %xA0.
    ccnx:/Name=foo/Name=bar/App:1=0xA0

A name /foo/bar with version %xA0 and App:2 value 0x09.
    ccnx:/foo/bar/Version=0xA0/App:2=0x09

A name /foo/.., where the ".." is a literal name component,
not a relative dot-segment.
   ccnx:/foo/Name=..

A name /foo/bar with application type 0 "hello"
and application type 1 "world".
   ccnx:/Name=foo/Name=bar/App:0=hello/App:1=world
 ]]></artwork>
        </figure>
      </section>
    </section>


    <section anchor="compareb" title="ccnx: URI comparison">
      <t>While most comparisons are done using a wire format representation
        of a ccnx: URI, some applications may compare the CCNx URI using
      their URI representation.  This section defines the rules for
      comparing ccnx: URIs using the methods of <xref target="RFC3986">Section 6</xref>
      </t>

      <t>Comparing typed name URIs must be done with:
        <list style="symbols">
          <t>Syntax-based normalization</t>
          <t>Case normalization: normalize the representation of percent encodings.
          ccnx: does not use the host portion of the URI, and should be ignored if
          present.</t>
          <t>Percent encoding normalization: Percent encodings of unreserved
          characters must be converted to the unreserved character.</t>
          <t>Path segment normalization: dot-segments must be resolved first.</t>
          <t>Scheme-based normalization: The authority should be removed and
          the path represented as an absolute path.</t>
          <t>Protocol-based normalization: Should not be done.  A trailing
          slash indicates a zero-length terminal name component and signifies
          a different name.</t>
          <t>typed-name-segment normalization: All segments should be presented
          with their type, do not elide the "N=" for Name components.</t>
          <t>Binary unsigned integer normalization: remove any leading %x00
          from numbers, leaving only the terminal %x00 for "0".</t>
          <t>type parameters: they must have their percent encodings normalized.
          If they are integers, such as for the 'A' type, they must not have
          leading zeros.</t>
        </list>
      </t>
    </section>
    </section>
     <section anchor="IRI" title="IRI Considerations">
      <t>International Resource Identifiers extend the unreserved character set
        to include characters above U+07F and encode them using percent encoding.
        This extension is compatible with the ccnx: schema.  It applies only to the
        "value" portion of an ls-segment.</t>

      <t>The canonical name is determined by the
        URI representation of the IRI, after applying the rules of Section 3.1
      of <xref target="RFC3987"/> and resolving dot-segments.  The canonical name thus includes the
      URI representation of language markers, including the bidirectional
      components.</t>

      <t>The value of a UTF-8 Name segment should be interpreted using IRI rules,
      including bidirectional markers.  They may be displayed using localized
      formats.</t>

      <t>Binary unsigned integer types are not interpreted
      under IRI rules, they are specifically percent encoded numbers.  They may be
      displayed using a localized format.</t>

    </section>


    <!-- This PI places the pagebreak correctly (before the section title) in the text output. -->

    <?rfc needLines="8" ?>


    <section anchor="Acknowledgements" title="Acknowledgements"> </section>

    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>

      <t>All drafts are required to have an IANA considerations section (see <xref target="RFC5226"
          >Guidelines for Writing an IANA Considerations Section in RFCs</xref> for a guide). If the
        draft does not require IANA to do anything, the section contains an explicit statement that
        this is the case (as above). If there are no requirements for IANA, the section will be
        removed during conversion into an RFC by the RFC Editor.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>All drafts are required to have a security considerations section. See <xref
          target="RFC3552">RFC 3552</xref> for a guide.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
    1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
    2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
       (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

    Both are cited textually in the same manner: by using xref elements.
    If you use the PI option, xml2rfc will, by default, try to find included files in the same
    directory as the including file. You can also define the XML_LIBRARY environment variable
    with a value containing a set of directories to search.  These can be either in the local
    filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
      <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
      &RFC2119; </references>

    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->
      &RFC3552;
      &RFC3986;
      &RFC3987;
      &RFC5226;
      &RFC5234;

      <!-- A reference written by by an organization not a person. -->

    </references>

  </back>
</rfc>
