Internet DRAFT - draft-ekim-sipping-conf-floor-package
draft-ekim-sipping-conf-floor-package
Internet Draft E. Kim
Internet Engineering Task Force NIST/ETRI
draft-ekim-sipping-conf-floor-package-01.txt S.Kang
February 2005 ETRI
Expires August 2005 G. Camarillo
Ericsson
A Session Initiation Protocol (SIP) Event Package for
Conference Floor State
draft-ekim-sipping-conf-floor-package-01
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
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
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 August 20, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
E.Kim Expires - August 2005 [Page 1]
Floor State Event Package February 2005
Abstract
This document defines a conference floor event package for Session
Initiation Protocol (SIP) conferences that require floor control. The
conference floor event package allows users to subscribe to a
conference floor server URIs. Notifications are sent about changes in
the floor state of the conference and optionally about changes in the
state of additional floor components of the conference. Subscriptions
and notifications of conference floor are supported by an event
package within the general SIP event notification framework.
Table of Contents
1. Introduction...................................................3
2. Conventions used in this document..............................3
3. Terminology....................................................3
4. Background and Requirements....................................4
5. Conference Floor Event Package.................................5
5.1 Event Package Name.........................................5
5.2 Subscriber Generating a SUBSCRIBE Request..................5
5.3 Duration of the subscription...............................7
5.4 Notifier Generation of NOTIFY Requests.....................8
5.5 Subscriber Processing of NOTIFY Requests...................9
5.6 Handling of Forked Requests................................9
5.7 Rate of Notification.......................................9
6. Data format of the Floor state information.....................9
6.1 Floor Information.........................................10
6.2 Schema....................................................11
7. Examples......................................................13
8. Security Considerations.......................................15
9. References....................................................15
Acknowledgments..................................................16
Author's Addresses...............................................17
Intellectual Property Statement..................................18
E.Kim Expires - August 2005 [Page 2]
Floor State Event Package February 2005
1. Introduction
The Session Initiation Protocol (SIP) [1] conference package [3]
defines an event package for SIP conferences providing the conference
notification service as outlined in the SIP conferencing framework
[4].
Here, we define conference floor event package for SIP conferences,
which support conference floor event followed the rule defined in
RFC3265, the general event notification framework of SIP [2].
This document aims at providing state information of floor control of
a conference to its participants, no matter which participant
supports specific floor control protocol or not. As long as a
participant supports SIP conference floor event, even though it does
not include a specific floor control protocol such as BFCP [5], it
can get the changes of floor state of the conference it joins by
subscribing the event.
The conference floor server URI acts as the notifier, and provides
clients with updates on conference floor state.
Another possible scenario to get floor event information is that
conference participants subscribe to the conference server, called
focus [4], and the conference server requests the floor information
to the floor control server and acts as the notifier. Focus and floor
control server are logical entities, and communication between the
focus and floor control server is out of the scope of the document.
This document is intended to continue a discussion to explore
standard operations for conference floor event package. Please send
comments to the mailing list <sipping@ietf.org> or <xcon@ietf.org>
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 RFC 2119 [3] and
indicate requirement levels for compliant implementations.
3. Terminology
Floor
A permission to temporarily access or manipulate a specific
shared resource or set of resources.
E.Kim Expires - August 2005 [Page 3]
Floor State Event Package February 2005
Floor control
A mechanism that enables applications or users to gain safe and
mutually exclusive or non-exclusive input access to the shared
object or resource.
Floor control server
A logical entity that maintains the state of the floor(s)
including which floors exists, who the floor chairs are, who
holds a floor, etc. Requests to manipulate a floor are directed
at the floor control server.
4. Background and Requirements
Floor control is one of the needed functionalities for multi-party
conferences in which more than one speaker are participated. XCON WG
is working on providing floor control functions for centralized
conference, and builds a specific protocol named BFCP [5] and defines
essential operations for floor control, so that a UA are able to
request, be granted, release, and be withdrawn a floor by the
protocol. It is also possible a participant in the conference who
uses a BFCP get the information of the floor state by the protocol.
There are, however, not every UA may have the specific floor control
protocol, and sometimes it is okay to join the conference without the
floor control protocol when it only want to be an audience which does
not need to request floors in the conference. Especially, when one
joins to a conference with a mobile wireless device which has lack of
resources and bandwidth, it might not have enough resources to equip
all the needed protocol. However, the audiences may still want to
have the knowledge of the floors to understand what is going on in
the conference such as who is talking now.
In other hand, some participants want to get more specified floor
state information than what the floor control protocol provides,
although it uses the floor control protocol for obtaining and
releasing the floors. Currently, all the changes about a requested
floor are provided by request-answer mode in the BFCP. However,
someone may want to get only 'granted' floor information rather than
to get all the changes of the floor state, someone may want to only 5
recent issued floor information, or someone may want to get only
audio floors information. Otherwise, someone may want to manipulate
the time period when it receives the requesting floor information.
To meet these requirements, this draft defines a floor state event
package for SIP based conference aware UAs [4]. This event package
can be used for such participants. Those who do not have the specific
floor control protocol can get the floor state information by
subscribing the floor state event. The floor state event package
E.Kim Expires - August 2005 [Page 4]
Floor State Event Package February 2005
includes event throttling and event filtering, so that it also
satisfies those who want to richer information of the floors of the
conference.
5. Conference Floor Event Package
RFC3265 defining the general event notification framework of SIP [2]
provides an extension to SIP [1] for events. This document is for
specifying conference floor event. The general information required
for SIP event package is following RFC3265.
Conference aware SIP clients subscribe to the floor control server
represented by URIs. The floor control server has all state
information for floors in the conference [5], and it notifies the
floor state to the subscribed participants.
NOTE: Another possible scenario to get floor event information
is that conference participants subscribe to the conference
server, called focus [4], and the conference server requests the
floor information to the floor control server and acts as the
notifier. In this case, the floor event information can be
merged into the conference event package. We need to discuss
more if it is needed to be merged into the conference event
package.
5.1 Event Package Name
The name of the conference floor control event package is "floor".
This value appears in the Event and Allow-Events header, as described
in RFC3265.
Example of usage:
Event: floor
5.2 Subscriber Generating a SUBSCRIBE Request
5.2.1 SUBSCRIBE Bodies
A SUBSCRIBE for a conference floor package MAY contain a body. The
body can contain specific type of floor. In addition, the body can
specify the rules for event throttling or/and event filtering, such
as when a notification should be sent to, or what types of
information should be contain in the notification.
E.Kim Expires - August 2005 [Page 5]
Floor State Event Package February 2005
The specified rule can be changed during a dialog by re-issuing a new
SUBSCRIBE message. If a SUBSCRIBE within a dialog does not contain a
filtering rule, it implies to apply the existing filtering rule.
To support event filtering, all subscribers and notifiers SHOULD
support the "application/floor-filter+xml" data format.
The subscribe request MUST contain an Accept header field, if the
body includes the filter, and the value MUST be "application/floor-
filter+xml", and MAY include any other types capable of representing
dialog state.
A SUBSCRIBE for a conference floor package MAY be sent without a body.
This implies the default subscription filtering policy. By the
default policy, notifications are generated whenever if there is any
change in the state of the floors in the conference. Notifications
normally contain partial state that has changed. The exception is a
NOTIFY sent in response to a SUBSCRIBE. These NOTIFYs contain the
full state of the information requested by the subscriber.
5.2.2 Event Filtering
The floor state changes MAY occur quite often when multiple speakers
try to get the floor in a very aggressive conversation. The audience
MAY not want to get all the changes of the event, and only want to
get essential changes among them such as floor "granted", or only
want to get the most recent 5 changes. Sometimes, subscribers MAY
want to get only "audio" floor information, ignoring video or
whiteboard floor event changes which are simply recognizable via
application.
Multiple filters MAY be included in one SUBSCRIBE message, as
required.
To filter floor event information, the body has the root element of
"floor-filters". The element is consisted of one or more "filter"
elements, which describes specific rules for notification.
The "filter" has a mandatory attribute "id", and includes an optional
"floor-info" sub-element and an optional "floor-number" sub-element.
The "floor-info" sub-element is used for applying the filter by
specific floor state information. The sub-element has an optional
"floor-id" sub-element and an optional "resource" sub-element and an
optional "state" sub-element. The "resource" sub-element indicates
audio, video, whiteboard, or other resources. The "state" sub-element
has the value of "requested", "granted", "accepted", "released", and
"withdrawn".
E.Kim Expires - August 2005 [Page 6]
Floor State Event Package February 2005
The "floor-number" sub-element is used for specifying the specific
number of floor events.
Each filter is defined by "include" or "exclude".
5.2.3 Filtering examples
If a subscriber want to get a recent 5 event changes via the
responding notification, the SUBSCRIBE body contains the following
information.
<?xml version="1.0" encoding="UTF-8"?>
<floor-filters xmlns="urn:ietf:params:xml:ns:floor-filter">
<filter id="100">
<include>
<filter-number = 5>
</include>
</filter>
</floor-filters>
If a subscriber want to get only "granted" "audio" information, but
want to exclude a specific floor-id, the SUBSCRIBE body contains the
following information.
<?xml version="1.0" encoding="UTF-8"?>
<floor-filters xmlns="urn:ietf:params:xml:ns:floor-filter">
<filter id="200">
<include>
<filter-info>
<resource = "audio">
<state = "granted">
</filter-info>
</include>
</filter>
<filter id="201">
<exclude>
<filter-info>
<floor-id = "1">
</filter-info>
</exclude>
</filter>
</floor-filters>
5.3 Duration of the subscription
The duration of this subscription is following the rule of the
conference event package [3].
E.Kim Expires - August 2005 [Page 7]
Floor State Event Package February 2005
5.4 Notifier Generation of NOTIFY Requests
5.4.1 Notifier Processing of SUBSCRIBE Requests
The conference floors information contains sensitive information as
the conference information [4]. When a conference URI acts as a
notifier, it treats the floors information as the same policy with
the conference information. When a floor control server acts as a
notifter of this event, the authorization policy should be made. In
a basic recommendation policy, all subscriptions SHOULD be
authenticated and then authorized before approval.
If the SUBSCRIBE message includes filter with the data format of
"application/floor-filter+xml", and if the notifier is able to
interpret the filter, it MUST generate the notifications by the
request. If it cannot support the filter, it MUST send an error
message.
5.4.2 Notify bodies
As described in RFC 3265 [2], the NOTIFY message will contain bodies
that describe the state of the subscribed resource. This body is in
a format listed in the Accept header field of the SUBSCRIBE, or a
package-specific default if the Accept header field was omitted from
the SUBSCRIBE.
In this event package, the body of the notification contains floors
document. This document describes the state of floors of a
conference. All subscribers and notifiers MUST support the
"application/floor-info+xml" data format described in Section 4.
The subscribe request MAY contain an Accept header field. If no such
header field is present, it has a default value of
"application/floor-info+xml". If the header field is present, it
MUST include "application/floor-info+xml", and MAY include any other
types capable of representing dialog state.
5.4.3 Generation rule of NOTIFY Requests
Notifications SHOULD be generated for the conference every time when
a change is made in the state in any of the information delivered to
the subscriber.
The changes generally occur when a floor is requested, accepted,
granted, released, or withdrawn to a participant, and when a floor
holder is changed.
When the notifier receives a SUBSCRIBE with filtering or event
throttling rule, notification SHOULD be generated for the conference
E.Kim Expires - August 2005 [Page 8]
Floor State Event Package February 2005
every time when the specified rule requested by the subscriber is
satisfied.
The notifier incorporate, re-apply, or remove when it receives new
SUBSCRIBE message with new rule to be added, modified, or removed
from the existing rule.
5.5 Subscriber Processing of NOTIFY Requests
The NOTIFY for the conference floor event package will only contain
information about those floors of which state has changed. To
construct a coherent view of the total state of all floors, a
subscriber to the event package will need to combine NOTIFYs
received over time.
If the NOTIFY indicates that a subscription has been terminated, the
subscription is assumed to be terminated. The basic rule for events
handling is applied as the RFC3265 [2] states.
5.6 Handling of Forked Requests
The conference floors are handled in centralized way. Thus,
SUBSCRIBE requests for this event should normally not be forked.
5.7 Rate of Notification
RFC 3265 [2] requires each package to specify the maximum rate at
which notifications can be sent. With consideration of the
congestion control, it is RECOMMENDED that the server not generate
notifications for a single subscriber at a rate faster than once
every 5 seconds, applying the same rule with the conference event
package [4].
If the SUBSCRIBE contain any specified rule for the duration, it
follows the rule.
6. Data format of the Floor state information
XML document is used for the conference floor information. It MUST
be well-formed and SHOULD be valid. The document SHOULD be based on
XML 1.0 and MUST be encoded using UTF-8. The namespace URI for
elements defined by this specification is a URN [6], using the
namespace identifier 'ietf' defined by [7] and extended by [8]. This
URN is:
E.Kim Expires - August 2005 [Page 9]
Floor State Event Package February 2005
urn:ietf:params:xml:ns:floor-info
A conference floor information document begins with the root element
tag "floor-info".
6.1 Floor Information
Floor information has the root element "floors-info". This element
has an attribute, "conf-uri". The attribute is the identifier of the
conference in which the floors are exchanged. The root element also
has zero or more "floor-info" sub-element.
The "floor-info" has one mandatory attribute, "floor-id". It is the
identifier of a floor. If SDP or BFCP assigns a floor-id for a
resource, this value is matched with the value.
The "floor-info" has one "resource" sub-element, which identifies
the type (audio, video) or codec of the floor resource. It has zero
or more "chairs" sub-element that gives the information of chairs
who take charge of the floor. It has "state" sub-element that
explains current status of the floor, such as the floor is granted,
released, etc.
6.1.1 Resource element
The resource element specifies the resource name matched with the
floor. Generally it will be the same with the media name appeared in
the m lines of SDP.
6.1.2 Chairs element
The chairs element has zero or more chair element which is describing
the URIs of the chair. More than one chair can take charge of a floor.
If this element is used, it SHOULD show the all members of the chair
for the floor.
6.1.3 State element
The state element shows the current state of the floor, and the time
information about the floor. It has a "floorstate" element,which has
a mendatory "transaction" attribute identifying the floor request.
The "floorstate" element also has one or more "users" sub-element,
one or more "floor-action" sub-element, zero or more "action-time"
sub-element and "expiration" sub-element.
The "users" element has one or more user element which is identified
by URIs. The user element is used for reporting the participants who
currently make an action about the floor.
E.Kim Expires - August 2005 [Page 10]
Floor State Event Package February 2005
The "floor-action" element is for the state of the floor related any
action taken for the floor. It has the value of "requested,"
"accepted," "granted," "released," or "withdrawn". The following
explains the usage of the values.
requested: The floor is requested.
accepted: The requested floor is accepted by floor server.
granted: The requested floor is granted by floor server. In an
internal operation, floor server sends the request to the
floor chair(s), and the request is admitted by the floor
chair(s). The specific functional behavior is out of the
scope of this document and it will be performed by a floor
control protocol.
released: The floor holder releases the floor.
withdrawn: The floor which has been holding by someone is enforced to
be taken back by some reason. The reason will be dependant
on the policy of a floor control protocol.
The "action-time" element notifies the time when the floor operation
is made.
The "expiration" is for the time information for the floor,
especially notifies the expiration time.
6.2 Schema
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:floor-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:floor-info"
elementFormDefault="qualified">
<!-- root element -->
<xs:element name="floors-info">
<xs:complexType>
<xs:sequence>
<xs:element name="floor-info" type="floorType"/>
</xs:sequence>
<xs:attribute name="conf-uri" type="xs:anyURI"/>
</xs:complexType>
</xs:element>
E.Kim Expires - August 2005 [Page 11]
Floor State Event Package February 2005
<xs:complexType name="floorType">
<xs:sequence>
<xs:element name="resource" type="xs:string"/>
<xs:element name="chairs" type="chairsType" minOccurs="0"/>
<xs:element name="state" type="stateInfoType" minOccurs="1"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="floor-id" type="xs:int"/>
</xs:complexType>
<!-- chair of the floor -->
<xs:complexType name="chairsType">
<xs:sequence>
<xs:element name="chair" type="chairType"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="chairType">
<xs:attribute name="uri" type="xs:anyURI"/>
</xs:complexType>
<!-- state if the floor -->
<xs:complexType name="stateInfoType">
<xs:sequence>
<xs:element name="floorstate" type="floorstateType"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="floorstateType">
<xs:sequence>
<xs:element name="users" type="userType"/>
<xs:element name="floor-action" type="actionType"/>
<xs:element name="action-time" type="xs:dateTime" minOccurs="0"
/>
<xs:element name="expiration" type="xs:dateTime" minOccurs="0"
/>
</xs:sequence>
<xs:attribute name="transaction-id" type="xs:int"
use="required"/>
</xs:complexType>
<!?action type of the floor -->
<xs:simpleType name="actionType">
<xs:restriction base="xs:string">
<xs:enumeration value="requsted"/>
E.Kim Expires - August 2005 [Page 12]
Floor State Event Package February 2005
<xs:enumeration value="accepted"/>
<xs:enumeration value="granted"/>
<xs:enumeration value="released"/>
<xs:enumeration value="withdrawed"/>
</xs:restriction>
</xs:simpleType>
<!-- user of the floor -->
<xs:complexType name="userType">
<xs:attribute name="uri" type="xs:anyURI"/>
</xs:complexType>
</xs:schema>
7. Examples
The following is an example document of floor information in a
conference.
<?xml version="1.0" encoding="UTF-8"?>
<!-- XML file generated by XMLSPY v5 rel. 3 U
(http://www.xmlspy.com)-->
<floors-info xmlns="urn:ietf:params:xml:ns:floor-info"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:floor-info
D:\IETF\floor-info.xsd" conf-uri= "sip:conf1@example.com">
<floor-info floor-id="0">
<resource>audio</resource>
<chairs>
<chair uri="sip:alice@example.com"/>
</chairs>
<state>
<floorstate transaction-id="123">
<users uri="sip:bob@example.com"/>
<floor-action>granted</floor-action>
<action-time>2005-02-17T09:30:47</action-time>
<expiration>2005-02-17T09:45:47</expiration>
</floorstate>
<floorstate transaction-id="124">
<users uri="sip:carol@example.com"/>
<floor-action>requsted</floor-action>
<action-time>2005-02-17T09:32:00</action-time>
</floorstate>
</state>
</floor-info>
<floor-info floor-id="1">
<resource>whiteboard</resource>
<chairs>
E.Kim Expires - August 2005 [Page 13]
Floor State Event Package February 2005
<chair uri="sip:alice@example.com"/>
</chairs>
<state>
<floorstate transaction-id="234">
<users uri="sip:david@example.com"/>
<floor-action>granted</floor-action>
<action-time>2005-02-17T09:30:47</action-time>
<expiration>2005-02-17T09:35:47</expiration>
</floorstate>
<floorstate transaction-id="235">
<users uri="sip:carol@example.com"/>
<floor-action>requsted</floor-action>
<action-time>2005-02-17T09:32:00</action-time>
</floorstate>
</state>
</floor-info>
</floors-info>
If the subscriber designates a filter indicating that only "granted"
event changes should be included for the floor event, the
notification MUST be generated as the following:
<?xml version="1.0" encoding="UTF-8"?>
<floors-info xmlns="urn:ietf:params:xml:ns:floor-info"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:floor-info
D:\IETF\floor-info.xsd" conf-uri= "sip:conf1@example.com">
<floor-info floor-id="0">
<resource>audio</resource>
<chairs>
<chair uri="sip:alice@example.com"/>
</chairs>
<state>
<floorstate transaction-id="123">
<users uri="sip:bob@example.com"/>
<floor-action>granted</floor-action>
<action-time>2005-02-17T09:30:47</action-time>
<expiration>2005-02-17T09:45:47</expiration>
</floorstate>
</state>
</floor-info>
<floor-info floor-id="1">
<resource>whiteboard</resource>
<chairs>
<chair uri="sip:alice@example.com"/>
</chairs>
<state>
<floorstate transaction-id="234">
<users uri="sip:david@example.com"/>
<floor-action>granted</floor-action>
E.Kim Expires - August 2005 [Page 14]
Floor State Event Package February 2005
<action-time>2005-02-17T09:30:47</action-time>
<expiration>2005-02-17T09:35:47</expiration>
</floorstate>
</state>
</floor-info>
</floors-info>
If the subscriber designates a filter indicating that only "granted"
"audio" event changes should be included for the floor event, the
notification MUST be generated as the following:
<?xml version="1.0" encoding="UTF-8"?>
<floors-info xmlns="urn:ietf:params:xml:ns:floor-info"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:floor-info
D:\IETF\floor-info.xsd" conf-uri= "sip:conf1@example.com">
<floor-info floor-id="0">
<resource>audio</resource>
<chairs>
<chair uri="sip:alice@example.com"/>
</chairs>
<state>
<floorstate transaction-id="123">
<users uri="sip:bob@example.com"/>
<floor-action>granted</floor-action>
<action-time>2005-02-17T09:30:47</action-time>
<expiration>2005-02-17T09:45:47</expiration>
</floorstate>
</state>
</floor-info>
</floors-info>
8. Security Considerations
Conference floor information is very sensitive information, so that
the server MUST use appropriate authentication to ensure the commands
to manipulate or interact the data originated from trusted parties.
Other SIP considerations apply. The further concerned security issues
will be identified as the further works go on.
9. References
[1] J. Rosenberg, H. Schulzrinne, et al, "SIP: Session Initiation
Protocol, " RFC3261, Internet Engineering Task Force, Jun. 2002.
E.Kim Expires - August 2005 [Page 15]
Floor State Event Package February 2005
[2] A. Roach, "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[2] J. Rosenberg, "A framework for conferencing with the session
initiation protocol, " Internet Draft, Internet Engineering Task
Force, Feb. 2003. Work in progress.
[3] J. Rosenberg, H. Schulzrinne, "A Session Initiation Protocol
(SIP) Event Package for Conference State, " Internet Draft, Internet
Engineering Task Force, Jul. 2004. Work in progress.
[4] P. Koskelainen, "Requirements for conference policy data, "
Internet Draft, Internet Engineering Task Force, Feb. 2003. Work in
progress.
[4] W3C, "Simple Object Access Protocol (SOAP) 1.1. "
[5] G. Camarillo, J. Ott, K. Drage, "The Binary Floor Control
Protocol (BFCP), " Internet Draft, Internet Engineering Task Force,
April. 2004. Work in progress.
[6] R. Moats, "URN syntax, " RFC2141, Internet Engineering Task
Force, May 1997.
[7] R. Moats, "A URN namespace for IETF documents, " RFC2648,
Internet Engineering Task Force, Aug. 1999.
[8] M. Mealling, "The IETF XML registry, " Internet Draft, Internet
Engineering Task Force, Jul. 2002. Work in progress.
Acknowledgments
E.Kim Expires - August 2005 [Page 16]
Floor State Event Package February 2005
Author's Addresses
Eunsook Kim
100 Bureau Drive
Gaithersburg
MD 20899
USA
E-mail: eunah@nist.gov / eunah@etri.re.kr
Shin-Gak Kang
361 Gajeong-Dong Yuseong-Gu
Deajon 305-350
Korea
E-mail: sgkang@etri.re.kr
Gonzalo Camarillo
Hirsalantie 11
Jorvas 02420
Finland
E-mail: Gonzalo.Camarillo@ericsson.com
E.Kim Expires - August 2005 [Page 17]
Floor State Event Package February 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
E.Kim Expires - August 2005 [Page 18]
Floor State Event Package February 2005
Copyright (C) The Internet Society (2004). 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.
E.Kim Expires - August 2005 [Page 19]
