Subject: [Simple] Re: PIDF status values

From: "Avshalom Houri" <[email-masked]>
Date: Wed, 17 Apr 2002 21:30:13 +0300

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

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

        To:        "'Mark Day'" <[email-masked]>, "'Hiroyasu Sugano'" 
<[email-masked]>, "'Graham Klyne'" <[email-masked]>
        cc:        <[email-masked]>
        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-masked]">
         <tuple id="im">
           <status>
             <basic>open</basic>
             <local:location>home</local:location>
           </status>
           <contact>im:[email-masked]</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-masked] for non-technical discussions, please]

---

From: "Adrian Bateman" <[email-masked]>
Date: Wed, 17 Apr 2002 20:14:39 +0100

On 17 April 2002 19:30, Avshalom Houri wrote:
> 
> 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 
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. 

What's the difference between a status value and a hint? RFC 2778
doesn't define a hint, it merely refers to STATUS. In any event, in PIDF
we made a conscious decision to include only OPEN and CLOSED and to
leave the definition of other status ranges for future invention.

It seems to me that the value of some status elements will, perhaps more
often than not, be processed automatically, maybe to determine an icon
to display. These values are well defined and are as much status
information as open/closed, just intended for a different purpose.
Status values aren't limited only to those determining the presentity's
likely acceptance of instant messages. RFC 2778 just says that in that
case (instant messaging) the values OPEN and CLOSED are at minimum
necessary.

The language below uses 'away' and 'busy' simply as examples using words
that many people using current Instant Messaging agents will recognise.
If you'd prefer alternative language, by all means suggest some. My
point is to emphasise that we should maintain the basic open/closed
values for interoperability and that it isn't mandatory to define
mappings from other status ranges to the basic values.

> In parallel it seems that this discussion should be a joint discussion

> of the SIMPLE and the IMPP groups.

Yes, I for one welcome further input. The IMPP group is quiet and there
is much more activity in SIMPLE. In fact, I requested just such
discussion in my message to the SIMPLE list last Friday.

Best regards,

Adrian.

>         To:        "'Mark Day'" <[email-masked]>, "'Hiroyasu
Sugano'" <[email-masked]>, "'Graham Klyne'" <[email-masked]>

> recommended by Graham and the use of the 'entity' attribute as 
> discussed previously on the list.
> 

different
multiple
mustUnderstand="YES"
is
element.
may
>  [reminder: [email-masked] for non-technical discussions, 

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple