One document matched: draft-garcia-mmusic-sdp-misc-cap-00.txt
MMUSIC WG M. Garcia-Martin
Internet-Draft Ericsson
Intended status: Standards Track S. Veikkolainen
Expires: April 30, 2009 Nokia
R. Gilman
NDCI
October 27, 2008
Miscellaneous Capabilities Negotiation in the Session Description
Protocol (SDP)
draft-garcia-mmusic-sdp-misc-cap-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 April 30, 2009.
Abstract
SDP has been extended with a capability negotiation mechanism
framework that allows the endpoints to negotiate transport protocols
and attributes. This framework has been extended with a Media
capabilities negotiation mechanism that allows endpoints to negotiate
additional media-related capabilities. This negotiation is embedded
into the widely-used SDP offer/answer procedures.
This memo extends the SDP capability negotiation framework to allow
Garcia-Martin, et al. Expires April 30, 2009 [Page 1]
Internet-Draft Miscellaneous Capabilities in SDP October 2008
endpoints to negotiate a number of miscellaneous SDP capabilities.
In particular, this memo provides a mechanism to negotiate media
titles ("i=" line for each media), connection data ("c=" line), and
media bandwidth ("b=" line).
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 4
3.1. Extensions to SDP . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Bandwidth Capability . . . . . . . . . . . . . . . . . 5
3.1.2. Connection Data Capability . . . . . . . . . . . . . . 7
3.1.3. Information Capability . . . . . . . . . . . . . . . . 9
3.2. Session Level versus Media Level . . . . . . . . . . . . . 11
4. Field Replacement Rules . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
5.1. New SDP Attributes . . . . . . . . . . . . . . . . . . . . 12
5.2. New Option Tags . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Garcia-Martin, et al. Expires April 30, 2009 [Page 2]
Internet-Draft Miscellaneous Capabilities in SDP October 2008
1. Introduction
The Session Description Protocol (SDP) [RFC4566] is intended for
describing multimedia sessions for the purposes of session
announcement, session invitation, and other forms of multimedia
session initiation. SDP has been extended with a capability
negotiation mechanism framework
[I-D.ietf-mmusic-sdp-capability-negotiation] that allows the
endpoints to negotiate capabilities, such as support for Realtime
Transport Protocol (RTP) [RFC3550] and Secure Realtime Transport
Protocol (SRTP) [RFC3711]. The SDP media capabilities
[I-D.ietf-mmusic-sdp-media-capabilities] provides negotiation
capabilities to media lines as well.
This negotiation is embedded into the widely used SDP offer/answer
procedures [RFC3264]. This memo provides the means to negotiate
further capabilities than those specified in the SDP capability
negotiation mechanism framework
[I-D.ietf-mmusic-sdp-capability-negotiation] and the SDP media
capabilities [I-D.ietf-mmusic-sdp-media-capabilities]. In
particular, this memo provides a mechanism to negotiate media titles
("i="), connection data ("c="), and media bandwidth ("b="). It would
have been possible to define a mechanism to negotiate media
encryption keys ("k="). However, the usage of the media encryption
keys ("k=") is highly discouraged in favour of other existing more
sophisticated mechanisms. Therefore, we are not providing a
mechanism to provide capabilities for media encryption keys ("k=") at
this stage.
Since the three added capabilities are highly unconnected, it is not
expected that implementations will support all three at the same
time. Instead, it is expected that applications will choose their
needed capability for their specific purpose. Due to this, we are
writing the normative part pertaining to each capability in a self-
contained section. In particular, Section 3.1.1 describes the
bandwidth capability extension, Section 3.1.2 describes the
connection data capability extension, and Section 3.1.3 describes the
information capability extension. Separate option tags are defined
for each capability.
2. Conventions Used in This Document
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
[RFC2119] and indicate requirement levels for compliant
implementations.
Garcia-Martin, et al. Expires April 30, 2009 [Page 3]
Internet-Draft Miscellaneous Capabilities in SDP October 2008
3. Protocol Description
3.1. Extensions to SDP
The SDP Capability Negotiation Framework
[I-D.ietf-mmusic-sdp-capability-negotiation] and the SDP media
capabilities [I-D.ietf-mmusic-sdp-media-capabilities] specify
attributes for negotiating SDP capabilities. These documents specify
new attributes (e.g., 'acap', 'tcap', 'mcap') for achieving their
purpose. In this document we define a number of new additional
capability attributes for SDP lines of the the general form:
type=value
for types "i", "c", and "b". The corresponding capability attributes
are defined as "icap", "ccap", and "bcap", respectively.
From the sub-rules of "a=" line in SDP [RFC4566], SDP attributes are
of the form:
attribute = (att-field ":" att-value) / att-field
att-field = token
att-value = byte-string
Capability attributes use only the 'att-field:att-value' form.
The new attributes may be referenced in potential configurations
("a=pcfg") or in latent configurations ("a=lcfg"), as productions
conforming to the extension-config-list as defined in
[I-D.ietf-mmusic-sdp-capability-negotiation].
extension-config-list = ["+"] ext-cap-name "="
ext-cap-list
ext-cap-name = 1*(ALPHA / DIGIT)
ext-cap-list = 1*VCHAR ; defined in [RFC4234]
The optional "+" is used to indicate that the entire configuration,
not just the parameter, must be ignored if the parameter is not
supported. The attributes may be referenced in actual configurations
as productions conforming to the sel-extension-config defined in
[I-D.ietf-mmusic-sdp-capability-negotiation].
sel-extension-config = ext-cap-name "=" 1*VCHAR
The specific parameters are defined in the individual description of
each capability, below.
It is not the intention of this work to negotiate these new
Garcia-Martin, et al. Expires April 30, 2009 [Page 4]
Internet-Draft Miscellaneous Capabilities in SDP October 2008
capabilities at the session level, rather only at the media level.
Therefore, capabilities referenced by any configuration attribute
MUST appear at the media level when a configuration is "converted" to
a corresponding media block. For this reason, the "icap" attribute
is called the "media information capability". Specific values for
each new attribute are described below.
3.1.1. Bandwidth Capability
According to RFC 4566 [RFC4566] the bandwidth field denotes the
proposed bandwidth to be used by the session or media. For what it
concerns this memo, we focus on the bandwidth at the media level.
This bandwidth field is specified in RFC 4566 [RFC4566] according to
the following syntax:
b=<bwtype>:<bandwidth>
where <bwtype> is an alphanumeric modifier giving the meaning of the
<bandwidth> figure.
In this document, we define a new capability attribute: the bandwidth
capability attribute "bcap". This attribute lists bandwidth as
capabilities according to the following definition:
"a=bcap:" bw-cap-num 1*WSP bwtype ":" bandwidth CRLF
where <bw-cap-num> is a unique ordinal identifier of the bandwidth
capability, and the other elements are as defined for the "b=" field
in [RFC4566].
This format satisfies the general attribute production rules in
[RFC4566] according to the following Augmented Backus-Naur Form
(ABNF) [RFC5234] syntax:
att-field = "bcap"
att-value = bw-cap-num 1*WSP bwtype ":" bandwidth
bw-cap-num = 1*DIGIT ; integer between 1 and 2^31-1, inclusive
Negotiation of bandwidth per media stream can be useful when
negotiating media encoding capabilities with different bandwidths.
3.1.1.1. Configuration Parameters
The SDP Capability Negotiation Framework
[I-D.ietf-mmusic-sdp-capability-negotiation] provides for the
existence of the "pcfg" and "acfg" attributes, which can carry one or
more potential configurations to be negotiated. The concept is
extended by the the Media Capabilities Negotiation
Garcia-Martin, et al. Expires April 30, 2009 [Page 5]
Internet-Draft Miscellaneous Capabilities in SDP October 2008
[I-D.ietf-mmusic-sdp-media-capabilities] with an "lcfg" attribute
that conveys latent configurations. Extensions to the "pcfg" and
"lcfg" attributes are defined through <extension-config-list>, and
extensions to the "acfg" attribute are defined through the <sel-
extension-config> as defined in
[I-D.ietf-mmusic-sdp-capability-negotiation].
In this document we extend the <extension-config-list> field to be
able to convey lists of bandwidth capabilities in latent or potential
configurations, according to the following Augmented Backus-Naur Form
(ABNF) [RFC5234] syntax:
extension-config-list = bandwidth-config-list
bandwidth-config-list = ["+"] "b=" bw-cap-list *(BAR b-cap-list)
bw-cap-list = bw-cap-num *("," b-cap-num)
bw-cap-num = 1*DIGIT ; 1 to 2^32-1 inclusive
Figure 1: Syntax of the bandwidth parameter in lcfg and pcfg
attributes
Each bandwidth capability configuration is a comma-separated list of
bandwidth capability attribute numbers where 'b-cap-num' refers to
the bw-cap-num bandwidth capability numbers defined explicitly
earlier in this document, and hence must be between 1 and 2^31-1
(both included). Alternative bandwidth configurations are separated
by a vertical bar ("|").
The bandwidth parameter to the actual configuration attribute
("a=acfg") is formulated as a sel-extension-config with
ext-cap-name = "b"
hence
sel-extension-config = sel-bandwidth-config
sel-bandwidth-config = "b=" bw-cap-list ; bw-cap-list as above.
Figure 2: Syntax of the bandwidth parameter in acfg attributes
3.1.1.2. Option tag
The SDP Capability Negotiation Framework
[I-D.ietf-mmusic-sdp-capability-negotiation] solution allows for
capability negotiation extensions to be defined. Associated with
each such extension is an option tag that identifies the extension in
question. Hereby, we define a new option tag of "bcap-v0" that
identifies support for the bandwidth capability. This option tag
Garcia-Martin, et al. Expires April 30, 2009 [Page 6]
Internet-Draft Miscellaneous Capabilities in SDP October 2008
SHOULD be added to other existing option tags present in the "csup"
and "creq" attributes in SDP, according to the procedures defined in
the SDP Capability Negotiation Framework
[I-D.ietf-mmusic-sdp-capability-negotiation].
3.1.2. Connection Data Capability
According to SDP [RFC4566], the connection data field in SDP contains
the connection data, and it has the following syntax:
c=<nettype> <addrtype> <connection-address>
where <nettype> indicates the network type, <addrtype> indicates the
address type, and the <connection-address> is the connection address,
which is dependent on the address type.
At the moment, the only network type defined is "IN", which indicates
Internet network type. The address types "IP4" and "IP6" indicate
the type of IP addresses.
SDP [RFC4566] permits specification of connection data at the session
or at the media level. In order to permit negotiation of connection
data at the media level, we define the connection data capability
attribute ("a=ccap") in the form:
"a=ccap:" conn-cap-num 1*WSP nettype SP addrtype SP connection-
address CRLF
where <conn-cap-num> is a unique ordinal identifier of the connection
data capability, and the other elements are as defined in [RFC4566].
This format corresponds to the [RFC4566] attribute production rules
according to the following Augmented Backus-Naur Form (ABNF)
[RFC5234] syntax:
att-field = "ccap"
att-value = conn-cap-num 1*WSP nettype SP addrtype
SP connection-address
conn-cap-num = 1*DIGIT ; integer between 1 and 2^31-1, inclusive
The connection information capability can be used to negotiate the
use of IPv4 or IPv6 addresses without resort to Interactive
Connectivity Establishment(ICE) [I-D.ietf-mmusic-ice]. Note,
however, that ICE provides for real-time reachability testing of
multiple addresses, whereas use of the connection capability forces
an early choice of connection address.
Garcia-Martin, et al. Expires April 30, 2009 [Page 7]
Internet-Draft Miscellaneous Capabilities in SDP October 2008
3.1.2.1. Configuration Parameters
The SDP Capability Negotiation Framework
[I-D.ietf-mmusic-sdp-capability-negotiation] provides for the
existence of the "pcfg" and "acfg" attributes, which can carry one or
more potential configurations to be negotiated. The concept is
extended by the the Media Capabilities Negotiation
[I-D.ietf-mmusic-sdp-media-capabilities] with an "lcfg" attribute
that conveys latent configurations.
In this document we define a <connection-config> parameter to be used
to specify a connection data capability in a potential or latent
configuration attribute. The parameter follows the form of an
extension-config-list, with
ext-cap-name = "c"
ext-cap-list = conn-cap-list
where, according to the following Augmented Backus-Naur Form (ABNF)
[RFC5234] syntax:
extension-config-list = conn-config-list
conn-config-list = "c=" conn-cap-list
conn-cap-list = conn-cap-num *(BAR conn-cap-num)
conn-cap-num = 1*DIGIT ; 1 to 2^32-1 inclusive
Figure 3: Syntax of the connection data parameter in lcfg and pcfg
attributes
Each capability configuration alternative contains a single
connection data capability attribute number and refers to the conn-
cap-num capability number defined explicitly earlier in this
document, and hence must be between 1 and 2^31-1 (both included).
The connection data capability allows the expression of only a single
capability in each alternative, rather than a list of capabilities,
since no more than a single connection data field is permitted per
media block. Nevertheless, it is still allowed to express
alternative potential connection configurations separated by a
vertical bar ("|").
The connection data parameter to the actual configuration attribute
("a=acfg") is formulated as a sel-extension-config with
ext-cap-name = "c"
hence
Garcia-Martin, et al. Expires April 30, 2009 [Page 8]
Internet-Draft Miscellaneous Capabilities in SDP October 2008
sel-extension-config = sel-connection-config
sel-connection-config = "c=" conn-cap-num ; as defined above.
Figure 4: Syntax of the connection data parameter in acfg attributes
3.1.2.2. Option tag
The SDP Capability Negotiation Framework
[I-D.ietf-mmusic-sdp-capability-negotiation] solution allows for
capability negotiation extensions to be defined. Associated with
each such extension is an option tag that identifies the extension in
question. Hereby, we define a new option tag of "ccap-v0" that
identifies support for the connection data capability. This option
tag SHOULD be added to other existing option tags present in the
"csup" and "creq" attributes in SDP, according to the procedures
defined in the SDP Capability Negotiation Framework
[I-D.ietf-mmusic-sdp-capability-negotiation].
3.1.3. Information Capability
RFC 4566 [RFC4566] provides for the existence of an information field
expressed in the format of the "i=" line, which can appear either at
the session level or at the media level. An "i=" line that is
present at the session level is known as the "session name", and its
purpose is to convey a human-readable textual information about the
session. We don't see much usage of capabilities related to the "i="
line at the session level.
The "i=" line in SDP can also appear at the media level, in which
case it is used to label the media stream it is related to, so that
it indicates the purpose of the media stream. In this case, it is
foreseen that applications declaring capabilities related to
different media lines also need to provide different labels to media
streams that are substantially different. For example, if two media
streams are offered one as alternative to the other, most likely
their associated labels are different. Hence, there is value in
defining a mechanism to provide labels of media streams as
capabilities.
According to SDP [RFC4566], the media label has the following syntax:
"i="text
where "text" represents a human-readable text indicating the purpose
of the media stream.
In this document we define a new capability attribute: the
information media capability, "icap". This attribute lists
Garcia-Martin, et al. Expires April 30, 2009 [Page 9]
Internet-Draft Miscellaneous Capabilities in SDP October 2008
information media labels as capabilities, according to the following
definition:
"a=icap:" info-cap-num 1*WSP text
where <info-cap-num> is the ordinal identifier of the particular
media information capability and <text> is a human-readable text that
indicates the purpose of the media stream it is supposed to
characterize.
As an example, one might use:
a=icap:1 Document Camera
to represent a purpose of a media stream identified with the
capability number 1.
The media information capability attribute satisfies the general
attribute production rules in [RFC4566] according to the following
Augmented Backus-Naur Form (ABNF) [RFC5234] syntax:
att-field = "icap"
att-value = info-cap-num 1*WSP text
; text is defined in RFC 4566
info-cap-num = 1*DIGIT ; integer between 1 and 2^31-1
3.1.3.1. Configuration Parameters
The SDP Capability Negotiation Framework
[I-D.ietf-mmusic-sdp-capability-negotiation] provides for the
existence of the "pcfg" and "acfg" attributes, which can carry one or
more potential configurations to be negotiated. The concept is
extended by the the Media Capabilities Negotiation
[I-D.ietf-mmusic-sdp-media-capabilities] with an "lcfg" attribute
that conveys latent configurations.
In this document, we define an <info-config-list> parameter to be
used to convey information capabilities in a potential or latent
configuration. This parameter is defined as an <extension-config-
list> with the following associations:
ext-cap-name = "i"
ext-cap-list = info-cap-list
This leads to the following definition for the information capability
parameter:
Garcia-Martin, et al. Expires April 30, 2009 [Page 10]
Internet-Draft Miscellaneous Capabilities in SDP October 2008
extension-config-list = info-config-list
info-config-list = "i=" info-cap-list
info-cap-list = info-cap-num *(BAR info-cap-num)
info-cap-num = 1*DIGIT ; 1 to 2^32-1 inclusive
; BAR defined in SDP capabilities
; negotiation
Figure 5: Syntax of the information capability parameter in lcfg and
pcfg attributes
Each potential capability configuration contains a single information
capability attribute number where 'info-cap-num' is the information
capability number defined explicitly earlier in this document, and
hence must be between 1 and 2^31-1 (both included). The information
capability allows the expression of only a single capability in each
alternative, since no more than a single information field is
permitted per media block. Nevertheless, it is still allowed to
express alternative potential information configurations separated by
a vertical bar ("|").
3.1.3.2. Option Tag
The information field ("i=") in SDP, rather than providing
information for a software application, provides information for a
human user. Therefore, it is questionable whether the text in the
information field or the information capability is relevant for
negotiating SDP capabilities. In particular, unlike the bandwidth
and the connection data capabilities, there are no compelling use
cases that hint for the definition of an option tag for the
information capability. This is because it is not expected that an
endpoint would declare that the negotiation should fail if the
information field (which is for human consumption) is not understood.
As a consequence, we do not define an option tag associated to the
information capability.
3.2. Session Level versus Media Level
The icap, ccap, and bcap attributes can appear at the session level
and/or at the media level, but MUST be interpreted as a media-level
capability. To avoid confusion, the <type-attr-num> for each line
must be unique across all capability attributes of the same type
within the entire session description. As described below, these
capability attributes may be referenced by acfg, pcfg and/or lcfg
attributes.
Garcia-Martin, et al. Expires April 30, 2009 [Page 11]
Internet-Draft Miscellaneous Capabilities in SDP October 2008
4. Field Replacement Rules
To simplify the construction of SDP records, given the need to
include fields at the base level for endpoints that do not support
capabilities negotiation, we define some simple field-replacement
rules for those fields invoked by potential or latent configurations.
In particular, any i-field or c-field invoked by a configuration MUST
replace the corresponding field, if present at the base media level.
Any b-field invoked by a configuration MUST replace any b-field of
the same bandwidth type at the media level.
5. IANA Considerations
5.1. New SDP Attributes
IANA is hereby requested to register the following new SDP
attributes:
Attribute name: icap
Long form name: Information Capability
Type of attribute: Media-level
Subject to charset: No
Purpose: Negotiate human-readable media information
Appropriate values: See Section 3.1.3
Attribute name: ccap
Long form name: Connection Data Capability
Type of attribute: Media-level
Subject to charset: No
Purpose: Negotiate media-level connection data
Appropriate values: See Section 3.1.2
Attribute name: bcap
Long form name: Bandwidth Capability
Garcia-Martin, et al. Expires April 30, 2009 [Page 12]
Internet-Draft Miscellaneous Capabilities in SDP October 2008
Type of attribute: Media-level
Subject to charset: No
Purpose: Negotiate media-level bandwidths
Appropriate values: See Section 3.1.1
5.2. New Option Tags
IANA is hereby requested to add the new option tags "ccap-v0" and
"bcap-v0", defined herein, to the SDP Capability Negotiation Option
Tag Registry.
6. Security Considerations
This document provides an extension on top of RFC 4566 [RFC4566], RFC
3264 [RFC3264], SDP Capability Negotiation Framework
[I-D.ietf-mmusic-sdp-capability-negotiation], and SDP Media
Capabilities Negotiation [I-D.ietf-mmusic-sdp-media-capabilities].
As such, the security considerations of those documents apply.
7. Acknowledgments
Thanks to Christer Holmberg, Alf Heidermark, and Ingemar Johansson
for arguing for the existence of this document and early reviewing
it.
8. References
8.1. Normative References
[I-D.ietf-mmusic-sdp-capability-negotiation]
Andreasen, F., "SDP Capability Negotiation",
draft-ietf-mmusic-sdp-capability-negotiation-09 (work in
progress), July 2008.
[I-D.ietf-mmusic-sdp-media-capabilities]
Gilman, R., Even, R., and F. Andreasen, "SDP media
capabilities Negotiation",
draft-ietf-mmusic-sdp-media-capabilities-05 (work in
progress), July 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Garcia-Martin, et al. Expires April 30, 2009 [Page 13]
Internet-Draft Miscellaneous Capabilities in SDP October 2008
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
8.2. Informative References
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
Authors' Addresses
Miguel A. Garcia-Martin
Ericsson
Calle Via de los Poblados 13
Madrid, 28033
Spain
Phone: +34 91 339 1000
Email: miguel.a.garcia@ericsson.com
Simo Veikkolainen
Nokia
P.O. Box 407
NOKIA GROUP, FI 00045
Finland
Phone: +358 50 486 4463
Email: simo.veikkolainen@nokia.com
Garcia-Martin, et al. Expires April 30, 2009 [Page 14]
Internet-Draft Miscellaneous Capabilities in SDP October 2008
Robert R. Gilman
NDCI
3243 W. 11th Ave. Dr.
Broomfield, Colorado 80020
U.S.A.
Phone: +1 303 898 9780
Email: bob_gilman@comcast.net
Garcia-Martin, et al. Expires April 30, 2009 [Page 15]
Internet-Draft Miscellaneous Capabilities in SDP October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Garcia-Martin, et al. Expires April 30, 2009 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-23 04:21:04 |