GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3863

Network Working Group H. Sugano Request for Comments: 3863 S. Fujimoto Category: Standards Track Fujitsu

                                                              G. Klyne
                                                          Nine by Nine
                                                            A. Bateman
                                                            VisionTech
                                                               W. Carr
                                                                 Intel
                                                           J. Peterson
                                                               NeuStar
                                                           August 2004
              Presence Information Data Format (PIDF)

Status of this Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2004).

Abstract

 This memo specifies the Common Profile for Presence (CPP) Presence
 Information Data Format (PIDF) as a common presence data format for
 CPP-compliant Presence protocols, and also defines a new media type
 "application/pidf+xml" to represent the XML MIME entity for PIDF.

Table of Content

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1.  Terminology and Conventions. . . . . . . . . . . . . . .  3
 2.  Design Decisions . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Minimal Model. . . . . . . . . . . . . . . . . . . . . .  3
     2.2.  Added Features . . . . . . . . . . . . . . . . . . . . .  4
     2.3.  XML Encoding Decision. . . . . . . . . . . . . . . . . .  5
 3.  Overview of Presence Information Data Format . . . . . . . . .  5
     3.1.  The 'application/pidf+xml' Content Type. . . . . . . . .  5
     3.2.  Presence Information Contents. . . . . . . . . . . . . .  5
 4.  XML-encoded Presence Data Format . . . . . . . . . . . . . . .  6
     4.1.  XML Format Definitions . . . . . . . . . . . . . . . . .  6

Sugano, et al. Standards Track [Page 1] RFC 3863 Presence Information Data Format August 2004

           4.1.1. The <presence> element. . . . . . . . . . . . . .  6
           4.1.2. The <tuple> element . . . . . . . . . . . . . . .  7
           4.1.3. The <status> element. . . . . . . . . . . . . . .  8
           4.1.4. The <basic> element . . . . . . . . . . . . . . .  8
           4.1.5. The <contact> element . . . . . . . . . . . . . .  8
           4.1.6. The <note> element. . . . . . . . . . . . . . . .  9
           4.1.7. The <timestamp> element . . . . . . . . . . . . .  9
     4.2.  Presence Information Extensibility . . . . . . . . . . . 10
           4.2.1. XML Namespaces Background . . . . . . . . . . . . 10
           4.2.2. XML Namespaces In Presence Information. . . . . . 11
           4.2.3. Handling Of Unrecognized Element Names. . . . . . 12
           4.2.4. Status Value Extensibility. . . . . . . . . . . . 12
           4.2.5. Standardizing Status Extensions . . . . . . . . . 13
     4.3.  Examples . . . . . . . . . . . . . . . . . . . . . . . . 14
           4.3.1. Default Namespace with Status Extensions. . . . . 14
           4.3.2. Presence with Other Extension Elements. . . . . . 15
           4.3.3. Example Mandatory To Understand Elements. . . . . 16
     4.4.  XML Schema Definitions . . . . . . . . . . . . . . . . . 16
 5.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 18
     5.1.  Content-type registration for 'application/pidf+xml' . . 18
     5.2.  URN sub-namespace registration for
           'urn:ietf:params:xml:ns:pidf'. . . . . . . . . . . . . . 19
     5.3.  URN sub-namespace registration for
           'urn:ietf:params:xml:ns:pidf:status' . . . . . . . . . . 20
 6.  Security Considerations. . . . . . . . . . . . . . . . . . . . 21
 7.  Internationalization Considerations. . . . . . . . . . . . . . 22
 8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     8.1.  Normative References . . . . . . . . . . . . . . . . . . 22
     8.2.  Informative References . . . . . . . . . . . . . . . . . 23
 Appendix A. Document Type Definitions. . . . . . . . . . . . . . . 25
 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 28

1. Introduction

 The Common Profiles for Instant Messaging (CPIM) [CPIM] and Presence
 (CPP) [CPP] specifications define a set of operations and parameters
 to achieve interoperability between different Instant Messaging and
 Presence protocols which meet RFC 2779 [RFC2779].
 This memo further defines the Presence Information Data Format (PIDF)
 as a common presence data format for CPP-compliant presence
 protocols, allowing presence information to be transferred across
 CPP-compliant protocol boundaries without modification, with
 attendant benefits for security and performance.

Sugano, et al. Standards Track [Page 2] RFC 3863 Presence Information Data Format August 2004

 The format specified in this memo defines the base presence format
 and extensibility required by RFC 2779.  It defines a minimal set of
 presence status values defined by the IMPP Model document [RFC2778].
 However, a presence application is able to define its own status
 values using the extensibility framework provided by this memo.
 Defining such extended status values is beyond the scope of this
 memo.
 Note also that this memo defines only the format for a presence data
 payload and the extensibility framework for it.  How the presence
 data is transferred within a specific protocol frame would be defined
 separately in a protocol specification.

1.1. Terminology and Conventions

 This memo makes use of the vocabulary defined in the IMPP Model
 document [RFC2778].  Terms such as CLOSED, INSTANT MESSAGE, OPEN,
 PRESENCE SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT in the
 memo are used in the same meaning as defined therein.
 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
 interpreted as described in BCP 14, RFC 2119 [RFC2119].

2. Design Decisions

 We have adopted the IMPP Model and Requirements documents [RFC2778,
 RFC2779] as the starting point of our discussion.  The two RFCs
 contain a number of statements about presence information, which can
 be regarded as a basic set of constraints for the format design.
 Also, we took the minimalist approach to the design based on them.
 Starting from the minimal model, only the features that are necessary
 to solve particular problems have been included.

2.1. Minimal Model

 This specification is based on the minimal model extracted from the
 IMPP Model and Requirements documents.  The model consists of the
 following items.  Each of them is accompanied with the corresponding
 RFCs and their section numbers as its grounds, e.g.,
 (RFC2778:Sec.2.4) refers to Section 2.4 of RFC 2778.
 (a) PRESENCE INFORMATION consists of one or more PRESENCE TUPLES,
     where a PRESENCE TUPLE consists of a STATUS, an optional
     COMMUNICATION ADDRESS, and optional OTHER PRESENCE MARKUP.  Note
     that the CONTACT ADDRESS in a COMMUNICATIONS ADDRESS is
     understood in this document to refer only to a URI
     (RFC2778:Sec.3).

Sugano, et al. Standards Track [Page 3] RFC 3863 Presence Information Data Format August 2004

 (b) STATUS has at least the mutually-exclusive values OPEN and
     CLOSED, which have meaning for the acceptance of INSTANT
     MESSAGES, and may have meaning for other COMMUNICATION MEANS.
     There may be other values of STATUS that do not imply anything
     about INSTANT MESSAGE acceptance.  These other values of STATUS
     may be combined with OPEN and CLOSED or they may be mutually-
     exclusive with those values (RFC2778:Sec.3, RFC2779:Sec.4.4.1-
     4.4.3).
 (c) STATUS may consist of single or multiple values.(RFC2778:Sec.2.4)
 (d) There must be a means of extending the common presence format to
     represent additional information not included in the common
     format.  The extension and registration mechanisms must be
     defined for presence information schema, including new STATUS
     conditions and new forms for OTHER PRESENCE MARKUP
     (RFC2779:Sec.3.1.4-3.1.5).
 (e) The common presence format must include a means to uniquely
     identify the PRESENTITY whose PRESENCE INFORMATION is reported
     (RFC2779:Sec.3.1.2).
 (f) The common presence format must allow the PRESENTITY to secure
     presence information sent to a WATCHER.  The format must allow
     integrity, confidentiality and authentication properties to be
     applied to presence information (RFC2779:Sec5.2.1, 5.2.4, 5.3.1,
     5.3.3).

2.2. Added Features

 In addition to the minimal model described above, the format
 specified in this specification has the following features.
 (a) Relative priorities of contact addresses are specifiable in order
      to allow the source of PRESENCE INFORMATION to tell the receiver
      (WATCHER USER AGENTS) its preference over multiple contact
      means.
 (b) The presence format is able to contain the timestamp of the
      creation of the PRESENCE INFORMATION.  The timestamp in the
      presence document lets the receiver know the time of the
      creation of the data even if the message containing it is
      delayed.  It can also be used to detect a replay attack,
      independent of the underlying signature mechanism.  Note that
      this mechanism does not assume any global time synchronization
      system for watchers and presentities (see Appendix A of RFC2779,
      8.1.4 A7), but rather assumes that the minimum length of time
      that might pass before presence information is considered stale

Sugano, et al. Standards Track [Page 4] RFC 3863 Presence Information Data Format August 2004

      is long enough that minor variations among system clocks will
      not lead to misjudgments of the freshness of presence
      information.

2.3. XML Encoding Decision

 The Presence Information Data Format encodes presence information in
 XML (eXtensible Markup Language [XML]).  Regarding the features of
 PRESENCE INFORMATION discussed above, such that it has a hierarchical
 structure and it should be fully extensible, XML is considered as the
 most desirable framework over other candidates such as vCard [vCard].

3. Overview of Presence Information Data Format

 This section describes an overview of the presence data format
 defined in this memo.

3.1. The 'application/pidf+xml' Content Type

 This memo defines a new content type "application/pidf+xml" for an
 XML MIME entity that contains presence information.  This
 specification follows the recommendations and conventions described
 in [RFC3023], including the naming convention of the type ('+xml'
 suffix) and the usage of the 'charset' parameter.
 Although it is defined as optional, use of the 'charset' parameter is
 RECOMMENDED.  If the 'charset' parameter is not specified, conforming
 XML processors MUST follow the requirements in section 4.3.3 of
 [XML].

3.2. Presence Information Contents

 This subsection outlines the information in an "application/pidf+xml"
 document.  A full definition of the PIDF content is in Section 4.
 o PRESENTITY URL: specifies the "pres" URL of the PRESENTITY.
 o List of PRESENCE TUPLES
   - Identifier: token to identify this tuple within the presence
     information.
   - STATUS: OPEN/CLOSED and/or extension status values.
   - COMMUNICATION ADDRESS: COMMUNICATION MEANS and CONTACT
       ADDRESS of this tuple. (optional)
   - Relative priority: numerical value specifying the priority
       of this COMMUNICATION ADDRESS. (optional)
   - Timestamp: timestamp of the change of this tuple.(optional)
   - Human readable comment: free text memo about this tuple
       (optional)

Sugano, et al. Standards Track [Page 5] RFC 3863 Presence Information Data Format August 2004

 o PRESENTITY human readable comment: free text memo about the
     PRESENTITY (optional).

4. XML-encoded Presence Data Format

 This section defines an XML-encoded presence information data format
 (PIDF) for use with CPP compliant systems.  A presence payload in
 this format is expected to be produced by the PRESENTITY (the source
 of the PRESENCE INFORMATION) and transported to the WATCHERS by the
 presence servers or gateways without any interpretation or
 modification.

4.1. XML Format Definitions

 A PIDF object is a well formed XML document.
 It MUST have the XML declaration and it SHOULD contain an encoding
 declaration in the XML declaration, e.g., "<?xml version='1.0'
 encoding='UTF-8'?>".  If the charset parameter of the MIME content
 type declaration is present and it is different from the encoding
 declaration, the charset parameter takes precedence.
 Every application conformant to this specification MUST accept the
 UTF-8 character encoding to ensure the minimal interoperability.

