From simple-admin@mailman.dynamicsoft.com  Mon Apr  1 01:16:32 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08359
	for <simple-archive@odin.ietf.org>; Mon, 1 Apr 2002 01:16:32 -0500 (EST)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g316AxFA014387;
	Mon, 1 Apr 2002 01:10:59 -0500 (EST)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA00654;
	Mon, 1 Apr 2002 01:14:05 -0500 (EST)
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA00642
	for <simple@mailman.dynamicsoft.com>; Mon, 1 Apr 2002 01:13:38 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.23])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g316DfTE022292;
	Mon, 1 Apr 2002 01:13:41 -0500 (EST)
Message-ID: <3CA7FA4F.4709C99@dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mikko.lonnfors@nokia.com
CC: tanglih@cn.ibm.com, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] question about winfo-package (resend with revision marks)
References: <0C1353ABB1DEB74DB067ADFF749C4EEF0DCAED@esebe004.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Mon, 01 Apr 2002 01:12:31 -0500
Content-Transfer-Encoding: 7bit



mikko.lonnfors@nokia.com wrote:
> 
> My opinion about your question is as follows:
> 
> The motivating application for winfo package is presence authorization.
> If
> User B is authorized to subscribe A's presence, as you said, generally
> speaking the PS doesn't need to notify A of the B's subscription status
> for
> authorization.
> 
> <ML>
> I would still say that winfo is designed to enable presentity to get
> lists of watchers interested in their presence status.
> This should happen regardless of the watcher's authorization status.
> Presence authorization may be the main motivation
> to enable this functionality but not the only one.
> </ML>

Yes. However, the decision about when to send NOTIFY for winfo is a
server decision; it can decide to not send two notifications in the case
of a fetch.


> 
> If the PS needs to notify A of this FETCH subscription, you may use the
> 'expiration' attribute of winfo foramt. Like this:
>   <watcherinfo>
>      <resource uri="sip:A@foo.com" package="presence">
>        <watcher uri="sip:B@nokia.com" status="active"
>                    event="subscribe" expiration="0"/>
>      </resource>
>    </watcherinfo>
> In this case, A should understanding that a FETCH subscription is
> requested.
> How about this way to solute your problem?
> 
> <ML>
> I think there are some problems with this approach. I think that winfo
> is designed to
> signal changes in watchers subscription status i.e. signal the state to
> which a watcher has moved from previous state.
> In this case, as you said,  A should be able to understand that
> 
>     <resource uri="sip:A@foo.com" package="presence">
>        <watcher uri="sip:B@nokia.com" status="active"
>                    event="subscribe" expiration="0"/>
> 
> means FETCH. This would mean special casing expiration="0".

It only needs to be special cased if you are trying to explicitly
identify fetch requests. I see no reason to do that. The above
notification stands, by itself, as something reasonable. However, if you
want to send a single notification, you are probably better off sending
the one on the transition to terminated due to timeout.



> We could take an other example. Let's say that B performs FETCH but has
> no authorization. Should A now get
> 
>    <resource uri="sip:A@foo.com" package="presence">
>        <watcher uri="sip:B@nokia.com" status="pending"
>                    event="subscribe" expiration="0"/>
> 
> I would say that sending
> 
>    <resource uri="sip:A@foo.com" package="presence">
>        <watcher uri="sip:B@nokia.com" status="waiting"
>                    event="subscribe"/>
> 
> would make more sense.

I agree that the second one makes more sense. The first is valid, of
course, but if you want to send just one notification, the latter is
more useful. Again, the decision about which state change notifications
to send is a matter of local policy.

-Jonathan R.

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


From simple-admin@mailman.dynamicsoft.com  Mon Apr  1 05:02:14 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11460
	for <simple-archive@odin.ietf.org>; Mon, 1 Apr 2002 05:02:13 -0500 (EST)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g319xSe8001440
	for <simple-archive@odin.ietf.org>; Mon, 1 Apr 2002 04:59:28 -0500 (EST)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA01949
	for <simple-archive@lists.ietf.org>; Mon, 1 Apr 2002 05:02:41 -0500 (EST)
Date: Mon, 1 Apr 2002 05:02:41 -0500 (EST)
Message-Id: <200204011002.FAA01949@mailman.dynamicsoft.com>
Subject: mailman.dynamicsoft.com mailing list memberships reminder
From: mailman-owner@mailman.dynamicsoft.com
To: simple-archive@ietf.org
X-No-Archive: yes
X-Ack: no
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk

This is a reminder, sent out once a month, about your
mailman.dynamicsoft.com mailing list memberships.  It includes your
subscription info and how to use it to change it or unsubscribe from a
list.

You can visit the URLs to change your membership status or
configuration, including unsubscribing, setting digest-style delivery
or disabling delivery altogether (e.g., for a vacation), and so on.

In addition to the URL interfaces, you can also use email to make such
changes.  For more info, send a message to the '-request' address of
the list (for example, simple-request@mailman.dynamicsoft.com)
containing just the word 'help' in the message body, and an email
message will be sent to you with instructions.

If you have questions, problems, comments, etc, send them to
mailman-owner@mailman.dynamicsoft.com.  Thanks!

Passwords for simple-archive@lists.ietf.org:

List                                     Password // URL
----                                     --------  
simple@mailman.dynamicsoft.com           ifheto    
http://mailman.dynamicsoft.com/mailman/options/simple/simple-archive%40lists.ietf.org


From simple-admin@mailman.dynamicsoft.com  Wed Apr  3 10:48:14 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07029
	for <simple-archive@odin.ietf.org>; Wed, 3 Apr 2002 10:48:13 -0500 (EST)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g33FhDe8021979;
	Wed, 3 Apr 2002 10:43:13 -0500 (EST)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12944;
	Wed, 3 Apr 2002 10:46:10 -0500 (EST)
Received: from crash.dfw.dynamicsoft.com (dyn-tx-arch-crash.dfw.dynamicsoft.com [63.110.3.64])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12933
	for <simple@mailman.dynamicsoft.com>; Wed, 3 Apr 2002 10:45:50 -0500 (EST)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g33FmjA22926
	for <simple@mailman.dynamicsoft.com>; Wed, 3 Apr 2002 09:48:45 -0600
From: Robert Sparks <rsparks@dynamicsoft.com>
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.3 
Message-Id: <1017848628.1774.70.camel@dhcp222.dfw.dynamicsoft.com>
Mime-Version: 1.0
Subject: [Simple] Draft minutes from IETF53 meeting
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: 03 Apr 2002 09:43:48 -0600
Content-Transfer-Encoding: 7bit

Thanks to James Undery for taking the notes.

Please provide comments/corrections by Apr-8.

RjS
---------------------------------------------
SIMPLE 53rd IETF Salon C Mar-20-2002 15:30

Summary:

* The presence and watcher-info drafts are ready for nits review.
  Nits review will occur by Apr 5 and will proceed to WGLC.

* CPIM mapping effort is on track for June milestone

* Message session
  - Jonathan will provide a proposal for message sessions using
    normal SIP instead of IMTP, using loose routing to solve
    our earlier transport issues
  - Analysis of this proposal and IMXP for satisfying transport
    constraints and CPIM conformity will be provided within 4 weeks 
    (by Apr-22-2002).

* There is general agreement to work on providing solutions for the
  gaps identified in the simple-components draft. Some of the work
  would be done in SIMPLE, some in SIP/SIPPING, and some in a few
  other fora. The work to be done in SIMPLE will be identified and
  a proposed charter reflecting it will be submitted shortly.
    
Detailed Minutes (provided by James Undery)

Agenda Bash
+ No issues

Current deliverables
Apr 02 Presence to be submitted
Apr 02 watcher info to IESG
May 02 CPIM mapping to IESG
Jun 02 IM sessions to draft

SIMPLE issues - Jonathon Rosenberg
==================================

Jonathon presented the latest changes and upcoming work for a number of the 
drafts he is authoring.

Presence
- Alignment with new SIP and sip-events upcoming RFCs
- Removal of 3/4 of examples, removal of example PIDF content from remaining 
  examples
- Additional security, usage of SMIME and sips
- Recommended PUA implement this package, so network can subscribe
- Handle generally applicable issues such as IANA considerations and split 
  references into normative and non-normative categories.

winfo-format
- First-Subscribed will now indicate when the current state machine was first 
  created rather than the first subscription ever
- Removed notify address
- Added expiration params
- Removed most recent subscribed
- id and version attributes will be added after the blackout
Open issue: duration meaningless in fetch operation; Jonathon said to ignore it,
speakers from the floor agreed.

winfo-package
- Forking issue need to get subscriptions on all machines handling 
  subscriptions. Two methods were discussed forking or use existing dialog. 
  Which method to use depends on whether you are the presentity or not. i.e. A 
  pure watcher should use an existing dialog.
- IANA considerations
- State agent text will be rewritten

The proposed schedule for progressing these items was
Arrange nits reviews
Updated drafts by Apr 5 for WGLC
Submit to IESG

CPIM mapping draft open issues - Ben Campbell
=============================================

Ben commented there has been no discussion of this draft on lists. Ben then ran
through his list of open issues.

- How the URI is handled at the CPIM gateway. Two methods have been suggested
  - Direct scheme substitution
  - Leave as a gateway local mapping
  - Ben proposed taking the local policy approach. There was no objection.

- Update the draft to take account of changes in the latest SIP spec. e.g. 
  transaction IDs and dialog.

Christian Huitema observed that CPIM was designed to allow SMIME to cover the 
body, we should check we don't need to change the body at the gateway.

Ben agreed it was reasonable to meet charter deadline of May 02 provided the
work didn't have to account for message sessions (due June 02).

Message sessions
================

IMSX - Marshall Rose
--------------------

Marshall ran through a brief presentation of how IMSX and beep would work.
The steps involved were establish a TCP connection, tune BEEP session and then
exchange messages. Examples of the SDP involved were given showing privacy 
being tuned. 

At this point Christian noted the problems opening the TCP connection from a 
SDP negotiation; Rohan Mahy noted this is being worked on by mmusic in the 
comedia draft.

Marshall explained the tuning process negotiates authentication integrity 
privacy of the connection and how the initial message can be piggybacked with 
opening a IMSX channel. The simplicity of the scheme was then covered, i.e. 
it deals with no addressing, routing,middlebox, message formats or rendering. 
All these issues are handled by other protocols.

Cullen Jennings questioned if lack of middlebox issues was true. The answer 
from various people was this was a SIP/SDP/Midcom issue with the session setup.

Ben asked how large is a beep implementation? Marshall estimated that 20 
screens would cover the simplest implementation and more feature equated to 
more code. 

Jonathon noted SIP offers a lot of the negotiation feature making large 
portions of the BEEP/IMSX setup redundant. To which Marshall replied Beep
stays out of signaling and noted media protocols might want security
negotiation indirectly too.

Christian said attributes should be negotiated in the SDP to remove a level of 
indirection and that TLS handles negotiation of encryption integrity.

Henning Schulzrinne  commented multiple negotiations allows multiple new 
failures.
   
Question from the floor is binary data in beep transported as binary or base 
64 encoded, the reply was BEEP sends as binary.

A discussion of UDP and TCP transversing middleboxes followed, the consensus 
was this is a non-issue as it's the same for both proposals.

IMTP - Jonathon Rosenberg
-------------------------

Jonathon ran through the changes to the SIP spec that have greatly aided and
simplified this work. The main change to benefit IMTP was loose routing that
removed the need to make IMTP a subset of SIP ( by removing UDP, forking and 
redirection). The requirement now being loose routing can only use TCP hops.
Other changes relating to when a proxy can change the Request URI (i.e. only 
when it owns the domain in the Request URI) means using a FQDN or IP of host 
ensures no forking or redirection.

Henning asked if this would interference with normal signaling traffic. 
Jonathon replied that the element handling IMTP wouldn't necessarily be a 
signaling entity.

Henning also inquired if it is possible to open multiple TCP connections to 
handle messages. Jonathon replied yes, however because it's SHOULD to reuse
connection this would requires special code for this instance.

A speaker noted that IMTP was routed at application level yet should act like 
media. Jonathon drew attention to the problems of creating a bespoke protocol 
and how it'd probably be similar to IMTP anyway.

Christian noted we could stream CPIM over TCP as a minimum, however, we might 
need a proxy for logging etc. So IMTP is probably minimal for what we want.

Bob Penfield observed using Record-Routes seems overkill. Jonathon responded 
by saying it was likely that the loose route would be obtained separately 
routes in the signaling.

The chairs commented we have two concrete proposals neither absolutely flawed, 
we have the options pick one, pick both or chuck the problem. After a lengthy 
discussion on the two alternatives it was decided that both options would verify 
they conform to CPIM sanity checks and report this back within 4 weeks. Once 
this information was in the WG would be in a better position to pick one or 
proceed with both.

Andrew Zmolek added that picking one option now doesn't shut the door on the 
other, SIP can still use it later.

Alison Mankin noted that the proposals should also tidy loose ends as they 
checked for CPIM conformity.

Page vs Session modes and groups - Jonathon Rosenberg
=====================================================

Jonathon ran through talk showing groups existed in both modes, and 
characterised with mode was appropriate. Counter examples were discussed, and
Jonathon agreed group messaging covered a spectrum of modes and potentially 
mode transition would be useful.

Open issues were then covered including threading and ordering of group 
messages, group addressing and maximum message size for page mode (Bis 
will automatically use TCP for big messages)

Christian noted for security and page mode we want to use SMIME which could be
large due to the certificates. Jonathon replied session mode could use a 
session key rather than certs. Christian also noted this could be a bigger SIP
issue.

Jonathon finished with the biggest open issue, how much effort should we put 
in to adding group mode that is how to use the existing modes one, both or 
neither. Jonathon recommended for groups mode use session. Henning replied we 
don't need to make the decision, there are cases for both, we should give 
advice not make a choice. Dave Oran questioned this asking why would you 
need group in both, one reason for page mode is latency for the initial 
message, otherwise use session.

SIMPLE components - Jonathon Rosenberg
======================================

Jonathon gave a presentation of the network components that would be required
for a functional "buddy list" application, and suggested we ensure the tools 
were available to build this.

Jonathon identified a list of what's missing which included; data manipulation,
status notification (i.e. is typing notification), message storing, group 
conferencing, content sharing, threading, publication and glue for above. His
proposal was SIMPLE adopt "buddy list" application, adopt a "is typing" 
solution, adopt development of IM statuses for PIDF, finish message sessions 
(including threading), adopt data manipulation (i.e. list allow or deny), 
a presence publication document and an architecture document to put it all
together.

Henning commented that we have started group mode and threading. Jonathon
noted this is just for SIMPLE, the homeless items are message store (VPIM ?),
content vault manipulation (Webdav ?), conferencing floor control 
(needs a BOF ?) and profiles, user and group discovery (whois++). Lots of 
people agree this is needed, someone noted this homeless stuff needs to go 
somewhere. Sean Olsen asked if we can expand the charter to encompass this 
or pass it out to other WGs. Henning noted another conferencing adhoc had
occurred and were going to produce requirements within 3 weeks.

It was agreed to hold an adhoc meeting to continue this discussion

Markus commented this stuff is needed by 3GPP who will be looking at it 
after release 5. Someone else observed AOL has trademarked buddylist,
Jonathon agreed to change the name he used.

A hum on adopting the work and discussing what it means was held with 
strong consensus for continuing this work.

Keith Drage requested we don't set priorities until input from external groups 
has had a chance to come in.



_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Wed Apr  3 11:38:31 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08585
	for <simple-archive@odin.ietf.org>; Wed, 3 Apr 2002 11:38:26 -0500 (EST)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g33GXne8022718;
	Wed, 3 Apr 2002 11:33:49 -0500 (EST)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13125;
	Wed, 3 Apr 2002 11:37:03 -0500 (EST)
Received: from crash.dfw.dynamicsoft.com (dyn-tx-arch-crash.dfw.dynamicsoft.com [63.110.3.64])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13114
	for <simple@mailman.dynamicsoft.com>; Wed, 3 Apr 2002 11:36:59 -0500 (EST)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g33GdtA23069
	for <simple@mailman.dynamicsoft.com>; Wed, 3 Apr 2002 10:39:55 -0600
From: Robert Sparks <rsparks@dynamicsoft.com>
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.3 
Message-Id: <1017851682.1774.101.camel@dhcp222.dfw.dynamicsoft.com>
Mime-Version: 1.0
Subject: [Simple] notes from the SIMPLE components adhoc at IETF53
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: 03 Apr 2002 10:34:42 -0600
Content-Transfer-Encoding: 7bit

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 avshalom@il.ibm.com
Sriram Parameswar sriramp@nortelnetworks.com
Sean Olson seancolson@yahoo.com
Tony Hansen tony@att.com
Andy Zmolek zmolek@avaya.com
Cullen Jennings fluffy@cisco.com
Robert Sparks rsparks@dynamicsoft.com
Jonathan Rosenberg jdrosen@dynamicsoft.com
Mary Barnes mbarnes@nortelnetworks.com
Adam Roach adam@dynamicsoft.com
Ben Campbell bcampbell@dynamicsoft.com
Mikko Lannfors mikko.lonnfors@nokia.com
Markus Isomaki markus.isomaki@nokia.com
Kristian Kiss kristian.kiss@nokia.com
Mark beckmann mark.beckmann@siemens.com
Georg mayer georg.mayer@icn.siemens.de
Paul Kyzivat pkyzivat@cisco.com
Wolfgang Beck beckw@t-systems.com
Mark Day markday@cisco.com
Hirogasu Sugano sugano.h@jp.fujitsu.com
Keith Drage drage@lucent.com
Dean Willis dean.willis@softarmor.com
James Undery james@ubiquity.com
Rohan Mahy rohan@cisco.com
Jon Peterson jon.Peterson@neustar.biz
Miguel Garcia Miguel.Garcia@ericsson.com
Sonia Garapaty sonia.garapaty@nortelnetworks.com
Jayshree bharatia jayshree@nortelnetworks.com
Pekka pessi pekka.pessi@nokia.com
Miguel A. Garcia Miguel.A.Garcia@ericsson.com



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
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Wed Apr  3 22:52:42 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24930
	for <simple-archive@odin.ietf.org>; Wed, 3 Apr 2002 22:52:42 -0500 (EST)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g343mwe8027364;
	Wed, 3 Apr 2002 22:48:58 -0500 (EST)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA14993;
	Wed, 3 Apr 2002 22:52:02 -0500 (EST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA14982
	for <simple@mailman.dynamicsoft.com>; Wed, 3 Apr 2002 22:51:53 -0500 (EST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id WAA09419;
	Wed, 3 Apr 2002 22:50:55 -0500 (EST)
Received: from cs.columbia.edu (pool-138-89-41-36.mad.east.verizon.net [138.89.41.36])
	(authenticated bits=0)
	by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g343omPm003003
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Wed, 3 Apr 2002 22:50:54 -0500 (EST)
Message-ID: <3CABCD9B.5E7EC028@cs.columbia.edu>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Sparks <rsparks@dynamicsoft.com>
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] notes from the SIMPLE components adhoc at IETF53
References: <1017851682.1774.101.camel@dhcp222.dfw.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Wed, 03 Apr 2002 22:50:51 -0500
Content-Transfer-Encoding: 7bit

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.

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

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.

> 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, ..?

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

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
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Thu Apr  4 07:04:43 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10872
	for <simple-archive@odin.ietf.org>; Thu, 4 Apr 2002 07:04:43 -0500 (EST)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g34C10e8028587;
	Thu, 4 Apr 2002 07:01:00 -0500 (EST)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16340;
	Thu, 4 Apr 2002 07:04:05 -0500 (EST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16329
	for <simple@mailman.dynamicsoft.com>; Thu, 4 Apr 2002 07:03:22 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10739;
	Thu, 4 Apr 2002 07:02:23 -0500 (EST)
Message-Id: <200204041202.HAA10739@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: simple@mailman.dynamicsoft.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-06.txt
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Thu, 04 Apr 2002 07:02:23 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.

	Title		: Session Initiation Protocol (SIP) Extensions for 
                          Presence
	Author(s)	: J. Rosenberg et al.
	Filename	: draft-ietf-simple-presence-06.txt
	Pages		: 26
	Date		: 03-Apr-02
	
This document describes the usage of the Session Initiation Protocol
(SIP) for subscriptions and notifications of user presence. User
presence is defined as the willingness and ability of a user to
communicate with other users on the network. Historically, presence
has been limited to 'on-line' and 'off-line' indicators; the notion
of presence here is broader. Subscriptions and notifications of user
presence are supported by defining an event package within the
general SIP event notification framework. This protocol is also
compliant with the Common Presence and Instant Messaging (CPIM)
framework.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-06.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-simple-presence-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-presence-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020403130515.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-presence-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-simple-presence-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020403130515.I-D@ietf.org>

--OtherAccess--

--NextPart--


_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Thu Apr  4 18:44:42 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12903
	for <simple-archive@odin.ietf.org>; Thu, 4 Apr 2002 18:44:41 -0500 (EST)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g34NXxe8004375;
	Thu, 4 Apr 2002 18:33:59 -0500 (EST)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA18186;
	Thu, 4 Apr 2002 18:37:05 -0500 (EST)
Received: from crash.dfw.dynamicsoft.com (dyn-tx-arch-crash.dfw.dynamicsoft.com [63.110.3.64])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA18175
	for <simple@mailman.dynamicsoft.com>; Thu, 4 Apr 2002 18:36:51 -0500 (EST)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g34NdkA28409
	for <simple@mailman.dynamicsoft.com>; Thu, 4 Apr 2002 17:39:46 -0600
From: Robert Sparks <rsparks@dynamicsoft.com>
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.3 
Message-Id: <1017963350.1228.6.camel@localhost.localdomain>
Mime-Version: 1.0
Subject: [Simple] WGLC: draft-ietf-simple-presence-06.txt
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: 04 Apr 2002 17:35:50 -0600
Content-Transfer-Encoding: 7bit

This is a SIMPLE working group last call for comments on the
presence draft announced below. 

This draft has been through a last call before, but was
touched afterwards to align with the changes in sip-events
and the new RFC. As such, this call for comments is short.

Please post any comments you have on this draft to the list
before April 11.

Thanks,

RjS

-----Forwarded Message-----

> From: Internet-Drafts@ietf.org
> Cc: simple@mailman.dynamicsoft.com
> Subject: I-D ACTION:draft-ietf-simple-presence-06.txt
> Date: 04 Apr 2002 07:02:23 -0500
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.
> 
> 	Title		: Session Initiation Protocol (SIP) Extensions for 
>                           Presence
> 	Author(s)	: J. Rosenberg et al.
> 	Filename	: draft-ietf-simple-presence-06.txt
> 	Pages		: 26
> 	Date		: 03-Apr-02
> 	
> This document describes the usage of the Session Initiation Protocol
> (SIP) for subscriptions and notifications of user presence. User
> presence is defined as the willingness and ability of a user to
> communicate with other users on the network. Historically, presence
> has been limited to 'on-line' and 'off-line' indicators; the notion
> of presence here is broader. Subscriptions and notifications of user
> presence are supported by defining an event package within the
> general SIP event notification framework. This protocol is also
> compliant with the Common Presence and Instant Messaging (CPIM)
> framework.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-06.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body of the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-simple-presence-06.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-simple-presence-06.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 


_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Thu Apr  4 21:07:39 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15067
	for <simple-archive@odin.ietf.org>; Thu, 4 Apr 2002 21:07:38 -0500 (EST)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3523oe8004955;
	Thu, 4 Apr 2002 21:03:51 -0500 (EST)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA18611;
	Thu, 4 Apr 2002 21:07:02 -0500 (EST)
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA18600
	for <simple@mailman.dynamicsoft.com>; Thu, 4 Apr 2002 21:06:26 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.11])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g3526eTE028991;
	Thu, 4 Apr 2002 21:06:40 -0500 (EST)
Message-ID: <3CAD0668.554BC8EB@dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Sparks <rsparks@dynamicsoft.com>
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] WGLC: draft-ietf-simple-presence-06.txt
References: <1017963350.1228.6.camel@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Thu, 04 Apr 2002 21:05:28 -0500
Content-Transfer-Encoding: 7bit

Note that the changes from -05 to -06 are entirely cosmetic, based on
nits reviews on the -05 version.

-Jonathan R.

Robert Sparks wrote:
> 
> This is a SIMPLE working group last call for comments on the
> presence draft announced below.
> 
> This draft has been through a last call before, but was
> touched afterwards to align with the changes in sip-events
> and the new RFC. As such, this call for comments is short.
> 
> Please post any comments you have on this draft to the list
> before April 11.
> 
> Thanks,
> 
> RjS
> 
> -----Forwarded Message-----
> 
> > From: Internet-Drafts@ietf.org
> > Cc: simple@mailman.dynamicsoft.com
> > Subject: I-D ACTION:draft-ietf-simple-presence-06.txt
> > Date: 04 Apr 2002 07:02:23 -0500
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the SIP for Instant Messaging and
> Presence Leveraging Extensions Working Group of the IETF.
> >
> >       Title           : Session Initiation Protocol (SIP) Extensions
> for
> >                           Presence
> >       Author(s)       : J. Rosenberg et al.
> >       Filename        : draft-ietf-simple-presence-06.txt
> >       Pages           : 26
> >       Date            : 03-Apr-02
> >
> > This document describes the usage of the Session Initiation Protocol
> > (SIP) for subscriptions and notifications of user presence. User
> > presence is defined as the willingness and ability of a user to
> > communicate with other users on the network. Historically, presence
> > has been limited to 'on-line' and 'off-line' indicators; the notion
> > of presence here is broader. Subscriptions and notifications of user
> > presence are supported by defining an event package within the
> > general SIP event notification framework. This protocol is also
> > compliant with the Common Presence and Instant Messaging (CPIM)
> > framework.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-06.txt
> >
> > To remove yourself from the IETF Announcement list, send a message to
> > ietf-announce-request with the word unsubscribe in the body of the
> message.
> >
> > Internet-Drafts are also available by anonymous FTP. Login with the
> username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> >       "get draft-ietf-simple-presence-06.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> >       mailserv@ietf.org.
> > In the body type:
> >       "FILE /internet-drafts/draft-ietf-simple-presence-06.txt".
> >
> > NOTE: The mail server at ietf.org can return the document in
> >       MIME-encoded form by using the "mpack" utility.  To use this
> >       feature, insert the command "ENCODING mime" before the "FILE"
> >       command.  To decode the response(s), you will need "munpack" or
> >       a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
> >       exhibit different behavior, especially when dealing with
> >       "multipart" MIME messages (i.e. documents which have been split
> >       up into multiple messages), so check your local documentation on
> >       how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

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


From simple-admin@mailman.dynamicsoft.com  Fri Apr  5 14:07:04 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13637
	for <simple-archive@odin.ietf.org>; Fri, 5 Apr 2002 14:07:04 -0500 (EST)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g35J2re8009471;
	Fri, 5 Apr 2002 14:02:53 -0500 (EST)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21373;
	Fri, 5 Apr 2002 14:06:03 -0500 (EST)
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21361
	for <simple@mailman.dynamicsoft.com>; Fri, 5 Apr 2002 14:05:07 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.11])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g35J4nTE029575;
	Fri, 5 Apr 2002 14:04:49 -0500 (EST)
Message-ID: <3CADF509.7CF561D@dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: Robert Sparks <rsparks@dynamicsoft.com>, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] notes from the SIMPLE components adhoc at IETF53
References: <3CABCD9B.5E7EC028@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Fri, 05 Apr 2002 14:03:37 -0500
Content-Transfer-Encoding: 7bit



Henning Schulzrinne wrote:
> 
> 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.
> 
> >
> > 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.
> 
> For example, buddy lists are, abstracted, just a list of events and SIP
> 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?
> 
> 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.

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

> 
> > 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, ..?
> 
> 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.

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 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.
> 
> This could be considered a service-location problem. As long as you know
> the domain, "remote" SLP would work quite nicely for that.

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
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Fri Apr  5 14:28:51 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14707
	for <simple-archive@odin.ietf.org>; Fri, 5 Apr 2002 14:28:46 -0500 (EST)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g35JOle8009679;
	Fri, 5 Apr 2002 14:24:47 -0500 (EST)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21453;
	Fri, 5 Apr 2002 14:28:02 -0500 (EST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21442
	for <simple@mailman.dynamicsoft.com>; Fri, 5 Apr 2002 14:27:20 -0500 (EST)
Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA09781;
	Fri, 5 Apr 2002 14:26:18 -0500 (EST)
Received: from bart.cs.columbia.edu (localhost [127.0.0.1])
	by bart.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g35JQHDS023006;
	Fri, 5 Apr 2002 14:26:17 -0500 (EST)
Received: from localhost (hgs@localhost)
	by bart.cs.columbia.edu (8.12.1/8.12.1/Submit) with ESMTP id g35JQGlr023003;
	Fri, 5 Apr 2002 14:26:17 -0500 (EST)
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
cc: Robert Sparks <rsparks@dynamicsoft.com>, <simple@mailman.dynamicsoft.com>
Subject: Re: [Simple] notes from the SIMPLE components adhoc at IETF53
In-Reply-To: <3CADF509.7CF561D@dynamicsoft.com>
Message-ID: <Pine.GSO.4.31.0204051415590.22989-100000@bart.cs.columbia.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Fri, 5 Apr 2002 14:26:16 -0500 (EST)


> >
> > 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.
>
> Sure. The main point is that somewhere, there needs to be a list of
> 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.

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

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

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

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.

> > > 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.
> >
> > This could be considered a service-location problem. As long as you know
> > the domain, "remote" SLP would work quite nicely for that.
>
> I think we agreed to steer clear of this problem for now, actually. I
> 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.

_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Fri Apr  5 18:13:44 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06563
	for <simple-archive@odin.ietf.org>; Fri, 5 Apr 2002 18:13:44 -0500 (EST)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g35N9pe8011452;
	Fri, 5 Apr 2002 18:09:51 -0500 (EST)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA22098;
	Fri, 5 Apr 2002 18:13:03 -0500 (EST)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA22087
	for <simple@mailman.dynamicsoft.com>; Fri, 5 Apr 2002 18:12:19 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g35NBe505785;
	Fri, 5 Apr 2002 18:11:40 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAH98014;
	Fri, 5 Apr 2002 18:14:34 -0500 (EST)
Message-ID: <3CAE2F14.A335A079@cisco.com>
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
CC: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Robert Sparks <rsparks@dynamicsoft.com>,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] notes from the SIMPLE components adhoc at IETF53
References: <Pine.GSO.4.31.0204051415590.22989-100000@bart.cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Fri, 05 Apr 2002 18:11:16 -0500
Content-Transfer-Encoding: 7bit

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

"Henning G. Schulzrinne" wrote:
> 
> > >
> > > 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.
> >
> > Sure. The main point is that somewhere, there needs to be a list of
> > 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.
> 
> >
> > 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.
> 
> I'm arguing that ACAP is probably not the right fit. SOAP can do anything
> so it's never the wrong fit :-)
> 
> >
> > 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.
> >
> >
> 
> 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.
> 
> > > > 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.
> > >
> > > This could be considered a service-location problem. As long as you know
> > > the domain, "remote" SLP would work quite nicely for that.
> >
> > I think we agreed to steer clear of this problem for now, actually. I
> > 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.
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Fri Apr  5 20:36:57 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16898
	for <simple-archive@odin.ietf.org>; Fri, 5 Apr 2002 20:36:57 -0500 (EST)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g361Wte8011895;
	Fri, 5 Apr 2002 20:32:55 -0500 (EST)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA22489;
	Fri, 5 Apr 2002 20:36:04 -0500 (EST)
Received: from web11608.mail.yahoo.com (web11608.mail.yahoo.com [216.136.172.60])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id UAA22477
	for <simple@mailman.dynamicsoft.com>; Fri, 5 Apr 2002 20:35:06 -0500 (EST)
Message-ID: <20020406013410.1461.qmail@web11608.mail.yahoo.com>
Received: from [131.107.3.70] by web11608.mail.yahoo.com via HTTP; Fri, 05 Apr 2002 17:34:10 PST
From: Sean Olson <seancolson@yahoo.com>
To: sipping@ietf.org, simple@mailman.dynamicsoft.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [Simple] draft-olson-sipping-content-indirect-00.txt
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Fri, 5 Apr 2002 17:34:10 -0800 (PST)

FYI. I've put together a draft of requirements
for a mechanism to allow content indirection
(an indirect reference to content that would normally
be carried directly in the SIP payload)

http://www.ietf.org/internet-drafts/draft-olson-sipping-content-indirect-00.txt

/sean


