IMPP Working Group
December 7, 1998

Chairs: Dave Marvit, Vijay Saraswat
Minutes recorded by Lisa Lippert (with minor modifications by the chairs).
Somebody suggested "Presence Information and Messaging Protocol", but Dave 
said Discussion of the Acronym is not on the Agenda.
Agenda:
- Group Status
- Charter Review
- Presentations
- Vijay Saraswat: TOC
- Jonathan Rosenberg: SIP for PIP
- Jesse Vincent: State of IMPP Consensus
- Open Discussion
- Action Items

Explanation of Pre-Working Group Status
Patrick Faltstrom explained that the WG is approved by the area directors, 
but the charter is not yet approved by the IESG.
Discussion of Charter
Dave stressed that the scope must be narrow in order to finish.
Charter Goals:
- Simple instant messaging
- Presence awareness/notification
- Specify optional extensions for message integrity, encryption, access 
control
Non-Goals:
- A general event notification mechanism
Somebody asked if the Area Directors would allow the security extensions to 
be optional. Patrick clarified that these extensions MUST be within scope, 
but there was no decision on what will be optional. Dave encouraged 
security geeks to participate.
Scope
Presence (format, protocol)
Instant Messaging

Sharing
Some features will probably not be invented from scratch:
- Entity namespace will probably borrow from existing namespaces
- Authentication, message integrity, encryption
- Access Control
- Scalability
- Network Topology

This is not a laboratory protocol.
TOC Presentation
Vijay Saraswat, AT&T

There have been at least three different protocols submitted: WhoDP, RVP, 
and the PIP-Demo protocol. (See URLs off http://www.research.att.com/~vj , 
select Presence Information Protocol.)

TOC is a very specific protocol which has only recently been made public by 
AOL. Vijay intends to convey a particular design which is in use today for 
instant messaging. The design is rather simple.
*** slide too complicated to reproduce here-includes diagram of TOC
***

AOL Instant Messaging, or AIM, uses a binary protocol called "OSCAR".  TOC 
is an ASCII-based protocol gatewayed to OSCAR, and already used by several 
AIM clients.
Go to http://aim.aol.com/tik for a client that speaks this protocol. You 
can now from within EMACS send and receive AOL instant messages (TNT 
client). You can find a file within the download (PROTOCOL), and that is 
what my description is based upon.
TCP connection opened for duration of IM session.  Sign-on: initial 
handshake, then commands are sent from client to server and vice versa.
Sign-on includes: client version, configuration information, nickname 
Instant messages are routed through the AOL server. They appear to be 
buffered for some time. I have no information as to what is going on inside 
the AOL server system.
Question: (Eric Rescorla) Given that there will not be enough information 
to understand the protocol, what is the purpose of this presentation?
Vijay: This should be as much information as was presented on RVP and 
WhoDP-the protocol, not the implementation.
Eric: They are underspecified too.
The only instant messages that arrive are through the connection to the 
server, so there is some certainty of where the message comes from 
(Somebody asked what if the TCP connection is hijacked.)
Question: So why are send-IM, chat whisper and chat send separate kinds of 
messages?
Vijay: They give context, such as what room the message occurs in.
Questioner: This doesn't have to be three different messages.  Vijay: I'm 
merely presenting the protocol, this is the way it's designed.
Question: Can you change state?
Vijay: yes...
Question: This seems to be an ascii only protocol, how do you intend to 
extend it for internationalization?
Vijay: I don't. I don't work for that company, I'm just presenting it.
Question: what does Eviled mean?
Vijay: Any user can "evil" another user. When a person is "evilled" enough, 
their messages don't make it through the server.
Marc Horvitz: Denial of service attack waiting to happen...
SIP for IMP
Jonathan Rosenberg, Bell Laboratories.

