RE: Presence service basics

I don't really believe that there are any misunderstandings at this
point in the debate about the arguments and positions of those involved.
It seems to me that there are simply fundamental disagreements about the
requirements and it is unlikely that people's opinions on this will
change now.

That said, help is at hand because we have a definitive approach to
solving the issues in this group. That approach is to provide for the
requirements in RFC 2779 that provide a specific implementation for the
model defined in RFC 2778 and that we should introduce only those things
necessary to meet those requirements or to make the protocol work.

Graham's catching up summary is a useful one but I think we also need to
talk in terms of the requirements.

There are two main issues I think:

A) The concept of whether timestamps are necessary in the envelope for
presence notifications.

     Jon Peterson has provided us with a rebuttal in terms of the
decisions made
     as part of RFC 2779 (notably 8.1.4 A5/A7) which he contends means
that this
     is not necessary.

     John Ramsdell clearly disagrees and has given examples of attacks
that can't
     be detected without such a timestamp. I think, however, that John
must point
     out explicitly how RFC 2779 requires us to handle these cases.

I contend that unless we can clearly show that we must handle these
issues, out 'minimalist' approach says that they should not be dealt
with now.

B) The concept of having some service/domain authority who can sign
presence notifications on behalf of different presentities. There is a
debate about whether this should be a URI or a domain name.

I can't find anything which requires us to handle this case. John's
concept of a corporate authority charged with signing any unsigned
notifications might be useful to some people in some situations but so
might a host of other things to other people. If we must handle this
situation, can someone point me to the RFC 2779 requirement that
mandates this.

Best,

Adrian.