Re: PIDF for buddylists

Adrian Bateman wrote:
> 
> Don't forget that 2778/2779 only defined the base
> vocabulary/requirements. CPIM/PIDF/etc define the implementation
> decisions taken to produce our standard IMPP that fits the model.

Yes. I'm mindful that what we are discussing here is likely at minimum an extension to PIDF. I don't want to derail plans for timely progress on presence.

Hopefully extensions should be sufficient, and could come down the pipeline after the current stuff progresses.

One way to represent more than one level of hierarchy is simply to include a <presence> element in a <tuple> as an extension element. So it could also be added as an
optional element in a future extension and be backward compatible.

A subscription option to receive differences rather than full updates could be encoded in the body as part of a filter. This would make sense, since it is a sort of filter.
And it would be compatible with the current direction.

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>

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.

	Paul



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