Presence and IntComm WG

[Michael Van Norman <>]

> In the draft, presence is addressed by Person, Service, and Device.  In
> section 3.5, Modeling Ambiguity, the difficulty is named - should it be
> the watcher (application, human, etc.) or the agent (generally
> automated) that merges conflicting presence information?  Sounds like
> philosophy but there are some technical recommendations.  The
> service/device/person occurrence can be uniquely identified with an
> occurrence identifier and tracked.  But to resolve ambiguities, the URI
> should not be used as the occurrence identifier. With presence agents, I
> think this means that a user agent URI should not be allowed to login to
> a server more than once. After the first login, subsequent logins should
> overrule the previous occurrence identifier. Without this, location
> tracking is not possible.  Additionally, and especially in a
> peer-to-peer case, when all else fails, the timestamp on the presence
> update document can be used by either server or peer to resolve the
> ambiguity.  What do you think?

I would consider the single login restriction to be severely broken.  We
have to handle to following:

I am working on my office workstation.  I leave for home/meeting/etc and my
client automatically marks me away.

I open up my laptop (or log into my home machine) and my SIP client sets me
available at this location.

I turn off my home machine (or leave it running and it marks me away due to
idle timers), leave the meeting, etc., and return to my office.  My
workstation client will notice me back and un-away me.

If I am using my laptop in my office, both clients will show me as
available.

I can only do this with multiple logins.  If I have to explicitly login
in/out at various locations, I simply won't use it.  I'll use Skype/AIM/etc
-- which handle this fine and don't make me do anything special.

Systems today handle the ambiguity.  SIP, to compete, has to handle it as
well -- it can't just define it away.

> To answer your question about the Refresh Interval on EyeBeam, that
> variable indicates how long you want your subscription to the presence
> agent to last.  I would like to see EyeBeam produce an error message
> when the subscription expires and you then try to update your contact
> list or your own presence, but I don't think it's a requirement to
> automatically resubscribe.  I think that's a privacy issue.

If this is what the variable means, then eyeBeam *MUST* have an option to
automatically re-subscribe.  Otherwise it is broken (in the sense that
people won't use it).

Bottom line, this stuff HAS to work as easy and transparently as AIM and
Skype.  If it doesn't just work, people will use what does.

/Mike