One document matched: draft-garcia-app-area-file-data-format-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<?rfc symrefs="yes" ?>
<rfc ipr="full3978" category="std">
<front>
<title abbrev="XML Data Format for Files">
An Extensible Data Format (XML) for Describing Files
</title>
<author initials="M" surname="Garcia-Martin" fullname="Miguel A. Garcia-Martin">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>P.O.Box 22</street>
<city>Nokia Siemens Networks</city> <region>FIN</region><code>02022</code>
<country>Finland</country>
</postal>
<email>miguel.garcia@nsn.com</email>
</address>
</author>
<author initials="M" surname="Matuszewski" fullname="Marcin Matuszewski">
<organization>Nokia</organization>
<address>
<postal>
<street>P.O.Box 407</street>
<city>NOKIA GROUP</city> <region>FIN</region><code>00045</code>
<country>Finland</country>
</postal>
<email>marcin.matuszewski@nokia.com</email>
</address>
</author>
<date day="9" month="November" year="2007" />
<area>Applications</area>
<keyword>file</keyword>
<keyword>format</keyword>
<keyword>XML</keyword>
<abstract>
<t>
This document defines an Extensible Data Format (XML) for
describing files.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
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 <xref
target="I-D.garcia-sipping-file-sharing-framework">Session
Initiation Protocol (SIP) file sharing framework </xref>,
which describes a usage of SIP for publishing file
metadata. Other usages, for example, based on the <xref
target="RFC2616">HyperText Transfer Protocol (HTTP) </xref>
have been also discussed, and it is expected that the growing
usage of XML in IETF protocols will increase the demand for
this format.
</t>
<t>
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.
</t>
</section>
<section title="Terminology">
<t>
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, <xref target="RFC2119">RFC 2119</xref> and indicate
requirement levels for compliant implementations.
</t>
</section>
<section title="The 'file-metadata' XML Document" anchor="file-metadata-document">
<t>
A 'file-metadata' document is an <xref
target="W3C.REC-xml-20001006">XML document </xref> 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 <xref
target="RFC3629">UTF-8 </xref>. This specification makes use of
XML namespaces for identifying 'file-metadata' documents. The
namespace URI for elements defined by this specification is a
<xref target="RFC2141"> URN </xref>, using the namespace
identifier 'ietf'. This URN is:
</t>
<t>
<list style='hanging'>
<t>
urn:ietf:params:xml:ns:file
</t>
</list>
</t>
<t>
The 'file-metadata' documents are identified with the MIME type
"application/file+xml" and are instances of the XML schema
defined in <xref target="schema" />.
</t>
<t>
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.
</t>
<t>
<list style="hanging">
<t>
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.
</t>
</list>
</t>
<t>
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 <xref
target="full-file-metadata-document"/> and <xref
target="partial-file-metadata-document"/>, respectively.
</t>
<section title="Full 'file-metadata' document"
anchor="full-file-metadata-document">
<t>
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 <xref
target="RFC3261">SIP </xref>, 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.
</t>
<!-- It seems that the 'version' attribute should only be
mandatory in notifications. In publications there isn't a
need for 'version', because the ETags do the same thing. We
shouldn't have two overlapping mechanisms that achieve the
same thing -->
<t>
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.
</t>
<t>
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.
</t>
<t>
The <timestamp< element contains a string indicating
when the document has been last updated. The value of this
element MUST follow the <xref target="RFC3339">IMPP datetime
format</xref>. 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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
The <identity> element contains an 'id' attribute whose
value MUST be unique within the XML document.
</t>
<t>
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.
</t>
<t>
The <urn> element contains a persistent,
location-independent, resource identifier expressed as a <xref
target="RFC2141"> Uniform Resource Name (URN) </xref> 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 <xref
target="RFC2141">RFC 2141 </xref>.
</t>
<t>
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.
</t>
<t>
The <size> element contains the file size in
octets.
</t>
<t>
The <sha1> element contains the results of a hashing
operation on the file. The hashing operation MUST be
computed using the <xref target="RFC3174"> US Secure Hash
Algorithm 1 (SHA1) </xref> and MUST be expressed in
hexadecimal format.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
The <uri> element contains either a location-dependent,
typically protocol-specific file identifier expressed as a
<xref target="RFC3986"> Uniform Resource Identifier (URI)
</xref>. The <uri> element can be, for example, an HTTP
or FTP URI.
</t>
<t>
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.
</t>
<t>
The <user-gruu> provides a SIP <xref
target="I-D.ietf-sip-gruu">Globally Routable User Agent URI
(GRUU) </xref> 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.
</t>
<t>
The <name> element contains the file name.
</t>
<t>
The <description> element contains a human readable text
describing the file.
</t>
<t>
The <iconptr> element contains a URI that points to an
icon that represents the file. This is typically
applicable to image or video files.
</t>
<t>
The <creation-date> element indicates the date and time
at which the file was created.
</t>
<t>
The <modification-date> element indicates the date and
time at which the file was last modified.
</t>
<t>
The <read-date> element indicates the date and time at
which the file was last read.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Partial 'file-metadata' document: patch operations"
anchor="partial-file-metadata-document">
<t>
A partial 'file-metadata' document begins with the root
element tag <patch> that describes a collection of <xref
target="I-D.ietf-simple-xml-patch-ops"> XML patch operations
</xref> 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.
</t>
<t>
The <patch> element consists of one or more child
<add>, <replace>, or <remove> elements whose
type definitions are included from the <xref
target="I-D.ietf-simple-xml-patch-ops">XML Patch Operations
</xref> identified with the namespace
"urn:ietf:params:xml:schema:xml-patch-ops".
</t>
<t>
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.
</t>
<t>
The <add> element is used to add new content to the
'file-metadata' document. The details of the <add>
element are discussed in the <xref
target="I-D.ietf-simple-xml-patch-ops">XML Patch Operations
</xref>.
</t>
<t>
The <replace> element is used to update content in the
'file-metadata' document. The details of the <replace>
element are discussed in the <xref
target="I-D.ietf-simple-xml-patch-ops">XML Patch Operations
</xref>.
</t>
<t>
The <remove> element is used to remove content from the
'file-metadata' document. The details of the <remove>
element are discussed in the <xref
target="I-D.ietf-simple-xml-patch-ops">XML Patch Operations
</xref>.
</t>
<t>
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.
</t>
</section>
<section title="XML Schema" anchor="schema">
<t>
Implementations according to this specification MUST comply to
the following XML schema that defines the constraints of the
'file-metadata' document:
</t>
<figure title="'file-metadata' document XML schema"
anchor="fig-schema">
<artwork>
<?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>
</artwork></figure>
</section>
<section title="Examples" anchor="sec-example">
<section title="Example of a full 'file-document' document">
<t>
<xref target="fig-example-full-1"/> is an example of a
'file-metadata' document.
</t>
<figure title="Example of a full 'file-metadata' document" anchor="fig-example-full-1"><artwork>
<?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>
</artwork></figure>
<t>
The example in <xref target="fig-example-full-1" /> 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.
</t>
</section>
<section title="Example of a partial 'file-metadata' document" anchor="file-metadata-example-partial-1">
<t>
<xref target="fig-example-partial-1" /> is an example
of a partial 'file-metadata' document.
</t>
<figure title="Example of a partial 'file-metadata' document" anchor="fig-example-partial-1"><artwork>
<?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>
</artwork></figure>
<t>
The example in <xref target="fig-example-partial-1" /> 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
<xref target="fig-example-full-1" /> results in a document
that contains the description of two files.
</t>
<t>
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 <xref
target="fig-example-full-1" />. The document replaces the
previous <timestamp> and <note> elements with
new values.
</t>
</section>
<section title="Example of a full 'file-metadata' document" anchor="file-example-full-2">
<t>
<xref target="fig-example-full-2" /> is an example of a
full 'file-metadata' document.
</t>
<figure title="Example of a full 'file-metadata' document" anchor="fig-example-full-2"><artwork>
<?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>
</artwork></figure>
<t>
The example in <xref target="fig-example-full-2" /> 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.
</t>
</section>
<section title="Example of a partial 'file-metadata' document" anchor="file-example-partial-2">
<t>
<xref target="fig-example-partial-2" /> is an example
of a partial 'file-metadata' document.
</t>
<figure title="Example of a partial 'file-metadata' document" anchor="fig-example-partial-2"><artwork>
<?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>
</artwork></figure>
<t>
<xref target="fig-example-partial-2" /> contains a
number of XML patch operations to be applied to the full
'file-metadata' document included in <xref
target="fig-example-full-2" />. The document in <xref
target="fig-example-partial-2" /> 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
<xref target="fig-example-full-2" />.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
<list style="hanging">
<t>
Note: the 'sel' attribute of the <replace> element
in <xref target="fig-example-partial-2" /> is split
in two lines due to formatting restrictions. It will
appear as a single line in XML documents.
</t>
</list>
</t>
</section>
</section>
</section>
<section title="Security Considerations" anchor="security">
<t>
TBD
</t>
</section>
<section title="IANA Considerations" anchor="iana">
<t>
TBD
</t>
<!-- Need to register the XML schema and namespace -->
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to
Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott
Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
</front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723'
target='ftp://ftp.isi.edu/in-notes/rfc2119.txt' />
<format type='HTML' octets='14486'
target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5661'
target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
<?rfc include="reference.RFC.2141"?>
<?rfc include="reference.RFC.3174"?>
<?rfc include="reference.RFC.3339"?>
<?rfc include="reference.RFC.3629"?>
<?rfc include="reference.RFC.3986"?>
<?rfc include="reference.W3C.REC-xml-20001006"?>
<?rfc include="reference.I-D.ietf-simple-xml-patch-ops"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.2616"?>
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.I-D.ietf-sip-gruu"?>
<?rfc include="reference.I-D.garcia-sipping-file-sharing-framework"?>
</references>
</back>
</rfc>
<!-- LocalWords: xref CDATA XML
-->
| PAFTECH AB 2003-2026 | 2026-04-23 14:30:48 |