IMPP Working Group Meeting 44th IETF meeting Chaired by: Dave Marvit and Vijay Saraswat Notes taken by: Lisa Lippert Agenda presented by Dave Marvit, Fujitsu. Assuming nobody objects, the agenda will be: Discussion of charter changes. (IESG has approved our WG status with some changes to the charter.) Intellectual property issues. (Patrik will present some IP policy issues to the group.) Discussion of Security Expectations. (This will be a follow-up to discussions on the mailing list.) Draft IMPP Model. (mark will discuss a model for thinking about IMPP and a set of terminology, on the assumption that - if we all speak the same language, there will be no discord. Call it "The Esperanto principle". Contentious issues. (Vijay will lead a discussion of contentious issues as a way of ferreting out where the disagreements are.) Seeing no objections... Charter Changes (Dave Marvit) The charter was changed because of IESG concerns that the scope was not narrowly-enough defined. By forcing the group to work strictly on a design document the focus can be maintained. This focus is required to develop a sound protocol. Since there is an expectation that IMPP wil be widely used it is important that this WG does a good job. So...the WG will work first on a requirements document, then, when the requirements / design document is approved, the charter will be extended. Intellectual Property (Patrick F„ltstr÷m) Patrick explained the IETF policy towards intellectual policy. Individuals that participate in the IETF and are aware of patent actions or patents pending which might impinge on a WG's work, then the individual should report their awareness to the WG chair or refrain from participating. Details need not be provided. That said, an RFC may discuss things that are patented or protected. For example, the patent holder may license a technology royalty-free for use with the RFC. Discussion of Security Expectations (Vijay Saraswat, AT&T) Vijay explained that the security expectations document contained somewhat naive expectations that unsophisticated users may have. Some of these expectations may be in conflict. Even so, we need to be aware of those expectations. Discussion of security expectations of A & B when A subscribes to B Patrick asked for clarification of A3 (anonymous subscriptions). Is it required to be an atomic operation? Jonathan Rosenberg: If A expects that it can subscribe to B anonymously, and B expects that it can know that A subscribed to it, these expectations conflict. Questioner: Is the anonymity requirement satisfied if A can get a one-time ID and use that? Vijay: The problem is you must be able to receive and send for a while using that temporary ID. Patrick: How can A have any guarantee that its anonymity will be preserved unless it is accessing B through a proxy which serves A's purposes? If B runs the proxy, it can't assure A's anonymity. Vijay: That would work. Clarification that right now we're not designing solutions for meeting the expectations, we're just listing reasonable expectations. Chris Apple: A2 is a very reasonable expectation (that a third party won't know about other people's subscriptions). John Stracke: Even though B may not know that A is subscribed to it, it may have statistics (know that n people are subscribed) Larry Masinter: In the area of reasonableness: expectations may not be implementable as described. Some may need to be reshaped in order to be reasonable, and that analysis can be very valuable. Jonathan R: These don't have to be reasonable. Italy: pointed out that A5 conflicted with B6. Vijay: True. Jesse: We need to add more expectations to the subscription scenario, such as: "C, an authorized administrator, expects that C can cancel subscriptions to C's server, create subscriptions, etc.". But we should bring this up on the list and work on it on the list. Jonathan: Time-based restrictions will be desired: My boss can subscribe to me between 8:00 and 5:00 only. Christopher Burke: Add the expectation that both A and B expect that the subscription has some temporal limits. Unknown: If B can deny a subscription without telling A, then can B accept a subscription without telling A?. John Stracke: A will know that it has been denied if it is not getting notifications Vijay: But does A know reliably if it is getting all events or just some or fake events? Italy: Is there an expectation that instant messages be delivered in order? Jay: If there is an expectation that the IP address not be revealed, does that correspond to my workstation? My server? Christopher Burke: Do the expectations restrict people from sharing location information with consent? Vijay: We haven't systematically discussed that. Keith Moore: Why is this not a general facility for notifying authorized subscribers to particular kinds of events? It's useful to talk about net presence and it's useful to talk about physical presence. I can't imagine that we would want to restrict it a priori to particular kinds of events. Vijay: This has come up many times - whether we want a general solution or a particular solution. Keith: You've got subscribers and the thing being monitored. I'm not suggesting that SMB be used, but it's very similar - you subscribe to the thing you want to know about, whatever that is. Why not be able to monitor for other kinds of events. Mark Day: I would like to use this to segue to the model discussion to see if we can accommodate your request. Keith: I want Patrick to know, for example, when I'm in the same airport as him, but I don't want Yaron to know. Marc H: The target of a subscription doesn't find out anything about the subscriber, except the name of A, unless A is anonymous. Jesse: I believe the user belief was: B will not know anything about A that hasn't intended to be revealed. Timothy Roscoe (Sprint): If you want to be able to restrict information, to tell people different things, it's more of a kind of pairwise relationship between people. If A wants to know where I am, tell them. If Z wants to know, don't tell them. Vijay: Yes, B may be manipulating multiple presences that A and others may be subscribed to in different ways. Timothy Roscoe: Will people be able to tell the difference between those two presences? Josh: Whatever I say is my presence, is accurate. Timothy R: I agree there are attributes that have different values for different people. Jonathan: I want to repeat, I feel strongly that IP addresses should be discoverable if users wish to reveal them. We can't prevent that. Various: OK, you're right, that's not the intention. Draft IMPP Model Mark Day presented (Lotus) Slides were presented very quickly, that cover the draft which is the model document. Clarification of Presentity: A presentity is not necessarily a person, it could be a process. Larry Masinter: This model seems tied to an implementation. The model with the relationship between the roles seems to include a system model. Sam: Why does a watcher request for information from a presentity rather than a principal? Mark: The principal is a person. The presentity is a piece of software that has the principals presence information. Timothy Roscoe: That doesn't allow for different people to have different views of a principal's information. Timothy R: Are you exposing a fair amount of information that the principal doesn't want to expose -that the principal has multiple presentities?. Josh: You think you're subscribing to a principal, but unbeknownst to you, you're subscribing to a particular presentity of the principal. Timothy R.: The watcher might not know the particular presentity they are actually subscribing to. Derek Atkins, TelCordia: How do you name a presentity? Unless it is an abstract concept, it is just a view of a principal. Mark: No, it's a model, not a view. Gordon: Nobody really sends me, Gordon Mohr, an email. They send it to my mailbox. So the presentity is like a mailbox. You don't know if I have several mailboxes, similarly you don't know Marc: Why does the principal appear in the model then? Mark Day: It's useful to talk about principals. Josh: What Gordon said is not right. The sender knows the name of the mailbox. If you notice that another mailer has a different name for a principal, you know it corresponds to another mailbox. A principal's presentities have the same address. Gordon: You think there are two presentities behind the same address. That could be true. Jesse: I happen to know this is a circular definition. I propose: An instant message is a notification sent from one IM entity to another IM entity. Mark: Well, a receiving IM entity is an "instant inbox". Derek: We can combine watcher/subscriber with receiver/sender of IMs Mark Day: We don't want to do that now. Sam: I understand that an instant message can go to a named group of people, and that's not covered in this definition. Mark Day: We'll get to this later. Jonathan: Should the instant inbox address be defined as: "If present, indicates where the presentity's principal can receive..." Response: Not necessarily. It could also say just "be back in five minutes". Jonathan: Presence is two things: status and how people can communicate with me. Mark: The goal is that the two of those things together, the status and the instant inbox address, are enough to tell how to get in touch with me and whether. Unknown: If I have an IM address, how long is it valid for? Mark Day: I dont' know. Larry: I understand this model might help focus the group, but tweaking it carefully isn't part of our charter, the requirements document is. Mark Day: The other reason to go through this is to see if people will say that they have an IM system that is nothing like this. Larry: I have an IM system that is nothing like this. Mark Day: Well, please describe it. Pete Resnick: While status and inbox address are sufficient to determine whether the principal is ready to receive an instant message, they are not necessary. Gordon: The regular case for applications out there is that presence information and IM go hand in hand. If you're online, you can receive IM's. I think that you can have presentities that advertise information but never send or receive IM's. I think you can also have instant inboxes that send and receive IM's but do not publish any kind of status information. Appendix A: Contentious Issues Vijay Saraswat, AT&T The main purpose is to catalogue contentious issues, to get them on the list, or if we're really lucky, to remove them from the list. This is a starter list. We are not trying to resolve these contentious issues here and now. Jesse: Name-space management is also domains. Vijay: We are running into model problems, no doubt about it. Imagine a space with subscribers and people who are providing presence services (which manage status information). Are we committing that there be presence services that have to be part of this? That is an issue that is addressed by the first point, which asks if each user can manage their own presence service or namespace. Timothy R: This WG doesn't need to deal with that. It doesn't matter whether the user is running it themselves or on some server. Keith Moore: I would rephrase this question. If you want to run a namespace for a set of 1 or more individuals, what are the requirements for being able to do that? I would imagine that the requirements might be full-time net presence. That doesn't prevent an individual from running their own net presence server, but it does raise a barrier -- much like web service, you can do it if you have the hardware, or you can find a hosting service to do it for you. Larry: Really, you need connectivity that is as good as that of the subscribers. The presence/messaging system that I thought ought to be comprehended is finger+talk, and muds. These both have a history of what subscribers want and do and also a source of requirements that come from the dissatisfaction. Vijay: That's a push/pull issue. Is presence information subscribed to or just published? Larry: Well, you can always take published information and have a third party poll then push. Pete Resnick: May I suggest that whether users can run their own namespaces is non-contentious. Jonathan What I thought you were talking about is that there are people who provide presence services, and there are namespaces, and a PS has a NS, mapped thorugh some kind of DNS. Is it possible for me to own namespaces and delegate? Is that what the contentious issue is? Keith Moore: I can't imagine that this group is going to create its own namespace. If you're not going to piggyback on something like DNS and maybe extend it, I want to know how you're going to do it. Mark Day: That's not the issue. The contention is whether we will use email addresses or web addresses, or whatever. The piece of DNS is a non-contentious issue. Sam: Deciding to fully use DNS is not as simple as we think it is. IRC channels are ephemeral. Do we really want to have a chunk of DNS space that's modified that often by end users. Ted T'so: People seem to have different ideas what are the requirements of the namespace, and what you do with the namespace. People from ICQ and Zephyr may have different assumptions about what a namespace is. Gordon: Is it contentious that we need push model? Jesse: We know we need push. Do we need pull? Larry M: I don't think the WG should discuss whether to do push/pull. Keith Moore: We tend to jump to implementation, but there is usually an underlying issue we have in mind. Larry: Good. So translate "push/pull" to a set of requirements on latency, etc. Gordon: Request for clarification: It seems the charter, amended as it is, says that some broad outline of how things will be done, needs to be in the document. Is that true? Keith: There was worry that aspects of security would not be as carefully regarded. The goal is to get the requirements on paper and agree. [discussion of contentious push/pull issues captured in that doc] Larry: The concerns of latency, bandwidth - those constraints are so bad that one implementation will dominate. The choice of push/pull cannot be made across all conditions. There may be situations where polling is desirable. Work on the requirements outside of the design, then you can evaluate for a particular network. Timothy R: I agree with Larry, this implies that one of the goals should be to say something about denial of service attacks. Vijay: We should not assume that these are always used under conditions of full connectivity. People with pagers and phones might have very different conditions. Marc: Can you define instant for me? Jesse: We're talking about whether you must poll another server for other people's instant messages, and that's ludicrous. Derek: In order to be able to receive instant message, you must have an agent that is fully connected and able to receive pushes. John Klensin: It's clear to me, as a person who might have to review a charter, that this group does not know what they are talking about. The authors and chairs might want to take ten minutes to find out what we mean by instant, and message, and push, and pull. Vijay: I think I will go ahead with other issues and cover this on the ML. John K: MLs are notoriously bad at clarifying terminology. Derek: Another question of contention is that of anonymity or pseudonymity. Mark Day: I want to reinforce Johns point, maybe we want to take this offline. C= contentious NC= Non-contentious Namespaces Contentious issues: How email addresses are mapped. What namespace syntax is. Whether namespaces are hierarchical. Non-contentious: Use of DNS is not contentions. We will ride on top of DNS somehow. NC: Users can manage their own namespaces (a service can have only one user). Privacy, Security, Authentication C: whether the system will support selective lying. What we think presence means. C: ACLs C: public key? C: shared secrets C: Anonymity/pseudonymity Push/pull C: Liveness, length of TCP connection C: presence must be pretty live - what does live mean.. C: The presence service must not operate in a pull-only mode. NC: IM is clearly push. C: Presence might be pull as well as push. Transport C: Use of TCP, UDP, unicast, multicast. At this point, participants were encouraged to continue their contributions on the mailing list, and thanked for their hearty participation. The meeting was adjourned. some die-hards chose to remain and continue the discussion informally.