*Attendees*
Art Vandenberg, GSU
Tom Barton, U. Chicago
Tyler Johnson, UNC-Chapel Hill
Nadim El-Khoury, UNC-Chapel Hill
Jeanette Fielden, Internet2
Steve Olshansky, Internet2

*Discussion*
Nadim El-Khoury of UNC –Chapel Hill is the new chair of the VidMid-VC Working Group.

Presence is an area of interest for H.350. Presence is defined in the IETF with a SIMPLE set of standards. SIMPLE is a SIP extension so it may not work with H.323 or other protocols. SIMPLE is also not yet standardized. The issue of multi-domain secure realm and scalability is better addressed in LDAP than SIMPLE. The H.350 architecture has dialing attributes so presence would be just another attribute. LDAP has been criticized for being write intensive but presence conforms to the notion of reading frequency being greater than writing frequency so that should not be an issue. The architecture allows the separation of the commObject information from the enterprise directory so the directory could be tuned for high-speed access, and used for presence though not quite as dynamic as SIMPLE. The IETF definition of presence could serve as a starting point. IETF RFC's that reference presence are: RFC 2778, RFC 2779, and RFC 3343. commObject may be another possibility for storing presence information. Study Group 16 of the ITU has some interest in the notion of presence as well.
[AI] Tyler can write a technical document outlining what we propose that could be presented at the September ITU meeting.

Microsoft uses SIMPLE, it is not known if AOL does. Samir has previously agreed to write up a summary of what he thought the existing efforts in SIMPLE are. Most implementations seem to be very single domain oriented. There don't appear to be any that are large scale with multiple autonomous realms. The new Presence Integrated Communications Working Group under the Applications area of Internet2 should be contacted to see where the intersection of interests and work are between them and VidMid-VC. There is also an existing P2P group at the application level and some discussion about creating a middleware P2P group in the fall time frame. There is also a P2P project called LionShare at Penn State that should be reviewed. http://p2p.libraries.psu.edu/

LDAP doesn't solve the federation issue. It does scale up to enterprises. Our model would be multiple enterprises. LDAP supports robust security in terms of communication with the LDAP server and fine-grained access control to data. These are fundamental prerequisites for any federation applied on top of that.

A key issue is the definition of presence. What exactly is presence? And where is the distinction between presence and resource discovery? On AOL it is your ID that's present. Is the person actually present for the related device? Ideally, the person is present for the related device. A buddy list may be separate from presence and actually be a resource discovery mechanism. There are multiple dimensions to the problem: presence information and recording it, then discovering that information, and who's allowed to discover that, i.e. restricting access. The architecture of the entire solution will have to be taken into account. Requirements, attributes and scenarios outlining how they might be used need to be clearly defined first.

Resource discovery also needs to be more clearly defined. Art described a paper on resource discovery that defined it as the registering of information and the mechanism to find that information and take action on it. You can describe a place to store appropriate information on state of presence and describe the processes that maintain the information and processes by which it can be found and read. Part of that is presence itself, and part is resource discovery of presence.
[AI] Art will forward a link to a paper on resource discovery.

In AIM you can search by e-mail address, which is also supported in the MIT and Yale approach.
There is the AIM feature for group chat, which raises privacy implications around resource discovery.
Friendster.com is a social networking site based around the concept of six degrees of separation and self-selecting groups. You can talk to friends, or friends of friends but not to just anyone, there has to be a connection. Friend of A Friend is an open source version of friendster, http://rdfweb.org/.
[AI] Tyler and Nadim will write a proposal of possible work for the VidMid VC group and will circulate for comment.

LDAP ENUM:
ENUM is a standard adopted by the IETF that uses the domain name system (DNS) to map telephone numbers to IP locations. There are a couple of drawbacks. NAPTR records are not widely used and DNS is insecure. DNSIX is proposed to address that but it's not widely deployed. There is also privacy issues since people can discover all this information associated with your DNS entry. ENUM is hierarchical and not meant to generically resolve numbers. In the U.S. that would mean telephone companies would control data and have all the associated regulation of that industry.

The notion has been advanced that LDAP might be able to address this problem more effectively. It's secure, scalable, and implementable now. It's a large complex problem and requires an in-depth exploration of what the problem trying to solve is and the associated issues of security, privacy, number updates, randomness of numbers due to number portability, size of the number space, and resource discovery. The H.323 forum has formed a dialing plan working group. ViDe.net was originally formed around this issue.

How do you find the LDAP entry you're looking for and once found what credentials do you use access it? You can't have credentials in everyone's directory so you would have to give processes limited credentials and that creates a much more complex kind of architecture.

The next call is July 28, 2003.