[AI] All: please read Peter’s authN/z e-mail to the list so it can be discussed next call.

I2IM Conference Call March 5th, 2004

*Attendees*

*Discussion*

Klaas sent notes with questions regarding Brendan’s pseudonymous cases to the list. When do you have a persistent session? The only distinction between a persistent session and a one time session is the length of it. Do we want to make this distinction? When are receiving a message and sending a message close enough to each other in time to call it a session?

Brendan noted that for persistency there is the idea that the target of an initial session might be the initiator of subsequent session with the original initiator at some later point in time. Without a persistent identifier how are you going to re-contact them? It seems like you would never know when the session ends. The session becomes an infinitely long thing.

Is it necessary/helpful to track the session to know that it’s gone away? A persistent session identifier over a reasonable amount of time can be convenient if what you’re doing is trying to have federated discussions and you don’t want to keep re-authenticating. Use of the term session isn’t critical, it could be described another way.

There are a couple of cases where persistence could be important. 1. If a student contacts a professor and the professor later needs to contact the student to correct information previously provided. 2. Or if a conversation is in process and interrupted, for example by a power failure, being able to reestablish the conversation. Cases 5 and 6 have to do with the ability to bridge between what's been referred to as sessions. The question may be more: How long do you preserve that information, a day, a month, or years? What are the policies for maintaining state, user versus system dictated? Do some states live longer than others? Under what circumstances?

Michael indicated that it needs to be clear in the cases that the student is an authenticated entity known to be a member of the professor’s class. Since cases 5 and 6 utilize the assumption from case 1 that usage should be made clear as well.

Steve suggested that one possibility is to create a set of somewhat persistent identifiers that could be allocated only once in a given situation. A person could be assigned student36 for physics 101 and once it’s assigned to them no one else could be student36 for physics 101.

There was discussion that the cases should provide context from a functional requirements perspective. For example, defining the context in which the student would use student36 without specifying how it would be implemented. The professor might be able to designate a proxy or "call forwarding", such as the class TA. Student36 might be used to communicate with the lab, the TA, and the professor for the class. This might also be used in the commercial world for customer service where a customer wants to be anonymous in discussing a trouble ticket. More discussion of how and when persistency applies in the cases would be useful.

Spring Member meeting:
The working group chairs are discussing the agenda for the Real Time Communications summit. It should be finalized in the next week or so and details distributed.