< draft-ietf-sip-parameter-registry-01.txt		draft-ietf-sip-parameter-registry-02.txt >
	Internet Engineering Task Force SIP WG		SIP Working Group G. Camarillo
	Internet Draft G. Camarillo		Internet-Draft Ericsson
	Ericsson		Expires: December 15, 2004 June 16, 2004
	draft-ietf-sip-parameter-registry-01.txt
	November 24, 2003
	Expires: May 2004
	The Internet Assigned Number Authority Header Field		The Internet Assigned Number Authority (IANA) Header Field Parameter
	Parameter Registry for the Session Initiation Protocol		Registry for the Session Initiation Protocol (SIP)
			draft-ietf-sip-parameter-registry-02.txt
	STATUS OF THIS MEMO		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		By submitting this Internet-Draft, I certify that any applicable
	all provisions of Section 10 of RFC2026.		patent or other IPR claims of which I am aware have been disclosed,
			and any of which I become aware will be disclosed, in accordance with
			RFC 3668.
	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 Internet-		groups may also distribute working documents as Internet-Drafts.
	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.
	To view the list Internet-Draft Shadow Directories, see		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 December 15, 2004.
			Copyright Notice
			Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	This document creates an IANA registry for SIP header field		This document creates an IANA registry for SIP header field
	parameters. It also lists the already existing parameters to be used		parameters and parameter values. It also lists the already existing
	as initial values for that registry.		parameters and parameter values to be used as the initial entries for
			this registry.
	Table of Contents		Table of Contents
	1 Introduction ........................................ 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2 Terminology ......................................... 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3 Use of the Registry ................................. 3		3. Use of the Registry . . . . . . . . . . . . . . . . . . . . . 3
	4 IANA Considerations ................................. 3		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
	4.1 Header Field Parameters Sub-Registry ................ 4		4.1 Header Field Parameters Sub-Registry . . . . . . . . . . . 4
	4.2 Registration Policy for SIP Header Field		4.2 Registration Policy for SIP Header Field Parameters . . . 7
	Parameters .......................................... 4		5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	5 Security Considerations ............................. 4		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
	6 Acknowledgements .................................... 4		7. Normative References . . . . . . . . . . . . . . . . . . . . . 8
	7 Authors' Addresses .................................. 4		Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8
	8 Normative References ................................ 4		Intellectual Property and Copyright Statements . . . . . . . . 9
	9 Informative References .............................. 5
	1 Introduction		1. Introduction
	RFC3261 [1] allows new header field parameters to be defined.		RFC 3261 [3] allows new header field parameters and new parameter
	However, RFC3261 omitted an IANA registry for them. This document		values to be defined. However, RFC3261 omitted an IANA registry for
	creates such a registry.		them. This document creates such a registry.
	2 Terminology		RFC 3427 [4] documents the process to extend SIP. This document
			updates RFC 3427 by specifying how to define and register new SIP
			header field parameters and parameter values.
			2. Terminology
	In this document, the key words "MUST", "MUST NOT", "REQUIRED",		In this document, the key words "MUST", "MUST NOT", "REQUIRED",
	"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",		"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
	and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and		RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
	indicate requirement levels for compliant SIP implementations.		described in BCP 14, RFC 2119 [1] and indicate requirement levels for
			compliant implementations.
	3 Use of the Registry		3. Use of the Registry
	SIP header field parameters MUST be documented in an RFC in order to		SIP header field parameters and parameter values MUST be documented
	be registered by IANA. This documentation MUST fully explain the		in an RFC in order to be registered by IANA. This documentation MUST
	syntax, intended usage and semantics of the parameter. The intent of		fully explain the syntax, intended usage and semantics of the
	this requirement is to assure inetroperability between independent		parameter or parameter value. The intent of this requirement is to
	implementations, and to prevent accidental namespace collisions		assure interoperability between independent implementations, and to
	between implementations of dissimialr features.		prevent accidental namespace collisions between implementations of
			dissimilar features.
	RFCs defining SIP header field parameters MUST register them with		Note that this registry, unlike other protocol registries, only
	IANA as described below.		deals with parameters and parameter values defined in RFCs (i.e.,
			it lacks a vendor-extension tree). RFC 3427 [4] documents concerns
			with regards to new SIP extensions which may be damaging towards
			security, greatly increase the complexity of the protocol, or
			both. New parameters and parameter values need to be documented in
			RFCs as a result of these concerns.
	Registered SIP header field parameters are to be considered "reserved		RFCs defining SIP header field parameters or parameter values MUST
	words". In order to preserve interoperability, registered parameters		register them with IANA as described below.
	MUST be used in a manner consistent with that described in their
	defining RFC. Implementations MUST NOT utilize "private" or "locally		Registered SIP header field parameters and parameter values are to be
	defined" SIP header field parameters that conflict with registered		considered "reserved words". In order to preserve interoperability,
			registered parameters and parameter values MUST be used in a manner
			consistent with that described in their defining RFC. Implementations
			MUST NOT utilize "private" or "locally defined" SIP header field
			parameters or parameter values that conflict with registered
	parameters.		parameters.
	Note that although unregistered SIP header field parameters		Note that although unregistered SIP header field parameters and
	may be used in implementations, developers are cautioned		parameter values may be used in implementations, developers are
	that usage of such parameters is risky. New SIP header		cautioned that usage of such parameters is risky. New SIP header
	field parameters may be registered at any time, and there		field parameters and parameter values may be registered at any
	is no assurance that these new registered URI parameters		time, and there is no assurance that these new registered
	will not conflict with unregistered parameters currently in		parameters or parameter values will not conflict with unregistered
	use.		parameters currently in use.
	4 IANA Considerations		Some SIP header field parameters only accept a set of predefined
			parameter values. For example, a parameter indicating the transport
			protocol in use may only accept as valid values the predefined tokens
			TCP, UDP, and SCTP. Registering all parameter values for all SIP
			header field parameters of this type would require a large number of
			subregistries. Instead, we have chosen to register parameter values
			by reference. That is, the entry in the parameter registry for a
			given header field parameter contains references to the RFCs defining
			new values of the parameter. References to RFCs defining parameter
			values appear in brackets in the registry.
	Section 27 of RFC 3261 [1] creates an IANA registry for method names,		So, the header field parameter registry contains a column that
			indicates whether or not each parameter only accepts a set of
			predefined values. Implementers of parameters with a "yes" in that
			column need to find all the valid parameter values in the RFCs
			provided as references.
			4. IANA Considerations
			Section 27 of RFC 3261 [3] creates an IANA registry for method names,
	header field names, warning codes, status codes, and option tags.		header field names, warning codes, status codes, and option tags.
	This specification instructs the IANA to create a new sub-registry		This specification instructs the IANA to create a new sub-registry
	under http://www.iana.org/assignments/sip-parameters:		for header field parameters under
	o Header Field Parameters		http://www.iana.org/assignments/sip-parameters:
	4.1 Header Field Parameters Sub-Registry		4.1 Header Field Parameters Sub-Registry
	The majority of the SIP header fields can be extended by defining new		The majority of the SIP header fields can be extended by defining new
	parameters. New SIP header field parameters are registered by the		parameters. New SIP header field parameters are registered by the
	IANA. When registering a new parameter for a header field, the		IANA. When registering a new parameter for a header field or a new
	following information MUST be provided.		value for a parameter, the following information MUST be provided.
	o Header field in which the parameter can appear.
	o Name of the parameter.
	o A reference to the RFC were the parameter is defined.		o Header field in which the parameter can appear.
			o Name of the header field parameter being registered.
			o Whether the parameter only accepts a set of predefined values.
			o A reference to the RFC where the parameter is defined and to any
			RFC that defines new values for the parameter. References to RFCs
			defining parameter values appear in brackets in the registry.
	Parameters that can appear in different header fields MAY have the		Parameters that can appear in different header fields MAY have the
	same name. However, parameters that can appear in the same header		same name. However, parameters that can appear in the same header
	field MUST have different names.		field MUST have different names.
	Table 1 contains the initial values for this sub-registry.		The following are the initial values for this sub-registry.
	4.2 Registration Policy for SIP Header Field Parameters		Header Field Parameter Name Predefined Reference
			Values
			___________________________________________________________
			Accept q No RFC 3261
			Accept-Encoding q No RFC 3261
			Accept-Language q No RFC 3261
			Authorization algorithm Yes RFC 3261
			[RFC 3310]
			Authorization auts No RFC 3310
			Authorization cnonce No RFC 3261
			Authorization nc No RFC 3261
			Authorization nonce No RFC 3261
			Authorization opaque No RFC 3261
			Authorization qop Yes RFC 3261
			Authorization realm No RFC 3261
			Authorization response No RFC 3261
			Authorization uri No RFC 3261
			Authorization username No RFC 3261
			Authentication-Info cnonce No RFC 3261
			Authentication-Info nc No RFC 3261
			Authentication-Info nextnonce No RFC 3261
			Authentication-Info qop Yes RFC 3261
			Authentication-Info rspauth No RFC 3261
			Call-Info purpose Yes RFC 3261
			Contact expires No RFC 3261
			Contact q No RFC 3261
			Content-Disposition handling Yes RFC 3261
			Event id No RFC 3265
			From tag No RFC 3261
			P-Access-Network-Info cgi-3gpp No RFC 3455
			P-Access-Network-Info utran-cell-id-3gpp No RFC 3455
			P-Charging-Function-Addresses ccf No RFC 3455
			P-Charging-Function-Addresses ecf No RFC 3455
			P-Charging-Vector icid-value No RFC 3455
			P-Charging-Vector icid-generated-at No RFC 3455
			P-Charging-Vector orig-ioi No RFC 3455
			P-Charging-Vector term-ioi No RFC 3455
			P-DCS-Billing-Info called No RFC 3603
			P-DCS-Billing-Info calling No RFC 3603
			P-DCS-Billing-Info charge No RFC 3603
			P-DCS-Billing-Info locroute No RFC 3603
			P-DCS-Billing-Info rksgroup No RFC 3603
			P-DCS-Billing-Info routing No RFC 3603
			P-DCS-LAES content No RFC 3603
			P-DCS-LAES key No RFC 3603
			P-DCS-Redirect count No RFC 3603
			P-DCS-Redirect redirector-uri No RFC 3603
			Proxy-Authenticate algorithm Yes RFC 3261
			[RFC 3310]
			Proxy-Authenticate domain No RFC 3261
			Proxy-Authenticate nonce No RFC 3261
			Proxy-Authenticate opaque No RFC 3261
			Proxy-Authenticate qop Yes RFC 3261
			Proxy-Authenticate realm No RFC 3261
			Proxy-Authenticate stale Yes RFC 3261
			Proxy-Authorization algorithm Yes RFC 3261
			[RFC 3310]
			Proxy-Authorization auts No RFC 3310
			Proxy-Authorization cnonce No RFC 3261
			Proxy-Authorization nc No RFC 3261
			Proxy-Authorization nonce No RFC 3261
			Proxy-Authorization opaque No RFC 3261
			Proxy-Authorization qop Yes RFC 3261
			Proxy-Authorization realm No RFC 3261
			Proxy-Authorization response No RFC 3261
			Proxy-Authorization uri No RFC 3261
			Proxy-Authorization username No RFC 3261
			Reason cause Yes RFC 3326
			Reason text No RFC 3326
			Retry-After duration No RFC 3261
			Security-Client alg Yes RFC 3329
			Security-Client ealg Yes RFC 3329
			Security-Client d-alg Yes RFC 3329
			Security-Client d-qop Yes RFC 3329
			Security-Client d-ver No RFC 3329
			Security-Client mod Yes RFC 3329
			Security-Client port1 No RFC 3329
			Security-Client port2 No RFC 3329
			Security-Client prot Yes RFC 3329
			Security-Client q No RFC 3329
			Security-Client spi No RFC 3329
			Security-Server alg Yes RFC 3329
			Security-Server ealg Yes RFC 3329
			Security-Server d-alg Yes RFC 3329
			Security-Server d-qop Yes RFC 3329
			Security-Server d-ver No RFC 3329
			Security-Server mod Yes RFC 3329
			Security-Server port1 No RFC 3329
			Security-Server port2 No RFC 3329
			Security-Server prot Yes RFC 3329
			Security-Server q No RFC 3329
			Security-Server spi No RFC 3329
			Security-Verify alg Yes RFC 3329
			Security-Verify ealg Yes RFC 3329
			Security-Verify d-alg Yes RFC 3329
			Security-Verify d-qop Yes RFC 3329
			Security-Verify d-ver No RFC 3329
			Security-Verify mod Yes RFC 3329
			Security-Verify port1 No RFC 3329
			Security-Verify port2 No RFC 3329
			Security-Verify prot Yes RFC 3329
			Security-Verify q No RFC 3329
			Security-Verify spi No RFC 3329
			Subscription-State expires No RFC 3265
			Subscription-State reason Yes RFC 3265
			Subscription-State retry-after No RFC 3265
			To tag No RFC 3261
			Via branch No RFC 3261
			Via comp Yes RFC 3486
			Via maddr No RFC 3261
			Via received No RFC 3261
			Via rport No RFC 3581
			Via ttl No RFC 3261
			WWW-Authenticate algorithm Yes RFC 3261
			[RFC 3310]
			WWW-Authenticate domain Yes RFC 3261
			WWW-Authenticate nonce No RFC 3261
			WWW-Authenticate opaque No RFC 3261
			WWW-Authenticate qop Yes RFC 3261
			WWW-Authenticate realm No RFC 3261
			WWW-Authenticate stale Yes RFC 3261
	As per the terminology in RFC 2434 [3], the registration policy for		4.2 Registration Policy for SIP Header Field Parameters
	SIP header field parameters shall be "Specification Required".
	For the purposes of this registry, the parameter for which IANA		As per the terminology in RFC 2434 [2], the registration policy for
	registration is requested MUST be defined by an RFC. There is no		SIP header field parameters and parameter values shall be
	requirement that this RFC be standards-track.		"Specification Required".
	5 Security Considerations		For the purposes of this registry, the parameter or the parameter
			value for which IANA registration is requested MUST be defined by an
			RFC. There is no requirement that this RFC be standards-track.
			5. Security Considerations
	There are no security considerations associated to this document.		There are no security considerations associated to this document.
	6 Acknowledgements		6. Acknowledgements
	Jonathan Rosenberg, Henning Schulzrinne, Rohan Mahy, Dean Willis, Aki		Jonathan Rosenberg, Henning Schulzrinne, Rohan Mahy, Dean Willis, Aki
	Niemi, and Bill Marshall provided useful comments.		Niemi, Bill Marshall, Miguel A. Garcia-Martin, Jean Francois Mule,
			and Allison Mankin provided useful comments.
	7 Authors' Addresses		7 Normative References
	Gonzalo Camarillo		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Ericsson		Levels", BCP 14, RFC 2119, March 1997.
	Advanced Signalling Research Lab.
	FIN-02420 Jorvas
	Finland
	electronic mail: Gonzalo.Camarillo@ericsson.com
	8 Normative References		[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
			Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
	[1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J.		[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
	Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session		Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
	initiation protocol," RFC 3261, Internet Engineering Task Force, June		Session Initiation Protocol", RFC 3261, June 2002.
	2002.
	[2] S. Bradner, "Key words for use in RFCs to indicate requirement		[4] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B.
	levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.		Rosen, "Change Process for the Session Initiation Protocol
			(SIP)", BCP 67, RFC 3427, December 2002.
	[3] T. Narten and H. Alvestrand, "Guidelines for writing an IANA		Author's Address
	considerations section in RFCs," RFC 2434, Internet Engineering Task
	Force, Oct. 1998.
	9 Informative References		Gonzalo Camarillo
			Ericsson
			Hirsalantie 11
			Jorvas 02420
			Finland
			EMail: Gonzalo.Camarillo@ericsson.com
			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 Rights 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; nor does it represent that it has
	has made any effort to identify any such rights. Information on the		made any independent effort to identify any such rights. Information
	IETF's procedures with respect to rights in standards-track and		on the IETF's procedures with respect to rights in IETF Documents can
	standards-related documentation can be found in BCP-11. Copies of		be found in BCP 78 and BCP 79.
	claims of rights made available for publication and any assurances of
	licenses to be made available, or the result of an attempt made to		Copies of IPR disclosures made to the IETF Secretariat and any
	obtain a general license or permission for the use of such		assurances of licenses to be made available, or the result of an
	proprietary rights by implementors or users of this specification can		attempt made to obtain a general license or permission for the use of
	be obtained from the IETF Secretariat.		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		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 that may cover technology that may be required to implement
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF at
	Director.		ietf-ipr@ietf.org.
	Full Copyright Statement
	Copyright (c) The Internet Society (2003). All Rights Reserved.		Disclaimer of Validity
	This document and translations of it may be copied and furnished to		This document and the information contained herein are provided on an
	others, and derivative works that comment on or otherwise explain it		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	or assist in its implementation may be prepared, copied, published		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	and distributed, in whole or in part, without restriction of any		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	kind, provided that the above copyright notice and this paragraph are		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	included on all such copies and derivative works. However, this		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	document itself may not be modified in any way, such as by removing		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	the copyright notice or references to the Internet Society or other
	Header Field Parameter Name Reference
	____________________________________________________________
	Accept q RFC 3261
	Accept-Encoding q RFC 3261
	Accept-Language q RFC 3261
	Authorization algorithm RFC 3261
	Authorization cnonce RFC 3261
	Authorization nc RFC 3261
	Authorization nonce RFC 3261
	Authorization opaque RFC 3261
	Authorization qop RFC 3261
	Authorization realm RFC 3261
	Authorization response RFC 3261
	Authorization uri RFC 3261
	Authorization username RFC 3261
	Authentication-Info cnonce RFC 3261
	Authentication-Info nc RFC 3261
	Authentication-Info nextnonce RFC 3261
	Authentication-Info qop RFC 3261
	Authentication-Info rspauth RFC 3261
	Call-Info purpose RFC 3261
	Contact expires RFC 3261
	Contact q RFC 3261
	Content-Disposition handling RFC 3261
	Event id RFC 3265
	From tag RFC 3261
	P-Charging-Function-Addresses ccf RFC 3455
	P-Charging-Function-Addresses ecf RFC 3455
	P-Charging-Vector icid-value RFC 3455
	P-Charging-Vector icid-generated-at RFC 3455
	P-Charging-Vector orig-ioi RFC 3455
	P-Charging-Vector term-ioi RFC 3455
	P-DCS-Billing-Info called RFC 3603
	P-DCS-Billing-Info calling RFC 3603
	P-DCS-Billing-Info charge RFC 3603
	P-DCS-Billing-Info locroute RFC 3603
	P-DCS-Billing-Info rksgroup RFC 3603
	P-DCS-Billing-Info routing RFC 3603
	P-DCS-LAES content RFC 3603
	P-DCS-LAES key RFC 3603
	P-DCS-Redirect count RFC 3603
	P-DCS-Redirect redirector-uri RFC 3603
	Proxy-Authenticate algorithm RFC 3261
	Proxy-Authenticate domain RFC 3261
	Proxy-Authenticate nonce RFC 3261
	Proxy-Authenticate opaque RFC 3261
	Proxy-Authenticate qop RFC 3261
	Proxy-Authenticate realm RFC 3261
	Reason text RFC 3326
	Retry-After duration RFC 3261
	Security-Client alg RFC 3329
	Security-Client ealg RFC 3329
	Security-Client d-alg RFC 3329
	Security-Client d-qop RFC 3329
	Security-Client d-ver RFC 3329
	Security-Client mod RFC 3329
	Security-Client port1 RFC 3329
	Security-Client port2 RFC 3329
	Security-Client prot RFC 3329
	Security-Client q RFC 3329
	Security-Client spi RFC 3329
	Security-Server alg RFC 3329
	Security-Server ealg RFC 3329
	Security-Server d-alg RFC 3329
	Security-Server d-qop RFC 3329
	Security-Server d-ver RFC 3329
	Security-Server mod RFC 3329
	Security-Server port1 RFC 3329
	Security-Server port2 RFC 3329
	Security-Server prot RFC 3329
	Security-Server q RFC 3329
	Security-Server spi RFC 3329
	Security-Verify alg RFC 3329
	Security-Verify ealg RFC 3329
	Security-Verify d-alg RFC 3329
	Security-Verify d-qop RFC 3329
	Security-Verify d-ver RFC 3329
	Security-Verify mod RFC 3329
	Security-Verify port1 RFC 3329
	Security-Verify port2 RFC 3329
	Security-Verify prot RFC 3329
	Security-Verify q RFC 3329
	Security-Verify spi RFC 3329
	Subscription-State expires RFC 3265
	Subscription-State reason RFC 3265
	Subscription-State retry-after RFC 3265
	To tag RFC 3261
	Via branch RFC 3261
	Via comp RFC 3486
	Via maddr RFC 3261
	Via received RFC 3261
	Via rport RFC 3581
	Via ttl RFC 3261
	WWW-Authenticate algorithm RFC 3261
	WWW-Authenticate domain RFC 3261
	WWW-Authenticate nonce RFC 3261
	WWW-Authenticate opaque RFC 3261
	WWW-Authenticate qop RFC 3261
	WWW-Authenticate realm RFC 3261
	Table 1: IANA SIP header field parameter sub-registry		Copyright Statement
	Internet organizations, except as needed for the purpose of		Copyright (C) The Internet Society (2004). This document is subject
	developing Internet standards in which case the procedures for		to the rights, licenses and restrictions contained in BCP 78, and
	copyrights defined in the Internet Standards process must be		except as set forth therein, the authors retain all their rights.
	followed, or as required to translate it into languages other than
	English.
	The limited permissions granted above are perpetual and will not be		Acknowledgment
	revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on an		Funding for the RFC Editor function is currently provided by the
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		Internet Society.
	TASK FORCE DISCLAIMS 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.
End of changes. 51 change blocks.
	234 lines changed or deleted		296 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/