| draft-nottingham-site-meta-01.txt |  | draft-nottingham-site-meta-02.txt |
--- | --- | --- | --- | ---
| Network Working Group M. Nottingham |  | Network Working Group M. Nottingham |
| Internet-Draft E. Hammer-Lahav |  | Internet-Draft E. Hammer-Lahav |
| Intended status: Informational February 10, 2009 |  | Intended status: Informational April 8, 2009 |
| Expires: August 14, 2009 |  | Expires: October 10, 2009 |
| Host Metadata for the Web |  | Host Metadata for the Web |
| draft-nottingham-site-meta-01 |  | draft-nottingham-site-meta-02 |
| Status of this Memo |  | Status of this Memo |
| This Internet-Draft is submitted to IETF in full conformance with the |  | This Internet-Draft is submitted to IETF in full conformance with the |
| provisions of BCP 78 and BCP 79. |  | provisions of BCP 78 and BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF), its areas, and its working groups. Note that |  | Task Force (IETF), its areas, and its working groups. Note that |
| other groups may also distribute working documents as Internet- |  | other groups may also distribute working documents as Internet- |
| Drafts. |  | Drafts. |
| skipping to change at page 1, line 32 |  | skipping to change at page 1, line 32 |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| The list of current Internet-Drafts can be accessed at |  | The list of current Internet-Drafts can be accessed at |
| http://www.ietf.org/ietf/1id-abstracts.txt. |  | http://www.ietf.org/ietf/1id-abstracts.txt. |
| The list of Internet-Draft Shadow Directories can be accessed at |  | The list of Internet-Draft Shadow Directories can be accessed at |
| http://www.ietf.org/shadow.html. |  | http://www.ietf.org/shadow.html. |
| This Internet-Draft will expire on August 14, 2009. |  | This Internet-Draft will expire on October 10, 2009. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2009 IETF Trust and the persons identified as the |  | Copyright (c) 2009 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents in effect on the date of |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | publication of this document (http://trustee.ietf.org/license-info). |
| publication of this document. Please review these documents |  | Please review these documents carefully, as they describe your rights |
| carefully, as they describe your rights and restrictions with respect |  | and restrictions with respect to this document. |
| to this document. |  |  |
| Abstract |  | Abstract |
| This memo describes a method for locating host-specific metadata for |  | This memo describes a method for locating host-specific metadata for |
| the Web. |  | the Web. |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 |
| 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 |  | 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 |
| 3. The host-meta File Format . . . . . . . . . . . . . . . . . . 4 |  | 3. The host-meta File Format . . . . . . . . . . . . . . . . . . 4 |
| 3.1. The Link host-meta Field . . . . . . . . . . . . . . . . . 5 |  | 3.1. The Link host-meta Field . . . . . . . . . . . . . . . . . 5 |
| 4. Discovering host-meta Files . . . . . . . . . . . . . . . . . 5 |  | 4. Discovering host-meta Files . . . . . . . . . . . . . . . . . 5 |
| 5. Minting New meta-fields . . . . . . . . . . . . . . . . . . . 6 |  | 5. Minting New meta-fields . . . . . . . . . . . . . . . . . . . 6 |
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 |  | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 |
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 |  | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 |
| 7.1. application/host-meta Media Type Registration . . . . . . 6 |  | 7.1. application/host-meta Media Type Registration . . . . . . 7 |
| 7.2. The host-meta Field Registry . . . . . . . . . . . . . . . 7 |  | 7.2. The host-meta Field Registry . . . . . . . . . . . . . . . 7 |
| 7.2.1. Registration Template . . . . . . . . . . . . . . . . 8 |  | 7.2.1. Registration Template . . . . . . . . . . . . . . . . 8 |
| 7.2.2. The Link host-meta field . . . . . . . . . . . . . . . 8 |  | 7.2.2. The Link host-meta field . . . . . . . . . . . . . . . 8 |
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 |  | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 |
| 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 |  | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 |
| 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 |  | 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 |
| Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 |  | Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 |
| Appendix B. Frequently Asked Questions . . . . . . . . . . . . . 10 |  | Appendix B. Frequently Asked Questions . . . . . . . . . . . . . 10 |
| B.1. Is this mechanism appropriate for all kinds of |  | B.1. Is this mechanism appropriate for all kinds of |
| metadata? . . . . . . . . . . . . . . . . . . . . . . . . 10 |  | metadata? . . . . . . . . . . . . . . . . . . . . . . . . 10 |
| B.2. Why not use OPTIONS * with content negotiation to |  | B.2. Why not use OPTIONS * with content negotiation to |
| discover different types of metadata directly? . . . . . . 10 |  | discover different types of metadata directly? . . . . . . 10 |
| B.3. Why not use a META tag or microformat in the root |  | B.3. Why not use a META tag or microformat in the root |
| resource? . . . . . . . . . . . . . . . . . . . . . . . . 10 |  | resource? . . . . . . . . . . . . . . . . . . . . . . . . 10 |
| B.4. Why not use response headers on the root resource, and |  | B.4. Why not use response headers on the root resource, and |
| have clients use HEAD? . . . . . . . . . . . . . . . . . . 10 |  | have clients use HEAD? . . . . . . . . . . . . . . . . . . 10 |
| B.5. Why scope metadata to an authority? . . . . . . . . . . . 10 |  | B.5. Why scope metadata to a single URI scheme, host and |
|  |  | port combination? . . . . . . . . . . . . . . . . . . . . 10 |
| B.6. Why /host-meta? . . . . . . . . . . . . . . . . . . . . . 11 |  | B.6. Why /host-meta? . . . . . . . . . . . . . . . . . . . . . 11 |
| B.7. Aren't you concerned about pre-empting an authority's |  | B.7. Aren't you concerned about pre-empting an authority's |
| URI namespace? . . . . . . . . . . . . . . . . . . . . . . 11 |  | control over their URI namespace? . . . . . . . . . . . . 11 |
| B.8. Why use link relations instead of media types to |  | B.8. Why use link relations instead of media types to |
| identify kinds of metadata? . . . . . . . . . . . . . . . 11 |  | identify kinds of metadata? . . . . . . . . . . . . . . . 11 |
| B.9. What impact does this have on existing mechanisms, |  | B.9. What impact does this have on existing mechanisms, |
| such as P3P and robots.txt? . . . . . . . . . . . . . . . 11 |  | such as P3P and robots.txt? . . . . . . . . . . . . . . . 11 |
| B.10. Why not (insert existing similar mechanism here)? . . . . 11 |  | B.10. Why not (insert existing similar mechanism here)? . . . . 11 |
| Appendix C. Document History . . . . . . . . . . . . . . . . . . 11 |  | Appendix C. Document History . . . . . . . . . . . . . . . . . . 11 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 |  | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 |
| 1. Introduction |  | 1. Introduction |
| It is increasingly common for Web-based protocols to require the |  | It is increasingly common for Web-based protocols to require the |
| discovery of policy or metadata before making a request. For |  | discovery of policy or metadata before making a request. For |
| example, the Robots Exclusion Protocol specifies a way for automated |  | example, the Robots Exclusion Protocol specifies a way for automated |
| processes to obtain permission to access resources; likewise, the |  | processes to obtain permission to access resources; likewise, the |
| Platform for Privacy Preferences [W3C.REC-P3P-20020416] tells user- |  | Platform for Privacy Preferences [W3C.REC-P3P-20020416] tells user- |
| agents how to discover privacy policy beforehand. |  | agents how to discover privacy policy beforehand. |
| skipping to change at page 3, line 25 |  | skipping to change at page 3, line 25 |
| HTTP headers, WebDAV's PROPFIND [RFC4918]), the overhead associated |  | HTTP headers, WebDAV's PROPFIND [RFC4918]), the overhead associated |
| with them often precludes their use in these scenarios. |  | with them often precludes their use in these scenarios. |
| When this happens, it is common to designate a "well-known location" |  | When this happens, it is common to designate a "well-known location" |
| for such metadata, so that it can be easily located. However, this |  | for such metadata, so that it can be easily located. However, this |
| approach has the drawback of risking collisions, both with other such |  | approach has the drawback of risking collisions, both with other such |
| designated "well-known locations" and with pre-existing resources. |  | designated "well-known locations" and with pre-existing resources. |
| To address this, this memo proposes a single (and hopefully last) |  | To address this, this memo proposes a single (and hopefully last) |
| "well-known location", /host-meta, which acts as a directory to the |  | "well-known location", /host-meta, which acts as a directory to the |
| interesting metadata about a particular authority. Future mechanisms |  | interesting metadata about the resources that share a URI scheme, |
| that require authority-wide metadata can easily include an entry in |  | host and port. Future mechanisms that require such widely-scoped |
| the host-meta resource, thereby making their metadata cheaply |  | metadata can easily include an entry in the host-meta resource, |
| available (indeed, because it can be cached, the more mechanisms that |  | thereby making their metadata cheaply available (indeed, because it |
| use it, the more efficient it becomes) without impinging on others' |  | can be cached, the more mechanisms that use it, the more efficient it |
| URI space. |  | becomes) without impinging on others' URI space. |
| Note that the metadata provided by a host-meta resource is explicitly |  | Note that the metadata provided by a host-meta resource is explicitly |
| scoped to apply to the entire authority (in the URI [RFC3986] sense) |  | scoped to apply to the resources associated with the same combination |
| associated with it (using the process described in Section 4); it |  | of scheme, host and port (using the process described in Section 4); |
| does not apply to a subset, nor does it apply to other authorities |  | it does not apply to a subset, nor does it apply to other resources |
| (e.g., using another port, or a different hostname in the same |  | (e.g., using another port, or a different hostname in the same |
| domain). However, individual mechanisms (e.g., a relation type in |  | domain). However, individual mechanisms (e.g., a relation type in |
| the Link field) MAY reduce or expand this scope. This should only be |  | the Link field) MAY reduce or expand this scope. This should only be |
| done after careful consideration of the consequences upon security, |  | done after careful consideration of the consequences upon security, |
| administration, interoperability and network load. |  | administration, interoperability and network load. |
| Please discuss this draft on the www-talk@w3.org [1] mailing list. |  | Please discuss this draft on the www-talk@w3.org [1] mailing list. |
| 2. Notational Conventions |  | 2. Notational Conventions |
| skipping to change at page 4, line 10 |  | skipping to change at page 4, line 10 |
| document are to be interpreted as described in RFC 2119 [RFC2119]. |  | document are to be interpreted as described in RFC 2119 [RFC2119]. |
| This documnet uses the Augmented Backus-Naur Form (ABNF) notation of |  | This documnet uses the Augmented Backus-Naur Form (ABNF) notation of |
| [RFC5234], and explicitly includes the following rules from it: CRLF |  | [RFC5234], and explicitly includes the following rules from it: CRLF |
| (CR LF), OCTET (any 8-bit sequence of data), DIGIT, ALPHA, and WSP |  | (CR LF), OCTET (any 8-bit sequence of data), DIGIT, ALPHA, and WSP |
| (white space). |  | (white space). |
| 3. The host-meta File Format |  | 3. The host-meta File Format |
| The host-meta file format is an extremely simple textual language |  | The host-meta file format is an extremely simple textual language |
| that allows an authority to convey metadata about itself and its |  | that allows a set of resources to convey metadata about themselves. |
| resources. |  |  |
| Its syntax is similar to that of HTTP header-fields [RFC2616], but |  | Its syntax is similar to that of HTTP header-fields [RFC2616], but |
| has a few differences: |  | has a few differences: |
| o White space is permissible both before and after the block of |  | o White space is permissible both before and after the block of |
| fields, and |  | fields, and |
| o fields MUST NOT be folded across multiple lines. |  | o fields MUST NOT be folded across multiple lines. |
| Furthermore, this format's use diverges from HTTP header-fields in a |  | Furthermore, this format's use diverges from HTTP header-fields in a |
| number of ways: |  | number of ways: |
| o The fields are transferred as the message body, not as headers, |  | o The fields are transferred as the message body, not as headers, |
| and |  | and |
| o rather than being related to a message, the fields in host-meta |  | o rather than being related to a message, the fields in host-meta |
| pertain to the entire associated authority (see Section 4), and |  | pertain to the entire set of resources in scope (see Section 4), |
|  |  | and |
| o the permissible field-names are constrained by the host-meta field |  | o the permissible field-names are constrained by the host-meta field |
| registry. This specification defines one such field, Link. |  | registry. This specification defines one such field, Link. |
| host-meta = *( WSP / CRLF ) |  | host-meta = *( WSP / CRLF ) |
| *( meta-field CRLF ) |  | *( meta-field CRLF ) |
| *( WSP / CRLF ) |  | *( WSP / CRLF ) |
| meta-field = field-name ":" [ field-value ] |  | meta-field = field-name ":" [ field-value ] |
| field-name = 1*tchar |  | field-name = 1*tchar |
| field-value = *( field-content / WSP ) |  | field-value = *( field-content / WSP ) |
| field-content = <field content> |  | field-content = <field content> |
| skipping to change at page 4, line 50 |  | skipping to change at page 4, line 50 |
| For example, |  | For example, |
| Link: </robots.txt>; rel="robots" |  | Link: </robots.txt>; rel="robots" |
| Link: </w3c/p3p.xml>; rel="privacy"; type="application/p3p.xml" |  | Link: </w3c/p3p.xml>; rel="privacy"; type="application/p3p.xml" |
| Link: <http://example.net/example>; rel="http://example.com/rel" |  | Link: <http://example.net/example>; rel="http://example.com/rel" |
| As with HTTP headers, field-names are not case-sensitive, |  | As with HTTP headers, field-names are not case-sensitive, |
| unrecognised field-names SHOULD be silently ignored when parsing this |  | unrecognised field-names SHOULD be silently ignored when parsing this |
| format, and ordering of fields SHOULD NOT be considered significant |  | format, and ordering of fields SHOULD NOT be considered significant |
| unless specified otherwise. Additionally, although the syntax does |  | unless specified otherwise. Note also that blank links are not |
| not explicitly allow empty lines between fields, parsers SHOULD |  | permitted between fields. |
| silently discard them (i.e., be permissive in what they accept). |  |  |
| Field content is constrained by the specification indicated by its |  | Field content is constrained by the specification indicated by its |
| associated field-name. |  | associated field-name. |
| 3.1. The Link host-meta Field |  | 3.1. The Link host-meta Field |
| The "Link" host-meta field uses the syntax of the Link HTTP header- |  | The "Link" host-meta field uses the syntax of the Link HTTP header- |
| field [I-D.nottingham-http-link-header] to convey links whose context |  | field [I-D.nottingham-http-link-header] to convey links whose context |
| is the entire authority, rather than a single resource. For example, |  | is the entire host, rather than a single resource. For example, |
| Link: </terms>; rel="license" |  | Link: </terms>; rel="license" |
| indicates that the URI "/terms" refers to a license for all resources |  | found at 'http://example.com/host-meta' indicates that the URI |
| associated with the authority. |  | "/terms" refers to a license for all resources associated with |
|  |  | 'http://example.com'. |
| The Link host-meta field differs from the Link header in the |  | The Link host-meta field differs from the Link header in the |
| following respects: |  | following respects: |
| o Its context is defined as all resources that share its authority, |  | o Its context is defined as all resources that share the same URI |
| by default (although this MAY be overridden by a representation |  | scheme, host and port, by default (although this MAY be overridden |
| obtained from the indicated resource), and |  | by a representation obtained from the indicated resource), and |
| o When the link URI is relative, its base URI is the root resource |  | o When the link URI is relative, its base URI is the root resource |
| of the authority. For example, in the example above, if the |  | of the authority. In the example above, if the authority is |
| authority is "example.com", the full link URI would be |  | "example.com", the full link URI would be |
| "http://example.com/me". |  | "http://example.com/terms". |
| 4. Discovering host-meta Files |  | 4. Discovering host-meta Files |
| The metadata for a given authority can be discovered by dereferencing |  | The metadata for a given authority can be discovered by dereferencing |
| the path /host-meta on the same authority. For example, for an HTTP |  | the path /host-meta on the host and port, using the protocol |
| URI [RFC2616], the following request would obtain metadata for the |  | indicated by the URI scheme. For example, the following request |
| authority "www.example.com:80"; |  | would obtain metadata for "http://www.example.com/"; |
| GET /host-meta HTTP/1.1 |  | GET /host-meta HTTP/1.1 |
| Host: www.example.com |  | Host: www.example.com |
| The semantics of the protocol used for access to the resource apply. |  | The semantics of the protocol used for access to the resource apply. |
| Therefore, if the resource indicates the client should try a |  | Therefore, if the resource indicates the client should try a |
| different request (in HTTP, the 301, 302, 303 or 307 response status |  | different request (in HTTP, the 301, 302, 303 or 307 response status |
| code), the client SHOULD attempt to do so; note that this implies |  | code), the client SHOULD attempt to do so; note that this implies |
| that the host-meta file for one authority MAY be retrieved from a |  | that the host-meta file for one authority MAY be retrieved from a |
| different authority. Likewise, if the resource is not available or |  | different authority. Likewise, if the resource is not available or |
| existent (in HTTP, the 404 or 410 status code), the client SHOULD |  | existent (in HTTP, the 404 or 410 status code), the client SHOULD |
| infer that metadata is not available via this mechanism. |  | infer that metadata is not available via this mechanism. |
| If a representation is successfully obtained, but is not in the |  | If a representation is successfully obtained, but is not in the |
| format described above, clients SHOULD infer that the authority is |  | format described above, clients SHOULD infer that the authority is |
| using this URI for other purposes, and not process it as a host-meta |  | using this URI for other purposes, and not process it as a host-meta |
| file. |  | file. |
| To aid in this process, authorities using this mechanism SHOULD |  | To aid in this process, host-meta responses SHOULD be labelled with |
| correctly label host-meta responses with the "application/host-meta" |  | the "application/host-meta" internet media type. |
| internet media type. |  |  |
| 5. Minting New meta-fields |  | 5. Minting New meta-fields |
| Applications that wish to mint new meta-fields for use in the host- |  | Applications that wish to mint new meta-fields for use in the host- |
| meta format MUST register them in the host-meta field-registry, |  | meta format MUST register them in the host-meta field-registry, |
| following the procedures in Section 7.2. Field-names MUST conform to |  | following the procedures in Section 7.2. Field-names MUST conform to |
| the field-name ABNF Section 3, and field-value syntax MUST be well- |  | the field-name ABNF Section 3, and field-value syntax MUST be well- |
| defined (e.g., using ABNF, or a reference to the syntax of an |  | defined (e.g., using ABNF, or a reference to the syntax of an |
| existing header field-value). Field-values SHOULD use the ISO-859-1 |  | existing header field-value). Field-values SHOULD use the ASCII |
| character encoding. If a field-value applies to a scope other than |  | character encoding. If a field-value applies to a scope other than |
| the entire authority, that scope MUST be well-defined. |  | the entire authority, that scope MUST be well-defined. |
| 6. Security Considerations |  | 6. Security Considerations |
| The metadata returned by the /host-meta resource is presumed to be |  | The metadata returned by the /host-meta resource is presumed to be |
| under the control of the appropriate authority and representative of |  | under the control of the appropriate authority and representative of |
| all resources contained by it. If this resource is compromised or |  | all resources contained by it. If this resource is compromised or |
| otherwise under the control of another party, it may represent a risk |  | otherwise under the control of another party, it may represent a risk |
| to the security of the server and data served by it, depending on |  | to the security of the server and data served by it, depending on |
| what mechanisms use /host-meta. |  | what mechanisms use /host-meta. |
| Scoping metadata to a single authority is the default in host-meta. |  | Scoping metadata to a single URI scheme, host and port is the default |
| Thus "http://example.com/", "https://example.com" and |  | in host-meta. Thus "http://example.com/", "https://example.com" and |
| "http://www.example.com/" all have different host-meta files with |  | "http://www.example.com/" all have different host-meta files with |
| seperate and non-overlapping scopes of applicability. Applications |  | seperate and non-overlapping scopes of applicability. Applications |
| that change the scope of metadata can incur security risks without |  | that change the scope of metadata can incur security risks without |
| careful consideration. |  | careful consideration. |
|  |  | An attacker with certain types of limited access to a server may be |
|  |  | able to affect how the host-meta resource is served; for example, |
|  |  | they may be able to upload a file at that location, but not affect |
|  |  | its media type, or they may be able to cause a server to redirect |
|  |  | /host-meta to a URI that they control. |
| 7. IANA Considerations |  | 7. IANA Considerations |
| 7.1. application/host-meta Media Type Registration |  | 7.1. application/host-meta Media Type Registration |
| The host-meta format can be identified with the following media type: |  | The host-meta format can be identified with the following media type: |
| MIME media type name: application |  | MIME media type name: application |
| MIME subtype name: host-meta |  | MIME subtype name: host-meta |
| Mandatory parameters: None. |  | Mandatory parameters: None. |
| Optional parameters: None. |  | Optional parameters: None. |
| Encoding considerations: field-values may specify any encoding for |  | Encoding considerations: field-values may specify any encoding for |
| their contents, although it is expected that most will use ISO- |  | their contents, although it is expected that most will use ASCII |
| 8859-1 or a subset thereof (for both historic and interoperability |  | or a subset thereof (for both historic and interoperability |
| purposes). |  | purposes). |
| Security considerations: As defined in this specification. [[update |  | Security considerations: As defined in this specification. [[update |
| upon publication]] |  | upon publication]] |
| Interoperability considerations: There are no known interoperability |  | Interoperability considerations: There are no known interoperability |
| issues. |  | issues. |
| Published specification: This specification. [[update upon |  | Published specification: This specification. [[update upon |
| publication]] |  | publication]] |
| Applications which use this media type: No known applications |  | Applications which use this media type: No known applications |
| currently use this media type. |  | currently use this media type. |
| skipping to change at page 9, line 45 |  | skipping to change at page 9, line 49 |
| April 2002. |  | April 2002. |
| URIs |  | URIs |
| [1] <http://lists.w3.org/Archives/Public/www-talk/> |  | [1] <http://lists.w3.org/Archives/Public/www-talk/> |
| Appendix A. Acknowledgements |  | Appendix A. Acknowledgements |
| We would like to acknowledge the contributions of everyone who |  | We would like to acknowledge the contributions of everyone who |
| provided feedback and use cases for this draft; in particular, Phil |  | provided feedback and use cases for this draft; in particular, Phil |
| Archer, Dirk Balfanz, Tim Bray, Paul Hoffman, Barry Leiba, Ashok |  | Archer, Dirk Balfanz, Adam Barth, Tim Bray, Brian Eaton, Paul |
| Malhotra, Breno de Medeiros, and John Panzer. The authors take all |  | Hoffman, Barry Leiba, Ashok Malhotra, Breno de Medeiros, and John |
| responsibility for errors and omissions. |  | Panzer, and Drummond Reed. The authors take all responsibility for |
|  |  | errors and omissions. |
| Appendix B. Frequently Asked Questions |  | Appendix B. Frequently Asked Questions |
| B.1. Is this mechanism appropriate for all kinds of metadata? |  | B.1. Is this mechanism appropriate for all kinds of metadata? |
| No. The primary use cases are described in the introduction; when |  | No. The primary use cases are described in the introduction; when |
| it's necessary to discover metadata or policy before a resource is |  | it's necessary to discover metadata or policy before a resource is |
| accessed, and/or it's necessary to describe metadata for a whole |  | accessed, and/or it's necessary to describe metadata for a whole site |
| authority (or large portions of it), host-meta is appropriate. In |  | (or large portions of it), host-meta is appropriate. In other cases |
| other cases (e.g., fine-grained metadata that doesn't need to be |  | (e.g., fine-grained metadata that doesn't need to be known ahead of |
| known ahead of time), other mechanisms are more appropriate. |  | time), other mechanisms are more appropriate. |
| B.2. Why not use OPTIONS * with content negotiation to discover |  | B.2. Why not use OPTIONS * with content negotiation to discover |
| different types of metadata directly? |  | different types of metadata directly? |
| Two reasons; a) OPTIONS is not cacheable -- a severe problem for |  | Two reasons; a) OPTIONS is not cacheable -- a severe problem for |
| scaling -- and b) it is not well-supported in browsers, and difficult |  | scaling -- and b) it is not well-supported in browsers, and difficult |
| to configure in servers. |  | to configure in servers. |
| B.3. Why not use a META tag or microformat in the root resource? |  | B.3. Why not use a META tag or microformat in the root resource? |
| This places constraints on the format of an authority's root resource |  | This places constraints on the format of a site's root resource to be |
| to be HTML or similar. While extremely common, it isn't universal |  | HTML or similar. While extremely common, it isn't universal (e.g., |
| (e.g., mobile sites, machine-to-machine communication, etc.). Also, |  | mobile sites, machine-to-machine communication, etc.). Also, some |
| some root resources are very large, which would place additional |  | root resources are very large, which would place additional overhead |
| overhead on clients and intervening networks. |  | on clients and intervening networks. |
| B.4. Why not use response headers on the root resource, and have |  | B.4. Why not use response headers on the root resource, and have |
| clients use HEAD? |  | clients use HEAD? |
| The headers on a root resource pertain to that resource, not the |  | The headers on a root resource pertain to that resource, not the |
| whole site. While it is possible to mint new message headers that |  | whole site. While it is possible to mint new message headers that |
| apply to the whole site, such a header would need to be sent on every |  | apply to the whole site, such a header would need to be sent on every |
| response for the root resource, whether it was useful or not, with |  | response for the root resource, whether it was useful or not, with |
| the potential for substantially increasing the size of those |  | the potential for substantially increasing the size of those |
| responses (which are often popular, and not very cacheable). |  | responses (which are often popular, and not very cacheable). |
| B.5. Why scope metadata to an authority? |  | B.5. Why scope metadata to a single URI scheme, host and port |
|  |  | combination? |
| The alternative is to allow scoping to be dynamic and determined |  | The alternative is to allow scoping to be dynamic and determined |
| locally, but this has its own issues, which usually come down to a) |  | locally, but this has its own issues, which usually come down to a) |
| an unreasonable number of requests to determine authoritative |  | an unreasonable number of requests to determine authoritative |
| metadata, b) increased complexity, with a higher likelihood of |  | metadata, b) increased complexity, with a higher likelihood of |
| implementation and interoperability (or even security) problems. |  | implementation and interoperability (or even security) problems. |
| Besides, many mechanisms on the Web already presume a single |  |  |
| authority scope (e.g., robots.txt, P3P, cookies, javascript |  | Besides, many mechanisms on the Web already presume a single scheme/ |
|  |  | host/port scope (e.g., robots.txt, P3P, cookies, javascript |
| security), and the effort and cost required to mint a new URI |  | security), and the effort and cost required to mint a new URI |
| authority is small and shrinking. |  | authority is small and shrinking. |
| B.6. Why /host-meta? |  | B.6. Why /host-meta? |
| It's short, descriptive and according to search indices, not widely |  | It's short, descriptive and according to search indices, not widely |
| used. |  | used. |
| B.7. Aren't you concerned about pre-empting an authority's URI |  | B.7. Aren't you concerned about pre-empting an authority's control over |
| namespace? |  | their URI namespace? |
| Yes, but it's unfortunately a necessary (and already present) evil; |  | Yes, but it's unfortunately a necessary (and already present) evil; |
| this proposal tries to minimise future abuses. |  | this proposal tries to minimise future abuses. |
| B.8. Why use link relations instead of media types to identify kinds of |  | B.8. Why use link relations instead of media types to identify kinds of |
| metadata? |  | metadata? |
| A link relation declares the intent and use of the link (or inline |  | A link relation declares the intent and use of the link (or inline |
| content, when present); a media type defines the format and |  | content, when present); a media type defines the format and |
| processing model for those bits. |  | processing model for those bits. |
| skipping to change at page 11, line 39 |  | skipping to change at page 11, line 44 |
| We are aware that there are several existing proposals with similar |  | We are aware that there are several existing proposals with similar |
| functionality. In our estimation, none have gained sufficient |  | functionality. In our estimation, none have gained sufficient |
| traction. This may be because they were perceived to be too complex, |  | traction. This may be because they were perceived to be too complex, |
| or tied too closely to one use case. |  | or tied too closely to one use case. |
| Appendix C. Document History |  | Appendix C. Document History |
| [[RFC Editor: please remove this section before publication.]] |  | [[RFC Editor: please remove this section before publication.]] |
|  |  | o -02 |
|  |  | * Changed preferred encoding to ASCII. |
|  |  | * Disallow blank lines between fields. |
|  |  | * Expanded scope beyond authority to include scheme. |
|  |  | * Fixed relative URI example. |
|  |  | * Added 'partial control' attack to security considerations. |
| o -01 |  | o -01 |
| * Changed "site-meta" to "host-meta" after feedback. |  | * Changed "site-meta" to "host-meta" after feedback. |
| * Changed from XML to text-based header-like format. |  | * Changed from XML to text-based header-like format. |
| * Remove capability for generic inline content. |  | * Remove capability for generic inline content. |
| * Added registry for host-meta fields. |  | * Added registry for host-meta fields. |
| * Clarified scope of metadata application. |  | * Clarified scope of metadata application. |
| * Added security consideration about HTTP vs. HTTPS, expanding |  | * Added security consideration about HTTP vs. HTTPS, expanding |
| scope. |  | scope. |
| Authors' Addresses |  | Authors' Addresses |
End of changes. 30 change blocks.
| 65 lines changed or deleted |  | 80 lines changed or added |
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/