Subject: [Simple] notes from the SIMPLE components adhoc at IETF53

From: Robert Sparks <[email-masked]>
Date: 03 Apr 2002 10:34:42 -0600

Thanks to Mary Barnes for taking these notes:
-------------------------------------------------
   
SIMPLE WG adhoc meeting 

Meeting was led by Jonathan Rosenberg with SIMPLE (Robert Sparks) and SIPPING (Rohan Mahy) WG chairs moderating the discussion for the items affecting their WGs.

Notetaker: Mary Barnes

Attendees:
Avshalom Houri [email-masked]
Sriram Parameswar [email-masked]
Sean Olson [email-masked]
Tony Hansen [email-masked]
Andy Zmolek [email-masked]
Cullen Jennings [email-masked]
Robert Sparks [email-masked]
Jonathan Rosenberg [email-masked]
Mary Barnes [email-masked]
Adam Roach [email-masked]
Ben Campbell [email-masked]
Mikko Lannfors [email-masked]
Markus Isomaki [email-masked]
Kristian Kiss [email-masked]
Mark beckmann [email-masked]
Georg mayer [email-masked]
Paul Kyzivat [email-masked]
Wolfgang Beck [email-masked]
Mark Day [email-masked]
Hirogasu Sugano [email-masked]
Keith Drage [email-masked]
Dean Willis [email-masked]
James Undery [email-masked]
Rohan Mahy [email-masked]
Jon Peterson [email-masked]
Miguel Garcia [email-masked]
Sonia Garapaty [email-masked]
Jayshree bharatia [email-masked]
Pekka pessi [email-masked]
Miguel A. Garcia [email-masked]

The purpose of the meeting was to work through the list of new work items that had been discussed during the main SIMPLE WG session on Wednesday (1530-1730) including a list  of 7 work items for SIMPLE WG, several work items proposed for SIPPING WG and 4 work items whose "home" needed to be determined. 

SIMPLE Work items:   
o Adopt a buddylist package as a work item
o Fairly well scoped. Package or Template package?
o Subscribe to list rather than members.
o Nothing to do with list manipulation. 
 
o Adopt development of a solution for is-typing:
o What is it?
* Is this related to key events in SIPPING 
* Presence data field format, BUT there's a correlation issue. 
*  Needs to be scoped to IM.  IN the middle of message, it's another stream.
* Dialog associated? 

Discussion: 
* It's a session associated with presence
* Mark: getting semantics confused with transport.
* Ben: disagree that it's presence since it's associated with a conversation. Could do that with "brainless" filtering.
* Rohan: It shouldn't be keypress thing.
* Adam: Frequency with which they occur, even if it's presence Sub/Not would not be appropriate.
* Mark: At higher aspect, it's presence. 
* Jon P: We should have concept of presence towards an individual.  So, discounting this because it's a session. 
* Dean: It's "scoped" presence.
* Ben: Is this just for sessions? Or is it for paging in general? 
* Tony: Getting into solving the problem, thus discussion out of scope.
* Jonathan: trying to see if there is acknowledgement to tackle this one.
* Robert: Agreement that there is a requirement to solve this one.
* Rohan: list possibilities and work offline.
* Sean: Would like to scope it as availability and not just UI indication. 
* Keith: Only need to go into details if you think it might impact another WG. 
* Jonathan: If it can't be done with Sub/not, then there's a problem.
* Andrew: Plenty of examples where it is not a good idea for sub/not, but in general might want something else...hierarchy that does use sub/not.
* Avshalom: It's more of a type of session, must be coordinated.
* Ben: Objection to presence isn't an objection to sub/not.

Conclusion (as stated by Dean): agreement on "is preparing". Agreement that this is a session scoped activity. 

o Adopt development of a set of IM statuses for PIDF
o PIDF is supposed to be extensible.
o If you want a semantic, need to broaden set.

Discussion: 
* Sriram: 3GPP went crazy with this.  Agreed OPEN/CLOSE because it was the only 2 for which they could get agreement.
* Ben: same question came up in IMPP, so there may be a Q wrt WG.
* Jonathan: thinks it's okay to have this in SIMPLE since it's actively working.
* Miguel: Related to status of user at a particular time: Auth pending. 
* Jonathan: Yahoo for a while used such a state.  Not unreasonable.  It's complicated due to the scope of these things. Could be potentially unbound.  Doesn't mean you should do nothing.  Do we want a list of values that meet capabilities of existing deployed systems?  Do you need something more wireless specific. 
* Rohan: Time domain of "how closed are you?" granularity would be useful.
* Tony: These are all substates of open and closed.
* Adam: Defining beyond open/closed if you don't have specific semantics is problematic.  Need specific semantics for substates.  Leave reasons freeform.
* Ben: Agrees with Adam.  Perhaps a note - useful for a human.  Minimalist as possible for automata, otherwise infinite possibilities.
* Paul K: subordinate status is peered to contact.  But, status may apply to only one contact.
* Cullen: It's not open/closed; it's probabilistic. There will be lots of uncertainty.
* Jonathan: given that English phrase is not important; What are the semantics? 
* Mark: don't see this as a SIMPLE problem.  This is a home versus office status defining activity.  Not clear that you would manage to get consensus within SIMPLE on any given set of profiles.  Want a framework. 
* Rohan: Disagreeing with Ben's previous comment.  English phrases are useful.  These will need to be localized.  Need to be able to apply semantic meaning. 
* Ben: Addressing Mark's comment. Think we're in danger of trying to do way too much.  This should be left to service. Define minimal set for interop; more than we have now. 
* Sriram: Even if you set busy, you are closed.  Think Open/closed are only 2 interoperable cases.  Then have English phrases for others.
* Dean: 2 ways. 1. Semantic web model. 2. Leave it completely open. What is availability is presence which is dynamically updated. Really need basic minimum set with extension mechanism.
* Mark: Already did some of this in another draft (??) Open/ close were roots of XML trees.  Other messaging systems elaborate those.
* Jon P: Want to be able to build a real system.  Obligation should be to build states to go beyond IM service. John would like telephony services.  Suggests scope is IM at this time; thinks this should be beyond OPEN and Closed. 
* Avashalm:  Need a schema that can be "negotiated" between different systems.
* Sean: Haven't heard anything yet that don't boil down to Open and closed.  For interop, that's it. 
* Jonathan: Textual stuff works great until you realize consumer of presence may be automata (onhook/offhook versus open/closed).  Are there a  set of things for semantic understanding?
* Andrew: Automatic sensing.  Don't want to preclude giving different answers based on policy.  
* Ben: Process comment... aren't converging. 
* Jonathan: Is this a work item?   
* Rohan: Onhook/offhook - like tree idea.  
* Jon P: Want things like offline and idle - beyond open/close.
* Tony: Need some way of specifying substates.  Why are we doing this?  Filling in gaps so that folks building services know how to to this. Need to document ...
* Miguel: What are the requirements for this aspect?  Need to standardize semantic of substates.  Don't think this is the problem. Systems today solve this problem. Need to write down requirements. 
* James U: need a method to group open and closed.  Phone may be offhook, but message window may be open.  Presence in messaging appl needs to accurately reflect the combined states. 
* Adam: was arguing for a discrete number of states. 
* Jonathan: Is there a deliverable here?
* Mark: arguing against using Note to convey semantics.  Right question is that you need to trust that you're going to get from IMPP the capability for statuses, how are you going to use the toolkit?

Jonathan restating objective:
* Deliver an IM and presence system which is consumer grade buddylist app which mirrors existing systems.

Discussion:
* Sriram: at the beginning was trying to not combine IM and presence.
* Jonathan: trying to determine what to do when. 

An attempt by Robert to summarize "Agreement": have in existence a set which is bigger than open and closed.  

Discussion:
* Robert: do we want to build this set in SIMPLE or in IETF? 
* General consensus: want to do this in SIMPLE. 
* Robert: As Mark has suggested, they've tried to do this repeatedly. 
* Dean: get list from wireless village that they've submitted to 3G standards
* Adam: they're not semantically separate. 

An attempt by Jonathan to summarize work item: List, semantically oriented, limit to existing solutions.  Propose group to look at what's out there. 

Conclusion: Avashalom volunteered to take on this task.  Look at existing work in this area.  Mark can provide background info. 

o Finish message sessions (solving threading)
   Too fine grained to discuss now. 

o Adopt a work item to develop the needed data manipulations for buddylist, allow/deny
1. Model for block list, allow list: data schema and object manipulation. 
2. Harder part is the protocol: SOAP, ACAP, ..? 

Discussion: 
* Jonathan: difficulty would also be in authorization, authentication and other such security things. 
* Ben: is data exchange a part of this problem? 
* Jonathan: Yes, it falls out from this problem. 
* Sriram: had previously suggested the web.
* Jonathan: most general.  Simple components document says that.  Architecture doc could talk about this.  Markus would point out the inability for this to work in that environment. Need at a minimum a yes/no to approve a buddy. 
* Tony: the scope of what you can manipulate. Define the minimum set. 
* Cullen: must be defined at an API level that could be used by automata.
* Markus: is this generic group management?  Or is this specific to buddylists? 
* Robert: Need to decide this scope.  In this context, general is way too broad. 
* Jonathan: Everything as a group is another wireless village initiative.

Robert summarizing problem: We have learning to do about data models. Proposing to define a data model for buddylists, authorization lists (for presence and IM), accept/deny.  The issue of how you go about sending the data state in the network relates to the publish problem.  Is there anything we can do in SIMPLE to accelerate that problem. 

Discussion:
* Jonathan: the publish is listed as a simple work item.
* Rohan: didn't get what happened.  Thought the conclusion was for Ben to lead the effort on how to use http to bind...
* Ben: access control and authorization for data manipulation
* Sriram: trying to hook for foo with SIMPLE.  
* Jonathan: want unified view and not solve just one problem.

Robert again summarizing the problem: Able to express buddylists and authorization states and manipulation.  

Discussion:
* Jonathan: collect the results of this and solicit volunteers.
* Robert: buddylists and authorization should be do able.  Data manipulation is another issue. 

Conclusion: Ben will start working on this and Robert will work with Rohan on where this work belongs. 

o Presence document publication
o This was included as part of the previous work item. 
             
o Architecture doc (informational)
o Call flows, etc. 
o Big, long document

Discussion: 
* Adam: is this going to go through the process?
* Jonathan: apparently, this has been done before. Should do this here in SIMPLE.  Document should describe how to build a consumer grade appl. 
* Tony: BCP?
* Jonathan: implies more from standard's process, etc. 

Conclusion: consensus to work on that document. 

Proposed new work with SIPPING: 

1 and 2: Straight-forward - agreed 
3. Message confirmation package.   When you're going to something like a GW, want to propagate those backward.  This is similar to REFER use of NOTIFY.  

Discussion:
* Rohan: Message creates a dialog with implicit NOTIFY. 
* Adam: Are you proposing that whenever we send a message, we create a subscription? 
* Ben: The difference between this and REFER is the time scope.  There could be days for SMS. 
* Jonathan: for mobiles, do you have to re-subscribe when you power back on. 
* Robert: attempting to use sub/not , high probability of state drop.
* Rohan: define a new message type: confirmation body.
* Ben: also implies the need to signal for confirmation. 
* Jon P: per SMTP
* Rohan: or SIPFRAG

Conclusion: this would then be a SIMPLE WG item to develop the message. 

4. URI list - content and direction

Jonathan describing problem: Removal of feature in SIP EVENTS, where you could have a URI list. Used MIME type text-URI and this is experimental.  Could not have a reference in a normative RFC. With MIME registrations, it's extremely difficult to get timely resolution ... There is a bigger problem, in that this would be more useful for other messages. Problem: What is scope, lifetime, etc?   Thus, it was pulled out. BUT is a valid SIPPING work item.  

Discussion:
* Sean: lifetime issues are appl specific, thus solving this in a general manner might be problematic. 
* Rohan: How do you use content indirection for sub/not.
* Andrew: they did this for VPIM.  
* Ben: Process: URL only issue?  NOT dealing with how it gets there, etc. 
* Robert: mechanism in notify got killed because of mime type.  REFER put a URL in a header.  
* Adam: trying to point to things that would otherwise be in the body.
* Ben: things may operate on the body without headers
Conclusion:
* Sean and Adam: will write requirements

Continued discussion:
* Dean: Proxy turns stuff into URI list, then it belongs in a header and NOT in a body.
* Andrew: VPIM wants to do this.  Put in body and then extract to header. 

Homeless
o Message store 
o VPIM?
Jonathan overview: Notification of messages that you missed, message histories and store. 
Discussion: 
o Sounds like IMAP and mail.
o Jonathan: that's the proposal. 
o Rohan: to get to data, would need request history. 
Conclusion: Mary to talk to Glenn Parsons and determine if this is it. Rohan to talk to Glenn about coordinating this work between WGs. 

o Content vault 
o Webdav?

Problem description: Want to be able to put contact in, define access list, how you authenticate, lifetime issues and letting others fetch.

Discussion: 
o Cullen: Is "IT" one blob?  
o Jonathan: IT's a blob. 

o Jonathan: Motivated by filesharing appl.  "File transfer"

Conclusion: Sean/Sriram  will talk to someone in webdav and come up with requirements. 

o Floor control, conference policy
o Agreement in BoF to write requirements document. 
o Part of SIPPING right now. 

o Profiles, user and group discovery
Whois++
o Jonathan: find a group for whatever.  How do you do this across distributed domains?  Would work from a webpage in one domain.  
o Mark: IRTF problem.
o Tony: areas like that, provide a URI that points to where to do it.  
Conclusion: Need a liaison and make sure the right things are there. Who:??

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 03 Apr 2002 22:50:51 -0500

A general remark: where possible, I believe it would be helpful to
abstract from the specific event type and see if the operation also
applies to other SIP events. This seems likely to further increase the
leverage that the general SIP event mechanism, as opposed to a specific
presence mechanism, offers. In particular, I believe that conferencing
might later be able to make good use of these generalizations.

> o Nothing to do with list manipulation.

For example, buddy lists are, abstracted, just a list of events and SIP
URIs that I subscribe to. It should be treated as such. 

> * Jonathan: Textual stuff works great until you realize consumer of presence may be automata (onhook/offhook versus open/closed).  Are there a  set of things for semantic understanding?

Comment: The important thing is a unique name (plus maybe an English
phrase) so that I can program behavior. It's not terribly important that
there is a legal definition as to what state of mind and body each word
entails. For example, it's sufficient if within a community of interest
"ttsio" state means "talking to student in office".

Also, priorities are a good example: "Urgent" doesn't have a distinct
meaning ("the building's on fire" vs. "I need this a week from now"),
but it's still useful.

> 2. Harder part is the protocol: SOAP, ACAP, ..?

Again, this is likely a general event/subscription problem, not
specifically a presence problem. ACAP is a configuration retrieval
protocol with very limited deployment, not an RPC mechanism.

Again, conference management ("Dear moderator: User X wants to join
conference. Yes/no?") has a similar problem, as discussed in one of the
meetings.

> o Jonathan: find a group for whatever.  How do you do this across distributed domains?  Would work from a webpage in one domain.

This could be considered a service-location problem. As long as you know
the domain, "remote" SLP would work quite nicely for that.
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 05 Apr 2002 14:03:37 -0500

> URIs that I subscribe to. It should be treated as such.

I agree. THis was one of the discussion points, in fact, as to whether
to make it a template package. Its template packate format would be a
"collection" template, for example:

presence.collection
conference.collection

The fact that its more general doesn't rule out simple doing it, though.
AFter all, watcherinfo is the same - it evolved into a template so
others could use it.

> 
> > * Jonathan: Textual stuff works great until you realize consumer of
> presence may be automata (onhook/offhook versus open/closed).  Are there
> a  set of things for semantic understanding?
> 

Sure. The main point is that somewhere, there needs to be a list of
names, with reasonably defined meanings associated with them...

> protocol with very limited deployment, not an RPC mechanism.

I'm not sure if you are arguing that ACAP is a better fit, if SOAP is a
better fit, or if netiher are the right fit, since this is another event
problem. 

The problem has an event component, but there is more than that. I need
to be able to manipulate lists stored on a server - adding entries,
removing entries, getting the list of entries. I also need to be
notified if that list is changed outside of my client/handset - for
example, modified by customer support, or from a web page. 

> > o Jonathan: find a group for whatever.  How do you do this across
> distributed domains?  Would work from a webpage in one domain.
> 

I think we agreed to steer clear of this problem for now, actually. I
believe it is far more complex than service discovery. 

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Fri, 5 Apr 2002 14:26:16 -0500 (EST)

> names, with reasonably defined meanings associated with them...

While I think a registration mechanism is helpful, I don't even think it's
strictly necessary. It's more important that UAs make it easy to add new
word/description pairs that are meaningful to me. Thus, there's no large
need to worry about restricting the set. If I want to add "tired" or
"drunk" as states of presence, this doesn't seem to do much harm. (At
least in some colleges, those are probably the two most common states...)
One
minor issue is the ability to represent new states via some kind of icon;
that would argue against being too generous in adding hundreds of presence
states each month.

> better fit, or if netiher are the right fit, since this is another event

I'm arguing that ACAP is probably not the right fit. SOAP can do anything
so it's never the wrong fit :-)

> example, modified by customer support, or from a web page.

Speaking from conf-control experience, we found that a combination of
events (SIP) and object manipulation (SOAP methods) works well. The SOAP
component deals with request-response things, SIP events with asynchronous
events that the client can't anticipate.

> believe it is far more complex than service discovery.

In its full generality, I agree. For more circumscribed problems ("find
groups related to cooking that are open to minors and are moderated on
provider BPM.COM"), this is manageable and similar enough. I believe even
the limited functionality would be helpful. Again, it would be similar
between conferences and IM groups.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Apr 2002 18:11:16 -0500

I suspect that we are trying to load too much significance onto a single status value - trying to make it convey everything nuance of availability into one value.

There are a couple of problems with this:
- as Henning noted, there is an expectation that the status value can be represented as an icon. The more values there are the harder it is to do.

- the syntax already supports multiple value elements in status. As soon as there is more than one, mapping to a single icon is a problem that must be dealt with.

Another issue is that this is being approached assuming that the sip/simple community has no vested interest in any particular way of characterizing status. But this isn't
true - we have callerprefs, which provide a way of characterizing availability of contacts. These have not (yet) been integrated with presence, but they ought to be.

Callerprefs provide a number of dimensions on which to classify a contact (tuple). These could be mapped directly to status values. Or they could be mapped to some new
elements within a tuple. They are a bit more complex than the what is currently defined by urn:ietf:params:cpim-presence:status-type:basic. There are a number of preference
parameter types (class, duplex, feature, language, media, mobility, methods, priority), and each in turn has an enumerated set of possible values. (There is also a
"description" parameter, but it probably should be mapped to <note>, and a q-value that is already represented as the priority attribute of <contact>.)

These preference parameters are a bit different than the existing and proposed values. The existing and proposed values generally indicate what state the presentity is in /
what it is doing and leave it up to the watcher to how that relates to its willingness to accept a call. The callerprefs parameters more explicitly state what sorts of
calls should be accepted, without any other explicit indication of current state.

This difference has implications for the UI, but serves more-or-less the same purpose of helping the caller decide whether to attempt a call.

It is important to align these mechanisms, because it provides linkage to registration. If I use registration w/callerprefs to control how/if forking proxies decide to send
calls to me, the information that is learned via presence ought to be consistent. So there ought to be some well defined relationship between the states of the two
mechanisms.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 08 Apr 2002 22:13:39 -0400

"Henning G. Schulzrinne" wrote:

> that would argue against being too generous in adding hundreds of

Without a registration mechanism, and a reasonably well defined meaning
known to all, how could you select the appropriate icon for a status
(assuming you don't send the icon itself)?

This is really symptomatic of the general problem. Without standardized
meanings for a bunch of values, there is no way for an automata to do
processing of presence data. Such processing might include display of an
icon, but there are other things:

  * automatically try to ring the cell phone instead of the desk phone
when someones status is "in a meeting", as opposed to "busy" where the
call would go to voicemail instead.

  * block phone calls when the status is "sleeping" but allow IM

and so on.

> between conferences and IM groups.

When you know the domain where teh group is hosted, its easy, yes. The
whole trick is when you DONT know, and it is that problem which I wish
to steer clear of.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 09 Apr 2002 09:23:59 -0400

>   * block phone calls when the status is "sleeping" but allow IM

However, that type of processing is best done at the callee. Thus, this
only needs to be a local convention between the callee and his proxy
server. It doesn't matter in that case whether I call the state
"dozing", "sleeping", "zzzz" or "napping". I may well have many
different local states that influence call routing, as in "meeting with
boss", "meeting with customer", "meeting with salescritter" (please
interrupt at any time, the sooner, the better), etc. In most of these
cases, I don't want to make this information visible to watchers, yet
still have it be useful for call routing, as part of a CPL or cgi
script, say.

> and so on.

There's a range of utility here, I believe:

(1) private labels (no registration) - can't do icons except by explicit
table in the UA, would need to manually program behavior on a
case-by-case basis, based on token match (com.dynamicsoft.sleeping);
still useful for closed user communities

(2) central registration, but fairly open - can do icons (and other
pre-programmed behavior) as long as list doesn't change too often; fall
back to displaying "other" icon and text string for entities that don't
recognize the state;

(3) limited base set that everybody should understand - icons,
exhaustive case match, useful across general Internet community, etc.

I agree that (3) is important, but I think we'll have an easier time
agreeing on (3) if we don't preclude (2) and (1).

> whole trick is when you DONT know, and it is that problem which I wish

No disagreement; in many cases, I suspect that we can approximate the
latter by meta-sites, just like Yahoo or OpenDirectory provide listings
for many "external" web sites. I would just point my search tool at
best-discussion-groups.com, which in turn finds groups. Same mechanism
as per-domain, but still avoids the "one root" or "global unstructured
search" problem.
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Apr 2002 15:56:10 -0400

Henning,

I am somewhat concerned about the usage model if we attempt to preserve both kinds of status information - what I am doing & what I am willing to do. I don't think it is
reasonable to expect a user to manually set both, nor do I see how one can be derived from the other.

These are distinct mechanisms (callerprefs & presence) that have evolved in different environments (voice & im) and that are trying to expand into each other's niche. They
each have something to contribute, but they have gratuitous differences that get in the way of coexistence or union.

For both mechanisms, some aspects of management can be handled automatically, but not all:

In the case of IM, there has often been an expectation that you manually log on when you are present and log off when you are not, and that this implicitly provides one
mechanism for updating presence. After that, and other nuances (e.g. away from desk) are handled by explicit user interaction. The status values are simple, so they are
easy to manage manually (e.g. by picking from a menu.) 

In the case of callerprefs, while the mechanism has been under development for some time, there is little practical usage experience. The environment in which it is
intended to operate is somewhat different - typically a phone remains connected and accessible whether there is a user attending it or not. Also, the notation for
expressing callerprefs is not so simple - it isn't easily mapped to a simple UI. Simple use of callerprefs will probably be static configuration.

However, I have in mind more active use of callerprefs - picking up the phone may change my availability. Exactly how it changes it should be a configurable option. I may
choose to be unavailable for voice calls whenever I am on a voice call. Or, I may be willing to participate in up to 2 voice calls at a time. My UA could be configured to
update my registration to honor my preferences in this regard.

Other aspects of my callerprefs can't be so easily inferred. If I only want to take personal calls and calls from my bookie when I am on vacation, then I need a UI that
lets me express that kind of logic. 

The trick is - do I have one UI or two? 

Worst case - when I am getting set to go on vacation, I use one UI to update my callerprefs, requesting only personal calls plus calls from my bookie. (This is what I am
*willing* to do.) Then, with a different UI I update my presence, to status "On Vacation".

Slightly better - I use one UI, but set two distinct attributes as above.

Better yet - I use one UI, and select one menu item that causes both attributes to be set.

Further comments below.

	Paul

Henning Schulzrinne wrote:
> 
> Paul Kyzivat wrote:
> >
> > Henning,
> >
> > I'm not sure that this will simplify the task, but it might focus it.
> >
> > A first step is to decide whether callerprefs should be mapped to <value> elements of <status> or if they should be mapped to attributes of <contact> in the way that the
> > q-value is already mapped to a <priority> attribute of <contact>.
> 
> Interesting idea - making it a Contact parameter would remove the need
> for a presence document, to a large extent.

Yes! If you agree that there is a substantial overlap in functionality between callerprefs and presence, then it becomes a lot more appealing to simply update your
callerprefs via REGISTER and not bother updating a presence document separately.

> I suspect we need both, with the same mapping, so that
> Accept/Reject-Contact doesn't need to know whether you registered via
> document or Contact parameter.

Not sure I follow. Are you suggesting that uploading a presence document might cause a re-registration if the contact information in the presence document is in conflict
with the current registration?

I am a bit concerned about that. There is a well defined mechanism for updating contact information in a registration piecemeal from different endpoints. But there is no
similar mechanism for presence documents.

I would rather change presence so that I can upload the part of the presence document that doesn't come from registration, and say that the rest should come from the
registrar/location service.

> > Also, I think there needs to be a discussion of whether we ought to be describing what the presentity is doing, or what it is willing to do, or both. If both, are they
> > dealt with in the same value space, or they separate but equal? While these seem to be different, I am concerned that nobody will be interested in managing them separately
> > - doing so would be cumbersome in a UI. Unfortunately, I don't think there is a well defined mapping between what I am doing and what I am willing to do. Saying what I am
> > willing to do seems more useful to a caller than saying what I am doing.
> 
> I like this distinction.

If we can agree that these are two dimensions to presence status, and that both are relevant, it *might* simplify the problem of defining standard values, by factoring it.

OTOH, it will complicate the problem of mapping to other presence systems that only have one dimension.

> What I'm willing to be doing is pretty simple, for call setup - I'm
> either willing to talk or not. The only real distinction might be the
> media - "willing to text chat" (since I'm in a meeting), "willing to do
> video". We already have the ability to express this in caller
> preferences.

I agree we have the ability to do it, but don't agree that it is simple. The nuances are straightforward syntactically, but not simply represented in a UI. (They don't map
to alternative variants of a single icon.)

"I'm willing to text chat in english or french about business; but I'm only willing to take urgent voice calls,and only in english"

> Expressing my state (what I'm doing) seems most useful to let the other
> side gauge whether their attempt at communication is likely to be
> well-received. Noting "sleeping" or "in a meeting" tells the caller that
> the call better be really important or I'm likely to be rather short
> with them. Similarly, "in a car" might be helpful to know for the caller
> - discussing a deep subject while trying to avoid rear-ending the car in
> front of me is not such a good idea.
> 
> Maybe it would be helpful to have a list of examples in each category.
> 
> So far, I can think of two categories: reflecting general surroundings
> ("car", "home", "office", "public transport" [i.e., don't assume
> privacy]) [caller preferences already has "personal" and "business"] and
> reflecting my degree of distraction or interruptibility ("in meeting",
> "watching TV", "on another call", "thinking", ...). The latter category
> seems to have no end.
> 
> Did I catch what you were trying to say?

I think we are on somewhat the same wavelength.
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 09 Apr 2002 19:00:55 -0400

> reasonable to expect a user to manually set both, nor do I see how one can be derived from the other.

I agree - they are largely orthogonal.

> easy to manage manually (e.g. by picking from a menu.)

While this is true today, I can well imagine more sophisticated
mechanisms, e.g., by referring to the user's appointment book or
biometric sensors (for "sleeping", "talking", "not in good mood",
"legally drunk"). Others, like "in phone call", are hard to derive for
separate IM/voice systems, but trivial for integrated systems.

> expressing callerprefs is not so simple - it isn't easily mapped to a simple UI. Simple use of callerprefs will probably be static configuration.

Most of the parameters are pretty static and often tied to the device
properties ("mobile"), so there isn't as much need for a UI.

> update my registration to honor my preferences in this regard.

Agreed.

> *willing* to do.) Then, with a different UI I update my presence, to status "On Vacation".

Wait a second - caller preferences don't influence what I'm willing to
accept directly, except in an oblique way. To indicate "only calls from
bookie" would be a CPL thingie, not a caller preferences thing.

> callerprefs via REGISTER and not bother updating a presence document separately.

I suspect that we have slightly different notions of what caller
preferences does. The REGISTER side in caller preferences describes
properties of various Contact's, which are then matched by corresponding
Accept-Contact etc. in the INVITE.

> with the current registration?

I don't understand. If the presence state is somehow reflected in the
variables "visible" during caller preferences handling, this doesn't
have to be a re-registration. Logically, the Accept-/Reject-Contact
processing doesn't really care where the parameters came from, REGISTER,
manual configuration or some other mechanism.

> "I'm willing to text chat in english or french about business; but I'm only willing to take urgent voice calls,and only in english"

That's a UI issue. I suspect that much of that information is fairly
constant, with a few parameters changing dynamically. As long as the
parameters are orthogonal, you could have

    Language        Purpose
(1) [x] English     Business
OR
(2) [x] French

etc.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Apr 2002 18:48:11 -0400

Henning - comments below.

	Paul

> bookie" would be a CPL thingie, not a caller preferences thing.

You are right. I can't do that in any obvious way with callerprefs.
I can however do the personal call thing:

	Contact: "cell phone"<tel:+11235551212>;class="personal"
	Contact: <sip:[email-masked]>;class="business"

> Accept-Contact etc. in the INVITE.

The register side describes properties of the contact - properties
that I am willing to admit to (willing to do.) (I do English & Spanish, I do business at
this contact, personal stuff at that one, etc.)

It isn't super rich in expressiveness, but it isn't all the impoverished either. 

> manual configuration or some other mechanism.

I think we must till be talking past one another.

You seem to be saying that the Accept-/Reject-Contact processing, which occurs in a proxy, typically using contact info from a location service, might have got its contact
info from the uploading of a presence document. 

Now either this means that the uploading of the presence document revised the location service, or else proxies that are privy to presence information might work
differently than those that only have access to the location service.

And, if uploading the presence document revises the location service, then there must be some rule for how presence document uploads and registrations are merged into the
location service.

If some proxies use the presence information in addition to location service information to evaluate callerprefs, then again there must be rules for how the two information
sources are merged.

========

Something just occurred to me: 

Perhaps callerprefs in a presence subscription could be used as a filter on presence information. So for example I could subscribe to your presence for class="business",
or for media="voice".

This might work reasonably well - then a smaller set of actual presence states would be useful - even just offline/pending/open/closed.

	Paul