4.1.1. The <presence> element

 PIDF elements are associated with the XML namespace name
 'urn:ietf:params:xml:ns:pidf', declared using an xmlns attribute, per
 [XML-NS].  The namespace may be a default namespace, or may be
 associated with some namespace prefix (see section 4.2.2 for
 examples).
 The root of an "application/pidf+xml" object is a <presence> element
 associated with the presence information namespace.  This contains
 any number (including 0) of <tuple> elements, followed by any number
 (including 0) of <note> elements, followed by any number of OPTIONAL
 extension elements from other namespaces.
 The <presence> element MUST have an 'entity' attribute.  The value of
 the 'entity' attribute is the 'pres' URL of the PRESENTITY publishing
 this presence document.
 The <presence> element MUST contain a namespace declaration ('xmlns')
 to indicate the namespace on which the presence document is based.
 The presence document compliant to this specification MUST have the
 namespace 'urn:ietf:params:xml:ns:pidf:'.

Sugano, et al. Standards Track [Page 6] RFC 3863 Presence Information Data Format August 2004

 It MAY contain other namespace declarations for the extensions used
 in the presence XML document.

4.1.2. The <tuple> element

 The <tuple> element carries a PRESENCE TUPLE, consisting of a
 mandatory <status> element, followed by any number of OPTIONAL
 extension elements (possibly from other namespaces), followed by an
 OPTIONAL <contact> element, followed by any number of OPTIONAL <note>
 elements, followed by an OPTIONAL <timestamp> element.
 Tuples provide a way of segmenting presence information.  Protocols
 or applications may choose to segment the presence information
 associated with a presentity for any number of reasons - for example,
 because components of the full presence information for a presentity
 have come from distinct devices or different applications on the same
 device, or have been generated at different times.  Tuples should be
 preferred over other manners of segmenting presence information such
 as creating multiple PIDF instances.
 The <tuple> element MUST contain an 'id' attribute which is used to
 distinguish this tuple from other tuples in the same PRESENTITY.  The
 value of an 'id' attribute MUST be unique within 'id' attribute
 values of other tuples for the same PRESENTITY.  An 'id' value is
 used by applications processing the presence document to identify the
 corresponding tuple in the previously acquired PRESENCE INFORMATION
 of the same PRESENTITY.  The value of the 'id' attribute is an
 arbitrary string, and has no significance beyond providing a means to
 distinguish <tuple> values, as noted above.
 The <contact> element is OPTIONAL because a PRESENTITY might need to
 hide its COMMUNICATION ADDRESS or there might be tuples not related
 to any COMMUNICATION MEANS.  Tuples that contain a <basic> status
 element SHOULD contain a <contact> address.  Tuples MAY contain
 conflicting presence status - one <tuple> might provide a <basic>
 <status> of OPEN, and another <tuple> in the same PIDF could contain
 a <basic> <status> of CLOSED, even if they both contain the same
 <contact> address.
 The manner in which segmented presence information is understood by
 the WATCHER USER AGENT is highly dependent on the capabilities of the
 WATCHER USER AGENT and the presence application in question.  In the
 absence of any application-specific or protocol-specific
 understanding of the meaning of tuples, WATCHER USER AGENTS MAY obey
 the following guidelines.  WATCHER USER AGENTS should note which
 tuples in the PIDF have changed their state since the last

Sugano, et al. Standards Track [Page 7] RFC 3863 Presence Information Data Format August 2004

 notification by correlating the 'id' of each <tuple> with those
 received in previous notifications and comparing both <status> values
 and <timestamp> elements in the tuples, if any are present.

4.1.3. The <status> element

 The <status> element contains one OPTIONAL <basic> element, followed
 by any number of OPTIONAL extension elements (possibly from other
 namespaces), under the restriction that at least one child element
 appears in the <status> element.  These children elements of <status>
 contain status values of this tuple.  By allowing multiple status
 values in a single <tuple> element, different types of status values,
 e.g., reachability and location, can be represented by a <tuple>.
 See Section 4.3 for an example with multiple status values.
 This memo only defines the <basic> status value element.  Other
 status values may be included using the standard extensibility
 framework (see Section 4.2.4).  Applications encountering
 unrecognized elements within <status> may ignore them, unless they
 carry a mustUnderstand="true" or mustUnderstand="1" attribute (see
 section 4.2.3).
 Note that, while the <status> element MUST have at least one status
 value element, this status value might not be the <basic> element.

4.1.4. The <basic> element

 The <basic> element contains one of the following strings: "open" or
 "closed".
 The values "open" and "closed" indicate availability to receive
 INSTANT MESSAGES if the <tuple> is for an instant messaging address.
 They also indicate general availability for other communication
 means, but this memo does not specify these in detail.
 open: In the context of INSTANT MESSAGES, this value means that the
    associated <contact> element, if any, corresponds to an INSTANT
    INBOX that is ready to accept an INSTANT MESSAGE.
 closed: In the context of INSTANT MESSAGES, this value means that
    the associated <contact> element, if any, corresponds to an
    INSTANT INBOX that is unable to accept an INSTANT MESSAGE.

4.1.5. The <contact> element

 The <contact> element contains a URL of the contact address.  It
 optionally has a 'priority' attribute, whose value means a relative
 priority of this contact address over the others.  The value of the

Sugano, et al. Standards Track [Page 8] RFC 3863 Presence Information Data Format August 2004

 attribute MUST be a decimal number between 0 and 1 inclusive with at
 most 3 digits after the decimal point.  Higher values indicate higher
 priority.  Examples of priority values are 0, 0.021, 0.5, 1.00. If
 the 'priority' attribute is omitted, applications MUST assign the
 contact address the lowest priority.  If the 'priority' value is out
 of the range, applications just SHOULD ignore the value and process
 it as if the attribute was not present.
 Applications SHOULD handle contacts with a higher priority as they
 have precedence over those with lower priorities.  How they are
 actually treated is beyond this specification.  Also, how to handle
 contacts with the same priority is up to implementations.

4.1.6. The <note> element

 The <note> element contains a string value, which is usually used for
 a human readable comment.  A <note> element MAY appear as a child
 element of <presence> or as a child element of the <tuple> element.
 In the former case the comment is about the PRESENTITY and in the
 latter case the comment is regarding the particular tuple.
 Note that, wherever it appears, a <note> element SHOULD NOT be used,
 and interpreted, as a non-interoperable substitute for status of its
 parent element.
 The <note> element SHOULD have a special attribute 'xml:lang' to
 specify the language used in the contents of this element as defined
 in Section 2.12 of [XML].  The value of this attribute is the
 language identifier as defined by [RFC3066].  It MAY be omitted when
 the language used is implied by the larger context such as the
 encoding information of the contents, such as an xml:lang attribute
 on an enclosing XML element, or a Content-language header [RFC3282]
 on an enclosing MIME wrapper.

4.1.7. The <timestamp> element

 The <timestamp> element contains a string indicating the date and
 time of the status change of this tuple.  The value of this element
 MUST follow the IMPP datetime format [RFC3339].  Timestamps that
 contain 'T' or 'Z' MUST use the capitalized forms.
 As a security measure, the <timestamp> element SHOULD be included in
 all tuples unless the exact time of the status change cannot be
 determined.  For security guidelines for watchers receiving presence
 information with timestamps, see the Security Considerations.
 A PRESENTITY MUST NOT generate successive <presence> elements
 containing the same timestamp.

Sugano, et al. Standards Track [Page 9] RFC 3863 Presence Information Data Format August 2004

4.2. Presence Information Extensibility

 The presence information extensibility framework is based on XML
 namespaces [XML-NS].
 RFC 2779 requires that PIDF have a means of extending <status> values
 beyond <basic>.  These extensions MUST NOT modify how <basic> is to
 be understood, nor change the structure or semantics of PIDF bodies
 themselves.  These extensions merely allow protocols and applications
 to define richer presence data.

4.2.1. XML Namespaces Background

 All elements and some attributes are associated with a "namespace",
 which is in turn associated with a globally unique URI.  Any
 developer can introduce their own element names, avoiding conflict by
 choosing an appropriate namespace URI.
 Within the presence data, element or attribute names are associated
 with a particular namespace by a namespace prefix, which is a leading
 part of the name, followed by a colon (":"); e.g.,
    <prefix:element-name ...> ... </prefix:element-name>
 Where, 'prefix' is the header name prefix, 'element-name' is a name
 which is scoped by the namespace associated with 'prefix'.  Note that
 the choice of 'prefix' is quite arbitrary;  it is the corresponding
 URI that defines the naming scope.  Two different prefixes associated
 with the same namespace URI refer to the same namespace.
 A default namespace can be declared for XML elements without a
 namespace prefix.  The default namespace does NOT apply to attribute
 names, but interpretation of an unprefixed attribute can be
 determined by the containing element.
 A namespace is identified by a URI.  In this usage, the URI is used
 simply as a globally unique identifier, and there is no requirement
 that it can be used to retrieve a web resource, or for any other
 purpose.  Any legal globally unique URI MAY be used to identify a
 namespace.  (By "globally unique", we mean constructed according to
 some set of rules so that it is reasonable to expect that nobody else
 will use the same URI for a different purpose.)
 For further details, see the XML namespace specification [XML-NS].

Sugano, et al. Standards Track [Page 10] RFC 3863 Presence Information Data Format August 2004

4.2.2. XML Namespaces In Presence Information

 A URI used as a namespace identifier in PRESENCE INFORMATION data
 MUST be a full absolute-URI, per RFC 2396 [URI].  (Relative URIs and
 URI-references containing fragment identifiers MUST NOT be used for
 this purpose.)
 The namespace URI for elements defined by this specification is a URN
 [URN], using the namespace identifier 'ietf' defined by [URN-NS-IETF]
 and extended by [XML-Registry]:
    urn:ietf:params:xml:ns:pidf
 Thus, simple presence data might be thus:
 <?xml version="1.0" encoding="UTF-8"?>
 <impp:presence xmlns:impp="urn:ietf:params:xml:ns:pidf"
     entity="pres:someone@example.com">
   <impp:tuple id="sg89ae">
     <impp:status>
       <impp:basic>open</impp:basic>
     </impp:status>
     <impp:contact priority="0.8">tel:+09012345678</impp:contact>
   </impp:tuple>
 </impp:presence>
 , using a default XML namespace:
 <?xml version="1.0" encoding="UTF-8"?>
 <presence xmlns="urn:ietf:params:xml:ns:pidf"
     entity="pres:someone@example.com">
   <tuple id="sg89ae">
     <status>
       <basic>open</basic>
     </status>
     <contact priority="0.8">tel:+09012345678</contact>
   </tuple>
 </presence>
 As is generally the case in XML with namespaces, the xmlns attribute
 can be used on any element in the presence information to define
 either the default namespace or a namespace associated with a
 namespace prefix.

Sugano, et al. Standards Track [Page 11] RFC 3863 Presence Information Data Format August 2004

4.2.3. Handling Of Unrecognized Element Names

 Except as noted below, a processor of PRESENCE INFORMATION MUST
 ignore any XML element with an unrecognized name (i.e., having an
 unrecognized namespace URI, or an unrecognized local name within that
 namespace).  This includes all of the element content, even if it
 appears to contain elements with recognized names.
 Extensions to PIDF are informational in nature - they provide
 additional information beyond <basic> status.  However, in order to
 understand a complex extension, nested elements within an extension
 element might need to be marked as mandatory.  In such cases, the
 element name is qualified with a mustUnderstand='true' or
 mustUnderstand='1' attribute.  See section 4.3.3 for an example.
    NOTE:  a mustUnderstand='true' or mustUnderstand='1' attribute
    within an element that is being ignored is itself ignored.  The
    writer of nested mandatory-to-understand information is
    responsible for ensuring that any enclosing element is also
    labelled with a mustUnderstand='true' or mustUnderstand='1'
    attribute, if necessary.
 This specification defines (section 4.1) elements within the
 'urn:ietf:params:xml:ns:pidf' namespace that MUST be recognized in
 CPP presence data.  Processors MUST handle these as described, even
 if they do not carry a mustUnderstand attribute.  The XML Schema
 Definition (section 4.4) indicates those elements that MUST be
 present in a valid presence information document.
 If an agent receives PRESENCE INFORMATION with a <status> block
 containing an unrecognized element with a mustUnderstand='true' (or
 '1') attribute, it should treat that entire element and any content
 as unrecognized and not attempt to process it.
 In order to ensure that minimal implementations can correctly process
 basic PIDF information the mustUnderstand attribute MUST be used only
 within optional elements nested in a <status> element.  This will
 ensure that problems processing an extension are restricted to that
 extension and do not affect the processing of the basic PIDF
 information defined in this specification.

4.2.4. Status Value Extensibility

 This memo defines only the <basic> status value with values of "open"
 and "closed".  Other status values are possible using the standard
 namespace-based extensibility rules defined above.

Sugano, et al. Standards Track [Page 12] RFC 3863 Presence Information Data Format August 2004

 For example, a location status value might be included thus:
 <?xml version="1.0" encoding="UTF-8"?>
 <presence xmlns="urn:ietf:params:xml:ns:pidf"
     xmlns:local="urn:example-com:pidf-status-type"
     entity="pres:someone@example.com">
   <tuple id="ub93s3">
     <status>
       <basic>open</basic>
       <local:location>home</local:location>
     </status>
     <contact>im:someone@example.com</contact>
   </tuple>
 </presence>
 Some new status values will 'extend' the value of the <basic>
 element.  For example, a status value defined for use with instant
 messaging may include values such as 'away', 'busy' and 'offline'.
 In order that some level of interoperability be maintained with user
 agents that don't recognize the new extension, the <basic> status
 value must also be included.  This means that extensions are not
 obligated to define a mapping from each of their values to OPEN or
 CLOSED.

4.2.5. Standardizing Status Extensions

 Although the existing PIDF definition allows arbitrary elements to
 appear in the <status> element, it may be sometimes desirable to
 standardize extension status elements and their semantics (the
 meanings of particular statuses, how they should be interpreted).
 The URN 'urn:ietf:params:xml:ns:pidf:status' has been specified as an
 umbrella namespace under which extensions to the <status> PIDF
 element should be specified (e.g.,
 urn:ietf:params:xml:ns:pidf:status:my-extension).  New values under
 this namespace MUST be defined by a standards-track RFC.
 The following example XML Schema defines an extension for <location>
 presence information, which can have the values of 'home', 'office',
 or 'car'.  If the <location> element were standardized, this document
 would be made available in an RFC along with information about the
 use of the extension.  These extensions should use the namespace
 'urn:ietf:params:xml:ns:pidf:status', and each RFC defining an
 extension should register an extension name within that namespace
 with IANA.
 <?xml version="1.0" encoding="UTF-8"?>
 <xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf:status"
      xmlns:tns="urn:ietf:params:xml:ns:pidf:status"

Sugano, et al. Standards Track [Page 13] RFC 3863 Presence Information Data Format August 2004

      xmlns:xs="http://www.w3.org/2001/XMLSchema"
      elementFormDefault="qualified"
      attributeFormDefault="unqualified">
   <xs:simpleType name="location">
     <xs:restriction base="xs:string">
       <xs:enumeration value="home"/>
       <xs:enumeration value="office"/>
       <xs:enumeration value="car"/>
     </xs:restriction>
   </xs:simpleType>
 </xs:schema>
 In addition to the XML Schema to validate the extension, registration
 of the extension name with IANA, RFCs defining extensions MUST
 discuss:
  1. The domain of applicability of the extension. Is this extension

exclusively valuable to IM clients, telephones, geolocators, etc?

    What sorts of presence applications would use this extension and
    under what circumstances?
  1. Semantics for the presence states defined in the extension. What

disposition provokes an automated presentity to declare that it is

    in state X, or does a human select X from a drag-down menu? Is
    there any general guidance for watchers of presence information
    with state Y (for example, how they should best attempt to
    communicate with the presentity, if at all, when the principal is
    in state Y).
 Extensions SHOULD also discuss:
  1. How, if at all, any presence states defined in the extension

related to <basic>, or to any relevant extension previously

    published in an RFC.  For example, "state Z implies OPEN, so it
    MUST NOT be used if a basic state of CLOSED is expressed", or
    "you should use the extension in this document, not the extension
    in RFC QQQQ, if your circumstances are as follows...."

4.3. Examples

4.3.1. Default Namespace with Status Extensions

 The following instance document uses a hypothetical 'pidf:im' XML
 namespace as an example of the sort of status extension that might be
 developed for PIDF.

Sugano, et al. Standards Track [Page 14] RFC 3863 Presence Information Data Format August 2004

 <?xml version="1.0" encoding="UTF-8"?>
 <presence xmlns="urn:ietf:params:xml:ns:pidf"
      xmlns:im="urn:ietf:params:xml:ns:pidf:im"
      xmlns:myex="http://id.example.com/presence/"
      entity="pres:someone@example.com">
   <tuple id="bs35r9">
     <status>
       <basic>open</basic>
       <im:im>busy</im:im>
       <myex:location>home</myex:location>
     </status>
     <contact priority="0.8">im:someone@mobilecarrier.net</contact>
     <note xml:lang="en">Don't Disturb Please!</note>
     <note xml:lang="fr">Ne derangez pas, s'il vous plait</note>
     <timestamp>2001-10-27T16:49:29Z</timestamp>
   </tuple>
   <tuple id="eg92n8">
     <status>
       <basic>open</basic>
     </status>
     <contact priority="1.0">mailto:someone@example.com</contact>
   </tuple>
   <note>I'll be in Tokyo next week</note>
 </presence>

4.3.2. Presence with Other Extension Elements

 <?xml version="1.0" encoding="UTF-8"?>
 <impp:presence xmlns:impp="urn:ietf:params:xml:ns:pidf"
      xmlns:myex="http://id.example.com/presence/"
      entity="pres:someone@example.com">
   <impp:tuple id="ck38g9">
     <impp:status>
       <impp:basic>open</impp:basic>
     </impp:status>
     <myex:mytupletag>Extended value in tuple</myex:mytupletag>
     <impp:contact priority="0.65">tel:+09012345678</impp:contact>
   </impp:tuple>
   <impp:tuple id="md66je">
     <impp:status>
       <impp:basic>open</impp:basic>
     </impp:status>
     <impp:contact priority="1.0">
        im:someone@mobilecarrier.net</impp:contact>
   </impp:tuple>
   <myex:mytag>My extended presentity information</myex:mytag>
 </impp:presence>

Sugano, et al. Standards Track [Page 15] RFC 3863 Presence Information Data Format August 2004

4.3.3. Example Mandatory To Understand Elements

 <?xml version="1.0" encoding="UTF-8"?>
 <impp:presence xmlns:impp="urn:ietf:params:xml:ns:pidf"
      xmlns:myex="http://id.mycompany.com/presence/"
      entity="pres:someone@example.com">
   <impp:tuple id="tj25ds">
     <impp:status>
       <impp:basic>open</impp:basic>
     </impp:status>
     <myex:complexExtension>
       <myex:ex1 impp:mustUnderstand="1">val1</myex:ex1>
       <myex:ex2>val2</myex:ex2>
     </myex:complexExtension>
     <impp:contact priority="0.725">tel:+09012345678</impp:contact>
   </impp:tuple>
   <myex:mytag>My extended presentity information</myex:mytag>
 </impp:presence>
 Here, <myex:ex1> must be understood and, if it is not recognized,
 <myex:complexExtension> MUST be ignored.   <myex:mytag> and
 <myex:ex2> MAY be ignored if they are not recognized.

4.4. XML Schema Definitions

 This section gives the XML Schema Definition [XMLSchema1] of the
 "application/pidf+xml" format.  This is presented as a formal
 definition of the "application/pidf+xml" format.  Note that the XML
 Schema definition is not intended to be used with on-the-fly
 validation of the presence XML document.
 <?xml version="1.0" encoding="UTF-8"?>
 <xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf"
      xmlns:tns="urn:ietf:params:xml:ns:pidf"
      xmlns:xs="http://www.w3.org/2001/XMLSchema"
      elementFormDefault="qualified"
      attributeFormDefault="unqualified">
   <!-- This import brings in the XML language attribute xml:lang-->
   <xs:import namespace="http://www.w3.org/XML/1998/namespace"
     schemaLocation="http://www.w3.org/2001/xml.xsd"/>
   <xs:element name="presence" type="tns:presence"/>
   <xs:complexType name="presence">
     <xs:sequence>
       <xs:element name="tuple" type="tns:tuple" minOccurs="0"
          maxOccurs="unbounded"/>

Sugano, et al. Standards Track [Page 16] RFC 3863 Presence Information Data Format August 2004

       <xs:element name="note" type="tns:note" minOccurs="0"
          maxOccurs="unbounded"/>
       <xs:any namespace="##other" processContents="lax" minOccurs="0"
          maxOccurs="unbounded"/>
     </xs:sequence>
     <xs:attribute name="entity" type="xs:anyURI" use="required"/>
   </xs:complexType>
   <xs:complexType name="tuple">
     <xs:sequence>
       <xs:element name="status" type="tns:status"/>
       <xs:any namespace="##other" processContents="lax" minOccurs="0"
          maxOccurs="unbounded"/>
       <xs:element name="contact" type="tns:contact" minOccurs="0"/>
       <xs:element name="note" type="tns:note" minOccurs="0"
          maxOccurs="unbounded"/>
       <xs:element name="timestamp" type="xs:dateTime" minOccurs="0"/>
     </xs:sequence>
     <xs:attribute name="id" type="xs:ID" use="required"/>
   </xs:complexType>
   <xs:complexType name="status">
     <xs:sequence>
       <xs:element name="basic" type="tns:basic" minOccurs="0"/>
       <xs:any namespace="##other" processContents="lax" minOccurs="0"
          maxOccurs="unbounded"/>
     </xs:sequence>
   </xs:complexType>
   <xs:simpleType name="basic">
     <xs:restriction base="xs:string">
       <xs:enumeration value="open"/>
       <xs:enumeration value="closed"/>
     </xs:restriction>
   </xs:simpleType>
   <xs:complexType name="contact">
     <xs:simpleContent>
       <xs:extension base="xs:anyURI">
         <xs:attribute name="priority" type="tns:qvalue"/>
       </xs:extension>
     </xs:simpleContent>
   </xs:complexType>
   <xs:complexType name="note">
     <xs:simpleContent>
       <xs:extension base="xs:string">
         <xs:attribute ref="xml:lang"/>
       </xs:extension>

Sugano, et al. Standards Track [Page 17] RFC 3863 Presence Information Data Format August 2004

     </xs:simpleContent>
   </xs:complexType>
   <xs:simpleType name="qvalue">
     <xs:restriction base="xs:decimal">
       <xs:pattern value="0(.[0-9]{0,3})?"/>
       <xs:pattern value="1(.0{0,3})?"/>
     </xs:restriction>
   </xs:simpleType>
   <!-- Global Attributes -->
   <xs:attribute name="mustUnderstand" type="xs:boolean" default="0">
     <xs:annotation>
       <xs:documentation>
       This attribute may be used on any element within an optional
       PIDF extension to indicate that the corresponding element must
       be understood by the PIDF processor if the enclosing optional
       element is to be handled.
       </xs:documentation>
     </xs:annotation>
   </xs:attribute>
 </xs:schema>

5. IANA Considerations

 This memo calls for IANA to:
  1. register a new MIME content-type application/pidf+xml, per [MIME],
  1. register a new XML namespace URN per [XML-Registry].
  1. register a new XML namespace URN for status extensions per [XML-

Registry].

 The registration templates for these are below. For more information
 on status extensions, see section 4.2.5.

5.1. Content-type registration for 'application/pidf+xml'

 To: ietf-types@iana.org
 Subject: Registration of MIME media type application/pidf+xml
 MIME media type name:  application
 MIME subtype name:     pidf+xml
 Required parameters:   (none)

Sugano, et al. Standards Track [Page 18] RFC 3863 Presence Information Data Format August 2004

 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 presence 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
    presence information across different CPP compliant protocols.
 Published specification:
    RFC 3863
 Applications which use this media type:
    Presence and instant messaging systems.
 Additional information:
    Magic number(s):  File extension(s):  Macintosh File Type Code(s):
 Person & email address to contact for further information:
    Hiroyasu Sugano EMail: sugano.h@jp.fujitsu.com
 Intended usage:
    LIMITED USE
 Author/Change controller:
    This specification is a work item of the IETF IMPP working group,
    with mailing list address <impp@iastate.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/pidf+xml.

5.2. URN sub-namespace registration for 'urn:ietf:params:xml:ns:pidf'

 URI
    urn:ietf:params:xml:ns:pidf

Sugano, et al. Standards Track [Page 19] RFC 3863 Presence Information Data Format August 2004

 Description:
    This is the XML namespace URI for XML elements defined by RFC 3863
    to describe CPP presence information in application/pidf+xml
    content type.
 Registrant Contact
    IETF, IMPP working group, <impp@iastate.edu>
    Hiroyasu Sugano, <sugano.h@jp.fujitsu.com>
 XML
    BEGIN
      <?xml version="1.0"?>
      <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
                "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
      <html xmlns="http://www.w3.org/1999/xhtml">
      <head>
        <meta http-equiv="content-type"
           content="text/html;charset=utf-8"/>
        <title>Namespace for CPP presence information</title>
      </head>
      <body>
        <h1>Namespace for CPP presence information</h1>
        <h2>urn:ietf:params:xml:ns:pidf</h2>
        <p>See <a
           href="[[[ftp://ftp.rfc-editor.org/in-notes/rfc3863.txt]]]">
           RFC3863</a>.</p>
      </body>
      </html>
    END

5.3. URN sub-namespace registration for

     'urn:ietf:params:xml:ns:pidf:status'
 URI
    urn:ietf:params:xml:ns:pidf:status
 Description:
    This is the XML namespace URI for XML elements defined by
    RFC 3863 to describe extensions to the status of CPP presence
    information in application/pidf+xml content type.
 Registrant Contact
    IETF, IMPP working group, <impp@iastate.edu>
    Hiroyasu Sugano, <sugano.h@jp.fujitsu.com>
 XML
    BEGIN
      <?xml version="1.0"?>

Sugano, et al. Standards Track [Page 20] RFC 3863 Presence Information Data Format August 2004

      <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
                "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
      <html xmlns="http://www.w3.org/1999/xhtml">
      <head>
        <meta http-equiv="content-type"
           content="text/html;charset=utf-8"/>
        <title>Namespace for CPP status extensions</title>
      </head>
      <body>
        <h1>Namespace for CPP presence information extensions</h1>
        <h2>urn:ietf:params:xml:ns:pidf:status</h2>
      <p>See <a
        href="[[[ftp://ftp.rfc-editor.org/in-notes/rfc3863.txt]]]">
        RFC3863</a>.</p>
      </body>
      </html>
    END

6. Security Considerations

 Because presence is very privacy-sensitive information, the protocol
 for the presence information MUST have capabilities to protect PIDF
 from possible threats, such as eavesdropping, corruption, tamper and
 replay attacks.  These security mechanisms must be able to be used
 end-to-end between presentities and watchers, even if the watcher and
 the presentity employ different presence protocols and communicate
 through a CPP gateway.  Since the 'application/pidf+xml' MIME type is
 defined for this PIDF document, staging security for PIDF at the MIME
 level (with S/MIME [RFC3851]) seems appropriate.  Therefore, PIDF
 should follow the normative recommendations for the use of S/MIME
 (including minimum ciphersuites) given in the core CPP specification.
 Note that the use of timestamps in PIDF (see section 4.1.7) can
 provide some rudimentary protection against replay attacks.  If a
 watcher receives presence information that is outdated, it SHOULD be
 ignored.  A watcher can determine that presence information is
 outdated in a number of fashions.  Most significantly, if the newest
 timestamp in presence information is older than the newest timestamp
 in the last received presence information, it should be considered
 outdated.  Applications and protocols also are advised to adopt their
 own rules for determining how frequently presence information should
 be refreshed.  For example, if presence information appears to be
 more than one hour old, it could be considered outdated (a
 notification generated for this presence information will not take
 such a long time to reach a watcher, and if a presentity has not
 refreshed its presence state in the last hour, it is probably
 offline).

Sugano, et al. Standards Track [Page 21] RFC 3863 Presence Information Data Format August 2004

7. Internationalization Considerations

 All the processors conformant to this specification MUST be able to
 generate and accept UTF-8 encoding, this being one of the mandatory
 character encodings for XML conforming processors, and also required
 by the policies set out in RFC 2277 [RFC2277].
 Other character encodings MAY be accepted (but CPP compliant
 processors are strongly discouraged from emitting anything other than
 UTF-8).

8. References

8.1. Normative References

 [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", RFC 2119, BCP 14, March 1997.
 [RFC3023]      Murata, M., St. Laurent, S., and D. Kohn, "XML Media
                Types", RFC 3023, January 2001.
 [XML]          Bray, T., Paoli, J., Sperberg-McQueen, C., and E.
                Maler, "Extensible Markup Language (XML) 1.0 (Second
                Edition)", W3C Recommendation, October 2000,
                <http://www.w3.org/TR/2000/REC-xml-20001006>
 [MIME]         Freed, N. and N. Borenstein, "Multipurpose Internet
                Mail Extensions (MIME) Part One: Format of Internet
                Message Bodies", RFC 2045, November 1996.
                Freed, N. and N. Borenstein, "Multipurpose Internet
                Mail Extensions (MIME) Part Two: Media Types", RFC
                2046, November 1996.
                Moore, K., "MIME (Multipurpose Internet Mail
                Extensions) Part Three:  Message Header Extensions for
                Non-ASCII Text", RFC 2047, November 1996.
                Freed, N., Klensin, J., and J. Postel, "Multipurpose
                Internet Mail Extensions (MIME) Part Four:
                Registration Procedures", BCP 13, RFC 2048, November
                1996.
                Freed, N. and N. Borenstein, "Multipurpose Internet
                Mail Extensions (MIME) Part Five: Conformance Criteria
                and Examples", RFC 2049, November 1996.

Sugano, et al. Standards Track [Page 22] RFC 3863 Presence Information Data Format August 2004

 [RFC3066]      Alvestrand, H., "Tags for the Identification of
                Languages", BCP 47, RFC 3066, March 1995.
 [RFC3339]      Klyne, G. and C. Newman, "Date and Time on the
                Internet: Timestamps", RFC 3339, July 2002.
 [XML-NS]       Bray, T., Hollander, D., and A. Layman "Namespaces in
                XML", W3C recommendation: xml-names, 14 January 1999,
                <http://www.w3.org/TR/REC-xml-names>
 [URI]          Berners-Lee, T., Fielding, R., and L. Masinter,
                "Uniform Resource Identifiers (URI): Generic Syntax",
                RFC 2396, August 1998.
 [URN]          Moats, R., "URN Syntax", RFC 2141, May 1997.
 [URN-NS-IETF]  Moats, R., "A URN Namespace for IETF Documents", RFC
                2648, August 1999.
 [XML-Registry] Mealling, M., "The IETF XML Registry", RFC 3688,
                January 2004.
 [RFC2277]      Alvestrand, H., "IETF Policy on Character Sets and
                Languages", BCP 18, RFC 2277, January 1998.
 [XMLSchema1]   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/>.

8.2. Informative References

 [RFC2778]      Day, M., Rosenberg, J., and H. Sugano, "A Model for
                Presence and Instant Messaging", RFC 2778, February
                2000.
 [RFC2779]      Day, M., Aggarwal, S., Mohr, G., and J. Vincent,
                "Instant Messaging / Presence Protocol Requirements",
                RFC 2779, February 2000.
 [CPIM]         Peterson, J., "Common Profile for Instant Messaging
                (CPIM)", RFC 3860, August 2004.
 [CPP]          Peterson, J., "Common Presence for Presence (CPP)",
                RFC 3859, August 2004.
 [vCard]        Dawson, F. and T. Howes, "vCard MIME Directory
                Profile", RFC 2426, September 1998.

Sugano, et al. Standards Track [Page 23] RFC 3863 Presence Information Data Format August 2004

 [RFC3851]      Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
                Extensions (S/MIME) Version 3.1 Message
                Specification", RFC 3851, July 2004.
 [RFC3282]      Alvestrand, H., "Content Language Headers", RFC 3282,
                May 2002.

Sugano, et al. Standards Track [Page 24] RFC 3863 Presence Information Data Format August 2004

Appendix A. Document Type Definitions

 The Document Type Definition for the "application/pidf+xml" format is
 described.  The DTD here is presented only for informational for
 those who may not familiar with the XML Schema definition.
 Note: the DTD does not show where extension elements can be added.
 See the XML Schema for that information.
 <!ENTITY % URL         "CDATA">
 <!ENTITY % URI         "CDATA">
 <!ENTITY % TUPLEID     "CDATA">
 <!ENTITY % DATETIME    "CDATA">
 <!ENTITY % VALUETYPE   "CDATA">
 <!ENTITY % PRIORITY    "CDATA">
 <!ENTITY % NOTE        "CDATA">
 <!ELEMENT presence ((tuple*),note?)>
 <!ATTLIST presence
           xmlns     %URI;     #REQUIRED
           entity    %URL;     #REQUIRED
 >
 <!ELEMENT tuple (status,contact?,note?,timestamp?)>
 <!ATTLIST tuple
           id   %TUPLEID;      #REQUIRED
 >
 <!ELEMENT status (basic?)>
 <!ELEMENT basic CDATA>
 <!ELEMENT contact %URL;>
 <!ATTLIST contact
           priority %PRIORITY; #IMPLIED
 >
 <!ELEMENT note %NOTE;>
 <!ELEMENT timestamp %DATETIME;>

Sugano, et al. Standards Track [Page 25] RFC 3863 Presence Information Data Format August 2004

Authors' Addresses

 Hiroyasu Sugano
 Fujitsu Laboratories Ltd.
 64, Nishiwaki
 Ohkubo-cho
 Akashi 674-8555
 Japan
 EMail: sugano.h@jp.fujitsu.com
 Shingo Fujimoto
 Fujitsu Laboratories Ltd.
 64, Nishiwaki
 Ohkubo-cho
 Akashi 674-8555
 Japan
 EMail: shingo_fujimoto@jp.fujitsu.com
 Graham Klyne
 Nine by Nine
 EMail: GK@ninebynine.org
 Adrian Bateman
 VisionTech Limited
 Colton, Staffordshire, WS15 3LD
 United Kingdom
 EMail: bateman@acm.org
 Wayne Carr
 Intel Corporation
 2111 NE 25th Avenue
 Hillsboro, OR 97124
 USA
 EMail: wayne.carr@intel.com

Sugano, et al. Standards Track [Page 26] RFC 3863 Presence Information Data Format August 2004

 Jon Peterson
 NeuStar, Inc.
 1800 Sutter St
 Suite 570
 Concord, CA  94520
 USA
 Phone: +1 925/363-8720
 EMail: jon.peterson@neustar.biz

Sugano, et al. Standards Track [Page 27] RFC 3863 Presence Information Data Format August 2004

Full Copyright Statement

 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.
 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.

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.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Sugano, et al. Standards Track [Page 28]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3863.txt · Last modified: 2004/08/16 19:42 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki