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. :