Re: PIDF status values

Following a discussion in the SIMPLE group I am not sure that values such 
as 
"away" or "busy" are really statuses. They seem to be *hints* to the user 
on how 
s/he should anticipate that the message will be handled. The actual 
handling of 
"away" for example can be displaying the message in hidden window in one 
system 
and in other system the message will be displayed in a pop up window.

In parallel it seems that this discussion should be a joint discussion of 
the 
SIMPLE and the IMPP groups.

Avshalom Houri
Presence and Instant Messaging Architect
Lotus Sametime, IBM Software Group
[email protected]






"Adrian Bateman" <[email protected]>
Sent by: [email protected]
17/04/2002 13:39
Please respond to "Adrian Bateman"

 
        To:        "'Mark Day'" <[email protected]>, "'Hiroyasu Sugano'" 
<[email protected]>, "'Graham Klyne'" <[email protected]>
        cc:        <[email protected]>
        Subject:        PIDF status values

 

This is a draft describing the my proposal for the structure of the
status values within PIDF. My example reflects the urn change
recommended by Graham and the use of the 'entity' attribute as discussed
previously on the list.

When it came down to it, I couldn't think of a tremendous amount to
write for the 4.2.4 section so if there are gaps you'd like mentioned,
please let me know, or fill them in :o).

To address Graham's issue with a status value registry, aren't we
covered by simply registering the xml namespace urn?

Regards,

Adrian.


4.1.4  The <status> element

   The <status> element contains one or more elements indicating status
   values. It can have multiple status values at the same time. 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 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="YES"
   attribute (see section 4.2.3).


4.1.5  The <basic> element

   The <basic> element contains a CDATA value whose possible values are
   either "open" or "closed". The values "open" and "closed" has the
   same meaning as OPEN and CLOSED defined in RFC 2778 respectively, and
   stand for 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.2.4  Status value extensibility

   This memo only defines the <basic> status value with values of "open"
   and "closed". Other status values are possible using the standard
   namespace-based extensibility rules defined above.

   For example, a location status value might be included thus:
 
       <presence xmlns="urn:ietf:params:xml:ns:cpim-pidf"
           xmlns:local="urn:example-com:pidf-status-type"
           entity="pres:[email protected]">
         <tuple id="im">
           <status>
             <basic>open</basic>
             <local:location>home</local:location>
           </status>
           <contact>im:[email protected]</contact>
         </tuple>
       </presence>

   Some new status values will 'extend' the value of the <basic>
element.
   For example, a status value defined for use with instant messaging
may
   include values such as 'away', 'busy' and 'offline'. In order that
   some level of interoperability be maintained with user agents that
   don't recognise the new extension, the <basic> status value must also
   be included. This means that extensions are not obligated to define a
   mapping from each of their values to OPEN or CLOSED.




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