=====
Sean Olson <seancolson@yahoo.com>

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Mon Apr  8 10:12:59 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24418
	for <simple-archive@odin.ietf.org>; Mon, 8 Apr 2002 10:12:59 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g38E8rPe001543;
	Mon, 8 Apr 2002 10:08:54 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01139;
	Mon, 8 Apr 2002 10:12:04 -0400 (EDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01128
	for <simple@mailman.dynamicsoft.com>; Mon, 8 Apr 2002 10:11:34 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g38EARDX019488;
	Mon, 8 Apr 2002 10:10:28 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAI02609;
	Mon, 8 Apr 2002 10:13:22 -0400 (EDT)
Message-ID: <3CB1A4BC.8DB70998@cisco.com>
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sean Olson <seancolson@yahoo.com>
CC: sipping@ietf.org, simple@mailman.dynamicsoft.com
References: <20020406013410.1461.qmail@web11608.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [Simple] Re: [Sipping] draft-olson-sipping-content-indirect-00.txt
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Mon, 08 Apr 2002 10:10:04 -0400
Content-Transfer-Encoding: 7bit

Sean - comment below.

	Paul

Sean Olson wrote:
> 
> FYI. I've put together a draft of requirements
> for a mechanism to allow content indirection
> (an indirect reference to content that would normally
> be carried directly in the SIP payload)
> 
> http://www.ietf.org/internet-drafts/draft-olson-sipping-content-indirect-00.txt

What is the purpose of REQ-2? 

Since this proposal is about content indirection, it seems like the purpose of the content should be unchanged whether it is indirected or not. Whatever mechanism there is
out to apply equally whether the content is direct or indirect. The Content-Disposition header already serves this purpose.

Perhaps you are trying to say that it should be possible to use several URLs as an alternative to several parts in a multipart-MIME body, and that you want an ability
equivalent to specifying a separate Content-Disposition header for each. That seems reasonable.

But if you are suggesting a need for more forms of disposition than are currently covered by Content-Disposition, then I think that should be handled in a way independent
of content indirection.

	Paul
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Mon Apr  8 11:12:53 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26471
	for <simple-archive@odin.ietf.org>; Mon, 8 Apr 2002 11:12:53 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g38EpkPe001998;
	Mon, 8 Apr 2002 10:51:46 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01299;
	Mon, 8 Apr 2002 10:55:04 -0400 (EDT)
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01286
	for <simple@mailman.dynamicsoft.com>; Mon, 8 Apr 2002 10:54:58 -0400 (EDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g38ErID25199;
	Mon, 8 Apr 2002 09:53:18 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2JXVK3GP>; Mon, 8 Apr 2002 09:50:42 -0500
Message-ID: <EF1056F8EB4ED511B8FB0002A56079D401E5AFE8@zrc2c014.us.nortel.com>
From: "Sriram Parameswar"<sriramp@nortelnetworks.com>
To: "'Paul Kyzivat'" <pkyzivat@cisco.com>, Sean Olson <seancolson@yahoo.com>
Cc: sipping@ietf.org, simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Re: [Sipping] draft-olson-sipping-content-indirect-0
	0.txt
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1DF0C.C00A0BD0"
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Mon, 8 Apr 2002 09:50:39 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1DF0C.C00A0BD0
Content-Type: text/plain;
	charset="iso-8859-1"

Sean:

Couple of additional comments/requirements:

** Access-Control - control over access to the content either by
authorization mechanisms or others. 
** Access-Control mechanism - this is probably extreme but we could probably
add an access-control mechanism. This should allow for a method of
access-control modification i.e. I gave you permission to see a particular
content - then want to revoke this privilege.

Thanks,

Sriram

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-684-3986
Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com


-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent: Monday, April 08, 2002 9:10 AM
To: Sean Olson
Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
Subject: [Simple] Re: [Sipping]
draft-olson-sipping-content-indirect-00.txt


Sean - comment below.

	Paul

Sean Olson wrote:
> 
> FYI. I've put together a draft of requirements
> for a mechanism to allow content indirection
> (an indirect reference to content that would normally
> be carried directly in the SIP payload)
> 
>
http://www.ietf.org/internet-drafts/draft-olson-sipping-content-indirect-00.
txt

What is the purpose of REQ-2? 

Since this proposal is about content indirection, it seems like the purpose
of the content should be unchanged whether it is indirected or not. Whatever
mechanism there is
out to apply equally whether the content is direct or indirect. The
Content-Disposition header already serves this purpose.

Perhaps you are trying to say that it should be possible to use several URLs
as an alternative to several parts in a multipart-MIME body, and that you
want an ability
equivalent to specifying a separate Content-Disposition header for each.
That seems reasonable.

But if you are suggesting a need for more forms of disposition than are
currently covered by Content-Disposition, then I think that should be
handled in a way independent
of content indirection.

	Paul
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple

------_=_NextPart_001_01C1DF0C.C00A0BD0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [Simple] Re: [Sipping] =
draft-olson-sipping-content-indirect-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Sean:</FONT>
</P>

<P><FONT SIZE=3D2>Couple of additional comments/requirements:</FONT>
</P>

<P><FONT SIZE=3D2>** Access-Control - control over access to the =
content either by authorization mechanisms or others. </FONT>
<BR><FONT SIZE=3D2>** Access-Control mechanism - this is probably =
extreme but we could probably add an access-control mechanism. This =
should allow for a method of access-control modification i.e. I gave =
you permission to see a particular content - then want to revoke this =
privilege.</FONT></P>

<P><FONT SIZE=3D2>Thanks,</FONT>
</P>

<P><FONT SIZE=3D2>Sriram</FONT>
</P>

<P><FONT SIZE=3D2>__________________________________________</FONT>
<BR><FONT SIZE=3D2>Sriram =
Parameswar&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; Phone: 972-685-8540</FONT>
<BR><FONT SIZE=3D2>Interactive Multimedia Server (IMS) Fax: =
972-684-3986</FONT>
<BR><FONT SIZE=3D2>Nortel Networks, Richardson USA&nbsp; Email: =
sriramp@nortelnetworks.com</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Paul Kyzivat [<A =
HREF=3D"mailto:pkyzivat@cisco.com">mailto:pkyzivat@cisco.com</A>]</FONT>=

<BR><FONT SIZE=3D2>Sent: Monday, April 08, 2002 9:10 AM</FONT>
<BR><FONT SIZE=3D2>To: Sean Olson</FONT>
<BR><FONT SIZE=3D2>Cc: sipping@ietf.org; =
simple@mailman.dynamicsoft.com</FONT>
<BR><FONT SIZE=3D2>Subject: [Simple] Re: [Sipping]</FONT>
<BR><FONT SIZE=3D2>draft-olson-sipping-content-indirect-00.txt</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Sean - comment below.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Paul</FONT>
</P>

<P><FONT SIZE=3D2>Sean Olson wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; FYI. I've put together a draft of =
requirements</FONT>
<BR><FONT SIZE=3D2>&gt; for a mechanism to allow content =
indirection</FONT>
<BR><FONT SIZE=3D2>&gt; (an indirect reference to content that would =
normally</FONT>
<BR><FONT SIZE=3D2>&gt; be carried directly in the SIP payload)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-olson-sipping-content-=
indirect-00.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-olson-sippin=
g-content-indirect-00.txt</A></FONT>
</P>

<P><FONT SIZE=3D2>What is the purpose of REQ-2? </FONT>
</P>

<P><FONT SIZE=3D2>Since this proposal is about content indirection, it =
seems like the purpose of the content should be unchanged whether it is =
indirected or not. Whatever mechanism there is</FONT></P>

<P><FONT SIZE=3D2>out to apply equally whether the content is direct or =
indirect. The Content-Disposition header already serves this =
purpose.</FONT></P>

<P><FONT SIZE=3D2>Perhaps you are trying to say that it should be =
possible to use several URLs as an alternative to several parts in a =
multipart-MIME body, and that you want an ability</FONT></P>

<P><FONT SIZE=3D2>equivalent to specifying a separate =
Content-Disposition header for each. That seems reasonable.</FONT>
</P>

<P><FONT SIZE=3D2>But if you are suggesting a need for more forms of =
disposition than are currently covered by Content-Disposition, then I =
think that should be handled in a way independent</FONT></P>

<P><FONT SIZE=3D2>of content indirection.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Paul</FONT>
<BR><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>simple mailing list</FONT>
<BR><FONT SIZE=3D2>simple@mailman.dynamicsoft.com</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://mailman.dynamicsoft.com/mailman/listinfo/simple" =
TARGET=3D"_blank">http://mailman.dynamicsoft.com/mailman/listinfo/simple=
</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1DF0C.C00A0BD0--
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Mon Apr  8 12:44:40 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29526
	for <simple-archive@odin.ietf.org>; Mon, 8 Apr 2002 12:44:39 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g38GelPe003300;
	Mon, 8 Apr 2002 12:40:47 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01666;
	Mon, 8 Apr 2002 12:44:03 -0400 (EDT)
Received: from web11602.mail.yahoo.com (web11602.mail.yahoo.com [216.136.172.54])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id MAA01655
	for <simple@mailman.dynamicsoft.com>; Mon, 8 Apr 2002 12:43:05 -0400 (EDT)
Message-ID: <20020408164205.88765.qmail@web11602.mail.yahoo.com>
Received: from [207.46.137.8] by web11602.mail.yahoo.com via HTTP; Mon, 08 Apr 2002 09:42:05 PDT
From: Sean Olson <seancolson@yahoo.com>
To: Paul Kyzivat <pkyzivat@cisco.com>
Cc: sipping@ietf.org, simple@mailman.dynamicsoft.com
In-Reply-To: <3CB1A4BC.8DB70998@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [Simple] Re: [Sipping] draft-olson-sipping-content-indirect-00.txt
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Mon, 8 Apr 2002 09:42:05 -0700 (PDT)


> 
> Perhaps you are trying to say that it should be
> possible to use several URLs as an alternative to
> several parts in a multipart-MIME body, and that you
> want an ability
> equivalent to specifying a separate
> Content-Disposition header for each. That seems
> reasonable.

Exactly. I will make this explicit.

> 
> But if you are suggesting a need for more forms of
> disposition than are currently covered by
> Content-Disposition, then I think that should be
> handled in a way independent
> of content indirection.

I think Content-Disposition could be easily
extended to accommodate what I have in mind.
I will leave those details to a draft that 
proposes an implementation of these requirements.

> 
> 	Paul

Thanks for the comments.
/sean



__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Mon Apr  8 13:07:57 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00069
	for <simple-archive@odin.ietf.org>; Mon, 8 Apr 2002 13:07:56 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g38H2iPe003561;
	Mon, 8 Apr 2002 13:02:44 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01768;
	Mon, 8 Apr 2002 13:06:03 -0400 (EDT)
Received: from web11607.mail.yahoo.com (web11607.mail.yahoo.com [216.136.172.59])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id NAA01757
	for <simple@mailman.dynamicsoft.com>; Mon, 8 Apr 2002 13:05:46 -0400 (EDT)
Message-ID: <20020408170447.29119.qmail@web11607.mail.yahoo.com>
Received: from [207.46.137.9] by web11607.mail.yahoo.com via HTTP; Mon, 08 Apr 2002 10:04:47 PDT
From: Sean Olson <seancolson@yahoo.com>
Subject: RE: [Simple] Re: [Sipping] draft-olson-sipping-content-indirect-0 0.txt
To: Sriram Parameswar <sriramp@nortelnetworks.com>,
        "'Paul Kyzivat'" <pkyzivat@cisco.com>
Cc: sipping@ietf.org, simple@mailman.dynamicsoft.com
In-Reply-To: <EF1056F8EB4ED511B8FB0002A56079D401E5AFE8@zrc2c014.us.nortel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Mon, 8 Apr 2002 10:04:47 -0700 (PDT)

This starts to spill over into the content vault
area. I'm preparing a separate draft for this.
There is obviously a lot of overlap here. I 
should be able to post the new draft in about a
week. Let me know if this doesn't cover your 
concerns.

Thanks,
Sean

--- Sriram Parameswar <sriramp@nortelnetworks.com>
wrote:
> Sean:
> 
> Couple of additional comments/requirements:
> 
> ** Access-Control - control over access to the
> content either by
> authorization mechanisms or others. 
> ** Access-Control mechanism - this is probably
> extreme but we could probably
> add an access-control mechanism. This should allow
> for a method of
> access-control modification i.e. I gave you
> permission to see a particular
> content - then want to revoke this privilege.
> 
> Thanks,
> 
> Sriram
> 
> __________________________________________
> Sriram Parameswar              Phone: 972-685-8540
> Interactive Multimedia Server (IMS) Fax:
> 972-684-3986
> Nortel Networks, Richardson USA  Email:
> sriramp@nortelnetworks.com
> 
> 
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Monday, April 08, 2002 9:10 AM
> To: Sean Olson
> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> Subject: [Simple] Re: [Sipping]
> draft-olson-sipping-content-indirect-00.txt
> 
> 
> Sean - comment below.
> 
> 	Paul
> 
> Sean Olson wrote:
> > 
> > FYI. I've put together a draft of requirements
> > for a mechanism to allow content indirection
> > (an indirect reference to content that would
> normally
> > be carried directly in the SIP payload)
> > 
> >
>
http://www.ietf.org/internet-drafts/draft-olson-sipping-content-indirect-00.
> txt
> 
> What is the purpose of REQ-2? 
> 
> Since this proposal is about content indirection, it
> seems like the purpose
> of the content should be unchanged whether it is
> indirected or not. Whatever
> mechanism there is
> out to apply equally whether the content is direct
> or indirect. The
> Content-Disposition header already serves this
> purpose.
> 
> Perhaps you are trying to say that it should be
> possible to use several URLs
> as an alternative to several parts in a
> multipart-MIME body, and that you
> want an ability
> equivalent to specifying a separate
> Content-Disposition header for each.
> That seems reasonable.
> 
> But if you are suggesting a need for more forms of
> disposition than are
> currently covered by Content-Disposition, then I
> think that should be
> handled in a way independent
> of content indirection.
> 
> 	Paul
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
>
http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 


=====
Sean Olson <seancolson@yahoo.com>

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Tue Apr  9 03:33:56 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28423
	for <simple-archive@lists.ietf.org>; Tue, 9 Apr 2002 03:33:56 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g397UmPe008429;
	Tue, 9 Apr 2002 03:30:48 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04053;
	Tue, 9 Apr 2002 03:34:03 -0400 (EDT)
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04042
	for <simple@mailman.dynamicsoft.com>; Tue, 9 Apr 2002 03:33:37 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.115])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g397X9o6002206;
	Tue, 9 Apr 2002 03:33:10 -0400 (EDT)
Message-ID: <3CB24E53.47BCABDF@dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
CC: Robert Sparks <rsparks@dynamicsoft.com>, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] notes from the SIMPLE components adhoc at IETF53
References: <Pine.GSO.4.31.0204051415590.22989-100000@bart.cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Mon, 08 Apr 2002 22:13:39 -0400
Content-Transfer-Encoding: 7bit



"Henning G. Schulzrinne" wrote:
> 

> > > 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.
> >
> > Sure. The main point is that somewhere, there needs to be a list of
> > 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.

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.


> > I think we agreed to steer clear of this problem for now, actually. I
> > 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.

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.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Tue Apr  9 03:37:56 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28480
	for <simple-archive@lists.ietf.org>; Tue, 9 Apr 2002 03:37:55 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g397YiPe008494;
	Tue, 9 Apr 2002 03:34:45 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04090;
	Tue, 9 Apr 2002 03:38:03 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04079
	for <simple@mailman.dynamicsoft.com>; Tue, 9 Apr 2002 03:37:58 -0400 (EDT)
From: mikko.lonnfors@nokia.com
Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g397bH513326
	for <simple@mailman.dynamicsoft.com>; Tue, 9 Apr 2002 10:37:17 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5a26b78ce3ac158f22077@esvir02nok.ntc.nokia.com>;
 Tue, 9 Apr 2002 10:37:00 +0300
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Tue, 9 Apr 2002 10:36:59 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] question about winfo-package (resend with revision marks)
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF104067@esebe004.NOE.Nokia.com>
Thread-Topic: [Simple] question about winfo-package (resend with revision marks)
Thread-Index: AcHZRECmLKeXD7SsTnuU7OZCmRT3oQGUk19A
To: <jdrosen@dynamicsoft.com>
Cc: <simple@mailman.dynamicsoft.com>
X-OriginalArrivalTime: 09 Apr 2002 07:36:59.0954 (UTC) FILETIME=[5570F120:01C1DF99]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id DAA04079
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Tue, 9 Apr 2002 10:36:59 +0300
Content-Transfer-Encoding: 8bit

Hi,

Thanks for the answer. I have one more question about draft-ietf-simple-winfo-package-01.
Chapter 4.7.1 The Subscription State Machine (after figure 1) says:

"If, when a subscription arrives, there is no authorization policy in
existence, the subscription moves into the pending state. In this
state, the server is awaiting an authorization decision. No
notifications are generated, but the subscription FSM is maintained."

Is this to say that the package on which winfo is applied to should not generate
any NOTIFY messages to subscriber? This sound a bit weird because SIP events says that NOTIFY
should be send immediately after 200-class response. (I am here assuming SUB-202 request/response
if there is no authorization policy is set)

So in short how should the quoted sentence be interpreted?

regards
- Mikko

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: 01 April, 2002 09:13
> To: Lonnfors Mikko (NRC/Helsinki)
> Cc: tanglih@cn.ibm.com; simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] question about winfo-package (resend 
> with revision
> marks)
> 
> 
> 
> 
> mikko.lonnfors@nokia.com wrote:
> > 
> > My opinion about your question is as follows:
> > 
> > The motivating application for winfo package is presence 
> authorization.
> > If
> > User B is authorized to subscribe A's presence, as you 
> said, generally
> > speaking the PS doesn't need to notify A of the B's 
> subscription status
> > for
> > authorization.
> > 
> > <ML>
> > I would still say that winfo is designed to enable presentity to get
> > lists of watchers interested in their presence status.
> > This should happen regardless of the watcher's authorization status.
> > Presence authorization may be the main motivation
> > to enable this functionality but not the only one.
> > </ML>
> 
> Yes. However, the decision about when to send NOTIFY for winfo is a
> server decision; it can decide to not send two notifications 
> in the case
> of a fetch.
> 
> 
> > 
> > If the PS needs to notify A of this FETCH subscription, you 
> may use the
> > 'expiration' attribute of winfo foramt. Like this:
> >   <watcherinfo>
> >      <resource uri="sip:A@foo.com" package="presence">
> >        <watcher uri="sip:B@nokia.com" status="active"
> >                    event="subscribe" expiration="0"/>
> >      </resource>
> >    </watcherinfo>
> > In this case, A should understanding that a FETCH subscription is
> > requested.
> > How about this way to solute your problem?
> > 
> > <ML>
> > I think there are some problems with this approach. I think 
> that winfo
> > is designed to
> > signal changes in watchers subscription status i.e. signal 
> the state to
> > which a watcher has moved from previous state.
> > In this case, as you said,  A should be able to understand that
> > 
> >     <resource uri="sip:A@foo.com" package="presence">
> >        <watcher uri="sip:B@nokia.com" status="active"
> >                    event="subscribe" expiration="0"/>
> > 
> > means FETCH. This would mean special casing expiration="0".
> 
> It only needs to be special cased if you are trying to explicitly
> identify fetch requests. I see no reason to do that. The above
> notification stands, by itself, as something reasonable. 
> However, if you
> want to send a single notification, you are probably better 
> off sending
> the one on the transition to terminated due to timeout.
> 
> 
> 
> > We could take an other example. Let's say that B performs 
> FETCH but has
> > no authorization. Should A now get
> > 
> >    <resource uri="sip:A@foo.com" package="presence">
> >        <watcher uri="sip:B@nokia.com" status="pending"
> >                    event="subscribe" expiration="0"/>
> > 
> > I would say that sending
> > 
> >    <resource uri="sip:A@foo.com" package="presence">
> >        <watcher uri="sip:B@nokia.com" status="waiting"
> >                    event="subscribe"/>
> > 
> > would make more sense.
> 
> I agree that the second one makes more sense. The first is valid, of
> course, but if you want to send just one notification, the latter is
> more useful. Again, the decision about which state change 
> notifications
> to send is a matter of local policy.
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
> 
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Tue Apr  9 09:26:43 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04428
	for <simple-archive@odin.ietf.org>; Tue, 9 Apr 2002 09:26:43 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g39DMmPe009723;
	Tue, 9 Apr 2002 09:22:48 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05048;
	Tue, 9 Apr 2002 09:26:05 -0400 (EDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05037
	for <simple@mailman.dynamicsoft.com>; Tue, 9 Apr 2002 09:25:28 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA07867;
	Tue, 9 Apr 2002 09:24:29 -0400 (EDT)
Received: from cs.columbia.edu (pool-138-89-41-200.mad.east.verizon.net [138.89.41.200])
	(authenticated bits=0)
	by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g39DORPm018603
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Tue, 9 Apr 2002 09:24:28 -0400 (EDT)
Message-ID: <3CB2EB6F.BF507ECE@cs.columbia.edu>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: Robert Sparks <rsparks@dynamicsoft.com>, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] notes from the SIMPLE components adhoc at IETF53
References: <Pine.GSO.4.31.0204051415590.22989-100000@bart.cs.columbia.edu> <3CB24E53.47BCABDF@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Tue, 09 Apr 2002 09:23:59 -0400
Content-Transfer-Encoding: 7bit

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

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


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

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
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Tue Apr  9 13:09:47 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12361
	for <simple-archive@odin.ietf.org>; Tue, 9 Apr 2002 13:09:47 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g39H5sPe012253;
	Tue, 9 Apr 2002 13:05:54 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05658;
	Tue, 9 Apr 2002 13:09:03 -0400 (EDT)
Received: from web11608.mail.yahoo.com (web11608.mail.yahoo.com [216.136.172.60])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id NAA05647
	for <simple@mailman.dynamicsoft.com>; Tue, 9 Apr 2002 13:08:12 -0400 (EDT)
Message-ID: <20020409170715.94629.qmail@web11608.mail.yahoo.com>
Received: from [207.46.137.9] by web11608.mail.yahoo.com via HTTP; Tue, 09 Apr 2002 10:07:15 PDT
From: Sean Olson <seancolson@yahoo.com>
To: "Beck01, Wolfgang" <BeckW@t-systems.com>, sipping@ietf.org,
        simple@mailman.dynamicsoft.com
In-Reply-To: <C3F9C806AEC6D5119643000347055E322088B9@G9JNW.mgb01.telekom.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [Simple] RE: [Sipping] draft-olson-sipping-content-indirect-00.txt
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Tue, 9 Apr 2002 10:07:15 -0700 (PDT)

I absolutely appreciate your concern. Simply
put, any system must have an appropriately defined
security mechanism in place for any packets it
receives. Ignoring Content-Disposition: for now,
what dangers do you perceive for handling an INVITE,
or a SUBSCRIBE, or a REFER, or ... ? This is
roughly equivalent to the problem of handling CPL 
upload. How do you trust the CPL you receive to
know it is safe to execute? Assuming there is
an answer to that question, can you apply that
answer to an "execute" disposition?

I would like to solicit other people's comments
on this topic. If there is sufficient pushback,
I'll remove this item.

Thanks!
/sean

--- "Beck01, Wolfgang" <BeckW@t-systems.com> wrote:
> Sean,
> 
> disposition "execute" in REQ-2 is very dangerous. A
> popular E-mail program
> used to have a similar function enabled by default,
> which resulted
> in a worldwide breakdown of many mail servers. Even
> "render" might be dangerous, if
> the document uses some language like PostScript or
> Word macros.
> 
> 
> --
> Wolfgang Beck
> T-Systems Nova GmbH 
> 
> 


=====
Sean Olson <seancolson@yahoo.com>

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Tue Apr  9 13:27:54 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13080
	for <simple-archive@odin.ietf.org>; Tue, 9 Apr 2002 13:27:54 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g39HNlPe012453;
	Tue, 9 Apr 2002 13:23:47 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05752;
	Tue, 9 Apr 2002 13:27:03 -0400 (EDT)
Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05011
	for <simple@mailman.dynamicsoft.com>; Tue, 9 Apr 2002 09:22:06 -0400 (EDT)
Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 9 Apr 2002 15:19:23 +0200
Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <2Q8W76AN>; Tue, 9 Apr 2002 15:20:30 +0200
Message-Id: <C3F9C806AEC6D5119643000347055E322088B9@G9JNW.mgb01.telekom.de>
From: "Beck01, Wolfgang" <BeckW@t-systems.com>
To: seancolson@yahoo.com, sipping@ietf.org, simple@mailman.dynamicsoft.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Subject: [Simple] RE: [Sipping] draft-olson-sipping-content-indirect-00.txt
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Tue, 9 Apr 2002 15:20:29 +0200

Sean,

disposition "execute" in REQ-2 is very dangerous. A popular E-mail program
used to have a similar function enabled by default, which resulted
in a worldwide breakdown of many mail servers. Even "render" might be dangerous, if
the document uses some language like PostScript or Word macros.


--
Wolfgang Beck
T-Systems Nova GmbH 


_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Tue Apr  9 15:58:54 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19508
	for <simple-archive@odin.ietf.org>; Tue, 9 Apr 2002 15:58:53 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g39JsnPe013984;
	Tue, 9 Apr 2002 15:54:49 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06222;
	Tue, 9 Apr 2002 15:58:05 -0400 (EDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06211
	for <simple@mailman.dynamicsoft.com>; Tue, 9 Apr 2002 15:57:44 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g39JuXR9015767;
	Tue, 9 Apr 2002 15:56:33 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAI13115;
	Tue, 9 Apr 2002 15:59:28 -0400 (EDT)
Message-ID: <3CB34759.E8512A1C@cisco.com>
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] notes from the SIMPLE components adhoc at IETF53
References: <Pine.GSO.4.31.0204051415590.22989-100000@bart.cs.columbia.edu> <3CAE2F14.A335A079@cisco.com> <3CAF1D6C.90444446@cs.columbia.edu> <3CB1D49A.C9BA1BC2@cisco.com> <3CB232B8.C4D665B6@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Tue, 09 Apr 2002 15:56:10 -0400
Content-Transfer-Encoding: 7bit

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
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Tue Apr  9 19:11:29 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25364
	for <simple-archive@odin.ietf.org>; Tue, 9 Apr 2002 19:11:28 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g39N0mPe015494;
	Tue, 9 Apr 2002 19:00:48 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA06757;
	Tue, 9 Apr 2002 19:04:03 -0400 (EDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA06746
	for <simple@mailman.dynamicsoft.com>; Tue, 9 Apr 2002 19:03:51 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA00933;
	Tue, 9 Apr 2002 19:02:46 -0400 (EDT)
Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46])
	(authenticated bits=0)
	by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g39N2jPm021562
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Tue, 9 Apr 2002 19:02:45 -0400 (EDT)
Message-ID: <3CB372A7.F7363C5D@cs.columbia.edu>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
CC: simple@mailman.dynamicsoft.com
References: <Pine.GSO.4.31.0204051415590.22989-100000@bart.cs.columbia.edu> <3CAE2F14.A335A079@cisco.com> <3CAF1D6C.90444446@cs.columbia.edu> <3CB1D49A.C9BA1BC2@cisco.com> <3CB232B8.C4D665B6@cs.columbia.edu> <3CB34759.E8512A1C@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [Simple] State labels (Was: notes from the SIMPLE components adhoc at IETF53)
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Tue, 09 Apr 2002 19:00:55 -0400
Content-Transfer-Encoding: 7bit

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

I agree - they are largely orthogonal.

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

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.

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

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.

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

Agreed.

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

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.


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


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

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

> 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"

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.
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Tue Apr  9 21:53:59 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28491
	for <simple-archive@lists.ietf.org>; Tue, 9 Apr 2002 21:53:58 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3A1omPe016172;
	Tue, 9 Apr 2002 21:50:48 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA07281;
	Tue, 9 Apr 2002 21:54:03 -0400 (EDT)
Received: from obsoft.com (sdsl-64-139-4-113.dsl.sca.megapath.net [64.139.4.113])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA07270
	for <simple@mailman.dynamicsoft.com>; Tue, 9 Apr 2002 21:53:20 -0400 (EDT)
Received: from obsoft.com (localhost.localdomain [127.0.0.1])
	by obsoft.com (8.11.6/8.11.6) with ESMTP id g3A1v4t14429;
	Tue, 9 Apr 2002 18:57:04 -0700
Message-ID: <3CB39BF0.4A4435C8@obsoft.com>
From: Bobby Sardana <sardana@obsoft.com>
Organization: ObjectSoftware, Inc
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Beck01, Wolfgang" <BeckW@t-systems.com>
CC: seancolson@yahoo.com, sipping@ietf.org, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] RE: [Sipping] draft-olson-sipping-content-indirect-00.txt
References: <C3F9C806AEC6D5119643000347055E322088B9@G9JNW.mgb01.telekom.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Tue, 09 Apr 2002 18:57:04 -0700
Content-Transfer-Encoding: 7bit

I am sure that the appropriate UAC will implement a "security sandbox" for both the
"execute" and "render" feature set. A properly designed UAC will also allow such
features to be manually disabled.

Personally, I like the "execute" feature as it allows new services to be deployed on
the UAC.

regards,

Bobby Sardana.
sardana@obsoft.com

"Beck01, Wolfgang" wrote:

> Sean,
>
> disposition "execute" in REQ-2 is very dangerous. A popular E-mail program
> used to have a similar function enabled by default, which resulted
> in a worldwide breakdown of many mail servers. Even "render" might be dangerous, if
> the document uses some language like PostScript or Word macros.
>
> --
> Wolfgang Beck
> T-Systems Nova GmbH
>
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Wed Apr 10 03:00:49 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12754
	for <simple-archive@lists.ietf.org>; Wed, 10 Apr 2002 03:00:49 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3A6vkPe017130;
	Wed, 10 Apr 2002 02:57:46 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA08131;
	Wed, 10 Apr 2002 03:01:03 -0400 (EDT)
Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA08120
	for <simple@mailman.dynamicsoft.com>; Wed, 10 Apr 2002 03:00:40 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3A70fJ22877
	for <simple@mailman.dynamicsoft.com>; Wed, 10 Apr 2002 10:00:41 +0300 (EET DST)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5a2bbbb5ebac158f21083@esvir01nok.ntc.nokia.com>;
 Wed, 10 Apr 2002 09:59:38 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 10 Apr 2002 09:59:40 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 10 Apr 2002 09:59:39 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] question about winfo-package (resend with revision marks)
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB777910E@esebe019.NOE.Nokia.com>
Thread-Topic: [Simple] question about winfo-package (resend with revision marks)
Thread-Index: AcHZRECmLKeXD7SsTnuU7OZCmRT3oQGUk19AADGUEyA=
To: <mikko.lonnfors@nokia.com>, <jdrosen@dynamicsoft.com>
Cc: <simple@mailman.dynamicsoft.com>
X-OriginalArrivalTime: 10 Apr 2002 06:59:39.0910 (UTC) FILETIME=[48AF1A60:01C1E05D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id DAA08120
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Wed, 10 Apr 2002 09:59:38 +0300
Content-Transfer-Encoding: 8bit

The first NOTIFY is sent of course, but there will be no NOTIFYs sent when a change to winfo occurs.

Regards,
Hisham

> -----Original Message-----
> From: Lonnfors Mikko (NRC/Helsinki) 
> Sent: Tuesday, April 09, 2002 10:37 AM
> To: jdrosen@dynamicsoft.com
> Cc: simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] question about winfo-package (resend 
> with revision
> marks)
> 
> 
> Hi,
> 
> Thanks for the answer. I have one more question about 
> draft-ietf-simple-winfo-package-01.
> Chapter 4.7.1 The Subscription State Machine (after figure 1) says:
> 
> "If, when a subscription arrives, there is no authorization policy in
> existence, the subscription moves into the pending state. In this
> state, the server is awaiting an authorization decision. No
> notifications are generated, but the subscription FSM is maintained."
> 
> Is this to say that the package on which winfo is applied to 
> should not generate
> any NOTIFY messages to subscriber? This sound a bit weird 
> because SIP events says that NOTIFY
> should be send immediately after 200-class response. (I am 
> here assuming SUB-202 request/response
> if there is no authorization policy is set)
> 
> So in short how should the quoted sentence be interpreted?
> 
> regards
> - Mikko
> 
> > -----Original Message-----
> > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> > Sent: 01 April, 2002 09:13
> > To: Lonnfors Mikko (NRC/Helsinki)
> > Cc: tanglih@cn.ibm.com; simple@mailman.dynamicsoft.com
> > Subject: Re: [Simple] question about winfo-package (resend 
> > with revision
> > marks)
> > 
> > 
> > 
> > 
> > mikko.lonnfors@nokia.com wrote:
> > > 
> > > My opinion about your question is as follows:
> > > 
> > > The motivating application for winfo package is presence 
> > authorization.
> > > If
> > > User B is authorized to subscribe A's presence, as you 
> > said, generally
> > > speaking the PS doesn't need to notify A of the B's 
> > subscription status
> > > for
> > > authorization.
> > > 
> > > <ML>
> > > I would still say that winfo is designed to enable 
> presentity to get
> > > lists of watchers interested in their presence status.
> > > This should happen regardless of the watcher's 
> authorization status.
> > > Presence authorization may be the main motivation
> > > to enable this functionality but not the only one.
> > > </ML>
> > 
> > Yes. However, the decision about when to send NOTIFY for winfo is a
> > server decision; it can decide to not send two notifications 
> > in the case
> > of a fetch.
> > 
> > 
> > > 
> > > If the PS needs to notify A of this FETCH subscription, you 
> > may use the
> > > 'expiration' attribute of winfo foramt. Like this:
> > >   <watcherinfo>
> > >      <resource uri="sip:A@foo.com" package="presence">
> > >        <watcher uri="sip:B@nokia.com" status="active"
> > >                    event="subscribe" expiration="0"/>
> > >      </resource>
> > >    </watcherinfo>
> > > In this case, A should understanding that a FETCH subscription is
> > > requested.
> > > How about this way to solute your problem?
> > > 
> > > <ML>
> > > I think there are some problems with this approach. I think 
> > that winfo
> > > is designed to
> > > signal changes in watchers subscription status i.e. signal 
> > the state to
> > > which a watcher has moved from previous state.
> > > In this case, as you said,  A should be able to understand that
> > > 
> > >     <resource uri="sip:A@foo.com" package="presence">
> > >        <watcher uri="sip:B@nokia.com" status="active"
> > >                    event="subscribe" expiration="0"/>
> > > 
> > > means FETCH. This would mean special casing expiration="0".
> > 
> > It only needs to be special cased if you are trying to explicitly
> > identify fetch requests. I see no reason to do that. The above
> > notification stands, by itself, as something reasonable. 
> > However, if you
> > want to send a single notification, you are probably better 
> > off sending
> > the one on the transition to terminated due to timeout.
> > 
> > 
> > 
> > > We could take an other example. Let's say that B performs 
> > FETCH but has
> > > no authorization. Should A now get
> > > 
> > >    <resource uri="sip:A@foo.com" package="presence">
> > >        <watcher uri="sip:B@nokia.com" status="pending"
> > >                    event="subscribe" expiration="0"/>
> > > 
> > > I would say that sending
> > > 
> > >    <resource uri="sip:A@foo.com" package="presence">
> > >        <watcher uri="sip:B@nokia.com" status="waiting"
> > >                    event="subscribe"/>
> > > 
> > > would make more sense.
> > 
> > I agree that the second one makes more sense. The first is valid, of
> > course, but if you want to send just one notification, the latter is
> > more useful. Again, the decision about which state change 
> > notifications
> > to send is a matter of local policy.
> > 
> > -Jonathan R.
> > 
> > -- 
> > Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> > Chief Scientist                         First Floor
> > dynamicsoft                             East Hanover, NJ 07936
> > jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
> > http://www.jdrosen.net                  PH:  (973) 952-5000
> > http://www.dynamicsoft.com
> > 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Wed Apr 10 13:08:40 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25405
	for <simple-archive@odin.ietf.org>; Wed, 10 Apr 2002 13:08:35 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3AH3rPe020634;
	Wed, 10 Apr 2002 13:03:54 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09730;
	Wed, 10 Apr 2002 13:07:07 -0400 (EDT)
Received: from teltier.com (teltier.com [161.58.154.42])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09719
	for <simple@mailman.dynamicsoft.com>; Wed, 10 Apr 2002 13:06:14 -0400 (EDT)
Received: from GUERNICA (fwuser@[65.202.44.138]) by teltier.com (8.11.6) id g3AH5AH28977; Wed, 10 Apr 2002 13:05:10 -0400 (EDT)
Reply-To: <jorge@teltier.com>
From: "Jorge Lobo" <jorge@teltier.com>
To: <pkyzivat@cisco.com>, <hgs@cs.columbia.edu>
Cc: <simple@mailman.dynamicsoft.com>
Message-ID: <PAEMLHBKBFEKFKBDBLNGCEBLCJAA.jorge@teltier.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <200204101600.MAA09548@mailman.dynamicsoft.com>
Subject: [Simple] RE: State labels (Was: notes from the SIMPLE components adhoc at IETF53)
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Wed, 10 Apr 2002 12:59:07 -0400
Content-Transfer-Encoding: 7bit


Paul and Henning,

I have been following your discussion on call preferences and
presence and I would like to offer an alternative view.

I have been working with PAM, the presence and availability
management standards being adopted by Parley and 3GPP,
(http://www.PAMForum.org).

In PAM there is a separation between "presence" and "availability".
Presence, as mention by Henning, in the IM world is set by the
user, but in many cases can be and will be automatically detected.
The presence of your cellular phone in the network is detected 
automatically.

What availability offers is a layer over presence where the subscriber
describes preferences on how to expose presence. Preference rules to
compute availability can be as simple as opt-in or out to publication of
presence as in current IM systems to extremely to extremely sophisticated
rules where the user can decide how to expose the information based on 
who is requesting the information, the time of the request, 
the location of the requester and the user, etc. - the bookie example is
one this more complicated examples.

In the case of PAM there is a minimal set of controls that a presence
server should provide as an implementation of availability, but it is
left open to the different implementations how sophisticated the
computation of availability can be.

A similar approach here may solve many of your problems.

Regards,

Jorge.

------------------------
Jorge Lobo, Ph.D.
Principal Architect
Teltier Technologies
60 Walnut Avenue, #300
Clark, NJ 07066
mailto:jorge@teltier.com
------------------------


_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Wed Apr 10 18:51:10 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04645
	for <simple-archive@odin.ietf.org>; Wed, 10 Apr 2002 18:51:10 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3AMkoPe024064;
	Wed, 10 Apr 2002 18:46:50 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA10719;
	Wed, 10 Apr 2002 18:50:06 -0400 (EDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA10706
	for <simple@mailman.dynamicsoft.com>; Wed, 10 Apr 2002 18:49:44 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3AMmZYe009044;
	Wed, 10 Apr 2002 18:48:36 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAI21980;
	Wed, 10 Apr 2002 18:51:29 -0400 (EDT)
Message-ID: <3CB4C12B.5292F18E@cisco.com>
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: simple@mailman.dynamicsoft.com
References: <Pine.GSO.4.31.0204051415590.22989-100000@bart.cs.columbia.edu> <3CAE2F14.A335A079@cisco.com> <3CAF1D6C.90444446@cs.columbia.edu> <3CB1D49A.C9BA1BC2@cisco.com> <3CB232B8.C4D665B6@cs.columbia.edu> <3CB34759.E8512A1C@cisco.com> <3CB372A7.F7363C5D@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [Simple] Re: State labels (Was: notes from the SIMPLE components adhoc at IETF53)
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Wed, 10 Apr 2002 18:48:11 -0400
Content-Transfer-Encoding: 7bit

Henning - comments below.

	Paul

Henning Schulzrinne wrote:
> 
> > 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".
> 
> 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.

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:me.voicemail@foo.com>;class="business"

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

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. 

> > > 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 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 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
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Wed Apr 10 19:14:57 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05005
	for <simple-archive@odin.ietf.org>; Wed, 10 Apr 2002 19:14:57 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3ANAhPe024270;
	Wed, 10 Apr 2002 19:10:43 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA10846;
	Wed, 10 Apr 2002 19:14:03 -0400 (EDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA10835
	for <simple@mailman.dynamicsoft.com>; Wed, 10 Apr 2002 19:13:59 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3ANCpfM010098;
	Wed, 10 Apr 2002 19:12:51 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAI22059;
	Wed, 10 Apr 2002 19:15:45 -0400 (EDT)
Message-ID: <3CB4C6DB.A0A7C7D1@cisco.com>
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: jorge@teltier.com
CC: hgs@cs.columbia.edu, simple@mailman.dynamicsoft.com
References: <PAEMLHBKBFEKFKBDBLNGCEBLCJAA.jorge@teltier.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [Simple] Re: State labels (Was: notes from the SIMPLE components adhoc at IETF53)
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Wed, 10 Apr 2002 19:12:27 -0400
Content-Transfer-Encoding: 7bit

Jorge,

I just took a quick look at the PAM specification.

While it would take a much longer look to fully understand the mappings, I agree that there does seem to be some commonality here.

	Paul

Jorge Lobo wrote:
> 
> Paul and Henning,
> 
> I have been following your discussion on call preferences and
> presence and I would like to offer an alternative view.
> 
> I have been working with PAM, the presence and availability
> management standards being adopted by Parley and 3GPP,
> (http://www.PAMForum.org).
> 
> In PAM there is a separation between "presence" and "availability".
> Presence, as mention by Henning, in the IM world is set by the
> user, but in many cases can be and will be automatically detected.
> The presence of your cellular phone in the network is detected
> automatically.
> 
> What availability offers is a layer over presence where the subscriber
> describes preferences on how to expose presence. Preference rules to
> compute availability can be as simple as opt-in or out to publication of
> presence as in current IM systems to extremely to extremely sophisticated
> rules where the user can decide how to expose the information based on
> who is requesting the information, the time of the request,
> the location of the requester and the user, etc. - the bookie example is
> one this more complicated examples.
> 
> In the case of PAM there is a minimal set of controls that a presence
> server should provide as an implementation of availability, but it is
> left open to the different implementations how sophisticated the
> computation of availability can be.
> 
> A similar approach here may solve many of your problems.
> 
> Regards,
> 
> Jorge.
> 
> ------------------------
> Jorge Lobo, Ph.D.
> Principal Architect
> Teltier Technologies
> 60 Walnut Avenue, #300
> Clark, NJ 07066
> mailto:jorge@teltier.com
> ------------------------
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Wed Apr 10 20:01:52 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05630
	for <simple-archive@odin.ietf.org>; Wed, 10 Apr 2002 20:01:52 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3ANvmPe024573;
	Wed, 10 Apr 2002 19:57:48 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA11043;
	Wed, 10 Apr 2002 20:01:03 -0400 (EDT)
Received: from teltier.com (teltier.com [161.58.154.42])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA11032
	for <simple@mailman.dynamicsoft.com>; Wed, 10 Apr 2002 20:00:54 -0400 (EDT)
Received: from GUERNICA (fwuser@[65.202.44.138]) by teltier.com (8.11.6) id g3ANxqj15152; Wed, 10 Apr 2002 19:59:52 -0400 (EDT)
Reply-To: <jorge@teltier.com>
From: "Jorge Lobo" <jorge@teltier.com>
To: "Paul Kyzivat" <pkyzivat@cisco.com>
Cc: <hgs@cs.columbia.edu>, <simple@mailman.dynamicsoft.com>
Message-ID: <PAEMLHBKBFEKFKBDBLNGOECBCJAA.jorge@teltier.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <3CB4C6DB.A0A7C7D1@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Subject: [Simple] RE: State labels (Was: notes from the SIMPLE components adhoc at IETF53)
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Wed, 10 Apr 2002 19:53:46 -0400
Content-Transfer-Encoding: 7bit


A quick mapping from some of the concepts of PAM to SIMPLE.

PAM is based on Identities, and Identities have Agents
associated with them.  Agents are electronic representations
of (software or hardware) devices. Agents are the producers
of "raw" presence, and the presence of an Identity is derived
from the devices the Identity owns.

Identities  ---> Presentities
Agents      ---> Presence User Agent

Some applications may have direct access to presence but most
applications will be allowed only access to availability.

The basic API calls from PAM relevant to SIMPLE are

set and get presence

set and get preferences

get availability

One more thing.  There is a special class of presence data associated
with agents in PAM called capabilities - given that the capabilities of
an agent (Presence User Agent) can vary with time. For example, a capability
can be J2ME-cable, an attribute of the capability can be
communicationAddress
which can be a dynamic IP address assigned to the agent for communication.

Best,

Jorge.

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent: Wednesday, April 10, 2002 7:12 PM
To: jorge@teltier.com
Cc: hgs@cs.columbia.edu; simple@mailman.dynamicsoft.com
Subject: Re: State labels (Was: notes from the SIMPLE components adhoc
at IETF53)


Jorge,

I just took a quick look at the PAM specification.

While it would take a much longer look to fully understand the mappings, I
agree that there does seem to be some commonality here.

	Paul

Jorge Lobo wrote:
>
> Paul and Henning,
>
> I have been following your discussion on call preferences and
> presence and I would like to offer an alternative view.
>
> I have been working with PAM, the presence and availability
> management standards being adopted by Parley and 3GPP,
> (http://www.PAMForum.org).
>
> In PAM there is a separation between "presence" and "availability".
> Presence, as mention by Henning, in the IM world is set by the
> user, but in many cases can be and will be automatically detected.
> The presence of your cellular phone in the network is detected
> automatically.
>
> What availability offers is a layer over presence where the subscriber
> describes preferences on how to expose presence. Preference rules to
> compute availability can be as simple as opt-in or out to publication of
> presence as in current IM systems to extremely to extremely sophisticated
> rules where the user can decide how to expose the information based on
> who is requesting the information, the time of the request,
> the location of the requester and the user, etc. - the bookie example is
> one this more complicated examples.
>
> In the case of PAM there is a minimal set of controls that a presence
> server should provide as an implementation of availability, but it is
> left open to the different implementations how sophisticated the
> computation of availability can be.
>
> A similar approach here may solve many of your problems.
>
> Regards,
>
> Jorge.
>
> ------------------------
> Jorge Lobo, Ph.D.
> Principal Architect
> Teltier Technologies
> 60 Walnut Avenue, #300
> Clark, NJ 07066
> mailto:jorge@teltier.com
> ------------------------

_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Wed Apr 10 22:29:51 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08300
	for <simple-archive@odin.ietf.org>; Wed, 10 Apr 2002 22:29:51 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3B2PmPe025056;
	Wed, 10 Apr 2002 22:25:48 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA11496;
	Wed, 10 Apr 2002 22:29:03 -0400 (EDT)
Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA11485
	for <simple@mailman.dynamicsoft.com>; Wed, 10 Apr 2002 22:28:21 -0400 (EDT)
Received: from d23rh902.au.ibm.com 
        by ausmtp01.au.ibm.com (IBM AP 2.0) with ESMTP id g3B2MK363670;
        Thu, 11 Apr 2002 12:22:20 +1000
Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18])
	by d23rh902.au.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g3B1lIA15152;
	Thu, 11 Apr 2002 11:47:18 +1000
Subject: Re: [Simple] RE: State labels (Was: notes from the SIMPLE components adhoc
 at IETF53)
To: <jorge@teltier.com>
Cc: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: <OF0DEC05BF.90C3BA86-ON48256B98.00090F08@cn.ibm.com>
From: "Li Hua Tang" <tanglih@cn.ibm.com>
X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at
 11/04/2002 09:47:18
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Thu, 11 Apr 2002 09:47:15 +0800


Jorge,

Tell the truth I am little confused by the concepts you mentioned,
presence, availability and capability in PAM world. Could you please give
me a scenario in the real world?

And how to control the different access to presence and availability? Has
authorization and authentication been considered in PAM?


Best regards,

Tang Lihua



                                                                                                          
                    "Jorge Lobo"                                                                          
                    <jorge@teltier.com>              To:     "Paul Kyzivat" <pkyzivat@cisco.com>          
                    Sent by:                         cc:     <hgs@cs.columbia.edu>,                       
                    simple-admin@mailman.dynam        <simple@mailman.dynamicsoft.com>                    
                    icsoft.com                       Subject:     [Simple] RE: State labels (Was: notes   
                                                      from the SIMPLE components adhoc at IETF53)         
                                                                                                          
                    2002-04-11 07:53                                                                      
                    Please respond to jorge                                                               
                                                                                                          
                                                                                                          




A quick mapping from some of the concepts of PAM to SIMPLE.

PAM is based on Identities, and Identities have Agents
associated with them.  Agents are electronic representations
                 --------
               >>Indentities here?
of (software or hardware) devices. Agents are the producers
of "raw" presence, and the presence of an Identity is derived
from the devices the Identity owns.

Identities  ---> Presentities
Agents      ---> Presence User Agent

Some applications may have direct access to presence but most
applications will be allowed only access to availability.

The basic API calls from PAM relevant to SIMPLE are

set and get presence

set and get preferences

get availability

One more thing.  There is a special class of presence data associated
with agents in PAM called capabilities - given that the capabilities of
an agent (Presence User Agent) can vary with time. For example, a
capability
can be J2ME-cable, an attribute of the capability can be
communicationAddress
which can be a dynamic IP address assigned to the agent for communication.

Best,

Jorge.

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent: Wednesday, April 10, 2002 7:12 PM
To: jorge@teltier.com
Cc: hgs@cs.columbia.edu; simple@mailman.dynamicsoft.com
Subject: Re: State labels (Was: notes from the SIMPLE components adhoc
at IETF53)


Jorge,

I just took a quick look at the PAM specification.

While it would take a much longer look to fully understand the mappings, I
agree that there does seem to be some commonality here.

           Paul

Jorge Lobo wrote:
>
> Paul and Henning,
>
> I have been following your discussion on call preferences and
> presence and I would like to offer an alternative view.
>
> I have been working with PAM, the presence and availability
> management standards being adopted by Parley and 3GPP,
> (http://www.PAMForum.org).
>
> In PAM there is a separation between "presence" and "availability".
> Presence, as mention by Henning, in the IM world is set by the
> user, but in many cases can be and will be automatically detected.
> The presence of your cellular phone in the network is detected
> automatically.
>
> What availability offers is a layer over presence where the subscriber
> describes preferences on how to expose presence. Preference rules to
> compute availability can be as simple as opt-in or out to publication of
> presence as in current IM systems to extremely to extremely sophisticated
> rules where the user can decide how to expose the information based on
> who is requesting the information, the time of the request,
> the location of the requester and the user, etc. - the bookie example is
> one this more complicated examples.
>
> In the case of PAM there is a minimal set of controls that a presence
> server should provide as an implementation of availability, but it is
> left open to the different implementations how sophisticated the
> computation of availability can be.
>
> A similar approach here may solve many of your problems.
>
> Regards,
>
> Jorge.
>
> ------------------------
> Jorge Lobo, Ph.D.
> Principal Architect
> Teltier Technologies
> 60 Walnut Avenue, #300
> Clark, NJ 07066
> mailto:jorge@teltier.com
> ------------------------

_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple




_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Thu Apr 11 09:47:08 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27178
	for <simple-archive@odin.ietf.org>; Thu, 11 Apr 2002 09:47:07 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3BDf9Pe027437;
	Thu, 11 Apr 2002 09:41:09 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13446;
	Thu, 11 Apr 2002 09:43:03 -0400 (EDT)
Received: from david.siemens.de (david.siemens.de [192.35.17.14])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA11613
	for <simple@mailman.dynamicsoft.com>; Wed, 10 Apr 2002 22:44:38 -0400 (EDT)
Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14])
	by david.siemens.de (8.11.6/8.11.6) with ESMTP id g3B2hdd19151
	for <simple@mailman.dynamicsoft.com>; Thu, 11 Apr 2002 04:43:39 +0200 (MET DST)
Received: from hvrz00da.hvr.siemens.de (hvrz00da.hvr.siemens.de [129.103.192.197])
	by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id g3B2hdn09655
	for <simple@mailman.dynamicsoft.com>; Thu, 11 Apr 2002 04:43:39 +0200 (MEST)
Received: by hvrz00da.hvr.siemens.de with Internet Mail Service (5.5.2653.19)
	id <2QC93XLM>; Thu, 11 Apr 2002 04:43:39 +0200
Message-ID: <F56AAADD3A90D311A0220090275CCDE202AEFAF5@hvrz00da.hvr.siemens.de>
From: BECKMANN MARK <mark.beckmann@sal.siemens.de>
To: simple@mailman.dynamicsoft.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Simple] Presence data format extension
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Thu, 11 Apr 2002 04:43:33 +0200

Hello,

this may be rather a question to the impp WG, but hopefully someone on this
list can also help me, so that I dont have to subscribe to yet another
list;). 

