SIPPING WG S. Veikkolainen, Ed. Internet-Draft Nokia Siemens Networks Intended status: Standards Track M. Isomaki Expires: December 3, 2007 Nokia June 2007 A Simple Application Configuration Protocol draft-veikkolainen-sipping-app-config-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 3, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract For applications requiring configuration of various settings, it is desirable that the end user needs to enter as little configuration information as possible. Especially applications running in devices with limited user interface, such as mobile phones, Personal Digital Assistants (PDAs), and terminal adaptors, would benefit from an automated configuration process. This document defines a simple application configuration mechanism using the Domain Name System Veikkolainen & Isomaki Expires December 3, 2007 [Page 1] Internet-Draft Simple Application Configuration Protocol June 2007 (DNS) and HyperText Transfer Protocol (HTTP). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 3 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview of operation . . . . . . . . . . . . . . . . . . . . 4 4.1. Discovery of the servers . . . . . . . . . . . . . . . . . 5 4.2. Retrieving the configuration bootstrap document . . . . . 6 4.3. Retrieving configuration objects . . . . . . . . . . . . . 7 4.4. Reporting on the success or failure of the configuration action . . . . . . . . . . . . . . . . . . . 7 4.5. Learning about changes in the configuration data . . . . . 8 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8 5.1. Discovering configuration servers . . . . . . . . . . . . 8 5.2. Retrieving the configuration bootstrap document . . . . . 9 5.3. Retrieving configuration objects . . . . . . . . . . . . . 9 5.4. Format of the configuration bootstrap document . . . . . . 10 5.4.1. Configuration boostrap document XML element descriptions . . . . . . . . . . . . . . . . . . . . . 10 5.4.2. MIME type . . . . . . . . . . . . . . . . . . . . . . 11 5.4.3. Relax NG definition . . . . . . . . . . . . . . . . . 11 5.5. Format of the SIP configuration object . . . . . . . . . . 11 5.5.1. SIP Configuration object XML element descriptions . . 12 5.5.2. MIME type . . . . . . . . . . . . . . . . . . . . . . 12 5.5.3. Relax NG definition . . . . . . . . . . . . . . . . . 12 5.6. Event notifications . . . . . . . . . . . . . . . . . . . 12 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Message flow . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. DNS records . . . . . . . . . . . . . . . . . . . . . . . 14 6.3. Configuration bootstrap document . . . . . . . . . . . . . 15 6.4. SIP configuration object . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7.1. U-NAPTR record . . . . . . . . . . . . . . . . . . . . . . 17 7.2. SRV record . . . . . . . . . . . . . . . . . . . . . . . . 17 7.3. MIME type . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 10. Normative References . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Veikkolainen & Isomaki Expires December 3, 2007 [Page 2] Internet-Draft Simple Application Configuration Protocol June 2007 1. Introduction Configuration of application settings may in many cases be cumbersome. The settings needed for an application to successfully operate may not be intuitively understandable for a person not intimate with the underlying protocol and application level details. A number of solutions and protocols have been defined earlier, which target the same problem space, including Application Configuration Access Protocol (ACAP) [1], The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) [2], and Service Location Protocol (SLP) [3]. Despite these earlier efforts, many applications today use proprietary mechanisms for configuration purposes. The key driver for these proprietary solutions seems to be simplicity and possibility to use readily available software components, such as web clients and servers, as part of the solution. This document defines mechnisms for an application for locating configuration servers in a given network domain, contacting those servers and learning the configuration mechanisms and protocols supported by the servers, and fetching configuration data. Primary goals of this work have been simplicity of the basic configuration, reuse of existing and widely deployed protocols and software components, extensibility for more advanced features, and minimal burder for a service provide to set up a configuration service. This document is structured as follows: Section 2 provides the document conventions, Section 3 introduces the definitions used in this document, Section 4 presents an overview of the protocol operation, Section 5 contains the protocol specfication. Examples are provided in Section 6. Sections 7 and 8 contain the IANA and Security considerations, respectively. 2. Document Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [4] and indicate requirement levels for compliant implementations. Veikkolainen & Isomaki Expires December 3, 2007 [Page 3] Internet-Draft Simple Application Configuration Protocol June 2007 3. Definitions This document uses the following terms to describe the configuration protocol: configuration bootstrap document: a document residing in a pre- defined location on the configuration server. The configuration bootstrap document contains information about available configuration objects and configuration related metadata within a particular domain. configuration object: a set of data required by an application to successfully use a service within a specific domain. The configuration object may be personalized for each user and/or application vendor. configuration server: an entity that stores the configuration bootsrap document and possibly configuration objects for a particular domain. At minimum, the configuration server provides an HTTP based interface for the configuration client to retrieve the configuration bootstrap document and configuration objects. configuration client: an entity within a host that interacts with the configuration server on behalf of an application, such as SIP or email User Agent. The configuration client is responsible for the discovery of the configuration server, obtaining the required configuration objcets and configuration related metadata. 4. Overview of operation This section provides an overview of the configuration process, including o discovery of the configuration server within a domain that is hosting the application related service, o discovery of the available configuration objects, other configuration related mechanisms and metadata o retrieval of the required configuration objects(s) o reporting on the success or failure in applying the retrieved configuration o getting notifications when the contents of the configuration data changes Veikkolainen & Isomaki Expires December 3, 2007 [Page 4] Internet-Draft Simple Application Configuration Protocol June 2007 4.1. Discovery of the servers If configuration data is not available for an application, the configuration client needs to locate the configuration server(s) that could provide the necessary data. The configuration server name or address may be obtained by means outside the scope of this document, for example by user input or given by the service provider when creating an account for a service through a web self-service portal. If the configuration server is not known, the configuration client needs to discover the server. It does this by 1. querying the Domain Name System (DNS) [5] for the Naming Authority Pointer records for URIs (U-NAPTR) [6] for the configuration service within a given domain, or if that is not successful, 2. by querying the DNS for the Service (SRV) [7] record that identifies a host providing configuration services for a certain domain. The format of the SRV record is specified in Section 5.1. It is assumed that the domain for which the query is done is given by the user (as the domain part of SIP Address-of-Record, or email address, for example). This document does not restrict learning the domain using other means, such as preconfiguration. Also, in a specific case, when the application wants to retrieve configuration data from the domain associated with the local network the host running the application is attached to, the domain can be learned using the Dynamic Host Configuration Protocol (DHCP) for IPv4 (DHCPv4) [8] or IPv6 DHCPv6 [9]). The result of the U-NAPTR query is a URI which points to the configuration bootstrap document on the configuration server. The configuration client may invoke that URI in order to retrieve the configuration bootsrap document. In case there are no U-NAPTR records defined for this service with the given domain, and the SRV query is successful, the response to the SRV query carries the server name which the configuration client may resolve to an IP address using normal A or AAAA DNS queries. In this case the configuration boostrap document can be retrieved by issuing a request to a well-known resource that points to the configuration bootstrap document, as described in Section 4.2 below. Load balancing using DNS can be done already at this point. Veikkolainen & Isomaki Expires December 3, 2007 [Page 5] Internet-Draft Simple Application Configuration Protocol June 2007 4.2. Retrieving the configuration bootstrap document The configuration bootstrap document contains general information about a domain's configuration capabilities, such as available configuration objects, and metadata. If the configuration client has learned the URI of the configuration bootstrap document through U-NAPTR query, it can directly retrieve that document by issuing an HTTP GET request to that URI. If the configuration client learned the configuration server name through SRV query, and wants to retrieve the configuration bootstrap document, it creates an HTTP GET request and sets the URI to point to a well known resource, called index.xml, located in the /configuration directory under the root of the resource hierarchy. Thus, a configuration client wishing to retrieve the configuration bootstrap document at server srv.example.com sets the URI to point to http://srv.example.com/configuration/index.xml. The server can challenge request, requiring the client to include proper credentials in the request for authenticating the originator. The user may provide a username and password, or the application may be pre-provisioned with credentials, such as device certificate, which may be used for authentication. Based on the authentication, the server can tailor the requested configuration object to be user specific. If the server accepts the request, it will respond with a 200 OK response that carries the configuration bootstrap document. The configuration bootstrap document contains: o listing of directly available configuration objects and their types o optionally, configuration related information and capabilities that apply to the whole domain, such as * refresh (polling) period: how often the application should check for new configuration data OPEN ISSUE: Should the configuration bootstrap document also include a URI to which the client can issue a POST request to indicate success/failure of the client configuration. The configuration objects are identified by a type parameter, and they contain either configuration data in-line, or a reference to the actual configuration data. The configuration objects may also include information related to the polling period for that object. Veikkolainen & Isomaki Expires December 3, 2007 [Page 6] Internet-Draft Simple Application Configuration Protocol June 2007 In that case, the object-specific information overrides the domain- specific information provided in the configuration bootstrap document. The configuration objects may include a reference to a configuration protocol or mechanism specified elsewhere. The reference may point to a server address or a boostrap document. These configuration protocols, as any other configuration object, are identified by the type associated to the configuration object. For example, the reference may be to a bootstrapping information, as in the case of an Open Mobile Alliance (OMA) Device Management (DM) boostrap document defined in [10] for initiating a SyncML session. Or, as another example, the reference may be to a server providing configuration services as defined in the SIP UA Configuration Framework [11]. It is however not necessary that the configuration server itself supports all the protocols referred to in the response. The HTTP requests and responses should be protected by TLS. The configuration data may contain personalized or otherwise sensitive data, but even if the configuration data is publicly available, the integrity of the data should be ensured. After retrieving the configuration bootstrap document, the configuration client may use either HTTP or HTTPS for retrieving one of the configuration objects listed in the configuration bootstrap document, or one of the configuration protocols to start a configuration session. 4.3. Retrieving configuration objects If the configuration bootstrap document contains a reference to the configuration object, and the configuration client wishes to retrieve that particular object, it creates a GET request with a URI pointing to that document. The client also sets the Accept header to contain the MIME type of the configuration object. The configuration server returns that document as per normal HTTP procedures. 4.4. Reporting on the success or failure of the configuration action A configuration object may include a URI which the configuration client can invoke in order to report on the success or failure of the configuration action. Even though this doesn't provide detailed information for example on why the configuration was not successful, it still provides a means for an administrator to monitor the rate of successful operations within a given domain. Veikkolainen & Isomaki Expires December 3, 2007 [Page 7] Internet-Draft Simple Application Configuration Protocol June 2007 4.5. Learning about changes in the configuration data This document does not specify any notification mechanisms, but the configuration objects may contain a reference to a notification protocol such that an application is able to use it in order to learn about changes in the configuration data. An example of such a notification protocol is the SIP Event package for SIP UA configuration, defined in [11]. 5. Protocol Description 5.1. Discovering configuration servers In order to find a configuration server, the configuration client needs to be aware of the domain from which the server is looked up. There are typically two ways for the client to learn the domain name. The user may simply input the domain name of his account in an appropriate field in an application. Alternatively, for SIP applications, the user inputs his complete SIP Address-of-Record, which is a SIP URI of the form sip:user@domain. The client can then derive the domain as all the characters located to the right of the '@' sign in the SIP Address-of-Record. Notice that, since an Address-of-Record is expected, SIP parameters are not part of it and should be discarded in case they are present. Similarly, for an email account, the domain name can be derived as the characters on the right hand side of the '@' sign. Once the configuration client has obtained the domain name, it SHOULD create an U-NAPTR query for that domain by setting the Application Service tag (defined in [6]) to a value of "CONF", registered in Section 7. If the response to the U-NAPTR query is a terminal lookup with the "u" flag, the client SHOULD use this as the URI value when retrieving the configuration bootstrap document. If the response to the U-NAPTR query is a terminal lookup with the "a" flag, the client SHOULD use the output of that rule as the domain name for which address lookup is made. If the response the U-NAPTR query is a terminal lookup with the "s" flag, the client SHOULD use the output of that rule as the FQDN for which the SRV query is made. If the NAPTR query fails, the client SHOULD try whether any SRV records are configured for that domain for the configuration service. The client constructs a string that MUST set to the token '_config.' Veikkolainen & Isomaki Expires December 3, 2007 [Page 8] Internet-Draft Simple Application Configuration Protocol June 2007 appended by the transport protocol '_tcp' or '_tls._tcp', appended by the domain. For example, for a domain name of 'example.com' the string is set to '_config._tcp.example.com' or '_config._tls._tcp.example.com'. The DNS responds to the query with any SRV records it has for the _config service. The client then uses A or AAAA queries to translate the host name(s) into IP address(es). 5.2. Retrieving the configuration bootstrap document The configuration client uses HTTP [12] for contacting the configuration server. Upon first contact with the configuration server, the client constructs a GET request targeted to the URI or host name resolved in the U-NAPTR or SRV query, respectively. If the configuration client learned the URI to the configuration bootstrap document through an U-NAPTR query, it SHOULD use that directly as the URI of the GET request. If the client learned the server name through an SRV query, the client SHOULD set the Request-URI of the GET request to point to a well known resource '/configuration/index.xml'in order to retrieve the configuration bootstrap document. The client MAY set the URI to point to another resource, if it is aware of the specific location of that resource. The client SHOULD list supported MIME types in the Accept header of the GET request. All clients MUST support the MIME type defined for the configuration boostrap document in Section 5.4. The server MAY challenge the request with a 401 Unauthorized response. In this case the client SHOULD calculate the authentication response and send a new GET request that includes the response, as per regular procedures in HTTP Digest authentication [13]. At a minimum, HTTP Digest and TLS MUST be supported by the client. A successful response to the GET request carries in the body of the 200 OK response a configuration bootstrap document describing the available configuration objects at the server, and optionally optionally other information. The configuration bootstrap document structure and Relax NG definition are presented in Section 5.4. 5.3. Retrieving configuration objects The configuration client learns the available configuration objects or references to their location from the configuration bootstrap document. Veikkolainen & Isomaki Expires December 3, 2007 [Page 9] Internet-Draft Simple Application Configuration Protocol June 2007 When the client wishes to retrieve a specific configuration object, it constructs a GET request, and MUST set the URI of the request to the value that was received in the configuration bootstrap document. The client SHOULD include the object MIME type in the Accept header of the GET request. 5.4. Format of the configuration bootstrap document The configuration bootstrap document contains the available configuration objects, or references thereto, and optionally information related to the polling period (how often the client should check for changes in the configuration data) as well as a URI which the client can invoke when reporting on the success or failure of the configuration operation. The configuration objects may also contain a reference to other configuration protocols or mechanism. 5.4.1. Configuration boostrap document XML element descriptions 5.4.1.1. The element The element is the main level element that contains the available configuration objects. The configuration objects may be included in-line, or as reference to the actual configuration data in the element. 5.4.1.2. The element The element contains the configuration data or a reference thereto. Each configuration object is identified by its type, and is associated by a MIME type. The has an attribute "type" which identifies the object type. Three object types are defined in this document: "sip", "oma-dm" and "sip-ua-config". Further object types may be defined by other specifications. Each extension must define the semantics for the and elements described below. The element has three child elements: , and . The mandatory element contains the URI to the configuration object. The semantics of the element depends on the "type" attribute. For example, the element may contain a HTTP URI where the configuration object is available, or it may contain a SIP URI to where a SUBSCRIBE request can be sent. Veikkolainen & Isomaki Expires December 3, 2007 [Page 10] Internet-Draft Simple Application Configuration Protocol June 2007 The mandatory element contains the mime type of the configuration object. Each configuration object is associated to a MIME type. If the "type" attribute is set to "sip", the element contains the HTTP URI from where the SIP UA configuration object can be retrieved. The MIME type for the SIP configuration object is defined in Section 5.5 If the "type" attribute is set to "sip-ua-config", the element contains the SIP URI of the Profile Delivery Server(PDS) according to the rules presented in [11]. The MIME type is set to the MIME type defined for the profile content. If the "type" attribute is set to "oma-dm", the element contains the HTTP URI pointing to a Open Mobile Alliance (OMA) Device Management (DM) bootstrap document as defined in [10]. The MIME type for the boostrap information is "application/ vnd.wap.connectivity-wbxml". The optional element defines a time (in seconds) after which the client SHOULD issue a new GET request to check if there are changes in the configuration object. The client MAY use the URI provided in the element to retrieve only this single object type. The element may contain the actual configuration object in-line in addition to carrying a reference to the object. This way, the client can receive the configuration data already in the first response from the configuration server. For example, the configuration object for SIP UA, defined in Section 5.5, could be included after the and elements. 5.4.2. MIME type The MIME type associated to the configuration bootstrap document is application/config-bootstrap+xml. 5.4.3. Relax NG definition To be provided. 5.5. Format of the SIP configuration object The SIP configuration object type contains information related to the configuration of the SIP User Agent (UA). The configuration object is defined as an XML document. Veikkolainen & Isomaki Expires December 3, 2007 [Page 11] Internet-Draft Simple Application Configuration Protocol June 2007 5.5.1. SIP Configuration object XML element descriptions The SIP configuration object main level element is and it has three optional elements. The element contains the SIP address of the outbound proxy (see [14] for a definition of outbound proxy). The element contains the XCAP root URI defined in [2]. The contains the URI which the client may invoke to create an ad-hoc conference. See [15] for a definition of the conference factory URi. Other elements may be defined through extensions to this specification. 5.5.2. MIME type The SIP configuration object is associated to the MIME type application/config-info-sip+xml. 5.5.3. Relax NG definition To be provided. 5.6. Event notifications Event notifications may be used to inform the application about changes in the configuration data. In order to receive notifications, the application needs to subscribe to the resource(s) it would like to get notifications of. Configuration server can indicate support for such protocols in the element. Support for SIP event package for SIP UA Configuration Framework, defined in [11], can be indicated by setting the "type" attribute of the element to "sip-ua- config", as described in Section 5.4.1. Other notification protocols, for example based on Session Initiation Protocol (SIP)-specific Event Notification [16] or Publish-Subscribe [17] for Extensible Messaging and Presence Protocol (XMPP) [18], can be specified by extensions to this document. Each extensions needs to define the semantics for the and elements. 6. Examples Consider the following example: Alice has created an account at a SIP service provider's web portal. She has received her SIP Address-of- Veikkolainen & Isomaki Expires December 3, 2007 [Page 12] Internet-Draft Simple Application Configuration Protocol June 2007 Record and a Digest password. She now starts a wizard on her device, which requests her to enter the AoR and password. The wizard passes this information to the configuration client, that start the configuration process. 6.1. Message flow An example flow of a successful configuration using simple HTTP GET operations is depicted in Figure 1. Configuration DHCP DNS Configuration client Server | Server | | | | |(1) NAPTR query | | | |---------------------------------->| | |(2) NAPTR resp | | | |<----------------------------------| | |(3) SRV query | | | |- - - - - - - - - - - - - - - - - >| | |(4) SRV resp | | | |<- - - - - - - - - - - - - - - - - | | |(5) HTTP GET | | | |--------------------------------------------------->| |(6) 401 Unauthorized | | |<---------------------------------------------------| |(7) HTTP GET (with credentials) | | |--------------------------------------------------->| |(8) 200 OK | | | |<---------------------------------------------------| |(9) HTTP GET | | | |- - - - - - - - - - - - - - - - - - - - - - - - - ->| |(10) 200 OK | | | |<- - - - - - - - - - - - - - - - - - - - - - - - - -| | | | | Figure 1: Example Message Flow 1. The client notices that it requires some configuration information and constructs an U-NAPTR query for the service "CONF" for a domain. The domain is given by the end-user ar part of her SIP AoR. 2. The DNS responds with the HTTP URI that points to the configuration boostrap document. Veikkolainen & Isomaki Expires December 3, 2007 [Page 13] Internet-Draft Simple Application Configuration Protocol June 2007 3. If the NAPTR query did not return any U-NAPTR records defined for this service in the domain, the client constructs an SRV query for a service type _config in the domain. Dashed line is used here to indicate that the SRV query is made only in NAPTR query was not successful. 4. The DNS responds with one or more configuration server addresses and/or hostnames. The client selects one and may store the address or hostname as the configuration server name. 5. The client constructs an HTTP GET request with the URI set to the value learned in step 2. If the client learned the configuration server name in step 4, it sets the URI to point to a well-known resource /configuration/index.xml to retreive the configuration bootstrap document. 6. The server challenges the GET request with 401 Unauthorized. The client responds with the credentials (user name and password) given by the user. 7. The client sends the GET request with the credentials. 8. The 200 OK response carries the configuration bootstrap document containing the available configuration objects. The configuration bootstrap document may contain the configuration object(s) also in-line in addition to providing a reference to the data. 9. If the configuration object the client is interested in was not included in the configuration boostrap document, it issues a HTTP GET request to the URI where the configuration object is available. Dashed line indicates that this step is needed only if the configuration object was not in-line within the configuration boostrap document. 10. The server returns the configuration object in the body of the 200 OK response. 6.2. DNS records An example U-NAPTR record for getting the configuration bootstrap document URI in domain example.com is given below. example.com. ;; order pref flags IN NAPTR 100 10 "u" "CONF:http" ( ; service "!.*!http://example.com/config/index.xml"; regexp Veikkolainen & Isomaki Expires December 3, 2007 [Page 14] Internet-Draft Simple Application Configuration Protocol June 2007 "" ; replacement ) If there are no U-NAPTR records available, the client may try SRV records. The following example shows the DNS SRV records for the domain example.com. ;;Service TTL Cl Pr Wght Port Target _config._tls._tcp.example.com 86400 IN SRV 0 1 80 config.example.com _config._tcp.domain.com 86400 IN SRV 0 1 80 config.example.com The client selects one of the targets, and if that is not a numeric IP address, may use regular DNS A or AAAA queries for translating the host name into an IP address. 6.3. Configuration bootstrap document This section provides an example configuration bootstrap document. The "sip" configuration object is here included in-line in the configuration bootstrap document. The configuration bootstrap document contains also references to configuration object types "oma-dm" and "sip-ua-config", which the client may use to start configuration sessions using OMA Device Management protocol, or the event package for SIP UA configuration. Veikkolainen & Isomaki Expires December 3, 2007 [Page 15] Internet-Draft Simple Application Configuration Protocol June 2007 http://config.example.com/configuration/sip.xml application/config-info-sip+xml 86400 sip:srv1.out@example.com http://xcap.example.com/ sip:conf1@conference.example.com http://omadmserver.example.com application/vnd.wap.connectivity-wbxml sip:sipconfigsrv@example.com application/uaconfig+xml 6.4. SIP configuration object This section provides an example of a SIP configuration object. The configuration client may retrieve this configuration object directly by issuing an HTTP GET request with a URI set to the value contained in the element in the configuration boostrap document for configuration object type "sip". This client may want to retrieve only this single object after the the poll-period has elapsed. sip:srv1.out@example.com http://xcap.example.com/ sip:conf1@conference.example.com 7. IANA Considerations Veikkolainen & Isomaki Expires December 3, 2007 [Page 16] Internet-Draft Simple Application Configuration Protocol June 2007 7.1. U-NAPTR record This document specifies a new U-NAPTR Application Service. The proposed name for Application Service is "CONF". The Application Protocol is "http". 7.2. SRV record This document specifies a new SRV record to identify a configuration service. The proposed name for the SRV record is _config. 7.3. MIME type This specification requests the registration of two new MIME types according to the procedures of Media Type Specifications and Registration Procedures [19] and guidelines in XML Media Types [20]. MIME media type name: application MIME subtype name: config-bootstrap+xml Mandatory parameters: none Optional parameters: charset Indicates the character encoding of enclosed XML. Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See XML Media Types [20], Section 3.2. Security considerations: None Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification.] this document MIME media type name: application MIME subtype name: config-sip-info+xml Mandatory parameters: none Optional parameters: charset Indicates the character encoding of enclosed XML. Veikkolainen & Isomaki Expires December 3, 2007 [Page 17] Internet-Draft Simple Application Configuration Protocol June 2007 Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See XML Media Types [20], Section 3.2. Security considerations: None Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification.] this document 8. Security Considerations The protocol specified in this document uses HTTP GET and optionally POST operations for fetching the configuration related data, and informing the server about the success/failure of the configuration transaction, respectively. See [12] for discussion on security considerations related to HTTP. The configuration data retrieved from the configuration server may contain sensitive, personalized data. Communication channel between the client and the configuration server MUST be secured with TLS if such personalized data is returned from the server to the application. In other cases, the communication channel SHOULD be secured with TLS in order to ensure the integrity of the configuration object(s). The client and the configuration server MUST support HTTP Digest as described in [13]. The server MUST present its server certificate, using which the client can verify the configuration server's identity. The clients may use HTTP POST request to indicate success or failure of an operation at the application. The Request-URI in the POST request may contain a pseudo-random string which is used to correlate the POST request to an earlier transaction. Implementors are advised to consider the length of the pseudo-random part of the URI, so that an acceptable level of randomness is guaranteed. 9. Acknowledgments The authors would like to thank the following persons for their insightful comments: Miguel Garcia, Aki Niemi, Christian Schmidt, Henning Schulzrinne and Markku Vimpari. Veikkolainen & Isomaki Expires December 3, 2007 [Page 18] Internet-Draft Simple Application Configuration Protocol June 2007 10. Normative References [1] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997. [2] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007. [3] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [5] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [6] Daigle, L., "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", RFC 4848, April 2007. [7] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [8] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [9] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [10] "OMA DM Standardized Objects, version 1.2", February 2007. [11] Petrie, D. and S. Channabasappa, "A Framework for Session Initiation Protocol User Agent Profile Delivery", draft-ietf-sipping-config-framework-12 (work in progress), June 2007. [12] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [13] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Veikkolainen & Isomaki Expires December 3, 2007 [Page 19] Internet-Draft Simple Application Configuration Protocol June 2007 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [15] Barnes, M., "A Framework for Centralized Conferencing", draft-ietf-xcon-framework-08 (work in progress), May 2007. [16] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [17] Millard, P., Saint-Andre, P., and R. Meijer, "XMPP: Publish- Subscribe", September 2006. [18] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, October 2004. [19] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005. [20] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. Authors' Addresses Simo Veikkolainen (editor) Nokia Siemens Networks P.O. Box 6 Nokia Siemens Networks, FIN 02022 Finland Phone: +358 50 486 4463 Email: simo.veikkolainen@nsn.com Markus Isomaki Nokia P.O. Box 100 NOKIA GROUP, FIN 00045 Finland Phone: +358 50 522 5984 Email: markus.isomaki@nokia.com Veikkolainen & Isomaki Expires December 3, 2007 [Page 20] Internet-Draft Simple Application Configuration Protocol June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Veikkolainen & Isomaki Expires December 3, 2007 [Page 21]