Presence Information ProtocolsINLS310 – Seminar in Internet Policy and Future Initiative; Tuesday, April 25Instructor: Paul Jones Presenter: Peter Buch |
What is a PIP?
How they work Hacking ICQ Extending the model RVP Resources |
What is a PIP?
A presence information protocol is a set of messages and
methods that determine whether and where an internet user is online. They are implemented commercially as services
called “buddy lists” or “instant messengers”. The biggest are ICQ, Netscape
AOL Instant Messenger, and MSN Messenger. Here’s what they do:
Why do we care?
Buddy lists are pretty simple,
but they employ two very powerful concepts.
The first is public directories – you can locate someone by any one of
a number of properties. The second is
the subscription/notification model.
This is the internet-wide implementation of event-driven
programming. We can find out about
others, tell others about us, and take actions based on what we find. This is a very basic framework for the
deployment of agents on the web. Will we
ever see this? Not so long as the
parochial interests of buddy list providers rules the day. This
report gives a look at current PIP technology, and a wish list for an open
standard. Curiously, the Evil Empire
had a proposal on the table that would fill the wish list and more, and which
could easily have provided the framework for powerful agents. But they took it off the table, and
nothing has been heard since. Someday,
though, open directories and subscription-notification protocols will revolutionize the web, and change the
communications model forever. How they work.
Nearly
all buddy list systems use a combination of client/server and peer-to-peer
(client/client) protocols. A purely peer-to-peer system will have difficulty
in accounting for dynamic IP addresses. A system that most people will use
must handle dynamic IP addresses, so we will only discuss systems that have a
client/server component. Once you have installed
a buddy list program, you must register at the server. The server will
collect personal information that identifies you to other users, such as your
name, home address, and e-mail address. Your e-mail address will typically be
used to verify that you are, in fact, a unique new person. The system may
then continue to use your e-mail address as your handle, or it may assign you
a system-generated handle. The system-generated handle is a somewhat superior
approach, since you won’t be required to start over if you change your e-mail
service. A small, low-profile
application is launched when you start your computer, to listen for internet
activity. The application uses very little memory and very few cycles. It has
to be smart enough to stay away from FTP and Telnet, so it takes a
combination of connecting to via TCP/IP and launching an HTTP browser to
trigger the startup sequence. The program now contacts
the server for the service you installed. This can be a fairly slow process,
since you are competing with other users who are also signing on, or have
already signed on. (Remember, this is free!). Your client tells the server
that you are on, and (this is crucial), what IP address you are using. Now
you are marked as signed on (for now) at the server. Other clients can learn,
via the server, that you are there, and contact you. If you don’t already
have a list of buddies, you need to make one. This is done by searching or
browsing the server’s list of registered users by any one of the parameters
it collected at registration time. If you find someone you want, you add
their handle to your list. If you don’t find who you are looking for, but you
have reason to believe that he or she will be registering soon, many services
allow you to leave a spot for them, usually identified by e-mail address, so
that they will be automatically added to your list when they join. When you sign on, the
service will check your list against the most current server information to
see who is signed on. The server will ping it’s active users periodically to
make to see if they are still connected to the internet. Your client will
periodically query the server to refresh your list with the latest news of
who’s on and who’s off. You’re on, I’m on. We
know each other’s IP addresses. We’re ready to talk. Some sevices will handle
the negotiations between the clients before leaving them on their own. Others
will leave the negotiations to the clients. The best services will
allow you to do any of these things: o
Send
quick messages o
Chat o
Transfer
(small) files o
Share
a URL o
Send
(quick) e-mail o
Join
in a game Some of
the more generous services will store messages for users who are not logged
on, much like a mail server does. Since these services are free, there is
very little disk storage allocated per user, so messages saved on the server
should be short, and will expire quickly. Hacking ICQ
If you know the layout of the messages the client sends,
you can talk to the server yourself.
That’s what Netscape did when Microsoft introduced MSN Messenger –
they gave their users access to the MSN Messenger database of users. Until MSN scrambled their messages. It’s pretty easy to reverse engineer the messages. I got these layouts from a college kid in Sweden. http://www.student.nada.kth.se/~d95-mih/icq/spec/v2/icq091.txt Client to server.
Server
to client format is identical, except the UIN is omitted. This
is the layout of the Parms area for a CHANNEL_INIT, which initiates a TCP
session between clients. The initiating user is referred to as local – the
other user is remote.
1 IP address and Real IP address will be the same unless
the user is behind a firewall. 2.
The remote user’s IP address and Port are returned in the USER_ONLINE server
message. These are selected sample commands. The command names
are, I assume, purely speculative.
Extending the model.
The problem with buddy lists is that you can only talk to people on your own server. It’s electronic feudalism. We need to adopt standards. If we were to design a standard for PIP’s, what would be on our wish list? ·
Open communications. Everybody could access everybody else’s directory, so long as
they followed the protocol. ·
Server to server communications. One server could not handle the entire
database of users, nor all the traffic.
We need a model, much like domain name servers, for sharing information. ·
Information about properties other than
online/offline. You should be able to
inquire about or subscribe to any properties the server wishes to support. Examples – away/ back in town, still
married/divorced, looking for a used car/selling a car. ·
Support for authentication. ·
Reciprocal messages. An agent inquiring about properties must be willing to reveal
verifiable information about the inquiring user. ·
Support for initiation of any type of
communication, e.g. net phone, videoconference, without knowing the
particulars of that communication protocol. The Rendezvous Proposal.
Microsoft
has long been a proponent of open standards, provided that those standards
are developed by Microsoft. Someone more cynical than the author might
suggest that Microsoft proposed open standard for instant messaging only
after losing the ICQ battle to AOL. The author prefers to give credence to
Microsoft’s claim that it looked at ICQ, sniffed, and decided that a new open
standard would be a far better idea. In 1998 Microsoft proposed to the IETF an open Presence
Information Protocol standard known as the Rendezvous Protocol (RVP). ( RVP
is and extension to the HTTP-DAV specification.) The industry has responded
with widespread support – more than forty development companies endorsed the
standard. Regardless of the events leading to Microsoft’s proposal, RVP looked
like a clear winner. At the same time, Microsoft began plans for their own MSN
Instant Messenger, which they launched in 1999. Since that time, all of the drafts have disappeared, and
neither the IETF Working Group nor Microsoft appear to be working towards any
open standards. A draft
of a proposal specifying the desired characteristics of an open instant
messaging protocol, written Martin R. Calsyn and Lisa Dusseault of Microsoft,
is available at: http://search.ietf.org/internet-drafts/draft-dussealt-pipr-00.txt ·
Globally
unique human-readable address can be assigned to a user without consulting a
central authority. Microsoft
has provided server-to-server methods without specifying what server topology
to use. One implementation might be to deploy RVP servers by domain, by ISP,
or by geographic location. ·
Supports
a subscription/notification model. A user can subscribe to one, many or all persistent or
"leased" properties of a node. Signed-on is an obvious, but
certainly not the only, property. ·
Users
should be able to query standard properties of a group to obtain a list of
current subscribers. Or a list of groups, I hope! ·
A
name representing a property container or property in the PIP namespace
should be mappable to one or more servers capable of answering requests
targeted at that container or property. I included this in it’s entirety because it is
important. This is crucial to server-to-server interoperability. ·
Supports
1-to-1, 1-to-many and interest-classified messaging. A container may hold a collection
of one or more nodes. Properties must include one or more unique names,
associated unambiguous addresses, and control information about
authorization. Beyond that, properties may be whatever you want. ·
Supports
reverse-lookup. All
subscription and notification methods must send responses to both parties. If
someone wants to know something about you, you get to find out "Who
wants to know?" Blocking, of course, is supported. ·
The
PIP should support many different types of content. Instant messages are the only
media with support built into the protocol, but since the protocol supports
media negotiation, one can extend invitations to any media one choose,
including streaming media such as sound or video. ·
The
protocol should facilitate the transport of credentials. Microsoft has wisely chosen not
to specify what will be used for authentication, but simply to provide for
implementation of the developers/users choice of standards. ·
Users
may roam. RVP
provides for forwarding on a temporary or permanent basis. ·
Control
over peer-to-peer messaging. Peer-to-peer is clearly superior with regard to
efficiency, but implementations may want to retain control over client
activity. This will make the suits happy – they can continue to spy on their
employees. ·
Firewall
friendly. The
intention is to provide a vehicle, but to leave the specifics of firewall
negotiation to the implementation. RVP
is not intended to: ·
·
Replace
e-mail. There
are no requirements for message storage for offline users. On the other hand,
there is no reason you can’t. I t’s not far-fetched to suggest that e-mail is
vulnerable. ·
Replace
LDAP. Microsoft
considers LDAP to be sufficient for communicating static data. RVP is better
for dynamic properties, and, of course, offers presence information and
messaging. I would not be surprised to see LDAP become a functional subset of
RVP. A look under RVP’s
(proposed) hood The next level of detail on RVP is found in RVP
Implementation Specification, by Sonu Aggarwal, Josh Cohen and Jesse
Vincent, all of Microsoft. Here, a set of methods are detailed, without regard
for language or environment-specific implementations. Methods This is
a representative, but incomplete, list of methods.
Some RVP Implementation
Characteristics Containers. RVP
uses XML containers. Collections. Resources
may be collections of other resources, such as nodes. Depth. The
depth header specification of 0 means the request applies only to the
resource, 1 means the resource and it's children, infinity means all levels
of subordination. Authorization to access
properties. If a requester is not authorized to access properties,
the RVP server will respond "quietly", omitting the property. Mime. Mime
type headers may be enclosed within a mime-data XML element An RVP Example This example is reprinted from
the RVP Implementation Specification Draft The following example retrieves
the online status and displayname properties of an RVP user. Note that in all examples that follow, the exact URL for the RVP namespace is TBD. >>Request
PROPFIND
/local/im.example.com/users/stevem/ HTTP/1.1 Host:
dino.seattle.example.com Notifications-Version: 1.0 Depth: 0 Content-type: text/xml Content-Length: xyz <?xml
version="1.0" ?> <?xml:namespace
ns="DAV:" prefix="D" ?> <?xml:namespace
ns="http://www.w3.com/standards/foo/notification/"
prefix="Z" ?> <D:propfind>
<D:prop>
<Z:online-status/>
<D:displayname/>
</D:prop>
</D:propfind>
>>Response
HTTP/1.1
207 Multi-Status Notifications-Version: 1.0 Content-Type: text/xml Content-Length: xxxxx <?xml
version="1.0" ?> <?xml:namespace
ns="DAV:" prefix="D" ?> <?xml:namespace
ns="http://www.w3.com/standards/foo/notification/"
prefix="Z" ?> <D:multistatus> <D:response> <D:href>http://dino.seattle.example.com/local/im.example.com/users/stevem/</D:href> <D:propstat> <D:prop>
<Z:online-status>
online </Z:online-status> <D:displayname>
Steve Morgan </D:displayname> </D:prop> <D:status>HTTP/1.1
200 OK</D:status> </D:propstat>
</D:response>
</D:multistatus
Attack of the loosely coupled federated constellation of servers RVP offers huge opportunities, far beyond it's suggested use as a replacement for buddy lists. RVP is, in fact, a simple model for event-driven information acquisition and publication. By using an XML, meta-data driven model, Microsoft has provided an open-ended framework for modeling knowledge of networks of users and their interests. Developers, once they adopt the standard, will have to define commonly accepted public behaviors for servers. This will take time, but there are endless variations on implementations. Standalone IM clients will become a thing of the past. RVP will be implemented in browsers and groupware clients. E-mail will not go away quickly, but it is not unlikely that RVP servers will provide sufficient capacity to store messages for users. Super servers could traverse all known servers, and acquire knowledge of what the servers contain. Servers could act as agents, interacting with other persistent RVP resources, and negotiating relationships on behalf of individuals and groups (or themselves). Anyone who
can provide or use a persistent resource on the Internet could maintain
unattended intelligent communications.
Resources.
The Internet Messaging and Presence Protocols (IMPP)
working group of the Internet Engineering Task Force (IETF) http://search.ietf.org:80/html.charters/impp-charter.html An
boring article from Wired about PIP’s:
ICQ Internals http://www.student.nada.kth.se/~d95-mih/icq/spec/v2/icq091.txt
|
