IMPP Working Group Meeting
44th IETF meeting

Chaired by:
Dave Marvit <dave@marvit.org> and Vijay Saraswat <vj@research.att.com>
Notes taken by:
 Lisa Lippert <lisal@microsoft.com>

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.