Minutes recorded magnificently by Lisa Lippert, lightly edited to full sentences for
IETF minutes by Mark Day.
BOF chair: Mark Day, Lotus
The initial agenda consisted of 4 parts:
1. administrivia (finishing WG charter, choosing WG chair(s))
2. hearing about recent related designs (IDIP, SIP, PIP-DEMO)
3. discussing the draft requirements document
4. summarizing, setting action items.
1. ADMINISTRIVIA
The BOF at the L.A. IETF meeting worked out a wording for the charter but we didn't
get milestones or a chair fixed. The milestones have been discussed on the list and are
as follows:
August 1: Requirements draft 1
IETF 42: Discuss requirements draft 1
October 15: Requirements draft 2
November 15: Protocol draft 1
December 1: WG last call on Requirements
IETF 43: Meet to discuss Protocol draft 1
March 1 (1999): Protocol draft 2
IETF 44: Meet to discuss Protocol draft 2
June 1: Protocol draft 3
July 15: WG last call on Protocol
A clarifying question (reflected in the milestones above) was whether the requirements
would still be under discussion at IETF 43, after the WG last call. The goal was not to
be discussing the requirements at the next IETF meeting, but to instead be discussing
the protocol.
Choosing a chair: Mark moved to name Dave Marvit of Fujitsu and Vijay Saraswat of
AT&T as co-chairs.
Schulzrinne questioned whether Dave Marvit actually had a proposal before the
working group and therefore could not act as an unbiased co-chair -- Mark explained
that Dave's work was not a proposal for PIP, although it was a related, more general
proposal that could well be of interest to people interested in PIP. We put off the final
decision about chairs until after Dave's presentation.
2. RECENT DESIGNS
2.1 Identity Infrastructure Protocol (IDIP) -- Dave Marvit, Fujitsu
There is more to presence stuff than just buddy lists. Identity is a superset of presence
and should be considered in its own right. Online identity is a persistent kind of presence.
The IDentity Infrastructure consists of data about individuals, applications... The model
presented allows multiple "Identity Objects" (IDOs) to communicate over IDIP
See http://idi.fla.fujitsu.com for more detail
Summary suggestion : that a new WG should be formed to discuss identity, which
could be a bunch of issues that excludes buddy lists being dealt with in PIPR, OR --
that the PIPR WG should include identity issues.
2.2 SIP, PIP & IDIP -- Jonathan Rosenberg, Lucent
Session Initiation Protocol (SIP) is a product of the mmusic WG. SIP is in IESG last
call. SIP is http-like, and supports registration -- i.e. it is possible to inform a proxy of
where a user is (expressible as a URL). In addition, SIP has means to describe a
complex policy about how calls should be redirected according to rules: if caller = Joe
then busy... if day = monday then redirect...
A lot of the problems of locating users and advertising where they are, contact policy
and things like that, are done by SIP. Jonathan presented what would need to be done
to meet the PIPR requirements in SIP and concluded that one or two methods (NOTIFY,
SUBSCRIBE), and no new headers, would need to be added to make SIP solve the PIPR
issues as identified by the draft requirements.
The advantages of using SIP: it already exists (in last call); it makes launching
multimedia integration easy (it integrates with the existing IETF multimedia
infrastructure); it solves major reliability problems that PIP will have to solve.
2..3 PIP-DEMO -- Gordon Mohr, Activerse
Gordon pointed to the pressing need for standards: the market for buddy lists is taking
off even without any standard or interoperability. Right now, using buddy lists means
committing yourself to a single vendor and not all options are possible.
PIP-DEMO is just a demo protocol, to throw out ideas. It is not necessarily secure or
stable, but it includes the major pieces necessary:
- subscriptions
- the ability to sense, at a distance, the presence of somebody
- standard format/data model
- the ability to indicate what you're interested in hearing about
- enables instant messaging
- bare minimum required for implementation
PIP-DEMO is http-like to avoid starting from scratch. It adds two methods to an
HTTP-like base: SUBSCRIBE and NOTIFY. A URL can represent a person. A
SUBSCRIBE method is like a GET that endures, and NOTIFY is the back-channel.
There is also a mechanism for changing the information back at the service. PIP-
DEMO has elements drawn from RVP, GENA and WHODP. It is implemented (by
teams from Microsoft, Lotus/Ubique, Activerse, and Fujitsu so far) and will be demoed
after the session. We got a lot of re-use out of HTTP libraries, and it works with
proxies & gateways.
3. DRAFT REQUIREMENTS -- Sonu Aggarwal, Microsoft
The scope of the requirements is quite narrow: presence information and instant
messages between USERS. The main functionality requirements are
(A) a means for users to determine and be notified of changes in the presence
information of other users, and
(B) a means to deliver small, simple messages instantly to other users.
These requirements are intended to exclude stock tickers, toaster notifications, etc.
except insofar as those can be accommodated by a system designed for people to be
aware of each other and send messages to each other.
Sonu covered administrative requirements, common format of data, quality of service,
accuracy, sender control (access control & spam avoidance), scalability, firewall support.
The common format for presence information must include common contact
information, and user states must include online/offline as well as (if online) available/
busy/idle. The common format must be extensible. Presence information must be
maintainable automatically, meaning that clients that are not contactable by the server
must eventually be marked as offline.
The common format for instant messaging must include a return address and must
support MIME-encoded bodies.
4. DISCUSSION OF REQUIREMENTS
Patrik asked if we were sure that we knew the can of worms we were going to open if
we form a WG on the topic. There are WGs and BOFs on the same topics or related
topics. The Area Directors need to be convinced that you agree on what you want to
do, so that we can be reasonably sure that you will accomplish it.
Mark responded that he thinks this problem is fairly well in-hand. NOTIFY is going
after a broader set of problems, and interoperable buddy lists is a much smaller
problem. Because it is a smaller problem, already implemented by several vendors,
we think this is a solvable problem.
Rohit Khare on behalf of the people concerned with the NOTIFY BOF said that from
the notify perspective, there is a distinct difference in maturity. PIPR is a focused
discussion and domain. There is some commonality under methods like SUBSCRIBE
and NOTIFY.
Ted Hardy, NASA offered to donate 1 years supply of Zantac to chairs, because the
scope is still very large. He added that some huge ratholes still remain such as the
latency requirement which is not currently met by the transport layer. Constant polling
would be a huge scalability problem.
Jonathan Rosenberg, Bell Labs commented that they solved some scalability problems
in SIP by having expirations, but we never addressed the latency problems that you
will have. The granularity of expirations in SIP is much larger than envisioned for
PIP -- a SIP expiration might happen after an hour. Jonathan was also not clear why
instant messaging has to be integrated with a presence protocol.
Mark said that instant messages require a person to be present in order to be delivered.
Lisa pointed out that Harald Alvestrand told us (in the last BOF) to solve instant
messaging as long as we were solving presence information.
John Noerenberg drew attention to another scope problem: Handling all MIME types
is hard to combine with latency requirements. He commented that we have identified
several protocol areas here, which could be distinct but also could be taken on by a
single WG. The WG may be more successful concentrating on presence, Harald's
comments notwithstanding.
Sonu responded that since presence needs to be communicated at the same latency as
instant messaging, they can use the same methods.
There was an attempt to offer alternate language for the latency requirement. Mark
commented that we have tried several different forms but all had problems of one sort
or another. The current latency requirement seems to be the least objectionable of
several possibilities.
Rob Earhart, CMU suggested that the scope should be expanded to allow non-users
to send and receive instant messages.
Mark responded that the intent was to have interoperable buddy lists. To the extent
that the resulting solution allows devices to communicate, that's fine. But we will not
take into account the requirements of systems such as satellite tracking and tons of
notifications. That problem doesn't have to be solved to get interoperable buddy lists,
so we ruled it out.
Rob went on to say that the guarantee of delivery applies really to the user's agent, not
the user.
Sonu responded that there should be some kind of ACK when an instant message has
been presented to the user.
Scott Petrack, Vocaltec, suggested that using the language of "user agent" instead of
"user" might avoid confusion. Scott suggested dividing the effort into three items:
presence description format, application protocol for instant messages, and transport
for presence information. The advantage of the division is that the first (presence
description format) is clearly not being addressed by anyone else, so it would be
helpful if it could proceed even if the others collided with other work in the IETF.
Henning Schulzrinne, Columbia U, commented that we shouldn't limit ourselves to
AOL-like systems, which are a very limited domain. We might find that we need to
solve the "toaster" problem in order to solve the user presence problem. In the
notification space, we do have SIP, which we should avoid replicating, and we have
VCard. These existing technologies should not be re-invented.
Mark responded that it has been difficult to convince the people in MMUSIC that
buddy lists are useful aside from just leading to multi-media sessions, but he agreed
there's no point to reinventing things.
John N was concerned about the focus on firewall traversal; he felt that the document
editors were too concerned about it. John argued that if the service is useful, people
will allow it through their firewalls. Security and usability is always a tradeoff. You
don't want to use lots of ports though. He added that he liked the constraint on latency
because it will drive a lot of other requirements.
Mark responded that it's not clear that any vendors, with their experience implementing
this stuff and working with firewalls, would agree with the analysis of firewalls as
being a non-issue.
5. RETURN TO DISCUSSION OF CHAIRS
Mark called for approval of Dave Marvit and VIjay Saraswat as co-chairs. No
objection was heard and no other candidates came forward. In the absence of
disagreement about chairs on the mailing list, we will go forward with Dave
and Vijay.
Patrik (our AD) stepped up to discuss whether there was support for forming a WG.
First question: How many people in the room see a clear difference between this group
and NOTIFY? About a third of the audience raised their hands. Second question:
How many people think the same thing is being done in both meetings? Only a few
people raised their hands.
Henning commented after these shows of hands that one effort may well turn out to
be a slightly more scoped version of the other; Patrik responded that NOTIFY is
horizontal, PIP is much more vertical.
Lisa commented that as a quiet observer, she has seen a lot of cooperation &
understanding between the two efforts.
The conclusion seemed to be that the community saw a clear distinction between PIPR
and NOTIFY, despite Patrik's concern that they were dealing with the same thing. The
remaining question was whether PIPR should actually go forward with solving its
particular problem
Patrik asked how many people would like to solve the buddy list problem; a majority
was in favor.
Mark declared the BOF session over.
None Received