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

Some notes inline.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Dave Crocker [mailto:[email protected]]
> Sent: Friday, January 24, 2003 7:13 AM
> To: [email protected]
> Subject: draft-ietf-impp-cpim-pidf-06.txt (was: WG Last Call 
> on multiple
> documents (deadline Jan 12))
> 
> 
[snip]
> 
> 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.
> 

A comment to similar was received before last call, actually - Thanos wrote
some notes about this to this mailing list on 11/26. The thread that
followed discussed the dependency of PIDF on IM in some detail.

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

Well, RFC2779 contains a lot of text that is intended to be requirements for
a presence information data format. Showing how this document satisfies
those requirements is important. I think this is a pretty common practice
here in the IETF. These references are largely confined to an early section
that exists specifically to show how PIDF relates to RFC2778/9.

While this may make the document less readable, I don't think it imposes too
much of a burden on the reader - it doesn't make this document incomplete
somehow.

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

I agree that the title and remainder of the document should not use this
older notation of 'CPIM'. I don't think we need to remove all references to
IM, however - I think it is valid to refer to IM as an example of a
communication means used in the <contact> element. I agree that the document
should not be IM-specific - but other than the legacy use of the term CPIM,
I don't think the document really does.

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

I think it worth referring to CPP in the introduction somewhere, maybe in
the first sentence below instead of 'CPIM'.

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

Actually, I think these words are still quite necessary. We still intend
that there might be gateways that presence information will pass through.
PIDF provides a format that can be shared end-to-end by different presence
protocols that interconnect through a gateway.

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

Agreed.

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

Good.

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

I think we want URI, actually. We define IM, for example, as a URI in the
impp-srv document.

> 
>    (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 ]]
> >>

I think we can rely on the definitions in RFC2778/RFC2779, particular in 2.4

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

Again, this is just citing RFC2778. I'm not sure we need to reiterate what
it says here. The definition of status in Section 3, rather than Section
2.4, or RFC2778 might be a better reference for this, though.

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

Last I checked, SHOULD and RECOMMENDED were synonymous in RFC2119.

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

CDATA is defined by XML. We could put a reference here, I suppose.

It doesn't say that the 'id' attribute needs to be globally unique above...
it merely says it needs to be unique among tuples in a single PIDF document.
Is there a motivation for which should be globally unique?

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

The example that is constantly held up is geo-location - there is an idea
that some forms of presence do not describe a communications disposition.

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

It is essential to allow something beyond OPEN and CLOSED if we hope it to
be useful, yes.

It is also a requirement from RFC2779 that this format be extensible
(2779:3.1.4)

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

Again, we inherit this from RFC2779. Personally, I think this requirement
makes sense. We've all no doubt seen commercial IM&P systems with a richer
status vocabulary. This extensibility allows individual services employing
PIDF to choose richer statuses to their liking, while maintaining baseline
OPEN/CLOSED functionality with other providers when both speak PIDF.

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


From RFC2778 2.4:

   STATUS is further defined by the model to have at least two states
   that interact with INSTANT MESSAGE delivery -- OPEN, in which INSTANT
   MESSAGES will be accepted, and CLOSED, in which INSTANT MESSAGES will
   not be accepted. OPEN and CLOSED may also be applicable to other
   COMMUNICATION MEANS -- OPEN mapping to some state meaning "available"
   or "open for business" while CLOSED means "unavailable" or "closed to
   business." The model allows STATUS to include other values, which may
   be interpretable by programs or only by persons.  The model also
   allows STATUS to consist of single or multiple values.

Perhaps we could just remind readers of this passage here?

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

'Priority' is pretty commonly used in this sense in my experience, though I
recognize that 'precedence' is probably better.

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

I can't speak to the historical reasons why this was chosen, but this
couldn't be a show-stopper either way. I'd rather keep it as it is, given
the status of the document.

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

Fair.

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

Again, last I checked in RFC2119, these two statements were equivalent.

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

That is also fair. I think it is trying to state the obvious - that
applications SHOULD prefer contacts with a higher priority.

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

I think this sentence says exactly the opposite - that <note> SHOULD NOT be
used instead of <status>. 'Parent' above refers to XML parent. If <note>
appears in <tuple> (<tuple> is its parent), then <note> should not be used
as a substitute for <status>. In other words, it's arguing exactly what you
are, I think.

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

It provids some limited replay protection. If you turn to the last paragraph
of the Sec Cons, as the paragraph above suggests, you will see some more
text about it.

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

Yeah, that is pretty thick - that sentence should be cleaned up.

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

Maybe 'informational' isn't the right word. The sense this is trying to get
across, I think, is that extensions to PIDF do not change what PIDF is,
allow one to define new top-level <elements> - they only allow you to
provide supplemental <status> information. It is also trying to get across
that these extensions cannot be mandatory - that is, that you cannot fail to
understand PIDF because you fail to understand an extension.

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

Regarding [optional what?], how about: ... used only within optional
elements nestled in a <status> element.

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



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