One document matched: draft-ietf-sipping-capacity-attribute-05.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc symrefs="yes" ?>
<rfc ipr="full3978"
docName="draft-ietf-sipping-capacity-attribute-05.txt" category="std">
<front>
<title abbrev="Copy Control Attribute in Resource Lists">
Extensible Markup Language (XML) Format Extension for
Representing Copy Control Attributes in Resource Lists
</title>
<author initials="M." surname="Garcia-Martin" fullname="Miguel A. Garcia-Martin">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>P.O.Box 6</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="G." surname="Camarillo" fullname="Gonzalo Camarillo">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>Gonzalo.Camarillo@ericsson.com</email>
</address>
</author>
<date day="13" month="November" year="2007" />
<area>RAI</area>
<workgroup>SIPPING Working Group</workgroup>
<keyword>XML</keyword>
<keyword>copy</keyword>
<keyword>control</keyword>
<keyword>resource</keyword>
<keyword>list</keyword>
<abstract>
<t>
In certain types of multimedia communications, a Session Initiation
Protocol (SIP) request is distributed to a group of SIP User Agents
(UAs). The sender sends a single SIP request to a server which further
distributes the request to the group. This SIP request contains a list
of Uniform Resource Identifiers (URIs), which identify the recipients
of the SIP request. This URI-list is expressed as a resource list XML
document. This specification defines an XML extension to the XML
resource list format that allows the sender of the request to qualify
a recipient with a copy control level similar to the copy control
level of existing e-mail systems.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The <xref target="I-D.ietf-sipping-uri-services"> Framework and
Security Considerations for Session Initiation Protocol (SIP) URI-List
Services </xref> describes a generic framework for carrying Uniform
Resource Identifier (URI)-lists in <xref target="RFC3261">SIP </xref>
messages. Specifically, the document provides a common framework for
specific implementations of URI-list services, such as <xref
target="I-D.ietf-sip-uri-list-conferencing"> conferences initiated
with INVITE requests </xref> or <xref
target="I-D.ietf-sip-uri-list-message"> Multiple-recipient MESSAGE
requests </xref>.
</t>
<t>
Common to all URI-list services is the presence of a SIP request that
contains a collection of resources, typically expressed as an <xref
target="RFC4826">XML resource list
</xref>. SIP requests carrying resource lists can appear either in
requests received by the URI-list server, indicating the list of
intended recipients, or in each of the requests that the URI-list
server sends to recipients, indicating the list of recipients of the
same SIP request.
</t>
<t>
Although the <xref target="RFC4826">XML
resource list </xref> provides a powerful mechanism for describing
a list of resources, there is a need for a copy control attribute to
determine whether a resource is receiving a SIP request as a primary
recipient, a carbon copy, or a blind carbon copy. This is similar to
common e-mail systems, where the sender can categorize each recipient
as To, Cc, or Bcc recipient.
</t>
<t>
This document addresses this problem by providing an extension to the
<xref target="RFC4826">XML resource list </xref> that enables the
sender to supply a copy control attribute that labels each recipient
as a "to", "cc", or "bcc" recipient. This attribute indicates whether
the recipient is receiving a primary copy of the SIP request, a carbon
copy, or a blind carbon copy. Additionally, we provide the sender with
the capability of indicating in the URI-list that one or more
resources should be anonymized, so that some recipients' URIs are not
disclosed to the other recipients. Instead, these URIs are replaced
with anonymous URIs.
</t>
<t>
The remainder of this document is organized as follows: <xref
target="sec-terminology" /> introduces the terminology used throughout
this specification. <xref target="sec-overview" /> gives an overview
of operation. <xref target="sec-uri-list-extension" /> formally
defines an extension to URI-lists. The XML schema definition is
provided in <xref target="sec-xml-schema"/>. <xref
target="sec-examples" /> shows examples of the URI-lists with the
extensions defined in this document. <xref
target="sec-carrying-uri-lists" /> discusses the implications of
carrying URI-lists in SIP messages.
</t>
</section>
<section title="Terminology" anchor="sec-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>
<t>
<list style='hanging'>
<t hangText='URI-list service:'>
SIP application service that receives a SIP request containing a
URI-list and sends a similar SIP request to each URI in the
list.
<vspace blankLines="1" />
</t>
<t hangText='Intended recipient:'>
The intended final recipient of the request to be generated by
URI-list service.
<vspace blankLines="1" />
</t>
<t hangText='Copy control: '>
An attribute assigned by the sender to a URI in a XML resource
list. Its purpose is to indicate to the recipient whether he is
getting a primary, carbon, or blind carbon copy of the SIP
request.
<vspace blankLines="1" />
</t>
<t hangText='Recipient list or recipient XML resource list: '>
An XML resource list containing the list of intended
recipients. The sender sets this list in the SIP request he
sends to the URI-list server.
<vspace blankLines="1" />
</t>
<t hangText='Recipient-history list or recipient-history XML resource list: '>
An XML resource list containing the visible list of recipients
(i.e., those non-anonymous non-bcc). The URI-list server
creates this list, based on the recipient list, and includes it
in each of the SIP requests it sends to each recipient.
<vspace blankLines="1" />
</t>
</list>
</t>
</section>
<section title="Overview of operation" anchor="sec-overview">
<t>
<xref target="fig-example-flow" /> depicts a general overview of the
operation of a URI-list server. A SIP User Agent Client (UAC) issuer
sends a SIP request (F1) to a URI-list server containing a recipient
list. The URI-list server generates a SIP request to each recipient,
according to the specific SIP method. Each of these SIP requests
contains a recipient-history list that indicates the visible list of
recipients of the SIP request.
</t>
<figure anchor="fig-example-flow" title="Example of
operation"><artwork><![CDATA[
+--------+ +---------+ +--------+ +--------+ +--------+
|SIP UAC | | URI-list| |intended| |intended| |intended|
| issuer | | server | | recip. | | recip. | | recip. |
| | | | | 1 | | 2 | | 3 |
+--------+ +---------+ +--------+ +--------+ +--------+
| | | | |
| F1. SIP request | | | |
| (recipt. list) | | | |
| ---------------->| | | |
| F2. 2xx response | | | |
|<---------------- | F3. SIP request | | |
| | (recp-hist.list)| | |
| | --------------->| | |
| | F4. SIP request | | |
| | (recp-hist.list)| | |
| | -------------------------->| |
| | F5. SIP request | | |
| | (recp-hist.list)| | |
| | ------------------------------------->|
| | F6. 200 OK | | |
| |<--------------- | | |
| | F7. 200 OK | | |
| |<-------------------------- | |
| | F8. 200 OK | | |
| |<------------------------------------- |
| | | | |
| | | | |
| | | | |
]]></artwork></figure>
<t>
The URI-list mechanism allows a sender to specify multiple targets for
a SIP request by including a recipient <xref
target="RFC4826">XML resource list </xref> in
the body of the SIP request. This recipient list includes the target
URIs of the SIP request (the actual procedures are method specific and
outside the scope of this document). Each target URI may also be
marked with a copy control attribute to indicate the copy level in
which the recipient is receiving the SIP request. This is achieved by
the sender qualifying each URI in the URI-list with a 'copyControl'
attribute. The available values of the 'copyControl' attribute include
"to", "cc", and "bcc" (analogous to e-mail). This is discussed in
greater detailed in <xref target="sec-uri-list-extension" />. When the
URI-list server expands the request to each recipient, the URI-list
server includes a recipient-history XML resource list built upon the
recipient list received from the sender. The recipient-history XML
resource list replaces the recipient list in the SIP requests
generated by the URI-list server towards each recipient. The URI-list
server copies from the recipient list those targets which are marked
with the "to" and "cc" copy control level, and pastes them in the
recipient-history list. The URI-list server explicitly excludes from
the copy those URIs marked with a "bcc" copy control. When a recipient
receives the SIP request containing the recipient-history XML resource
list, he is able to determine which other visible recipients are
getting the same SIP requests, and whether they are marked with the
"to" or "cc" copy control level. Later, if needed, the recipient can
generate a reply to those visible recipients.
</t>
<t>
In addition to the 'copyControl' attribute for a URI in an XML
resource list, we define a second boolean attribute called
'anonymize'. The sender of a SIP request can mark a URI in a recipient
XML resource list with the 'anonymize' attribute to indicate the
URI-list server that the URI marked with that attribute is to be
replaced with an anonymous URI in the recipient-history XML resource
list. This provides knowledge to the recipients of a SIP request of
the number of additional visible recipients whose URIs have not been
disclosed.
</t>
<t>
There are cases when the sender marks several URIs with the
'anonymize' attribute. The URI-list server can group the anonymized
URIs in a single anonymized URI within its copy control level, and
provide a count of the number of anonymized URIs. To support this
scenario, we define a new 'count' attribute to a URI in the
recipient-history XML resource list. It is expected that the 'count'
attribute is only used with anonymous URIs, although syntactically it
is possible to add a 'count' attribute to any URI in any XML resource
list.
</t>
<t>
Initially, it may be thought that the 'anonymize' attribute overlaps
with the "bcc" value of the 'copyControl' attribute. However, there
are differences between them. If the sender qualifies a URI with a
'copyControl' attribute of "bcc" in the recipient XML resource list,
the URI-list server will completely remove that URI from the
recipient-history XML resource list. Recipients of the SIP request
will not notice that one or more extra URIs also received the
request. However, if the sender qualifies a URI with the 'anonymize'
attribute in the recipient XML resource list, the URI-list server will
replace the URI with an anonymous one in the recipient-history
list. Recipients of the SIP request will notice that there have been
one or more additional recipients of the same request, but their URIs
have not been disclosed.
</t>
</section>
<section title="Extension to the resource lists data format"
anchor="sec-uri-list-extension">
<t>
This document defines an extension to the <xref
target="RFC4826"> XML resource list data
format </xref> that allows the sender to indicate a copy control
attribute that qualifies a recipient with a copy control level. We
define a new 'copyControl' attribute to the <entry> element of
the <xref target="RFC4826"> resource list
document format </xref>. The 'copyControl' attribute has similar
semantics to the type of destination address in e-mail systems. It can
take the values "to", "cc", and "bcc". A "to" value of the
'copyControl' attribute indicates that the resource is considered a
primary recipient of the SIP request. A "cc" value indicates that the
resource receives a carbon copy of the SIP request. A "bcc" value
indicates that the resource receives a blind carbon copy of the SIP
request (i.e., this URI is not disclosed in the recipient-history
list). The default 'copyControl' value is "bcc". That is, the absence
of a 'copyControl' attribute MUST be treated as if the 'copyControl'
was set to "bcc". URI-list servers use URIs marked with the "bcc"
'copyControl' attribute to route SIP requests, but MUST NOT include
them in recipient-history lists.
</t>
<t>
A new 'anonymize' attribute can be included in a <entry> element
of the <xref target="RFC4826"> resource list
document format </xref>. If set to a "true" value, it provides an
indication to the URI-list server for not disclosing the URI itself in
a URI-list sent to the recipient, but instead, to anonymize the URI
(i.e., making it bogus in the recipient-history XML resource
list). URI-list servers can use URIs tagged with the 'anonymize'
attribute for routing SIP requests, but MUST convert them to an
anonymized URI (such as sip:anonymous@anonymous.invalid) in
recipient-history lists. The default value of the 'anonymize'
attribute is "false".
</t>
<t>
There are occasions where the URI-list server encounters the same URI
entry duplicated in a resource list, where duplicated URI entries are
tagged with the same or different values of the 'copyControl'
attribute. There are no reasonable usages that justify duplicated URIs
in resource lists, thus, this is considered an error. URI-list servers
should not send duplicated copies of the same SIP request to the same
intended recipient. In case the URI-list server encounters the same
URI entry duplicated in a resource list, it should send at most a single
copy of the request to that intended recipient. For each set of
duplicated URI entries, the URI-list server MUST select the highest
precedence value of the 'copyControl' attribute for the same intended
recipient. The order of precedence of the values of the 'copyControl'
attribute is: "to", "cc", and "bcc". Once the URI-list server has
selected a value for the 'copyControl' attribute of an intended
recipient, the URI-list can continue processing the request.
</t>
<t>
Processing of URIs tagged with a 'copyControl' attribute set to a
"bcc" value has higher precedence over the 'anonymize'
attribute. Thus, if the 'copyControl' of a URI is set to "bcc", the
URI-list server MUST remove that URI from the recipient-history list,
and the 'anonymize' attribute will be ignored. Therefore, the
'anonymize' attribute is only useful for those URIs tagged with a
'copyControl' of "to" or "cc".
</t>
<t>
A new 'count' attribute can be also included in a <entry>
element of the <xref target="RFC4826">
resource list document format </xref>. It provides the number of equal
URIs. Typically, recipient lists created by UACs will not have equal
(or duplicate) URI entries, thus, it is not expected to contain URIs
tagged with 'count' attributes. However, recipient-history lists can
contain duplicated anonymized URIs, therefore, it is expected that
recipient-history lists will contain 'count' attributes. The default
value of the 'count' attribute is "1".
</t>
<t>
The 'copyControl', 'anonymize', and 'count' attributes SHOULD be included
as modifiers of any of the child elements included in the
<list> element of a resource list (e.g., attribute of the
<entry> or <external> elements).
</t>
<t>
<xref target="sec-xml-schema" /> describes the format of the
'copyControl', 'anonymize', and 'count' attributes. Implementations
according to this specification MUST support this XML Schema.
</t>
</section>
<section title="XML Schema" anchor="sec-xml-schema">
<figure anchor="fig-xml-schema" title="XML Schema of the extension to
the resource list format">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:copycontrol"
xmlns="urn:ietf:params:xml:ns:copycontrol"
xmlns:rls="urn:ietf:params:xml:ns:resource-lists"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:documentation xml:lang="en">
Adds the copyControl, anonymize, and count attributes
to URIs included in a resource list.
</xs:documentation>
</xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:resource-lists"
schemaLocation="urn:ietf:params:xml:schema:resource-lists"/>
<xs:attribute name="copyControl">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="to"/>
<xs:enumeration value="cc"/>
<xs:enumeration value="bcc"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="anonymize" type="xs:boolean" default="false"/>
<xs:attribute name="count" type="xs:nonNegativeInteger"
default="1"/>
</xs:schema>
]]></artwork></figure>
</section>
<section title="Examples" anchor="sec-examples">
<t>
This section shows two examples of URI-lists that can be included in
SIP requests. The first example in <xref target="fig-sender-list" />
shows a recipient list that the UAC sends to the URI-list server. This
corresponds to a list that will be included in the flow F2 in <xref
target="fig-example-flow" />. The recipient list contains a flat list
according to the resource list data format specified in <xref
target="RFC4826">RFC 4826 </xref>. Each resource indicates the copy
control of a resource with a 'copyControl' attribute. Some of the
resources are also marked with the 'anonymize' attribute. This
provides an indication to the URI-list service for not disclosing
their URIs in a recipient-history list. The last two <entry>
elements are marked with a 'copyControl' attribute of "bcc". This
provides an indication to the URI-list server for removing these URIs
in the recipient-history list.
</t>
<figure anchor="fig-sender-list" title="Recipient list sent from the UAC to
the URI-list server"> <artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
<list>
<entry uri="sip:bill@example.com" cp:copyControl="to" />
<entry uri="sip:randy@example.net" cp:copyControl="to"
cp:anonymize="true"/>
<entry uri="sip:eddy@example.com" cp:copyControl="to"
cp:anonymize="true"/>
<entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:carol@example.net" cp:copyControl="cc"
cp:anonymize="true"/>
<entry uri="sip:ted@example.net" cp:copyControl="bcc" />
<entry uri="sip:andy@example.com" cp:copyControl="bcc" />
</list>
</resource-lists>
]]></artwork></figure>
<t>
Upon receipt of the SIP request containing the recipient list of <xref
target="fig-sender-list" /> the URI-list server creates a SIP request
to each of the URIs listed in the recipient list (so, in our example,
it creates 7 SIP requests). The URI-list server processes the
recipient list and creates a recipient-history list that is included
in each of the outgoing SIP requests. The process is as follows: the
URI-list server creates a new recipient-history list, based on the
recipient list, but with changes. First it copies all the URIs
(<entry> elements) marked with the "to" or "cc" 'copyControl'
attributes, which do not contain an 'anonymize' attribute (or when the
'anonymize' attribute is set to "false"). Then all the URIs marked
with a 'copyControl' attribute set to "to" and 'anonymize' attribute
set to "true" are replaced with an anonymous URI, such as
"sip:anonymous@anonymous.invalid". In this entry the URI-list server
also adds the original value of the 'copyControl' attribute ("to" in
our example), and it adds a 'count' attribute containing the number of
anonymous entries in this group ("2" in our example). Then the
URI-list server does the same operation to the URIs tagged with the
'copyControl' attribute set to "cc" and 'anonymize' attribute set to
"true", adding also the 'count' attribute containing the number of
anonymous attributes in this group ("1" in the example). Last, the
URI-list server completely removes URIs marked with the "bcc"
'copyControl' attribute. The resulting recipient-history list is shown
in <xref target="fig-recipients-list" />.
</t>
<figure anchor="fig-recipients-list"
title="Recipient-history list sent from the URI-list server to each recipient">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
<list>
<entry uri="sip:bill@example.com" cp:copyControl="to" />
<entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="to"
cp:count="2"/>
<entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="cc"
cp:count="1"/>
</list>
</resource-lists>
]]></artwork></figure>
</section>
<section title="Carrying URI-lists in SIP"
anchor="sec-carrying-uri-lists">
<t>
A SIP UAC (User Agent Client) that composes a SIP request can include
a URI-list with the extensions specified in this document to indicate
the list of intended recipients. On doing so, as specified in the
<xref target="I-D.ietf-sipping-uri-services"> Framework and Security
Considerations for SIP URI-List Services </xref>, the UAC adds a <xref
target="RFC2183">Content-Disposition </xref> header field set to the
value 'recipient-list'. Typically UACs send these 'recipient-list'
bodies to URI-list services (this corresponds to flow F1 in <xref
target="fig-example-flow" />). A body whose Content-Disposition type
is 'recipient-list' contains a URI-list that includes the intended
recipients of the SIP request, something known throughout this
document as a recipient list. The <entry> element in the
URI-list MAY also include a 'copyControl' and 'anonymize' attributes,
as specified in <xref target="sec-uri-list-extension" />.
</t>
<t>
To be able to inform intended recipients of who else is receiving a
copy of the SIP request, we define a new mail disposition type to be
included in a <xref target="RFC2183"> Content-Disposition </xref>
header field of a SIP request. The value of this new disposition type
is 'recipient-list-history' and its purpose is to indicate a list of
recipients that a SIP request was sent to, something known throughout
this document as a recipient-history list. A body whose
Content-Disposition type is 'recipient-list-history' contains a
URI-list with the visible (including anonymized) recipients of the SIP
request. The <entry> element in the URI-list MAY also include a
'copyControl' and 'count' attributes, as specified in <xref
target="sec-uri-list-extension" />.
</t>
<t>
On sending a SIP request that contains a recipient-history list, if
the intended recipient does not support this specification, the SIP
request should not fail. In order to ensure successful receipt of the
SIP requests that include 'recipient-list-history' bodies, User Agents
(such as URI-list servers) that build SIP requests with the
Content-Disposition header field set to 'recipient-list-history'
SHOULD add a <xref target="RFC3204"> 'handling' parameter </xref> set
to "optional". Otherwise, the SIP request could fail and never be
received by the intended recipient.
</t>
<t>
Even though <xref target="I-D.ietf-sip-body-handling"> Message Body
Handling in SIP </xref> mandates support for multipart bodies, legacy
recipients may not support them. In such a case, if the request sent
by the relay to the recipient needs to contain another body (e.g., a
MESSAGE request carrying a message in its body), the relay will not be
able to use this extension because the recipient would not be able to
process a multipart body with the original body plus the
'recipient-list-history' body.
</t>
</section>
<section title="Security Considerations"
anchor="sec-security">
<t>
The <xref target="I-D.ietf-sipping-uri-services"> Framework and
Security Considerations for SIP URI-List Services </xref> discusses
issues related to SIP URI-list services. Implementations of this
specification MUST follow the security-related rules in the <xref
target="I-D.ietf-sipping-uri-services"> Framework and Security
Considerations for SIP URI-List Services</xref>. These rules include
mandatory authentication and authorization of clients, and opt-in
lists.
</t>
<t>
User Agent Clients SHOULD NOT hand SIP requests containing URI-list
services to unauthenticated and untrusted parties. This is to avoid
man-in-the-middle attacks or acquiring URI-lists for performing SPAM
attacks.
</t>
<t>
URI-lists may contain private information, such as SIP URIs. It is
therefore not desirable that these URI-lists are known by third
parties. Eavesdroppers are able to watch URI-lists contained in SIP
requests unless the SIP message is sent over a secured channel, by
using any of the available SIP mechanisms, such as <xref
target="RFC4346">Transport Layer Security (TLS) </xref>, or unless the
URI-list body itself is encrypted with, e.g., <xref
target="RFC3851">S/MIME</xref>. Therefore, it is RECOMMENDED that
URI-list bodies are encrypted with <xref
target="RFC3851">S/MIME</xref> or that the SIP request is encrypted
with <xref target="RFC4346">TLS</xref> or any other suitable
encryption mechanism.
</t>
<t>
Note that this URI-list does not indicate the actual participants in the
session. It indicates only the URIs invited and that might accept the
request. It does not assert that these parties actually exist, that
they are reachable at the given URI, or that they have accepted the
invitation. No inferences about billing should be made from this
information. It is subject to spoofing by loading the list with
falsified content.
</t>
</section>
<section title="IANA Considerations" anchor="iana">
<t>
The following sections instruct the IANA to register: a new disposition
type, a new XML namespace, and a new XML schema.
</t>
<section title="Disposition Type Registration" anchor="iana-disp">
<t>
<xref target="sec-carrying-uri-lists" /> defines a new
'recipient-list-history' value of the Mail Content Disposition Values
registry. This value should be registered in the IANA registry of
Mail Content Disposition Values with the following registration
data:
</t>
<texttable anchor="ianatable" title="Registration of the
'recipient-list-history' Mail Content Disposition Value">
<ttcol width="37%">Name</ttcol>
<ttcol>Description</ttcol>
<ttcol width="15%" align="center">Reference</ttcol>
<c>recipient-list-history</c>
<c>the body contains a list of URIs that indicates the recipients of
the SIP request</c>
<c>[RFCXXXX]</c>
</texttable>
<t>Note to IANA and the RFC editor: replace RFCXXXX above with the RFC
number of this specification.</t>
</section>
<section title="XML Namespace Registration">
<t>
This section registers a new XML namespace in the IANA XML
registry, as per the guidelines in <xref target="RFC3688">RFC
3688 </xref>.
</t>
<t>
URI: The URI for this namespace is
urn:ietf:params:xml:ns:copycontrol
</t>
<t>
Registrant Contact: IETF, SIPPING working group, (sipping@ietf.org),
Miguel Garcia-Martin (miguel.an.garcia@nokia.com).
</t>
<t>
XML:
</t>
<figure><artwork><![CDATA[
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Copy Control Namespace</title>
</head>
<body>
<h1>Namespace for the Copy Control Attribute Extension
in Resource Lists</h1>
<h2>urn:ietf:params:xml:ns:copycontrol</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX
[NOTE TO IANA/RFC-EDITOR: Please replace XXXX with
the RFC number of this specification.]</a>.</p>
</body>
</html>
END
]]>
</artwork></figure>
</section>
<section title="XML Schema Registration">
<t>
This section registers a new XML schema in the IANA XML
registry per the procedures in <xref target="RFC3688">RFC 3688
</xref>.
</t>
<t>
URI: urn:ietf:params:xml:schema:copycontrol
</t>
<t>Registrant Contact: IETF, SIPPING working group, (sipping@ietf.org),
Miguel Garcia-Martin (miguel.an.garcia@nokia.com).
</t>
<t>
The XML for this schema can be found as the sole content of <xref
target="sec-xml-schema" />.
</t>
</section>
</section>
<section title="Acknowledgements">
<t>
Thanks to Dean Willis, Jari Urpalainen, Pekka Kuure, Atsushi Sato,
Brian Rosen, Mary Barnes, and James Polk for reviewing this document
and providing helpful comments.
</t>
</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.2183" ?>
<?rfc include="reference.RFC.3204"?>
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.RFC.3688"?>
<?rfc include="reference.RFC.3851"?>
<?rfc include="reference.RFC.4346"?>
<?rfc include="reference.RFC.4826"?>
<?rfc include="reference.I-D.ietf-sipping-uri-services" ?>
</references>
<references title="Informational References">
<?rfc include="reference.I-D.ietf-sip-uri-list-conferencing" ?>
<?rfc include="reference.I-D.ietf-sip-uri-list-message" ?>
<?rfc include="reference.I-D.ietf-sip-body-handling" ?>
</references>
</back>
</rfc>
<!-- LocalWords: xref CDATA exploders BUA -->
| PAFTECH AB 2003-2026 | 2026-04-24 01:07:55 |