I would like to know if my understanding is correct that basically each
implementor is free to develop his/her own presence data format extension in
particular additional value types and that the extensions are then just
identified by a unique xmlns without having to register the new status value
types and/or create a new RFC to describe those extensions.

Now, if my understanding is correct I wonder whether it is necessary to
define any status values beyond a very limited set at all. The schema
attribute allows each recipient of presence data to find out about the data
format. The limited set of specified status values would allow
interoperability without having to check the data format or semantic
description. For any status information beyond that, interoperability is
achieved by providing information about the data format in the schema
attribute. Of course it is then still open how a user will find out about
the meaning of the status values. Couldn't an additional link pointing to
the semantic description of the extensions solve this problem? 

Thanks,

Mark

Mark Beckmann			Siemens AG

ICM MP PO8 SA 82
P.O.Box 100702			phone: +49 (5341) 906 1814
D-38228 Salzgitter   		fax:   +49 (5341) 906 2010

mailto: Mark.Beckmann@siemens.com


_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Thu Apr 11 16:00:34 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12120
	for <simple-archive@odin.ietf.org>; Thu, 11 Apr 2002 16:00:30 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3BJtsPe001848;
	Thu, 11 Apr 2002 15:55:54 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14658;
	Thu, 11 Apr 2002 15:59:04 -0400 (EDT)
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14647
	for <simple@mailman.dynamicsoft.com>; Thu, 11 Apr 2002 15:58:44 -0400 (EDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3BJvh415774
	for <simple@mailman.dynamicsoft.com>; Thu, 11 Apr 2002 14:57:43 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2JXVMV39>; Thu, 11 Apr 2002 14:57:49 -0500
Message-ID: <EF1056F8EB4ED511B8FB0002A56079D401E5B002@zrc2c014.us.nortel.com>
From: "Sriram Parameswar"<sriramp@nortelnetworks.com>
To: simple@mailman.dynamicsoft.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1E193.2489FE70"
Subject: [Simple] draft-ietf-simple-presence-06 WGLC comments
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Thu, 11 Apr 2002 14:57:43 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1E193.2489FE70
Content-Type: text/plain;
	charset="iso-8859-1"

Hi All,

The draft looks good. My comments/questions are as follows:
*	Section 4 - "In fact, behavior of the presence agent for handing a
SUBSCRIBE with Expires of zero is no different than for any other expiration
value; all SUBSCRIBE requests result in a triggered NOTIFY with the current
presentity and subscription state". My question is on a presence 'fetch' -
what happens if a SUBSCRIBE is not authorized so the first NOTIFY contains
either 'bogus' presence information or no body - if an automaton then
performs an authorization (using some mechanism) and sends another NOTIFY
with actual presence information - is this valid? Either way (valid or not
valid) it would be good to have a line of clarification on how Presence
fetches in the un-authorized case are handled.
*	RFC 2119 key words (MUST, SHOULD etc.) lack a space after them in
sections - 7.2, 9.2, 9.5.

Thanks,

Sriram

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-684-3986
Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com


------_=_NextPart_001_01C1E193.2489FE70
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>draft-ietf-simple-presence-06 WGLC comments</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi All,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The draft looks good. My =
comments/questions are as follows:</FONT>

<UL><LI><FONT SIZE=3D2 FACE=3D"Arial">Section 4 - &quot;</FONT><FONT =
FACE=3D"Times New Roman">In fact, behavior of the presence agent for =
handing a SUBSCRIBE with Expires of zero is no different than for any =
other expiration value; all SUBSCRIBE requests result in a triggered =
NOTIFY with the current presentity and subscription =
state&quot;.</FONT><FONT SIZE=3D2 FACE=3D"Arial"> My question is on a =
presence 'fetch' - what happens if a SUBSCRIBE is not authorized so the =
first NOTIFY contains either 'bogus' presence information or no body - =
if an automaton then performs an authorization (using some mechanism) =
and sends another NOTIFY with actual presence information - is this =
valid? Either way (valid or not valid) it would be good to have a line =
of clarification on how Presence fetches in the un-authorized case are =
handled.</FONT></LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">RFC 2119 key words (MUST, SHOULD =
etc.) lack a space after them in sections - 7.2, 9.2, 9.5.</FONT></LI>
<BR>
</UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Sriram</FONT>
</P>

<P><B><FONT SIZE=3D2 FACE=3D"Comic Sans =
MS">__________________________________________</FONT></B>
<BR><B><FONT SIZE=3D2 FACE=3D"Comic Sans MS">Sriram =
Parameswar&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D2 FACE=3D"Arial">Phone: =
972-685-8540</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Interactive Multimedia Server (IMS) =
Fax: 972-684-3986</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Nortel Networks, Richardson =
USA&nbsp;</FONT> <FONT SIZE=3D2 FACE=3D"Arial Narrow">Email: =
sriramp@nortelnetworks.com</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1E193.2489FE70--
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Thu Apr 11 18:14:20 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16928
	for <simple-archive@odin.ietf.org>; Thu, 11 Apr 2002 18:14:19 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3BM9uPe003455;
	Thu, 11 Apr 2002 18:09:56 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA15101;
	Thu, 11 Apr 2002 18:13:04 -0400 (EDT)
Received: from teltier.com (teltier.com [161.58.154.42])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA15090
	for <simple@mailman.dynamicsoft.com>; Thu, 11 Apr 2002 18:12:20 -0400 (EDT)
Received: from GUERNICA (fwuser@[65.202.44.138]) by teltier.com (8.11.6) id g3BMArf29294; Thu, 11 Apr 2002 18:10:53 -0400 (EDT)
Reply-To: <jorge@teltier.com>
From: "Jorge Lobo" <jorge@teltier.com>
To: "Li Hua Tang" <tanglih@cn.ibm.com>
Cc: <simple@mailman.dynamicsoft.com>
Subject: RE: [Simple] RE: State labels (Was: notes from the SIMPLE components adhoc at IETF53)
Message-ID: <PAEMLHBKBFEKFKBDBLNGGECOCJAA.jorge@teltier.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <OF0DEC05BF.90C3BA86-ON48256B98.00090F08@cn.ibm.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Thu, 11 Apr 2002 18:04:48 -0400
Content-Transfer-Encoding: 7bit


Dear Tang Lihua,

authentication is done in a different place through a framework. PAM, as
specified by the PAMForum, has a simple authentication framework, but
inside Parley and 3GPP, the framework works across all the services
provided by them. Usually after authenticating with the framework a
token is returned to the requester and it is used in every API call.
The framework is also used to discover services such as PAM.  Other
services are call control, billing, etc.

Jorge.
-----Original Message-----
From: Li Hua Tang [mailto:tanglih@cn.ibm.com]
Sent: Wednesday, April 10, 2002 9:47 PM
To: jorge@teltier.com
Cc: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] RE: State labels (Was: notes from the SIMPLE
components adhoc at IETF53)



Jorge,

Tell the truth I am little confused by the concepts you mentioned,
presence, availability and capability in PAM world. Could you please give
me a scenario in the real world?

And how to control the different access to presence and availability? Has
authorization and authentication been considered in PAM?


Best regards,

Tang Lihua




                    "Jorge Lobo"
                    <jorge@teltier.com>              To:     "Paul Kyzivat"
<pkyzivat@cisco.com>
                    Sent by:                         cc:
<hgs@cs.columbia.edu>,
                    simple-admin@mailman.dynam
<simple@mailman.dynamicsoft.com>
                    icsoft.com                       Subject:     [Simple]
RE: State labels (Was: notes
                                                      from the SIMPLE
components adhoc at IETF53)

                    2002-04-11 07:53
                    Please respond to jorge






A quick mapping from some of the concepts of PAM to SIMPLE.

PAM is based on Identities, and Identities have Agents
associated with them.  Agents are electronic representations
                 --------
               >>Indentities here?
of (software or hardware) devices. Agents are the producers
of "raw" presence, and the presence of an Identity is derived
from the devices the Identity owns.

Identities  ---> Presentities
Agents      ---> Presence User Agent

Some applications may have direct access to presence but most
applications will be allowed only access to availability.

The basic API calls from PAM relevant to SIMPLE are

set and get presence

set and get preferences

get availability

One more thing.  There is a special class of presence data associated
with agents in PAM called capabilities - given that the capabilities of
an agent (Presence User Agent) can vary with time. For example, a
capability
can be J2ME-cable, an attribute of the capability can be
communicationAddress
which can be a dynamic IP address assigned to the agent for communication.

Best,

Jorge.

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent: Wednesday, April 10, 2002 7:12 PM
To: jorge@teltier.com
Cc: hgs@cs.columbia.edu; simple@mailman.dynamicsoft.com
Subject: Re: State labels (Was: notes from the SIMPLE components adhoc
at IETF53)


Jorge,

I just took a quick look at the PAM specification.

While it would take a much longer look to fully understand the mappings, I
agree that there does seem to be some commonality here.

           Paul

