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

Some notes below. Sounds like we're mostly in agreement.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Adrian Bateman [mailto:[email protected]]
> Sent: Tuesday, August 27, 2002 2:22 AM
> To: 'Peterson, Jon'; [email protected]
> Cc: [email protected]
> Subject: RE: comments on draft-ietf-impp-cpim-pidf-05
> 
> 
> On 27 August 2002 07:07, Peterson, Jon wrote:
[snip]
> > 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. 

Well, I would be surprised if anyone seriously contended that RFC2779 did
not require us to adopt a common format for end-to-end security. Several of
the requirements entail that directly. In the absence of some baseline
common security mechanism (and ciphersuite) secure implementations will not
be interoperable. I think we have a mandate to come to consensus on a
format.

> 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.
> 

All correct - I just think that the high-level security properties of
presence information identified in RFC2779 need to be explicitly enumerated
as requirements, that's all, and that somewhere in the CPIM document set
there must be some interoperable understanding of how security is applied
when it is necessary.

[snip]
> > extensions? Personally, I think that the semantics of these extensions
merit
> > inclusion in an RFC
[snip]
> 
> 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.
> 

Well, today the document just doesn't say one way or another about
standardization of extension schemas that I could find. I think we would all
agree that we expect this work to be extended, and I think we should make
sure that extensibility is well-specified in the document either way. And
personally I do believe that encouraging the registration merely of names
for extensions seems a little less ambitious than we need to be, given our
objectives. Of course we shouldn't rule out private or proprietary
extensions, but nor should we encourage that there be nothing but.

Fair enough about the difficulty of coming to consensus. I think we should
continue to encourage standards work in this direction, though, however
tedious it may be.

[snip]
> 
> > - 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. 

Yes, that's bad - especially if <basic> is also present in the information,
but the client is forced to unsubscribe because of some unrelated mandatory
extension.

> At the
> moment, I can't really think of a suitable example where the
> mustUnderstand attribute seems really useful, however. 

I've had some trouble with that myself, actually.

> 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).

Agreed, <basic> doesn't need to be sent in every message. But mustUnderstand
doesn't really add any value to this case - <basic> is optional, and if
neither <basic> nor any known extension is present, then presence
information will not be used, regardless of the presence of 'mustUnderstand'
on the extension. All I want is to prevent usable presence information from
being discarded.

> 
> 
> Adrian.
> 



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