SIPPING D. Petrie
Internet-Draft SIPez LLC.
Intended status: Standards Track S. Channabasappa
Expires: May 20, 2008 CableLabs
S. Ganesan
Motorola
November 17, 2007
The Session Initiation Protocol User Agent Identity Profile Data Set
draft-petrie-sipping-identity-dataset-02.txt
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 May 20, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document defines the properties and data format for the SIP user
agent identity profile data set. The properties in this data set
define identities or SIP address of records (AORs) related to
incoming or outgoing SIP signaling on a user agent. The identities
may be those that are registered via the SIP REGISTER method or
Petrie, et al. Expires May 20, 2008 [Page 1]
Internet-Draft SIP UA Data Set November 2007
identities which are provisioned on the user agent. These identities
may be used or referenced when defining identity specific handling
related to SIP features on the user agent.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Terminology . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SIP Identity Data Set . . . . . . . . . . . . . . . . . . . . 5
3.1. sipIdentity Element . . . . . . . . . . . . . . . . . . . 6
3.2. aor Element . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. locationRegistration Element . . . . . . . . . . . . . . . 7
3.4. registerPeriod Element . . . . . . . . . . . . . . . . . . 7
3.5. qValue Element . . . . . . . . . . . . . . . . . . . . . . 7
3.6. sipCredential Element . . . . . . . . . . . . . . . . . . 7
3.6.1. realm Element . . . . . . . . . . . . . . . . . . . . 8
3.6.2. authUser Element . . . . . . . . . . . . . . . . . . . 8
3.6.3. a1Digest Element . . . . . . . . . . . . . . . . . . . 8
3.6.4. password Element . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5.1. Content-type registration for 'application/uapid+xml' . . 9
6. Change History . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Changes from draft-petrie-sipping-identity-dataset-01 . . 10
6.2. Changes from draft-petrie-sipping-identity-dataset-00 . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informational References . . . . . . . . . . . . . . . . . 11
Appendix A. SIP Identity Dataset Schema . . . . . . . . . . . . . 12
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Petrie, et al. Expires May 20, 2008 [Page 2]
Internet-Draft SIP UA Data Set November 2007
1. Introduction
[I-D.ietf-sipping-config-framework] defines a configuration framework
for finding, retrieving and change notification of profile data for
SIP [RFC3261] user agents. It is intended that the identity dataset
defined in this document may be contained in the user and device
profiles described in the configuration framework.
[I-D.petrie-sipping-profile-datasets] defines a general XML schema to
contain user agent profile data. This document defines identity
specific data by extending the profile data sets schema.
In this document we define properties and XML schema which allow the
definition of SIP identities, whether an identity should be
registered with the SIP [RFC3261] REGISTER method and how. In
addition credential properties related to the identities need to
support SIP DIGEST authentication are defined. The information
contained in the identity data set is intended to be sufficient to
enable the user agent to store and/or retrieve the users' (or
identities') certificates and private keys from the Credential
Service as defined in [I-D.ietf-sipping-certs]. Certificate
management where the certificate or private key for an identity is
contained directly in a user agent profile is out of scope for this
document.
This document defines the properties and XML schema for the SIP user
agent identity profile data set. The following XML elements are
defined to contain the identity properties in this document:
sipIdentity
aor
locationRegistration
registerPeriod
qValue
sipCredential
realm
authUser
a1Digest
password
1.1. Requirements Terminology
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
"MAY" that appear in this document are to be interpreted as described
in RFC 2119[RFC2119].
2. Overview
The sipIdentity element is the container for all of the properties
Petrie, et al. Expires May 20, 2008 [Page 3]
Internet-Draft SIP UA Data Set November 2007
related to a specific identity or AOR. The identities defined in
sipIdentity element(s) define identities for inbound or outbound SIP
signaling from the user agent. The use of the data contained in the
sipIdentity element is intended to be independent from the particular
SIP application (e.g. VoIP, IM or presence). From a VoIP
perspective, the sipIdentity is similar to a line definition.
However the sipIdentity element is not intended to contain all of the
VoIP or call handling feature options and properties. The
sipIdentity element has an id attribute which can be used when
defining identity specific feature behavior. The definition of
identity specific feature properties is out of scope of this
document. The sipIdentity attribute "id" is defined to enable
feature properties to reference the identity(s) to which they are
specific.
The identity data set provides the ability to define which AORs to
enable on a user agent and whether to register the AOR. It also
associates SIP digest authentication credentials with the AOR that
the user agent may used when challenged. [SIP] specifies that a UAS
should reject incoming requests if "the Request-URI does not identify
an address that the UAS is willing to accept requests for". The
identity data set provides a means to define the identities for the
addresses that the UAS should accept.
The sipIdentity element is considered to be atomic when it comes to
merging. That is all sipIdentity elements are taken in whole from
the user and device profiles obtained via the ua-profile event
package. If duplicate AORs are found the one which occurred first
when looking through the device and then user profiles is used and
subsequent, duplicate sip-identity elements are ignored. [need
reference for AOR comparison in 3261]. User agents that support a
limited number of identities use the first N unique sipIdentity
elements when searching through the profiles in the order described
above, where N is the number of identities the user agent can
support.
The following excerpt of a SIP user agent profile is an example of
the SIP identity data set.
Petrie, et al. Expires May 20, 2008 [Page 4]
Internet-Draft SIP UA Data Set November 2007
<sipIdentity id="home">
<aor>"Alice Jones"<alice@home.example.com></aor>
<locationRegistration>true</locationRegistration>
<registerPeriod>3600</registerPeriod>
<sipCredential>
<realm>home.example.com</realm>
<authUser>alice</auth-user>
<a1Digest>670d8b81e3de71980a1f0a757c0f4273</a1Digest>
</sipCredential>
<sipCredential>
<realm>myhomeserviceprovider.com</realm>
<authUser>alice.jones</authUser>
<a1Digest>9da610b04b2b76bd7c3cfae84b6f9eee</a1Digest>
</sipCredential>
</sipIdentity>
<sipIdentity id="work" default="outbound">
<aor>
"Alice Jones"<alice@work.example.com;transport=TLS>
</aor>
<locationRegistration>true</should-register>
<registerPeriod>45</registerPeriod>
<qValue>1.0</qValue>
<sipCredential>
<realm>work.example.com</realm>
<authUser>alice</authUser>
<a1Digest>670d8b81e3de71980a1f0a757c0f4273</a1Digest>
</sipCredential>
</sipIdentity>
In the above example the user has two identities. Both of these
identities may be contained in the user or device profile or one
identity could be in the device profile and the other in the user
profile. Both identities have an id attribute which serves as a
unique label or handle for the identity. In this example case the
first identity has an id of "home" the second has the id of "work".
The id attribute values are only text labels and have no semantic
meaning. How this particular user got two identities in their
profile is a profile delivery server implementation issue and is out
of scope of this document.
3. SIP Identity Data Set
The XML schema defined in this document extends the root element
"property_set" schema defined in
[I-D.petrie-sipping-profile-datasets].
Petrie, et al. Expires May 20, 2008 [Page 5]
Internet-Draft SIP UA Data Set November 2007
3.1. sipIdentity Element
sipIdentity - This element contains properties related to a specific
SIP identity or AOR. It is an XML element that extends on the XML
"setting_container" element contained in the root "property_set"
element. There MAY be zero or more sipIdentity elements in a
property_set element. The sipIdentity elements MAY appear in
multiple profile (e.g. device and user).
The sipIdentity element MUST contain one aor and locationRegistration
element. The sipIdentity element MAY contain zero or one
registerPeriod, zero or one qValue, and zero or more sipCredential
elements. Contained in property_set.
sipIdentity has two attributes: id and default. - type string.
default - indicates this is the default line to for outbound, inbound
or both directions.
id - is a label of type string (default value: ""). This label MAY
be used by other user agent features to specify behavior that is
specific to a particular identity. For example a call handling
feature such as "do not disturb" might be enabled for inbound
calls to a specific identity. The properties for the "do not
disturb" feature could reference which identity using the string
in the "id" attribute. The "id" attribute is specified in this
document, but user agent feature properties which use the "id"
attribute (such as "do not disturb") are out of scope of this
document.
default - specifies that the identity contained in this sipIdentity
element is to be used as the default identity (default value: "").
Possible values: "inbound", "outbound", "both". No value
indicates that this identity should only be used when specifically
addressed by the inbound signaling or as indicated by the user for
outbound initiated signaling. A value of "inbound" means that
this identity should be used for inbound signaling that does not
match any of the other identities defined in other sipIdentity
element. A value of "inbound" also indicates that the user agent
should accept incoming signaling that is not addressed to a
specific identity defined in a sipIdentity element. A value of
"outbound" indicates that the user agent should use this identity
as the default for outbound SIP signaling. A value of "both" is
the equivalent of "inbound" and "outbound" There SHOULD be at most
one sipIdentity element with a "default" attribute of "inbound"
and at most one with a value of "outbound" or one with a value of
"both". If more than one sipIdentity has the "default" attribute
to indicate that it is the default for inbound or outbound
signaling, the first occurrence is used when searching through the
device and then user profiles.
Petrie, et al. Expires May 20, 2008 [Page 6]
Internet-Draft SIP UA Data Set November 2007
3.2. aor Element
The "aor" element is contained in the sipIdentity element. The aor
element specifies the SIP address of record for the identity. The
value of the aor element is in the form of the name-addr ABNF
construct defined in SIP [RFC3261]. It is important to note that the
name-addr construct may contain a display name, URI parameters and
SIP message header parameters. The user agent SHOULD include these
parameters when constructing a Contact header for registration (if
this identity is to be registered). Exactly one aor element SHOULD
be contained in a sipIdentity element.
3.3. locationRegistration Element
The "locationRegistration" element is used to indicate whether the
user agent is to register the local Contact for this identity using
the SIP [RFC3261] REGISTER method. A value of "register" indicates
that the user agent SHOULD register a Contact for this identity. A
value of "provisioned" indicates that the Contact is provisioned in
the network and that the user agent SHOULD NOT register a Contact
(Default value: "register"). Exactly one locationRegistration
element SHOULD be contained in a sipIdentity element.
3.4. registerPeriod Element
The registerPeriod element MAY be used to indicate the Expiration
header value in seconds to use in REGISTER requests for this
identity. This element is ignored unless the locationRegistration
element indicates that the user agent SHOULD register. The value of
the registerPeriod element SHOULD be an integer greater than 1.
(Default value: 3600) Zero or one registerPeriod element MAY be
contained in a sipIdentity element.
3.5. qValue Element
The qValue element contains the value that SHOULD be used in the q
field parameter of the Contact header when sending REGISTER request
for this identity. Zero or one qValue element MAY be included in the
sipIdentity element. The qValue element is meaningless unless the
locationRegistration indicates that the user agent should register a
contact. The value of the qValue element is a decimal number between
1.0 and 0.0 (the legal values for the qvalue ABNF construct in
[RFC3261])
3.6. sipCredential Element
The sipCredential element contains the credentials for performing SIP
[RFC3261] digest authentication related to a single realm. As it is
Petrie, et al. Expires May 20, 2008 [Page 7]
Internet-Draft SIP UA Data Set November 2007
possible for a user agent to be challenged from multiple realms when
sending SIP requests, zero or more sipCredential elements may be
contained in a sipIdentity element. The user agent SHOULD only use
the credentials contained in the identity that is used for the
outbound request. That is, the user agent SHOULD not use credentials
contained in other sipIdentity elements. The sipCredential element
SHOULD contain exactly one of each of the elements: realm, auth-user
and one of either the a1Digest or password elements.
3.6.1. realm Element
The realm element contains the string that defines the realm to which
this credential pertains. The value of the realm element is the same
as the realm parameter in the [RFC2617] headers: WWW-Authenticate,
Authorization and the SIP [RFC3261] headers: Proxy-Authenticate and
Proxy-Authorization. When the user agent receives a authentication
challenge (401 or 407 response), the user agent looks for a
sipCredential element which contains a realm element that matches the
realm parameter in the authorization response challenge. If a match
of the realm value is found, the user agent uses the values in the
authUser and a1Digest elements contained in the sipCredential
element. Exactly one realm element SHOULD be contained in a
sipCredential element.
3.6.2. authUser Element
The authUser element contains the string value of the username
parameter which SHOULD be used in Authorization and Proxy-
Authorization request headers when retrying a request that was
challenged for authentication. Exactly one authUser element SHOULD
be contained in a sipCredential element.
3.6.3. a1Digest Element
The a1Digest element contains a string with the value of the A1
digest of the username, realm and password as defined in [RFC2617].
At most one a1Digest element MUST be contained in a sipCredential
element. The a1Digest element MUST NOT exist in a sipCredential
element containing a password element. The username and realm used
to construct the value of the a1Digest element MUST match the values
of the realm and authUser elements contained in the sipCredential
element with the a1Digest element.
3.6.4. password Element
The password element contains the clear text password for use with
DIGEST Authentication [RFC2617]. At most one password MUST be
contained in a sipCredential element. The password element MUST NOT
Petrie, et al. Expires May 20, 2008 [Page 8]
Internet-Draft SIP UA Data Set November 2007
exist in a sipCredential element containing a a1Digest element. The
user agent uses this password along with the realm and authUser
elements to calculate the A1 digest used for DIGEST Authentication.
4. Security Considerations
Security is mostly a profile delivery problem. The delivery
framework MUST provide a secure means of delivering the profile data
as it may contain sensitive data that would be undesirable if it were
stolen or sniffed. Storage of the profile on the profile delivery
server and user agent is an implementation problem. The profile
delivery server and the user agent MUST provide protection that
prevents unauthorized access of the profile data. The profile
delivery server and the user agent MUST enforce the access control
policies defined in the profile data sets if present.
5. IANA Considerations
XML name space registration: urn:ietf:params:xml:ns:uaprof:id
5.1. Content-type registration for 'application/uapid+xml'
To: ietf-types@iana.org
Subject: Registration of MIME media type application/uapid+xml
MIME media type name: application
MIME subtype name: uapid+xml
Required parameters: (none)
Optional parameters: charset Indicates the character encoding of
enclosed XML. Default is UTF-8.
Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See RFC
3023 [RFC 3023], section 3.2.
Security considerations: This content type is designed to carry SIP
user agent profile data, which may be considered private
information. Appropriate precautions should be adopted to limit
disclosure of this information.
Interoperability considerations: This content type provides a common
format for exchange of SIP user agent profile information.
Published specification: RFC XXXX (Note to RFC Editor: Please fill
in XXXX with the RFC number of this specification)
Applications which use this media type: SIP user agents and profile
delivery servers.
Petrie, et al. Expires May 20, 2008 [Page 9]
Internet-Draft SIP UA Data Set November 2007
Additional information: Magic number(s): File extension(s):
Macintosh File Type Code(s):
Person & email address to contact for further information: Daniel
Petrie EMail: dan.ietf AT sipez DOT com
Intended usage: LIMITED USE
Author/Change controller: This specification is a proposed work item
of the IETF SIPPING working group, with mailing list address:
sipping@ietf.edu.
Other information: This media type is a specialization of
application/xml [RFC 3023], and many of the considerations
described there also apply to application/uapid+xml.
6. Change History
[[RFC Editor: Please remove this entire section upon publication as
an RFC.]]
6.1. Changes from draft-petrie-sipping-identity-dataset-01
Re-revved and activated draft
6.2. Changes from draft-petrie-sipping-identity-dataset-00
Converted the DTD schema to use Relax NG schema.
Defined XML name space for schema: "urn:ietf:params:xml:ns:uaprof:id"
Defined mime type: application/uapid+xml to be used as default
content type for the configuration framework.
Changed names of elements, attributes and other data types which
contained "-" or "_" to use camel case.
Added password element so that credential can contain either A1
digest or clear text password as the clear text password is required
by the user agent in some cases to wildcard the realm.
7. References
7.1. Normative References
[I-D.ietf-sipping-config-framework]
Channabasappa, S., "A Framework for Session Initiation
Protocol User Agent Profile Delivery",
draft-ietf-sipping-config-framework-14 (work in progress),
November 2007.
Petrie, et al. Expires May 20, 2008 [Page 10]
Internet-Draft SIP UA Data Set November 2007
[I-D.petrie-sipping-profile-datasets]
Petrie, D., "A Schema and Guidelines for Defining Session
Initiation Protocol User Agent Profile Datasets",
draft-petrie-sipping-profile-datasets-04 (work in
progress), October 2006.
[RFC2617] 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.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[W3C.REC-xml-20001006]
Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)",
World Wide Web Consortium FirstEdition REC-xml-20001006,
October 2000,
<http://www.w3.org/TR/2000/REC-xml-20001006>.
[W3C.REC-xml-names-19990114]
Hollander, D., Bray, T., and A. Layman, "Namespaces in
XML", World Wide Web Consortium FirstEdition REC-xml-
names-19990114, January 1999,
<http://www.w3.org/TR/1999/REC-xml-names-19990114>.
7.2. Informational References
[I-D.ietf-sipping-certs]
Jennings, C. and J. Peterson, "Certificate Management
Service for The Session Initiation Protocol (SIP)",
draft-ietf-sipping-certs-03 (work in progress),
March 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for
the Use of Extensible Markup Language (XML)
within IETF Protocols", BCP 70, RFC 3470, January 2003.
[W3C.REC-xmlschema-1]
Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
"XML Schema Part 1: Structures", W3C REC-xmlschema-1,
May 2001, <http://www.w3.org/TR/xmlschema-1/>.
Petrie, et al. Expires May 20, 2008 [Page 11]
Internet-Draft SIP UA Data Set November 2007
[W3C.REC-xmlschema-2]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes",
W3C REC-xmlschema-2, May 2001,
<http://www.w3.org/TR/xmlschema-2/>.
Appendix A. SIP Identity Dataset Schema
The following is the Relax NG XML schema for the SIP Identity
dataset.
<?xml version="1.0"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0"
ns="urn:ietf:params:xml:ns:uaprof:id"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<include href="uaprofile.rng">
<define name="ElementGenericSetting">
<ref name="ElementGenericIdSetting"/>
</define>
<define name="ElementGenericSettingContainer">
<ref name="ElementGenericIdSettingContainer"/>
</define>
</include>
<define name="ElementGenericIdSettingContainer">
<element>
<anyName>
<except>
<nsName ns="urn:ietf:params:xml:ns:uaprof"/>
<nsName ns="urn:ietf:params:xml:ns:uaprof:id"/>
<nsName ns=""/>
</except>
</anyName>
<ref name="SettingContainerAttributes"/>
<!-- container can have containers or settings not both -->
<choice>
<zeroOrMore>
<ref name="ElementGenericIdSetting"/>
</zeroOrMore>
<zeroOrMore>
<ref name="ElementGenericIdSettingContainer"/>
</zeroOrMore>
</choice>
</element>
</define>
Petrie, et al. Expires May 20, 2008 [Page 12]
Internet-Draft SIP UA Data Set November 2007
<define name="ElementGenericIdSetting">
<element>
<anyName>
<except>
<nsName ns="urn:ietf:params:xml:ns:uaprof"/>
<nsName ns="urn:ietf:params:xml:ns:uaprof:id"/>
<nsName ns=""/>
</except>
</anyName>
<ref name="SettingAttributes"/>
<zeroOrMore>
<ref name="AttributeGeneric"/>
</zeroOrMore>
<zeroOrMore>
<choice>
<text/>
<ref name="ElementGenericIdSetting"/>
</choice>
</zeroOrMore>
</element>
</define>
<!-- Extend elements in root/propertySet -->
<define name="PropertySetExtension" combine="interleave">
<zeroOrMore>
<ref name="ElementSipIdentity"/>
</zeroOrMore>
</define>
<define name="ElementSipIdentity">
<element name="sipIdentity">
<optional>
<attribute name="id">
<text/>
</attribute>
</optional>
<optional>
<attribute name="default">
<choice>
<value/><!-- default is both -->
<value>both</value>
<value>outbound</value>
<value>inbound</value>
</choice>
</attribute>
</optional>
<zeroOrMore>
<ref name="AttributeGeneric"/>
</zeroOrMore>
Petrie, et al. Expires May 20, 2008 [Page 13]
Internet-Draft SIP UA Data Set November 2007
<ref name="ElementAor"/>
<optional>
<ref name="ElementLocationRegistration"/>
</optional>
<optional>
<ref name="ElementRegisterPeriod"/>
</optional>
<optional>
<ref name="ElementQValue"/>
</optional>
<zeroOrMore>
<ref name="ElementSipCredential"/>
</zeroOrMore>
</element>
</define>
<define name="ElementAor">
<element name="aor">
<zeroOrMore>
<ref name="AttributeGeneric"/>
</zeroOrMore>
<!--<ref name="DataSipNameAddr"/>-->
<text/>
</element>
</define>
<define name="ElementLocationRegistration">
<element name="locationRegistration">
<choice>
<value></value><!-- defaults to true -->
<value>true</value>
<value>false</value>
</choice>
</element>
</define>
<define name="ElementRegisterPeriod">
<element name="registerPeriod">
<zeroOrMore>
<ref name="AttributeGeneric"/>
</zeroOrMore>
<data type="integer">
<param name="minInclusive">25</param>
</data>
</element>
</define>
<define name="ElementQValue">
<element name="qValue">
<data type="float">
<param name="minInclusive">0</param>
<param name="maxInclusive">1.0</param>
Petrie, et al. Expires May 20, 2008 [Page 14]
Internet-Draft SIP UA Data Set November 2007
</data>
</element>
</define>
<define name="ElementSipCredential">
<element name="sipCredential">
<zeroOrMore>
<ref name="AttributeGeneric"/>
</zeroOrMore>
<ref name="DataCredential"/>
</element>
</define>
</grammar>
Note: delta-seconds, name-addr, qvalue, realm-value, username-value
are defined in the ABNF for SIP [RFC3261].
Appendix B. Acknowledgments
Authors' Addresses
Daniel Petrie
SIPez LLC.
34 Robbins Rd.
Arlington, MA 02476
US
Phone: +1 617 273 4000
Email: dan.ietf@SIPez.com
URI: http://www.sipez.com/
Sumanth Channabasappa
CableLabs
858 Coal Creek Circle
Louisville, CO 80027
US
Phone:
Email: sumanth@cablelabs.com
URI:
Petrie, et al. Expires May 20, 2008 [Page 15]
Internet-Draft SIP UA Data Set November 2007
Sam Ganesan
Motorola
80 Central Street
Boxborough, MA 01719
US
Phone:
Email: sam.ganesan@motorola.com
URI:
Petrie, et al. Expires May 20, 2008 [Page 16]
Internet-Draft SIP UA Data Set November 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).
Petrie, et al. Expires May 20, 2008 [Page 17]