Re: Improving PIDF

A bunch of comments here.

First off, when you mentioned this split during the meeting, I was not 
entirely sure what you meant. In my mind, there wasn't really anything 
about PIDF that was IM specific. It seems that, in your interpretation, 
the status, note and contact components are associated with IM, and that 
other tuple types could omit such elements. However, I do not find that 
consistent with the model in RFC 2778. That model explicitly points out 
that each tuple has a status, an address (i.e., contact) and other 
markup. It does not say that these are specific to IM; they are generic 
to all tuple types.

In fact, RFC 2778 explicitly says that the basic status of OPEN/CLOSED 
applies to IM, but that:

>   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

OK, so it does say that status "may" apply to other types. However, the 
fact that this is "may" as opposed to "does" hardly seems to merit 
ripping this document in half.

You also give examples of tuples such as location. In my view, location 
is a status for a tuple, not a tuple itself. What is the communications 
means associated with location? There is none. The model explicitly 
calls out that a tuple has a particular communications means associated 
with it.

As a result, I do not see much reason for this split, and would prefer 
to continue with PIDF as defined and as agreed upon to date.

I'll also point out that you have changed the specifications beyond just 
this split. The most obvious change is the MIME type, which you propose 
to change from application/cpim-pidf+xml to application/cpp-pidf+xml. 
This, of course, will completely break interoperability with existing 
implementations, of which there are many. Yes, yes, I know, this is an 
I-D and we are allowed to change. But, I find this change gratuitous, 
and given that I see little value in the document split, of no benefit.

To reiterate my basic philosophy here with regards to IMPP:

  IF IT AINT BROKE, DONT FIX IT
  FINISHED IS A FEATURE, AND ITS THE MOST IMPORTANT ONE

Thanks,
Jonathan R.

Thanos Diacakis wrote:
> Following up on our discussion in Atlanta last week, in line with neatly
> separating the CPIM draft into three separate drafts, we need to split PIDF
> into two.  As I mentioned last week, I'm not suggesting any functionality or
> content changes.  We need all the content, just in two separate drafts.
> 
> The logic behind this is that PIDF essentially contains two things:
> 
> 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)
> 
> It doesn't make sense to mandate that all presence documents that use (a),
> need to carry the elements in (b), of which indeed some are mandatory.  For
> example, a tuple that publishes one's location doesn't necessarily need a
> "status" field.
> 
> Also, the separation between the presence format, and particular attribute
> schemata will serve as a good example on how to add new schemata to cover
> other applications.  (e.g. the SIMPLE WG is working on a similar item
> [draft-lonnfors-simple-prescaps-ext-00]).
> 
> Lastly, we can better focus the main PIDF draft on issues related to joining
> and splitting PI documents without needing to worry about what is in them at
> the same time.
> 
> Having said that, I've performed this split and made the two resulting
> drafts available here:
> 
> http://www.diacakis.com/impp/draft-diacakis-ietf-impp-cpp-pidf-00.txt
> http://www.diacakis.com/impp/draft-diacakis-ietf-impp-cpp-pidf-im-00.txt
> 
> In addition to the split, while I was at it, I added two more changes:
> - Jonathan's "zero or more tuples" - I presume there are no objections to
> that
> - Misc fixes replacing CPIM with CPP & CPIM as necessary
> 
> After this is scrutinized and if there are no objections, I would propose to
> make those two docs WG drafts.
> 
> Thanos
> ---
> Thanos Diacakis
> Openwave Systems
> [email protected]
> +1-303 385 6705
> 
> 
> 
> 
> 
> 
> 
>   [reminder: [email protected] for non-technical discussions, please]
> 
> 

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email protected]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com




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