[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                           E. Wilde
Internet-Draft                                                  C. Davis
Intended status: Standards Track                         EMC Corporation
Expires: June 10, 2013                                            Y. Liu
                                                             UC Berkeley
                                                        December 7, 2012


                       URI Template Descriptions
                      draft-wilde-template-desc-00

Abstract

   Interactions with many resources on the Web are driven by and/or can
   be described by URI Templates.  RFC 6570 says that "a URI Template is
   a compact sequence of characters for describing a range of Uniform
   Resource Identifiers through variable expansion."  This specification
   defines Template Descriptions, a schema and a media type that can be
   used to document and describe a URI Template by supporting
   descriptive markup that allows variables to be associated with
   documentation (human-oriented) and/or descriptions (machine-
   oriented).  Template Descriptions can be used by media types (by
   inclusion or by reference) that seek to make URI Templates self-
   describing, without having to create their own representation.

Note to Readers

   Please discuss this draft on the rest-discuss mailing list [9].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 10, 2013.

Copyright Notice




Wilde, et al.             Expires June 10, 2013                 [Page 1]

Internet-Draft          URI Template Descriptions          December 2012


   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  URI Template  . . . . . . . . . . . . . . . . . . . . . . . 3
     1.2.  Describing Variables  . . . . . . . . . . . . . . . . . . . 4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  Template Descriptions . . . . . . . . . . . . . . . . . . . . . 5
     3.1.  General Concepts  . . . . . . . . . . . . . . . . . . . . . 5
     3.2.  Template Description Structure  . . . . . . . . . . . . . . 5
     3.3.  Variable Description Structure  . . . . . . . . . . . . . . 5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
     4.1.  Media Type  . . . . . . . . . . . . . . . . . . . . . . . . 5
     4.2.  Link Relation . . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   6.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     6.1.  OpenSearch  . . . . . . . . . . . . . . . . . . . . . . . . 7
     6.2.  Atom Feeds  . . . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8















Wilde, et al.             Expires June 10, 2013                 [Page 2]

Internet-Draft          URI Template Descriptions          December 2012


1.  Introduction

   Simple interactions with resources on the Web often are driven by
   simply following links, but in many other cases, interactions with
   resources require clients to provide information in addition to just
   using a fixed URI in a request.  In these cases, information can
   provided in any way supported by the interaction protocol, and in
   case of HTTP, this often means that information is either embedded in
   the URI, and/or in the body of the request.  For the first case, the
   "URI Template" standard Section 1.1 provides a standard that allows
   servers and clients to exchange information about the URIs that a
   service accepts.

1.1.  URI Template

   The "URI Template" standard RFC 6570 [1] specifies "a compact
   sequence of characters for describing a range of Uniform Resource
   Identifiers through variable expansion."  It allows servers to
   publish their expectation how a URI should be created by substituting
   variables with values.  Consider the following URI Template:
   http://www.example.com/feed{?pagesize,page}

   This URI Template allows clients to expand two variables to end up
   with a concrete URI such as the following:
   http://www.example.com/feed?pagesize=10&page=42

   URI Templates cover the aspect of starting with a template with
   variables in it, assigning values to these variables, and then
   expanding the template into a URI that can be used for sending a
   request.  URI Templates make no assumptions or statements about the
   value range of the variables, except for those aspects which are
   required to cover the process of expanding the template.  In
   particular, for the example given above, there is no indication that
   the values are supposed to be positive integers (the simple data
   type), nor is there any indication that the service may apply certain
   limits such as a maximum page size (which may change depending on
   which paged resource is being accessed).  As a side note, even if
   this information was known, URI template expansion could still result
   in URIs that would not yield successful requests, such as when asking
   for a page that is beyond the number of pages that a feed has (in a
   given page size).

   The goal of Templates Descriptions as defined here is to allow
   servers to expose a description resource that provides support both
   at development time (when a developer looks at a media type that uses
   URI Templates) and at runtime (when a client wants to use a URI
   template as part of its application flow).




Wilde, et al.             Expires June 10, 2013                 [Page 3]

Internet-Draft          URI Template Descriptions          December 2012


1.2.  Describing Variables

   Variables can be described in a variety of ways when using Template
   Descriptions.  For each variable in the URI Template, it is possible
   to use the following description methods:

      Domain Concept: It is possible to associate a variable with a
      domain concept, so that media types and applications can make an
      association between the concepts they are defining/exposing, and
      where they are represented in URI Tenplates.  Concepts can be
      referred to by URI, or by using a QName [2].

      Datatype: Variables can be described in terms of using certain
      datatypes, and the datatype vocabulary is that of XML Schema Part
      2 [3], plus all of the applicable facets of those datatypes.  This
      allows Template Descriptions to constrain the set of allowed
      values.

      Documentation: Documentation constructs can be associated with
      variables, which allows Template Descriptions to attach human-
      readable information to individual variables.  The documentation
      constructs use the documentation design of XML Schema Part 1 [4].

      Application Information: Application information constructs can be
      associated with variables, which allows Template Descriptions to
      attach machine-readable information to individual variables.  The
      application information constructs use the application information
      design of XML Schema Part 1 [4].

   For the purpose of this specification, the term "description" should
   be interpreted loosely.  Some aspects of descriptions can be formal,
   such as the datatypes of variables.  Thus, such a description can be
   used to drive general-purpose logic that knows nothing but this
   specification.  However, for most other description aspects (domain
   concepts, documentation, and application information), this
   specification does not prescribe a description framework; it simply
   provides a structure how to deliver these descriptions.


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 [5].







Wilde, et al.             Expires June 10, 2013                 [Page 4]

Internet-Draft          URI Template Descriptions          December 2012


3.  Template Descriptions

   Template Descriptions are based on a URI Template, and add
   descriptive elements that allow publishers of URI Templates to
   describe the URI Template as a whole, and to add individual
   descriptions of all variables in the template.

3.1.  General Concepts

   As mentioned in Section 1.1, most of the descriptions in this spec to
   not prescribe a specific description framework.  While variables
   (Section 3.3) can be described with a built-in vocabulary of
   datatypes, most other descriptions are either for human consumption,
   or do rely on some external description framework.  To attach these
   descriptions to both the template as a whole, and individual
   variables, this specification reuses the "appinfo" and
   "documentation" elements from XML Schema Part 1 [4].  These elements
   carry a "source" attribute which is used (quoting from [4]) "to
   supplement the local information."

3.2.  Template Description Structure

   A template is described by including the URI Template itself, and
   optionally adding documentation and/or appinfo elements to add human-
   or machine-readable descriptions.

3.3.  Variable Description Structure

   A variable is described by specifying the variable name.  Variables
   can refer to a "concept" associated with a variable, which can by
   identified by URI, or by a QName (at most one of these SHALL be
   present).  This specification makes no provision how such a concept
   is defined or described, but it allows consumers of a Template
   Description to match their understanding of certain concepts to those
   identifiers, which then establishes a binding between the concept,
   and the variable it has been bound to.

   Variable descriptions can optionally add documentation and/or appinfo
   elements to add human- or machine-readable descriptions.


4.  IANA Considerations

4.1.  Media Type

   The Internet media type for a Template Description document is
   application/td+xml.




Wilde, et al.             Expires June 10, 2013                 [Page 5]

Internet-Draft          URI Template Descriptions          December 2012


      Type name: application

      Subtype name: td+xml

      Required parameters: none

      Optional parameters: none

      Encoding considerations: binary

      Security considerations: See Security Considerations in Section 5.

      Interoperability considerations: N/A

      Published specification: [[ This document ]]

      Applications that use this media type: Applications that publish
      descriptions of URI Templates.

      Additional information:

         Magic number(s): N/A

         File extension(s): .tdx

         Macintosh file type code(s): TEXT

      Person & email address to contact for further information: Erik
      Wilde <erik.wilde@emc.com>

      Intended usage: COMMON

      Restrictions on usage: none

      Author: Erik Wilde <erik.wilde@emc.com>

      Change controller: IETF

4.2.  Link Relation

   The link relation type below will be registered by IANA per Section
   6.2.1 of RFC 5988 [6]:

      Relation Name: query-template

      Description: Linking to a resource that can be used as a template
      description for creating a request URI for the context resource.




Wilde, et al.             Expires June 10, 2013                 [Page 6]

Internet-Draft          URI Template Descriptions          December 2012


      Reference: [[ This document ]]

      Notes: Template Descriptions can be used in all scenarios where
      clients want to create requests that represent a query into the
      context resource.  The media type of the context resource and the
      media type of the template description resource are not
      constrained by this specification.


5.  Security Considerations

   ...


6.  Examples

   ...

6.1.  OpenSearch

   ...

6.2.  Atom Feeds

   ...

   "Feed Paging and Archiving" specified in RFC 5005 [8]

   Maybe suggest to use profiles?


7.  Open Issues

      If and how to use profiles (example in Section 6); if profile use
      is recommended, define a suggested profile URI for other specs to
      use?

      Should we support other ways how URIs could be generated, most
      importantly the application/x-www-form-urlencoded method of HTML
      forms?

      How to handle variables in Level 4 templates that are supposed to
      have composite values?

      Should there be some way how default values can be exposed/
      documented?





Wilde, et al.             Expires June 10, 2013                 [Page 7]

Internet-Draft          URI Template Descriptions          December 2012


      If a template is refined in an incremental process, does it make
      sense to be able to add a "back" link and/or "home" link, so that
      clients can find the "most general" version easily?


8.  References

8.1.  Normative References

   [1]  Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D.
        Orchard, "URI Template", RFC 6570, March 2012.

   [2]  Hollander, D., Layman, A., Thompson, H., Tobin, R., and T. Bray,
        "Namespaces in XML 1.0 (Third Edition)", World Wide Web
        Consortium Recommendation REC-xml-names-20091208, December 2009,
        <http://www.w3.org/TR/2009/REC-xml-names-20091208>.

   [3]  Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second
        Edition", World Wide Web Consortium Recommendation REC-
        xmlschema-2-20041028, October 2004,
        <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.

   [4]  Thompson, H., Beech, D., Mendelsohn, N., and M. Maloney, "XML
        Schema Part 1: Structures Second Edition", World Wide Web
        Consortium Recommendation REC-xmlschema-1-20041028,
        October 2004,
        <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.

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

   [6]  Nottingham, M., "Web Linking", RFC 5988, October 2010.

   [7]  Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication
        Format", RFC 4287, December 2005.

8.2.  Informative References

   [8]  Nottingham, M., "Feed Paging and Archiving", RFC 5005,
        September 2007.

URIs

   [9]  <http://tech.groups.yahoo.com/group/rest-discuss/>







Wilde, et al.             Expires June 10, 2013                 [Page 8]

Internet-Draft          URI Template Descriptions          December 2012


Authors' Addresses

   Erik Wilde
   EMC Corporation
   6801 Koll Center Parkway
   Pleasanton, CA 94566
   U.S.A.

   Phone: +1-925-6006244
   Email: erik.wilde@emc.com
   URI:   http://dret.net/netdret/


   Cornelia Davis
   EMC Corporation

   Email: cornelia.davis@emc.com


   Yiming Liu
   UC Berkeley
   South Hall
   Berkeley, CA 94720
   U.S.A.

   Email: yliu@ischool.berkeley.edu

























Wilde, et al.             Expires June 10, 2013                 [Page 9]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/