RE: [Simple] Re: PIDF status values

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

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.

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




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