RE: comments on draft-ietf-impp-cpim-pidf-05

On 27 August 2002 07:07, Peterson, Jon wrote:
> MUST level, not a SHOULD. Also, note that deferring this function to
the
> 'transport protocol' (we might want to use another term here, to
> differentiate this from layer 4 protocols - maybe 'using protocol'?)
has a
> number of dangerous implications, the most serious of which is that
the
> contents of a confidential notification would be revealed to a CPIM
gateway
> when an encrypted message was passed from one CPIM-compliant protocol
to
> another. I believe this security must be staged around the MIME body,
not

I believe that this is what we meant - what we were saying was that the
security staged around the MIME body was not part of the PIDF scope. It
does belong in CPIM but I'm not sure that there is a consensus there
about precise formats. The main point was that we wanted a format for
presence information that might be used in isolation from the actual
transportation/notification of that information; for example, it might
be stored in a database. One might think that this would still need to
be able to store, say, signatures, but I think this is a local thing.
Clearly, if you think of the parallel case, encryption, you normally
encrypt based upon who you want to be able to read the information so
that wouldn't make sense here.


> - A few things about timestamps. First, I think that 2.2 (b) should
mention

That makes sense - the implication of timestamps is probably only more
fully understood following the recent debate - that's a positive thing.

> PIDF. First, I believe that the document could greatly benefit from an
> example of an XML Schema for an extension to PIDF that could be used
as a
> reference by those that intend to extend PIDF (perhaps an XML Schema
> definition for the 'local' extension shown in 4.2.4). There is already
an
> example of how a PIDF body would look with such an extension, which
benefits
> implementers, but protocol designers could use some help with
authoring

This is a good idea - it shouldn't be too difficult to achieve such an
example. One thing we need to be careful about, however, is to not uses
something for the example that is misinterpreted as a standard. In the
past people have mistakenly criticised PIDF because they believed, for
example, that it was defining states 'away' and 'busy'.

> these extensions as well. Secondly, I think the document should offer
some
> guidance about how extensions are managed at a process level in the
IETF or
> elsewhere. Should extensions (with their XML Schema and motivational
text)
> be published as RFCs, or it enough to just register the URN in the
> designated namespace? Is any particular review process required for
these
> extensions? Personally, I think that the semantics of these extensions
merit
> inclusion in an RFC, and that this should be strongly encouraged if
not
> required. If standardization is not encouraged, I fear this will lead
to the
> balkanization of presence extensions, the proliferation of many
slightly
> differing but unfortunately non-interoperable presence extensions that
will
> be used by competing protocols or providers.

I think the publication of extensions depends upon the use. I certainly
expect lots of implementations to want to store their own local-specific
presence information. It would be wise to include some information about
the process but I'm not sure we should spend too much time on this. As
the 'debates' in the SIMPLE group can attest, getting people to agree on
much beyond OPEN and CLOSED is difficult at best.


> - The mustUnderstand attribute in 4.2.3 provides some primitive but
useful
[snip]
> down to something that all devices support, namely <basic>  - I
suspect that
[snip]
> requires us to have a mustUnderstand-like concept - we could abandon
it,
> saying that <basic> is mandatory and all extensions are optional
(which

There's two things here: if a presence document is rejected because of
mustUnderstand, I would expect a client to unsubscribe and indicate that
it isn't compatible with the available presence information. At the
moment, I can't really think of a suitable example where the
mustUnderstand attribute seems really useful, however. Secondly, though,
it is important to realise that not all presence information 'extends'
<basic>. The (somewhat clumsy?) text tries to say that <basic> must be
present where it makes sense (e.g. for the availability of an instant
message box that says 'busy' but also must say whether that means OPEN
or CLOSED) but not where it doesn't (e.g. a location value).


Adrian.