RE: PIDF for buddylists

I've been away travelling and haven't been following this - so apologies in
advance.

The proposal looks like adding the ability to add extensions as the direct
child of the presence element.  That's already in
http://www.ietf.org/internet-drafts/draft-ietf-impp-cpim-pidf-05.txt  The **
part of the suggested schema section below are in the XML schema now.

Also for people not familiar with XML schema --  in another Internet Draft
someone can define a new XML format in a new namespace that includes the
PIDF format presence element (lists of them if they want).  They don't need
to redefine PIDF in their draft, they just include it by including an
element with the pidf namespace - so can have lists of presence elements.

I think the PIDF format is flexible enough that it can handle the types of
things being discussed without changes to PIDF itself.

> -----Original Message-----
> From: Adrian Bateman [mailto:[email protected]]
> Sent: Monday, June 10, 2002 10:50 PM
> To: 'Paul Kyzivat'
> Cc: [email protected]; [email protected]; [email protected]
> Subject: RE: PIDF for buddylists
> 
> 
> On 10 June 2002 23:51, Paul Kyzivat wrote:
> > One thing that might be a problem would be indicating that 
> a response 
> > has had filtering and/or differencing applied. Some of it could be 
> > handled as extension values in tuples, but I can foresee a need to 
> > know this at the <presence> level too. One possible change to the 
> > current proposed PIDF format that might help here would be to make 
> > explicit provision for extension values within <presence> 
> itself. This
> 
> > would look like:
> > 
> >       <xs:complexType name="presence">
> >          <xs:sequence>
> >             <xs:element name="tuple" type="tns:tuple"
> maxOccurs="unbounded"/>
> >             <xs:element name="note" type="xs:string" minOccurs="0"
> >                 maxOccurs="unbounded"/>
> > *           <xs:any namespace="##other" processContents="lax"
> minOccurs="0"
> > *              maxOccurs="unbounded"/>
> >          </xs:sequence>
> >          <xs:attribute name="entity" type="xs:anyURI" 
> use="required"/>
> >       </xs:complexType>
> 
> This has been mentioned in the past, but AFAIK, this is the first
> concrete example of *why* we should make it. In the past, I think I've
> probably stuck with the letter of 2778 using our current approach, but
> on the basis that this is such a small change, has been 
> requested a few
> times, and generally looks like a good idea, I think we 
> should adopt it.
> 
> > Another approach for handling this kind of change would be 
> to simply 
> > define a different presence document type for representing 
> diffs and 
> > multilevel presence status. Clients wanting to use it would 
> then have 
> > to be prepared for servers that can't handle it, by falling back to 
> > the old PIDF.
> 
> I'd like to avoid that if possible - I think we should make 
> the change.
> 
> Adrian.
> 
> 
> 
> 
> 
>   [reminder: [email protected] for non-technical 
> discussions, please]
> 



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