SIP is the Session Initiation Protocol, going through IESG last-call. I 
observed when I first got involved with IMP/PIP that a lot of the 
requirements for namespace, etc. were closely related to session initation. 
Presence is the precursor to communication. SIP provides generic features 
which are useful for PIP. A lot of the security issues are addressed 
already by SIP, details already worked out.
One of the things that SIP does really well is handle proxies. If I make a 
message to jdrosen at belllabs.com, this message can make it through all 
the servers on the path to me. Loop detection, etc are already covered in 
the protocol.
SIP provides generic MIME transport service. These are typically session 
description, but this is very similar to instant messages.
SIP has spent a lot of time thinking about feature management for 
extensions. It can use PEP. It has its own mechanism for adding extensions 
(headers, etc). It is text-based. Doing all this work is tedious, SIP has 
done it already. Request pipelining is neat.
SIP has some very specific features useful for presence/instant messaging. 
The "contact" header lists URIs for future communications. It has 
parameters for preferences, home phone, work phone. The SIP register 
message informs the server you're now logged in and available to 
communicate.
SIP identifies the relevant parties. A single request can be sent to 
multiple receivers. This is useful in instant messages, where the target 
may be on any one of a number of client devices, but I want to reach that 
person anyway.
I went through the requirements document, one version of which has a list 
of requirements, to see which were already satisfied by SIP.
*** Insert SIP & Requirements slide ***
Let's not reinvent the wheel. I'd like to emphasize, please look at SIP to 
see how it fits the requirements.
Questions: Can you summarize what the network topology looks like?  Jon: 
Local proxies for sending messages outside the domain... works like email.
Questioner: SO if you want to talk in a chat room, where every message is 
sent to the entire group, would you have to have M by N connections? 
 Jonathan: It would work like a mailing list, with a central server to 
