Re: PIDF - some things left out of draft

Adrian,

I think we should be more explicit about how extension status values are integrated;
that is,
 * where the extension values can be placed?
 * what the extensions of <basic> element means?
 * what happens if the <basic> value and an extension value seems to be contradictory
    (or, which has the precedence?)
 * and so on.

Would you suggest some additional wordings?

It would also be nice if there is a statement that the <basic> element is optional.
Although
I know it would be redundant, it would be much better to be explicit.

Regards,


-- Hiroyasu Sugano


----- Original Message -----
From: "Adrian Bateman" <[email protected]>
To: "'Carr, Wayne'" <[email protected]>; "'Hiroyasu Sugano'"
<[email protected]>; "'Graham Klyne'" <[email protected]>; <[email protected]>
Sent: Friday, May 03, 2002 4:01 AM
Subject: RE: PIDF - some things left out of draft


> On 02 May 2002 19:47, Carr, Wayne wrote:
> > > It says this in the context of status values that 'extend' the value
>
> > > of the <basic> element. The must is for this extension case, not the
> > > general case. It reads that way to me, but if you've got some
> > > alternative text that makes it clearer, feel free to post it.
> >
> > I think that's the part I'm confused about.  To extend the basic
> > element -- doesn't that mean to include child elements inside the
> > <status> element from some other namespaces?  (so not really extending
>
> > the <basic> element, but including other child elements inside status)
>
> > I read the sentence as meaning if you use those other extensions
> > elements in another namespace then you have to include a <basic>
> > element too.  Wouldn't that mean you always have the <basic> element -
>
> > otherwise there would be nothing at all as content of the <status>
> > element.
>
> I meant in a semantic sense - the <basic> element represents status as
> regards the acceptance of instant messages. Some status value ranges
> will be designed to 'extend' the two allowable states by providing
> greater granularity. I anticipate that there will be a great deal of
> argument in the discussions for producing an IETF instant messaging
> status range particularly in dealing with how different values map to
> open or closed. For example, does 'busy' mean I'm accepting messages but
> doing something else so I may not answer, or does it mean I'm doing
> something else so I'm not accepting messages. By saying that these types
> of status range must include the <basic> element for interoperability,
> not only does this imply some downward compatibility, but it negates the
> point of such an argument.
>
> Other types of status value will be entirely orthogonal to the <basic>
> element and as such stand in their own right. I don't consider this
> 'extending' the value of <basic>, but merely including additional status
> information.
>
> Maybe 'extend' is the wrong word, but it was the best I came up with.
>
> Adrian.
>
>
>
>
>   [reminder: [email protected] for non-technical discussions, please]
>
>



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