Presence and IntComm WG

[Jeremy George <>]

  Maybe it would be helpful to talk a little bit about how the demos
work from just a few thousand feet above the code level.  The brief
architectural overview I did pretty much got buried in the doco but
let's use it for reference.  pic.internet2.edu/PIC-note.pdf.

  The first thing to notice is that presence and location services are
being developed by two different groups in the ietf, and they're using
two different architectures.  So, smushing them together we came up with
"pals", or presence and location services.  Because the nomenclatures
are different we need to be a little tolerant of descriptive language.
I think I'll stick to presence for the moment.

  Referring to the url above, when a UA (pda, laptop, whatever) is
powered up, in the architecture we're using, a PUBLISH message is sent
to the presence server.  Let's keep it simple and say the machine has
just notified the server it's online.

  The presence server has a list of watchers who have SUBSCRIBEd to
my presence information, with my explicit permission.  The server
sends NOTIFYs to each of the authorized watchers and the transaction
is complete.  For rich presence and location services the transaction
is more complicated but follows the same general path.

  With an edge presence server (what Microsoft currently implements)
there is no central server.  Subscriber information, permission
mechanisms, etc. are all located on the same machine as the UA.

  Bringing this back to the tussle space discussion, I suggest that
the centralized architecture favors the government in that it has
a single point to tap with an appropriate court order.  The latter
presents a technical barrier to that law enforcement approach.  Each
stakeholder has a clearly defined interest and each of the architectures
tilts the field.

  Bringing it all the way back to Dr. Clark's notion, the tussle space
is large enough to accomodate each of the stakeholders.

- Jeremy

--