| TOC |
|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
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.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 15, 2008.
This document defines an Extensible Data Format (XML) for describing files.
1.
Introduction
2.
Terminology
3.
The 'file-metadata' XML Document
3.1.
Full 'file-metadata' document
3.2.
Partial 'file-metadata' document: patch operations
3.3.
XML Schema
3.4.
Examples
3.4.1.
Example of a full 'file-document' document
3.4.2.
Example of a partial 'file-metadata' document
3.4.3.
Example of a full 'file-metadata' document
3.4.4.
Example of a partial 'file-metadata' document
4.
Security Considerations
5.
IANA Considerations
6.
References
6.1.
Normative References
6.2.
Informative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
In the recent times there is a growing interest for defining a standard format for describing files and its associated meta-data. This is the case, for example, of the Session Initiation Protocol (SIP) file sharing framework (Garcia-Martin, M., Matuszewski, M., Beijar, N., and J. Lehtinen, “Sharing Files with the Session Initiation Protocol (SIP),” November 2007.) [I‑D.garcia‑sipping‑file‑sharing‑framework], which describes a usage of SIP for publishing file metadata. Other usages, for example, based on the HyperText Transfer Protocol (HTTP) (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [RFC2616] have been also discussed, and it is expected that the growing usage of XML in IETF protocols will increase the demand for this format.
This document creates a generic XML document format for describing files and their associated meta-data. The document format is extensible, so future needs can be addressed thorough extensions. It is expected that applications that need to describe files use this format as their standard format.
| TOC |
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 BCP 14, RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119] and indicate requirement levels for compliant implementations.
| TOC |
A 'file-metadata' document is an XML document (Sperberg-McQueen, C., Maler, E., Paoli, J., and T. Bray, “Extensible Markup Language (XML) 1.0 (Second Edition),” October 2000.) [W3C.REC‑xml‑20001006] that MUST be well-formed and SHOULD be valid. A 'file-metadata' document MUST be based on XML 1.0 and MUST be encoded using UTF-8 (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.) [RFC3629]. This specification makes use of XML namespaces for identifying 'file-metadata' documents. The namespace URI for elements defined by this specification is a URN (Moats, R., “URN Syntax,” May 1997.) [RFC2141], using the namespace identifier 'ietf'. This URN is:
- urn:ietf:params:xml:ns:file
The 'file-metadata' documents are identified with the MIME type "application/file+xml" and are instances of the XML schema defined in Section 3.3 (XML Schema).
The XML schema that defines the constrains of the 'file-metadata' document provides support for full and partial 'file-metadata' documents, so that applications that can accommodate differentiated versions of XML documents can use partial content to signal a change in one or more files. The XML schema contains provisions for two root elements, namely <file-set> and <patch>, of which only one MUST be present in a valid 'file-metadata' document. The <file-set> element is used to describe a full 'file-metadata' document, i.e., one containing a full state of the available files. A full 'file-metadata' document MUST be used in any initial publication or initial notification. On the contrary, the <patch> element is used to describe a partial 'file-metadata' document. The <patch> element contains a number of patch operations that, once applied to a previous version of a full 'file-metadata' document, create an updated full document.
- The XML schema rules require that only one root element is present in an XML document. Therefore, a 'file-metadata' document compliant with the XML schema definition contains either a <file-set> root element or a <patch> root element, but not both.
Due to the duality of a 'file-metadata' document, depending on whether it contains a full or a partial 'file-metadata' document, we describe separately each of them in Section 3.1 (Full 'file-metadata' document) and Section 3.2 (Partial 'file-metadata' document: patch operations), respectively.
| TOC |
A full 'file-metadata' document begins with the root element tag <file-set> that describes a collection of files. The <file-set> element contains a mandatory 'version' attribute. When 'file-metadata' documents are used with protocols that provide the notion of a session, such as SIP (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261], an initial appearance of a 'file-metadata' document in a session selects an initial value for the 'version' attribute of the <file-set> element. Subsequent 'file-metadata' documents within the same session MUST increment the value of the 'version' attribute by one, no matter whether they are full or partial, and add it either to the <file-set> or <patch> element, as appropriate. As a consequence, the counter of the 'version' attribute is shared between <file-set> and <patch> elements.
The <file-set> element consists of one or more child <file> elements. The <file-set> element MAY contain a <timestamp> element, a <note> element, and MAY contain other elements and attributes from different namespaces for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored.
Each <file> element represents the description data of a file. It includes an 'id' attribute that contains a unique identifier. The value of the 'id' attribute MUST be unique within the 'file-metadata' document.
The <timestamp< element contains a string indicating when the document has been last updated. The value of this element MUST follow the IMPP datetime format (Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” July 2002.) [RFC3339]. Timestamps that contain 'T' or 'Z' MUST use the capitalized forms. It is recommended that file metadata documents contain a <timestamp> element to indicate the age of the document.
The <note> element contains a string value, which is usually used for a human readable comment. A <note> element MAY appear as a child element of <file-set> element.
The <file> element consists of one <identity> element and one or more <instance> elements. The <file> element MAY also contain other elements and attributes from different namespaces for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored.
The <identity> element groups a number of elements that represent the invariant data of the file, i.e., file metadata that is common across different instances of the file. For example, the <identity> element provides a description for the hash or size of a file. On the contrary, data that is specific to the location of the file are grouped in the <instance> element. This can include a Uniform Resource Identifier (URI) of the user who hosts the file or a human readable description of the file.
The <identity> element contains an 'id' attribute whose value MUST be unique within the XML document.
The <identity> element contains zero or one <urn>, <mime-type>, <size>, and <sha1> elements. The <identity> element MAY also contain other elements and attributes from different namespaces for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored.
The <urn> element contains a persistent, location-independent, resource identifier expressed as a Uniform Resource Name (URN) (Moats, R., “URN Syntax,” May 1997.) [RFC2141] that is allocated to the file and uniquely identifies it. If present, the value of the <urn> element MUST be formatted according to the URN syntax specified in RFC 2141 (Moats, R., “URN Syntax,” May 1997.) [RFC2141].
The <mime-type> element contains the Multipurpose Internet Mail Extensions (MIME) type of the file. If present, the value of the <mime-type> element SHOULD contain an IANA registered MIME media type expressed as type/subtype format.
The <size> element contains the file size in octets.
The <sha1> element contains the results of a hashing operation on the file. The hashing operation MUST be computed using the US Secure Hash Algorithm 1 (SHA1) (Eastlake, D. and P. Jones, “US Secure Hash Algorithm 1 (SHA1),” September 2001.) [RFC3174] and MUST be expressed in hexadecimal format.
One or more <instance> elements can be included in the <file> element. Each <instance> element provides information that is related to a particular instance of the file, rather than the file itself.
Each <instance> element contains an 'id' attribute whose value MUST be unique within the XML document. The <instance> element also contains one or more <uri> and <urn> elements, and zero or one <user-uri>, <user-gruu>, <name>, <description> <iconptr>, <creation-date>, <modification-date>, <read-date> and <keywords> elements. Additionally, the <instance> element MAY contain other elements and attributes from different namespaces for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored.
The <uri> element contains either a location-dependent, typically protocol-specific file identifier expressed as a Uniform Resource Identifier (URI) (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) [RFC3986]. The <uri> element can be, for example, an HTTP or FTP URI.
The <user-uri> provides a container for a URI that resolves to the URI f the user where the file is available. For example, this can be a SIP or SIPS URI. This might be useful when it is not possible to provide a URI (in the <uri> element) that resolves to the file itself, but instead, there is a URI that resolves to the user that hosts the file.
The <user-gruu> provides a SIP Globally Routable User Agent URI (GRUU) (Rosenberg, J., “Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP),” October 2007.) [I‑D.ietf‑sip‑gruu] that points to the SIP instance in the User Agent where the file is available. This element completes the <user-uri> by providing an pointer to the SIP instance that is hosting the file.
The <name> element contains the file name.
The <description> element contains a human readable text describing the file.
The <iconptr> element contains a URI that points to an icon that represents the file. This is typically applicable to image or video files.
The <creation-date> element indicates the date and time at which the file was created.
The <modification-date> element indicates the date and time at which the file was last modified.
The <read-date> element indicates the date and time at which the file was last read.
The <keywords> element is a container of keywords associated to the file. Its main purpose is to assist indexing and search engines. The <keywords> element contains one or more <keyword> elements (notice the singular form of the child elements). The <keywords> element MAY contain other attributes from different namespaces for the purposes of extensibility; attributes from unknown namespaces MUST be ignored.
Each <keyword> element contains one word that represents a keyword associated to the file. A <keyword> element SHOULD NOT contain any white spaces. If several keywords are to be included, each one should be included in a separate <keyword> element.
| TOC |
A partial 'file-metadata' document begins with the root element tag <patch> that describes a collection of XML patch operations (Urpalainen, J., “An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors,” November 2007.) [I‑D.ietf‑simple‑xml‑patch‑ops] that are to be applied to a previous version of a full 'file-metadata' document. The <patch> element contains a mandatory 'version' attribute whose counter is shared with the 'version' attribute of the <file-set> element. Each new partial 'file-metadata' document MUST increment the 'version' attribute value by one, with respect the previously sent version. The value of the 'version' attribute can be used to ensure consistent updates as the recipient of the document can use the 'version' number to properly order received documents and to ensure that updates have not been lost.
The <patch> element consists of one or more child <add>, <replace>, or <remove> elements whose type definitions are included from the XML Patch Operations (Urpalainen, J., “An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors,” November 2007.) [I‑D.ietf‑simple‑xml‑patch‑ops] identified with the namespace "urn:ietf:params:xml:schema:xml-patch-ops".
The <patch> element MAY contain other elements and attributes from different namespaces for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored.
The <add> element is used to add new content to the 'file-metadata' document. The details of the <add> element are discussed in the XML Patch Operations (Urpalainen, J., “An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors,” November 2007.) [I‑D.ietf‑simple‑xml‑patch‑ops].
The <replace> element is used to update content in the 'file-metadata' document. The details of the <replace> element are discussed in the XML Patch Operations (Urpalainen, J., “An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors,” November 2007.) [I‑D.ietf‑simple‑xml‑patch‑ops].
The <remove> element is used to remove content from the 'file-metadata' document. The details of the <remove> element are discussed in the XML Patch Operations (Urpalainen, J., “An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors,” November 2007.) [I‑D.ietf‑simple‑xml‑patch‑ops].
Once all the patch operations have been applied to the previous full 'file-metadata' document, a new full 'file-metadata' document is created with the same 'version' attribute value, letting a subsequent partial 'file-metadata' document operate on the last full document.
| TOC |
Implementations according to this specification MUST comply to the following XML schema that defines the constraints of the 'file-metadata' document:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:file"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:file"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:annotation>
<xs:documentation xml:lang="en">
XML Schema Definition to provide information about
available files at a host.
</xs:documentation>
</xs:annotation>
<!-- include xml-patch-ops type definitions -->
<xs:include
schemaLocation="urn:ietf:params:xml:schema:xml-patch-ops"/>
<xs:element name="file-set" type="file-setType"/>
<xs:element name="patch" type="patchType"/>
<xs:complexType name="file-setType">
<xs:sequence>
<xs:element name="file" type="fileType"
maxOccurs="unbounded"/>
<xs:element name="timestamp" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="note" type="note" minOccurs="0"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="version" type="xs:unsignedInt"
use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<xs:complexType name="fileType">
<xs:sequence>
<xs:element name="identity" type="identityType" />
<xs:element name="instance" type="instanceType"
maxOccurs="unbounded" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<xs:complexType name="identityType">
<xs:sequence>
<xs:element name="urn" type="xs:anyURI" minOccurs="0"/>
<xs:element name="mime-type" type="xs:string" minOccurs="0"/>
<xs:element name="size" type="xs:nonNegativeInteger"
minOccurs="0"/>
<xs:element name="sha1" type="xs:hexBinary" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<xs:complexType name="instanceType">
<xs:sequence>
<xs:element name="name" type="xs:string" minOccurs="0"/>
<xs:element name="description" type="xs:string"
minOccurs="0"/>
<xs:element name="uri" type="xs:anyURI" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="user-uri" type="xs:anyURI" minOccurs="0"/>
<xs:element name="user-gruu" type="xs:anyURI" minOccurs="0"/>
<xs:element name="iconptr" type="xs:anyURI"
minOccurs="0"/>
<xs:element name="creation-date" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="modification-date" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="read-date" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="keywords" type="keywordsType"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<xs:complexType name="keywordsType">
<xs:sequence>
<xs:element name="keyword" type="xs:token"
maxOccurs="unbounded" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<xs:complexType name="patchType">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="add" type="add"/>
<xs:element name="replace" type="replace"/>
<xs:element name="remove" type="remove"/>
</xs:choice>
<xs:attribute name="version" type="xs:unsignedInt"/>
</xs:complexType>
<xs:complexType name="note">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang"/>>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
| Figure 1: 'file-metadata' document XML schema |
| TOC |
| TOC |
Figure 2 (Example of a full 'file-metadata' document) is an example of a 'file-metadata' document.
<?xml version="1.0" encoding="UTF-8"?>
<file-set xmlns="urn:ietf:params:xml:ns:file"
version="123">
<file id="id38sh12jd">
<identity id="id9d8c9">
<mime-type>image/jpeg</mime-type>
<size>230432</size>
<sha1>72245FE8653DDAF371362F86D471913EE4A2CE2E</sha1>
</identity>
<instance id="idc989c00">
<name>coolpic.jpg</name>
<description>
This is my latest cool picture from my summer vacation
</description>
<user-uri>sip:miguel.an.garcia@example.com</user-uri>
<user-gruu>
sip:miguel.an.garcia@example.com;
gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
</user-gruu>
<iconptr>http://www.example.com/coolpic-icon.jpg</iconptr>
<creation-date>2006-05-09T09:30:47+03:00</creation-date>
<modification-date>
2006-05-09T10:24:34+03:00
</modification-date>
<read-date>2006-05-10T14:24:32+03:00</read-date>
<keywords>
<keyword>summer</keyword>
<keyword>vacation</keyword>
</keywords>
</instance>
</file>
<timestamp>2007-11-12T09:55:28Z</timestamp>
<note xml:lang="en">There is only one available file</note>
</file-set>
| Figure 2: Example of a full 'file-metadata' document |
The example in Figure 2 (Example of a full 'file-metadata' document) shows a full 'file-metadata' document. The example contains the description of a single file: an image file. The source of the information provides description of the file (an <file> element) that contains the static data of the file included in the <identity> element and the variable data (that depends on the actual instance of the file) in the <instance> element. The <identity> element contains a number of characteristics of the file that would not change across different instances, such as the MIME type, the size, and the hash of the file. On the contrary, the <instance> element contains the data related to the particular instance of the file, such as the name assigned by the user to the file, a human readable description, the GRUU that points to the SIP User Agent where the file is stored, the creation, modification, and read dates, etc. Last, a <timestamp> and a <note> elements indicate the date and time when the XML document was created and a human readable note.
| TOC |
Figure 3 (Example of a partial 'file-metadata' document) is an example of a partial 'file-metadata' document.
<?xml version="1.0" encoding="UTF-8"?>
<patch xmlns="urn:ietf:params:xml:ns:file"
version="124">
<add sel="file-set">
<file id="b390d92">
<identity id="mm8b8d">
<mime-type>message/msrp</mime-type>
</identity>
<instance id="hhdu23">
<name>IETFers chat room</name>
<description>
Dedicated chat room for IETF discussions
</description>
<user-gruu>
sip:miguel.an.garcia@example.com;
gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
</user-gruu>
<user-uri>sip:miguel.an.garcia@example.com</user-uri>
</instance>
</file>
</add>
<replace sel="file-set/timestamp">
<timestamp>2007-11-12T11:00:00Z</timestamp>
</replace>
<replace sel="file-set/note">
<note xml:lange="en">Now I have two available files</note>
</replace>
</patch>
| Figure 3: Example of a partial 'file-metadata' document |
The example in Figure 3 (Example of a partial 'file-metadata' document) shows an example of a partial 'file-metadata' document. The document contains the patch operations that adds one more new file to the existing list of files, so the result of applying the patch to the initial file metadata document of Figure 2 (Example of a full 'file-metadata' document) results in a document that contains the description of two files.
The 'version' attribute of the <patch> element is incremented by one with respect the 'version' attribute of the <file-set> element of the full 'file-metadata' document in Figure 2 (Example of a full 'file-metadata' document). The document replaces the previous <timestamp> and <note> elements with new values.
| TOC |
Figure 4 (Example of a full 'file-metadata' document) is an example of a full 'file-metadata' document.
<?xml version="1.0" encoding="UTF-8"?>
<file-set xmlns="urn:ietf:params:xml:ns:file"
version="312">
<file id="nkcdn0">
<identity id="aa77d7">
<mime-type>audio/3gpp</mime-type>
<size>34987</size>
<sha1>E05DA01A590E31F6E3100AD7BEC39C63464A1CD0</sha1>
</identity>
<instance id="idea1dof">
<name>recording-1.3gp</name>
<description>
Bob's speech at a conference
</description>
<user-uri>sip:miguel.an.garcia@example.com</user-uri>
<user-gruu>
sip:miguel.an.garcia@example.com;
gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
</user-gruu>
<creation-date>2006-05-01T01:30:47+03:00</creation-date>
<modification-date>
2006-05-02T02:24:34+03:00
</modification-date>
<read-date>2006-05-03T03:24:32+03:00</read-date>
<keywords>
<keyword>Bob</keyword>
<keyword>speech</keyword>
</keywords>
</instance>
<instance id="kxf-312">
<name>bob-speech.3gp</name>
<description>
Bob talking about nanotechnology
</description>
<user-uri>sip:alice@example.com</user-uri>
<user-gruu>
sip:alice@example.com;
gr=urn:uuid:f81d4fae-7dec-11d0-4de9-00a2ac4e398a
</user-gruu>
<creation-date>2006-05-01T01:30:47+03:00</creation-date>
<modification-date>
2006-05-02T02:24:34+03:00
</modification-date>
<read-date>2006-05-24T05:12:07+02:00</read-date>
<keywords>
<keyword>Bob</keyword>
<keyword>nanotechnology</keyword>
</keywords>
</instance>
</file>
<timestamp>2007-11-12T14:01:02Z</timestamp>
<note>There is a single file available at two endpoints</note>
</file-set>
| Figure 4: Example of a full 'file-metadata' document |
The example in Figure 4 (Example of a full 'file-metadata' document) shows an example of a full 'file-metadata' document. The document describes a single audio file, which is available at two difference hosts, thus, the 'file-metadata' document starts with a <file-set> element that contains the description of the file in the <file> element. The <file> element contains an <identity> element and two <instance> elements. The <identity> element contains descriptive invariant data of the file. Each of the <instance> elements contains data related to the particular instance where the file is available.
| TOC |
Figure 5 (Example of a partial 'file-metadata' document) is an example of a partial 'file-metadata' document.
<?xml version="1.0" encoding="UTF-8"?>
<patch xmlns="urn:ietf:params:xml:ns:file"
version="313">
<add sel="file-set/file[@id='nkcdn0']">
<instance id="ak6v3d">
<name>nanotalk.3gp</name>
<description>
Nanotechnology speech
</description>
<user-gruu>
sip:bob@example.com;
gr=urn:uuid:f81d4fae-7dec-11d0-5d3a-bbc333431122
</user-gruu>
<user-uri>sip:bob@example.com</user-uri>
</instance>
</add>
<replace sel="id('idea1dof')/read-date/text()"
>2006-06-07T17:26:04+03:00</replace>
<replace sel="file-set/timestamp">
<timestamp>2007-11-12T18:02:02Z</timestamp>
</replace>
<replace sel="file-set/note">
<note xml:lange="en"<Three instances of the same file</note>
</replace>
</patch>
| Figure 5: Example of a partial 'file-metadata' document |
Figure 5 (Example of a partial 'file-metadata' document) contains a number of XML patch operations to be applied to the full 'file-metadata' document included in Figure 4 (Example of a full 'file-metadata' document). The document in Figure 5 (Example of a partial 'file-metadata' document) starts with a <patch> root element, indicating that it is a partial 'file-metadata' document. The 'version' attribute is incremented by one with respect the 'version' attribute of the <file-set> element of the full 'file-metadata' document of Figure 4 (Example of a full 'file-metadata' document).
The document contains an <add> element that first selects the <file> element whose 'id' attribute is set to "nkcdn0". Then it appends, at the end of the existing child elements, a new <instance> element that describes the availability of the same file at a different endpoint.
The first <replace> element selects the <read-date> element of the <instance> whose 'id' attribute is set to "idea1dof" and replaces the value with a new date and time. Then, the following <replace> elements replace the <timestamp> and <note> elements, respectively.
- Note: the 'sel' attribute of the <replace> element in Figure 5 (Example of a partial 'file-metadata' document) is split in two lines due to formatting restrictions. It will appear as a single line in XML documents.
| TOC |
TBD
| TOC |
TBD
| TOC |
| TOC |
| TOC |
| [RFC2616] | Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” RFC 2616, June 1999 (TXT, PS, PDF, HTML, XML). |
| [RFC3261] | Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” RFC 3261, June 2002 (TXT). |
| [I-D.ietf-sip-gruu] | Rosenberg, J., “Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP),” draft-ietf-sip-gruu-15 (work in progress), October 2007 (TXT). |
| [I-D.garcia-sipping-file-sharing-framework] | Garcia-Martin, M., Matuszewski, M., Beijar, N., and J. Lehtinen, “Sharing Files with the Session Initiation Protocol (SIP),” draft-garcia-sipping-file-sharing-framework-01 (work in progress), November 2007 (TXT). |
| TOC |
| Miguel A. Garcia-Martin | |
| Nokia Siemens Networks | |
| P.O.Box 22 | |
| Nokia Siemens Networks, FIN 02022 | |
| Finland | |
| Email: | miguel.garcia@nsn.com |
| Marcin Matuszewski | |
| Nokia | |
| P.O.Box 407 | |
| NOKIA GROUP, FIN 00045 | |
| Finland | |
| Email: | marcin.matuszewski@nokia.com |
| TOC |
Copyright © The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.