RE: PIDF extension schema documentation

"Peterson, Jon" <[email protected]>
Newsgroups gmane.ietf.impp
Message-ID <[email protected]>
[snip]
> what do you consider a baseline requirement here. The things I can think
> of include:
> 
> * An XML schema that can be used to validate the extension namespace
> * Registration of the namespace
> * An RFC describing the expected use of the extension including the
> schema and referring to the namespace registration
> 

I think that's a good start. We might also encourage (expanding here on the
'use of the extension'):

* A domain of applicability for 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?
* Semantics for presence states defined in the extension. Merely having the
syntax (schema) might not always be sufficient. What disposition provokes a
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 (about, say, how they should best
attempt to communicate with the presentity, if at all, under this
condition).
* How, if at all, any presence states defined in the extension relate to
<basic>, or to any relevant extension previously published in an RFC. e.g.
State Z implies OPEN, so it MUST NOT be used if a basic state of CLOSED is
expressed. e.g. You should use the extension in this document, not the
extension in RFC QQQQ, if your circumstances are thus.

I think the first of these should probably be mandatory - the second two
optional.

At a process level, I think there should also be some review of presence
extensions by some parties to ensure that the applicability is appropriate,
that the extension does not overlap dramatically with any previous
extension, that names for presence states are reasonably useful and
informative, and so on. We would need to describe the need for this review
in cpim-pidf-0x as well.

[snip]

Jon Peterson
NeuStar, Inc. 



  [reminder: [email protected] for non-technical discussions, please]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.