< draft-dolly-sipping-config-content-00.txt		draft-dolly-sipping-config-content-01.txt >
	SIPPING M. Dolly		SIPPING M. Dolly
	Internet-Draft AT&T Labs		Internet-Draft AT&T Labs
	Expires: November 9, 2004 May 11, 2004		Expires: January 13, 2005 July 15, 2004
	Data Content for SIP User Agent Profile Delivery		Data Content for SIP User Agent Profile Delivery
	draft-dolly-sipping-config-content-00.txt		draft-dolly-sipping-config-content-01.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that other
	other groups may also distribute working documents as		groups may also distribute working documents as Internet-Drafts.
	Internet-Drafts.
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at http://
	http://www.ietf.org/ietf/1id-abstracts.txt.		www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on November 9, 2004.		This Internet-Draft will expire on January 13, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	This document defines the data content for providing profile data to		This document defines the data content for providing profile data to
	SIP user agents in support of the framework defined in		SIP user agents in support of the framework defined in
	I-D.ietf-sipping-config-framework-02.txt.		I-D.ietf-sipping-config-framework-03.txt and is intended to be input
			to the data sets defined by
	The profile content format will be defined in a later version of this		draft-petrie-sipping-profile-datasets-00.txt..
	document or in a separate document.
	Conventions used in this document		Conventions used in this document
	RFC2119 [1] provides the interpretations for the key words "MUST",		RFC2119 [1] provides the interpretations for the key words "MUST",
	"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",		"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
	"RECOMMENDED", "MAY", and "OPTIONAL" found in this document.		"RECOMMENDED", "MAY", and "OPTIONAL" found in this document.
	I-D.ietf-sipping-config-framework-02.txt [6] provides the		I-D.ietf-sipping-config-framework-02.txt [6] provides the
	interpretations for the terms "profile", "device", "profile content		interpretations for the terms "profile", "device", "profile content
	server", "notifier", and "profile delivery server".		server", "notifier", and "profile delivery server".
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Data Content . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Data Content . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1 User Data . . . . . . . . . . . . . . . . . . . . . . . . 3		4. Data Set Examples . . . . . . . . . . . . . . . . . . . . . . 6
	3.2 Device Data . . . . . . . . . . . . . . . . . . . . . . . 4		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	3.3 Environment Data . . . . . . . . . . . . . . . . . . . . . 4		6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 7
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 4		8. Change History . . . . . . . . . . . . . . . . . . . . . . . . 7
	6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 5		9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 5		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		10.1 Normative References . . . . . . . . . . . . . . . . . . . . 7
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5		10.2 Informative References . . . . . . . . . . . . . . . . . . . 7
	9.1 Normative References . . . . . . . . . . . . . . . . . . . . 5		Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8
	9.2 Informative References . . . . . . . . . . . . . . . . . . . 6		A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6		B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
	A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 6		Intellectual Property and Copyright Statements . . . . . . . . 9
	B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
	Intellectual Property and Copyright Statements . . . . . . . . 7
	1. Introduction		1. Introduction
	This document defines the data content for providing profile data to		This document defines the data content for providing profile data to
	SIP user agents in support of the framework defined in		SIP user agents in support of the framework defined in
	I-D.ietf-sipping-config-framework-02.txt [6]. The current framework		I-D.ietf-sipping-config-framework-02.txt [6]. The current framework
	draft identifies two types of profiles, defined as "user" and		draft identifies two types of profiles, defined as "user" and
	"device". It is anticipated, per discussion at the previous meeting,		"device". It is anticipated, per discussion at the previous meeting,
	that the draft 03 version will define a profile for "environment".		that the draft 03 version will define a profile for "local".
	The profile delivery framework is intended to enable a first phase		The profile delivery framework is intended to enable a first phase
	migration to a standard means of providing profiles to SIP user		migration to a standard means of providing profiles to SIP user
	agents. It is expected that UA vendors willbe able to use this		agents. It is expected that UA vendors willbe able to use this
	framework as a means of delivering their existing proprietary user		framework as a means of delivering their existing proprietary user
	and device data profiles.		and device data profiles.
	2. Overview		2. Overview
	The three types of content to be defined are user, device and		The three types of content to be defined are user, device and local.
	environment. The profile delivery server will provide the content or		The profile delivery server will provide the content or URI(s)
	URI(s) associated with the user and device profiles. The environment		associated with the user and device profiles. The local profile is
	profile is optional and its content will be provided by the local		optional and its content will be provided by the local domain serving
	domain serving the SIP User Agent.		the SIP User Agent.
	The content of the device profile is a function of the vnedor, model,		The content of the device profile is a function of the vendor, model,
	and version parameters associted with the device, whoch are specified		and version parameters associted with the device, which are specified
	by the vendor of the user agent. THese parameters allow the profile		by the vendor of the user agent. These parameters allow the profile
	delivery server to provide different profiles based upon these		delivery server to provide different profiles based upon these
	variables.		variables.
	As noted in the framework, a default user maybe assigned to a device.		As noted in the framework, a default user maybe assigned to a device.
	In this scenario the profile delivery server may provide the URI(s)		In this scenario the profile delivery server may provide the URI(s)
	in the NOTIFY request for the default user when subscribing to the		in the NOTIFY request for the default user when subscribing to the
	device profile type. Effectively the device profile type becomes a		device profile type. Effectively the device profile type becomes a
	superset of the user profile subscription. The user type is still		superset of the user profile subscription. The user type is still
	useful in this scenario to allow the user agent to obtain profile		useful in this scenario to allow the user agent to obtain profile
	data or URI(s) for a user other than the default user. This provides		data or URI(s) for a user other than the default user. This provides
	the ability to support a hoteling function where a user may "login"		the ability to support a hoteling function where a user may "login"
	to a local domain and obtain the content of the environment profile.		to a local domain and obtain the content of the local profile.
	3. Data Content		3. Data Content
	The contributor WILL provide descriptive text for the content items		The data content list below is intended as input into the datasets to
	in the next revision.		be defined in draft-petrie-sipping-profile-datasets-00.txt.
	3.1 User Data		The local data may be inputted by the subscriber or the local access
			domain.
	Elements of the User Data include:		Elements of the User Data include:
	Proxy and Registration Server URIs		-- Proxy and Registration Server URIs - IP addresses of the
	Preloaded Route Sets		primary SIP proxyand registration servers that will be used.
	User Address of Record and Display Name		(address format is the in IP dotted-decimal notation)
	User Authentication Information and Other Credentials
	Privacy Settings
	Pre Media Configuration Parameters (e.g., Audio Configuration)
	Dial Plan
	Progess Tone Settings
	ENUM Settings
	International Settings
	Call Forwarding and Redirection Settings
	Speed Dial Settings
	Local Control Feature Settings (e.g., transfer, conference)
	Alert Settings, including pre-caller alerting
	URIs and timers for additional profile configuration
	Logging Settings
	3.2 Device Data		--Preloaded Route Set
	Elements of the Device Data include:		-- User Address of Record and Display Name - A user'sline
			represents an address-of-record identified by a URL There are many
			properties which may be associated with or should be applied to
			the line or signaling addressed to or from the line. The display
			name is the identifiation as it should appear for the Caller ID
			associated with the user.
	Firmware Upgrade		-- User Authentication Information and Other Credentials -
	SIP Timer Values		Authentication name - name used by the device for authenication
	Response Status Code Handling		if a registration is challenged.
	RTP Parameters		Authenication Password - Password used by the device for
	SDP Payload Types		athentication. The device may have a default logical password
	Audio Configurations		(e.g., MAC IP address).
	Firewall and NAT Support Parameters
	Manual Network Addressing
	Local Administration Settings
	3.3 Environment Data		-- Privacy Settings - calling party presentation restriction.
	The environment data may be inputed by the subscriber or the local		-- Pre Media Configuration Parameters (e.g., Audio Configuration)
	access domain.
	4. IANA Considerations		-- Dial Plan - A dial plan which defines the maximum expected
			length of a typical telephone. Zero or more digit maps that map a
			dial plan and a SIP address to which phone numbers of the type
			should be routed. The digit maps define numeric patterns that when
			matched define:
			1) a rule by which the end point has to judge that the user has
			completed dialing;
			2) a rule to construct a URL from the dialed digits;
			3) Optionally, an outbound proxy to be used in routing the SIP
			INVITE.
			Note: Intra-Digit and Howler tone timers are associated with
			the dial plan.
			The end point must support the configuration of a default digit
			map.
			Some operators support overlap dialing and may want the SIP
			device to operate in that mode.
			-- Progess Tone Settings - These include confirmation, reorder,
			and "ring-ping" type tones.
			-- ENUM Settings - IP address and port address of ENUM server.
			-- International Settings - This may include language preference,
			and default server addreses.
			-- Call Forwarding and Redirection Settings - contains the forward
			to/redirection addresses, conditions of forwarding/redirection,
			and methiods used to forward/redirect.
			-- Speed Dial Settings - users speed dial numbers and associated
			device keys.
			-- Local Control Feature Settings (e.g., transfer, conference) -
			-- Alert Settings, including pre-caller alerting - The manner in
			which a user is alerted to an incoming call (visually, audibly, or
			possibly both) used by a device. This includes different volumes
			and melodies. There may be a pointer to a file to obtain the
			melody. Ringer sound files may be specified to alert the user to
			the type of incoming call (e.g., normal, high priority, internal,
			external).
			-- URIs and timers for additional profile configuration - contains
			URIs of functional specific servers (e.g., Voice Mail, Phonebook,
			Directory).
			-- Logging Settings
			-- Firmware Upgrade
			-- Response Status Code Handling - mapping of response status
			codes to device final handling treatment (e.g., tones and
			annoucements).
			-- Protocol Data Sets - Contains SIP extensions, body types,
			transport protocols (UDP, TCP, TLS, SCTP) or external protocols
			(e.g., http) that need to be supported.
			-- Media Data Set - This includes Codec DATA set, maximum number
			of streams, allowed bandwidth per stream, IPaddresses/ports, etc.
			-- RTP Parameters
			RTP Port Range - A range of port numbers used by a device for
			the consecutive pairs of ports that are used to receive audio
			and ontrol information (RTP and RCTP) for each concurrent
			connection.
			-- SDP Payload Types
			-- Audio Configurations
			-- Firewall and NAT Support Parameters
			NAT Address - WAN IP address of the NAT or firewall server. A
			network address (such as an IP address) used by a device to
			make calls through a NAT. The device includes this IP address
			in the SIP messages and SDP it sends to the other SIP agents to
			indicate that this is the adddress to which SIP, RTP, and RTCP
			packets are be sent. This supports the case where the NAT is
			configured to statically map specific ports on hte external
			interface to a specific end point in side the NAT. The end
			point in turn is configured to spoof other SIP entities into
			thinking it is the external interface on the NAT.
			Manual Network Addressing
			Local Administration Settings
			4. Data Set Examples
			Telephony Prompts, Tones and Final Handling:
			Audio Configurations
			Alert Settings
			International Settings (or at least tones)
			Progess Tone Settings
			Pre Media Configuration Parameters
			Response Status Code Handling
			5. IANA Considerations
	This document introduces no requirements for IANA.		This document introduces no requirements for IANA.
	5. Security Considerations		6. Security Considerations
	Profiles may contain sensitive data such as user credentials. The		Profiles may contain sensitive data such as user credentials. The
	protection of this data depends upon how the data is delivered. If		protection of this data depends upon how the data is delivered. If
	the data is delivered in the NOTIFY body, SIP authentication MUST be		the data is delivered in the NOTIFY body, SIP authentication MUST be
	used for SUBSCRIPTION and SIPS and/or S/MIME MAY be used to encrypt		used for SUBSCRIPTION and SIPS and/or S/MIME MAY be used to encrypt
	the data. If the data is provided via content indirection, SIP		the data. If the data is provided via content indirection, SIP
	authentication is not necessary for the SUBSCRIBE request. With		authentication is not necessary for the SUBSCRIBE request. With
	content indirection the data is protected via the authentication,		content indirection the data is protected via the authentication,
	authorization and encryption mechanisms provided by the profile URL		authorization and encryption mechanisms provided by the profile URL
	scheme. Use of the URL scheme security mechanisms via content		scheme. Use of the URL scheme security mechanisms via content
	indirection simpifies the security solution as the SIP event package		indirection simpifies the security solution as the SIP event package
	does not need to authenticate, authorize or protect the contents of		does not need to authenticate, authorize or protect the contents of
	the SIP messages. Effectively the profile delivery server will		the SIP messages. Effectively the profile delivery server will
	provide profile URL(s) to anyone. The URLs themselves are protected		provide profile URL(s) to anyone. The URLs themselves are protected
	via authentication, authorization and snooping (e.g., via HTTPS).		via authentication, authorization and snooping (e.g., via HTTPS).
	6. Open Issues		7. Open Issues
	This section identifies issues yet to be addressed.		This section identifies issues yet to be addressed.
	7. Change History		8. Change History
	This section identifies changes to the document per draft revision.		This section identifies changes to the document per draft revision.
	8. Examples		9. Examples
	This section is informative in nature. If there is a discrepancy		This section is informative in nature. If there is a discrepancy
	between this section and the normative sections above, the normative		between this section and the normative sections above, the normative
	sections take precedence.		sections take precedence.
	9. References		10. References
	9.1 Normative References		10.1 Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[2] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC		[2] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
	3023, January 2001.		3023, January 2001.
	[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,		[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
	Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:		Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
	Session Initiation Protocol", RFC 3261, June 2002.		Session Initiation Protocol", RFC 3261, June 2002.
	[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event		[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
	Notification", RFC 3265, June 2002.		Notification", RFC 3265, June 2002.
	[5] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom,		[5] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom,
	"Uniform Resource Names (URN) Namespace Definition Mechanisms",		"Uniform Resource Names (URN) Namespace Definition Mechanisms",
	BCP 66, RFC 3406, October 2002.		BCP 66, RFC 3406, October 2002.
	9.2 Informative References		10.2 Informative References
	[6] Petrie, D., "A Framework for SIP User Agent Profile Delivery",		[6] Petrie, D., "A Framework for SIP User Agent Profile Delivery",
	draft-ietf-sipping-config-framework-02.txt (work in progress),		draft-ietf-sipping-config-framework-02.txt (work in progress),
	February 2004.		February 2004.
	[7] Rosenberg, J., "Obtaining and Using Globally Routable User		[7] Rosenberg, J., "Obtaining and Using Globally Routable User
	Agent (UA) URIs (GRUU) in the Session Initiation Protocol		Agent (UA) URIs (GRUU) in the Session Initiation Protocol
	(SIP)", draft-ietf-sip-gruu-01 (work in progress), February		(SIP)", draft-ietf-sip-gruu-01 (work in progress), February
	2004.		2004.
	skipping to change at page 7, line 12 ¶		skipping to change at page 9, line 12 ¶
	Thanks to Eric Burger on the use of the XML tools.		Thanks to Eric Burger on the use of the XML tools.
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to		intellectual property or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it		might or might not be available; neither does it represent that it
	has made any effort to identify any such rights. Information on the		has made any effort to identify any such rights. Information on the
	IETF's procedures with respect to rights in standards-track and		IETF's procedures with respect to rights in standards-track and
	standards-related documentation can be found in BCP-11. Copies of		standards-related documentation can be found in BCP-11. Copies of
	claims of rights made available for publication and any assurances of		claims of rights made available for publication and any assurances of
	licenses to be made available, or the result of an attempt made to		licenses to be made available, or the result of an attempt made to
	obtain a general license or permission for the use of such		obtain a general license or permission for the use of such
	proprietary rights by implementors or users of this specification can		proprietary rights by implementors or users of this specification can
	be obtained from the IETF Secretariat.		be obtained from the IETF Secretariat.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights which may cover technology that may be required to practice		rights which may cover technology that may be required to practice
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF Executive
	Director.		Director.
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for		developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be		copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than		followed, or as required to translate it into languages other than
	English.		English.
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assignees.		revoked by the Internet Society or its successors or assignees.
End of changes. 42 change blocks.
	101 lines changed or deleted		183 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/