idnits 2.17.1 draft-mosko-icnrg-ccnxurischeme-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 6, 2016) is 2935 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG M. Mosko 3 Internet-Draft C. Wood 4 Intended status: Experimental PARC, Inc. 5 Expires: October 8, 2016 April 6, 2016 7 The CCNx URI Scheme 8 draft-mosko-icnrg-ccnxurischeme-01 10 Abstract 12 This document defines an RFC3986 URI compliant identifier called a 13 Labeled Segment URI in which name segments carry a label. This 14 allows differentiation between unrelated resources with similar 15 identifiers. This document also specifies the CCNx URI scheme, 16 called "ccnx:," which conforms to the labeled segment encoding rules 17 presented here. The CCNx URI scheme applies specific labels to each 18 name segment of a URI to disambiguate between resources with similar 19 names. This document defines a specific set of segment labels with 20 label semantics. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 8, 2016. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 58 2. URI path segment grammar for label=value pairs . . . . . . . . 5 59 2.1. Labeled Segments . . . . . . . . . . . . . . . . . . . . . 5 60 2.2. URI comparison . . . . . . . . . . . . . . . . . . . . . . 7 61 3. Application to CCNx Names . . . . . . . . . . . . . . . . . . 9 62 3.1. The ccnx Scheme . . . . . . . . . . . . . . . . . . . . . 9 63 3.2. URI Representation . . . . . . . . . . . . . . . . . . . . 9 64 3.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 11 65 3.3. ccnx: URI comparison . . . . . . . . . . . . . . . . . . . 11 66 4. IRI Considerations . . . . . . . . . . . . . . . . . . . . . . 13 67 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 75 1. Introduction 77 A Labeled Segment is an URI [RFC3986] compliant convention that 78 allows an application or protocol to embed labels in name segments, 79 thus disambiguating the resource identified by the path. Labeled 80 Segment URIs also allow for query and fragment components to follow 81 the Labeled Segment form. 83 Some protocols may wish to disambiguate name segments between 84 different identifier spaces, such as "version" and "page". Other 85 protocols may wish to use a type system such as "/str=parc/int=7" and 86 "/str=parc/str=7". Labeled Segment URIs provide an unambiguous and 87 flexible representation in systems that allow resources with 88 otherwise similar names. 90 It is not sufficient to leave the determination of type to 91 application-specific conventions. In a networked system with 92 multiple applications accessing resources generated by other 93 applications, there needs to be a set of common conventions. For 94 example, if one application uses a base 64 encoding of a frame 95 number, e.g. base64(0xbdea), and another uses "ver=" to represent a 96 document version, there is an ambiguity because base64(0xbdea) is the 97 string "ver=". 99 Labeled Segments defines "ls-segment" as "label[:param]=value", where 100 the value only contains unreserved, percent-encoded, or certain sub- 101 delim characters. In the previous example, one application would say 102 "/frame=%BD%EA" and the other would say "/ver=". 104 In this document, we use URI [RFC3986] terminology, therefore a URI 105 and CCNx Name are both composed of a URI path, which is a collection 106 of name segments. We do not use the term "name component" as was 107 common in old CCNx. In this document, the word "segment" alone means 108 "name segment." 110 URIs conforming to the CCNx URI scheme carry a label for each name 111 segment. The contents of each name segment must conform to the label 112 semantics. Example segment types are "Binary Segment", "Name", and 113 "KeyId". 115 We use Labeled Segment URIs as the canonical, human-readable 116 representation. There is an unambiguous, one-to-one correspondence 117 between an absolute LS-URI path and a Labeled Name. Relative URI 118 representations are removed during encoding, so no relative name ends 119 up in wire format. Some labels are URIs that are IRI [RFC3987] 120 compatible. 122 Labeled Names shall be used everywhere a Name is used in CCNx, such 123 as in the Name of an Interest or Content Object. They are also used 124 in Links, KeyLocators, or any other place requiring a name. When 125 encoded for the wire, a binary representation is used, depending on 126 the specific wire format codec, which is outside the scope of this 127 document. 129 This document specifies: 131 o the ccnx scheme. 133 o a canonical URI representation. 135 Formal grammars use the ABNF [RFC5234] notation. 137 TODO: We have not adopted Requirements Language yet. 139 1.1. Requirements Language 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119 [RFC2119]. 145 2. URI path segment grammar for label=value pairs 147 2.1. Labeled Segments 149 This section describes the formal grammar for Labeled Segments using 150 ABNF [RFC5234] notation. We do not impose restrictions on the length 151 of labels or values. The semantics of values are URI scheme 152 specific, here we only describe the meta-structure of Labeled 153 Segments. We begin by reviewing some definitions from [RFC3986] that 154 define an absolute path URI. 156 URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] 157 hier-part = "//" authority path-abempty 158 / path-absolute 159 / 160 path-absolute = "/" [ segment-nz *( "/" segment ) ] 161 segment = *pchar 162 segment-nz = 1*pchar 163 pchar = unreserved / pct-encoded / sub-delims / ":" / "@" 164 query = *( pchar / "/" / "?" ) 165 fragment = *( pchar / "/" / "?" ) 166 pct-encoded = "%" HEXDIG HEXDIG 167 unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" 168 reserved = gen-delims / sub-delims 169 gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@" 170 sub-delims = "!" / "$" / "&" / "'" / "(" / ")" 171 / "*" / "+" / "," / ";" / "=" 173 Labeled Segments defines a new segment type that provides unambiguous 174 representation of a segment's label and its value. We define the 175 top-level LS-URI as the same form as a URI, wherein each part 176 conforms to the Label Segment grammar, which is a subset of the URI 177 grammar. 179 LS-URI = scheme ":" ls-hier-part ["?" ls-query] 180 ["#" fragment] 181 ls-hier-part = ["//" authority] ls-path-absolute 182 ls-path-absolute = "/" [ first-segment *( "/" ls-segment ) ] 183 first-segment = ls-segment-nz 184 ls-segment = lpv-segment / v-segment 185 lpv-segment = label [":" param] "=" *s-value-nz 186 v-segment = *s-value-nz 187 ls-segment-nz = lpv-segment-nz / v-segment-nz 188 lpv-segment-nz = label [":" param] "=" s-value-nz 189 v-segment-nz = s-value-nz 190 label = alpha-t / num-t 191 param = alpha-t / num-t 192 s-value-nz = 1*(s-pchar) 194 ls-query = *1 ( lpv-component / v-component 195 *( "&" (lpv-component / v-component) ) ) 196 lpv-component = label [":" param] "=" q-value 197 v-component = q-value 198 q-value = *(q-pchar) 200 alpha-t = ALPHA *(ALPHA / DIGIT) 201 num-t = dec-t / hex-t 202 dec-t = 1*(DIGIT) 203 hex-t = "0x" 1*(HEXDIG) 204 ls-pchar = unreserved / pct-encoded / ls-sub-delims 205 s-pchar = ls-pchar / ":" / "@" / "&" 206 q-pchar = ls-pchar / ":" / "@" / "/" 207 ls-sub-delims = "!" / "$" / "'" / "(" / ")" 208 / "*" / "+" / "," / ";" 210 A Labeled Segment URI (LS-URI) contains a scheme that uses Labeled 211 Segments, an optional authority, a labeled segment absolute path (ls- 212 path-aboslute), an optional labeled segment query (ls-query), and a 213 fragment. The authority is URI scheme specific and the fragment is 214 independent of the URI scheme. 216 the ls-path-aboslute is a first-segment followed by zero or more "/" 217 ls-segment. The first-segment may be empty or a non-zero ls-segment 218 (ls-segment-nz). If it is empty, it corresponds to a 0-lenght name 219 which typically is a default route. It is distinct from a 1-segment 220 name with no value (which is not allowed). The first-segment MUST 221 either be empty (the 0-lenght name) or MUST have a value. If the 222 first-segment is an ls-segment-nz, then it will have a value. 224 An ls-segment may (lpv-segment) or may not (v-segment) have a label. 225 A particular LS-URI scheme MUST define how unlabeled segments are 226 processed, and MAY disallow them. A v-segment is an implied type. 228 Once the implied type is resolved, it functions like an lpv-segment. 230 An lpv-segment has a label, optional parameter, and optional value 231 (s-value-nz). An empty value is a 0-length name segment with a 232 defined type. This is distinct from a 0-length first-segment, which 233 has neither type nor value. 235 lpv-segment values come from the s-pchar set, which excludes the "=" 236 equal sign. This means that the only equal sign in a name segment 237 must be the delimiter between the label:param and the value. Within 238 the value, an equal sign must be percent encoded. 240 lpv-segment labels and values may be alpha-numeric identifiers or 241 numbers (decimal or hexadecimal). For example, one scheme may define 242 the labels "name", "version", and "frame". A version may be of types 243 "date" or "serial", meaning that the version is either a date or a 244 monotonic serial number. Some examples of resulting LS-URIs are: 245 "/name=parc/name=csl/version:date=20130930" or "/name=alice_smith/ 246 version:serial=299". The parameters may also indicate an instance of 247 a label, such as "/name=books/year:1=1920/year:3=1940", where there 248 are scheme or application semantics associated with "year:1" and 249 "year:3". 251 lpv-segment labels and parameters may also be numbers. For example, 252 a protocol with a binary and URI representation may not have pre- 253 defined all possible labels. In such cases, it could render unknown 254 labels as their binary value, such as "/name=marc/x2003=green". 256 The ls-query component is a non-hierarchical set of components 257 separated by "&". Each ls-query component is either a lpv-component 258 or a v-component, similar to segments. They are based on q-value, 259 which uses q-pchar that excludes "&", but includes "/". This allows 260 an LS-URI scheme to use type query parameters. 262 Labeled Segments allow for dot-segments "." and ".." in a v-segment. 263 They operate as normal. A single dot "." refers to the current 264 hierarchy level and may be elided when the URI is resolved. Double 265 dot ".." segments pop off the previous non-dot segment. An lpv- 266 segment with a value of "." or ".." is not a dot-segment. It means 267 that the value of the given label is "." or "..". For example 268 /a=parc/b=csl/.. is equivalent to "/a=parc/b=csl", but the LS-URI 269 "/a=parc/b=csl/c=.." does not contain a dot-segment. 271 2.2. URI comparison 273 An LS-URI scheme MUST specify the normalization rules to be used, 274 following the methods of Section 6 [RFC3986]. At minimum, an LS-URI 275 scheme SHOULD do the following: 277 o Normalize unrestricted percent-encodings to the unrestricted form. 279 o Normalize num-t to either dec-t or hex-t. 281 o If the scheme allows for value-only segments or query components 282 and interprets them as a default type, they should be normalized 283 to having the type specified. 285 o If the scheme allows for undefined labels and represents them, for 286 example, as num-t, then it should normalize all labels to their 287 corresponding num-t. If "name", for example, is known to be %x50 288 in a binary encoding of the URI, then all labels should be 289 compared using their numeric value. 291 3. Application to CCNx Names 293 3.1. The ccnx Scheme 295 This section describes the CCNx URI scheme "ccnx:" for Labeled Names. 296 A Labeled Name assigns a semantic type or label to each segment of 297 the hierarchical content Name. 299 Unless otherwise specified, a name segment is an arbitrary sequence 300 of octets. 302 Several name segment labels are binary unsigned integers. These are 303 always encoded as variable length sequences of 1 or more octets in 304 network byte order using the shortest representation (i.e. no leading 305 %x00). The value of "0" is encoded as the single byte of "%x00". A 306 zero-length sequence must be interpreted as "not present." 308 The CCNx Name segment types are: 310 o Name Segment: A generic name segment that includes arbitrary 311 octets. 313 o Application Type N: An application may use application-specific 314 parameters, numbered as integers, where N is from 0 to a system- 315 specific maximum, not less than 255. These are represented as 316 "App:1=value", for example. 318 It is common for an information centric networking protocol, such as 319 CCNx or NDN, to use a binary on-the-wire representation for messages. 320 Such protocols, if they use the ccnx: scheme, must have an 321 appropriate codec that unambiguously represents Labeled Content 322 Information in the chosen wire format. Relative dot-segments should 323 not occur in the wire format, they should be resolved before 324 encoding. 326 3.2. URI Representation 328 Typed Names use a standard RFC 3986 representation following the LS- 329 URI convention. A name segment consists of any "unreserved" 330 characters plus percent-encoded characters. Reserved characters must 331 be percent encoded. 333 Within an absolute path, each segment consists of an "ls-segment" 334 (c.f. LS-URI). A labeled segment is a type and a name component 335 value, with a URI representation of "type=value". The "type=" 336 portion may be omitted if it is type Name. 338 Some name types take a parameter, such as the Application types. 340 They are represented as "A:nnn=value", where the "nnn" is the 341 application type number and value is the name component. 343 A CCNx URI MUST NOT include an Authority, Query, or Fragment. It is 344 an error to include them. 346 Dot-segments (relative name components) are resolved when the URI is 347 converted to a Typed Name. The "." dot-segment is removed. The ".." 348 dot-segment is removed along with the previous non-dot-segment. 350 +-------------------+-------------+---------------------------------+ 351 | Type | Display | Name | 352 +-------------------+-------------+---------------------------------+ 353 | 'Name' | Hexadecimal | Name Segment | 354 | | | | 355 | 'IPID' | Hexadecimal | Interest Payload Identifier | 356 | | | segment | 357 | | | | 358 | 'App:0' - | Hexadecimal | Application Component | 359 | 'App:255' | | | 360 +-------------------+-------------+---------------------------------+ 362 Table 1: The CCNx URI Scheme Types 364 3.2.1. Examples 366 A name / is 367 ccnx:/ and is a 0-length name. 369 A name /Name= is 370 ccnx:/Name= and is a 1-segment name of 0-length. 372 A name /foo/bar. 373 ccnx:/Name=foo/Name=bar 374 ccnx:/foo/Name=bar 375 ccnx:/foo/bar 377 A name /foo/bar with key %xA0. 378 ccnx:/Name=foo/Name=bar/App:1=0xA0 380 A name /foo/bar with version %xA0 and App:2 value 0x09. 381 ccnx:/foo/bar/Version=0xA0/App:2=0x09 383 A name /foo/.., where the ".." is a literal name component, 384 not a relative dot-segment. 385 ccnx:/foo/Name=.. 387 A name /foo/bar with application type 0 "hello" 388 and application type 1 "world". 389 ccnx:/Name=foo/Name=bar/App:0=hello/App:1=world 391 3.3. ccnx: URI comparison 393 While most comparisons are done using a wire format representation of 394 a ccnx: URI, some applications may compare the CCNx URI using their 395 URI representation. This section defines the rules for comparing 396 ccnx: URIs using the methods of Section 6 [RFC3986] 398 Comparing typed name URIs must be done with: 400 o Syntax-based normalization 402 o Case normalization: normalize the representation of percent 403 encodings. ccnx: does not use the host portion of the URI, and 404 should be ignored if present. 406 o Percent encoding normalization: Percent encodings of unreserved 407 characters must be converted to the unreserved character. 409 o Path segment normalization: dot-segments must be resolved first. 411 o Scheme-based normalization: The authority should be removed and 412 the path represented as an absolute path. 414 o Protocol-based normalization: Should not be done. A trailing 415 slash indicates a zero-length terminal name component and 416 signifies a different name. 418 o typed-name-segment normalization: All segments should be presented 419 with their type, do not elide the "N=" for Name components. 421 o Binary unsigned integer normalization: remove any leading %x00 422 from numbers, leaving only the terminal %x00 for "0". 424 o type parameters: they must have their percent encodings 425 normalized. If they are integers, such as for the 'A' type, they 426 must not have leading zeros. 428 4. IRI Considerations 430 International Resource Identifiers extend the unreserved character 431 set to include characters above U+07F and encode them using percent 432 encoding. This extension is compatible with the ccnx: schema. It 433 applies only to the "value" portion of an ls-segment. 435 The canonical name is determined by the URI representation of the 436 IRI, after applying the rules of Section 3.1 of [RFC3987] and 437 resolving dot-segments. The canonical name thus includes the URI 438 representation of language markers, including the bidirectional 439 components. 441 The value of a UTF-8 Name segment should be interpreted using IRI 442 rules, including bidirectional markers. They may be displayed using 443 localized formats. 445 Binary unsigned integer types are not interpreted under IRI rules, 446 they are specifically percent encoded numbers. They may be displayed 447 using a localized format. 449 5. Acknowledgements 450 6. IANA Considerations 452 This memo includes no request to IANA. 454 All drafts are required to have an IANA considerations section (see 455 Guidelines for Writing an IANA Considerations Section in RFCs 456 [RFC5226] for a guide). If the draft does not require IANA to do 457 anything, the section contains an explicit statement that this is the 458 case (as above). If there are no requirements for IANA, the section 459 will be removed during conversion into an RFC by the RFC Editor. 461 7. Security Considerations 463 All drafts are required to have a security considerations section. 464 See RFC 3552 [RFC3552] for a guide. 466 8. References 468 8.1. Normative References 470 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 471 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 472 RFC2119, March 1997, 473 . 475 8.2. Informative References 477 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 478 Text on Security Considerations", BCP 72, RFC 3552, 479 DOI 10.17487/RFC3552, July 2003, 480 . 482 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 483 Resource Identifier (URI): Generic Syntax", STD 66, 484 RFC 3986, DOI 10.17487/RFC3986, January 2005, 485 . 487 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 488 Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, 489 January 2005, . 491 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 492 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 493 DOI 10.17487/RFC5226, May 2008, 494 . 496 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 497 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 498 RFC5234, January 2008, 499 . 501 Authors' Addresses 503 Marc Mosko 504 PARC, Inc. 505 Palo Alto, California 94304 506 USA 508 Phone: +01 650-812-4405 509 Email: marc.mosko@parc.com 511 Christopher A. Wood 512 PARC, Inc. 513 Palo Alto, California 94304 514 USA 516 Phone: +01 650-812-4421 517 Email: christopher.wood@parc.com