Jorge Lobo wrote:
>
> Paul and Henning,
>
> I have been following your discussion on call preferences and
> presence and I would like to offer an alternative view.
>
> I have been working with PAM, the presence and availability
> management standards being adopted by Parley and 3GPP,
> (http://www.PAMForum.org).
>
> In PAM there is a separation between "presence" and "availability".
> Presence, as mention by Henning, in the IM world is set by the
> user, but in many cases can be and will be automatically detected.
> The presence of your cellular phone in the network is detected
> automatically.
>
> What availability offers is a layer over presence where the subscriber
> describes preferences on how to expose presence. Preference rules to
> compute availability can be as simple as opt-in or out to publication of
> presence as in current IM systems to extremely to extremely sophisticated
> rules where the user can decide how to expose the information based on
> who is requesting the information, the time of the request,
> the location of the requester and the user, etc. - the bookie example is
> one this more complicated examples.
>
> In the case of PAM there is a minimal set of controls that a presence
> server should provide as an implementation of availability, but it is
> left open to the different implementations how sophisticated the
> computation of availability can be.
>
> A similar approach here may solve many of your problems.
>
> Regards,
>
> Jorge.
>
> ------------------------
> Jorge Lobo, Ph.D.
> Principal Architect
> Teltier Technologies
> 60 Walnut Avenue, #300
> Clark, NJ 07066
> mailto:jorge@teltier.com
> ------------------------

_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple





_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Fri Apr 12 06:18:49 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01661
	for <simple-archive@odin.ietf.org>; Fri, 12 Apr 2002 06:18:49 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3CAEnPe005799;
	Fri, 12 Apr 2002 06:14:50 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16992;
	Fri, 12 Apr 2002 06:18:04 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16981
	for <simple@mailman.dynamicsoft.com>; Fri, 12 Apr 2002 06:17:29 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3CAGj514549
	for <simple@mailman.dynamicsoft.com>; Fri, 12 Apr 2002 13:16:45 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5a36bca2cdac158f2313d@esvir03nok.nokia.com>;
 Fri, 12 Apr 2002 13:16:28 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Fri, 12 Apr 2002 13:16:28 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 12 Apr 2002 13:16:28 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB777912D@esebe019.NOE.Nokia.com>
Thread-Topic: Comments on presence-06
Thread-Index: AcHiCxtmToYAyeNoTr+N6u5Zk0ydkw==
To: <simple@mailman.dynamicsoft.com>, <jdrosen@dynamicsoft.com>
X-OriginalArrivalTime: 12 Apr 2002 10:16:28.0290 (UTC) FILETIME=[1BDA6620:01C1E20B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id GAA16981
Subject: [Simple] Comments on presence-06
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Fri, 12 Apr 2002 13:16:27 +0300
Content-Transfer-Encoding: 8bit

I hope this is not too late.


3. Definitions

In a normal interpretation on client and server, a client requests and a server responds. They perform opposite tasks.

This leads to the confusion in understanding definitions of Presence Client and Presence Server. In this specification, they do the same thing and that is to respond to SUBSCRIBE requests and generate NOTIFY requests.

I understand that they share the common name of Presence Agent, but calling them Presence Client and Server does not make sense to me. My suggestion would be to keep Presence Server as is and change Presence Client to something like Presence Edge Server (or something similar to highlight the fact that it is the end point).

Presence Client definition is not used in the description through out the document. Section 6.11 hardly uses it when talking about migrations.

4. Overview of Operation

Third paragraph states 

  "If authorization could not be obtained at this
   time, the subscription is considered "pending", and a 202 response is
   returned. "

then

  "As the state of the presentity changes, the PA
   generates NOTIFYs for all subscribers with authorized subscriptions.
   The state of the subscription itself is carried in the Subscription-
   State header of the NOTIFY, and would typically indicate whether the
   subscription is active or pending."

Now, if NOTIFYs are generated, as a result of a change in state of presentity, to authorised subscribers only, why would you ever send an state update NOTIFY with subscription-state of pending. If the last sentence was not talking about NOTIFY updates, it should be split from the sentence above it.


5. Usage of Presence URLs
If the protocol-independent form is used in the R-URI, how do you know where the next hop is? do you still apply procedures in sip-srv draft on the pres url?


6.3
"The body of a SUBSCRIBE request MAY contain a body" should say "A SUBSCRIBE request MAY contain a body"

6.6.2
Third paragraph

  "For pending subscriptions, the
   state of the presentity SHOULD include some kind of textual note that
   indicates a pending status."

Why is that necessary to merit a SHOULD? It sounds like redundant info to me. Subscription-state header carries that info already.

6.11
- "On occasion" should be "On occasions".

- paragraph 4 states 
  "However, just because a PUA indicates it can accept
   subscriptions, does not mean a PA should migrate the subscriptions
   there."

Why not? I thought this was the dynamic means defining the condition of the migration to take place in this package.


9.5 and 9.6.1 is full of missed spaces. eg. "SUBSCRIBEand"


13.
Reference 3 should be "Common Presence and Instant Messaging (CPIM)"



General comment:
- Fetch of presence info is not mentioned at all in the document. Is the intentional?


That's all I have.

Regards,
Hisham Khartabil
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Fri Apr 12 07:13:07 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07652
	for <simple-archive@odin.ietf.org>; Fri, 12 Apr 2002 07:13:06 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3CB8iPe005968;
	Fri, 12 Apr 2002 07:08:44 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17201;
	Fri, 12 Apr 2002 07:12:03 -0400 (EDT)
Received: from imailg1.svr.pol.co.uk (imailg1.svr.pol.co.uk [195.92.195.179])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17190
	for <simple@mailman.dynamicsoft.com>; Fri, 12 Apr 2002 07:11:44 -0400 (EDT)
Received: from [195.92.168.141] (helo=tmailb1.svr.pol.co.uk)
	by imailg1.svr.pol.co.uk with esmtp (Exim 3.35 #1)
	id 16vyx2-0007dG-00; Fri, 12 Apr 2002 12:10:44 +0100
Received: from modem-3747.porcupine.dialup.pol.co.uk ([217.134.206.163] helo=ADRIANXP)
	by tmailb1.svr.pol.co.uk with esmtp (Exim 3.35 #1)
	id 16vyx1-0005If-00; Fri, 12 Apr 2002 12:10:43 +0100
Reply-To: <bateman@acm.org>
From: "Adrian Bateman" <bateman@acm.org>
To: "'BECKMANN MARK'" <mark.beckmann@sal.siemens.de>,
        <simple@mailman.dynamicsoft.com>
Subject: RE: [Simple] Presence data format extension
Organization: VisionTech Limited
Message-ID: <000601c1e212$86102be0$6405010a@ADRIANXP>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <F56AAADD3A90D311A0220090275CCDE202AEFAF5@hvrz00da.hvr.siemens.de>
Importance: Normal
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Fri, 12 Apr 2002 12:09:22 +0100
Content-Transfer-Encoding: 7bit

On 11 April 2002 03:43, BECKMANN MARK wrote:
> Hello,
> 
> this may be rather a question to the impp WG, but hopefully someone on
this
> list can also help me, so that I dont have to subscribe to yet another
> list;). 
> 
> I would like to know if my understanding is correct that basically
each
> implementor is free to develop his/her own presence data format
extension in
> particular additional value types and that the extensions are then
just
> identified by a unique xmlns without having to register the new status
value
> types and/or create a new RFC to describe those extensions.

Well, yes, anyone can create a new extension to the presence data format
using xmlns and abiding by the extensibility mechanism described in the
draft. As far as status values are concerned, we're just working up a
more refined solution to that in the published draft (in fact, we'd
welcome comments from anyone on the recent discussion - you can get to
the mailing list archives from http://www.imppwg.org/), but you can
provide different status value ranges too.

> Now, if my understanding is correct I wonder whether it is necessary
to
> define any status values beyond a very limited set at all. The schema
> attribute allows each recipient of presence data to find out about the
data
> format. The limited set of specified status values would allow
> interoperability without having to check the data format or semantic
> description. For any status information beyond that, interoperability
is
> achieved by providing information about the data format in the schema
> attribute. Of course it is then still open how a user will find out
about
> the meaning of the status values. Couldn't an additional link pointing
to
> the semantic description of the extensions solve this problem? 

In terms of interop, I fully expect there to be standard extensions
published. In fact, while we only deal with the RFC 2778 terms OPEN and
CLOSED directly, I think a set of standard IM status values is essential
including the usual things like "busy" and "away". We didn't want to
hold up the already tortuously slow process of producing the IMPP
presence draft by trying to get agreement on this, which is why it will
be an extension. It will be important for different user agents which
might use different protocols on opposite sides of a CPIM gateway to
have agreed on the meaning of the status values.

I've seen it mentioned that this might be a possible work item for this
group. I expect the discussion would be a bit of a religious debate
including things like "do we need busy and do-not-disturb, are these the
same thing, and if they are, which do we use" but it will have to be
done in the end.

Regards,

Adrian.


_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Sun Apr 14 10:59:51 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18656
	for <simple-archive@odin.ietf.org>; Sun, 14 Apr 2002 10:59:51 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3EEtrPe015352;
	Sun, 14 Apr 2002 10:55:53 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25227;
	Sun, 14 Apr 2002 10:59:07 -0400 (EDT)
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25216
	for <simple@mailman.dynamicsoft.com>; Sun, 14 Apr 2002 10:58:51 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id QAA38662
	for <simple@mailman.dynamicsoft.com>; Sun, 14 Apr 2002 16:57:49 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3EEvnU32486
	for <simple@mailman.dynamicsoft.com>; Sun, 14 Apr 2002 16:57:49 +0200
To: simple@mailman.dynamicsoft.com
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFDC05ACB4.FE68820E-ONC2256B8E.0038964B@telaviv.ibm.com>
From: "Avshalom Houri" <AVSHALOM@il.ibm.com>
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at
 14/04/2002 17:57:48,
	Serialize complete at 14/04/2002 17:57:48
Content-Type: multipart/alternative; boundary="=_alternative 00522F2AC2256B9B_="
Subject: [Simple] Status summary
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Sun, 14 Apr 2002 17:57:42 +0300

This is a multipart message in MIME format.
--=_alternative 00522F2AC2256B9B_=
Content-Type: text/plain; charset="us-ascii"

In the SIMPLE components adhoc meeting at IETF53, I have volunteered to 
summarize the various statuses used in various systems. The summary is 
below.

While going over the various statuses it occurred to me that we need a 
more 
precise definition of what we mean when we say status. The various status 
values 
in the various systems can be divided into:

* Mood - Happy, Sad etc.

* Hint - I am on the phone therefore I will probably not be able to 
respond 
  immediately. The way that the my client will display the message to me 
e.g.
  in Away mode some clients will display the message in a different way 
from
  the way they do in normal online mode. 

* Availability - Am I open or close to communication. The availability can 
be 
  simple just open or close or quite complex - I am open to communication 
  depending on who is calling and in which location am I.

While moods and hints can be localized to vendors and clients, it seems 
that 
availability is the part of the status that mostly needs standardization.

The summary:
===========

# AOL - No explicit status - only idle indication by sensing mouse and 
keyboard activity.

# MSN - Open and close statuses + hints
        * Online (OPEN)
        * Busy (CLOSED)
        * Be Right Back (OPEN)
        * Away (OPEN)
        * On the Phone (CLOSED)
        * Out to Lunch (OPEN)
        * Appear Offline (Lurking, CLOSED)

# YAHOO - Open and close + hints for open.
        * Offline (CLOSED)
        * Available (OPEN) 
        * Busy with various messages (configurable) e.g. Be Right Back, Busy 
          etc. (OPEN) 
        * Invisible (Lurking can be done only in login time) 

# ICQ - Open and close statuses. Open statuses are accompanied by hints. 
For 
  example if I am in DND, I will still get messages but the messages will 
not be 
  displayed on my screen.
        Simple Mode
                * Available
                * Away (OPEN, Messages are shown on the screen)
                * Offline
        Advanced Mode
                * Available
                * Free for chat
                * Away
                * N/A (Extended Away)
                * Occupied (Urgent messages)
                * DND (Do Not Disturb)
                * Privacy (Invisible) - Lurking
                * Offline

# Louts Sametime - Open and close + strong DND. Strong DND means that I am 
not 
  able to send a message to a person that is in DND mode
        * Active (OPEN)
        * DND (Online but closed)
        * Away (OPEN, an hint)

# Wireless Village - As defined by the spec status is composed from 
several 
  attributes as: availability, preferred contacts etc. Following is a 
complete 
  list. 
        * User availability
                - AVAILABLE
                - NOT_AVAILABLE
                - DISCREET (selectively available. Likd DND or busy in other systems)
         
        * Preferred Contacts (preferred contact method of the user + address of 
          contact)
                - CALL
                - SMS
                - MMS (Multi Media SMS)
                - IM
                - EMAIL
        * Preferred Language
        * Status Text (free text describing the status)
        * Status Mood (e.g. HAPPY, SAD, etc.)
        * Alias (alias name for the user)
        * Status Content - MMS content or URL to the MMS content that the user 
          has selected as personal status information.
        * Contact Info - Contact information (vCard)

# PAM Forum - As described in a previous message Jorge Lobo" 
  <jorge@teltier.com>. PAM forum has separate layers of presence 
information and 
  availability. Availability can be computed by a very simple methods or 
by very 
  complex conditions as if the message is from X try to get me on any 
available 
  device that I am on if not, leave a message on my desktop.

Avshalom Houri
Presence and Instant Messaging Architect
Lotus Sametime, IBM Software Group
avshalom@il.ibm.com

--=_alternative 00522F2AC2256B9B_=
Content-Type: text/html; charset="us-ascii"


<br><font size=1 face="sans-serif">In the SIMPLE components adhoc meeting at IETF53, I have volunteered to </font>
<br><font size=1 face="sans-serif">summarize the various statuses used in various systems. The summary is below.</font>
<br>
<br><font size=1 face="sans-serif">While going over the various statuses it occurred to me that we need a more </font>
<br><font size=1 face="sans-serif">precise definition of what we mean when we say status. The various status values </font>
<br><font size=1 face="sans-serif">in the various systems can be divided into:</font>
<br>
<br><font size=1 face="sans-serif">* Mood - Happy, Sad etc.</font>
<br>
<br><font size=1 face="sans-serif">* Hint - I am on the phone therefore I will probably not be able to respond </font>
<br><font size=1 face="sans-serif">&nbsp; immediately. The way that the my client will display the message to me e.g.</font>
<br><font size=1 face="sans-serif">&nbsp; in Away mode some clients will display the message in a different way from</font>
<br><font size=1 face="sans-serif">&nbsp; the way they do in normal online mode. </font>
<br>
<br><font size=1 face="sans-serif">* Availability - Am I open or close to communication. The availability can be </font>
<br><font size=1 face="sans-serif">&nbsp; simple just open or close or quite complex - I am open to communication </font>
<br><font size=1 face="sans-serif">&nbsp; depending on who is calling and in which location am I.</font>
<br>
<br><font size=1 face="sans-serif">While moods and hints can be localized to vendors and clients, it seems that </font>
<br><font size=1 face="sans-serif">availability is the part of the status that mostly needs standardization.</font>
<br>
<br><font size=1 face="sans-serif">The summary:</font>
<br><font size=1 face="sans-serif">===========</font>
<br>
<br><font size=1 face="sans-serif"># AOL - No explicit status - only idle indication by sensing mouse and keyboard activity.</font>
<br>
<br><font size=1 face="sans-serif"># MSN - Open and close statuses + hints</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; * Online (OPEN)</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; * Busy (CLOSED)</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; * Be Right Back (OPEN)</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; * Away (OPEN)</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; * On the Phone (CLOSED)</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; * Out to Lunch (OPEN)</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; * Appear Offline (Lurking, CLOSED)</font>
<br>
<br><font size=1 face="sans-serif"># YAHOO - Open and close + hints for open.</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; * Offline (CLOSED)</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; * Available (OPEN) &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; * Busy with various messages (configurable) e.g. Be Right Back, Busy </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; etc. (OPEN) &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; * Invisible (Lurking can be done only in login time) </font>
<br>
<br><font size=1 face="sans-serif"># ICQ - Open and close statuses. Open statuses are accompanied by hints. For </font>
<br><font size=1 face="sans-serif">&nbsp; example if I am in DND, I will still get messages but the messages will not be </font>
<br><font size=1 face="sans-serif">&nbsp; displayed on my screen.</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Simple Mode</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; * Available</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; * Away (OPEN, Messages are shown on the screen)</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; * Offline</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Advanced Mode</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; * Available</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; * Free for chat</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; * Away</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; * N/A (Extended Away)</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; * Occupied (Urgent messages)</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; * DND (Do Not Disturb)</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; * Privacy (Invisible) - Lurking</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; * Offline</font>
<br>
<br><font size=1 face="sans-serif"># Louts Sametime - Open and close + strong DND. Strong DND means that I am not </font>
<br><font size=1 face="sans-serif">&nbsp; able to send a message to a person that is in DND mode</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; * Active (OPEN)</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; * DND (Online but closed)</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; * Away (OPEN, an hint)</font>
<br>
<br><font size=1 face="sans-serif"># Wireless Village - As defined by the spec status is composed from several </font>
<br><font size=1 face="sans-serif">&nbsp; attributes as: availability, preferred contacts etc. Following is a complete </font>
<br><font size=1 face="sans-serif">&nbsp; list. &nbsp;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; * User availability</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; - AVAILABLE</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; - NOT_AVAILABLE</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; - DISCREET (selectively available. Likd DND or busy in other systems)</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; * Preferred Contacts (preferred contact method of the user + address of </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; contact)</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; - CALL</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; - SMS</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; - MMS (Multi Media SMS)</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; - IM</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; - EMAIL</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; * Preferred Language</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; * Status Text (free text describing the status)</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; * Status Mood (e.g. HAPPY, SAD, etc.)</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; * Alias (alias name for the user)</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; * Status Content - MMS content or URL to the MMS content that the user </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; has selected as personal status information.</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; * Contact Info - Contact information (vCard)</font>
<br>
<br><font size=1 face="sans-serif"># PAM Forum - As described in a previous message Jorge Lobo&quot; </font>
<br><font size=1 face="sans-serif">&nbsp; &lt;jorge@teltier.com&gt;. PAM forum has separate layers of presence information and </font>
<br><font size=1 face="sans-serif">&nbsp; availability. Availability can be computed by a very simple methods or by very </font>
<br><font size=1 face="sans-serif">&nbsp; complex conditions as if the message is from X try to get me on any available </font>
<br><font size=1 face="sans-serif">&nbsp; device that I am on if not, leave a message on my desktop.</font>
<br>
<br><font size=1 face="sans-serif">Avshalom Houri</font>
<br><font size=1 face="sans-serif">Presence and Instant Messaging Architect</font>
<br><font size=1 face="sans-serif">Lotus Sametime, IBM Software Group</font>
<br><font size=1 face="sans-serif">avshalom@il.ibm.com</font>
<br>
--=_alternative 00522F2AC2256B9B_=--
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Sun Apr 14 14:38:10 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21209
	for <simple-archive@odin.ietf.org>; Sun, 14 Apr 2002 14:38:09 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3EIYhPe015738;
	Sun, 14 Apr 2002 14:34:43 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25899;
	Sun, 14 Apr 2002 14:38:04 -0400 (EDT)
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25888
	for <simple@mailman.dynamicsoft.com>; Sun, 14 Apr 2002 14:37:54 -0400 (EDT)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g3EIaeX62727;
	Sun, 14 Apr 2002 13:36:41 -0500 (CDT)
From: "Ben Campbell" <bcampbell@dynamicsoft.com>
To: "Avshalom Houri" <AVSHALOM@il.ibm.com>, <simple@mailman.dynamicsoft.com>
Subject: RE: [Simple] Status summary
Message-ID: <HNEOJECGFHIABDLENMMCMELGCFAA.bcampbell@dynamicsoft.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001F_01C1E3B9.5D33B810"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-reply-to: <OFDC05ACB4.FE68820E-ONC2256B8E.0038964B@telaviv.ibm.com>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Sun, 14 Apr 2002 13:36:21 -0500

This is a multi-part message in MIME format.

------=_NextPart_000_001F_01C1E3B9.5D33B810
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I cannot speak for the other systems, but Yahoo Messenger allows you to
select open or closed when you create a user configurable message. Also, you
can  become invisible (i.e. lurk) at any time, not just at login.
  -----Original Message-----
  From: simple-admin@mailman.dynamicsoft.com
[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Avshalom Houri
  Sent: Sunday, April 14, 2002 9:58 AM
  To: simple@mailman.dynamicsoft.com
  Subject: [Simple] Status summary



  In the SIMPLE components adhoc meeting at IETF53, I have volunteered to
  summarize the various statuses used in various systems. The summary is
below.

  While going over the various statuses it occurred to me that we need a
more
  precise definition of what we mean when we say status. The various status
values
  in the various systems can be divided into:

  * Mood - Happy, Sad etc.

  * Hint - I am on the phone therefore I will probably not be able to
respond
    immediately. The way that the my client will display the message to me
e.g.
    in Away mode some clients will display the message in a different way
from
    the way they do in normal online mode.

  * Availability - Am I open or close to communication. The availability can
be
    simple just open or close or quite complex - I am open to communication
    depending on who is calling and in which location am I.

  While moods and hints can be localized to vendors and clients, it seems
that
  availability is the part of the status that mostly needs standardization.

  The summary:
  ===========

  # AOL - No explicit status - only idle indication by sensing mouse and
keyboard activity.

  # MSN - Open and close statuses + hints
          * Online (OPEN)
          * Busy (CLOSED)
          * Be Right Back (OPEN)
          * Away (OPEN)
          * On the Phone (CLOSED)
          * Out to Lunch (OPEN)
          * Appear Offline (Lurking, CLOSED)

  # YAHOO - Open and close + hints for open.
          * Offline (CLOSED)
          * Available (OPEN)
          * Busy with various messages (configurable) e.g. Be Right Back,
Busy
            etc. (OPEN)
          * Invisible (Lurking can be done only in login time)

  # ICQ - Open and close statuses. Open statuses are accompanied by hints.
For
    example if I am in DND, I will still get messages but the messages will
not be
    displayed on my screen.
          Simple Mode
                  * Available
                  * Away (OPEN, Messages are shown on the screen)
                  * Offline
          Advanced Mode
                  * Available
                  * Free for chat
                  * Away
                  * N/A (Extended Away)
                  * Occupied (Urgent messages)
                  * DND (Do Not Disturb)
                  * Privacy (Invisible) - Lurking
                  * Offline

  # Louts Sametime - Open and close + strong DND. Strong DND means that I am
not
    able to send a message to a person that is in DND mode
          * Active (OPEN)
          * DND (Online but closed)
          * Away (OPEN, an hint)

  # Wireless Village - As defined by the spec status is composed from
several
    attributes as: availability, preferred contacts etc. Following is a
complete
    list.
          * User availability
                  - AVAILABLE
                  - NOT_AVAILABLE
                  - DISCREET (selectively available. Likd DND or busy in
other systems)

          * Preferred Contacts (preferred contact method of the user +
address of
            contact)
                  - CALL
                  - SMS
                  - MMS (Multi Media SMS)
                  - IM
                  - EMAIL
          * Preferred Language
          * Status Text (free text describing the status)
          * Status Mood (e.g. HAPPY, SAD, etc.)
          * Alias (alias name for the user)
          * Status Content - MMS content or URL to the MMS content that the
user
            has selected as personal status information.
          * Contact Info - Contact information (vCard)

  # PAM Forum - As described in a previous message Jorge Lobo"
    <jorge@teltier.com>. PAM forum has separate layers of presence
information and
    availability. Availability can be computed by a very simple methods or
by very
    complex conditions as if the message is from X try to get me on any
available
    device that I am on if not, leave a message on my desktop.

  Avshalom Houri
  Presence and Instant Messaging Architect
  Lotus Sametime, IBM Software Group
  avshalom@il.ibm.com


------=_NextPart_000_001F_01C1E3B9.5D33B810
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2715.400" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D521364017-14042002><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
cannot speak for the other systems, but Yahoo Messenger allows you to =
select=20
open or closed when you create a user configurable message. Also, you =
can&nbsp;=20
become invisible (i.e. lurk) at any time, not just at =
login.</FONT></SPAN></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B>=20
  simple-admin@mailman.dynamicsoft.com=20
  [mailto:simple-admin@mailman.dynamicsoft.com]<B>On Behalf Of =
</B>Avshalom=20
  Houri<BR><B>Sent:</B> Sunday, April 14, 2002 9:58 AM<BR><B>To:</B>=20
  simple@mailman.dynamicsoft.com<BR><B>Subject:</B> [Simple] Status=20
  summary<BR><BR></FONT></DIV><BR><FONT face=3Dsans-serif size=3D1>In =
the SIMPLE=20
  components adhoc meeting at IETF53, I have volunteered to =
</FONT><BR><FONT=20
  face=3Dsans-serif size=3D1>summarize the various statuses used in =
various systems.=20
  The summary is below.</FONT> <BR><BR><FONT face=3Dsans-serif =
size=3D1>While going=20
  over the various statuses it occurred to me that we need a more=20
  </FONT><BR><FONT face=3Dsans-serif size=3D1>precise definition of what =
we mean=20
  when we say status. The various status values </FONT><BR><FONT =
face=3Dsans-serif=20
  size=3D1>in the various systems can be divided into:</FONT> =
<BR><BR><FONT=20
  face=3Dsans-serif size=3D1>* Mood - Happy, Sad etc.</FONT> =
<BR><BR><FONT=20
  face=3Dsans-serif size=3D1>* Hint - I am on the phone therefore I will =
probably=20
  not be able to respond </FONT><BR><FONT face=3Dsans-serif =
size=3D1>&nbsp;=20
  immediately. The way that the my client will display the message to me =

  e.g.</FONT> <BR><FONT face=3Dsans-serif size=3D1>&nbsp; in Away mode =
some clients=20
  will display the message in a different way from</FONT> <BR><FONT=20
  face=3Dsans-serif size=3D1>&nbsp; the way they do in normal online =
mode.=20
  </FONT><BR><BR><FONT face=3Dsans-serif size=3D1>* Availability - Am I =
open or=20
  close to communication. The availability can be </FONT><BR><FONT=20
  face=3Dsans-serif size=3D1>&nbsp; simple just open or close or quite =
complex - I=20
  am open to communication </FONT><BR><FONT face=3Dsans-serif =
size=3D1>&nbsp;=20
  depending on who is calling and in which location am I.</FONT> =
<BR><BR><FONT=20
  face=3Dsans-serif size=3D1>While moods and hints can be localized to =
vendors and=20
  clients, it seems that </FONT><BR><FONT face=3Dsans-serif =
size=3D1>availability is=20
  the part of the status that mostly needs standardization.</FONT> =
<BR><BR><FONT=20
  face=3Dsans-serif size=3D1>The summary:</FONT> <BR><FONT =
face=3Dsans-serif=20
  size=3D1>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT> <BR><BR><FONT =
face=3Dsans-serif size=3D1># AOL - No=20
  explicit status - only idle indication by sensing mouse and keyboard=20
  activity.</FONT> <BR><BR><FONT face=3Dsans-serif size=3D1># MSN - Open =
and close=20
  statuses + hints</FONT> <BR><FONT face=3Dsans-serif size=3D1>&nbsp; =
&nbsp; &nbsp;=20
  &nbsp; * Online (OPEN)</FONT> <BR><FONT face=3Dsans-serif =
size=3D1>&nbsp; &nbsp;=20
  &nbsp; &nbsp; * Busy (CLOSED)</FONT> <BR><FONT face=3Dsans-serif =
size=3D1>&nbsp;=20
  &nbsp; &nbsp; &nbsp; * Be Right Back (OPEN)</FONT> <BR><FONT =
face=3Dsans-serif=20
  size=3D1>&nbsp; &nbsp; &nbsp; &nbsp; * Away (OPEN)</FONT> <BR><FONT=20
  face=3Dsans-serif size=3D1>&nbsp; &nbsp; &nbsp; &nbsp; * On the Phone=20
  (CLOSED)</FONT> <BR><FONT face=3Dsans-serif size=3D1>&nbsp; &nbsp; =
&nbsp; &nbsp; *=20
  Out to Lunch (OPEN)</FONT> <BR><FONT face=3Dsans-serif size=3D1>&nbsp; =
&nbsp;=20
  &nbsp; &nbsp; * Appear Offline (Lurking, CLOSED)</FONT> <BR><BR><FONT=20
  face=3Dsans-serif size=3D1># YAHOO - Open and close + hints for =
open.</FONT>=20
  <BR><FONT face=3Dsans-serif size=3D1>&nbsp; &nbsp; &nbsp; &nbsp; * =
Offline=20
  (CLOSED)</FONT> <BR><FONT face=3Dsans-serif size=3D1>&nbsp; &nbsp; =
&nbsp; &nbsp; *=20
  Available (OPEN) &nbsp; &nbsp; &nbsp; &nbsp;</FONT> <BR><FONT =
face=3Dsans-serif=20
  size=3D1>&nbsp; &nbsp; &nbsp; &nbsp; * Busy with various messages =
(configurable)=20
  e.g. Be Right Back, Busy </FONT><BR><FONT face=3Dsans-serif =
size=3D1>&nbsp; &nbsp;=20
  &nbsp; &nbsp; &nbsp; etc. (OPEN) &nbsp; &nbsp; &nbsp; &nbsp;</FONT> =
<BR><FONT=20
  face=3Dsans-serif size=3D1>&nbsp; &nbsp; &nbsp; &nbsp; * Invisible =
(Lurking can be=20
  done only in login time) </FONT><BR><BR><FONT face=3Dsans-serif =
size=3D1># ICQ -=20
  Open and close statuses. Open statuses are accompanied by hints. For=20
  </FONT><BR><FONT face=3Dsans-serif size=3D1>&nbsp; example if I am in =
DND, I will=20
  still get messages but the messages will not be </FONT><BR><FONT=20
  face=3Dsans-serif size=3D1>&nbsp; displayed on my screen.</FONT> =
<BR><FONT=20
  face=3Dsans-serif size=3D1>&nbsp; &nbsp; &nbsp; &nbsp; Simple =
Mode</FONT>=20
  <BR><FONT face=3Dsans-serif size=3D1>&nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;=20
  &nbsp; &nbsp; * Available</FONT> <BR><FONT face=3Dsans-serif =
size=3D1>&nbsp;=20
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; * Away (OPEN, =
Messages are=20
  shown on the screen)</FONT> <BR><FONT face=3Dsans-serif =
size=3D1>&nbsp; &nbsp;=20
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; * Offline</FONT> <BR><FONT=20
  face=3Dsans-serif size=3D1>&nbsp; &nbsp; &nbsp; &nbsp; Advanced =
Mode</FONT>=20
  <BR><FONT face=3Dsans-serif size=3D1>&nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;=20
  &nbsp; &nbsp; * Available</FONT> <BR><FONT face=3Dsans-serif =
size=3D1>&nbsp;=20
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; * Free for =
chat</FONT>=20
  <BR><FONT face=3Dsans-serif size=3D1>&nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;=20
  &nbsp; &nbsp; * Away</FONT> <BR><FONT face=3Dsans-serif =
size=3D1>&nbsp; &nbsp;=20
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; * N/A (Extended Away)</FONT> =

  <BR><FONT face=3Dsans-serif size=3D1>&nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;=20
  &nbsp; &nbsp; * Occupied (Urgent messages)</FONT> <BR><FONT =
face=3Dsans-serif=20
  size=3D1>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; * DND =
(Do Not=20
  Disturb)</FONT> <BR><FONT face=3Dsans-serif size=3D1>&nbsp; &nbsp; =
&nbsp; &nbsp;=20
  &nbsp; &nbsp; &nbsp; &nbsp; * Privacy (Invisible) - Lurking</FONT> =
<BR><FONT=20
  face=3Dsans-serif size=3D1>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;=20
  * Offline</FONT> <BR><BR><FONT face=3Dsans-serif size=3D1># Louts =
Sametime - Open=20
  and close + strong DND. Strong DND means that I am not =
</FONT><BR><FONT=20
  face=3Dsans-serif size=3D1>&nbsp; able to send a message to a person =
that is in=20
  DND mode</FONT> <BR><FONT face=3Dsans-serif size=3D1>&nbsp; &nbsp; =
&nbsp; &nbsp; *=20
  Active (OPEN)</FONT> <BR><FONT face=3Dsans-serif size=3D1>&nbsp; =
&nbsp; &nbsp;=20
  &nbsp; * DND (Online but closed)</FONT> <BR><FONT face=3Dsans-serif=20
  size=3D1>&nbsp; &nbsp; &nbsp; &nbsp; * Away (OPEN, an hint)</FONT> =
<BR><BR><FONT=20
  face=3Dsans-serif size=3D1># Wireless Village - As defined by the spec =
status is=20
  composed from several </FONT><BR><FONT face=3Dsans-serif =
size=3D1>&nbsp;=20
  attributes as: availability, preferred contacts etc. Following is a =
complete=20
  </FONT><BR><FONT face=3Dsans-serif size=3D1>&nbsp; list. &nbsp;</FONT> =
<BR><FONT=20
  face=3Dsans-serif size=3D1>&nbsp; &nbsp; &nbsp; &nbsp; * User =
availability</FONT>=20
  <BR><FONT face=3Dsans-serif size=3D1>&nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;=20
  &nbsp; &nbsp; - AVAILABLE</FONT> <BR><FONT face=3Dsans-serif =
size=3D1>&nbsp;=20
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; - =
NOT_AVAILABLE</FONT>=20
  <BR><FONT face=3Dsans-serif size=3D1>&nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;=20
  &nbsp; &nbsp; - DISCREET (selectively available. Likd DND or busy in =
other=20
  systems)</FONT> <BR><FONT face=3Dsans-serif size=3D1>&nbsp; &nbsp; =
&nbsp; &nbsp;=20
  &nbsp; &nbsp; &nbsp; &nbsp; </FONT><BR><FONT face=3Dsans-serif =
size=3D1>&nbsp;=20
  &nbsp; &nbsp; &nbsp; * Preferred Contacts (preferred contact method of =
the=20
  user + address of </FONT><BR><FONT face=3Dsans-serif size=3D1>&nbsp; =
&nbsp; &nbsp;=20
  &nbsp; &nbsp; contact)</FONT> <BR><FONT face=3Dsans-serif =
size=3D1>&nbsp; &nbsp;=20
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; - CALL</FONT> <BR><FONT=20
  face=3Dsans-serif size=3D1>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;=20
  - SMS</FONT> <BR><FONT face=3Dsans-serif size=3D1>&nbsp; &nbsp; &nbsp; =
&nbsp;=20
  &nbsp; &nbsp; &nbsp; &nbsp; - MMS (Multi Media SMS)</FONT> <BR><FONT=20
  face=3Dsans-serif size=3D1>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;=20
  - IM</FONT> <BR><FONT face=3Dsans-serif size=3D1>&nbsp; &nbsp; &nbsp; =
&nbsp;=20
  &nbsp; &nbsp; &nbsp; &nbsp; - EMAIL</FONT> <BR><FONT face=3Dsans-serif =

  size=3D1>&nbsp; &nbsp; &nbsp; &nbsp; * Preferred Language</FONT> =
<BR><FONT=20
  face=3Dsans-serif size=3D1>&nbsp; &nbsp; &nbsp; &nbsp; * Status Text =
(free text=20
  describing the status)</FONT> <BR><FONT face=3Dsans-serif =
size=3D1>&nbsp; &nbsp;=20
  &nbsp; &nbsp; * Status Mood (e.g. HAPPY, SAD, etc.)</FONT> <BR><FONT=20
  face=3Dsans-serif size=3D1>&nbsp; &nbsp; &nbsp; &nbsp; * Alias (alias =
name for the=20
  user)</FONT> <BR><FONT face=3Dsans-serif size=3D1>&nbsp; &nbsp; &nbsp; =
&nbsp; *=20
  Status Content - MMS content or URL to the MMS content that the user=20
  </FONT><BR><FONT face=3Dsans-serif size=3D1>&nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; has=20
  selected as personal status information.</FONT> <BR><FONT =
face=3Dsans-serif=20
  size=3D1>&nbsp; &nbsp; &nbsp; &nbsp; * Contact Info - Contact =
information=20
  (vCard)</FONT> <BR><BR><FONT face=3Dsans-serif size=3D1># PAM Forum - =
As described=20
  in a previous message Jorge Lobo" </FONT><BR><FONT face=3Dsans-serif=20
  size=3D1>&nbsp; &lt;jorge@teltier.com&gt;. PAM forum has separate =
layers of=20
  presence information and </FONT><BR><FONT face=3Dsans-serif =
size=3D1>&nbsp;=20
  availability. Availability can be computed by a very simple methods or =
by very=20
  </FONT><BR><FONT face=3Dsans-serif size=3D1>&nbsp; complex conditions =
as if the=20
  message is from X try to get me on any available </FONT><BR><FONT=20
  face=3Dsans-serif size=3D1>&nbsp; device that I am on if not, leave a =
message on=20
  my desktop.</FONT> <BR><BR><FONT face=3Dsans-serif size=3D1>Avshalom =
Houri</FONT>=20
  <BR><FONT face=3Dsans-serif size=3D1>Presence and Instant Messaging=20
  Architect</FONT> <BR><FONT face=3Dsans-serif size=3D1>Lotus Sametime, =
IBM Software=20
  Group</FONT> <BR><FONT face=3Dsans-serif =
size=3D1>avshalom@il.ibm.com</FONT>=20
<BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_001F_01C1E3B9.5D33B810--

_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Sun Apr 14 16:58:35 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22361
	for <simple-archive@odin.ietf.org>; Sun, 14 Apr 2002 16:58:35 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3EKojPe015995;
	Sun, 14 Apr 2002 16:50:45 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA26349;
	Sun, 14 Apr 2002 16:54:04 -0400 (EDT)
Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA26338
	for <simple@mailman.dynamicsoft.com>; Sun, 14 Apr 2002 16:53:34 -0400 (EDT)
Received: from maillennium.att.com ([135.25.114.99])
	by kcmso2.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g3EKqX505957
	for <simple@mailman.dynamicsoft.com>; Sun, 14 Apr 2002 15:52:33 -0500 (CDT)
Received: from att.com (<unknown.domain>[135.210.96.171])
          by maillennium.att.com (mailgw1) with SMTP
          id <20020414205233gw100opi5be>
          (Authid: tony);
          Sun, 14 Apr 2002 20:52:33 +0000
Message-ID: <3CB9EA79.9080603@att.com>
From: Tony Hansen <tony@att.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com, impp@iastate.edu
CC: Avshalom Houri <AVSHALOM@il.ibm.com>
Subject: Re: [Simple] Status summary
References: <HNEOJECGFHIABDLENMMCMELGCFAA.bcampbell@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Sun, 14 Apr 2002 16:45:45 -0400
Content-Transfer-Encoding: 7bit

AT&T's IM Anywhere provides:

     OPEN with hints:
	Available
	Away
	Be right back
	Do not disturb
	On the phone
	you can also create your own custom messages

     CLOSED
	Offline (invisible, lurking)

Any of the states (including Offline) can be chosen at any time.

	Tony Hansen
	tony@att.com

Ben Campbell wrote:

> I cannot speak for the other systems, but Yahoo Messenger allows you to 
> select open or closed when you create a user configurable message. Also, 
> you can  become invisible (i.e. lurk) at any time, not just at login.
> 
>     -----Original Message-----
>     From: simple-admin@mailman.dynamicsoft.com
>     [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Avshalom Houri
>     Sent: Sunday, April 14, 2002 9:58 AM
>     To: simple@mailman.dynamicsoft.com
>     Subject: [Simple] Status summary
> 
> 
>     In the SIMPLE components adhoc meeting at IETF53, I have volunteered to
>     summarize the various statuses used in various systems. The summary
>     is below.
> 
>     While going over the various statuses it occurred to me that we need
>     a more
>     precise definition of what we mean when we say status. The various
>     status values
>     in the various systems can be divided into:
> 
>     * Mood - Happy, Sad etc.
> 
>     * Hint - I am on the phone therefore I will probably not be able to
>     respond
>       immediately. The way that the my client will display the message
>     to me e.g.
>       in Away mode some clients will display the message in a different
>     way from
>       the way they do in normal online mode.
> 
>     * Availability - Am I open or close to communication. The
>     availability can be
>       simple just open or close or quite complex - I am open to
>     communication
>       depending on who is calling and in which location am I.
> 
>     While moods and hints can be localized to vendors and clients, it
>     seems that
>     availability is the part of the status that mostly needs
>     standardization.
> 
>     The summary:
>     ===========
> 
>     # AOL - No explicit status - only idle indication by sensing mouse
>     and keyboard activity.
> 
>     # MSN - Open and close statuses + hints
>             * Online (OPEN)
>             * Busy (CLOSED)
>             * Be Right Back (OPEN)
>             * Away (OPEN)
>             * On the Phone (CLOSED)
>             * Out to Lunch (OPEN)
>             * Appear Offline (Lurking, CLOSED)
> 
>     # YAHOO - Open and close + hints for open.
>             * Offline (CLOSED)
>             * Available (OPEN)        
>             * Busy with various messages (configurable) e.g. Be Right
>     Back, Busy
>               etc. (OPEN)        
>             * Invisible (Lurking can be done only in login time)
> 
>     # ICQ - Open and close statuses. Open statuses are accompanied by
>     hints. For
>       example if I am in DND, I will still get messages but the messages
>     will not be
>       displayed on my screen.
>             Simple Mode
>                     * Available
>                     * Away (OPEN, Messages are shown on the screen)
>                     * Offline
>             Advanced Mode
>                     * Available
>                     * Free for chat
>                     * Away
>                     * N/A (Extended Away)
>                     * Occupied (Urgent messages)
>                     * DND (Do Not Disturb)
>                     * Privacy (Invisible) - Lurking
>                     * Offline
> 
>     # Louts Sametime - Open and close + strong DND. Strong DND means
>     that I am not
>       able to send a message to a person that is in DND mode
>             * Active (OPEN)
>             * DND (Online but closed)
>             * Away (OPEN, an hint)
> 
>     # Wireless Village - As defined by the spec status is composed from
>     several
>       attributes as: availability, preferred contacts etc. Following is
>     a complete
>       list.  
>             * User availability
>                     - AVAILABLE
>                     - NOT_AVAILABLE
>                     - DISCREET (selectively available. Likd DND or busy
>     in other systems)
>                    
>             * Preferred Contacts (preferred contact method of the user +
>     address of
>               contact)
>                     - CALL
>                     - SMS
>                     - MMS (Multi Media SMS)
>                     - IM
>                     - EMAIL
>             * Preferred Language
>             * Status Text (free text describing the status)
>             * Status Mood (e.g. HAPPY, SAD, etc.)
>             * Alias (alias name for the user)
>             * Status Content - MMS content or URL to the MMS content
>     that the user
>               has selected as personal status information.
>             * Contact Info - Contact information (vCard)
> 
>     # PAM Forum - As described in a previous message Jorge Lobo"
>       <jorge@teltier.com>. PAM forum has separate layers of presence
>     information and
>       availability. Availability can be computed by a very simple
>     methods or by very
>       complex conditions as if the message is from X try to get me on
>     any available
>       device that I am on if not, leave a message on my desktop.
> 
>     Avshalom Houri
>     Presence and Instant Messaging Architect
>     Lotus Sametime, IBM Software Group
>     avshalom@il.ibm.com
> 


_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Mon Apr 15 07:36:51 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13302
	for <simple-archive@lists.ietf.org>; Mon, 15 Apr 2002 07:36:51 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3FBRiDE000681;
	Mon, 15 Apr 2002 07:27:44 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00744;
	Mon, 15 Apr 2002 07:31:04 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00733
	for <simple@mailman.dynamicsoft.com>; Mon, 15 Apr 2002 07:30:57 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13143;
	Mon, 15 Apr 2002 07:29:55 -0400 (EDT)
Message-Id: <200204151129.HAA13143@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org, simple@mailman.dynamicsoft.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: [Simple] I-D ACTION:draft-ietf-sip-message-02.txt
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Mon, 15 Apr 2002 07:29:54 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: Session Initiation Protocol Extension for Instant 
                          Messaging
	Author(s)	: B. Campbell, J. Rosenberg et al.
	Filename	: draft-ietf-sip-message-02.txt
	Pages		: 19
	Date		: 12-Apr-02
	
Instant Messageing (IM) refers to the transfer of messages between
users in near real-time.  These messages are usually, but not
required to be, short.  IMs are often used in a conversational mode,
that is, the transfer of messages back and forth is fast enough for
participants to maintain an interactive conversation.
The MESSAGE method is an extension to the Session Initation Protocol
(SIP) that allows the transfer of Instant Messages.  MESSAGE requests
carry the content in the form of MIME body parts.  MESSAGE requests
do not themselves initiate a SIP dialog; under normal usage each
Instant Message stands alone, much like pager messages.  MESSAGE
requests may be sent in the context of a dialog initiated by some
other SIP request.
Since the MESSAGE request is an extension to SIP it inherits all the
request routing and security features of that protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-message-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-message-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-message-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020412140710.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-message-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sip-message-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020412140710.I-D@ietf.org>

--OtherAccess--

--NextPart--


_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Mon Apr 15 13:39:48 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29440
	for <simple-archive@odin.ietf.org>; Mon, 15 Apr 2002 13:39:48 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3FHZpDE003991;
	Mon, 15 Apr 2002 13:35:51 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01790;
	Mon, 15 Apr 2002 13:39:06 -0400 (EDT)
Received: from lor.jeremie.com (lor.jeremie.com [208.245.212.28])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01779
	for <simple@mailman.dynamicsoft.com>; Mon, 15 Apr 2002 13:38:19 -0400 (EDT)
Received: from localhost (stpeter@localhost)
	by lor.jeremie.com (8.9.3/8.9.3) with ESMTP id MAA05522;
	Mon, 15 Apr 2002 12:37:17 -0500
From: Peter Saint-Andre <stpeter@jabber.org>
X-Sender: stpeter@lor.jeremie.com
To: Tony Hansen <tony@att.com>
cc: simple@mailman.dynamicsoft.com, impp@iastate.edu,
        Avshalom Houri <AVSHALOM@il.ibm.com>
Subject: Re: [Simple] Status summary
In-Reply-To: <3CB9EA79.9080603@att.com>
Message-ID: <Pine.LNX.4.10.10204151112580.2567-100000@lor.jeremie.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Mon, 15 Apr 2002 12:37:17 -0500 (CDT)

FWIW, we provide the following statuses (stati?) in Jabber:

1. Unavailable (maps to CLOSED)

2. Available (maps to OPEN) with sub-statuses:
   - away
   - extended away
   - do not disturb
   - free/desiring to chat

3. Invisible

Any status can be extended with a natural-language description of the
status.

More information at
http://www.jabber.org/ietf/draft-miller-jabber-00.html#common-presence

Peter

--
Peter Saint-Andre
email+jabber: stpeter@jabber.org
weblog: http://www.saint-andre.com/blog/

On Sun, 14 Apr 2002, Tony Hansen wrote:

> AT&T's IM Anywhere provides:
> 
>      OPEN with hints:
> 	Available
> 	Away
> 	Be right back
> 	Do not disturb
> 	On the phone
> 	you can also create your own custom messages
> 
>      CLOSED
> 	Offline (invisible, lurking)
> 
> Any of the states (including Offline) can be chosen at any time.
> 
> 	Tony Hansen
> 	tony@att.com
> 
> Ben Campbell wrote:
> 
> > I cannot speak for the other systems, but Yahoo Messenger allows you to 
> > select open or closed when you create a user configurable message. Also, 
> > you can  become invisible (i.e. lurk) at any time, not just at login.

_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Mon Apr 15 13:59:52 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00280
	for <simple-archive@odin.ietf.org>; Mon, 15 Apr 2002 13:59:51 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3FHqdDE004194;
	Mon, 15 Apr 2002 13:52:39 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01869;
	Mon, 15 Apr 2002 13:56:03 -0400 (EDT)
Received: from web11604.mail.yahoo.com (web11604.mail.yahoo.com [216.136.172.56])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id NAA01858
	for <simple@mailman.dynamicsoft.com>; Mon, 15 Apr 2002 13:55:29 -0400 (EDT)
Message-ID: <20020415175425.36353.qmail@web11604.mail.yahoo.com>
Received: from [131.107.3.78] by web11604.mail.yahoo.com via HTTP; Mon, 15 Apr 2002 10:54:25 PDT
From: Sean Olson <seancolson@yahoo.com>
Subject: Re: [Simple] Status summary
To: simple@mailman.dynamicsoft.com, impp@iastate.edu,
        Avshalom Houri <AVSHALOM@il.ibm.com>
In-Reply-To: <Pine.LNX.4.10.10204151112580.2567-100000@lor.jeremie.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Mon, 15 Apr 2002 10:54:25 -0700 (PDT)

There seems to be a common thread here where
we can map communication status (presence) to
one of three states:

   open,
   closed,
   undisclosed (invisible)

Is there a fourth type of state I am missing?

/sean



=====
Sean Olson <seancolson@yahoo.com>

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Mon Apr 15 14:06:37 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00491
	for <simple-archive@odin.ietf.org>; Mon, 15 Apr 2002 14:06:37 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3FI0cDE004304;
	Mon, 15 Apr 2002 14:00:38 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01923;
	Mon, 15 Apr 2002 14:04:03 -0400 (EDT)
Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01912
	for <simple@mailman.dynamicsoft.com>; Mon, 15 Apr 2002 14:03:47 -0400 (EDT)
Received: from ierw.net.avaya.com (localhost [127.0.0.1])
	by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06062
	for <simple@mailman.dynamicsoft.com>; Mon, 15 Apr 2002 14:01:10 -0400 (EDT)
Received: from nj7460avexu1.global.avaya.com (h198-152-6-51.avaya.com [198.152.6.51])
	by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06048
	for <simple@mailman.dynamicsoft.com>; Mon, 15 Apr 2002 14:01:09 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Status summary
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Message-ID: <8CA1128D59AD27429985B397118CEDDFC44198@nj7460avexu1.global.avaya.com>
Thread-Topic: [Simple] Status summary
Thread-Index: AcHkpue64sgDy5gJQD2+nRb7YR12JAAAR7mw
From: "Boyer, David G (Dave)" <dgboyer@avaya.com>
To: "Sean Olson" <seancolson@yahoo.com>, <simple@mailman.dynamicsoft.com>,
        <impp@iastate.edu>, "Avshalom Houri" <AVSHALOM@il.ibm.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id OAA01912
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Mon, 15 Apr 2002 14:03:22 -0400
Content-Transfer-Encoding: 8bit

I am curious about something.  How would you catagorize present
but on the phone?  You may not be available for a SIP audio session, but
you would be available for an IM.  Different presence states for diff
communication channels?

Dave

> -----Original Message-----
> From: Sean Olson [mailto:seancolson@yahoo.com]
> Sent: Monday, April 15, 2002 1:54 PM
> To: simple@mailman.dynamicsoft.com; impp@iastate.edu; Avshalom Houri
> Subject: Re: [Simple] Status summary
> 
> 
> There seems to be a common thread here where
> we can map communication status (presence) to
> one of three states:
> 
>    open,
>    closed,
>    undisclosed (invisible)
> 
> Is there a fourth type of state I am missing?
> 
> /sean
> 
> 
> 
> =====
> Sean Olson <seancolson@yahoo.com>
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Tax Center - online filing with TurboTax
> http://taxes.yahoo.com/
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Mon Apr 15 14:46:40 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02527
	for <simple-archive@odin.ietf.org>; Mon, 15 Apr 2002 14:46:40 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3FIgeDE004836;
	Mon, 15 Apr 2002 14:42:40 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02095;
	Mon, 15 Apr 2002 14:46:04 -0400 (EDT)
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02079
	for <simple@mailman.dynamicsoft.com>; Mon, 15 Apr 2002 14:45:10 -0400 (EDT)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g3FIi8X65501
	for <simple@mailman.dynamicsoft.com>; Mon, 15 Apr 2002 13:44:08 -0500 (CDT)
From: "Ben Campbell" <bcampbell@dynamicsoft.com>
To: "Simple" <simple@mailman.dynamicsoft.com>
Subject: FW: [Simple] Status summary
Message-ID: <HNEOJECGFHIABDLENMMCMENPCFAA.bcampbell@dynamicsoft.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0083_01C1E483.9134CD50"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Mon, 15 Apr 2002 13:43:47 -0500

This is a multi-part message in MIME format.

------=_NextPart_000_0083_01C1E483.9134CD50
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The following is a conversation between Avshalom and myself that we took off
list by accident. We both agreed to forward it back to the list.
  -----Original Message-----
  From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]
  Sent: Monday, April 15, 2002 10:15 AM
  To: Avshalom Houri
  Subject: RE: [Simple] Status summary


  Agreed--but in the Yahoo environment, the sender can not tell for sure if
the message gets delivered immediately or gets store-and-forwarded. So from
the sender's perspective, the two situations are the same. On the other
hand, the _network_ treats the two differently.

  This is very different than, say, Windows Messenger, which if the
recipient appears to be offline, dumps you into an email editor instead of
the IM conversation client.
    -----Original Message-----
    From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]
    Sent: Monday, April 15, 2002 10:11 AM
    To: Ben Campbell
    Subject: RE: [Simple] Status summary



    I think that even if the system is able to deliver the message somehow
using offline messages it is not different from email and the state should
be regarded as closed.  I am not sure about this distinction in a wireless
systems where IM might be translated to an SMS that will be seen by the user
after a considerable period of time.

    Avshalom Houri
    Presence and Instant Messaging Architect
    Lotus Sametime, IBM Software Group
    avshalom@il.ibm.com




         "Ben Campbell" <bcampbell@dynamicsoft.com>
          15/04/2002 16:25
          Please respond to "Ben Campbell"


                  To:        Avshalom Houri/Haifa/IBM@IBMIL
                  cc:
                  Subject:        RE: [Simple] Status summary




    I guess it depends on your definition of "closed." From the sender's
    perspective, it is never more than a hint.

    On yahoo, others can send you a message at any time, without regard to
    whether you are open or closed. If you appear to be closed, they will
get a
    warning that you may not get the message immediately.

    If you are truly offline at the time, the message gets stored until you
    login next time. If you are logged in, it will get delivered to you,
    regardless of your status at the time.

    Now, with some experimentation, I find that a watcher's UI treats really
    being closed differently from online but unavailable. The first is
grayed
    out or not displayed (depending on your display mode), the second is
bolded,
    but shows an icon indicating you are unavailable.

    This seems to indicate a difference between open/closed as determined by
    login, and availability as determined by a user assertion. But the only
    difference from a watchers perspective is the user interface
presentation.

    > -----Original Message-----
    > From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]
    > Sent: Monday, April 15, 2002 5:25 AM
    > To: bcampbell@dynamicsoft.com
    > Subject: RE: [Simple] Status summary
    >
    >
    >
    > I Yahoo when you create your configurable satus message, you can mark
the
    > status
    > as busy but it is only an hint and other users can still send you a
    > message.
    >
    > Avshalom Houri
    > Presence and Instant Messaging Architect
    > Lotus Sametime, IBM Software Group
    > avshalom@il.ibm.com
    >
    >
    >
    >
    >   "Ben Campbell"
    >   <bcampbell@dynamicsoft.com>          To:        Avshalom
    >                                Houri/Haifa/IBM@IBMIL,
    >                                <simple@mailman.dynamicsoft.com>
    >   14/04/2002 21:36                     cc:
    >   Please respond to "Ben               Subject:        RE: [Simple]
    >   Campbell"                    Status summary
    >
    >
    >
    >
    >
    >
    >
    > I cannot speak for the other systems, but Yahoo Messenger allows you
to
    > select open or closed when you create a user configurable message.
Also,
    > you can  become invisible (i.e. lurk) at any time, not just at login.
    > -----Original Message-----
    > From: simple-admin@mailman.dynamicsoft.com
    > [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Avshalom
Houri
    > Sent: Sunday, April 14, 2002 9:58 AM
    > To: simple@mailman.dynamicsoft.com
    > Subject: [Simple] Status summary
    >
    >
    > In the SIMPLE components adhoc meeting at IETF53, I have volunteered
to
    > summarize the various statuses used in various systems. The summary is
    > below.
    >
    > While going over the various statuses it occurred to me that we
    > need a more
    >
    > precise definition of what we mean when we say status. The various
status
    > values
    > in the various systems can be divided into:
    >
    > * Mood - Happy, Sad etc.
    >
    > * Hint - I am on the phone therefore I will probably not be able
    > to respond
    >
    >  immediately. The way that the my client will display the message to
me
    > e.g.
    >  in Away mode some clients will display the message in a
    > different way from
    >
    >  the way they do in normal online mode.
    >
    > * Availability - Am I open or close to communication. The availability
can
    > be
    >  simple just open or close or quite complex - I am open to
communication
    >  depending on who is calling and in which location am I.
    >
    > While moods and hints can be localized to vendors and clients, it
seems
    > that
    > availability is the part of the status that mostly needs
standardization.
    >
    > The summary:
    > ===========
    >
    > # AOL - No explicit status - only idle indication by sensing mouse and
    > keyboard activity.
    >
    > # MSN - Open and close statuses + hints
    >        * Online (OPEN)
    >        * Busy (CLOSED)
    >        * Be Right Back (OPEN)
    >         * Away (OPEN)
    >        * On the Phone (CLOSED)
    >        * Out to Lunch (OPEN)
    >        * Appear Offline (Lurking, CLOSED)
    >
    > # YAHOO - Open and close + hints for open.
    >        * Offline (CLOSED)
    >        * Available (OPEN)
    >        * Busy with various messages (configurable) e.g. Be Right
    > Back, Busy
    >
    >          etc. (OPEN)
    >        * Invisible (Lurking can be done only in login time)
    >
    > # ICQ - Open and close statuses. Open statuses are accompanied by
hints.
    > For
    >  example if I am in DND, I will still get messages but the messages
will
    > not be
    >  displayed on my screen.
    >        Simple Mode
    >                * Available
    >                * Away (OPEN, Messages are shown on the screen)
    >                * Offline
    >        Advanced Mode
    >                * Available
    >                * Free for chat
    >                * Away
    >                * N/A (Extended Away)
    >                * Occupied (Urgent messages)
    >                * DND (Do Not Disturb)
    >                * Privacy (Invisible) - Lurking
    >                * Offline
    >
    > # Louts Sametime - Open and close + strong DND. Strong DND means that
I am
    > not
    >  able to send a message to a person that is in DND mode
    >        * Active (OPEN)
    >        * DND (Online but closed)
    >        * Away (OPEN, an hint)
    >
    > # Wireless Village - As defined by the spec status is composed
    > from several
    >
    >  attributes as: availability, preferred contacts etc. Following is a
    > complete
    >  list.
    >        * User availability
    >                - AVAILABLE
    >                - NOT_AVAILABLE
    >                - DISCREET (selectively available. Likd DND or
    > busy in other
    > systems)
    >
    >        * Preferred Contacts (preferred contact method of the user
    > + address
    > of
    >          contact)
    >                - CALL
    >                - SMS
    >                - MMS (Multi Media SMS)
    >                - IM
    >                - EMAIL
    >        * Preferred Language
    >        * Status Text (free text describing the status)
    >        * Status Mood (e.g. HAPPY, SAD, etc.)
    >        * Alias (alias name for the user)
    >        * Status Content - MMS content or URL to the MMS content that
the
    > user
    >          has selected as personal status information.
    >        * Contact Info - Contact information (vCard)
    >
    > # PAM Forum - As described in a previous message Jorge Lobo"
    >  <jorge@teltier.com>. PAM forum has separate layers of presence
    > information
    > and
    >  availability. Availability can be computed by a very simple methods
or by
    > very
    >  complex conditions as if the message is from X try to get me on any
    > available
    >  device that I am on if not, leave a message on my desktop.
    >
    > Avshalom Houri
    > Presence and Instant Messaging Architect
    > Lotus Sametime, IBM Software Group
    > avshalom@il.ibm.com





------=_NextPart_000_0083_01C1E483.9134CD50
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2715.400" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D027484118-15042002>The=20
following is a conversation between Avshalom and myself that we took off =
list by=20
accident. We both agreed to forward it back to the =
list.</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Ben Campbell=20
  [mailto:bcampbell@dynamicsoft.com]<BR><B>Sent:</B> Monday, April 15, =
2002=20
  10:15 AM<BR><B>To:</B> Avshalom Houri<BR><B>Subject:</B> RE: [Simple] =
Status=20
  summary<BR><BR></FONT></DIV>
  <DIV><SPAN class=3D974531215-15042002><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Agreed--but in the Yahoo environment, the sender can not tell =
for sure=20
  if the message gets delivered immediately or gets store-and-forwarded. =
So from=20
  the sender's perspective, the two situations are the same. On the =
other hand,=20
  the _network_ treats the two differently.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D974531215-15042002><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D974531215-15042002><FONT face=3DArial =
color=3D#0000ff size=3D2>This=20
  is very different than, say, Windows Messenger, which if the recipient =
appears=20
  to be offline, dumps you into an email editor instead of the IM =
conversation=20
  client.</FONT></SPAN></DIV>
  <BLOCKQUOTE=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid">
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Avshalom Houri=20
    [mailto:AVSHALOM@il.ibm.com]<BR><B>Sent:</B> Monday, April 15, 2002 =
10:11=20
    AM<BR><B>To:</B> Ben Campbell<BR><B>Subject:</B> RE: [Simple] Status =

    summary<BR><BR></FONT></DIV><BR><FONT face=3Dsans-serif size=3D2>I =
think that=20
    even if the system is able to deliver the message somehow using =
offline=20
    messages it is not different from email and the state should be =
regarded as=20
    closed. &nbsp;I am not sure about this distinction in a wireless =
systems=20
    where IM might be translated to an SMS that will be seen by the user =
after a=20
    considerable period of time.</FONT> <BR><BR><FONT face=3Dsans-serif=20
    size=3D2>Avshalom Houri<BR>Presence and Instant Messaging =
Architect<BR>Lotus=20
    Sametime, IBM Software=20
    Group<BR>avshalom@il.ibm.com<BR><BR></FONT><BR><BR><BR>
    <TABLE width=3D"100%">
      <TBODY>
      <TR vAlign=3Dtop>
        <TD>
        <TD><FONT face=3Dsans-serif size=3D1><B>"Ben Campbell"=20
          &lt;bcampbell@dynamicsoft.com&gt;</B></FONT>=20
          <P><FONT face=3Dsans-serif size=3D1>15/04/2002 16:25</FONT> =
<BR><FONT=20
          face=3Dsans-serif size=3D1>Please respond to "Ben =
Campbell"</FONT>=20
<BR></P>
        <TD><FONT face=3DArial size=3D1>&nbsp; &nbsp; &nbsp; &nbsp;=20
          </FONT><BR><FONT face=3Dsans-serif size=3D1>&nbsp; &nbsp; =
&nbsp; &nbsp;=20
          To: &nbsp; &nbsp; &nbsp; &nbsp;Avshalom =
Houri/Haifa/IBM@IBMIL</FONT>=20
          <BR><FONT face=3Dsans-serif size=3D1>&nbsp; &nbsp; &nbsp; =
&nbsp; cc:=20
          &nbsp; &nbsp; &nbsp; &nbsp;</FONT> <BR><FONT face=3Dsans-serif =

          size=3D1>&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; =
&nbsp;=20
          &nbsp;RE: [Simple] Status summary</FONT> <BR><BR><FONT =
face=3DArial=20
          size=3D1>&nbsp; &nbsp; &nbsp;=20
    &nbsp;</FONT></TD></TR></TBODY></TABLE><BR><BR><FONT face=3D"Courier =
New"=20
    size=3D2>I guess it depends on your definition of "closed." From the =

    sender's<BR>perspective, it is never more than a hint.<BR><BR>On =
yahoo,=20
    others can send you a message at any time, without regard =
to<BR>whether you=20
    are open or closed. If you appear to be closed, they will get =
a<BR>warning=20
    that you may not get the message immediately.<BR><BR>If you are =
truly=20
    offline at the time, the message gets stored until you<BR>login next =
time.=20
    If you are logged in, it will get delivered to you,<BR>regardless of =
your=20
    status at the time.<BR><BR>Now, with some experimentation, I find =
that a=20
    watcher's UI treats really<BR>being closed differently from online =
but=20
    unavailable. The first is grayed<BR>out or not displayed (depending =
on your=20
    display mode), the second is bolded,<BR>but shows an icon indicating =
you are=20
    unavailable.<BR><BR>This seems to indicate a difference between =
open/closed=20
    as determined by<BR>login, and availability as determined by a user=20
    assertion. But the only<BR>difference from a watchers perspective is =
the=20
    user interface presentation.<BR><BR>&gt; -----Original =
Message-----<BR>&gt;=20
    From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]<BR>&gt; Sent: =
Monday,=20
    April 15, 2002 5:25 AM<BR>&gt; To: bcampbell@dynamicsoft.com<BR>&gt; =

    Subject: RE: [Simple] Status summary<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt; =
I Yahoo=20
    when you create your configurable satus message, you can mark =
the<BR>&gt;=20
    status<BR>&gt; as busy but it is only an hint and other users can =
still send=20
    you a<BR>&gt; message.<BR>&gt;<BR>&gt; Avshalom Houri<BR>&gt; =
Presence and=20
    Instant Messaging Architect<BR>&gt; Lotus Sametime, IBM Software=20
    Group<BR>&gt; =
avshalom@il.ibm.com<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;=20
    &nbsp; "Ben Campbell"<BR>&gt; &nbsp; =
&lt;bcampbell@dynamicsoft.com&gt;=20
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;To: &nbsp; &nbsp; &nbsp;=20
    &nbsp;Avshalom<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;=20
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=20
    &nbsp;Houri/Haifa/IBM@IBMIL,<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;=20
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;=20
    &nbsp;&lt;simple@mailman.dynamicsoft.com&gt;<BR>&gt; &nbsp; =
14/04/2002 21:36=20
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;=20
    cc:<BR>&gt; &nbsp; Please respond to "Ben &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;=20
    &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;RE: =
[Simple]<BR>&gt;=20
    &nbsp; Campbell" &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;=20
    &nbsp; &nbsp;Status=20
    =
summary<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt; =
I=20
    cannot speak for the other systems, but Yahoo Messenger allows you=20
    to<BR>&gt; select open or closed when you create a user configurable =

    message. Also,<BR>&gt; you can &nbsp;become invisible (i.e. lurk) at =
any=20
    time, not just at login.<BR>&gt; -----Original Message-----<BR>&gt; =
From:=20
    simple-admin@mailman.dynamicsoft.com<BR>&gt;=20
    [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Avshalom=20
    Houri<BR>&gt; Sent: Sunday, April 14, 2002 9:58 AM<BR>&gt; To:=20
    simple@mailman.dynamicsoft.com<BR>&gt; Subject: [Simple] Status=20
    summary<BR>&gt;<BR>&gt;<BR>&gt; In the SIMPLE components adhoc =
meeting at=20
    IETF53, I have volunteered to<BR>&gt; summarize the various statuses =
used in=20
    various systems. The summary is<BR>&gt; below.<BR>&gt;<BR>&gt; While =
going=20
    over the various statuses it occurred to me that we<BR>&gt; need a=20
    more<BR>&gt;<BR>&gt; precise definition of what we mean when we say =
status.=20
    The various status</FONT> <BR><FONT face=3D"Courier New" =
size=3D2>&gt;=20
    values<BR>&gt; in the various systems can be divided =
into:<BR>&gt;<BR>&gt; *=20
    Mood - Happy, Sad etc.<BR>&gt;<BR>&gt; * Hint - I am on the phone =
therefore=20
    I will probably not be able<BR>&gt; to respond<BR>&gt;<BR>&gt;=20
    &nbsp;immediately. The way that the my client will display the =
message to=20
    me<BR>&gt; e.g.<BR>&gt; &nbsp;in Away mode some clients will display =
the=20
    message in a<BR>&gt; different way from<BR>&gt;<BR>&gt; &nbsp;the =
way they=20
    do in normal online mode.<BR>&gt;<BR>&gt; * Availability - Am I open =
or=20
    close to communication. The availability can<BR>&gt; be<BR>&gt; =
&nbsp;simple=20
    just open or close or quite complex - I am open to =
communication<BR>&gt;=20
    &nbsp;depending on who is calling and in which location am=20
    I.<BR>&gt;<BR>&gt; While moods and hints can be localized to vendors =
and=20
    clients, it seems<BR>&gt; that<BR>&gt; availability is the part of =
the=20
    status that mostly needs standardization.<BR>&gt;<BR>&gt; The=20
    summary:<BR>&gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>&gt;<BR>&gt; # =
AOL - No explicit status -=20
    only idle indication by sensing mouse and<BR>&gt; keyboard=20
    activity.<BR>&gt;<BR>&gt; # MSN - Open and close statuses + =
hints<BR>&gt;=20
    &nbsp; &nbsp; &nbsp; &nbsp;* Online (OPEN)<BR>&gt; &nbsp; &nbsp; =
&nbsp;=20
    &nbsp;* Busy (CLOSED)<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp;* Be Right =
Back=20
    (OPEN)<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; * Away (OPEN)<BR>&gt; =
&nbsp;=20
    &nbsp; &nbsp; &nbsp;* On the Phone (CLOSED)<BR>&gt; &nbsp; &nbsp; =
&nbsp;=20
    &nbsp;* Out to Lunch (OPEN)<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp;* =
Appear=20
    Offline (Lurking, CLOSED)<BR>&gt;<BR>&gt; # YAHOO - Open and close + =
hints=20
    for open.<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp;* Offline =
(CLOSED)<BR>&gt;=20
    &nbsp; &nbsp; &nbsp; &nbsp;* Available (OPEN)<BR>&gt; &nbsp; &nbsp; =
&nbsp;=20
    &nbsp;* Busy with various messages (configurable) e.g. Be =
Right<BR>&gt;=20
    Back, Busy<BR>&gt;<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;etc.=20
    (OPEN)<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp;* Invisible (Lurking can =
be done=20
    only in login time)<BR>&gt;<BR>&gt; # ICQ - Open and close statuses. =
Open=20
    statuses are accompanied by hints.<BR>&gt; For<BR>&gt; &nbsp;example =
if I am=20
    in DND, I will still get messages but the messages will<BR>&gt; not=20
    be<BR>&gt; &nbsp;displayed on my screen.<BR>&gt; &nbsp; &nbsp; =
&nbsp;=20
    &nbsp;Simple Mode<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;=20
    &nbsp;* Available<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;=20
    &nbsp;* Away (OPEN, Messages are shown on the screen)<BR>&gt; &nbsp; =
&nbsp;=20
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;* Offline<BR>&gt; &nbsp; =
&nbsp;=20
    &nbsp; &nbsp;Advanced Mode<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;=20
    &nbsp; &nbsp;* Available<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;=20
    &nbsp; &nbsp;* Free for chat<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;=20
    &nbsp; &nbsp; &nbsp;* Away<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;=20
    &nbsp; &nbsp;* N/A (Extended Away)<BR>&gt; &nbsp; &nbsp; &nbsp; =
&nbsp;=20
    &nbsp; &nbsp; &nbsp; &nbsp;* Occupied (Urgent messages)<BR>&gt; =
&nbsp;=20
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;* DND (Do Not=20
    Disturb)<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;*=20
    Privacy (Invisible) - Lurking<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;=20
    &nbsp; &nbsp; &nbsp;* Offline<BR>&gt;<BR>&gt; # Louts Sametime - =
Open and=20
    close + strong DND. Strong DND means that I am<BR>&gt; not<BR>&gt;=20
    &nbsp;able to send a message to a person that is in DND mode<BR>&gt; =
&nbsp;=20
    &nbsp; &nbsp; &nbsp;* Active (OPEN)<BR>&gt; &nbsp; &nbsp; &nbsp; =
&nbsp;* DND=20
    (Online but closed)<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp;* Away (OPEN, =
an=20
    hint)<BR>&gt;<BR>&gt; # Wireless Village - As defined by the spec =
status is=20
    composed<BR>&gt; from several<BR>&gt;<BR>&gt; &nbsp;attributes as:=20
    availability, preferred contacts etc. Following is a<BR>&gt;=20
    complete<BR>&gt; &nbsp;list.<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp;* =
User=20
    availability<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;=20
    &nbsp;- AVAILABLE<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;=20
    &nbsp;- NOT_AVAILABLE<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;=20
    &nbsp; &nbsp;- DISCREET (selectively available. Likd DND or<BR>&gt; =
busy in=20
    other<BR>&gt; systems)<BR>&gt;<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp;*=20
    Preferred Contacts (preferred contact method of the user<BR>&gt; +=20
    address<BR>&gt; of<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp;=20
    &nbsp;contact)<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;=20
    &nbsp;- CALL<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;=20
    &nbsp;- SMS<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;-=20
    MMS (Multi Media SMS)<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;=20
    &nbsp; &nbsp;- IM<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;=20
    &nbsp;- EMAIL<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp;* Preferred=20
    Language<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp;* Status Text (free text =

    describing the status)<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp;* Status =
Mood=20
    (e.g. HAPPY, SAD, etc.)<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp;* Alias =
(alias=20
    name for the user)<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp;* Status =
Content - MMS=20
    content or URL to the MMS content that the<BR>&gt; user<BR>&gt; =
&nbsp;=20
    &nbsp; &nbsp; &nbsp; &nbsp;has selected as personal status=20
    information.<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp;* Contact Info - =
Contact=20
    information (vCard)<BR>&gt;<BR>&gt; # PAM Forum - As described in a =
previous=20
    message Jorge Lobo"<BR>&gt; &nbsp;&lt;jorge@teltier.com&gt;. PAM =
forum has=20
    separate layers of presence<BR>&gt; information<BR>&gt; and<BR>&gt;=20
    &nbsp;availability. Availability can be computed by a very simple =
methods or=20
    by<BR>&gt; very<BR>&gt; &nbsp;complex conditions as if the message =
is from X=20
    try to get me on any<BR>&gt; available<BR>&gt; &nbsp;device that I =
am on if=20
    not, leave a message on my desktop.<BR>&gt;<BR>&gt; Avshalom =
Houri<BR>&gt;=20
    Presence and Instant Messaging Architect<BR>&gt; Lotus Sametime, IBM =

    Software Group<BR>&gt;=20
avshalom@il.ibm.com<BR><BR></FONT><BR><BR></BLOCKQUOTE></BLOCKQUOTE></BOD=
Y></HTML>

------=_NextPart_000_0083_01C1E483.9134CD50--

_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Mon Apr 15 14:47:21 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02546
	for <simple-archive@odin.ietf.org>; Mon, 15 Apr 2002 14:47:21 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3FIdgDE004770;
	Mon, 15 Apr 2002 14:39:43 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02056;
	Mon, 15 Apr 2002 14:43:04 -0400 (EDT)
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02045
	for <simple@mailman.dynamicsoft.com>; Mon, 15 Apr 2002 14:42:32 -0400 (EDT)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g3FIfSX65280;
	Mon, 15 Apr 2002 13:41:28 -0500 (CDT)
From: "Ben Campbell" <bcampbell@dynamicsoft.com>
To: "Sean Olson" <seancolson@yahoo.com>, <simple@mailman.dynamicsoft.com>,
        <impp@iastate.edu>, "Avshalom Houri" <AVSHALOM@il.ibm.com>
Subject: RE: [Simple] Status summary
Message-ID: <HNEOJECGFHIABDLENMMCIENPCFAA.bcampbell@dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <20020415175425.36353.qmail@web11604.mail.yahoo.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Mon, 15 Apr 2002 13:41:07 -0500
Content-Transfer-Encoding: 7bit

There may be some concept of Open, but unavailable, at least if you look at
the way Yahoo handles offline, vs. online but setting some unavailable
status. See the off-list conversation between Avshalom and myself that I am
forwarding separately.

> -----Original Message-----
> From: simple-admin@mailman.dynamicsoft.com
> [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Sean Olson
> Sent: Monday, April 15, 2002 12:54 PM
> To: simple@mailman.dynamicsoft.com; impp@iastate.edu; Avshalom Houri
> Subject: Re: [Simple] Status summary
>
>
> There seems to be a common thread here where
> we can map communication status (presence) to
> one of three states:
>
>    open,
>    closed,
>    undisclosed (invisible)
>
> Is there a fourth type of state I am missing?
>
> /sean
>
>
>
> =====
> Sean Olson <seancolson@yahoo.com>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Tax Center - online filing with TurboTax
> http://taxes.yahoo.com/
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Mon Apr 15 15:39:06 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04267
	for <simple-archive@odin.ietf.org>; Mon, 15 Apr 2002 15:39:05 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3FJXgDE005437;
	Mon, 15 Apr 2002 15:33:42 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02302;
	Mon, 15 Apr 2002 15:37:03 -0400 (EDT)
Received: from lor.jeremie.com (lor.jeremie.com [208.245.212.28])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02291
	for <simple@mailman.dynamicsoft.com>; Mon, 15 Apr 2002 15:36:26 -0400 (EDT)
Received: from localhost (stpeter@localhost)
	by lor.jeremie.com (8.9.3/8.9.3) with ESMTP id OAA07715;
	Mon, 15 Apr 2002 14:35:20 -0500
From: Peter Saint-Andre <stpeter@jabber.org>
X-Sender: stpeter@lor.jeremie.com
To: "Boyer, David G (Dave)" <dgboyer@avaya.com>
cc: Sean Olson <seancolson@yahoo.com>, simple@mailman.dynamicsoft.com,
        impp@iastate.edu, Avshalom Houri <AVSHALOM@il.ibm.com>
Subject: RE: [Simple] Status summary
In-Reply-To: <8CA1128D59AD27429985B397118CEDDFC44198@nj7460avexu1.global.avaya.com>
Message-ID: <Pine.LNX.4.10.10204151431280.5086-100000@lor.jeremie.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Mon, 15 Apr 2002 14:35:12 -0500 (CDT)

In Jabber we handle this with the concept of a "resource" -- one Jabber
Entity (normally user@host) can possess multiple resources associated with
different connection types or locations (e.g., user@host/cellphone and
user@host/desktop), there is no limit on the number of simultaneous
connected resources that may be associated with a Jabber Entity, and each
resource can have a distinct presence status.

Peter

--
Peter Saint-Andre
email+jabber: stpeter@jabber.org

On Mon, 15 Apr 2002, Boyer, David G (Dave) wrote:

> I am curious about something.  How would you catagorize present
> but on the phone?  You may not be available for a SIP audio session, but
> you would be available for an IM.  Different presence states for diff
> communication channels?
> 
> Dave
> 
> > -----Original Message-----
> > From: Sean Olson [mailto:seancolson@yahoo.com]
> > Sent: Monday, April 15, 2002 1:54 PM
> > To: simple@mailman.dynamicsoft.com; impp@iastate.edu; Avshalom Houri
> > Subject: Re: [Simple] Status summary
> > 
> > 
> > There seems to be a common thread here where
> > we can map communication status (presence) to
> > one of three states:
> > 
> >    open,
> >    closed,
> >    undisclosed (invisible)
> > 
> > Is there a fourth type of state I am missing?
> > 
> > /sean
> > 
> > 
> > 
> > =====
> > Sean Olson <seancolson@yahoo.com>
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Tax Center - online filing with TurboTax
> > http://taxes.yahoo.com/
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > 
> 
> 
> 
>   [reminder: meta-impp@iastate.edu for non-technical discussions, please]
> 

_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Mon Apr 15 16:10:31 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05301
	for <simple-archive@odin.ietf.org>; Mon, 15 Apr 2002 16:10:30 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3FK2iDE005723;
	Mon, 15 Apr 2002 16:02:44 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02425;
	Mon, 15 Apr 2002 16:06:03 -0400 (EDT)
Received: from imo-r05.mx.aol.com (imo-r05.mx.aol.com [152.163.225.101])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02321
	for <simple@mailman.dynamicsoft.com>; Mon, 15 Apr 2002 15:38:20 -0400 (EDT)
Received: from Juberti@aol.com
	by imo-r05.mx.aol.com (mail_out_v32.5.) id u.a6.24918124 (15876);
	Mon, 15 Apr 2002 15:37:14 -0400 (EDT)
Received: from  pcsn602343 ([10.2.115.71]) by air-id07.mx.aol.com (v84.14) with ESMTP id MAILINID73-0415153714; Mon, 15 Apr 2002 15:37:14 -0400
From: "Justin Uberti" <juberti@aol.com>
To: <simple@mailman.dynamicsoft.com>, <impp@iastate.edu>
Cc: "Avshalom Houri" <AVSHALOM@il.ibm.com>
Subject: RE: [Simple] Status summary
Message-ID: <NCBBJADBPKLDGGFBHGINCECBDMAA.juberti@aol.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <3CB9EA79.9080603@att.com>
Importance: Normal
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Mon, 15 Apr 2002 15:37:14 -0400
Content-Transfer-Encoding: 7bit

AOL has open and closed statuses and hints.

* Online (OPEN)
* Offline (CLOSED)
* Away with various configurable messages (CLOSED)
* Idle (OPEN)

Justin Uberti
America Online

> >     The summary:
> >     ===========
> >
> >     # AOL - No explicit status - only idle indication by sensing mouse
> >     and keyboard activity.
> >
> >     # MSN - Open and close statuses + hints
> >             * Online (OPEN)
> >             * Busy (CLOSED)
> >             * Be Right Back (OPEN)
> >             * Away (OPEN)
> >             * On the Phone (CLOSED)
> >             * Out to Lunch (OPEN)
> >             * Appear Offline (Lurking, CLOSED)
> >
> >     # YAHOO - Open and close + hints for open.
> >             * Offline (CLOSED)
> >             * Available (OPEN)
> >             * Busy with various messages (configurable) e.g. Be Right
> >     Back, Busy
> >               etc. (OPEN)
> >             * Invisible (Lurking can be done only in login time)
> >
> >     # ICQ - Open and close statuses. Open statuses are accompanied by
> >     hints. For
> >       example if I am in DND, I will still get messages but the messages
> >     will not be
> >       displayed on my screen.
> >             Simple Mode
> >                     * Available
> >                     * Away (OPEN, Messages are shown on the screen)
> >                     * Offline
> >             Advanced Mode
> >                     * Available
> >                     * Free for chat
> >                     * Away
> >                     * N/A (Extended Away)
> >                     * Occupied (Urgent messages)
> >                     * DND (Do Not Disturb)
> >                     * Privacy (Invisible) - Lurking
> >                     * Offline
> >
> >     # Louts Sametime - Open and close + strong DND. Strong DND means
> >     that I am not
> >       able to send a message to a person that is in DND mode
> >             * Active (OPEN)
> >             * DND (Online but closed)
> >             * Away (OPEN, an hint)
> >
> >     # Wireless Village - As defined by the spec status is composed from
> >     several
> >       attributes as: availability, preferred contacts etc. Following is
> >     a complete
> >       list.
> >             * User availability
> >                     - AVAILABLE
> >                     - NOT_AVAILABLE
> >                     - DISCREET (selectively available. Likd DND or busy
> >     in other systems)
> >
> >             * Preferred Contacts (preferred contact method of the user +
> >     address of
> >               contact)
> >                     - CALL
> >                     - SMS
> >                     - MMS (Multi Media SMS)
> >                     - IM
> >                     - EMAIL
> >             * Preferred Language
> >             * Status Text (free text describing the status)
> >             * Status Mood (e.g. HAPPY, SAD, etc.)
> >             * Alias (alias name for the user)
> >             * Status Content - MMS content or URL to the MMS content
> >     that the user
> >               has selected as personal status information.
> >             * Contact Info - Contact information (vCard)
> >
> >     # PAM Forum - As described in a previous message Jorge Lobo"
> >       <jorge@teltier.com>. PAM forum has separate layers of presence
> >     information and
> >       availability. Availability can be computed by a very simple
> >     methods or by very
> >       complex conditions as if the message is from X try to get me on
> >     any available
> >       device that I am on if not, leave a message on my desktop.
> >
> >     Avshalom Houri
> >     Presence and Instant Messaging Architect
> >     Lotus Sametime, IBM Software Group
> >     avshalom@il.ibm.com
> >

_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Mon Apr 15 16:33:33 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06061
	for <simple-archive@odin.ietf.org>; Mon, 15 Apr 2002 16:33:33 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3FKQhDE005930;
	Mon, 15 Apr 2002 16:26:43 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02520;
	Mon, 15 Apr 2002 16:30:04 -0400 (EDT)
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02507
	for <simple@mailman.dynamicsoft.com>; Mon, 15 Apr 2002 16:29:24 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.83])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g3FKTdo6010375;
	Mon, 15 Apr 2002 16:29:39 -0400 (EDT)
Message-ID: <3CBB37E7.25E75EC6@dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: hisham.khartabil@nokia.com
CC: mikko.lonnfors@nokia.com, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] question about winfo-package (resend with revision marks)
References: <2038BCC78B1AD641891A0D1AE133DBB777910E@esebe019.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Mon, 15 Apr 2002 16:28:23 -0400
Content-Transfer-Encoding: 7bit



hisham.khartabil@nokia.com wrote:
> 
> The first NOTIFY is sent of course, but there will be no NOTIFYs sent
> when a change to winfo occurs.

Right. I'll clarify that.

Thanks,
Jonathan R.

> > -----Original Message-----
> > From: Lonnfors Mikko (NRC/Helsinki)
> > Sent: Tuesday, April 09, 2002 10:37 AM
> > To: jdrosen@dynamicsoft.com
> > Cc: simple@mailman.dynamicsoft.com
> > Subject: RE: [Simple] question about winfo-package (resend
> > with revision
> > marks)
> >
> >
> > Hi,
> >
> > Thanks for the answer. I have one more question about
> > draft-ietf-simple-winfo-package-01.
> > Chapter 4.7.1 The Subscription State Machine (after figure 1) says:
> >
> > "If, when a subscription arrives, there is no authorization policy in
> > existence, the subscription moves into the pending state. In this
> > state, the server is awaiting an authorization decision. No
> > notifications are generated, but the subscription FSM is maintained."
> >
> > Is this to say that the package on which winfo is applied to
> > should not generate
> > any NOTIFY messages to subscriber? This sound a bit weird
> > because SIP events says that NOTIFY
> > should be send immediately after 200-class response. (I am
> > here assuming SUB-202 request/response
> > if there is no authorization policy is set)
> >
> > So in short how should the quoted sentence be interpreted?
> >
> > regards
> > - Mikko
> >
> > > -----Original Message-----
> > > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> > > Sent: 01 April, 2002 09:13
> > > To: Lonnfors Mikko (NRC/Helsinki)
> > > Cc: tanglih@cn.ibm.com; simple@mailman.dynamicsoft.com
> > > Subject: Re: [Simple] question about winfo-package (resend
> > > with revision
> > > marks)
> > >
> > >
> > >
> > >
> > > mikko.lonnfors@nokia.com wrote:
> > > >
> > > > My opinion about your question is as follows:
> > > >
> > > > The motivating application for winfo package is presence
> > > authorization.
> > > > If
> > > > User B is authorized to subscribe A's presence, as you
> > > said, generally
> > > > speaking the PS doesn't need to notify A of the B's
> > > subscription status
> > > > for
> > > > authorization.
> > > >
> > > > <ML>
> > > > I would still say that winfo is designed to enable
> > presentity to get
> > > > lists of watchers interested in their presence status.
> > > > This should happen regardless of the watcher's
> > authorization status.
> > > > Presence authorization may be the main motivation
> > > > to enable this functionality but not the only one.
> > > > </ML>
> > >
> > > Yes. However, the decision about when to send NOTIFY for winfo is a
> > > server decision; it can decide to not send two notifications
> > > in the case
> > > of a fetch.
> > >
> > >
> > > >
> > > > If the PS needs to notify A of this FETCH subscription, you
> > > may use the
> > > > 'expiration' attribute of winfo foramt. Like this:
> > > >   <watcherinfo>
> > > >      <resource uri="sip:A@foo.com" package="presence">
> > > >        <watcher uri="sip:B@nokia.com" status="active"
> > > >                    event="subscribe" expiration="0"/>
> > > >      </resource>
> > > >    </watcherinfo>
> > > > In this case, A should understanding that a FETCH subscription is
> > > > requested.
> > > > How about this way to solute your problem?
> > > >
> > > > <ML>
> > > > I think there are some problems with this approach. I think
> > > that winfo
> > > > is designed to
> > > > signal changes in watchers subscription status i.e. signal
> > > the state to
> > > > which a watcher has moved from previous state.
> > > > In this case, as you said,  A should be able to understand that
> > > >
> > > >     <resource uri="sip:A@foo.com" package="presence">
> > > >        <watcher uri="sip:B@nokia.com" status="active"
> > > >                    event="subscribe" expiration="0"/>
> > > >
> > > > means FETCH. This would mean special casing expiration="0".
> > >
> > > It only needs to be special cased if you are trying to explicitly
> > > identify fetch requests. I see no reason to do that. The above
> > > notification stands, by itself, as something reasonable.
> > > However, if you
> > > want to send a single notification, you are probably better
> > > off sending
> > > the one on the transition to terminated due to timeout.
> > >
> > >
> > >
> > > > We could take an other example. Let's say that B performs
> > > FETCH but has
> > > > no authorization. Should A now get
> > > >
> > > >    <resource uri="sip:A@foo.com" package="presence">
> > > >        <watcher uri="sip:B@nokia.com" status="pending"
> > > >                    event="subscribe" expiration="0"/>
> > > >
> > > > I would say that sending
> > > >
> > > >    <resource uri="sip:A@foo.com" package="presence">
> > > >        <watcher uri="sip:B@nokia.com" status="waiting"
> > > >                    event="subscribe"/>
> > > >
> > > > would make more sense.
> > >
> > > I agree that the second one makes more sense. The first is valid, of
> > > course, but if you want to send just one notification, the latter is
> > > more useful. Again, the decision about which state change
> > > notifications
> > > to send is a matter of local policy.
> > >
> > > -Jonathan R.
> > >
> > > --
> > > Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> > > Chief Scientist                         First Floor
> > > dynamicsoft                             East Hanover, NJ 07936
> > > jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
> > > http://www.jdrosen.net                  PH:  (973) 952-5000
> > > http://www.dynamicsoft.com
> > >
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> >

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


From simple-admin@mailman.dynamicsoft.com  Mon Apr 15 17:29:47 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07121
	for <simple-archive@odin.ietf.org>; Mon, 15 Apr 2002 17:29:47 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3FLPjDE006627;
	Mon, 15 Apr 2002 17:25:46 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02702;
	Mon, 15 Apr 2002 17:29:04 -0400 (EDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02691
	for <simple@mailman.dynamicsoft.com>; Mon, 15 Apr 2002 17:28:18 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA27458;
	Mon, 15 Apr 2002 17:27:16 -0400 (EDT)
Received: from cs.columbia.edu (slip-32-102-22-11.md.us.prserv.net [32.102.22.11])
	(authenticated bits=0)
	by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g3FLRBPm029753
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Mon, 15 Apr 2002 17:27:13 -0400 (EDT)
Message-ID: <3CBB4583.94152842@cs.columbia.edu>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@jabber.org>
CC: Tony Hansen <tony@att.com>, simple@mailman.dynamicsoft.com,
        impp@iastate.edu, Avshalom Houri <AVSHALOM@il.ibm.com>
Subject: Re: [Simple] Status summary
References: <Pine.LNX.4.10.10204151112580.2567-100000@lor.jeremie.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Mon, 15 Apr 2002 17:26:27 -0400
Content-Transfer-Encoding: 7bit

I'm curious: Windows Messenger, supposedly using SIP and IMPP presence,
has a bunch of status indications, similar to the ones mentioned on the
list (lunch, do not disturb, etc.). How are they encoded?

Peter Saint-Andre wrote:
> 
> FWIW, we provide the following statuses (stati?) in Jabber:
> 
> 1. Unavailable (maps to CLOSED)
> 
> 2. Available (maps to OPEN) with sub-statuses:
>    - away
>    - extended away
>    - do not disturb
>    - free/desiring to chat
> 
> 3. Invisible
> 
> Any status can be extended with a natural-language description of the
> status.
> 
> More information at
> http://www.jabber.org/ietf/draft-miller-jabber-00.html#common-presence
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Mon Apr 15 17:41:11 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07382
	for <simple-archive@odin.ietf.org>; Mon, 15 Apr 2002 17:41:11 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3FLYfDE006738;
	Mon, 15 Apr 2002 17:34:41 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02761;
	Mon, 15 Apr 2002 17:38:03 -0400 (EDT)
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02750
	for <simple@mailman.dynamicsoft.com>; Mon, 15 Apr 2002 17:37:58 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.83])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g3FLcFo6010845
	for <simple@mailman.dynamicsoft.com>; Mon, 15 Apr 2002 17:38:15 -0400 (EDT)
Message-ID: <3CBB47FA.86E3D26E@dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [Simple] changes to winfo format
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Mon, 15 Apr 2002 17:36:58 -0400
Content-Transfer-Encoding: 7bit

Folks,

In an attempt to make our XML usage in draft-ietf-simple-winfo-format
more consistent with "proper" XML usage (See
http://www.ietf.org/internet-drafts/draft-hollenbeck-ietf-xml-guidelines-00.txt),
I propose the following changes to the watcherinfo format draft:


1. The resource element be named to watchers, and the uri attribute be
renamed to resource. The reason is so that the element name (watchers)
actually identifies what it is that the element contains. Right now, the
name of the element is resource, but its value is not the resource, its
the watchers.

2. The value of the watcher element be the URI, rather than the optional
human readable name of the watcher. The URI is really the value of this
element, not the human readable form.

3. We add an xml:lang attribute to the watcher element, allowing for
declaration of the language for the human readable name of the watcher.

4. We explicitly disallow the usage of the XML declaration, and
explicitly mandate UTF-8 encoding.

5. We use a schema instead of a DTD.

6. We explicitly disallow XML processing instructions.

7. We explicitly say that any unrecognized elements or attributes are
ignored.


Comments?

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


From simple-admin@mailman.dynamicsoft.com  Tue Apr 16 06:42:48 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28635
	for <simple-archive@odin.ietf.org>; Tue, 16 Apr 2002 06:42:48 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3GAbgDE009343;
	Tue, 16 Apr 2002 06:37:42 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04806;
	Tue, 16 Apr 2002 06:41:04 -0400 (EDT)
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04795
	for <simple@mailman.dynamicsoft.com>; Tue, 16 Apr 2002 06:40:33 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id MAA43016;
	Tue, 16 Apr 2002 12:38:58 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3GAcup80066;
	Tue, 16 Apr 2002 12:38:56 +0200
To: Henning Schulzrinne <hgs@cs.columbia.edu>
Cc: impp@iastate.edu, simple@mailman.dynamicsoft.com,
        Peter Saint-Andre <stpeter@jabber.org>, Tony Hansen <tony@att.com>
MIME-Version: 1.0
Subject: Re: [Simple] Status summary
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFCA569DB5.4020157C-ONC2256B9D.003A367D@telaviv.ibm.com>
From: "Avshalom Houri" <AVSHALOM@il.ibm.com>
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at
 16/04/2002 13:38:57,
	Serialize complete at 16/04/2002 13:38:57
Content-Type: multipart/alternative; boundary="=_alternative 003A7FA4C2256B9D_="
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Tue, 16 Apr 2002 13:38:57 +0300

This is a multipart message in MIME format.
--=_alternative 003A7FA4C2256B9D_=
Content-Type: text/plain; charset="us-ascii"

I was checking the Windows messenger version 4.6. As far as I know:
        * This version is based on the MSN protocol and not SIP.
        * The SIP client is not publically available yet.

Avshalom Houri
Presence and Instant Messaging Architect
Lotus Sametime, IBM Software Group
avshalom@il.ibm.com






Henning Schulzrinne <hgs@cs.columbia.edu>
16/04/2002 00:26
Please respond to Henning Schulzrinne

 
        To:        Peter Saint-Andre <stpeter@jabber.org>
        cc:        Tony Hansen <tony@att.com>, simple@mailman.dynamicsoft.com, 
impp@iastate.edu, Avshalom Houri/Haifa/IBM@IBMIL
        Subject:        Re: [Simple] Status summary

 

I'm curious: Windows Messenger, supposedly using SIP and IMPP presence,
has a bunch of status indications, similar to the ones mentioned on the
list (lunch, do not disturb, etc.). How are they encoded?

Peter Saint-Andre wrote:
> 
> FWIW, we provide the following statuses (stati?) in Jabber:
> 
> 1. Unavailable (maps to CLOSED)
> 
> 2. Available (maps to OPEN) with sub-statuses:
>    - away
>    - extended away
>    - do not disturb
>    - free/desiring to chat
> 
> 3. Invisible
> 
> Any status can be extended with a natural-language description of the
> status.
> 
> More information at
> http://www.jabber.org/ietf/draft-miller-jabber-00.html#common-presence



--=_alternative 003A7FA4C2256B9D_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">I was checking the Windows messenger version 4.6. As far as I know:</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; * This version is based on the MSN protocol and not SIP.</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; * The SIP client is not publically available yet.</font>
<br>
<br><font size=2 face="sans-serif">Avshalom Houri<br>
Presence and Instant Messaging Architect<br>
Lotus Sametime, IBM Software Group<br>
avshalom@il.ibm.com<br>
<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>Henning Schulzrinne &lt;hgs@cs.columbia.edu&gt;</b></font>
<p><font size=1 face="sans-serif">16/04/2002 00:26</font>
<br><font size=1 face="sans-serif">Please respond to Henning Schulzrinne</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;Peter Saint-Andre &lt;stpeter@jabber.org&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;Tony Hansen &lt;tony@att.com&gt;, simple@mailman.dynamicsoft.com, impp@iastate.edu, Avshalom Houri/Haifa/IBM@IBMIL</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: [Simple] Status summary</font>
<br>
<br><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp;</font></table>
<br>
<br><font size=2 face="Courier New">I'm curious: Windows Messenger, supposedly using SIP and IMPP presence,<br>
has a bunch of status indications, similar to the ones mentioned on the<br>
list (lunch, do not disturb, etc.). How are they encoded?<br>
<br>
Peter Saint-Andre wrote:<br>
&gt; <br>
&gt; FWIW, we provide the following statuses (stati?) in Jabber:<br>
&gt; <br>
&gt; 1. Unavailable (maps to CLOSED)<br>
&gt; <br>
&gt; 2. Available (maps to OPEN) with sub-statuses:<br>
&gt; &nbsp; &nbsp;- away<br>
&gt; &nbsp; &nbsp;- extended away<br>
&gt; &nbsp; &nbsp;- do not disturb<br>
&gt; &nbsp; &nbsp;- free/desiring to chat<br>
&gt; <br>
&gt; 3. Invisible<br>
&gt; <br>
&gt; Any status can be extended with a natural-language description of the<br>
&gt; status.<br>
&gt; <br>
&gt; More information at<br>
&gt; http://www.jabber.org/ietf/draft-miller-jabber-00.html#common-presence<br>
</font>
<br>
<br>
--=_alternative 003A7FA4C2256B9D_=--
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Tue Apr 16 06:59:06 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28924
	for <simple-archive@odin.ietf.org>; Tue, 16 Apr 2002 06:59:05 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3GAsfDE009458;
	Tue, 16 Apr 2002 06:54:41 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04878;
	Tue, 16 Apr 2002 06:58:03 -0400 (EDT)
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04867
	for <simple@mailman.dynamicsoft.com>; Tue, 16 Apr 2002 06:57:50 -0400 (EDT)
Received: from d12relay02.de.ibm.com ([9.165.215.23])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id MAA171852;
	Tue, 16 Apr 2002 12:53:42 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3GAr1p101594;
	Tue, 16 Apr 2002 12:53:07 +0200
To: "Christian Huitema" <huitema@windows.microsoft.com>
Cc: impp@iastate.edu, owner-impp@iastate.edu,
        "Sean Olson" <seancolson@yahoo.com>, simple@mailman.dynamicsoft.com
MIME-Version: 1.0
Subject: RE: [Simple] Status summary
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF90F09D53.280A8DEE-ONC2256B9D.003A9CEE@telaviv.ibm.com>
From: "Avshalom Houri" <AVSHALOM@il.ibm.com>
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at
 16/04/2002 13:53:07,
	Serialize complete at 16/04/2002 13:53:07
Content-Type: multipart/alternative; boundary="=_alternative 003BCA26C2256B9D_="
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Tue, 16 Apr 2002 13:53:03 +0300

This is a multipart message in MIME format.
--=_alternative 003BCA26C2256B9D_=
Content-Type: text/plain; charset="us-ascii"

I agree with Christian. We would lose the meaning of being invisible (or 
actually lurking) if the status will be invisible.

It seems that there are open and close statuses where I think we need to 
get a 
clear definition of those.

It seems that:
* OPEN - The message will be received by the user agent no matter if the 
  user himself/herself is near the terminal. This include away and other 
  hints as idle.

* CLOSED - The message will not be received by the user agent.

As started to discuss with Ben Campbell, it seems that in parallel we need 
to 
decide what is the meaning of other means of conveying the message to the 
user
* If the system implements offline messages will that regarded as open or 
  closed?

* What about SMS, normal phone call, email etc.?

Avshalom Houri
Presence and Instant Messaging Architect
Lotus Sametime, IBM Software Group
avshalom@il.ibm.com






"Christian Huitema" <huitema@windows.microsoft.com>
Sent by: owner-impp@iastate.edu
16/04/2002 04:24
Please respond to "Christian Huitema"

 
        To:        "Sean Olson" <seancolson@yahoo.com>, <simple@mailman.dynamicsoft.com>, 
<impp@iastate.edu>, Avshalom Houri/Haifa/IBM@IBMIL
        cc: 
        Subject:        RE: [Simple] Status summary

 

Undisclosed is not a state. When someone is "invisible", they appear
"off line" (closed) to third parties. You definitely don't want a code
point that would say "X is online but would like to appear offline".

-- Christian Huitema

> -----Original Message-----
> From: Sean Olson [mailto:seancolson@yahoo.com]
> Sent: Monday, April 15, 2002 10:54 AM
> To: simple@mailman.dynamicsoft.com; impp@iastate.edu; Avshalom Houri
> Subject: Re: [Simple] Status summary
> 
> There seems to be a common thread here where
> we can map communication status (presence) to
> one of three states:
> 
>    open,
>    closed,
>    undisclosed (invisible)
> 
> Is there a fourth type of state I am missing?
> 
> /sean
> 
> 
> 
> =====
> Sean Olson <seancolson@yahoo.com>
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Tax Center - online filing with TurboTax
> http://taxes.yahoo.com/
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple



  [reminder: meta-impp@iastate.edu for non-technical discussions, please]




--=_alternative 003BCA26C2256B9D_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="Courier New">I agree with Christian. We would lose the meaning of being invisible (or </font>
<br><font size=2 face="Courier New">actually lurking) if the status will be invisible.</font>
<br>
<br><font size=2 face="Courier New">It seems that there are open and close statuses where I think we need to get a </font>
<br><font size=2 face="Courier New">clear definition of those.</font>
<br>
<br><font size=2 face="Courier New">It seems that:</font>
<br><font size=2 face="Courier New">* OPEN - The message will be received by the user agent no matter if the </font>
<br><font size=2 face="Courier New">&nbsp; user himself/herself is near the terminal. This include away and other </font>
<br><font size=2 face="Courier New">&nbsp; hints as idle.</font>
<br>
<br><font size=2 face="Courier New">* CLOSED - The message will not be received by the user agent.</font>
<br>
<br><font size=2><tt>As started to discuss with Ben Campbell, it seems that in parallel we need to </tt></font>
<br><font size=2><tt>decide what is the meaning of other means of conveying the message to the user</tt></font>
<br><font size=2 face="Courier New">* If the system implements offline messages will that regarded as open or </font>
<br><font size=2 face="Courier New">&nbsp; closed?</font>
<br>
<br><font size=2 face="Courier New">* What about SMS, normal phone call, email etc.?</font>
<br>
<br><font size=2 face="sans-serif">Avshalom Houri<br>
Presence and Instant Messaging Architect<br>
Lotus Sametime, IBM Software Group<br>
avshalom@il.ibm.com<br>
<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>&quot;Christian Huitema&quot; &lt;huitema@windows.microsoft.com&gt;</b></font>
<br><font size=1 face="sans-serif">Sent by: owner-impp@iastate.edu</font>
<p><font size=1 face="sans-serif">16/04/2002 04:24</font>
<br><font size=1 face="sans-serif">Please respond to &quot;Christian Huitema&quot;</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;&quot;Sean Olson&quot; &lt;seancolson@yahoo.com&gt;, &lt;simple@mailman.dynamicsoft.com&gt;, &lt;impp@iastate.edu&gt;, Avshalom Houri/Haifa/IBM@IBMIL</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;RE: [Simple] Status summary</font>
<br>
<br><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp;</font></table>
<br>
<br><font size=2 face="Courier New">Undisclosed is not a state. When someone is &quot;invisible&quot;, they appear<br>
&quot;off line&quot; (closed) to third parties. You definitely don't want a code<br>
point that would say &quot;X is online but would like to appear offline&quot;.<br>
<br>
-- Christian Huitema<br>
<br>
&gt; -----Original Message-----<br>
&gt; From: Sean Olson [mailto:seancolson@yahoo.com]<br>
&gt; Sent: Monday, April 15, 2002 10:54 AM<br>
&gt; To: simple@mailman.dynamicsoft.com; impp@iastate.edu; Avshalom Houri<br>
&gt; Subject: Re: [Simple] Status summary<br>
&gt; <br>
&gt; There seems to be a common thread here where<br>
&gt; we can map communication status (presence) to<br>
&gt; one of three states:<br>
&gt; <br>
&gt; &nbsp; &nbsp;open,<br>
&gt; &nbsp; &nbsp;closed,<br>
&gt; &nbsp; &nbsp;undisclosed (invisible)<br>
&gt; <br>
&gt; Is there a fourth type of state I am missing?<br>
&gt; <br>
&gt; /sean<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; =====<br>
&gt; Sean Olson &lt;seancolson@yahoo.com&gt;<br>
&gt; <br>
&gt; __________________________________________________<br>
&gt; Do You Yahoo!?<br>
&gt; Yahoo! Tax Center - online filing with TurboTax<br>
&gt; http://taxes.yahoo.com/<br>
&gt; _______________________________________________<br>
&gt; simple mailing list<br>
&gt; simple@mailman.dynamicsoft.com<br>
&gt; http://mailman.dynamicsoft.com/mailman/listinfo/simple<br>
<br>
<br>
<br>
 &nbsp;[reminder: meta-impp@iastate.edu for non-technical discussions, please]<br>
<br>
</font>
<br>
<br>
--=_alternative 003BCA26C2256B9D_=--
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Tue Apr 16 13:53:08 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26106
	for <simple-archive@odin.ietf.org>; Tue, 16 Apr 2002 13:53:08 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3GHmsDE013048;
	Tue, 16 Apr 2002 13:48:54 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06012;
	Tue, 16 Apr 2002 13:52:07 -0400 (EDT)
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA03364
	for <simple@mailman.dynamicsoft.com>; Mon, 15 Apr 2002 21:29:39 -0400 (EDT)
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 15 Apr 2002 18:28:36 -0700
Received: from 157.54.6.150 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 15 Apr 2002 18:28:37 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 15 Apr 2002 18:28:37 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 15 Apr 2002 18:28:32 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0);
	 Mon, 15 Apr 2002 18:24:57 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [Simple] Status summary
Message-ID: <F66A04C29AD9034A8205949AD0C90104032702C9@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: [Simple] Status summary
Thread-Index: AcHkpkaGBNWB4oCgSyCXHPelz0sCrQAP2jqg
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "Sean Olson" <seancolson@yahoo.com>, <simple@mailman.dynamicsoft.com>,
        <impp@iastate.edu>, "Avshalom Houri" <AVSHALOM@il.ibm.com>
X-OriginalArrivalTime: 16 Apr 2002 01:24:57.0319 (UTC) FILETIME=[85016770:01C1E4E5]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id VAA03364
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Mon, 15 Apr 2002 18:24:56 -0700
Content-Transfer-Encoding: 8bit

Undisclosed is not a state. When someone is "invisible", they appear
"off line" (closed) to third parties. You definitely don't want a code
point that would say "X is online but would like to appear offline".

-- Christian Huitema

> -----Original Message-----
> From: Sean Olson [mailto:seancolson@yahoo.com]
> Sent: Monday, April 15, 2002 10:54 AM
> To: simple@mailman.dynamicsoft.com; impp@iastate.edu; Avshalom Houri
> Subject: Re: [Simple] Status summary
> 
> There seems to be a common thread here where
> we can map communication status (presence) to
> one of three states:
> 
>    open,
>    closed,
>    undisclosed (invisible)
> 
> Is there a fourth type of state I am missing?
> 
> /sean
> 
> 
> 
> =====
> Sean Olson <seancolson@yahoo.com>
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Tax Center - online filing with TurboTax
> http://taxes.yahoo.com/
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Tue Apr 16 13:58:32 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26730
	for <simple-archive@odin.ietf.org>; Tue, 16 Apr 2002 13:58:32 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3GHq2DE013130;
	Tue, 16 Apr 2002 13:52:02 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06036;
	Tue, 16 Apr 2002 13:55:24 -0400 (EDT)
Received: from imail01.net2phone.com (imail01.net2phone.com [66.33.145.25])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05302
	for <simple@mailman.dynamicsoft.com>; Tue, 16 Apr 2002 09:29:00 -0400 (EDT)
Received: from mailsvr.net2phone.com (exchange.net2phone.com [216.53.60.1])
	by imail01.net2phone.com (8.12.2/8.12.2) with ESMTP id g3GDPPuc026439;
	Tue, 16 Apr 2002 09:25:25 -0400 (EDT)
Received: by mailsvr with Internet Mail Service (5.5.2653.19)
	id <2FHSMLZB>; Tue, 16 Apr 2002 09:26:27 -0400
Message-ID: <E816464C8D279D4D9582952E29FBDC3A0AB78D@mail03.ewr2.n2pcorp.com>
From: Tom  Karlo <tkarlo@net2phone.com>
To: "'Avshalom Houri'" <AVSHALOM@il.ibm.com>,
        Henning Schulzrinne
	 <hgs@cs.columbia.edu>
Cc: impp@iastate.edu, simple@mailman.dynamicsoft.com,
        Peter Saint-Andre
	 <stpeter@jabber.org>, Tony Hansen <tony@att.com>
Subject: RE: [Simple] Status summary
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1E549.D475FC80"
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Tue, 16 Apr 2002 09:23:00 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1E549.D475FC80
Content-Type: text/plain

Actually, the latest Windows Messenger has been SIP-based for a while now (6
months?) My company is one of the carriers providing support. You might have
to check the XP messenger, although I do believe 4.6 would be the right one.
If you get the version where when making a phone call, you're given a list
of services to choose from, then that's the SIP one. The old one only
allowed you to use the Net2Phone protocol.
 
Tom Karlo
Net2Phone
 
-----Original Message-----
From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com] 
Sent: Tuesday, April 16, 2002 6:39 AM
To: Henning Schulzrinne
Cc: impp@iastate.edu; simple@mailman.dynamicsoft.com; Peter Saint-Andre;
Tony Hansen
Subject: Re: [Simple] Status summary
 

