draft-ietf-impp-cpim-pidf-06.txt (was: WG Last Call on multiple documents (deadline Jan 12))

Yeah.  I know.  This is after the official deadline.

Sorry.

Detailed comments below.  Unfortunately, they are extensive, and often
basic.

This document needs to be substantially updated, to reflect the IM/Pres
specification split that how been done.  There is no reason for this
document to refer to IM at all.

The constant citation of key definitions and semantics in RFC2778 and
RFC2779 makes this document essentially unreadable.  It means that the
reader must constantly thumb back and forth among the different
documents.

It's fine to cite the others documents at the beginning and explain
that they provide requirements and definitions.  However the current
specification need not reference those other documents for validity or
for details. This is a specification document and it
should try to provide a specification as independently as possible.

This specification has a basic problem with extensibility and with
dependence on instant messaging.  Any portion that might have IM
information and/or other information needs to specify what the
alternatives are (and the associated syntax and semantics) or needs to
cite a registry for finding such information.

Offhand, I suggest citing a registry and then priming the pump with an
Appendix entry for portions associated with IM.

/d




              Common Presence and Instant Messaging (CPIM)
                    Presence Information Data Format

<<
   [[ The definition of CPIM is incorrect.  The simplest thing to do is
   simply title the document  "Presence Information Data Format (PIDF)".

   All references to IM should be removed.  This really is a separate
   service now.  Where a reference to a service is required, it should
   be to CPP.  (I suggest that the data type be application/pidf+xml.)
   /d ]]
>>


Abstract

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


1.     Introduction

   The Common Profile for Instant Messaging (CPIM) specifications define
   a set of common operations and various formats to achieve
   interoperability between different Instant Messaging and Presence
   protocols which meet RFC 2779 [RFC2779]. The CPIM core specification
   [CPIM] defines a set of common operations and their parameters to be
   supported by interworking Presence and IM protocols in order to allow
   straightforward gatewaying between them.  The CPIM Message Format
   [CPIM-MSG] defines a common format for instant messages, which
   enables secure end-to-end IM exchange through the gateways.
<<
   [[ Delete the above paragraph.  The next paragraph works dandy as an
   introduction.
   /d ]]
>>

   This memo further defines the CPIM Presence Information Data Format
   (PIDF) as a common presence data format for CPIM-compliant presence
   protocols.  The significance of the common presence format primarily
   resides in the fact that it alleviates the load of gatewaying of
   messages with presence data payloads.  Without such a common presence
   data format, a gateway must process and transform the presence data
   payload from one format to another every time it gateways the
   protocol messages.  Such payload processing also disables the
   validity of digitally signed presence data.  Utilizing the common
   presence data format allows secure transfer of the presence payloads
   across the boundary of different protocol domains.

<< The significance of the ... digitally signed presence data.
   [[Delete the contained sentences.  This specification is no longer
   about gatewaying.  It is about end-to-end data.
   /d ]]
>>

   The format specified in this memo is intended to define the base
<<  "The format specified in this memo is intended to define the"
   ->
   The format specified in this memo defines the
>>

...

2.     Design Decisions

   We have adopted the IMPP Model and Requirements documents [RFC2778,
   RFC2779] as the starting point of our discussion. The two RFCs
   contains a number of statements about presence information, which can

<< contains -> contain
>>

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


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 more narrowly in this document to refer only to a
       URI. (RFC2778:Sec.3)

<<     URI -> URL
>>

   (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.
<<
  [[ What does OPEN/CLOSED actually mean?  How are we to know the
  meanings for non-IM URLs?
  /d ]]
>>

       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)
<<
   [[ what does it mean to have multiple values?
   /d ]]
>>


...

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

   This memo defines a new content type "application/cpim-pidf+xml" for
   an XML MIME entity that encodes presence information conformant to
   this specification. 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
   STRONGLY RECOMMENDED. If the 'charset' parameter is not specified,

<< ->
   The 'charset' parameter SHOULD be used.
>>
   conforming XML processors to [XML] MUST follow the requirements in
   section 4.3.3 of [XML].


3.2.   Presence Information Contents

   This subsection outlines the information in an "application/cpim-
   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
       - Status: OPEN/CLOSED for Instant Messaging or status for
           other communication means.
       - Communication address: communication means and contact
           address of this tuple. (optional)

<< ???  >>>

...

4.1.2. The <tuple> element

...

   The <tuple> element MUST contain an 'id' attribute which is used to
   distinguish this tuple from other tuples in the same XML document.
   The value of an 'id' attribute MUST be unique within 'id' attribute
   values of other tuples in the same document.  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 SHOULD be
   treated as just a CDATA value (no semantics).

<<
   [[ Where is CDATA defined?
   Also - need to specify global uniqueness of identifier.
   /d]]
>>

   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.

<<
   [[ What does it mean to have no communications means?  How is the
   tuple used?
   /d]]
>>

   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
   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> elements, followed
   by any number of OPTIONAL extension elements 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 complexity is really essential, given the goal of
  minimality???
  /d ]]
>>



Sugano et al.                                                   [Page 9]

INTERNET DRAFT            CPIM Presence Format             December 2002


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

<<
   [[ How is the requirement for minimality served by permitting
   alternative, equivalent values?
   /d
>>

   Note that, while the <status> element MUST have at least one status
   value element, this status value may 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" has the same meaning as
   OPEN and CLOSED defined in RFC 2778 respectively, and stand for

<<
   [[ Provide the definition *here* !
   /d
   ]]
>>

   availability of receiving instant messages if the <tuple> is for an
   instant messaging address. They also have meanings of general
   availability for other communication means. But, this memo does not
   specify them in detail.


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 semantics being provided apply to the word "precedence",
   rather than "priority".
   /d
   ]]
>>

   The value of the
   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.

<<
   [[This is quite strange.  Why not keep things simple?  Instead of
   invoking fraction calculations (and representation), just specify
   the value to be an integer between 0 and 100.
   /d
   ]]
>>

    If the
   'priority' attribute is omitted, applications MUST understand that
   the contact address has the lowest priority.  If the 'priority' value

<<
   MUST understand that the contact address has the lowest
   ->
   MUST assign the contact address the lowest
>>
   
   is out of the range, applications just SHOULD ignore the value and
   process it as if the attribute was not present.

   It is RECOMMENDED that applications handles a contact with higher

<<
   ->  Applications SHOULD handle a contact with higher
>>
   priority than another one so that the priority is recognizable by
   users.

<<
   [[ Actually, I do not understand the above sentence.  I can't even
   guess what it is supposed to mean.
   /d
   ]]
>>

   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.



Sugano et al.                                                  [Page 10]

INTERNET DRAFT            CPIM Presence Format             December 2002


   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.
<<
   [[ You mean that it might be ok for a comment field, like <note> to
   be used for something semantic, like status of parent???  This is
   inviting non-interoperable.  Either the field is a human readable
   content or it is machine-readable and needs to permit formal
   definition.  (Anyone want me to cite yet another bit of experience
   from email?
   /d ]]
>>

   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 indentifier as defined by [RFC1766]. 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.

<<
   [[ How does a timestamp provide security?
   /d ]]
>>


...

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 use recognized names.

<<
   [[ What does "appears to use recognized names" mean, in the face of
   an "element with an unrecognized name"?
   /d]]
>>

   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.
<<
   [[ what is the alternative, besides "informational"?  What would it
   mean for an extension to *not* be informational?
   It appears that a mandatory status is being cited as opposite to
   informational.
   /d ]]
>>


...

   If an agent receives PRESENCE INFORMATION with a <status> block
   containing an unrecognized element that has a mustUnderstand='true'
   (or '1') attribute, it should treat the entire element as
   unrecognized and not attempt to process it.

   Note that the mustUnderstand attribute MUST NOT be used in a way that
   might prevent a minimal implementation from understanding the basic
   PIDF information defined in this specification.  To ensure this, the
   mustUnderstand attribute MUST NOT be used outside elements within
   optional, so that non-recognition of a mandatory extension results in
   no worse than ignoring the optional extension in which it is
   contained.

<<

  [[ There are quite a few negatives in the above paragraph. The
  combination makes the text a bit opaque. (Human cognitive processes
  do not handle negatives as well as positives; something that one
  might not immediately guess from IETF discussions...) Perhaps it is
  sufficient to to have the text say something like:

  In order to ensure that minimal implementations can correctly
  process basic PIDF information the mustUnderstand attribute MUST be
  used only within option [[optional what?]]. This will ensure that
  problems processing an extension are restricted to that extension
  and do not affect the processing of basic PIDF informationl.

  /d]]
>>




  [reminder: [email protected] for non-technical discussions, please]