### ----------------------------------------------------
### -- URI::Template
### -- Licenses: Artistic-2.0
### -- Authors: Jonathan Stowe <jns+git@gellyfish.co.uk>
### -- File: doc/rfc6570.txt
### ----------------------------------------------------
### -- Chunk 2 of 3
   processor, and the literal string to use for the name in name=value
   expansions (aside from when exploding an associative array).
   Variable names are case-sensitive because the name might be expanded
   within a case-sensitive URI component.

     variable-list =  varspec *( "," varspec )
     varspec       =  varname [ modifier-level4 ]
     varname       =  varchar *( ["."] varchar )
     varchar       =  ALPHA / DIGIT / "_" / pct-encoded






Gregorio, et al.             Standards Track                   [Page 14]

RFC 6570                      URI Template                    March 2012


   A varname MAY contain one or more pct-encoded triplets.  These
   triplets are considered an essential part of the variable name and
   are not decoded during processing.  A varname containing pct-encoded
   characters is not the same variable as a varname with those same
   characters decoded.  Applications that provide URI Templates are
   expected to be consistent in their use of pct-encoding within
   variable names.

   An expression MAY reference variables that are unknown to the
   template processor or whose value is set to a special "undefined"
   value, such as undef or null.  Such undefined variables are given
   special treatment by the expansion process (Section 3.2.1).

   A variable value that is a string of length zero is not considered
   undefined; it has the defined value of an empty string.

   In Level 4 templates, a variable may have a composite value in the
   form of a list of values or an associative array of (name, value)
   pairs.  Such value types are not directly indicated by the template
   syntax, but they do have an impact on the expansion process
   (Section 3.2.1).

   A variable defined as a list value is considered undefined if the
   list contains zero members.  A variable defined as an associative
   array of (name, value) pairs is considered undefined if the array
   contains zero members or if all member names in the array are
   associated with undefined values.

2.4.  Value Modifiers

   Each of the variables in a Level 4 template expression can have a
   modifier indicating either that its expansion is limited to a prefix
   of the variable's value string or that its expansion is exploded as a
   composite value in the form of a value list or an associative array
   of (name, value) pairs.

     modifier-level4 =  prefix / explode

2.4.1.  Prefix Values

   A prefix modifier indicates that the variable expansion is limited to
   a prefix of the variable's value string.  Prefix modifiers are often
   used to partition an identifier space hierarchically, as is common in
   reference indices and hash-based storage.  It also serves to limit
   the expanded value to a maximum number of characters.  Prefix
   modifiers are not applicable to variables that have composite values.





Gregorio, et al.             Standards Track                   [Page 15]

RFC 6570                      URI Template                    March 2012


     prefix        =  ":" max-length
     max-length    =  %x31-39 0*3DIGIT   ; positive integer < 10000

   The max-length is a positive integer that refers to a maximum number
   of characters from the beginning of the variable's value as a Unicode
   string.  Note that this numbering is in characters, not octets, in
   order to avoid splitting between the octets of a multi-octet-encoded
   character or within a pct-encoded triplet.  If the max-length is
   greater than the length of the variable's value, then the entire
   value string is used.

   For example,

     Given the variable assignments

       var   := "value"
       semi  := ";"

     Example Template     Expansion

       {var}              value
       {var:20}           value
       {var:3}            val
       {semi}             %3B
       {semi:2}           %3B

2.4.2.  Composite Values

   An explode ("*") modifier indicates that the variable is to be
   treated as a composite value consisting of either a list of values or
   an associative array of (name, value) pairs.  Hence, the expansion
   process is applied to each member of the composite as if it were
   listed as a separate variable.  This kind of variable specification
   is significantly less self-documenting than non-exploded variables,
   since there is less correspondence between the variable name and how
   the URI reference appears after expansion.

     explode       =  "*"

   Since URI Templates do not contain an indication of type or schema,
   the type for an exploded variable is assumed to be determined by
   context.  For example, the processor might be supplied values in a
   form that differentiates values as strings, lists, or associative
   arrays.  Likewise, the context in which the template is used (script,
   mark-up language, Interface Definition Language, etc.) might define
   rules for associating variable names with types, structures, or
   schema.