expand the mailing list to names.
Question: Instant messaging is a slightly different thing. Perhaps SIP 
could be used for presence, and chat-room-type stuff by another protocol.
Barry: What is SIP authentication like?
Jonathan: Like HTTP: digest, but there's a specification for PGP which also 
covers encryption. The general framework doesn't mandate public key. I 
don't argue that we have completely solved the security problems.
Parry: This worries me...
Jonathan: Those of you that understand the security, please get involved.
Mark Day: SIP includes a lot of stuff that is not required for IM. Would an 
IM server have to support all of those?
Jonathan : All the routing stuff would be necessary. Some of the fields 
required for session initiation have some mappings for IM. A minimal SIP 
server is indeed minimal. I doubt a minimal IM server/client could be more 
minimal.
Scott Penchak: SIP has an important server-to-server component, which is 
useful.
Jonathan: We started with a wide-universe, multi-server
Pete Resnick: Keith Moore made a big deal about SIP this morning. He said 
it was overused. Was it directed at you? (the application of SIP to IMPP?)
Patrick: I can explain part of this. We're worried about SIP, which solves 
call setup things, being used just because it already includes whether the 
receiver has colour on the fax, that SIP will also be used for a general 
lookup thing, and we ask ourselves if there is not something different we 
need.
Scott: SIP is only a way to transport invitations. What is inside is 
variable and extensible.
Dave: let's proceed
Addition to agenda: Zephyr Presentation
Marc Horowitz, marc@mit.edu
Zephyr has been in use for years. There are two client libraries (one in 
perl), three servers, and 2000 client hosts. It supports instant messages 
(one to one) as well as chat-room type things (one to many). It uses 
Kerberos to authenticate: users exchange keys with the server, logins and 
logouts are secure. There is not encryption, although users have layered 
encryption on top.
Each server stores the entire shebang, so if one goes down it's okay.
Hosts: the Zephyr Host Manager (ZHM) manages the connection between the
client and the server. All other clients on the host send through this...
Zephyr has "realms" or "galaxies". People have done inter-galactic 
messaging in two ways: a ZHM that knows how to talk to multiple sets of 
servers, and the other is a protocol for servers to proxy and pass messages 
to other servers. The first allows the user to configure things himself, 
the second cuts down on long-haul message traffic.
When you first log on, the ZWGC on your host loads your configuration, such 
as what groups you want to subscribe to. The system has no problems dealing 
with this much traffic. The ZWGC sends messages to the server over UDP. 
When somebody sends a message to a tuple, the server finds out who is 
subscribed to that tuple and passes it on. A tuple is <class, instance, 
recipient>. The last two can be wild-cards.
ZWrite is an example of a sending client. The elements of the protocol are 
binary blobs of auth data, timestamps are seconds-passed etc, but these are 
all text-encoded.
Zephyr also does location: the ZWGC registers your location. You can remain 
invisible even though you are subscribed to and receiving messages. Once 
you send a packet, it does have your location in it. A user can make his 
information available and can also register an interest in login events for 
other users.
Everything is in the clear, unless encryption is used.
The format is somewhat inflated by text-representation of binary data.  It 
includes version, UUID, timestamp, authenticator (Kerberos 4, AP-REQ and 
checksum information), class/instance/recipient (what channel you're on, 
referred to as a "tuple"). Opcode (e.g. ping), sender, frag-id, checksum 
(used to authenticate the message itself), and the message itself, which 
includes a human identifier as well as message text.
E.g. message to an individual:  message, personal, marc@athena.mit.edu
Message to a group:   message, help, *
Or in the consult class:  Consult, *, *
There are no exclusions in the server, though you can exclude in the 
client.
A subscription request contains a class, instance and recipient.
Location includes host, time and tty.
Vijay: Does zephyr do anything with firewalls?
Marc: No, there were no firewalls when this was designed. People have to 
poke holes.
Subscription operations include get, set, unset and clear all.
Host manager: boot, attach and detach (when a ZHM first connects or 
disconnects from a server), and flush.
Location operations include login, logout, flush, hide and unhide. E.g.
The server can tell you when your friend logs in.
One day, in a half-an-hour, 1/2 million messages (UDP packets?) were 
delivered by the MIT system.
Eric: Is there reliable delivery?
Marc: Yes, this is pretty complicated, involving multiple ACKs.
Parry: Is the UDP basis inherent in the model?
Marc: No, but until recently, there wasn't a Unix implemenation that could 
handle the number of TCP connection.
Eric: How are long messages handled?
Marc: Client fragments, server delivers, recipient reassembles (server 
knows nothing about fragmentation).
Questioner: Do you think this would scale larger than an university 
community?
Marc: Not as is, the broadcast packets would kill you.
Eric: The limited connection number is a problem with the server, not the 
client?
Marc: Yes, keeping track of state imposes limitations.
Eric: this brings up a universal restriction
There have been people thinking about the scalability of this for a long 
time. E.g. we now believe that the best place to handle location is at the 
user client itself. Then the client can do complicated scripting, access 
control, etc. The server knows where the client is, but it lets the client 
respond to location queries.
Ted Ts'o: It might be interesting to explore the tings that have been done 
with zephyr over the years.
Marc: Zephyr is incredibly lightweight, I used it run it over 1200 baud.

Vijay: have you used it on thin clients?
Marc: I've run it on a palmtop.
Ted: It was designed to run on a VAX

Eric: The limiting factor ?
Marc: the hierarchy is needed to organize subscriptions

State of IMPP Consensus
(Presentation by Jesse Vincent of a talk prepared by Jesse and Mark Day.)
(Jesse has slides which we will try to get up on a website.)
This "consensus" comes from the IMPP mailing list. If you are not on the 
IMPP mailing list, this might not reflect what you think. It represents 
Jesse and Mark's take, though they have spoken directly with many members 
of the mailing list.
The goal of this is to figure out what we don't agree on.
Overview:
- Basic functionality
- Transport
- Scalability and Performance
- Topology Management
- Content
- Namespace & Administration
- Authentication, access control
- Privacy

Basic functionality rough consensus: A user must be able to exchange 
messages, publish presence info and see others presence info.
Unresolved: protocol-level support for instant mailing lists: does it 
require in-band support? Should we prohibit or not prohibit in-band 
support?
Parry: Is this requirements or protocol?
Jesse: Both...

We haven't agreed on transport. IETF prefers not to invent new stuff when 
stuff exists. Candidates for extension include HTTP, either formally or 
informally, SIP and???
Scalability and Performance: It must be fast enough for conversational 
usage. We must scale to the entire internet, not just to a university. 
 (Federation must be loose, not requiring trust relationships between 
domains). Stale presence information is bad; there must be some way of 
dealing with it.
Unresolved in this area: How big is "scalable:"? How fast is fast enough? 
Can you update your presence info only partially? What are objective tests 
that the architecture can pass or fail?
Topology Management consensus: Dealing with firewalls, subscription 
proxying are required. Patrick wants the group to have good consensus on 
these issues.
Unresolved in topology management: Are performance requirements the same 
over proxies and firewalls? What existing infrastructure can we use?
Content consensus: MIME for message payload, extensible format for presence 
information.
Unresolved content issue: XML? RFC822? (for presence information) Does 
Vcard satisfy our presence requirements?
Namespace and administration consensus: Global namespace is required. 
 Entity names must be unique within a given DNS domain. There can be no 
central registry. Each domain must be responsible forits own namespace. 
 Like email.
N&A unresolved: do we need a unique schema identifier? E.g. imp://... What 
about names: should it look like email or like HTTP: or 
protocol://host/user?
Authentication consensus: Some mechanism for establishing identity to local 
server is required. There are existing solutions we can adopt.
Parry: We've got some very unworkable solution you can adopt right away.

Authentication unresolved: Are there feasible non-public-key solutions
for remote auth? Which ...
Access control consensus: Need access control to prevent stalking.
Access control unresolved: How much functionality is required? Should we 
have separate filters for instant messages and for presence information 
protection? Should you be able to lie to certain people?
Privacy consensus: Encryption, reuse of existing work. Encryption must not 
be required in the base spec. A scalable solution may depend on solving 
global authentication first.
Privacy unresolved issues: Which mechanism: TLS? S/MIME? OpenPGP? Shared 
secret? Should presence information be encrypted?
Summary: This is what Mark & I believe to be the state of the mailing list 
consensus.
Open Discussion
We realize we won't reach consensus here. We'll air opinions here, and 
resolve on the mailing list.
Dave Crocker, Brandenberg consulting: Congratulations for taking the 
summary approach to characterize, and present existing work. Classic BOF 
question, should this be done? There's a large attendance here, and AOL has 
done a huge proof of concept. My third reaction: I feel like I'm the 
transmission, and somebody is stepping both on the gas and the brake. A 
good solid long-term solution will be difficult. Transport. HTTP vs.  what? 
Is HTTP well-established for messaging? I was fascinated by the summary of 
consensus. I see a problem waiting to become very big, which is the choice 
of transport. There is a clear need for a presence protocol, and no 
debating that need for functionality. Other requirements such as addressing 
should be met OK. Access control is a big problem throughout the area, and 
there's nothing easy there, but it's high risk anyway. I saw that you need 
some kind of group mechanism.
Dave M: That's not actually part of the charter.
Dave C: That's delightful. As somebody else said, it's really fun to invent 
protocols. It's also expensive and slow. People have no idea how expensive 
it is to implement and deploy. This is why, in addition to good 
engineering, it's really important to reuse. It is very unsexy to make no 
technical changes to a protocol. The belief exists that email is slow, but 
this belief is wrong: it comes from the way email is implemented and 
deployed. There exist deployments where email is instantaneous. Therefore I 
encourage you to focus on the areas where there are no solutions. The 
existing email technology will meet your requirements if it is implemented 
and deployed differently from today.  You might have to run a parallel 
email service, with QOS. This could probably be fielded in 6 months. I'm 
done, thank-you.
Vijay: The area directors specifically said they'd like folks from the 
transport area involved, so participation from them is welcome.
Eric: I think Dave C. made some good points on strategy and tactics.  I've 
seen some misplaced concreteness, asking which security method should be 
used, rather than what the requirements are.
Perry: I wanted to caution, like Eric: If you merely pick a method for 
security, you're bound to pick wrong. People make claims for one system or 
another which actually depend on what you're doing with them. You need to 
put together a security model. Once you know your requirements, then figure 
out what will meet the needs. Second point: I very strongly believe that 
authentication and security are not optional. The security people cannot 
sprinkle the magic security pixie dust to fix things.  Vijay: most people 
on the list understand this.
Perry: This is probably going to become people's bread and butter soon, 
meaning that people will be sending very personal information.  Mark day: 
Clarification: The only piece that was left optional was privacy, and this 
was left optional because none of the existing IM systems offer privacy, 
therefore it is clearly not a requirement. Is it really required for 
everyone?? That's what it means when you put it in the basic spec.
Gordon: It should clearly be possible to send something which is not 
private. (the null encryption)
Perry: I can easily imagine banks wanting to use this, and they would say 
"it would be really neat to give people the opportunity to send instant 
messages..." Once it becomes ubiquitous, people will entrust value to it. 
It's easy to insert at this stage. If you don't spec it as something the 
servers are able to do, it will be much harder later.  Jonathan: This is 
great. A lot of times that security comes in only at the end is often 
because the security guys aren't involved at first.  Derik Atkins, 
Bellcore: We're here, and we're not going away.  Ted: The statement that it 
wasn't implemented means that it must not be a requirement is not good. 
Users expect security even when it is not there. Saying that it is not a 
base requirement scares me.
Vijay: How many people here think that some kind of privacy and securing 
messages in transport is a requirement?
Nearly all hands were raised.
Vijay: OK, this issue is closed.
Questioner: IRC has a reasonable structure, why is there no discussion?
We can at least avoid the problems of IRC. There's a published RFC
Timothy Roscoe, Sprint: It's getting late, I'm going to play devil's 
advocate. There's something missing, and it's billing. Presence information 
is going to be worth money. I haven't heard any mention of the idea that 
there will be organization gathering statistical or demographic data. It's 
different from the individual level of privacy and access control, but it 
needs to be explicit here. Large-scale data-mining will apply to presence.
Vijay: Aggregation clearly has value, but you mentioned billing. Should 
this apply at a granular level?
Timothy: I just wanted to emphasize that presence info has value. I'd point 
out that every system so far except IRC and zephyr is centralized, with one 
organization owning all the data, so the issue hasn't come out yet.
Pete Resnick: Marc's statement that personal information might lie back at 
the client got me thinking. There's a difference between finding out where 
an identifier lies out there on the net, and finding out about that 
identifier. It seems to me we might want to separate the two aspects: what 
address this thing exists at, separately from how to send to it, etc.
Larry Masinter, Xerox PARC: The first three issues are religion. I am 
mostly concerned about security, because I don't think that the currently 
deployed implementations of authorization and authentication are sufficient 
for preventing abuse, and ISPs will turn this off. You need to be able to 
prove that you are not someone (e.g. a stalker) as well as that you are 
someone. We don't have a lot of experience in these specific new issues, so 
don't depend on the transport to do that.
Question: Could some security guy stand up and give the state of the art?
Perry: The problem is that it depends on what your problem is.
Marc H: Transport: There's one very fundamental difference between email 
and messaging, and it is "push" vs. "pull". Right now email is always pull, 
your client asks for it. With instant messaging, you don't have to ask. So 
I think that email formats are probably ok, but the actual protocols have 
an assumption of user.
Perry: The email model, not for presence but for IM, has some good 
properties. You find the address, this model scales nicely and well.
There is no problem with stealing as much of the SMTP solution as we
can, not necessarily everything
Frank Dawson: I'm kind of interested in the content, in particular the use 
of extending VCard for presence information. It's very extensible.  There's 
been work in the OOPS committee of capturing presence information. So I'd 
be interested, offline, in carrying on a dialogue about how we might do 
this with VCard.
Scott Penchak: There are two problems. One seems to be finding the person, 
one seemst o be messaging, one seems to be finding presence. SIP might be 
good for some of these. If we agree these three things are truly 
orthogonal. We could easily get consensus on whether these are separate 
problems. This would also allow us to use them separately.  Vijay: We've 
already discussed two-way bifurcation.  Jonathan: there has already been 
discussion of partitioning. Presence consists of a number of components:
- subscription; I'm interested in finding more about another user.
- What is it that you're subscribing to; subscription format.
- Notification: whoever handles notifications sends them to subscribers.
- Presence format: hidden in the notification part.
Scott: Subscription/notification always go together? Then they're one 
component.
Jonathan: No, you could subscribe one way, specifying how you want to 
receive notification, and notification could be done another way.
Rohit: Push/pull, subscriber/source, all these terms are outlined in a
draft entitled scenarios for event notification service
Jonathan (continue list
- Access control: how user specifies control
- Publication: how does the user tell the server they are now 
online/available. Could be a registration method, or could be a radius-type 
thing.
Windup
Dave M: This is our third meeting, I think we got a lot of things wound up. 
Please stay involved in this effort, please participate in the mailing 
list, which is where a lot of the key discussions are going on.
More Discussion
The discussion continued in a semi-formal manner...
Perry discussed security
Perry: We should be talking about high-level requirements now.
Larry: There's a common set of threats.
Perry: Once you know there is a certain expectation of privacy, you can 
figure out how to break that.
Larry: What threats are unique to the presence/IM domain, and not 
applicable to email- Stalking is a problem in chat, and even more so in IM.
Jesse: Once they know you're online at home, they can come to your home.
Larry: It's a short list. Privacy, anonymity, avoidance of spoofing... 
Perry: Let's go through systematically.
Subscription
Notification
Publication
Subscription Access Control: the person specifies "I don't want Joe to know 
when I'm logged in".
Subscription
Ted: There is a confusion between registering to receive messages and 
registering to publish presence information. Directed at the instant 
messaging piece: There is one way IM can be different from email, as far as 
the services it provides. Some systems will tell you that somebody went 
offline, as you are typing to them. Some systems tell you when the message 
is received.
Jonathan: If you want to find out if the user is not online, you switch to 
the presence protocol.
Bill Sommerfeld : If you look from the privacy perspective, there's a 
difference between checking to see if they're there and trying to send a 
message to them.
Perry: If you get notification that it was not received, it tells you 
they're not there.
Derik: They could be online but not acknowledging receiving messages. 
 Marc: There is a difference between making presence information available 
to the server, and making presence information available to other users. My 
reading of notification is that you were talking about system push rather 
than user pull. With Zephyr, you can set things up so that when I login you 
get told. I can also set things up so that when I log in you are not told, 
but if you explicitly ask you are told if I am logged in.
Jonathan: We need a picture.
There is a user (publisher, subscribee), a server, and a number of 
subscribers, including "friend". Publication occurs when the user sends the 
server their location information. Notification is when the server sends  
 the "friend" the location information for "user" (Alternatively, user can 
fetch). Subscribe is when the friend lets the server know that they are 
interested in particular information on an ongoing basis.  Access control 
is when the user sends information to the server on what they want to 
allow.
Derik: If you expand your view to chat rooms, you enter the room by 
subscribing, you send a message by publishing, you receive a message in the 
room as a notification, and the access control also happens. (The only 
difference is the "fetch" doesn't exist in chat rooms.) There needs to be 
an ACL for publishing, notifications, subscriptions and for access control 
itself.
Bill: I point out that if you take the model that the presence information 
stays at the user's end point, and the server in the middle merely relay 
presence information, then the instant messaging and presence models merge 
even more.
Perry: The question of whether somebody is there becomes a kind of instant 
message, and the presence information response is another kind of instant 
message in reply to the first.
Some confusion over what a centralized server is.
Mark Day: To me, we're talking about interoperability. We can't afford to 
be agnostic about whether there is a server or not, because of the existing 
implementations.
Bill: Meta-comment about agnosticism: Security people worry because
security models become less well-defined
Vijay: The bottom line is we're living in a real world, there's a lot of 
stuff implemented. The stuff we're coming up with out of thin air do not 
exist.
Mark: To clarify, I realize why what I said sounded inflammatory. I'm not 
talking about just defining interoperability among the existing crufty 
implementations. There's been a lot of discussion on the ML, and we can't 
afford not to be agnostic about whether or not there is a server.
Ted: If we need interoperability with old stuff, keep in mind it has no 
security. We can design a clean protocol from scratch and then design 
gateway systems, or we can make the limitations of the cruft a fundamental 
limitation of the protocol. The other comment: If there is no technical 
difference whether we have a server or not, it still makes a fundamental 
difference to how we design the protocol.
Mark: we're designing a new protocol.
Perry: I'd to talk about user security expectations and write them down. 
 Let's start with presence. When I am subscribing, when I am specifying 
that I want to know when Mark logs on, what are my expectations- Who gets 
to legitimately know-
(Perry: where's a transparency I can write this down on-)
(Gordon: Just use the back of the existing one...)
Vijay: People want to know that the person they are subscribing to is 
really them.
Bill: This is unsolvable.
Perry: Let me tell a small story. Most organizations will find name 
duplicates. At the Usenix conference three months ago, there were two 
people with the same name.
Ted: Given that you have a handle, it is easy to solve the problem "is the 
person logging into this handle the person who's supposed to". It's also 
easy to find out "is this the same person I talked to last week".  It's 
hard to find out "Is this scott adams, creator of Dilbert": the real-world 
mapping is difficult.
Someone: May I suggest that visibility of subscription information be 
governed by access control-
Perry: If we really put access control on everything, this might get out of 
control.
Jonathan: My expectation is that the server is responsible for handling 
subscriptions, so that the user does not know who is subscribed to them. 
 As part of the subscription mechanism, I do not see it as a requirement 
that the subscribee know.
Rough consensus was arrived on whether the subscribee should be able to 
find out the list of subscribers to their information.
Mark: User studies made it very clear that users want to turn it off; users 
want to know how to find out who was watching them. It is a real user 
expectation.
Bill: I might have a system in which I try to subscribe to information 
without revealing who I am. The other party may block that, in which case 
the anonymous requestor could choose to stop there.  Mark: It is reasonable 
to allow that kind of mechanism, but I think you'll find that if users want 
to allow lurking, people don't want the default behaviour to be that people 
can watch you without you knowing that, and you have to put something in 
place to stop it. They want the default to be that they know who is 
subscribing.
Rough consensus was arrived on whether third parties can find out that a 
subscription exists: third parties should not know about the subscription 
request.
Derek: is it reasonable to have a multi-step protocol such that both 
parties can remain anonymous.
Lisa: I don't understand how the target of a subscription can remain
anonymous...
Bill: Is it a reasonable requirement to maximally protect the privacy of 
both parties by allowing the requestor of information to remain anonymous, 
at the risk of being denied due to being anonymous- The system would allow 
the target to control whether or not somebody can look for them 
anonymously.
Perry: You tell the phone company, "I don't want to accept anonymous 
calls". When somebody calls with caller-id blocking, they hear "This user 
blocks anonymous calls". You have to type *whatever to undo caller-id 
blocking..
Bill: The analogy is actually with phone directory lookup.
Marc: This issue is being able to control who is looking for you.
Speaker X: If you have a set of people who want to know where you are, you 
could encrypt your information with the public keys of the people you 
trust.
Perry: I want to finish Bills idea... as interesting as it is, it might be 
more than we actually want.
Marc: Can we just defer this-
Dave M: Users expect that their presence information is not arbitrarily 
republished (forwarded on).
Perry: Note in the minutes that it is unreasonable.
Dave M: Unreasonable expectations must be managed nonetheless.
Vijay: If I subscribe, and my subscription is not honoured, I should be 
told that.
Perry: Do we honour the expectation of the publisher or the stalker- 
 Jonathan: I think it is a principle that the privacy interests that are 
paramount in the system are the privacy interests of the publisher, not the 
subscriber.
Bill: The phrasing I like is, if there is a conflict between the privacy 
interests of the friend/stalker and the interests of the user, decide in 
favour of the user.
There was weak consensus on Bill's statement.
Objectoin from Eric from Nortel: If a subscriber is trying to contact the 
bank using instant messaging, e.g. a customer care center, the subscriber 
should be able to remain anonymous.
Dave M: Classic example is the AIDS hotline.
Perry: The principle still seems to be valuable.
Jesse: You could grant 'right of refusal'..
Perry: We may have to re-evaluate the principle that the publishing user's 
expectation of privacy is paramount. This makes a lot of sense for 
marketing too.
Notification
---: Notification receivers expect truthfulness, accuracy of information.
Mark: The truth, the whole truth, and nothing but the truth... You expect 
to get no lies, to get all the notifications generated, and to get no 
notifications that weren't generated.
Perry: Information on subscriptions remains private: people cannot find out 
that my subscription exists by watching notifications occur.
Applause occurred for the excellent note-taker due to an interaction not
recorded here
Speaker Y: You only get notification for things you're subscribed to. 
 Derik: An operator might decide that people must or cannot subscribe to 
particular things.
Jesse: If we don't solve this now, we have to for instant messaging.
Jeff: Goodnight, I've got to go now.
Erick from Nortel: If I get a notification, I should know that that 
notification comes from who I thought I subscribed to.
Perry: There might even be a way to tell the difference between a message 
generated by the user, and a message legitimately generated by the server 
on behalf of the user; by the user encrypting something with their private 
key.
Lisa: there are many situations where servers might act legitimately on 
behalf of the user, even for users not logged in.
Bill: There's a distinction between Bill saying he's not here, and the 
server saying Bills not here.
Brian: I would hesitate to mandate this agent-type functionality on the 
server.
Mark: Nobody has to convince me that we must allow users to selectively 
disseminate information., but there is still an expectation for truth. 
 Bill: If you phrase the statements in terms of the user says the server 
speaks for me, and the server says I'm there, then that's truthful even if 
the user has fallen off the face of the earth.
Perry: We can relay accurate information on how timely something is, but we 
cannot prevent somebody from delaying information in all cases.  Ted: The 
notification should include an event-time, a timestamp for when the event 
happened.
Vijay: what about timezones-
Everybody: Rathole.
Derek: Publication has two parts; the user telling the system that they're 
there; and the system telling other people.  Vijay Why is there a server in 
this context- We shouldn't be talking about the server in "expectations".
Marc: If there is a server, the server does things on behalf of.  Mark: The 
simplification of collapsing publishing and notifications together is 
tempting, but they can actually be separate. You might have different 
expectations when you send information out (publish/notify) than when you 
make it available (publish/fetch).
Lisa: Let's separate publication via notification vs. publication via
fetch
Brian: As a user, I would expect that even system administrators do not 
know that I'm there when I do not want them to.
DaveM: If you subscribe to me, and later I decide I hate you, I should be 
able to now block the subscription.
Marcus: This is dividing the "marcus" class into many variations, such as 
Marcus at home, marcus on the road.
Mark: I really think that's not what we're talking about here. I don't 
think we're talking about message classes.
Vijay; Is this business of lying, where I want to present information 
differently to different people, how would that even show up.  Marc: 
Distinguish between lies of omission and lies of commission.  Mark: People 
do want to provide different information to different people, and they do 
not call it lying.
Perry: We are building the virtual telepathy mechanism. We really do have 
to worry about all these things because the system will be so widely used.
Ted: A functional, scoping issue: what does notification mean- Is it just 
simply "I'm here"- Or does it carry arbitrary amounts of information- 
Zephyr had ZAway, where you could send a message, the agent could 
auto-reply on a per-user basis with different messages for different users.
Lisa: We've discussed this before, and it may not be a huge protocol issue: 
clients can be responsible for their own information, without worrying 
about "selective dissemination of information" in the protocol.
Derek: Sure, but we've got to record expectations.
Vijay: Expressability in the model: If we have the distinction of one event 
from user-to-server, then a fan-out from there, we can then ask whether the 
server is lying.
Dave: IMPP stands for Instant Messaging, Presence and Prevarication.
Brian: In response to lying: auditability. As long as the receiver can 
prove that he was sent information by the sender, even if the sender was 
lying, action can be taken later on.
We recapped and stopped due to the late hour. Lisa will publish the list of 
security expectations in a few days to the mailing list, and discussion 
will continue there.


: