RE: [Simple] RE: PIDF for buddylists

Sorry for not following the recent changes closely enough. I'm glad this
change was made :o)

Adrian.


On 11 June 2002 20:44, Carr, Wayne wrote:
> 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]
> > 
> _______________________________________________
> simple mailing list
> [email protected] 
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 





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