I was checking the Windows messenger version 4.6. As far as I know: 
        * This version is based on the MSN protocol and not SIP. 
        * The SIP client is not publically available yet. 

Avshalom Houri
Presence and Instant Messaging Architect
Lotus Sametime, IBM Software Group
avshalom@il.ibm.com





 
Henning Schulzrinne <hgs@cs.columbia.edu> 
16/04/2002 00:26 
Please respond to Henning Schulzrinne 
        
        To:        Peter Saint-Andre <stpeter@jabber.org> 
        cc:        Tony Hansen <tony@att.com>,
simple@mailman.dynamicsoft.com, impp@iastate.edu, Avshalom
Houri/Haifa/IBM@IBMIL 
        Subject:        Re: [Simple] Status summary 

       


I'm curious: Windows Messenger, supposedly using SIP and IMPP presence,
has a bunch of status indications, similar to the ones mentioned on the
list (lunch, do not disturb, etc.). How are they encoded?

Peter Saint-Andre wrote:
> 
> FWIW, we provide the following statuses (stati?) in Jabber:
> 
> 1. Unavailable (maps to CLOSED)
> 
> 2. Available (maps to OPEN) with sub-statuses:
>    - away
>    - extended away
>    - do not disturb
>    - free/desiring to chat
> 
> 3. Invisible
> 
> Any status can be extended with a natural-language description of the
> status.
> 
> More information at
> http://www.jabber.org/ietf/draft-miller-jabber-00.html#common-presence



------_=_NextPart_001_01C1E549.D475FC80
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">




<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C1E528.A866B380">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:DontDisplayPageBoundaries/>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:UseFELayout/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-alt:\5B8B\4F53;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
@font-face
	{font-family:sans-serif;
	panose-1:0 0 0 0 0 0 0 0 0 0;
	mso-font-alt:"Times New Roman";
	mso-font-charset:0;
	mso-generic-font-family:roman;
	mso-font-format:other;
	mso-font-pitch:auto;
	mso-font-signature:0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:SimSun;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:SimSun;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Actually, the latest Windows =
Messenger has
been SIP-based for a while now (6 months?) My company is one of the =
carriers
providing support. You might have to check the XP messenger, although I =
do believe
4.6 would be the right one. If you get the version where when making a =
phone
call, you&#8217;re given a list of services to choose from, then =
that&#8217;s
the SIP one. The old one only allowed you to use the Net2Phone =
protocol.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Tom =
Karlo<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Net2Phone<o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Avshalom Houri
[mailto:AVSHALOM@il.ibm.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, April 16, =
2002 6:39
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Henning =
Schulzrinne<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> impp@iastate.edu;
simple@mailman.dynamicsoft.com; Peter Saint-Andre; Tony Hansen<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: [Simple] =
Status
summary</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0in;margin-right:0in;margin-bottom:
12.0pt;margin-left:.5in'><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><br>
</span></font><font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;
font-family:sans-serif'>I was checking the Windows messenger version =
4.6. As
far as I know:</span></font> <br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>&nbsp;
&nbsp; &nbsp; &nbsp; * This version is based on the MSN protocol and =
not SIP.</span></font>
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>&nbsp;
&nbsp; &nbsp; &nbsp; * The SIP client is not publically available =
yet.</span></font>
<br>
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>Avshalom
Houri<br>
Presence and Instant Messaging Architect<br>
Lotus Sametime, IBM Software Group<br>
avshalom@il.ibm.com<br>
<br>
</span></font><br style=3D'mso-special-character:line-break'>
<![if !supportLineBreakNewLine]><br =
style=3D'mso-special-character:line-break'>
<![endif]><o:p></o:p></p>

<table class=3DMsoNormalTable border=3D0 cellpadding=3D0 width=3D"100%"
 style=3D'width:100.0%;mso-cellspacing:1.5pt;margin-left:.5in'>
 <tr style=3D'mso-yfti-irow:0;mso-yfti-lastrow:yes'>
  <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
  <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span
  style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>
  </td>
  <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
  <p class=3DMsoNormal><b><font size=3D1 face=3Dsans-serif><span =
style=3D'font-size:
  7.5pt;font-family:sans-serif;font-weight:bold'>Henning Schulzrinne
  &lt;hgs@cs.columbia.edu&gt;</span></font></b> <o:p></o:p></p>
  <p><font size=3D1 face=3Dsans-serif><span =
style=3D'font-size:7.5pt;font-family:
  sans-serif'>16/04/2002 00:26</span></font> <br>
  <font size=3D1 face=3Dsans-serif><span =
style=3D'font-size:7.5pt;font-family:sans-serif'>Please
  respond to Henning Schulzrinne</span></font> <o:p></o:p></p>
  </td>
  <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
  <p class=3DMsoNormal><font size=3D1 face=3DArial><span =
style=3D'font-size:7.5pt;
  font-family:Arial'>&nbsp; &nbsp; &nbsp; &nbsp; </span></font><br>
  <font size=3D1 face=3Dsans-serif><span =
style=3D'font-size:7.5pt;font-family:sans-serif'>&nbsp;
  &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;Peter Saint-Andre
  &lt;stpeter@jabber.org&gt;</span></font> <br>
  <font size=3D1 face=3Dsans-serif><span =
style=3D'font-size:7.5pt;font-family:sans-serif'>&nbsp;
  &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;Tony Hansen
  &lt;tony@att.com&gt;, simple@mailman.dynamicsoft.com, =
impp@iastate.edu, Avshalom
  Houri/Haifa/IBM@IBMIL</span></font> <br>
  <font size=3D1 face=3Dsans-serif><span =
style=3D'font-size:7.5pt;font-family:sans-serif'>&nbsp;
  &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: [Simple] =
Status
  summary</span></font> <br>
  <br>
  <font size=3D1 face=3DArial><span =
style=3D'font-size:7.5pt;font-family:Arial'>&nbsp;
  &nbsp; &nbsp; &nbsp;</span></font><o:p></o:p></p>
  </td>
 </tr>
</table>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0in;margin-right:0in;margin-bottom:
12.0pt;margin-left:.5in'><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><br>
<br>
</span></font><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>I'm curious: Windows Messenger, supposedly =
using SIP
and IMPP presence,<br>
has a bunch of status indications, similar to the ones mentioned on =
the<br>
list (lunch, do not disturb, etc.). How are they encoded?<br>
<br>
Peter Saint-Andre wrote:<br>
&gt; <br>
&gt; FWIW, we provide the following statuses (stati?) in Jabber:<br>
&gt; <br>
&gt; 1. Unavailable (maps to CLOSED)<br>
&gt; <br>
&gt; 2. Available (maps to OPEN) with sub-statuses:<br>
&gt; &nbsp; &nbsp;- away<br>
&gt; &nbsp; &nbsp;- extended away<br>
&gt; &nbsp; &nbsp;- do not disturb<br>
&gt; &nbsp; &nbsp;- free/desiring to chat<br>
&gt; <br>
&gt; 3. Invisible<br>
&gt; <br>
&gt; Any status can be extended with a natural-language description of =
the<br>
&gt; status.<br>
&gt; <br>
&gt; More information at<br>
&gt; =
http://www.jabber.org/ietf/draft-miller-jabber-00.html#common-presence<b=
r
style=3D'mso-special-character:line-break'>
<![if !supportLineBreakNewLine]><br =
style=3D'mso-special-character:line-break'>
<![endif]></span></font><o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01C1E549.D475FC80--
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Tue Apr 16 15:09:57 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05587
	for <simple-archive@odin.ietf.org>; Tue, 16 Apr 2002 15:09:56 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3GJ2mDE013762;
	Tue, 16 Apr 2002 15:02:48 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06295;
	Tue, 16 Apr 2002 15:06:05 -0400 (EDT)
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06281;
	Tue, 16 Apr 2002 15:05:03 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id VAA12580;
	Tue, 16 Apr 2002 21:03:28 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3GJ3Np179242;
	Tue, 16 Apr 2002 21:03:23 +0200
To: Tom Karlo <tkarlo@net2phone.com>
Cc: Henning Schulzrinne <hgs@cs.columbia.edu>, impp@iastate.edu,
        simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com,
        Peter Saint-Andre <stpeter@jabber.org>, Tony Hansen <tony@att.com>
MIME-Version: 1.0
Subject: RE: [Simple] Status summary
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF359CF956.7DCE2DB3-ONC2256B9D.006839EB@telaviv.ibm.com>
From: "Avshalom Houri" <AVSHALOM@il.ibm.com>
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at
 16/04/2002 22:03:27,
	Serialize complete at 16/04/2002 22:03:27
Content-Type: multipart/alternative; boundary="=_alternative 0068ACD3C2256B9D_="
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Tue, 16 Apr 2002 22:03:20 +0300

This is a multipart message in MIME format.
--=_alternative 0068ACD3C2256B9D_=
Content-Type: text/plain; charset="Windows-1255"
Content-Transfer-Encoding: base64

V2hhdCBpcyBzaXAgYmFzZWQgaW4gdGhlIFhQIFdpbmRvd3MgbWVzc2VuZ2VyIGlzIGluIHRoZSBW
T0lQIHBhcnQuIFRoZSBQSU0gDQpwYXJ0IGlzIHN0aWxsIHVzaW5nIHRoZSBNU04gcHJvdG9jb2wg
KFZFUiAxMTkpIGFzIGNhbiBiZSBzZWVuIGlmIHlvdSBsb29rIA0KYXQgdGhlIHBhY2tldHMgaXQg
c2VuZHMuDQoNCkF2c2hhbG9tIEhvdXJpDQpQcmVzZW5jZSBhbmQgSW5zdGFudCBNZXNzYWdpbmcg
QXJjaGl0ZWN0DQpMb3R1cyBTYW1ldGltZSwgSUJNIFNvZnR3YXJlIEdyb3VwDQphdnNoYWxvbUBp
bC5pYm0uY29tDQoNCg0KDQoNCg0KDQpUb20gIEthcmxvIDx0a2FybG9AbmV0MnBob25lLmNvbT4N
ClNlbnQgYnk6IHNpbXBsZS1hZG1pbkBtYWlsbWFuLmR5bmFtaWNzb2Z0LmNvbQ0KMTYvMDQvMjAw
MiAxNjoyMw0KUGxlYXNlIHJlc3BvbmQgdG8gVG9tICBLYXJsbw0KDQogDQogICAgICAgIFRvOiAg
ICAgICAgQXZzaGFsb20gSG91cmkvSGFpZmEvSUJNQElCTUlMLCBIZW5uaW5nIFNjaHVsenJpbm5l
IDxoZ3NAY3MuY29sdW1iaWEuZWR1Pg0KICAgICAgICBjYzogICAgICAgIGltcHBAaWFzdGF0ZS5l
ZHUsIHNpbXBsZUBtYWlsbWFuLmR5bmFtaWNzb2Z0LmNvbSwgUGV0ZXIgU2FpbnQtQW5kcmUgDQo8
c3RwZXRlckBqYWJiZXIub3JnPiwgVG9ueSBIYW5zZW4gPHRvbnlAYXR0LmNvbT4NCiAgICAgICAg
U3ViamVjdDogICAgICAgIFJFOiBbU2ltcGxlXSBTdGF0dXMgc3VtbWFyeQ0KDQogDQoNCkFjdHVh
bGx5LCB0aGUgbGF0ZXN0IFdpbmRvd3MgTWVzc2VuZ2VyIGhhcyBiZWVuIFNJUC1iYXNlZCBmb3Ig
YSB3aGlsZSBub3cgDQooNiBtb250aHM/KSBNeSBjb21wYW55IGlzIG9uZSBvZiB0aGUgY2Fycmll
cnMgcHJvdmlkaW5nIHN1cHBvcnQuIFlvdSBtaWdodCANCmhhdmUgdG8gY2hlY2sgdGhlIFhQIG1l
c3NlbmdlciwgYWx0aG91Z2ggSSBkbyBiZWxpZXZlIDQuNiB3b3VsZCBiZSB0aGUgDQpyaWdodCBv
bmUuIElmIHlvdSBnZXQgdGhlIHZlcnNpb24gd2hlcmUgd2hlbiBtYWtpbmcgYSBwaG9uZSBjYWxs
LCB5b3WScmUgDQpnaXZlbiBhIGxpc3Qgb2Ygc2VydmljZXMgdG8gY2hvb3NlIGZyb20sIHRoZW4g
dGhhdJJzIHRoZSBTSVAgb25lLiBUaGUgb2xkIA0Kb25lIG9ubHkgYWxsb3dlZCB5b3UgdG8gdXNl
IHRoZSBOZXQyUGhvbmUgcHJvdG9jb2wuDQogDQpUb20gS2FybG8NCk5ldDJQaG9uZQ0KIA0KLS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEF2c2hhbG9tIEhvdXJpIFttYWlsdG86QVZT
SEFMT01AaWwuaWJtLmNvbV0gDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAxNiwgMjAwMiA2OjM5IEFN
DQpUbzogSGVubmluZyBTY2h1bHpyaW5uZQ0KQ2M6IGltcHBAaWFzdGF0ZS5lZHU7IHNpbXBsZUBt
YWlsbWFuLmR5bmFtaWNzb2Z0LmNvbTsgUGV0ZXIgU2FpbnQtQW5kcmU7IFRvbnkgDQpIYW5zZW4N
ClN1YmplY3Q6IFJlOiBbU2ltcGxlXSBTdGF0dXMgc3VtbWFyeQ0KIA0KDQpJIHdhcyBjaGVja2lu
ZyB0aGUgV2luZG93cyBtZXNzZW5nZXIgdmVyc2lvbiA0LjYuIEFzIGZhciBhcyBJIGtub3c6IA0K
ICAgICAgICAqIFRoaXMgdmVyc2lvbiBpcyBiYXNlZCBvbiB0aGUgTVNOIHByb3RvY29sIGFuZCBu
b3QgU0lQLiANCiAgICAgICAgKiBUaGUgU0lQIGNsaWVudCBpcyBub3QgcHVibGljYWxseSBhdmFp
bGFibGUgeWV0LiANCg0KQXZzaGFsb20gSG91cmkNClByZXNlbmNlIGFuZCBJbnN0YW50IE1lc3Nh
Z2luZyBBcmNoaXRlY3QNCkxvdHVzIFNhbWV0aW1lLCBJQk0gU29mdHdhcmUgR3JvdXANCmF2c2hh
bG9tQGlsLmlibS5jb20NCg0KDQoNCg0KIA0KSGVubmluZyBTY2h1bHpyaW5uZSA8aGdzQGNzLmNv
bHVtYmlhLmVkdT4gDQoxNi8wNC8yMDAyIDAwOjI2IA0KUGxlYXNlIHJlc3BvbmQgdG8gSGVubmlu
ZyBTY2h1bHpyaW5uZSANCiAgICAgICAgDQogICAgICAgIFRvOiAgICAgICAgUGV0ZXIgU2FpbnQt
QW5kcmUgPHN0cGV0ZXJAamFiYmVyLm9yZz4gDQogICAgICAgIGNjOiAgICAgICAgVG9ueSBIYW5z
ZW4gPHRvbnlAYXR0LmNvbT4sIA0Kc2ltcGxlQG1haWxtYW4uZHluYW1pY3NvZnQuY29tLCBpbXBw
QGlhc3RhdGUuZWR1LCBBdnNoYWxvbSANCkhvdXJpL0hhaWZhL0lCTUBJQk1JTCANCiAgICAgICAg
U3ViamVjdDogICAgICAgIFJlOiBbU2ltcGxlXSBTdGF0dXMgc3VtbWFyeSANCg0KIA0KDQoNCkkn
bSBjdXJpb3VzOiBXaW5kb3dzIE1lc3Nlbmdlciwgc3VwcG9zZWRseSB1c2luZyBTSVAgYW5kIElN
UFAgcHJlc2VuY2UsDQpoYXMgYSBidW5jaCBvZiBzdGF0dXMgaW5kaWNhdGlvbnMsIHNpbWlsYXIg
dG8gdGhlIG9uZXMgbWVudGlvbmVkIG9uIHRoZQ0KbGlzdCAobHVuY2gsIGRvIG5vdCBkaXN0dXJi
LCBldGMuKS4gSG93IGFyZSB0aGV5IGVuY29kZWQ/DQoNClBldGVyIFNhaW50LUFuZHJlIHdyb3Rl
Og0KPiANCj4gRldJVywgd2UgcHJvdmlkZSB0aGUgZm9sbG93aW5nIHN0YXR1c2VzIChzdGF0aT8p
IGluIEphYmJlcjoNCj4gDQo+IDEuIFVuYXZhaWxhYmxlIChtYXBzIHRvIENMT1NFRCkNCj4gDQo+
IDIuIEF2YWlsYWJsZSAobWFwcyB0byBPUEVOKSB3aXRoIHN1Yi1zdGF0dXNlczoNCj4gICAgLSBh
d2F5DQo+ICAgIC0gZXh0ZW5kZWQgYXdheQ0KPiAgICAtIGRvIG5vdCBkaXN0dXJiDQo+ICAgIC0g
ZnJlZS9kZXNpcmluZyB0byBjaGF0DQo+IA0KPiAzLiBJbnZpc2libGUNCj4gDQo+IEFueSBzdGF0
dXMgY2FuIGJlIGV4dGVuZGVkIHdpdGggYSBuYXR1cmFsLWxhbmd1YWdlIGRlc2NyaXB0aW9uIG9m
IHRoZQ0KPiBzdGF0dXMuDQo+IA0KPiBNb3JlIGluZm9ybWF0aW9uIGF0DQo+IGh0dHA6Ly93d3cu
amFiYmVyLm9yZy9pZXRmL2RyYWZ0LW1pbGxlci1qYWJiZXItMDAuaHRtbCNjb21tb24tcHJlc2Vu
Y2UNCg0KDQoNCg==
--=_alternative 0068ACD3C2256B9D_=
Content-Type: text/html; charset="Windows-1255"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldoYXQgaXMgc2lwIGJhc2VkIGlu
IHRoZSBYUCBXaW5kb3dzIG1lc3NlbmdlciBpcyBpbiB0aGUgVk9JUCBwYXJ0LiBUaGUgUElNIHBh
cnQgaXMgc3RpbGwgdXNpbmcgdGhlIE1TTiBwcm90b2NvbCAoVkVSIDExOSkgYXMgY2FuIGJlIHNl
ZW4gaWYgeW91IGxvb2sgYXQgdGhlIHBhY2tldHMgaXQgc2VuZHMuPC9mb250Pg0KPGJyPg0KPGJy
Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5BdnNoYWxvbSBIb3VyaTxicj4NClByZXNl
bmNlIGFuZCBJbnN0YW50IE1lc3NhZ2luZyBBcmNoaXRlY3Q8YnI+DQpMb3R1cyBTYW1ldGltZSwg
SUJNIFNvZnR3YXJlIEdyb3VwPGJyPg0KYXZzaGFsb21AaWwuaWJtLmNvbTxicj4NCjxicj4NCjwv
Zm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10
b3A+DQo8dGQ+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPlRvbSAmbmJz
cDtLYXJsbyAmbHQ7dGthcmxvQG5ldDJwaG9uZS5jb20mZ3Q7PC9iPjwvZm9udD4NCjxicj48Zm9u
dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+U2VudCBieTogc2ltcGxlLWFkbWluQG1haWxtYW4u
ZHluYW1pY3NvZnQuY29tPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi
PjE2LzA0LzIwMDIgMTY6MjM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy
aWYiPlBsZWFzZSByZXNwb25kIHRvIFRvbSAmbmJzcDtLYXJsbzwvZm9udD4NCjxicj4NCjx0ZD48
Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8L2Zv
bnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyBUbzogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QXZzaGFsb20gSG91cmkv
SGFpZmEvSUJNQElCTUlMLCBIZW5uaW5nIFNjaHVsenJpbm5lICZsdDtoZ3NAY3MuY29sdW1iaWEu
ZWR1Jmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNjOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbXBw
QGlhc3RhdGUuZWR1LCBzaW1wbGVAbWFpbG1hbi5keW5hbWljc29mdC5jb20sIFBldGVyIFNhaW50
LUFuZHJlICZsdDtzdHBldGVyQGphYmJlci5vcmcmZ3Q7LCBUb255IEhhbnNlbiAmbHQ7dG9ueUBh
dHQuY29tJmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFN1YmplY3Q6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwO1JFOiBbU2ltcGxlXSBTdGF0dXMgc3VtbWFyeTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz
aXplPTEgZmFjZT0iQXJpYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvZm9udD48L3Rh
YmxlPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkFyaWFsIj5B
Y3R1YWxseSwgdGhlIGxhdGVzdCBXaW5kb3dzIE1lc3NlbmdlciBoYXMgYmVlbiBTSVAtYmFzZWQg
Zm9yIGEgd2hpbGUgbm93ICg2IG1vbnRocz8pIE15IGNvbXBhbnkgaXMgb25lIG9mIHRoZSBjYXJy
aWVycyBwcm92aWRpbmcgc3VwcG9ydC4gWW91IG1pZ2h0IGhhdmUgdG8gY2hlY2sgdGhlIFhQIG1l
c3NlbmdlciwgYWx0aG91Z2ggSSBkbyBiZWxpZXZlIDQuNiB3b3VsZCBiZSB0aGUgcmlnaHQgb25l
LiBJZiB5b3UgZ2V0IHRoZSB2ZXJzaW9uIHdoZXJlIHdoZW4gbWFraW5nIGEgcGhvbmUgY2FsbCwg
eW91knJlIGdpdmVuIGEgbGlzdCBvZiBzZXJ2aWNlcyB0byBjaG9vc2UgZnJvbSwgdGhlbiB0aGF0
knMgdGhlIFNJUCBvbmUuIFRoZSBvbGQgb25lIG9ubHkgYWxsb3dlZCB5b3UgdG8gdXNlIHRoZSBO
ZXQyUGhvbmUgcHJvdG9jb2wuPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAg
ZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCjxwPjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgw
IGZhY2U9IkFyaWFsIj5Ub20gS2FybG88L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIgY29sb3I9IzAw
MDA4MCBmYWNlPSJBcmlhbCI+TmV0MlBob25lPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGNvbG9y
PSMwMDAwODAgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCjxwPjxmb250IHNpemU9MiBmYWNl
PSJUYWhvbWEiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGI+PGJyPg0KRnJvbTo8L2I+IEF2
c2hhbG9tIEhvdXJpIFttYWlsdG86QVZTSEFMT01AaWwuaWJtLmNvbV0gPGI+PGJyPg0KU2VudDo8
L2I+IFR1ZXNkYXksIEFwcmlsIDE2LCAyMDAyIDY6MzkgQU08Yj48YnI+DQpUbzo8L2I+IEhlbm5p
bmcgU2NodWx6cmlubmU8Yj48YnI+DQpDYzo8L2I+IGltcHBAaWFzdGF0ZS5lZHU7IHNpbXBsZUBt
YWlsbWFuLmR5bmFtaWNzb2Z0LmNvbTsgUGV0ZXIgU2FpbnQtQW5kcmU7IFRvbnkgSGFuc2VuPGI+
PGJyPg0KU3ViamVjdDo8L2I+IFJlOiBbU2ltcGxlXSBTdGF0dXMgc3VtbWFyeTwvZm9udD4NCjxw
Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxwPjxm
b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpJIHdhcyBjaGVja2luZyB0aGUgV2lu
ZG93cyBtZXNzZW5nZXIgdmVyc2lvbiA0LjYuIEFzIGZhciBhcyBJIGtub3c6PC9mb250Pjxmb250
IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9
InNhbnMtc2VyaWYiPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsqIFRoaXMgdmVy
c2lvbiBpcyBiYXNlZCBvbiB0aGUgTVNOIHByb3RvY29sIGFuZCBub3QgU0lQLjwvZm9udD48Zm9u
dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNl
PSJzYW5zLXNlcmlmIj48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7KiBUaGUgU0lQ
IGNsaWVudCBpcyBub3QgcHVibGljYWxseSBhdmFpbGFibGUgeWV0LjwvZm9udD48Zm9udCBzaXpl
PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNl
PSJzYW5zLXNlcmlmIj48YnI+DQpBdnNoYWxvbSBIb3VyaTxicj4NClByZXNlbmNlIGFuZCBJbnN0
YW50IE1lc3NhZ2luZyBBcmNoaXRlY3Q8YnI+DQpMb3R1cyBTYW1ldGltZSwgSUJNIFNvZnR3YXJl
IEdyb3VwPGJyPg0KYXZzaGFsb21AaWwuaWJtLmNvbTxicj4NCjwvZm9udD48Zm9udCBzaXplPTMg
ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8cD4NCjx0YWJsZSB3
aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MSU+PGZvbnQgc2l6ZT0zIGZh
Y2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPHRkIHdpZHRoPTI4JT48Zm9udCBz
aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+SGVubmluZyBTY2h1bHpyaW5uZSAmbHQ7aGdzQGNz
LmNvbHVtYmlhLmVkdSZndDs8L2I+PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcg
Um9tYW4iPiA8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MTYvMDQv
MjAwMiAwMDoyNjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9m
b250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpQbGVhc2UgcmVzcG9uZCB0
byBIZW5uaW5nIFNjaHVsenJpbm5lPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcg
Um9tYW4iPiA8L2ZvbnQ+DQo8dGQgd2lkdGg9NzAlPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu
cy1zZXJpZiI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RvOiAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDtQZXRlciBTYWludC1BbmRyZSAmbHQ7c3RwZXRlckBqYWJiZXIub3Jn
Jmd0OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxm
b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7Y2M6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RvbnkgSGFuc2VuICZsdDt0b255
QGF0dC5jb20mZ3Q7LCBzaW1wbGVAbWFpbG1hbi5keW5hbWljc29mdC5jb20sIGltcHBAaWFzdGF0
ZS5lZHUsIEF2c2hhbG9tIEhvdXJpL0hhaWZhL0lCTUBJQk1JTDwvZm9udD48Zm9udCBzaXplPTMg
ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl
cmlmIj48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7U3ViamVjdDogJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7UmU6IFtTaW1wbGVdIFN0YXR1cyBzdW1tYXJ5PC9mb250Pjxmb250
IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0x
IGZhY2U9IkFyaWFsIj48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgPC9mb250PjwvdGFibGU+
DQo8cD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQo8L2ZvbnQ+PGZv
bnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpJJ20gY3VyaW91czogV2luZG93cyBN
ZXNzZW5nZXIsIHN1cHBvc2VkbHkgdXNpbmcgU0lQIGFuZCBJTVBQIHByZXNlbmNlLDxicj4NCmhh
cyBhIGJ1bmNoIG9mIHN0YXR1cyBpbmRpY2F0aW9ucywgc2ltaWxhciB0byB0aGUgb25lcyBtZW50
aW9uZWQgb24gdGhlPGJyPg0KbGlzdCAobHVuY2gsIGRvIG5vdCBkaXN0dXJiLCBldGMuKS4gSG93
IGFyZSB0aGV5IGVuY29kZWQ/PGJyPg0KPGJyPg0KUGV0ZXIgU2FpbnQtQW5kcmUgd3JvdGU6PGJy
Pg0KJmd0OyA8YnI+DQomZ3Q7IEZXSVcsIHdlIHByb3ZpZGUgdGhlIGZvbGxvd2luZyBzdGF0dXNl
cyAoc3RhdGk/KSBpbiBKYWJiZXI6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDEuIFVuYXZhaWxhYmxl
IChtYXBzIHRvIENMT1NFRCk8YnI+DQomZ3Q7IDxicj4NCiZndDsgMi4gQXZhaWxhYmxlIChtYXBz
IHRvIE9QRU4pIHdpdGggc3ViLXN0YXR1c2VzOjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOy0gYXdh
eTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOy0gZXh0ZW5kZWQgYXdheTxicj4NCiZndDsgJm5ic3A7
ICZuYnNwOy0gZG8gbm90IGRpc3R1cmI8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDstIGZyZWUvZGVz
aXJpbmcgdG8gY2hhdDxicj4NCiZndDsgPGJyPg0KJmd0OyAzLiBJbnZpc2libGU8YnI+DQomZ3Q7
IDxicj4NCiZndDsgQW55IHN0YXR1cyBjYW4gYmUgZXh0ZW5kZWQgd2l0aCBhIG5hdHVyYWwtbGFu
Z3VhZ2UgZGVzY3JpcHRpb24gb2YgdGhlPGJyPg0KJmd0OyBzdGF0dXMuPGJyPg0KJmd0OyA8YnI+
DQomZ3Q7IE1vcmUgaW5mb3JtYXRpb24gYXQ8YnI+DQomZ3Q7IGh0dHA6Ly93d3cuamFiYmVyLm9y
Zy9pZXRmL2RyYWZ0LW1pbGxlci1qYWJiZXItMDAuaHRtbCNjb21tb24tcHJlc2VuY2U8YnI+DQo8
L2ZvbnQ+DQo8cD4NCjxwPg0K
--=_alternative 0068ACD3C2256B9D_=--
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Tue Apr 16 16:21:36 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14237
	for <simple-archive@odin.ietf.org>; Tue, 16 Apr 2002 16:21:36 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3GKDiDE014505;
	Tue, 16 Apr 2002 16:13:44 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06510;
	Tue, 16 Apr 2002 16:17:04 -0400 (EDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06499
	for <simple@mailman.dynamicsoft.com>; Tue, 16 Apr 2002 16:16:29 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA25239;
	Tue, 16 Apr 2002 16:15:27 -0400 (EDT)
Received: from cs.columbia.edu (slip-32-102-22-19.md.us.prserv.net [32.102.22.19])
	(authenticated bits=0)
	by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g3GKFNPm004869
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Tue, 16 Apr 2002 16:15:26 -0400 (EDT)
Message-ID: <3CBC862E.BBEE9922@cs.columbia.edu>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com, impp@iastate.edu
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [Simple] Windows messenger
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Tue, 16 Apr 2002 16:14:38 -0400
Content-Transfer-Encoding: 7bit

Xiaotao Wu in my lab just ran windump and confirmed that Windows
Messenger Version 4.6(4.6.0077) uses SIP for NOTIFY, REGISTER,
SUBSCRIBE. For the "proof", see the message dumps at
http://www.cs.columbia.edu/sip/drafts/messenger.txt

To answer my own question: Messenger embraces and extends XPIDF:

<presence>
<presentity uri="sip:xiaotaow@cs.columbia.edu;method=SUBSCRIBE" />
<atom id="1003">
<address uri="sip:128.59.19.251:13170;user=ip" priority="0.800000">
<status status="open" />
<msnsubstatus substatus="online" />
</address>
</atom>
</presence>
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Tue Apr 16 18:52:35 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00741
	for <simple-archive@lists.ietf.org>; Tue, 16 Apr 2002 18:52:34 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3GMkkDE015744;
	Tue, 16 Apr 2002 18:46:46 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06936;
	Tue, 16 Apr 2002 18:50:05 -0400 (EDT)
Received: from jppxy1.proxy.att.com ([192.20.246.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06923
	for <simple@mailman.dynamicsoft.com>; Tue, 16 Apr 2002 18:49:35 -0400 (EDT)
Received: from maillennium.att.com ([135.25.114.99])
	by jppxy1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g3GMmWC18474
	for <simple@mailman.dynamicsoft.com>; Wed, 17 Apr 2002 07:48:33 +0900 (JST)
Received: from att.com (<unknown.domain>[135.210.121.22])
          by maillennium.att.com (mailgw1) with SMTP
          id <20020416224830gw100s10iue>
          (Authid: tony);
          Tue, 16 Apr 2002 22:48:30 +0000
Message-ID: <3CBCA9F0.6090607@att.com>
From: Tony Hansen <tony@att.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: Justin Uberti <juberti@aol.com>
CC: simple@mailman.dynamicsoft.com, impp@iastate.edu
Subject: Re: [Simple] Status summary
References: <NCBBJADBPKLDGGFBHGINCECBDMAA.juberti@aol.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Tue, 16 Apr 2002 18:47:12 -0400
Content-Transfer-Encoding: 7bit

"Away with various configurable messages (CLOSED)" should really be
classified as OPEN, not closed. Although you are away, AOL still passes
messages through to you.

	Tony Hansen
	tony@att.com

Justin Uberti wrote:
 > AOL has open and closed statuses and hints.
 > * Online (OPEN)
 > * Offline (CLOSED)
 > * Away with various configurable messages (CLOSED)
 > * Idle (OPEN)



_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Wed Apr 17 11:08:57 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22271
	for <simple-archive@odin.ietf.org>; Wed, 17 Apr 2002 11:08:56 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3HEdtDE019495;
	Wed, 17 Apr 2002 10:39:55 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09446;
	Wed, 17 Apr 2002 10:43:05 -0400 (EDT)
Received: from imo-d09.mx.aol.com (imo-d09.mx.aol.com [205.188.157.41])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09361
	for <simple@mailman.dynamicsoft.com>; Wed, 17 Apr 2002 10:19:59 -0400 (EDT)
Received: from Juberti@aol.com
	by imo-d09.mx.aol.com (mail_out_v32.5.) id 7.174.6d4a40b (15901);
	Wed, 17 Apr 2002 10:18:25 -0400 (EDT)
Received: from  pcsn602343 ([10.2.115.71]) by air-id09.mx.aol.com (v84.14) with ESMTP id MAILINID94-0417101825; Wed, 17 Apr 2002 10:18:25 -0400
From: "Justin Uberti" <juberti@aol.com>
To: "Tony Hansen" <tony@att.com>
Cc: <simple@mailman.dynamicsoft.com>, <impp@iastate.edu>
Subject: RE: [Simple] Status summary
Message-ID: <NCBBJADBPKLDGGFBHGINKECPDMAA.juberti@aol.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <3CBCA9F0.6090607@att.com>
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Wed, 17 Apr 2002 10:18:25 -0400
Content-Transfer-Encoding: 7bit

Agreed; I had misunderstood the meaning of CLOSED.

Note that being away can cause a message to be routed elsewhere, (e.g. to
your pager if you are away on your desktop), but I suppose this is still
OPEN, since the message is still delivered somewhere.

Justin Uberti
America Online

> -----Original Message-----
> From: owner-impp@iastate.edu [mailto:owner-impp@iastate.edu]On Behalf Of
> tony@att.com
> Sent: Tuesday, April 16, 2002 6:47 PM
> To: Justin Uberti
> Cc: simple@mailman.dynamicsoft.com; impp@iastate.edu
> Subject: Re: [Simple] Status summary
>
>
> "Away with various configurable messages (CLOSED)" should really be
> classified as OPEN, not closed. Although you are away, AOL still passes
> messages through to you.
>
>     Tony Hansen
>     tony@att.com
>
> Justin Uberti wrote:
>  > AOL has open and closed statuses and hints.
>  > * Online (OPEN)
>  > * Offline (CLOSED)
>  > * Away with various configurable messages (CLOSED)
>  > * Idle (OPEN)
>
>
>
>
>
>   [reminder: meta-impp@iastate.edu for non-technical discussions, please]
>
>

_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Wed Apr 17 14:34:21 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00816
	for <simple-archive@odin.ietf.org>; Wed, 17 Apr 2002 14:34:21 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3HIQ2DE021751;
	Wed, 17 Apr 2002 14:26:02 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10083;
	Wed, 17 Apr 2002 14:29:10 -0400 (EDT)
Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10072
	for <simple@mailman.dynamicsoft.com>; Wed, 17 Apr 2002 14:28:50 -0400 (EDT)
Received: from maillennium.att.com ([135.25.114.99])
	by kcmso2.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g3HIRl516027
	for <simple@mailman.dynamicsoft.com>; Wed, 17 Apr 2002 13:27:47 -0500 (CDT)
Received: from att.com (<unknown.domain>[135.210.41.41])
          by maillennium.att.com (mailgw1) with SMTP
          id <20020417182747gw100s10goe>
          (Authid: tony);
          Wed, 17 Apr 2002 18:27:47 +0000
Message-ID: <3CBDBB8D.5000400@att.com>
From: Tony Hansen <tony@att.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2
X-Accept-Language: en-us
MIME-Version: 1.0
CC: simple@mailman.dynamicsoft.com, impp@iastate.edu
Subject: Re: [Simple] Status summary
References: <Pine.LNX.4.10.10204151112580.2567-100000@lor.jeremie.com> <3CBB4583.94152842@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Wed, 17 Apr 2002 14:14:37 -0400
Content-Transfer-Encoding: 7bit

One aspect that hasn't come up yet in this conversation is something 
someone said at the ad-hoc mtg in MN: the temporal aspect of the various 
types of OPEN status messages. Why do you choose to use one message over 
another? Usually it's to give the others an idea of how quickly you'll 
respond.

Some of them mean "I'm doing stuff, but will probably respond to your 
message pretty quickly." (T = a couple minutes) Examples: Busy, On the 
Phone.

Some of them mean "I'm going to be gone for a while." (T = 1/2 - 1 hour) 
Example: Out to Lunch.

Some of them mean "Don't expect me to respond for hours." (T = 2-4 
hours) Example: Away, In Meetings.

Some of them mean "Don't expect me back for a long time." (T > 4 hours) 
Example: Out for the weekend.

When you go international, Out to Lunch doesn't mean a whole lot to 
anyone but English speakers. But specifying an expected time to be gone 
set at .5-1 hour certainly does translate well. Time is a pretty 
universal concept, and might be worth codifying as part of the status 
information.

	Tony Hansen
	tony@att.com

_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Wed Apr 17 14:37:13 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00949
	for <simple-archive@odin.ietf.org>; Wed, 17 Apr 2002 14:37:13 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3HISfDE021821;
	Wed, 17 Apr 2002 14:28:41 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10117;
	Wed, 17 Apr 2002 14:32:04 -0400 (EDT)
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10101
	for <simple@mailman.dynamicsoft.com>; Wed, 17 Apr 2002 14:31:18 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id UAA99332;
	Wed, 17 Apr 2002 20:30:12 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3HIUBL83060;
	Wed, 17 Apr 2002 20:30:11 +0200
To: <simple@mailman.dynamicsoft.com>, <impp@iastate.edu>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF7A26AF0A.6B73C7E0-ONC2256B9E.00644D28@telaviv.ibm.com>
From: "Avshalom Houri" <AVSHALOM@il.ibm.com>
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at
 17/04/2002 21:30:11,
	Serialize complete at 17/04/2002 21:30:11
Content-Type: multipart/alternative; boundary="=_alternative 0065A42EC2256B9E_="
Subject: [Simple] Re: PIDF status values
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Wed, 17 Apr 2002 21:30:13 +0300

This is a multipart message in MIME format.
--=_alternative 0065A42EC2256B9E_=
Content-Type: text/plain; charset="us-ascii"

Following a discussion in the SIMPLE group I am not sure that values such 
as 
"away" or "busy" are really statuses. They seem to be *hints* to the user 
on how 
s/he should anticipate that the message will be handled. The actual 
handling of 
"away" for example can be displaying the message in hidden window in one 
system 
and in other system the message will be displayed in a pop up window.

In parallel it seems that this discussion should be a joint discussion of 
the 
SIMPLE and the IMPP groups.

Avshalom Houri
Presence and Instant Messaging Architect
Lotus Sametime, IBM Software Group
avshalom@il.ibm.com






"Adrian Bateman" <bateman@acm.org>
Sent by: owner-impp@iastate.edu
17/04/2002 13:39
Please respond to "Adrian Bateman"

 
        To:        "'Mark Day'" <markday@cisco.com>, "'Hiroyasu Sugano'" 
<suga@flab.fujitsu.co.jp>, "'Graham Klyne'" <GK@ninebynine.org>
        cc:        <impp@iastate.edu>
        Subject:        PIDF status values

 

This is a draft describing the my proposal for the structure of the
status values within PIDF. My example reflects the urn change
recommended by Graham and the use of the 'entity' attribute as discussed
previously on the list.

When it came down to it, I couldn't think of a tremendous amount to
write for the 4.2.4 section so if there are gaps you'd like mentioned,
please let me know, or fill them in :o).

To address Graham's issue with a status value registry, aren't we
covered by simply registering the xml namespace urn?

Regards,

Adrian.


4.1.4  The <status> element

   The <status> element contains one or more elements indicating status
   values. It can have multiple status values at the same time. By
   allowing multiple status values in a single <tuple> element,
different
   types of status values, e.g. reachability and location, can be
   represented by a <tuple>. See Section 4.3 for an example with
multiple
   status values.

   This memo only defines the <basic> status value element. Other status
   values may be included using the standard extensibility framework
   (see Section 4.2.4). Applications encountering unrecognized elements
   within <status> may ignore them, unless they carry a
mustUnderstand="YES"
   attribute (see section 4.2.3).


4.1.5  The <basic> element

   The <basic> element contains a CDATA value whose possible values are
   either "open" or "closed". The values "open" and "closed" has the
   same meaning as OPEN and CLOSED defined in RFC 2778 respectively, and
   stand for availability of receiving instant messages if the <tuple>
is
   for an instant messaging address. They also have meanings of general
   availability for other communication means. But, this memo does not
   specify them in detail.


---


4.2.4  Status value extensibility

   This memo only defines the <basic> status value with values of "open"
   and "closed". Other status values are possible using the standard
   namespace-based extensibility rules defined above.

   For example, a location status value might be included thus:
 
       <presence xmlns="urn:ietf:params:xml:ns:cpim-pidf"
           xmlns:local="urn:example-com:pidf-status-type"
           entity="pres:someone@example.com">
         <tuple id="im">
           <status>
             <basic>open</basic>
             <local:location>home</local:location>
           </status>
           <contact>im:someone@example.com</contact>
         </tuple>
       </presence>

   Some new status values will 'extend' the value of the <basic>
element.
   For example, a status value defined for use with instant messaging
may
   include values such as 'away', 'busy' and 'offline'. In order that
   some level of interoperability be maintained with user agents that
   don't recognise the new extension, the <basic> status value must also
   be included. This means that extensions are not obligated to define a
   mapping from each of their values to OPEN or CLOSED.




  [reminder: meta-impp@iastate.edu for non-technical discussions, please]




--=_alternative 0065A42EC2256B9E_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Following a discussion in the SIMPLE group I am not sure that values such as </font>
<br><font size=2 face="sans-serif">&quot;away&quot; or &quot;busy&quot; are really statuses. They seem to be *hints* to the user on how </font>
<br><font size=2 face="sans-serif">s/he should anticipate that the message will be handled. The actual handling of </font>
<br><font size=2 face="sans-serif">&quot;away&quot; for example can be displaying the message in hidden window in one system </font>
<br><font size=2 face="sans-serif">and in other system the message will be displayed in a pop up window.</font>
<br>
<br><font size=2 face="sans-serif">In parallel it seems that this discussion should be a joint discussion of the </font>
<br><font size=2 face="sans-serif">SIMPLE and the IMPP groups.</font>
<br>
<br><font size=2 face="sans-serif">Avshalom Houri<br>
Presence and Instant Messaging Architect<br>
Lotus Sametime, IBM Software Group<br>
avshalom@il.ibm.com<br>
<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>&quot;Adrian Bateman&quot; &lt;bateman@acm.org&gt;</b></font>
<br><font size=1 face="sans-serif">Sent by: owner-impp@iastate.edu</font>
<p><font size=1 face="sans-serif">17/04/2002 13:39</font>
<br><font size=1 face="sans-serif">Please respond to &quot;Adrian Bateman&quot;</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;&quot;'Mark Day'&quot; &lt;markday@cisco.com&gt;, &quot;'Hiroyasu Sugano'&quot; &lt;suga@flab.fujitsu.co.jp&gt;, &quot;'Graham Klyne'&quot; &lt;GK@ninebynine.org&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;&lt;impp@iastate.edu&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;PIDF status values</font>
<br>
<br><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp;</font></table>
<br>
<br><font size=2 face="Courier New">This is a draft describing the my proposal for the structure of the<br>
status values within PIDF. My example reflects the urn change<br>
recommended by Graham and the use of the 'entity' attribute as discussed<br>
previously on the list.<br>
<br>
When it came down to it, I couldn't think of a tremendous amount to<br>
write for the 4.2.4 section so if there are gaps you'd like mentioned,<br>
please let me know, or fill them in :o).<br>
<br>
To address Graham's issue with a status value registry, aren't we<br>
covered by simply registering the xml namespace urn?<br>
<br>
Regards,<br>
<br>
Adrian.<br>
<br>
<br>
4.1.4 &nbsp;The &lt;status&gt; element<br>
<br>
 &nbsp; The &lt;status&gt; element contains one or more elements indicating status<br>
 &nbsp; values. It can have multiple status values at the same time. By<br>
 &nbsp; allowing multiple status values in a single &lt;tuple&gt; element,<br>
different<br>
 &nbsp; types of status values, e.g. reachability and location, can be<br>
 &nbsp; represented by a &lt;tuple&gt;. See Section 4.3 for an example with<br>
multiple<br>
 &nbsp; status values.<br>
<br>
 &nbsp; This memo only defines the &lt;basic&gt; status value element. Other status<br>
 &nbsp; values may be included using the standard extensibility framework<br>
 &nbsp; (see Section 4.2.4). Applications encountering unrecognized elements<br>
 &nbsp; within &lt;status&gt; may ignore them, unless they carry a<br>
mustUnderstand=&quot;YES&quot;<br>
 &nbsp; attribute (see section 4.2.3).<br>
<br>
<br>
4.1.5 &nbsp;The &lt;basic&gt; element<br>
<br>
 &nbsp; The &lt;basic&gt; element contains a CDATA value whose possible values are<br>
 &nbsp; either &quot;open&quot; or &quot;closed&quot;. The values &quot;open&quot; and &quot;closed&quot; has the<br>
 &nbsp; same meaning as OPEN and CLOSED defined in RFC 2778 respectively, and<br>
 &nbsp; stand for availability of receiving instant messages if the &lt;tuple&gt;<br>
is<br>
 &nbsp; for an instant messaging address. They also have meanings of general<br>
 &nbsp; availability for other communication means. But, this memo does not<br>
 &nbsp; specify them in detail.<br>
<br>
<br>
---<br>
<br>
<br>
4.2.4 &nbsp;Status value extensibility<br>
<br>
 &nbsp; This memo only defines the &lt;basic&gt; status value with values of &quot;open&quot;<br>
 &nbsp; and &quot;closed&quot;. Other status values are possible using the standard<br>
 &nbsp; namespace-based extensibility rules defined above.<br>
<br>
 &nbsp; For example, a location status value might be included thus:<br>
 &nbsp; <br>
 &nbsp; &nbsp; &nbsp; &lt;presence xmlns=&quot;urn:ietf:params:xml:ns:cpim-pidf&quot;<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; xmlns:local=&quot;urn:example-com:pidf-status-type&quot;<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; entity=&quot;pres:someone@example.com&quot;&gt;<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &lt;tuple id=&quot;im&quot;&gt;<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;status&gt;<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;basic&gt;open&lt;/basic&gt;<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;local:location&gt;home&lt;/local:location&gt;<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/status&gt;<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;contact&gt;im:someone@example.com&lt;/contact&gt;<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &lt;/tuple&gt;</font>
<br><font size=2 face="Courier New">&nbsp; &nbsp; &nbsp; &nbsp;&lt;/presence&gt;<br>
<br>
 &nbsp; Some new status values will 'extend' the value of the &lt;basic&gt;<br>
element.<br>
 &nbsp; For example, a status value defined for use with instant messaging<br>
may<br>
 &nbsp; include values such as 'away', 'busy' and 'offline'. In order that<br>
 &nbsp; some level of interoperability be maintained with user agents that<br>
 &nbsp; don't recognise the new extension, the &lt;basic&gt; status value must also<br>
 &nbsp; be included. This means that extensions are not obligated to define a<br>
 &nbsp; mapping from each of their values to OPEN or CLOSED.<br>
<br>
<br>
<br>
<br>
 &nbsp;[reminder: meta-impp@iastate.edu for non-technical discussions, please]<br>
<br>
</font>
<br>
<br>
--=_alternative 0065A42EC2256B9E_=--
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Wed Apr 17 14:37:18 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00961
	for <simple-archive@odin.ietf.org>; Wed, 17 Apr 2002 14:37:18 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3HIWfDE021919;
	Wed, 17 Apr 2002 14:32:41 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10159;
	Wed, 17 Apr 2002 14:36:04 -0400 (EDT)
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10147
	for <simple@mailman.dynamicsoft.com>; Wed, 17 Apr 2002 14:35:03 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id UAA37058;
	Wed, 17 Apr 2002 20:34:02 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3HIY2l43618;
	Wed, 17 Apr 2002 20:34:02 +0200
To: impp@iastate.edu, simple@mailman.dynamicsoft.com
MIME-Version: 1.0
Subject: Re: [Simple] Windows messenger
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF5EA04F5F.4B1DA913-ONC2256B9E.0065C08C@telaviv.ibm.com>
From: "Avshalom Houri" <AVSHALOM@il.ibm.com>
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at
 17/04/2002 21:34:02,
	Serialize complete at 17/04/2002 21:34:02
Content-Type: multipart/alternative; boundary="=_alternative 0065FEF8C2256B9E_="
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Wed, 17 Apr 2002 21:34:05 +0300

This is a multipart message in MIME format.
--=_alternative 0065FEF8C2256B9E_=
Content-Type: text/plain; charset="us-ascii"

I want to clarify the confusion. I have talked with Jonathan Christensen 
from MS and the status is this: 

The public .NET passport account uses a combination of SIP and  the MSN 
proprietary protocol for IM and presence.  A/V is negotiated with SIP and media is transported with standard RTP.

If you are talking with a SIP server the client talks SIP (you need to 
enable it via Tools/Options/Accounts/Communication Service). 

Avshalom Houri
Presence and Instant Messaging Architect
Lotus Sametime, IBM Software Group
avshalom@il.ibm.com






Henning Schulzrinne <hgs@cs.columbia.edu>
Sent by: simple-admin@mailman.dynamicsoft.com
16/04/2002 23:14
Please respond to Henning Schulzrinne

 
        To:        simple@mailman.dynamicsoft.com, impp@iastate.edu
        cc: 
        Subject:        [Simple] Windows messenger

 

Xiaotao Wu in my lab just ran windump and confirmed that Windows
Messenger Version 4.6(4.6.0077) uses SIP for NOTIFY, REGISTER,
SUBSCRIBE. For the "proof", see the message dumps at
http://www.cs.columbia.edu/sip/drafts/messenger.txt

To answer my own question: Messenger embraces and extends XPIDF:

<presence>
<presentity uri="sip:xiaotaow@cs.columbia.edu;method=SUBSCRIBE" />
<atom id="1003">
<address uri="sip:128.59.19.251:13170;user=ip" priority="0.800000">
<status status="open" />
<msnsubstatus substatus="online" />
</address>
</atom>
</presence>
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple



--=_alternative 0065FEF8C2256B9E_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">I want to clarify the confusion. I have talked with Jonathan Christensen from MS and the status is this:</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
The public .NET passport account uses a combination of SIP and &nbsp;the MSN &nbsp;proprietary protocol for IM and presence.</font><font size=3 face="Times New Roman"> &nbsp;A/V is negotiated with SIP and media is transported with standard RTP.</font><font size=2 face="sans-serif"><br>
</font>
<br><font size=2 face="sans-serif">If you are talking with a SIP server the client talks SIP (you need to enable it via Tools/Options/Accounts/Communication Service).</font><font size=3 face="Times New Roman"> </font>
<br>
<br><font size=2 face="sans-serif">Avshalom Houri<br>
Presence and Instant Messaging Architect<br>
Lotus Sametime, IBM Software Group<br>
avshalom@il.ibm.com<br>
<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>Henning Schulzrinne &lt;hgs@cs.columbia.edu&gt;</b></font>
<br><font size=1 face="sans-serif">Sent by: simple-admin@mailman.dynamicsoft.com</font>
<p><font size=1 face="sans-serif">16/04/2002 23:14</font>
<br><font size=1 face="sans-serif">Please respond to Henning Schulzrinne</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;simple@mailman.dynamicsoft.com, impp@iastate.edu</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;[Simple] Windows messenger</font>
<br>
<br><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp;</font></table>
<br>
<br><font size=2 face="Courier New">Xiaotao Wu in my lab just ran windump and confirmed that Windows<br>
Messenger Version 4.6(4.6.0077) uses SIP for NOTIFY, REGISTER,<br>
SUBSCRIBE. For the &quot;proof&quot;, see the message dumps at<br>
http://www.cs.columbia.edu/sip/drafts/messenger.txt<br>
<br>
To answer my own question: Messenger embraces and extends XPIDF:<br>
<br>
&lt;presence&gt;<br>
&lt;presentity uri=&quot;sip:xiaotaow@cs.columbia.edu;method=SUBSCRIBE&quot; /&gt;<br>
&lt;atom id=&quot;1003&quot;&gt;<br>
&lt;address uri=&quot;sip:128.59.19.251:13170;user=ip&quot; priority=&quot;0.800000&quot;&gt;<br>
&lt;status status=&quot;open&quot; /&gt;<br>
&lt;msnsubstatus substatus=&quot;online&quot; /&gt;<br>
&lt;/address&gt;<br>
&lt;/atom&gt;<br>
&lt;/presence&gt;<br>
_______________________________________________<br>
simple mailing list<br>
simple@mailman.dynamicsoft.com<br>
http://mailman.dynamicsoft.com/mailman/listinfo/simple<br>
</font>
<br>
<br>
--=_alternative 0065FEF8C2256B9E_=--
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Wed Apr 17 14:53:12 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01536
	for <simple-archive@odin.ietf.org>; Wed, 17 Apr 2002 14:53:11 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3HImhDE022159;
	Wed, 17 Apr 2002 14:48:43 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10234;
	Wed, 17 Apr 2002 14:52:04 -0400 (EDT)
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10223
	for <simple@mailman.dynamicsoft.com>; Wed, 17 Apr 2002 14:51:48 -0400 (EDT)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g3HIogX77907;
	Wed, 17 Apr 2002 13:50:42 -0500 (CDT)
From: "Ben Campbell" <bcampbell@dynamicsoft.com>
To: "Tony Hansen" <tony@att.com>
Cc: <simple@mailman.dynamicsoft.com>, <impp@iastate.edu>
Subject: RE: [Simple] Status summary
Message-ID: <HNEOJECGFHIABDLENMMCEEDGCGAA.bcampbell@dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-reply-to: <3CBDBB8D.5000400@att.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Wed, 17 Apr 2002 13:50:18 -0500
Content-Transfer-Encoding: 7bit

It seems to me this concept is still more intended for _human_ consumption.
It would be dangerous to provide any protocol semantic or other automatic
processing based on the assumption that I will be back at a certain time,
unless we build in explicit expiration times for the piece of state.

So, all of the following can be handled by some sort of "away" status that
contains a human readable comment (or some other indicator for user display
purposes only).

> -----Original Message-----
> From: simple-admin@mailman.dynamicsoft.com
> [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Tony Hansen
> Sent: Wednesday, April 17, 2002 1:15 PM
> Cc: simple@mailman.dynamicsoft.com; impp@iastate.edu
> Subject: Re: [Simple] Status summary
>
>
> One aspect that hasn't come up yet in this conversation is something
> someone said at the ad-hoc mtg in MN: the temporal aspect of the various
> types of OPEN status messages. Why do you choose to use one message over
> another? Usually it's to give the others an idea of how quickly you'll
> respond.
>
> Some of them mean "I'm doing stuff, but will probably respond to your
> message pretty quickly." (T = a couple minutes) Examples: Busy, On the
> Phone.
>
> Some of them mean "I'm going to be gone for a while." (T = 1/2 - 1 hour)
> Example: Out to Lunch.
>
> Some of them mean "Don't expect me to respond for hours." (T = 2-4
> hours) Example: Away, In Meetings.
>
> Some of them mean "Don't expect me back for a long time." (T > 4 hours)
> Example: Out for the weekend.
>
> When you go international, Out to Lunch doesn't mean a whole lot to
> anyone but English speakers. But specifying an expected time to be gone
> set at .5-1 hour certainly does translate well. Time is a pretty
> universal concept, and might be worth codifying as part of the status
> information.
>
> 	Tony Hansen
> 	tony@att.com
>
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Wed Apr 17 15:17:49 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02640
	for <simple-archive@odin.ietf.org>; Wed, 17 Apr 2002 15:17:43 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3HJCgDE022449;
	Wed, 17 Apr 2002 15:12:42 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10324;
	Wed, 17 Apr 2002 15:16:04 -0400 (EDT)
Received: from imailg1.svr.pol.co.uk (imailg1.svr.pol.co.uk [195.92.195.179])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10313
	for <simple@mailman.dynamicsoft.com>; Wed, 17 Apr 2002 15:15:51 -0400 (EDT)
Received: from [195.92.168.141] (helo=tmailb1.svr.pol.co.uk)
	by imailg1.svr.pol.co.uk with esmtp (Exim 3.35 #1)
	id 16xutE-0002gM-00; Wed, 17 Apr 2002 20:14:48 +0100
Received: from modem-1152.wolf.dialup.pol.co.uk ([217.134.84.128] helo=ADRIANXP)
	by tmailb1.svr.pol.co.uk with esmtp (Exim 3.35 #1)
	id 16xutA-0007zz-00; Wed, 17 Apr 2002 20:14:44 +0100
Reply-To: <bateman@acm.org>
From: "Adrian Bateman" <bateman@acm.org>
To: "'Avshalom Houri'" <AVSHALOM@il.ibm.com>, <simple@mailman.dynamicsoft.com>,
        <impp@iastate.edu>
Subject: RE: [Simple] Re: PIDF status values
Organization: VisionTech Limited
Message-ID: <000401c1e644$1fbc4000$6405010a@ADRIANXP>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
In-Reply-To: <OF7A26AF0A.6B73C7E0-ONC2256B9E.00644D28@telaviv.ibm.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Wed, 17 Apr 2002 20:14:39 +0100
Content-Transfer-Encoding: 7bit

On 17 April 2002 19:30, Avshalom Houri wrote:
> 
> Following a discussion in the SIMPLE group I am not sure that values 
> such as
> "away" or "busy" are really statuses. They seem to be *hints* to the
user on how 
> s/he should anticipate that the message will be handled. The actual
handling of 
> "away" for example can be displaying the message in hidden window in
one system 
> and in other system the message will be displayed in a pop up window. 

What's the difference between a status value and a hint? RFC 2778
doesn't define a hint, it merely refers to STATUS. In any event, in PIDF
we made a conscious decision to include only OPEN and CLOSED and to
leave the definition of other status ranges for future invention.

It seems to me that the value of some status elements will, perhaps more
often than not, be processed automatically, maybe to determine an icon
to display. These values are well defined and are as much status
information as open/closed, just intended for a different purpose.
Status values aren't limited only to those determining the presentity's
likely acceptance of instant messages. RFC 2778 just says that in that
case (instant messaging) the values OPEN and CLOSED are at minimum
necessary.

The language below uses 'away' and 'busy' simply as examples using words
that many people using current Instant Messaging agents will recognise.
If you'd prefer alternative language, by all means suggest some. My
point is to emphasise that we should maintain the basic open/closed
values for interoperability and that it isn't mandatory to define
mappings from other status ranges to the basic values.

> In parallel it seems that this discussion should be a joint discussion

> of the SIMPLE and the IMPP groups.

Yes, I for one welcome further input. The IMPP group is quiet and there
is much more activity in SIMPLE. In fact, I requested just such
discussion in my message to the SIMPLE list last Friday.

Best regards,

Adrian.

> 
> Avshalom Houri
> Presence and Instant Messaging Architect
> Lotus Sametime, IBM Software Group
> avshalom@il.ibm.com
> 
> 
> 
> 
> 
> 	"Adrian Bateman" <bateman@acm.org>
> Sent by: owner-impp@iastate.edu 
> 
> 17/04/2002 13:39
> Please respond to "Adrian Bateman" 
>         
>         To:        "'Mark Day'" <markday@cisco.com>, "'Hiroyasu
Sugano'" <suga@flab.fujitsu.co.jp>, "'Graham Klyne'" <GK@ninebynine.org>

>         cc:        <impp@iastate.edu> 
>         Subject:        PIDF status values 
> 
>        
> 
> 
> This is a draft describing the my proposal for the structure of the 
> status values within PIDF. My example reflects the urn change 
> recommended by Graham and the use of the 'entity' attribute as 
> discussed previously on the list.
> 
> When it came down to it, I couldn't think of a tremendous amount to 
> write for the 4.2.4 section so if there are gaps you'd like mentioned,

> please let me know, or fill them in :o).
> 
> To address Graham's issue with a status value registry, aren't we 
> covered by simply registering the xml namespace urn?
> 
> Regards,
> 
> Adrian.
> 
> 
> 4.1.4  The <status> element
> 
>   The <status> element contains one or more elements indicating status
>   values. It can have multiple status values at the same time. By
>   allowing multiple status values in a single <tuple> element,
different
>   types of status values, e.g. reachability and location, can be
>   represented by a <tuple>. See Section 4.3 for an example with
multiple
>   status values.
> 
>   This memo only defines the <basic> status value element. Other
status
>   values may be included using the standard extensibility framework
>   (see Section 4.2.4). Applications encountering unrecognized elements
>   within <status> may ignore them, unless they carry a
mustUnderstand="YES"
>   attribute (see section 4.2.3).
> 
> 
> 4.1.5  The <basic> element
> 
>   The <basic> element contains a CDATA value whose possible values are
>   either "open" or "closed". The values "open" and "closed" has the
>   same meaning as OPEN and CLOSED defined in RFC 2778 respectively,
and
>   stand for availability of receiving instant messages if the <tuple>
is
>   for an instant messaging address. They also have meanings of general
>   availability for other communication means. But, this memo does not
>   specify them in detail.
> 
> 
> ---
> 
> 
> 4.2.4  Status value extensibility
> 
>   This memo only defines the <basic> status value with values of
"open"
>   and "closed". Other status values are possible using the standard
>   namespace-based extensibility rules defined above.
> 
>   For example, a location status value might be included thus:
>   
>       <presence xmlns="urn:ietf:params:xml:ns:cpim-pidf"
>           xmlns:local="urn:example-com:pidf-status-type"
>           entity="pres:someone@example.com">
>         <tuple id="im">
>           <status>
>             <basic>open</basic>
>             <local:location>home</local:location>
>           </status>
>           <contact>im:someone@example.com</contact>
>         </tuple> 
>        </presence>
> 
>   Some new status values will 'extend' the value of the <basic>
element.
>   For example, a status value defined for use with instant messaging
may
>   include values such as 'away', 'busy' and 'offline'. In order that
>   some level of interoperability be maintained with user agents that
>   don't recognise the new extension, the <basic> status value must
also
>   be included. This means that extensions are not obligated to define
a
>   mapping from each of their values to OPEN or CLOSED.
> 
> 
> 
> 
>  [reminder: meta-impp@iastate.edu for non-technical discussions, 
> please]
> 
> 
> 
> 
> 


_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Wed Apr 17 15:31:30 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03279
	for <simple-archive@odin.ietf.org>; Wed, 17 Apr 2002 15:31:29 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3HJQnDE022677;
	Wed, 17 Apr 2002 15:26:49 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10390;
	Wed, 17 Apr 2002 15:30:05 -0400 (EDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10377
	for <simple@mailman.dynamicsoft.com>; Wed, 17 Apr 2002 15:29:13 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3HJSNtJ029612;
	Wed, 17 Apr 2002 15:28:24 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAI57885;
	Wed, 17 Apr 2002 15:31:18 -0400 (EDT)
Message-ID: <3CBDCCBF.9DA43CCC@cisco.com>
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ben Campbell <bcampbell@dynamicsoft.com>
CC: Tony Hansen <tony@att.com>, simple@mailman.dynamicsoft.com,
        impp@iastate.edu
Subject: Re: [Simple] Status summary
References: <HNEOJECGFHIABDLENMMCEEDGCGAA.bcampbell@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Wed, 17 Apr 2002 15:27:59 -0400
Content-Transfer-Encoding: 7bit

I see some parallels between open/away/closed and 200/202/4xx.

- "Open" means (sort of) that a MESSAGE should return a 200 - will be displayed and hopefully seen immediately.

- "Away" means (sort of) that a MESSAGE should return a 202 - will be accepted, but may not be displayed, or if displayed may not be seen immediately.

- "Closed" means (sort of) that a MESSAGE should fail because there is nobody willing or able to receive it.

The parallels aren't perfect by any means. E.g. 200 doesn't really mean that the message has been seen. Yet in some sense I think the purpose of the presence status is to
give a hint about what is likely to happen if communication is attempted. Maybe it would be helpful to make better parallels.

	Paul

Ben Campbell wrote:
> 
> It seems to me this concept is still more intended for _human_ consumption.
> It would be dangerous to provide any protocol semantic or other automatic
> processing based on the assumption that I will be back at a certain time,
> unless we build in explicit expiration times for the piece of state.
> 
> So, all of the following can be handled by some sort of "away" status that
> contains a human readable comment (or some other indicator for user display
> purposes only).
> 
> > -----Original Message-----
> > From: simple-admin@mailman.dynamicsoft.com
> > [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Tony Hansen
> > Sent: Wednesday, April 17, 2002 1:15 PM
> > Cc: simple@mailman.dynamicsoft.com; impp@iastate.edu
> > Subject: Re: [Simple] Status summary
> >
> >
> > One aspect that hasn't come up yet in this conversation is something
> > someone said at the ad-hoc mtg in MN: the temporal aspect of the various
> > types of OPEN status messages. Why do you choose to use one message over
> > another? Usually it's to give the others an idea of how quickly you'll
> > respond.
> >
> > Some of them mean "I'm doing stuff, but will probably respond to your
> > message pretty quickly." (T = a couple minutes) Examples: Busy, On the
> > Phone.
> >
> > Some of them mean "I'm going to be gone for a while." (T = 1/2 - 1 hour)
> > Example: Out to Lunch.
> >
> > Some of them mean "Don't expect me to respond for hours." (T = 2-4
> > hours) Example: Away, In Meetings.
> >
> > Some of them mean "Don't expect me back for a long time." (T > 4 hours)
> > Example: Out for the weekend.
> >
> > When you go international, Out to Lunch doesn't mean a whole lot to
> > anyone but English speakers. But specifying an expected time to be gone
> > set at .5-1 hour certainly does translate well. Time is a pretty
> > universal concept, and might be worth codifying as part of the status
> > information.
> >
> >       Tony Hansen
> >       tony@att.com
> >
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Thu Apr 18 08:16:31 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02414
	for <simple-archive@lists.ietf.org>; Thu, 18 Apr 2002 08:16:30 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3ICCpDE027070;
	Thu, 18 Apr 2002 08:12:51 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13100;
	Thu, 18 Apr 2002 08:16:04 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13089
	for <simple@mailman.dynamicsoft.com>; Thu, 18 Apr 2002 08:15:48 -0400 (EDT)
From: aki.niemi@nokia.com
Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3ICF6F16767
	for <simple@mailman.dynamicsoft.com>; Thu, 18 Apr 2002 15:15:06 +0300 (EET DST)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5a560f1b2dac158f22076@esvir02nok.ntc.nokia.com>;
 Thu, 18 Apr 2002 15:14:47 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 18 Apr 2002 15:14:47 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Status summary
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FECD0@esebe013.NOE.Nokia.com>
Thread-Topic: [Simple] Status summary
Thread-Index: AcHmSgvjPy7lAhhYQv6gLxRU+BMT+wAh6iRw
To: <pkyzivat@cisco.com>, <bcampbell@dynamicsoft.com>
Cc: <tony@att.com>, <simple@mailman.dynamicsoft.com>, <impp@iastate.edu>
X-OriginalArrivalTime: 18 Apr 2002 12:14:47.0268 (UTC) FILETIME=[A1A6FA40:01C1E6D2]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id IAA13089
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Thu, 18 Apr 2002 15:14:46 +0300
Content-Transfer-Encoding: 8bit

> I see some parallels between open/away/closed and 200/202/4xx.
> 
> - "Open" means (sort of) that a MESSAGE should return a 200 - 
> will be displayed and hopefully seen immediately.
> 
> - "Away" means (sort of) that a MESSAGE should return a 202 - 
> will be accepted, but may not be displayed, or if displayed 
> may not be seen immediately.

Correct me if I'm wrong, but reading draft-ietf-sip-message-02.txt, my understanding was that the 202 would *not* convey information on the handling of the message, i.e., whether it is displayed or not. 

It is sent back by a GW, or a message relay, and simply means that the message wasn't actually delivered to the recipient, but stored, gatewayed, etc, and may be delivered at a later time if at all.

Similarly, the 200 only states, that the message was received by the recipient, not necessarily displayed, seen, read, understood, etc.

Cheers,
Aki  
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Thu Apr 18 09:07:00 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04361
	for <simple-archive@lists.ietf.org>; Thu, 18 Apr 2002 09:07:00 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3ID2gDE027377;
	Thu, 18 Apr 2002 09:02:42 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13250;
	Thu, 18 Apr 2002 09:06:04 -0400 (EDT)
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13239
	for <simple@mailman.dynamicsoft.com>; Thu, 18 Apr 2002 09:05:23 -0400 (EDT)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g3ID43X56243;
	Thu, 18 Apr 2002 08:04:04 -0500 (CDT)
From: "Ben Campbell" <bcampbell@dynamicsoft.com>
To: <aki.niemi@nokia.com>, <pkyzivat@cisco.com>
Cc: <tony@att.com>, <simple@mailman.dynamicsoft.com>, <impp@iastate.edu>
Subject: RE: [Simple] Status summary
Message-ID: <HNEOJECGFHIABDLENMMCMEFHCGAA.bcampbell@dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FECD0@esebe013.NOE.Nokia.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Thu, 18 Apr 2002 08:03:38 -0500
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]
> Sent: Thursday, April 18, 2002 7:15 AM
> To: pkyzivat@cisco.com; bcampbell@dynamicsoft.com
> Cc: tony@att.com; simple@mailman.dynamicsoft.com; impp@iastate.edu
> Subject: RE: [Simple] Status summary
>
>
> > I see some parallels between open/away/closed and 200/202/4xx.
> >
> > - "Open" means (sort of) that a MESSAGE should return a 200 -
> > will be displayed and hopefully seen immediately.
> >
> > - "Away" means (sort of) that a MESSAGE should return a 202 -
> > will be accepted, but may not be displayed, or if displayed
> > may not be seen immediately.
>
> Correct me if I'm wrong, but reading
> draft-ietf-sip-message-02.txt, my understanding was that the 202
> would *not* convey information on the handling of the message,
> i.e., whether it is displayed or not.
>
> It is sent back by a GW, or a message relay, and simply means
> that the message wasn't actually delivered to the recipient, but
> stored, gatewayed, etc, and may be delivered at a later time if at all.
>
> Similarly, the 200 only states, that the message was received by
> the recipient, not necessarily displayed, seen, read, understood, etc.

Yes, this is correct. For example, a given service _might_ choose to return
202 all the time, if it perhaps did not want to indicate to the sender that
some messages go directly and others get store-and-forwarded. (I'm
not_suggesting_ this behavior, but it is legal).

_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Thu Apr 18 09:12:59 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04600
	for <simple-archive@lists.ietf.org>; Thu, 18 Apr 2002 09:12:59 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3ID6fDE027468;
	Thu, 18 Apr 2002 09:06:41 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13286;
	Thu, 18 Apr 2002 09:10:05 -0400 (EDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13273
	for <simple@mailman.dynamicsoft.com>; Thu, 18 Apr 2002 09:09:29 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3ID8ibI017105;
	Thu, 18 Apr 2002 09:08:45 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAI61363;
	Thu, 18 Apr 2002 09:11:38 -0400 (EDT)
Message-ID: <3CBEC543.E89B8C44@cisco.com>
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: aki.niemi@nokia.com
CC: bcampbell@dynamicsoft.com, tony@att.com, simple@mailman.dynamicsoft.com,
        impp@iastate.edu
Subject: Re: [Simple] Status summary
References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FECD0@esebe013.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Thu, 18 Apr 2002 09:08:20 -0400
Content-Transfer-Encoding: 7bit

aki.niemi@nokia.com wrote:
> 
> > I see some parallels between open/away/closed and 200/202/4xx.
> >
> > - "Open" means (sort of) that a MESSAGE should return a 200 -
> > will be displayed and hopefully seen immediately.
> >
> > - "Away" means (sort of) that a MESSAGE should return a 202 -
> > will be accepted, but may not be displayed, or if displayed
> > may not be seen immediately.
> 
> Correct me if I'm wrong, but reading draft-ietf-sip-message-02.txt, my understanding was that the 202 would *not* convey information on the handling of the message, i.e., whether it is displayed or not.
> 
> It is sent back by a GW, or a message relay, and simply means that the message wasn't actually delivered to the recipient, but stored, gatewayed, etc, and may be delivered at a later time if at all.
> 
> Similarly, the 200 only states, that the message was received by the recipient, not necessarily displayed, seen, read, understood, etc.

You are not wrong - the meanings are not exactly the same,
which is why I qualified the statements above with 
"(sort of)", and in the next paragraph of my message...

Paul Kyzivat wrote:
> 
> The parallels aren't perfect by any means. E.g. 200 doesn't really mean
> that the message has been seen. Yet in some sense I think the purpose
> of the presence status is to give a hint about what is likely to happen
> if communication is attempted.
> Maybe it would be helpful to make better parallels.

	Paul
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Thu Apr 18 13:06:08 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14910
	for <simple-archive@odin.ietf.org>; Thu, 18 Apr 2002 13:06:07 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3IH1qDE000059;
	Thu, 18 Apr 2002 13:01:52 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13965;
	Thu, 18 Apr 2002 13:05:05 -0400 (EDT)
Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13952
	for <simple@mailman.dynamicsoft.com>; Thu, 18 Apr 2002 13:04:59 -0400 (EDT)
Received: from us-exchange-1.ezenia.com by dfw7sosrv11.alter.net with ESMTP 
	(peer crosschecked as: [208.209.226.82])
	id QQmldk18441;
	Thu, 18 Apr 2002 17:03:08 GMT
Received: by us-exchange-1.ezenia.com with Internet Mail Service (5.5.2653.19)
	id <JF57NL7J>; Thu, 18 Apr 2002 13:10:29 -0400
Message-ID: <F1F23CCBCA00D4118B1100508BCF2A6C01A9B4C1@us-exchange-1.ezenia.com>
From: Duane Moore <DMoore@ezenia.com>
To: "'Christian Jansson'" <christian.jansson@hotsip.com>,
        Henning Schulzrinne <hgs@cs.columbia.edu>,
        simple@mailman.dynamicsoft.com, impp@iastate.edu
Subject: RE: [Simple] Windows messenger
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Thu, 18 Apr 2002 13:10:23 -0400

This is true, but is there any fully compliant SIP/SIMPLE/CPIM client
available yet?  I would expect future versions of Windows Messenger to
better support the standards as they are finalized.

-----Original Message-----
From: Christian Jansson [mailto:christian.jansson@hotsip.com] 
Sent: Thursday, April 18, 2002 9:37 AM
To: Henning Schulzrinne; simple@mailman.dynamicsoft.com; impp@iastate.edu
Subject: RE: [Simple] Windows messenger


But the Messenger seems to have a big problem with the presence
format. The presentity uri should identify the presentity for 
whom the presence data is being reported, but Messenger instead
sends the address of the receiver of the information!? 

The Messenger also does not have any Event header its NOTIFY
messages, and it sends a NOTIFY without any content to indicate
that it is offline.

/ Christian Jansson
 
> Xiaotao Wu in my lab just ran windump and confirmed that Windows
> Messenger Version 4.6(4.6.0077) uses SIP for NOTIFY, REGISTER,
> SUBSCRIBE. For the "proof", see the message dumps at
> http://www.cs.columbia.edu/sip/drafts/messenger.txt
> 
> To answer my own question: Messenger embraces and extends XPIDF:
> 
> <presence>
> <presentity uri="sip:xiaotaow@cs.columbia.edu;method=SUBSCRIBE" />
> <atom id="1003">
> <address uri="sip:128.59.19.251:13170;user=ip" priority="0.800000">
> <status status="open" />
> <msnsubstatus substatus="online" />
> </address>
> </atom>
> </presence>
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 



  [reminder: meta-impp@iastate.edu for non-technical discussions, please]
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Fri Apr 19 07:26:25 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16199
	for <simple-archive@odin.ietf.org>; Fri, 19 Apr 2002 07:26:25 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3JBM4DE005430;
	Fri, 19 Apr 2002 07:22:04 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16937;
	Fri, 19 Apr 2002 07:25:07 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16924
	for <simple@mailman.dynamicsoft.com>; Fri, 19 Apr 2002 07:24:19 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16051;
	Fri, 19 Apr 2002 07:23:15 -0400 (EDT)
Message-Id: <200204191123.HAA16051@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org, simple@mailman.dynamicsoft.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: [Simple] I-D ACTION:draft-ietf-sip-message-03.txt
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Fri, 19 Apr 2002 07:23:15 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: Session Initiation Protocol Extension for Instant 
                          Messaging
	Author(s)	: B. Campbell, J. Rosenberg
	Filename	: draft-ietf-sip-message-03.txt
	Pages		: 19
	Date		: 18-Apr-02
	
Instant Messageing (IM) refers to the transfer of messages between
users in near real-time.  These messages are usually, but not
required to be, short.  IMs are often used in a conversational mode,
that is, the transfer of messages back and forth is fast enough for
participants to maintain an interactive conversation.
The MESSAGE method is an extension to the Session Initation Protocol
(SIP) that allows the transfer of Instant Messages.  MESSAGE requests
carry the content in the form of MIME body parts.  MESSAGE requests
do not themselves initiate a SIP dialog; under normal usage each
Instant Message stands alone, much like pager messages.  MESSAGE
requests may be sent in the context of a dialog initiated by some
other SIP request.
Since the MESSAGE request is an extension to SIP it inherits all the
request routing and security features of that protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-message-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-message-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-message-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020418141051.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-message-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sip-message-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020418141051.I-D@ietf.org>

--OtherAccess--

--NextPart--


_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Fri Apr 19 09:33:18 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19371
	for <simple-archive@odin.ietf.org>; Fri, 19 Apr 2002 09:33:18 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3JDStDE006215;
	Fri, 19 Apr 2002 09:28:55 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17346;
	Fri, 19 Apr 2002 09:32:07 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17335
	for <simple@mailman.dynamicsoft.com>; Fri, 19 Apr 2002 09:31:35 -0400 (EDT)
From: aki.niemi@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3JDUqF03559
	for <simple@mailman.dynamicsoft.com>; Fri, 19 Apr 2002 16:30:52 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5a5b7ad6fdac158f24077@esvir04nok.ntc.nokia.com>;
 Fri, 19 Apr 2002 16:30:33 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Fri, 19 Apr 2002 16:30:33 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: Statuses and response codes (Was: RE: [Simple] Status summary)
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FECD3@esebe013.NOE.Nokia.com>
Thread-Topic: [Simple] Status summary
Thread-Index: AcHm2ik1tHv71taQR4a5XxY7swhbBAAyp5Sg
To: <pkyzivat@cisco.com>
Cc: <bcampbell@dynamicsoft.com>, <tony@att.com>,
        <simple@mailman.dynamicsoft.com>, <impp@iastate.edu>
X-OriginalArrivalTime: 19 Apr 2002 13:30:33.0638 (UTC) FILETIME=[61E9BC60:01C1E7A6]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id JAA17335
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Fri, 19 Apr 2002 16:30:33 +0300
Content-Transfer-Encoding: 8bit

Hi Paul,

> You are not wrong - the meanings are not exactly the same,
> which is why I qualified the statements above with 
> "(sort of)", and in the next paragraph of my message...

You are right, I probably got a little trigger happy with my response :-)

But if I edit the parallels you listed a little bit, could they still be used in a meaningful way?
  
	- Open: you can expect a 200 for the MESSAGE
	- Away: you probably can expect a 2xx
	- Closed: you can expect a 4xx, or a 202, but not a 200 for the MESSAGE

Cheers,
Aki
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Fri Apr 19 13:37:01 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08307
	for <simple-archive@odin.ietf.org>; Fri, 19 Apr 2002 13:37:01 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3JHWjDE008581;
	Fri, 19 Apr 2002 13:32:45 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18133;
	Fri, 19 Apr 2002 13:36:04 -0400 (EDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18121
	for <simple@mailman.dynamicsoft.com>; Fri, 19 Apr 2002 13:35:01 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3JHYEtV002601;
	Fri, 19 Apr 2002 13:34:14 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAI70570;
	Fri, 19 Apr 2002 13:37:08 -0400 (EDT)
Message-ID: <3CC054FD.796CABC9@cisco.com>
From: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Huitema <huitema@windows.microsoft.com>
CC: aki.niemi@nokia.com, bcampbell@dynamicsoft.com, tony@att.com,
        simple@mailman.dynamicsoft.com, impp@iastate.edu
Subject: Re: Statuses and response codes (Was: RE: [Simple] Status summary)
References: <F66A04C29AD9034A8205949AD0C901040327030F@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Fri, 19 Apr 2002 13:33:49 -0400
Content-Transfer-Encoding: 7bit

While the privacy concerns are significant, it seems to me that they should be largely equivalent in the two mechanisms. Someone who is intent on learning as much as
possible about my status will use every feature at hand, so hiding information via one channel but not the other is not useful.

Presence is not useful if it gives information that is often inconsistent with what I would discover by sending a MESSAGE or INVITE.

If I want to lie about my presence, then I should also set my UA up so that it lies in a consistent way to callers.

	Paul

Christian Huitema wrote:
> 
> >       - Open: you can expect a 200 for the MESSAGE
> >       - Away: you probably can expect a 2xx
> >       - Closed: you can expect a 4xx, or a 202, but not a 200 for the
> 
> We have to be a bit careful with this line of reasoning, and consider
> the privacy implications. I would argue that the response to MESSAGE
> SHOULD NOT provide an indication on the recipient's online status, or at
> least not in the general case. Otherwise, MESSAGE can be used as a
> covert channel to assess someone's presence status without going through
> the authorization mechanism built in subscriptions. Indeed, it may be OK
> to provide such status when the source of the message is an authorized
> subscriber to the user's presence, but you should also be a bit careful
> that the source URI is not forged.
> 
> Before anyone shrugs off the privacy complaint, consider the spooks'
> practice of locating a suspect's cell-phone. In a few occasion, the
> location was directly followed by a well targeted missile... From that
> point of view, the SMS' "read acknowledge" feature is terrible, and we
> should make sure to not emulate it.
> 
> -- Christian Huitema
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Fri Apr 19 16:03:27 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26827
	for <simple-archive@odin.ietf.org>; Fri, 19 Apr 2002 16:03:27 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3JJwiDE010405;
	Fri, 19 Apr 2002 15:58:44 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18698;
	Fri, 19 Apr 2002 16:02:04 -0400 (EDT)
Received: from hotsip.com ([62.119.82.43])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13694
	for <simple@mailman.dynamicsoft.com>; Thu, 18 Apr 2002 11:38:27 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Windows messenger
Message-ID: <FE03AFC4B33E7447979123987BD65F45141E2F@exchange.hotsip.com>
Thread-Topic: [Simple] Windows messenger
Thread-Index: AcHlg9qqNNkbJmVSSxeBvo67HoHFVwBagWPg
From: "Christian Jansson" <christian.jansson@hotsip.com>
To: "Henning Schulzrinne" <hgs@cs.columbia.edu>,
        <simple@mailman.dynamicsoft.com>, <impp@iastate.edu>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA13694
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Thu, 18 Apr 2002 17:37:21 +0200
Content-Transfer-Encoding: 8bit


But the Messenger seems to have a big problem with the presence
format. The presentity uri should identify the presentity for 
whom the presence data is being reported, but Messenger instead
sends the address of the receiver of the information!? 

The Messenger also does not have any Event header its NOTIFY
messages, and it sends a NOTIFY without any content to indicate
that it is offline.

/ Christian Jansson
 
> Xiaotao Wu in my lab just ran windump and confirmed that Windows
> Messenger Version 4.6(4.6.0077) uses SIP for NOTIFY, REGISTER,
> SUBSCRIBE. For the "proof", see the message dumps at
> http://www.cs.columbia.edu/sip/drafts/messenger.txt
> 
> To answer my own question: Messenger embraces and extends XPIDF:
> 
> <presence>
> <presentity uri="sip:xiaotaow@cs.columbia.edu;method=SUBSCRIBE" />
> <atom id="1003">
> <address uri="sip:128.59.19.251:13170;user=ip" priority="0.800000">
> <status status="open" />
> <msnsubstatus substatus="online" />
> </address>
> </atom>
> </presence>
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Fri Apr 19 16:03:52 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26895
	for <simple-archive@odin.ietf.org>; Fri, 19 Apr 2002 16:03:52 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3JJxdDE010485;
	Fri, 19 Apr 2002 15:59:39 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18737;
	Fri, 19 Apr 2002 16:03:05 -0400 (EDT)
Received: from zrtps0kn.us.nortel.com (zrtps0kn.nortelnetworks.com [47.140.192.55])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13498
	for <simple@mailman.dynamicsoft.com>; Thu, 18 Apr 2002 10:26:53 -0400 (EDT)
Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25])
	by zrtps0kn.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3IEOAT15027;
	Thu, 18 Apr 2002 10:24:10 -0400 (EDT)
Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <HCGHJL6H>; Thu, 18 Apr 2002 10:24:11 -0400
Message-ID: <ADF33184C5A8D511AD2100508BF9CEC7BB76D9@zmexc012.cala.nortel.com>
From: "Roberto Myers"<rmyers@nortelnetworks.com>
To: Avshalom Houri <AVSHALOM@il.ibm.com>, impp@iastate.edu,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Windows messenger
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1E6E4.B273F3C0"
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Thu, 18 Apr 2002 10:24:06 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1E6E4.B273F3C0
Content-Type: text/plain;
	charset="iso-8859-1"

Please unsuscribe roberto myers from dist. list

-----Original Message-----
From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]
Sent: Wednesday, April 17, 2002 12:34 PM
To: impp@iastate.edu; simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Windows messenger



I want to clarify the confusion. I have talked with Jonathan Christensen
from MS and the status is this: 

The public .NET passport account uses a combination of SIP and  the MSN
proprietary protocol for IM and presence.  A/V is negotiated with SIP and
media is transported with standard RTP.

If you are talking with a SIP server the client talks SIP (you need to
enable it via Tools/Options/Accounts/Communication Service). 

Avshalom Houri
Presence and Instant Messaging Architect
Lotus Sametime, IBM Software Group
avshalom@il.ibm.com





	Henning Schulzrinne <hgs@cs.columbia.edu> 
Sent by: simple-admin@mailman.dynamicsoft.com 


16/04/2002 23:14 
Please respond to Henning Schulzrinne 


        
        To:        simple@mailman.dynamicsoft.com, impp@iastate.edu 
        cc:         
        Subject:        [Simple] Windows messenger 

       


Xiaotao Wu in my lab just ran windump and confirmed that Windows
Messenger Version 4.6(4.6.0077) uses SIP for NOTIFY, REGISTER,
SUBSCRIBE. For the "proof", see the message dumps at
http://www.cs.columbia.edu/sip/drafts/messenger.txt

To answer my own question: Messenger embraces and extends XPIDF:

<presence>
<presentity uri="sip:xiaotaow@cs.columbia.edu;method=SUBSCRIBE" />
<atom id="1003">
<address uri="sip:128.59.19.251:13170;user=ip" priority="0.800000">
<status status="open" />
<msnsubstatus substatus="online" />
</address>
</atom>
</presence>
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple





------_=_NextPart_001_01C1E6E4.B273F3C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D880212313-18042002>Please=20
unsuscribe roberto myers from dist. list</SPAN></FONT></DIV>
<BLOCKQUOTE>
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Avshalom Houri=20
  [mailto:AVSHALOM@il.ibm.com]<BR><B>Sent:</B> Wednesday, April 17, =
2002 12:34=20
  PM<BR><B>To:</B> impp@iastate.edu;=20
  simple@mailman.dynamicsoft.com<BR><B>Subject:</B> Re: [Simple] =
Windows=20
  messenger<BR><BR></DIV></FONT><BR><FONT face=3Dsans-serif size=3D2>I =
want to=20
  clarify the confusion. I have talked with Jonathan Christensen from =
MS and the=20
  status is this:</FONT><FONT face=3D"Times New Roman" size=3D3> =
<BR></FONT><FONT=20
  face=3Dsans-serif size=3D2><BR>The public .NET passport account uses =
a combination=20
  of SIP and &nbsp;the MSN &nbsp;proprietary protocol for IM and=20
  presence.</FONT><FONT face=3D"Times New Roman" size=3D3> &nbsp;A/V is =
negotiated=20
  with SIP and media is transported with standard RTP.</FONT><FONT=20
  face=3Dsans-serif size=3D2><BR></FONT><BR><FONT face=3Dsans-serif =
size=3D2>If you are=20
  talking with a SIP server the client talks SIP (you need to enable it =
via=20
  Tools/Options/Accounts/Communication Service).</FONT><FONT=20
  face=3D"Times New Roman" size=3D3> </FONT><BR><BR><FONT =
face=3Dsans-serif=20
  size=3D2>Avshalom Houri<BR>Presence and Instant Messaging =
Architect<BR>Lotus=20
  Sametime, IBM Software =
Group<BR>avshalom@il.ibm.com<BR><BR></FONT><BR><BR><BR>
  <TABLE width=3D"100%">
    <TBODY>
    <TR vAlign=3Dtop>
      <TD>
      <TD><FONT face=3Dsans-serif size=3D1><B>Henning Schulzrinne=20
        &lt;hgs@cs.columbia.edu&gt;</B></FONT> <BR><FONT =
face=3Dsans-serif=20
        size=3D1>Sent by: simple-admin@mailman.dynamicsoft.com</FONT>=20
        <P><FONT face=3Dsans-serif size=3D1>16/04/2002 23:14</FONT> =
<BR><FONT=20
        face=3Dsans-serif size=3D1>Please respond to Henning =
Schulzrinne</FONT>=20
        <BR></P>
      <TD><FONT face=3DArial size=3D1>&nbsp; &nbsp; &nbsp; &nbsp; =
</FONT><BR><FONT=20
        face=3Dsans-serif size=3D1>&nbsp; &nbsp; &nbsp; &nbsp; To: =
&nbsp; &nbsp;=20
        &nbsp; &nbsp;simple@mailman.dynamicsoft.com, =
impp@iastate.edu</FONT>=20
        <BR><FONT face=3Dsans-serif size=3D1>&nbsp; &nbsp; &nbsp; =
&nbsp; cc: &nbsp;=20
        &nbsp; &nbsp; &nbsp;</FONT> <BR><FONT face=3Dsans-serif =
size=3D1>&nbsp;=20
        &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; =
&nbsp;[Simple]=20
        Windows messenger</FONT> <BR><BR><FONT face=3DArial =
size=3D1>&nbsp; &nbsp;=20
        &nbsp; &nbsp;</FONT></TR></TBODY></TABLE><BR><BR><FONT =
face=3D"Courier New"=20
  size=3D2>Xiaotao Wu in my lab just ran windump and confirmed that=20
  Windows<BR>Messenger Version 4.6(4.6.0077) uses SIP for NOTIFY,=20
  REGISTER,<BR>SUBSCRIBE. For the "proof", see the message dumps=20
  at<BR>http://www.cs.columbia.edu/sip/drafts/messenger.txt<BR><BR>To =
answer my=20
  own question: Messenger embraces and extends=20
  XPIDF:<BR><BR>&lt;presence&gt;<BR>&lt;presentity=20
  uri=3D"sip:xiaotaow@cs.columbia.edu;method=3DSUBSCRIBE" =
/&gt;<BR>&lt;atom=20
  id=3D"1003"&gt;<BR>&lt;address =
uri=3D"sip:128.59.19.251:13170;user=3Dip"=20
  priority=3D"0.800000"&gt;<BR>&lt;status status=3D"open" =
/&gt;<BR>&lt;msnsubstatus=20
  substatus=3D"online"=20
  =
/&gt;<BR>&lt;/address&gt;<BR>&lt;/atom&gt;<BR>&lt;/presence&gt;<BR>_____=
__________________________________________<BR>simple=20
  mailing=20
  =
list<BR>simple@mailman.dynamicsoft.com<BR>http://mailman.dynamicsoft.com=
/mailman/listinfo/simple<BR></FONT><BR><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1E6E4.B273F3C0--
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Fri Apr 19 16:04:14 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26907
	for <simple-archive@odin.ietf.org>; Fri, 19 Apr 2002 16:04:14 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3JJxUDE010454;
	Fri, 19 Apr 2002 15:59:30 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18714;
	Fri, 19 Apr 2002 16:02:57 -0400 (EDT)
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17743
	for <simple@mailman.dynamicsoft.com>; Fri, 19 Apr 2002 11:31:45 -0400 (EDT)
Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.154]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Fri, 19 Apr 2002 08:30:10 -0700
Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 19 Apr 2002 08:30:44 -0700
Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Fri, 19 Apr 2002 08:30:09 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 19 Apr 2002 08:30:08 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0);
	 Fri, 19 Apr 2002 08:27:06 -0700
x-mimeole: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: Statuses and response codes (Was: RE: [Simple] Status summary)
Message-ID: <F66A04C29AD9034A8205949AD0C901040327030F@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: Statuses and response codes (Was: RE: [Simple] Status summary)
Thread-Index: AcHm2ik1tHv71taQR4a5XxY7swhbBAAyp5SgAARUKyA=
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: <aki.niemi@nokia.com>, <pkyzivat@cisco.com>
Cc: <bcampbell@dynamicsoft.com>, <tony@att.com>,
        <simple@mailman.dynamicsoft.com>, <impp@iastate.edu>
X-OriginalArrivalTime: 19 Apr 2002 15:27:06.0869 (UTC) FILETIME=[AA341A50:01C1E7B6]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA17743
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Fri, 19 Apr 2002 08:27:06 -0700
Content-Transfer-Encoding: 8bit

> 	- Open: you can expect a 200 for the MESSAGE
> 	- Away: you probably can expect a 2xx
> 	- Closed: you can expect a 4xx, or a 202, but not a 200 for the

We have to be a bit careful with this line of reasoning, and consider
the privacy implications. I would argue that the response to MESSAGE
SHOULD NOT provide an indication on the recipient's online status, or at
least not in the general case. Otherwise, MESSAGE can be used as a
covert channel to assess someone's presence status without going through
the authorization mechanism built in subscriptions. Indeed, it may be OK
to provide such status when the source of the message is an authorized
subscriber to the user's presence, but you should also be a bit careful
that the source URI is not forged.

Before anyone shrugs off the privacy complaint, consider the spooks'
practice of locating a suspect's cell-phone. In a few occasion, the
location was directly followed by a well targeted missile... From that
point of view, the SMS' "read acknowledge" feature is terrible, and we
should make sure to not emulate it.

-- Christian Huitema
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Mon Apr 22 12:32:51 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01505
	for <simple-archive@odin.ietf.org>; Mon, 22 Apr 2002 12:32:51 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3MGSqqb003143;
	Mon, 22 Apr 2002 12:28:52 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01536;
	Mon, 22 Apr 2002 12:32:09 -0400 (EDT)
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01100
	for <simple@mailman.dynamicsoft.com>; Mon, 22 Apr 2002 09:44:57 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id PAB113476
	for <simple@mailman.dynamicsoft.com>; Mon, 22 Apr 2002 15:43:52 +0200
Received: from d13ml006 (d13ml006.ch.ibm.com [9.13.8.67])
	by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3MDhqS65138
	for <simple@mailman.dynamicsoft.com>; Mon, 22 Apr 2002 15:43:52 +0200
To: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <OF14517247.E2B2CC45-ONC1256BA3.004A4A92@LocalDomain>
From: "Lamine Brahimi" <LAM@zurich.ibm.com>
X-MIMETrack: Serialize by Router on D13ML006/13/M/IBM(Release 5.0.9a |January 7, 2002) at
 22/04/2002 15:43:51
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: [Simple] about SIP
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Mon, 22 Apr 2002 15:43:50 +0200

Dear all,

I'm a student who is developing the presence protocol based on SIP.
I have a general question. As a student, i do not have much information
about SIP situation and actual evolution in the market.
Is the SIP network (SIP proxy servers, registrars etc ...) already
developed, used, under developement ?
I looked for it but it seems to me that, so far, SIP is used only in
research circles and by a few "pioneer" companies.
Thanks for clarifying things for me,
Regards,

Lamine.

_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Mon Apr 22 17:17:07 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13539
	for <simple-archive@odin.ietf.org>; Mon, 22 Apr 2002 17:17:06 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3MLCdqb006010;
	Mon, 22 Apr 2002 17:12:39 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02354;
	Mon, 22 Apr 2002 17:16:04 -0400 (EDT)
Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01339
	for <simple@mailman.dynamicsoft.com>; Mon, 22 Apr 2002 11:18:12 -0400 (EDT)
Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14])
	by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g3MFHAR10729
	for <simple@mailman.dynamicsoft.com>; Mon, 22 Apr 2002 17:17:10 +0200 (MEST)
Received: from hvrz00da.hvr.siemens.de (hvrz00da.hvr.siemens.de [129.103.192.197])
	by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id g3MFH9O21442
	for <simple@mailman.dynamicsoft.com>; Mon, 22 Apr 2002 17:17:09 +0200 (MEST)
Received: by hvrz00da.hvr.siemens.de with Internet Mail Service (5.5.2653.19)
	id <JM85DM6M>; Mon, 22 Apr 2002 17:17:08 +0200
Message-ID: <F56AAADD3A90D311A0220090275CCDE202104AB0@hvrz00da.hvr.siemens.de>
From: BECKMANN MARK <mark.beckmann@sal.siemens.de>
To: simple@mailman.dynamicsoft.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Simple] Data manipulation
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Mon, 22 Apr 2002 17:17:07 +0200

Hello,

at the last IETF meeting, I had the impression that a solution for data
manipulation based on SOAP is preferred in the SIMPLE WG as it is also
proposed in the components draft. Now, I am not very familiar with the SOAP
protocol and I would like to know what exactly the benefit by using the SOAP
protocol is. From my point of view a presence user agent could basically
manipulate a presentities data by sending a message containing presence data
in a PIDF format. The fact that the data is sent from the presence user
agent to the presence agent would indicate that this is a data manipulation
procedure.

Best regards,

Mark

Mark Beckmann			Siemens AG

ICM MP PO8 SA 82
P.O.Box 100702			phone: +49 (5341) 906 1814
D-38228 Salzgitter   		fax:   +49 (5341) 906 2010

mailto: Mark.Beckmann@siemens.com


_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Thu Apr 25 02:37:26 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27724
	for <simple-archive@odin.ietf.org>; Thu, 25 Apr 2002 02:37:26 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3P6X7qb024328;
	Thu, 25 Apr 2002 02:33:07 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA11560;
	Thu, 25 Apr 2002 02:35:06 -0400 (EDT)
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA11547
	for <simple@mailman.dynamicsoft.com>; Thu, 25 Apr 2002 02:34:54 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.76])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g3P6ZCLC005437;
	Thu, 25 Apr 2002 02:35:12 -0400 (EDT)
Message-ID: <3CC7A34A.7446963F@dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sean Olson <seancolson@yahoo.com>
CC: simple@mailman.dynamicsoft.com
References: <20020320221024.31411.qmail@web11604.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [Simple] Re: Version Info in Watcher Info
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Thu, 25 Apr 2002 02:33:46 -0400
Content-Transfer-Encoding: 7bit

I just noticed this in my massive sip list backlog. It was originally
posted there, but belongs on simple.

The answer is that version does, in fact, belong as part of the top
level watcherinfo element. ID, however, serves the purpose to identify a
watcher uniquely, and so belongs as a watcher attribute. This change has
already been made.

For those wondering about the status of the promised updates to the
watcherinfo drafts - I have incorporated all wglc comments. The only
issue is an ongoing debate on other lists about DTD vs. schema....

-Jonathan R.

Sean Olson wrote:
> 
> I was curious why the version/id used for deltas
> is part of the watcher element and not the top level
> watcherinfo element. Is this to allow for simpler
> aggregation?
> 
> /sean
> 
> =====
> Sean Olson <seancolson@yahoo.com>
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Movies - coverage of the 74th Academy Awards(r)
> http://movies.yahoo.com/

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


From simple-admin@mailman.dynamicsoft.com  Thu Apr 25 11:21:52 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17904
	for <simple-archive@odin.ietf.org>; Thu, 25 Apr 2002 11:21:52 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3PFHfqb027034;
	Thu, 25 Apr 2002 11:17:41 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12982;
	Thu, 25 Apr 2002 11:21:06 -0400 (EDT)
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12971
	for <simple@mailman.dynamicsoft.com>; Thu, 25 Apr 2002 11:20:36 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id RAA50194
	for <simple@mailman.dynamicsoft.com>; Thu, 25 Apr 2002 17:19:27 +0200
Received: from d13ml006 (d13ml006.ch.ibm.com [9.13.8.67])
	by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3PFJRY35726
	for <simple@mailman.dynamicsoft.com>; Thu, 25 Apr 2002 17:19:28 +0200
To: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <OF136A12B4.58EAD136-ONC1256BA6.00531DEB@LocalDomain>
From: "Lamine Brahimi" <LAM@zurich.ibm.com>
X-MIMETrack: Serialize by Router on D13ML006/13/M/IBM(Release 5.0.9a |January 7, 2002) at
 25/04/2002 17:19:27
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: [Simple] Can contact-headers point to URIs that do not support SIP ?
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Thu, 25 Apr 2002 17:19:27 +0200

Dear all,

I have developped a presence service. Now I need to integrate it into
another project.
I would like to put an uri like: "tcp://toto:6700" as the Contact-address
in the Contact-header.
However this uri points to another application that does not use sip.
So i do not want to receive  sip message at this address. The subscribers
to the presentity
use this contact address to run another application we have defined.
My question is will sip messages be routed to this contact-address (I do
not know if this case was taken into account in chapter Locating SIP
server/ Computing list of next hops of rfc2453-bis07) ?
If true, is it possible to specify that this contact address is not a SIP
contact-addres so that  proxies etc .. must skip it ?

Regards,
Lamine.



_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Sun Apr 28 01:00:07 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13082
	for <simple-archive@odin.ietf.org>; Sun, 28 Apr 2002 01:00:07 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3S4tjqb011901;
	Sun, 28 Apr 2002 00:55:46 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA22658;
	Sun, 28 Apr 2002 00:59:08 -0400 (EDT)
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA22647
	for <simple@mailman.dynamicsoft.com>; Sun, 28 Apr 2002 00:58:41 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.12])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g3S4wmLC007722;
	Sun, 28 Apr 2002 00:58:48 -0400 (EDT)
Message-ID: <3CCB8135.89F0A820@dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Lamine Brahimi <LAM@zurich.ibm.com>
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Can contact-headers point to URIs that do not support SIP ?
References: <OF136A12B4.58EAD136-ONC1256BA6.00531DEB@LocalDomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Sun, 28 Apr 2002 00:57:25 -0400
Content-Transfer-Encoding: 7bit



Lamine Brahimi wrote:
> 
> Dear all,
> 
> I have developped a presence service. Now I need to integrate it into
> another project.
> I would like to put an uri like: "tcp://toto:6700" as the
> Contact-address
> in the Contact-header.
> However this uri points to another application that does not use sip.
> So i do not want to receive  sip message at this address. The
> subscribers
> to the presentity
> use this contact address to run another application we have defined.

I think you may not be talking about the contact header. The contact
header is used to determine where to send SIP NOTIFY requests, thats it.
It must be a SIP URL. You are talking about some kind of address that
would be used to launch another application. Presumably, if A subscribes
to B, A learns this address from the NOTIFY requests sent to it from B,
and then can use that to communicate. If this is what you have in mind,
you are actually talking about a contact address within the PIDF
document in the NOTIFY. This is purposefully extensible and can support
any type of URL.

However, there is no such thing as a tcp URL, as in your example above.
That is most certainly NOT what you want. 

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


From simple-admin@mailman.dynamicsoft.com  Tue Apr 30 08:49:26 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17891
	for <simple-archive@odin.ietf.org>; Tue, 30 Apr 2002 08:49:26 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3UCikUo009406;
	Tue, 30 Apr 2002 08:44:47 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04721;
	Tue, 30 Apr 2002 08:48:07 -0400 (EDT)
Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04710
	for <simple@mailman.dynamicsoft.com>; Tue, 30 Apr 2002 08:47:15 -0400 (EDT)
Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227])
	by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA18110
	for <simple@mailman.dynamicsoft.com>; Tue, 30 Apr 2002 14:45:58 +0200 (MET DST)
Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83])
	by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA18345
	for <simple@mailman.dynamicsoft.com>; Tue, 30 Apr 2002 14:45:32 +0200 (MET DST)
Received: by MCHH273E with Internet Mail Service (5.5.2653.19)
	id <JV3RA5HK>; Tue, 30 Apr 2002 14:46:05 +0200
Message-ID: <35AF9DD2E324D4119DA00000D11D813E013EDF1A@blns203e.bln.icn.siemens.de>
From: Schultz Clemens <Clemens.Schultz@icn.siemens.de>
To: simple@mailman.dynamicsoft.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: [Simple] text attributes for IM?
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Tue, 30 Apr 2002 14:45:57 +0200

Dear all,

is it anyhow foreseen to provide data with SIP MESSAGE that reflect attributes for the text (e.g. color, used font etc.)? Do you have any headers in mind, or is it really necessary to have proprietary solution.

Thanks,
Clemens

.................................................................................
Clemens B Schultz
SIEMENS AG			Information and Communication Mobile
ICM N PG U SE D6		Systems Engineering
Fon / Fax: +49 30 386 26780 / 49118
e.mail: clemens.schultz@icn.siemens.de

_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From simple-admin@mailman.dynamicsoft.com  Tue Apr 30 09:39:46 2002
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19909
	for <simple-archive@odin.ietf.org>; Tue, 30 Apr 2002 09:39:45 -0400 (EDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3UDZZUo009851;
	Tue, 30 Apr 2002 09:35:35 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04909;
	Tue, 30 Apr 2002 09:39:05 -0400 (EDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04898
	for <simple@mailman.dynamicsoft.com>; Tue, 30 Apr 2002 09:38:35 -0400 (EDT)
Received: from dynamo.cs.columbia.edu (dynamo.cs.columbia.edu [128.59.16.4])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA27759
	for <simple@mailman.dynamicsoft.com>; Tue, 30 Apr 2002 09:37:30 -0400 (EDT)
Received: from dynamo.cs.columbia.edu (localhost [127.0.0.1])
	by dynamo.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g3UDbTMI019675
	for <simple@mailman.dynamicsoft.com>; Tue, 30 Apr 2002 09:37:29 -0400 (EDT)
Received: (from petkos@localhost)
	by dynamo.cs.columbia.edu (8.12.1/8.12.1/Submit) id g3UDbSYI019674
	for simple@mailman.dynamicsoft.com; Tue, 30 Apr 2002 09:37:28 -0400 (EDT)
From: "Petri K. Koskelainen" <petkos@cs.columbia.edu>
Message-Id: <200204301337.g3UDbSYI019674@dynamo.cs.columbia.edu>
To: simple@mailman.dynamicsoft.com
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [Simple] text attributes for IM?
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:simple-request@mailman.dynamicsoft.com?subject=help>
List-Post: <mailto:simple@mailman.dynamicsoft.com>
List-Subscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=subscribe>
List-Id: SIP for Presence <simple.mailman.dynamicsoft.com>
List-Unsubscribe: <http://mailman.dynamicsoft.com/mailman/listinfo/simple>,
	<mailto:simple-request@mailman.dynamicsoft.com?subject=unsubscribe>
List-Archive: <http://mailman.dynamicsoft.com/pipermail/simple/>
Date: Tue, 30 Apr 2002 09:37:28 -0400 (EDT)
Content-Transfer-Encoding: 7bit


> is it anyhow foreseen to provide data with SIP MESSAGE that 
> reflect attributes for the text (e.g. color, used font etc.)? 
> Do you have any headers in mind, or is it really necessary 
> to have proprietary solution.

This has nothing to do with SIP. It is purely a content format issue.
You are free to send your favourite rich text format (e.g. html, MS-Word) 
in the payload of SIP MESSAGE.

--
Petri
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple