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

Jon,

Friday, January 24, 2003, 12:24:22 PM, you wrote:
>>
>> 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.
>> 

PJ> A comment to similar was received before last call, actually - Thanos wrote

Indeed he did.  And what he suggested actually matches what I am
suggesting.  He said:

             a) a format to carry any type of presence data (generally
             speaking that is the <presence> and <tuple> elements)

             b) a set of attributes or presence schema pertaining to
             IM or perhaps more broadly interpreted "communications
             presence" (that is nearly everything inside the tuple,
             except e.g. timestamp)

The key point is to separate normative text for Presence that is independent of any
particular medium like IM or email, and to specify normative text for
medium-specific Presence information somewhere else.  Thanos cites
another document.  I cited an Appendix.  The difference is not
significant, for the point I was making and, apparently, he was
making.


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


PJ> Well, RFC2779 contains a lot of text that is intended to be requirements for
PJ> a presence information data format. Showing how this document satisfies
PJ> those requirements is important.

For a judicial review, yes it is important.  However that is not the
job of a technical specification.  It needs to specify. It needs
enough pedagogy to aid understanding and implementation.  That's all.

Having the document serve multiple purposes (specification vs. defense
against claims that it does not match the requirements) reduces its
effectiveness for both.

As I said, it is one thing to have the introduction contain some
explanatory text and reference to the requirements document.  It is an
entirely different matter to have the entire text sprinkled with cross
references


PJ>  I think this is a pretty common practice
PJ> here in the IETF. These references are largely confined to an early section
PJ> that exists specifically to show how PIDF relates to RFC2778/9.

In fact the document makes normative references to the requirements
documents in a number of places.


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

I would not have cited the issue unless I thought it did, as well as
being distracting.



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

Glad we agree that references to IM should be in examples, rather than
normative text.



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

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

Sorry, no.  The current effort has nothing at all to do with
gatewaying.  This is an end-to-end object.  It does not get
translated.  Gateways do translation.  Relaying is what is done to
this object, not gatewaying.


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

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

Except for the few places where the UR* is simply used as a unique
identifier  (eg., <id>) it is a locator.  Hence they all need to say
URL, because that what they are.  Saying URI means, for example, that
a URN might qualify, and that would be incorrect.


>>    STRONGLY RECOMMENDED. If the 'charset' parameter is not specified,
>> 
>> << ->
>>    The 'charset' parameter SHOULD be used.
>> >>

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

amazing.  never saw that.

why keep things simple when we can have so much fun juggling
alternatives?   And, of course, the "strongly" helps the semantics
quite a lot.


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

PJ> ?

So much for my proofreading efforts.  Meant to add text asking what
the heck a communication address is, compared with the presentity's
URL?  How are the two different in specification and use?



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

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

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

Oops.


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

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

Sorry but I do not understand what this means.  It would help to see
something concrete as an example of use.

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

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

The complexity I was referring to was "multiple status values".


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

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

Having two different representations for the same semantics is not
"richer".  It is, in fact, an invitation to greater complexity and,
therefore, more bugs and less interoperability.


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

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

I guess that proves that, the current language in the spec needs to be
easier to understand...


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

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

I don't think so, since an attacker can modify it.

Without encryption-based data integrity added to the timestamp, the
timestamp adds nothing to security.


d/
-- 
 Dave <mailto:[email protected]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 t +1.408.246.8253; f +1.408.850.1850




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