Presence and IntComm WG

["Ben Chinowsky" <>]

*Action Items as of October 26*

(high priority)
[ACTION] All will read
http://middleware.internet2.edu/i2im/docs/draft-internet2-mace-i2im-pseudonymous-cases-01.html
in preparation for the continued federations discussion on the October 27 
call.
[ACTION] Ben T. will update SER on PALS with the latest PIC-SER package.
[ACTION] Rodger and Candace will try to organize a call with CounterPath
sometime in the next few weeks.
[ACTION] For the next few conference calls, Rodger will recruit PIC-SER
participants to summarize their experiences.
[ACTION] Based on PIC-SER experiences, the group will evaluate what functions
(e.g. group chat) should be added to the next version of the package.
[ACTION] Jamey will see if there's a writeup of the HP work on Linux location
tracking technologies.
[ACTION] Candace will follow up with Mike on the presence-updates issue.
[ACTION] Dennis will send Steve a short description of the proposed topic for
Cullen Jennings' talk.

(medium priority)
[ACTION] Steve will try to schedule Cullen Jennings as a guest speaker
on one of the PIC conference calls.
[ACTION] Candace will add a Wiki document on strict vs. loose routing.

(low priority)
[ACTION] Candace and Jamey will initiate an email discussion of their proposal
to modify the SER PA module so it can do presence via SUBSCRIBE and NOTIFY, to
accommodate clients that don't do PUBLISH.
[ACTION] Jamey will enable eyeBeam to use presence info to decide
whether messages should go straight to voicemail.
[ACTION] Jamey will update the interface requirements document.
[ACTION] Jamey will continue working on the future of the skiffs, and solicit
opinions from PIC members as needed.
[ACTION] People will research skiff-like offerings from various companies:
- Dennis - Newbury
- Rodger - Airespace (now part of Cisco)
- Jeremy - Eckehau (via Walt Magnussen)
[ACTION] Candace will look into Tyler Johnson's H.350-enabled version of the
NIST client.
[ACTION] Ben T. will write a short document describing the motivation for the
paths-in-the-snow approach to PIC development.

*Attendees*

Ben Teitelbaum (acting chair) - Internet2
Dennis Baron - MIT
Candace Holman - Harvard
Ben Chinowsky (scribe) - Internet2

*Discussion*

The call was devoted to defining what "federations" might mean in the SIP and
presence contexts. This discussion will continue on the October 27 call.

Definitions of what "federation" might mean in the context of SIP:

1. Federated Identity.

I, domain Y.edu, trust domain X.edu; domain X.edu trusts you and makes an
assertion about you (e.g. you are a registered student); therefore I believe 
it.
This is a natural extension of Shibboleth to SIP. The I2IM working group has
produced an excellent document that explores some usage scenarios for
authenticated IM, including anonymous IM.  [ACTION] All will read
http://middleware.internet2.edu/i2im/docs/draft-internet2-mace-i2im-pseudonymous-cases-01.html
in preparation for the continued federations discussion on the October 27 
call.

Deke believes that this could be a useful direction for the PIC WG. Although 
he
could not attend the call, he sent some comments by email that were deliveried
via proxy. Deke noted that federated identity could be accomplished via
pair-wise, hierarchical, or web-of-trust relationships. He also observed
that schools "already have the infrastructure in place to manage online
identities for their users and have a growing maturity in their ability to 
issue
assertions across realms", and suggested that PIC consider taking advantage of
this for presence and calling-party information.

2. Intra-Federation Peering.

a. You are part of the federation, therefore I will let your calls in. 
Otherwise
I won't, or I'll route them to the recipient's "probably SPIT" voicemail 
inbox.

b. We are part of the same federation, therefore I trust that when I route 
calls
to you via SIP, you will transmit them with a specified voice quality.

c. We are part of the same federation, therefore I trust that when I receive
calls from you via SIP, I can initiate a traceback into your domain if the 
call
is harassing or otherwise mischievous.

3. Inter-Federation Peering.

My federation has a deal with your federation/network/ITSP; therefore we will,
e.g., exchange traffic or relax SPIT-prevention measures.

4. Federated Resource Sharing.

a. You are in my disaster-recovery federation and experiencing a disaster;
therefore I'll route outbound PSTN calls for you and absorb the cost (because 
I
know you'd do the same for me if our roles were reversed).

b. You are in my federation, and I have a Shibboleth-like assertion about your
attributes; therefore I will give you access to some valuable human resource
(e.g. a research librarian).


Definitions of what "federation" might mean in the context of presence:

1. Protocol Federation.

We'll work together to build a gateway between my SIMPLE domain and your XMPP
domain.

Candace noted that we haven't really made inter-realm SIMPLE work yet.
Ben T. noted that the PIC WG has already decided against focusing on gateways.

2. Presence Federation.

I trust your domain; therefore I'll apply a relatively relaxed filter when I
share the presence of my users with yours.

There was general agreement that users should retain control over what
presence information to reveal, but Candace noted that presence federation
could still be useful for tasks that clients might not be able to accomplish,
like setting up a blacklist.

It was also noted that, as far as anyone on the call was aware, communication
between presence servers hasn't been tried, although there are standards for
it. Candace noted that it's not clear whether having servers talk to each
other would be an optimization or just a complication.