draft-ietf-mediactrl-mrb-14.txt   draft-ietf-mediactrl-mrb-15.txt 
Network Working Group C. Boulton Network Working Group C. Boulton
Internet-Draft NS-Technologies Internet-Draft NS-Technologies
Intended status: Standards Track L. Miniero Intended status: Standards Track L. Miniero
Expires: February 21, 2013 Meetecho Expires: April 8, 2013 Meetecho
G. Munson G. Munson
AT&T AT&T
August 20, 2012 October 5, 2012
Media Resource Brokering Media Resource Brokering
draft-ietf-mediactrl-mrb-14 draft-ietf-mediactrl-mrb-15
Abstract Abstract
The MediaCtrl work group in the IETF has proposed an architecture for The MediaCtrl work group in the IETF has proposed an architecture for
controlling media services. The Session Initiation Protocol (SIP) is controlling media services. The Session Initiation Protocol (SIP) is
used as the signalling protocol which provides many inherent used as the signalling protocol which provides many inherent
capabilities for message routing. In addition to such signalling capabilities for message routing. In addition to such signalling
properties, a need exists for intelligent, application level media properties, a need exists for intelligent, application level media
service selection based on non-static signalling properties. This is service selection based on non-static signalling properties. This is
especially true when considered in conjunction with deployment especially true when considered in conjunction with deployment
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on February 21, 2013. This Internet-Draft will expire on April 8, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 46 skipping to change at page 2, line 46
5.2.4. <mrbconsumer> . . . . . . . . . . . . . . . . . . . . 39 5.2.4. <mrbconsumer> . . . . . . . . . . . . . . . . . . . . 39
5.2.5. Media Service Resource Request . . . . . . . . . . . 39 5.2.5. Media Service Resource Request . . . . . . . . . . . 39
5.2.6. Media Service Resource Response . . . . . . . . . . . 51 5.2.6. Media Service Resource Response . . . . . . . . . . . 51
5.3. In-Line Unaware MRB Interface . . . . . . . . . . . . . 54 5.3. In-Line Unaware MRB Interface . . . . . . . . . . . . . 54
6. MRB acting as a B2BUA . . . . . . . . . . . . . . . . . . . . 56 6. MRB acting as a B2BUA . . . . . . . . . . . . . . . . . . . . 56
7. Multi-modal MRB Implementations . . . . . . . . . . . . . . . 57 7. Multi-modal MRB Implementations . . . . . . . . . . . . . . . 57
8. Relative Merits of Query Mode, IAMM, and IUMM . . . . . . . . 58 8. Relative Merits of Query Mode, IAMM, and IUMM . . . . . . . . 58
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 60 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 60
9.1. Publish Example . . . . . . . . . . . . . . . . . . . . 60 9.1. Publish Example . . . . . . . . . . . . . . . . . . . . 60
9.2. Consumer Example . . . . . . . . . . . . . . . . . . . . 65 9.2. Consumer Example . . . . . . . . . . . . . . . . . . . . 65
9.2.1. Query Example . . . . . . . . . . . . . . . . . . . . 66 9.2.1. Query Example . . . . . . . . . . . . . . . . . . . . 65
9.2.2. IAMM Example . . . . . . . . . . . . . . . . . . . . 68 9.2.2. IAMM Example . . . . . . . . . . . . . . . . . . . . 68
10. Media Service Resource Publisher Interface XML Schema . . . . 84 10. Media Service Resource Publisher Interface XML Schema . . . . 84
11. Media Service Resource Consumer Interface XML Schema . . . . 107 11. Media Service Resource Consumer Interface XML Schema . . . . 107
12. Security Considerations . . . . . . . . . . . . . . . . . . . 128 12. Security Considerations . . . . . . . . . . . . . . . . . . . 128
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 131 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 131
13.1. Media Control Channel Framework Package Registration . . 131 13.1. Media Control Channel Framework Package Registration . . 131
13.2. application/mrb-publish+xml Media Type . . . . . . . . . 131 13.2. application/mrb-publish+xml Media Type . . . . . . . . . 131
13.3. application/mrb-consumer+xml MIME Type . . . . . . . . . 132 13.3. application/mrb-consumer+xml Media Type . . . . . . . . 132
13.4. URN Sub-Namespace Registration for mrb-publish . . . . . 133 13.4. URN Sub-Namespace Registration for mrb-publish . . . . . 133
13.5. URN Sub-Namespace Registration for mrb-consumer . . . . 133 13.5. URN Sub-Namespace Registration for mrb-consumer . . . . 133
13.6. XML Schema Registration for mrb-publish . . . . . . . . 133 13.6. XML Schema Registration for mrb-publish . . . . . . . . 133
13.7. XML Schema Registration for mrb-consumer . . . . . . . . 134 13.7. XML Schema Registration for mrb-consumer . . . . . . . . 134
14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
14.1. Changes from 13 Version . . . . . . . . . . . . . . . . 135 14.1. Changes from 13 Version . . . . . . . . . . . . . . . . 135
14.2. Changes from 12 Version . . . . . . . . . . . . . . . . 135 14.2. Changes from 12 Version . . . . . . . . . . . . . . . . 135
14.3. Changes from 11 Version . . . . . . . . . . . . . . . . 135 14.3. Changes from 11 Version . . . . . . . . . . . . . . . . 135
14.4. Changes from 10 Version . . . . . . . . . . . . . . . . 135 14.4. Changes from 10 Version . . . . . . . . . . . . . . . . 135
14.5. Changes from 09 Version . . . . . . . . . . . . . . . . 136 14.5. Changes from 09 Version . . . . . . . . . . . . . . . . 136
skipping to change at page 31, line 27 skipping to change at page 31, line 27
to allow arbitrary values to be returned to allow arbitrary to allow arbitrary values to be returned to allow arbitrary
classification. The element MAY be present. classification. The element MAY be present.
The <label> element has no attributes. The <label> element has no attributes.
The <label> element has no child elements. The <label> element has no child elements.
5.1.5.20. <media-server-address> 5.1.5.20. <media-server-address>
The <media-server-address> element allows a Media Server to provide a The <media-server-address> element allows a Media Server to provide a
direct SIP URI address where it can be reached (e.g., the URI direct SIP URI where it can be reached (e.g., the URI Application
Application Server would call to in order to set-up a Control Channel Server would call to in order to set-up a Control Channel and relay
and relay SIP media dialogs). The element MAY be present. SIP media dialogs). The element MAY be present.
The <media-server-address> element has a single attribute. The <media-server-address> element has a single attribute.
The <media-server-address> element has no child elements. The <media-server-address> element has no child elements.
5.1.5.21. <encryption> 5.1.5.21. <encryption>
The <encryption> element allows a Media Server to declare support for The <encryption> element allows a Media Server to declare support for
encrypting RTP media streams using RFC 3711 [RFC3711]. The element encrypting RTP media streams using RFC 3711 [RFC3711]. The element
MAY be present. MAY be present.
skipping to change at page 33, line 26 skipping to change at page 33, line 26
operations required to request and then receive information from an operations required to request and then receive information from an
MRB, by making use of SIP [RFC3261] as transport for a request for MRB, by making use of SIP [RFC3261] as transport for a request for
media resources and the appropriate response when used with IAMM of media resources and the appropriate response when used with IAMM of
operation (as discussed in Section 5.2.2.1). operation (as discussed in Section 5.2.2.1).
Use of IAMM, besides having the MRB select appropriate media Use of IAMM, besides having the MRB select appropriate media
resources on behalf of a client application, includes setting up resources on behalf of a client application, includes setting up
either a Control Framework control channel between an application either a Control Framework control channel between an application
server and one of the media servers (Section 5.2.2.1) or a media server and one of the media servers (Section 5.2.2.1) or a media
dialog session between an application server and one of the media dialog session between an application server and one of the media
servers (Section 5.2.2.2). Note that in either case the SIP servers (Section 5.2.2.2). Note that in either case the SIP URIs of
addresses of the selected media servers are made known to the the selected media servers are made known to the requesting
requesting application server in the SIP 200 OK response by means of application server in the SIP 200 OK response by means of one or more
one or more <media-server-address> child elements in the <response- <media-server-address> child elements in the <response-session-info>
session-info> element (Section 5.2.6). element (Section 5.2.6).
5.2.2.1. IAMM and Setting up a Control Framework Control Channel 5.2.2.1. IAMM and Setting up a Control Framework Control Channel
The media resource request information, as defined by the The media resource request information, as defined by the
<mediaResourceRequest> element from Section 11, is carried in a SIP <mediaResourceRequest> element from Section 11, is carried in a SIP
INVITE request. The INVITE request will be constructed as it would INVITE request. The INVITE request will be constructed as it would
have been to connect to a Media Server, as defined by the Media have been to connect to a Media Server, as defined by the Media
Control Channel Framework [RFC6230]. It should be noted that this Control Channel Framework [RFC6230]. It should be noted that this
specification does not exclude the use of an offer-less INVITE as specification does not exclude the use of an offer-less INVITE as
defined in RFC3261 [RFC3261]. Using offer-less INVITE messages to an defined in RFC3261 [RFC3261]. Using offer-less INVITE messages to an
skipping to change at page 37, line 11 skipping to change at page 37, line 11
and MRB to correlate future media resource requests related to an and MRB to correlate future media resource requests related to an
initial media resource request. The <session-id> MUST be included initial media resource request. The <session-id> MUST be included
in all future related requests (see <session-id> use later in this in all future related requests (see <session-id> use later in this
section when constructing a subsequent request). section when constructing a subsequent request).
o <seq> is a numeric value returned to the Consumer client. On o <seq> is a numeric value returned to the Consumer client. On
issuing any future requests related to the media resource session issuing any future requests related to the media resource session
(as determined by the <session-id> element) the consumer client (as determined by the <session-id> element) the consumer client
MUST increment the value returned in the <seq> element and include MUST increment the value returned in the <seq> element and include
in the request (see <seq> use later in this section when in the request (see <seq> use later in this section when
constructing a subsequent request). constructing a subsequent request). Its value is a non-negative
integer, which MUST be limited within the 0..2^31-1 range.
o <expires> provides a value which provides the number of seconds o <expires> provides a value which provides the number of seconds
the request for media resources is deemed alive. The Consumer the request for media resources is deemed alive. The Consumer
client should issue a refresh of the request, as discussed later client should issue a refresh of the request, as discussed later
in this section, if the expires timer is due to fire and the media in this section, if the expires timer is due to fire and the media
resources are still required. resources are still required.
o <media-server-address> provides information representing an o <media-server-address> provides information representing an
assigned Media Server. More instances of this element may appear, assigned Media Server. More instances of this element may appear,
should the MRB assign more Media Servers to a Consumer request. should the MRB assign more Media Servers to a Consumer request.
skipping to change at page 37, line 49 skipping to change at page 37, line 50
o <seq> is a numeric value returned to Consumer client in the o <seq> is a numeric value returned to Consumer client in the
initial request for media resources, as discussed earlier in this initial request for media resources, as discussed earlier in this
section (<seq> element included as part of the <session-info> section (<seq> element included as part of the <session-info>
element in the initial <mediaResourceResponse>). On issuing any element in the initial <mediaResourceResponse>). On issuing any
future requests related to the specific media resource session (as future requests related to the specific media resource session (as
determined by the <session-id> element) the consumer client MUST determined by the <session-id> element) the consumer client MUST
increment the value returned in the <seq> element from the initial increment the value returned in the <seq> element from the initial
response (contained in the <mediaResourceResponse>) for every new response (contained in the <mediaResourceResponse>) for every new
request. The value of the <seq> element in requests acts as a request. The value of the <seq> element in requests acts as a
counter to and in conjunction with the unique <session-id> allows counter to and in conjunction with the unique <session-id> allows
for unique identification of a request. The first numeric value for unique identification of a request. As anticipated before,
for the <seq> element is not meant to be '1', but SHOULD be the value of a <seq> value is limited to the 0..2^31-1 range: in
generated randomly by the MRB: this is to reduce the chances a the unlikely case the counter increases to reach the highest
malicious MRB disrupts the session created by this MRB, as allowed value, the <seq> value MUST be set to 0. The first
explained in Section 12. numeric value for the <seq> element is not meant to be '1', but
SHOULD be generated randomly by the MRB: this is to reduce the
chances a malicious MRB disrupts the session created by this MRB,
as explained in Section 12.
o <action> element provides the operation to be carried out by the o <action> element provides the operation to be carried out by the
MRB on receiving the request: MRB on receiving the request:
* The value of 'update' is a request by the Consumer client to * The value of 'update' is a request by the Consumer client to
update the existing session at the MRB with alternate media update the existing session at the MRB with alternate media
resource requirements. If the requested resource information resource requirements. If the requested resource information
is identical to the existing MRB session, the MRB will attempt is identical to the existing MRB session, the MRB will attempt
a session refresh. If the information has changed, the MRB a session refresh. If the information has changed, the MRB
will attempt to update the existing session with the new will attempt to update the existing session with the new
skipping to change at page 40, line 31 skipping to change at page 40, line 36
<session-id>: is a unique identifier that explicitly references an <session-id>: is a unique identifier that explicitly references an
existing media resource session on the MRB. The identifier is existing media resource session on the MRB. The identifier is
included to update the existing session and is described in more included to update the existing session and is described in more
detail in Section 5.2.3. detail in Section 5.2.3.
<seq>: is used in association with the <session-id> element in a <seq>: is used in association with the <session-id> element in a
subsequent request to update an existing media resource session on subsequent request to update an existing media resource session on
an MRB. The <seq> number is incremented from its original value an MRB. The <seq> number is incremented from its original value
returned in response to the initial request for media resources. returned in response to the initial request for media resources.
More information about its use is provided in Section 5.2.3. Its value is a non-negative integer, which MUST be limited within
the 0..2^31-1 range. In the unlikely case the counter increases
to reach the highest allowed value, the <seq> value MUST be set to
0. More information about its use is provided in Section 5.2.3.
<action>: provides the operation that should be carried out on an <action>: provides the operation that should be carried out on an
existing media resource session on an MRB: existing media resource session on an MRB:
* The value of 'update' instructs the MRB to attempt to update * The value of 'update' instructs the MRB to attempt to update
the existing media resource session with the information the existing media resource session with the information
contained in the <ivrInfo> and <mixerInfo> elements. contained in the <ivrInfo> and <mixerInfo> elements.
* The value of 'remove' instructs the MRB to attempt to remove * The value of 'remove' instructs the MRB to attempt to remove
the existing media resource session. More information on its the existing media resource session. More information on its
skipping to change at page 55, line 13 skipping to change at page 55, line 18
With IUMM, the MRB may conclude that an assigned media resource is no With IUMM, the MRB may conclude that an assigned media resource is no
longer needed when it receives a SIP BYE from the application server longer needed when it receives a SIP BYE from the application server
or media server that ends that SIP dialog that initiated the request. or media server that ends that SIP dialog that initiated the request.
As with IAMM, in IUMM the SIP INVITE from the Application Server As with IAMM, in IUMM the SIP INVITE from the Application Server
could convey application/sdp payload to either set up a media dialog could convey application/sdp payload to either set up a media dialog
or a Control Framework control channel. In either case, in order to or a Control Framework control channel. In either case, in order to
permit the Application Server to associate a media dialog with a permit the Application Server to associate a media dialog with a
control channel to the same Media Server, using the procedures of control channel to the same Media Server, using the procedures of
[RFC6230] section 6, the MRB should be acting as a SIP proxy (and not [RFC6230] section 6, the MRB should be acting as a SIP proxy (and not
a B2BUA). This allows the SIP address of the targeted Media Server a B2BUA). This allows the SIP URI of the targeted Media Server to be
to be transparently passed back to the Application Server in the SIP transparently passed back to the Application Server in the SIP
response resulting in a SIP dialog directly between the Application response resulting in a SIP dialog directly between the Application
Server and the Media Server. Server and the Media Server.
While IUMM has the least impact on legacy application servers, it While IUMM has the least impact on legacy application servers, it
also provides the least versatility. See Section 8. also provides the least versatility. See Section 8.
6. MRB acting as a B2BUA 6. MRB acting as a B2BUA
An MRB entity can act as a SIP Back-2-Back-User-Agent (B2BUA) or a An MRB entity can act as a SIP Back-2-Back-User-Agent (B2BUA) or a
SIP Proxy Server as defined in RFC 3261 [RFC3261]. When acting as a SIP Proxy Server as defined in RFC 3261 [RFC3261]. When acting as a
skipping to change at page 62, line 9 skipping to change at page 62, line 9
Content-Length: 139 Content-Length: 139
<mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish"> <mrbpublish version="1.0" xmlns="urn:ietf:params:xml:ns:mrb-publish">
<mrbresponse status="200" reason="OK: Request accepted"/> <mrbresponse status="200" reason="OK: Request accepted"/>
</mrbpublish> </mrbpublish>
B1. MRB <- MS (CONTROL, event notification from MS) B1. MRB <- MS (CONTROL, event notification from MS)
--------------------------------------------------- ---------------------------------------------------
CFW 03fff52e7b7a CONTROL CFW 03fff52e7b7a CONTROL
Control-Package: mrb-publish/1.0 Control-Package: mrb-publish/1.0
Content-Type: application/mrb-publish+xml Content-Type: application/mrb-publish+xml
Content-Length: 4234 Content-Length: 4226
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mrbpublish version="1.0" <mrbpublish version="1.0"
xmlns="urn:ietf:params:xml:ns:mrb-publish"> xmlns="urn:ietf:params:xml:ns:mrb-publish">
<mrbnotification seqnumber="1" id="QQ6J3c"> <mrbnotification seqnumber="1" id="QQ6J3c">
<media-server-id>a1b2c3d4</media-server-id> <media-server-id>a1b2c3d4</media-server-id>
<supported-packages> <supported-packages>
<package name="msc-ivr/1.0"/> <package name="msc-ivr/1.0"/>
<package name="msc-mixer/1.0"/> <package name="msc-mixer/1.0"/>
<package name="mrb-publish/1.0"/> <package name="mrb-publish/1.0"/>
skipping to change at page 65, line 23 skipping to change at page 65, line 23
<A1>Campania</A1> <A1>Campania</A1>
<A3>Napoli</A3> <A3>Napoli</A3>
<A6>Via Claudio</A6> <A6>Via Claudio</A6>
<HNO>21</HNO> <HNO>21</HNO>
<LMK>University of Napoli Federico II</LMK> <LMK>University of Napoli Federico II</LMK>
<NAM>Dipartimento di Informatica e Sistemistica</NAM> <NAM>Dipartimento di Informatica e Sistemistica</NAM>
<PC>80210</PC> <PC>80210</PC>
</civicAddress> </civicAddress>
</media-server-location> </media-server-location>
<label>TestbedPrototype-01</label> <label>TestbedPrototype-01</label>
<media-server-address> <media-server-address>sip:MS1@ms.example.net</media-server-address>
sip:MediaServer@ms.example.net
</media-server-address>
<encryption> <encryption>
<keying-mechanism>SDES-SRTP</keying-mechanism> <keying-mechanism>SDES-SRTP</keying-mechanism>
</encryption> </encryption>
</mrbnotification> </mrbnotification>
</mrbpublish> </mrbpublish>
B2. MRB -> MS (200 to CONTROL) B2. MRB -> MS (200 to CONTROL)
------------------------------ ------------------------------
CFW 03fff52e7b7a 200 CFW 03fff52e7b7a 200
skipping to change at page 68, line 39 skipping to change at page 68, line 36
</mrbconsumer> </mrbconsumer>
As the example show, the request and response are associated by means As the example show, the request and response are associated by means
of the 'id' attribute (id="gh11x23v"). The MRB has picked '9' as the of the 'id' attribute (id="gh11x23v"). The MRB has picked '9' as the
random sequence number that needs to be incremented by the random sequence number that needs to be incremented by the
Application Server for the following request associated with the same Application Server for the following request associated with the same
session. session.
The rest of the scenario is omitted for brevity. After having The rest of the scenario is omitted for brevity. After having
received the 'mediaResourceResponse', the Application Server has the received the 'mediaResourceResponse', the Application Server has the
address of two Media Servers able to fulfil its media requirements, URIs of two Media Servers able to fulfil its media requirements, and
and can start a Control Dialog with one or both of them. can start a Control Dialog with one or both of them.
9.2.2. IAMM Example 9.2.2. IAMM Example
Two separate examples are presented for the IAMM case: in fact, IAMM- Two separate examples are presented for the IAMM case: in fact, IAMM-
mode can take advantage of two different approaches with respect to mode can take advantage of two different approaches with respect to
the SIP dialogs to be exploited to carry consumer messages, i.e.: i) the SIP dialogs to be exploited to carry consumer messages, i.e.: i)
a SIP control dialog to create a control channel, and, ii) a UAC a SIP control dialog to create a control channel, and, ii) a UAC
media dialog to attach to a Media Server. To make things clearer for media dialog to attach to a Media Server. To make things clearer for
the reader, the same consumer request as the one presented in the the reader, the same consumer request as the one presented in the
Query mode will be sent, in order to clarify how the behaviour of the Query mode will be sent, in order to clarify how the behaviour of the
skipping to change at page 132, line 5 skipping to change at page 132, line 5
Security considerations: See Section 10 of RFC 3023 [RFC3023] and Security considerations: See Section 10 of RFC 3023 [RFC3023] and
Section 12 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace Section 12 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace
XXXX with the RFC number of this specification.]]. XXXX with the RFC number of this specification.]].
Interoperability considerations: none. Interoperability considerations: none.
Published specification: Section 10 of RFCXXXX [[NOTE TO RFC- Published specification: Section 10 of RFCXXXX [[NOTE TO RFC-
EDITOR/IANA: Please replace XXXX with the RFC number of this EDITOR/IANA: Please replace XXXX with the RFC number of this
specification.]]. specification.]].
Applications which use this media type: This document type has been Applications which use this media type: This media type is used to
used to support a Media Resource Broker (MRB) entity. support a Media Resource Broker (MRB) entity.
Additional Information: Additional Information:
Magic Number: None Magic Number: None
File Extension: .xdf File Extension: .xdf
Macintosh file type code: "TEXT" Macintosh file type code: "TEXT"
Personal and email address for further information: Chris Boulton Personal and email address for further information: Chris Boulton
<chris at ns-technologies.com> <chris at ns-technologies.com>
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: The IETF. Author/Change controller: The IETF.
13.3. application/mrb-consumer+xml MIME Type 13.3. application/mrb-consumer+xml Media Type
To: application To: application
Subject: Registration of media type application/mrb-consumer+xml Subject: Registration of media type application/mrb-consumer+xml
Type name: application Type name: application
Subtype name: mrb-consumer+xml Subtype name: mrb-consumer+xml
Mandatory parameters: none Mandatory parameters: none
skipping to change at page 133, line 5 skipping to change at page 133, line 5
Security considerations: See Section 10 of RFC 3023 [RFC3023] and Security considerations: See Section 10 of RFC 3023 [RFC3023] and
Section 12 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace Section 12 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace
XXXX with the RFC number of this specification.]]. XXXX with the RFC number of this specification.]].
Interoperability considerations: none. Interoperability considerations: none.
Published specification: Section 11 of RFCXXXX [[NOTE TO RFC- Published specification: Section 11 of RFCXXXX [[NOTE TO RFC-
EDITOR/IANA: Please replace XXXX with the RFC number of this EDITOR/IANA: Please replace XXXX with the RFC number of this
specification.]]. specification.]].
Applications which use this media type: This document type has been Applications which use this media type: This media type is used to
used to support a Media Resource Broker (MRB) entity. support a Media Resource Broker (MRB) entity.
Additional Information: Additional Information:
Magic Number: None Magic Number: None
File Extension: .xdf File Extension: .xdf
Macintosh file type code: "TEXT" Macintosh file type code: "TEXT"
Personal and email address for further information: Chris Boulton Personal and email address for further information: Chris Boulton
<chris at ns-technologies.com> <chris at ns-technologies.com>
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: The IETF. Author/Change controller: The IETF.
13.4. URN Sub-Namespace Registration for mrb-publish 13.4. URN Sub-Namespace Registration for mrb-publish
Please register the URN name space Please register the URN "urn:ietf:params:xml:ns:mrb-publish", with
"urn:ietf:params:xml:ns:mrb-publish", with the ID of "mrb-publish". the ID of "mrb-publish". The schema of the XML namespace named
The schema of the XML namespace named
urn:ietf:params:xml:ns:mrb-publish" is Section 10. urn:ietf:params:xml:ns:mrb-publish" is Section 10.
13.5. URN Sub-Namespace Registration for mrb-consumer 13.5. URN Sub-Namespace Registration for mrb-consumer
Please register the URN name space Please register the URN "urn:ietf:params:xml:ns:mrb-consumer", with
"urn:ietf:params:xml:ns:mrb-consumer", with the ID of "mrb-consumer". the ID of "mrb-consumer". The schema of the XML namespace named
The schema of the XML namespace named
urn:ietf:params:xml:ns:mrb-consumer" is in Section 11. urn:ietf:params:xml:ns:mrb-consumer" is in Section 11.
13.6. XML Schema Registration for mrb-publish 13.6. XML Schema Registration for mrb-publish
Please register the schema for mrb-publish: Please register the schema for mrb-publish:
URI: urn:ietf:params:xml:schema:mrb-publish URI: urn:ietf:params:xml:schema:mrb-publish
ID: mrb-publish ID: mrb-publish
skipping to change at page 140, line 23 skipping to change at page 140, line 23
1:1997, 1997. 1:1997, 1997.
[ISO.639.1988] [ISO.639.1988]
International Organization for Standardization, "Code for International Organization for Standardization, "Code for
the representation of names of languages, 1st edition", the representation of names of languages, 1st edition",
ISO Standard 639, 1988. ISO Standard 639, 1988.
[ITU-T.Q.1950] [ITU-T.Q.1950]
International Telecommunication Union - Telecommunication International Telecommunication Union - Telecommunication
Standardization Bureau, "Call Bearer Control (CBC) Standardization Bureau, "Call Bearer Control (CBC)
Protocol", ITU-T Recommendation Q.1950. Protocol", ITU-T Recommendation Q.1950, 2002.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996. November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
skipping to change at page 141, line 13 skipping to change at page 141, line 13
Format for Presence Information Data Format Location Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, February 2008. Object (PIDF-LO)", RFC 5139, February 2008.
[W3C.CR-wsdl20-20051215] [W3C.CR-wsdl20-20051215]
Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana,
"Web Services Description Language (WSDL) Version 2.0 Part "Web Services Description Language (WSDL) Version 2.0 Part
1: Core Language", W3C CR CR-wsdl20-20051215, 1: Core Language", W3C CR CR-wsdl20-20051215,
December 2005. December 2005.
[W3C.REC-soap12-part1-20030624] [W3C.REC-soap12-part1-20030624]
Gudgin, M., Mendelsohn, N., Nielsen, H., Moreau, J., and Gudgin, M., Mendelsohn, N., Moreau, J., Nielsen, H., and
M. Hadley, "SOAP Version 1.2 Part 1: Messaging Framework", M. Hadley, "SOAP Version 1.2 Part 1: Messaging Framework",
World Wide Web Consortium FirstEdition REC-soap12-part1- World Wide Web Consortium FirstEdition REC-soap12-part1-
20030624, June 2003, 20030624, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part1-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part1-20030624>.
[W3C.REC-soap12-part2-20030624] [W3C.REC-soap12-part2-20030624]
Hadley, M., Mendelsohn, N., Gudgin, M., Moreau, J., and H. Hadley, M., Mendelsohn, N., Gudgin, M., Moreau, J., and H.
Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", World Wide Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", World Wide
Web Consortium FirstEdition REC-soap12-part2-20030624, Web Consortium FirstEdition REC-soap12-part2-20030624,
June 2003, June 2003,
 End of changes. 22 change blocks. 
42 lines changed or deleted 45 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/