Gregorio, et al.             Standards Track                   [Page 16]

RFC 6570                      URI Template                    March 2012


   Explode modifiers improve brevity in the URI Template syntax.  For
   example, a resource that provides a geographic map for a given street
   address might accept a hundred permutations on fields for address
   input, including partial addresses (e.g., just the city or postal
   code).  Such a resource could be described as a template with each
   and every address component listed in order, or with a far more
   simple template that makes use of an explode modifier, as in

      /mapper{?address*}

   along with some context that defines what the variable named
   "address" can include, such as by reference to some other standard
   for addressing (e.g., [UPU-S42]).  A recipient aware of the schema
   can then provide appropriate expansions, such as:

      /mapper?city=Newport%20Beach&state=CA

   The expansion process for exploded variables is dependent on both the
   operator being used and whether the composite value is to be treated
   as a list of values or as an associative array of (name, value)
   pairs.  Structures are processed as if they are an associative array
   with names corresponding to the fields in the structure definition
   and "." separators used to indicate name hierarchy in substructures.

   If a variable has a composite structure and only some of the fields
   in that structure have defined values, then only the defined pairs
   are present in the expansion.  This can be useful for templates that
   consist of a large number of potential query terms.

   An explode modifier applied to a list variable causes the expansion
   to iterate over the list's member values.  For path and query
   parameter expansions, each member value is paired with the variable's
   name as a (varname, value) pair.  This allows path and query
   parameters to be repeated for multiple values, as in

     Given the variable assignments

       year  := ("1965", "2000", "2012")
       dom   := ("example", "com")

     Example Template     Expansion

       find{?year*}       find?year=1965&year=2000&year=2012
       www{.dom*}         www.example.com







Gregorio, et al.             Standards Track                   [Page 17]

RFC 6570                      URI Template                    March 2012


3.  Expansion

   The process of URI Template expansion is to scan the template string
   from beginning to end, copying literal characters and replacing each
   expression with the result of applying the expression's operator to
   the value of each variable named in the expression.  Each variable's
   value MUST be formed prior to template expansion.

   The requirements on expansion for each aspect of the URI Template
   grammar are defined in this section.  A non-normative algorithm for
   the expansion process as a whole is provided in Appendix A.

   If a template processor encounters a character sequence outside an
   expression that does not match the <URI-Template> grammar, then
   processing of the template SHOULD cease, the URI reference result
   SHOULD contain the expanded part of the template followed by the
   remainder unexpanded, and the location and type of error SHOULD be
   indicated to the invoking application.

   If an error is encountered in an expression, such as an operator or
   value modifier that the template processor does not recognize or does
   not yet support, or a character is found that is not allowed by the
   <expression> grammar, then the unprocessed parts of the expression
   SHOULD be copied to the result unexpanded, processing of the
   remainder of the template SHOULD continue, and the location and type
   of error SHOULD be indicated to the invoking application.

   If an error occurs, the result returned might not be a valid URI
   reference; it will be an incompletely expanded template string that
   is only intended for diagnostic use.

3.1.  Literal Expansion

   If the literal character is allowed anywhere in the URI syntax
   (unreserved / reserved / pct-encoded ), then it is copied directly to
   the result string.  Otherwise, the pct-encoded equivalent of the
   literal character is copied to the result string by first encoding
   the character as its sequence of octets in UTF-8 and then encoding
   each such octet as a pct-encoded triplet.

3.2.  Expression Expansion

   Each expression is indicated by an opening brace ("{") character and
   continues until the next closing brace ("}").  Expressions cannot be
   nested.






Gregorio, et al.             Standards Track                   [Page 18]

RFC 6570                      URI Template                    March 2012


   An expression is expanded by determining its expression type and then
   following that type's expansion process for each comma-separated
   varspec in the expression.  Level 1 templates are limited to the
   default operator (simple string value expansion) and a single
   variable per expression.  Level 2 templates are limited to a single
   varspec per expression.

   The expression type is determined by looking at the first character
   after the opening brace.  If the character is an operator, then
   remember the expression type associated with that operator for later
   expansion decisions and skip to the next character for the variable-
   list.  If the first character is not an operator, then the expression
   type is simple string expansion and the first character is the
   beginning of the variable-list.

   The examples in the subsections below use the following definitions
   for variable values:

         count := ("one", "two", "three")
         dom   := ("example", "com")
         dub   := "me/too"
         hello := "Hello World!"
         half  := "50%"
         var   := "value"
         who   := "fred"
         base  := "http://example.com/home/"
         path  := "/foo/bar"
         list  := ("red", "green", "blue")
         keys  := [("semi",";"),("dot","."),("comma",",")]
         v     := "6"
         x     := "1024"
         y     := "768"
         empty := ""
         empty_keys  := []
         undef := null

3.2.1.  Variable Expansion

   A variable that is undefined (Section 2.3) has no value and is
   ignored by the expansion process.  If all of the variables in an
   expression are undefined, then the expression's expansion is the
   empty string.

   Variable expansion of a defined, non-empty value results in a
   substring of allowed URI characters.  As described in Section 1.6,
   the expansion process is defined in terms of Unicode code points in
   order to ensure that non-ASCII characters are consistently pct-
   encoded in the resulting URI reference.  One way for a template



Gregorio, et al.             Standards Track                   [Page 19]

RFC 6570                      URI Template                    March 2012


   processor to obtain a consistent expansion is to transcode the value
   string to UTF-8 (if it is not already in UTF-8) and then transform
   each octet that is not in the allowed set into the corresponding pct-
   encoded triplet.  Another is to map directly from the value's native
   character encoding to the set of allowed URI characters, with any
   remaining disallowed characters mapping to the sequence of pct-
   encoded triplets that correspond to the octet(s) of that character
   when encoded as UTF-8 [RFC3629].

   The allowed set for a given expansion depends on the expression type:
   reserved ("+") and fragment ("#") expansions allow the set of
   characters in the union of ( unreserved / reserved / pct-encoded ) to
   be passed through without pct-encoding, whereas all other expression
   types allow only unreserved characters to be passed through without
   pct-encoding.  Note that the percent character ("%") is only allowed
   as part of a pct-encoded triplet and only for reserved/fragment
   expansion: in all other cases, a value character of "%" MUST be pct-
   encoded as "%25" by variable expansion.

   If a variable appears more than once in an expression or within
   multiple expressions of a URI Template, the value of that variable
   MUST remain static throughout the expansion process (i.e., the
   variable must have the same value for the purpose of calculating each
   expansion).  However, if reserved characters or pct-encoded triplets
   occur in the value, they will be pct-encoded by some expression types
   and not by others.

   For a variable that is a simple string value, expansion consists of
   appending the encoded value to the result string.  An explode
   modifier has no effect.  A prefix modifier limits the expansion to
   the first max-length characters of the decoded value.  If the value
   contains multi-octet or pct-encoded characters, care must be taken to
   avoid splitting the value in mid-character: count each Unicode code
   point as one character.

   For a variable that is an associative array, expansion depends on
   both the expression type and the presence of an explode modifier.  If
   there is no explode modifier, expansion consists of appending a
   comma-separated concatenation of each (name, value) pair that has a
   defined value.  If there is an explode modifier, expansion consists
   of appending each pair that has a defined value as either
   "name=value" or, if the value is the empty string and the expression
   type does not indicate form-style parameters (i.e., not a "?" or "&"
   type), simply "name".  Both name and value strings are encoded in the
   same way as simple string values.  A separator string is appended
   between defined pairs according to the expression type, as defined by
   the following table:




Gregorio, et al.             Standards Track                   [Page 20]

RFC 6570                      URI Template                    March 2012


      Type    Separator
                 ","     (default)
        +        ","
        #        ","
        .        "."
        /        "/"
        ;        ";"
        ?        "&"
        &        "&"

   For a variable that is a list of values, expansion depends on both
   the expression type and the presence of an explode modifier.  If
   there is no explode modifier, the expansion consists of a comma-
   separated concatenation of the defined member string values.  If
   there is an explode modifier and the expression type expands named
   parameters (";", "?", or "&"), then the list is expanded as if it
   were an associative array in which each member value is paired with
   the list's varname.  Otherwise, the value will be expanded as if it
   were a list of separate variable values, each value separated by the
   expression type's associated separator as defined by the table above.

     Example Template     Expansion

       {count}            one,two,three
       {count*}           one,two,three
       {/count}           /one,two,three
       {/count*}          /one/two/three
       {;count}           ;count=one,two,three
       {;count*}          ;count=one;count=two;count=three
       {?count}           ?count=one,two,three
       {?count*}          ?count=one&count=two&count=three
       {&count*}          &count=one&count=two&count=three

3.2.2.  Simple String Expansion: {var}

   Simple string expansion is the default expression type when no
   operator is given.

   For each defined variable in the variable-list, perform variable
   expansion, as defined in Section 3.2.1, with the allowed characters
   being those in the unreserved set.  If more than one variable has a
   defined value, append a comma (",") to the result string as a
   separator between variable expansions.








Gregorio, et al.             Standards Track                   [Page 21]

RFC 6570                      URI Template                    March 2012


     Example Template     Expansion

       {var}              value
       {hello}            Hello%20World%21
       {half}             50%25
       O{empty}X          OX
       O{undef}X          OX
       {x,y}              1024,768
       {x,hello,y}        1024,Hello%20World%21,768
       ?{x,empty}         ?1024,
       ?{x,undef}         ?1024
       ?{undef,y}         ?768
       {var:3}            val
       {var:30}           value
       {list}             red,green,blue
       {list*}            red,green,blue
       {keys}             semi,%3B,dot,.,comma,%2C
       {keys*}            semi=%3B,dot=.,comma=%2C

3.2.3.  Reserved Expansion: {+var}

   Reserved expansion, as indicated by the plus ("+") operator for Level
   2 and above templates, is identical to simple string expansion except
   that the substituted values may also contain pct-encoded triplets and
   characters in the reserved set.

   For each defined variable in the variable-list, perform variable
   expansion, as defined in Section 3.2.1, with the allowed characters
   being those in the set (unreserved / reserved / pct-encoded).  If
   more than one variable has a defined value, append a comma (",") to
   the result string as a separator between variable expansions.




















Gregorio, et al.             Standards Track                   [Page 22]

RFC 6570                      URI Template                    March 2012


     Example Template        Expansion

       {+var}                value
       {+hello}              Hello%20World!
       {+half}               50%25

       {base}index           http%3A%2F%2Fexample.com%2Fhome%2Findex
       {+base}index          http://example.com/home/index
       O{+empty}X            OX
       O{+undef}X            OX

       {+path}/here          /foo/bar/here
       here?ref={+path}      here?ref=/foo/bar
       up{+path}{var}/here   up/foo/barvalue/here
       {+x,hello,y}          1024,Hello%20World!,768
       {+path,x}/here        /foo/bar,1024/here

       {+path:6}/here        /foo/b/here
       {+list}               red,green,blue
       {+list*}              red,green,blue
       {+keys}               semi,;,dot,.,comma,,
       {+keys*}              semi=;,dot=.,comma=,

3.2.4.  Fragment Expansion: {#var}

   Fragment expansion, as indicated by the crosshatch ("#") operator for
   Level 2 and above templates, is identical to reserved expansion
   except that a crosshatch character (fragment delimiter) is appended
   first to the result string if any of the variables are defined.

     Example Template     Expansion

       {#var}             #value
       {#hello}           #Hello%20World!
       {#half}            #50%25
       foo{#empty}        foo#
       foo{#undef}        foo
       {#x,hello,y}       #1024,Hello%20World!,768
       {#path,x}/here     #/foo/bar,1024/here
       {#path:6}/here     #/foo/b/here
       {#list}            #red,green,blue
       {#list*}           #red,green,blue
       {#keys}            #semi,;,dot,.,comma,,
       {#keys*}           #semi=;,dot=.,comma=,







Gregorio, et al.             Standards Track                   [Page 23]

RFC 6570                      URI Template                    March 2012


3.2.5.  Label Expansion with Dot-Prefix: {.var}

   Label expansion, as indicated by the dot (".") operator for Level 3
   and above templates, is useful for describing URI spaces with varying
   domain names or path selectors (e.g., filename extensions).

   For each defined variable in the variable-list, append "." to the
   result string and then perform variable expansion, as defined in
   Section 3.2.1, with the allowed characters being those in the
   unreserved set.

   Since "." is in the unreserved set, a value that contains a "." has
   the effect of adding multiple labels.

     Example Template     Expansion

       {.who}             .fred
       {.who,who}         .fred.fred
       {.half,who}        .50%25.fred
       www{.dom*}         www.example.com
       X{.var}            X.value
       X{.empty}          X.
       X{.undef}          X
       X{.var:3}          X.val
       X{.list}           X.red,green,blue
       X{.list*}          X.red.green.blue
       X{.keys}           X.semi,%3B,dot,.,comma,%2C
       X{.keys*}          X.semi=%3B.dot=..comma=%2C
       X{.empty_keys}     X
       X{.empty_keys*}    X

3.2.6.  Path Segment Expansion: {/var}

   Path segment expansion, as indicated by the slash ("/") operator in
   Level 3 and above templates, is useful for describing URI path
   hierarchies.

   For each defined variable in the variable-list, append "/" to the
   result string and then perform variable expansion, as defined in
   Section 3.2.1, with the allowed characters being those in the
   unreserved set.

   Note that the expansion process for path segment expansion is
   identical to that of label expansion aside from the substitution of
   "/" instead of ".".  However, unlike ".", a "/" is a reserved
   character and will be pct-encoded if found in a value.





Gregorio, et al.             Standards Track                   [Page 24]

RFC 6570                      URI Template                    March 2012


     Example Template     Expansion

       {/who}             /fred
       {/who,who}         /fred/fred
       {/half,who}        /50%25/fred
       {/who,dub}         /fred/me%2Ftoo
       {/var}             /value
       {/var,empty}       /value/
       {/var,undef}       /value
       {/var,x}/here      /value/1024/here
       {/var:1,var}       /v/value
       {/list}            /red,green,blue
       {/list*}           /red/green/blue
       {/list*,path:4}    /red/green/blue/%2Ffoo
       {/keys}            /semi,%3B,dot,.,comma,%2C
       {/keys*}           /semi=%3B/dot=./comma=%2C

3.2.7.  Path-Style Parameter Expansion: {;var}

   Path-style parameter expansion, as indicated by the semicolon (";")
   operator in Level 3 and above templates, is useful for describing URI
   path parameters, such as "path;property" or "path;name=value".

   For each defined variable in the variable-list:

   o  append ";" to the result string;

   o  if the variable has a simple string value or no explode modifier
      is given, then:

      *  append the variable name (encoded as if it were a literal
         string) to the result string;

      *  if the variable's value is not empty, append "=" to the result
         string;

   o  perform variable expansion, as defined in Section 3.2.1, with the
      allowed characters being those in the unreserved set.













Gregorio, et al.             Standards Track                   [Page 25]

RFC 6570                      URI Template                    March 2012


     Example Template     Expansion

       {;who}             ;who=fred
       {;half}            ;half=50%25
       {;empty}           ;empty
       {;v,empty,who}     ;v=6;empty;who=fred
       {;v,bar,who}       ;v=6;who=fred
       {;x,y}             ;x=1024;y=768
       {;x,y,empty}       ;x=1024;y=768;empty
       {;x,y,undef}       ;x=1024;y=768
       {;hello:5}         ;hello=Hello
       {;list}            ;list=red,green,blue
       {;list*}           ;list=red;list=green;list=blue
       {;keys}            ;keys=semi,%3B,dot,.,comma,%2C
       {;keys*}           ;semi=%3B;dot=.;comma=%2C

3.2.8.  Form-Style Query Expansion: {?var}

   Form-style query expansion, as indicated by the question-mark ("?")
   operator in Level 3 and above templates, is useful for describing an
   entire optional query component.

   For each defined variable in the variable-list:

   o  append "?" to the result string if this is the first defined value
      or append "&" thereafter;

   o  if the variable has a simple string value or no explode modifier
      is given, append the variable name (encoded as if it were a
      literal string) and an equals character ("=") to the result
      string; and,

   o  perform variable expansion, as defined in Section 3.2.1, with the
      allowed characters being those in the unreserved set.


     Example Template     Expansion

       {?who}             ?who=fred
       {?half}            ?half=50%25
       {?x,y}             ?x=1024&y=768
       {?x,y,empty}       ?x=1024&y=768&empty=
       {?x,y,undef}       ?x=1024&y=768
       {?var:3}           ?var=val
       {?list}            ?list=red,green,blue
       {?list*}           ?list=red&list=green&list=blue
       {?keys}            ?keys=semi,%3B,dot,.,comma,%2C
       {?keys*}           ?semi=%3B&dot=.&comma=%2C



Gregorio, et al.             Standards Track                   [Page 26]

RFC 6570                      URI Template                    March 2012


3.2.9.  Form-Style Query Continuation: {&var}

   Form-style query continuation, as indicated by the ampersand ("&")
   operator in Level 3 and above templates, is useful for describing
   optional &name=value pairs in a template that already contains a
   literal query component with fixed parameters.

   For each defined variable in the variable-list:

   o  append "&" to the result string;

   o  if the variable has a simple string value or no explode modifier
      is given, append the variable name (encoded as if it were a
      literal string) and an equals character ("=") to the result
      string; and,

   o  perform variable expansion, as defined in Section 3.2.1, with the
      allowed characters being those in the unreserved set.


     Example Template     Expansion

       {&who}             &who=fred
       {&half}            &half=50%25
       ?fixed=yes{&x}     ?fixed=yes&x=1024
       {&x,y,empty}       &x=1024&y=768&empty=
       {&x,y,undef}       &x=1024&y=768

       {&var:3}           &var=val
       {&list}            &list=red,green,blue
       {&list*}           &list=red&list=green&list=blue
       {&keys}            &keys=semi,%3B,dot,.,comma,%2C
       {&keys*}           &semi=%3B&dot=.&comma=%2C

4.  Security Considerations

   A URI Template does not contain active or executable content.
   However, it might be possible to craft unanticipated URIs if an
   attacker is given control over the template or over the variable
   values within an expression that allows reserved characters in the
   expansion.  In either case, the security considerations are largely
   determined by who provides the template, who provides the values to
   use for variables within the template, in what execution context the
   expansion occurs (client or server), and where the resulting URIs are
   used.






Gregorio, et al.             Standards Track                   [Page 27]

RFC 6570                      URI Template                    March 2012


   This specification does not limit where URI Templates might be used.
   Current implementations exist within server-side development
   frameworks and within client-side javascript for computed links or
   forms.

   Within frameworks, templates usually act as guides for where data
   might occur within later (request-time) URIs in client requests.
   Hence, the security concerns are not in the templates themselves, but
   rather in how the server extracts and processes the user-provided
   data within a normal Web request.

   Within client-side implementations, a URI Template has many of the
   same properties as HTML forms, except limited to URI characters and
   possibly included in HTTP header field values instead of just message
   body content.  Care ought to be taken to ensure that potentially
   dangerous URI reference strings, such as those beginning with
   "javascript:", do not appear in the expansion unless both the
   template and the values are provided by a trusted source.

   Other security considerations are the same as those for URIs, as
   described in Section 7 of [RFC3986].

5.  Acknowledgments

   The following people made contributions to this specification: Mike
   Burrows, Michaeljohn Clement, DeWitt Clinton, John Cowan, Stephen
   Farrell, Robbie Gates, Vijay K. Gurbani, Peter Johanson, Murray S.
   Kucherawy, James H. Manger, Tom Petch, Marc Portier, Pete Resnick,
   James Snell, and Jiankang Yao.

6.  References

6.1.  Normative References

   [ASCII]       American National Standards Institute, "Coded Character
                 Set - 7-bit American Standard Code for Information
                 Interchange", ANSI X3.4, 1986.

   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3629]     Yergeau, F., "UTF-8, a transformation format of ISO
                 10646", STD 63, RFC 3629, November 2003.

   [RFC3986]     Berners-Lee, T., Fielding, R., and L. Masinter,
                 "Uniform Resource Identifier (URI): Generic Syntax",
                 STD 66, RFC 3986, January 2005.




Gregorio, et al.             Standards Track                   [Page 28]

RFC 6570                      URI Template                    March 2012


   [RFC3987]     Duerst, M. and M. Suignard, "Internationalized Resource
                 Identifiers (IRIs)", RFC 3987, January 2005.

   [RFC5234]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
                 Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC6365]     Hoffman, P. and J. Klensin, "Terminology Used in
                 Internationalization in the IETF", BCP 166, RFC 6365,
                 September 2011.

   [UNIV6]       The Unicode Consortium, "The Unicode Standard, Version
                 6.0.0", (Mountain View, CA: The Unicode Consortium,
                 2011.  ISBN 978-1-936213-01-6),
                 <http://www.unicode.org/versions/Unicode6.0.0/>.

   [UTR15]       Davis, M. and M. Duerst, "Unicode Normalization Forms",
                 Unicode Standard Annex # 15, April 2003,
                 <http://www.unicode.org/unicode/reports/tr15/
                 tr15-23.html>.

6.2.  Informative References

   [OpenSearch]  Clinton, D., "OpenSearch 1.1", Draft 5, December 2011,
                 <http://www.opensearch.org/Specifications/OpenSearch>.

   [UPU-S42]     Universal Postal Union, "International Postal Address
                 Components and Templates", UPU S42-1, November 2002,
                 <http://www.upu.int/en/activities/addressing/
                 standards.html>.

   [WADL]        Hadley, M., "Web Application Description Language",
                 World Wide Web Consortium Member Submission
                 SUBM-wadl-20090831, August 2009,
                 <http://www.w3.org/Submission/2009/
                 SUBM-wadl-20090831/>.

   [WSDL]        Weerawarana, S., Moreau, J., Ryman, A., and R.
                 Chinnici, "Web Services Description Language (WSDL)
                 Version 2.0 Part 1: Core Language", World Wide Web
                 Consortium Recommendation REC-wsdl20-20070626,
                 June 2007, <http://www.w3.org/TR/2007/
                 REC-wsdl20-20070626>.









Gregorio, et al.             Standards Track                   [Page 29]

RFC 6570                      URI Template                    March 2012


Appendix A.  Implementation Hints

   The normative sections on expansion describe each operator with a
   separate expansion process for the sake of descriptive clarity.  In
   actual implementations, we expect the expressions to be processed
   left-to-right using a common