From owner-um@snowshore.com Fri Mar  1 13:46:18 2002
Received: (from majordomo@localhost)
	by flyingfox.snowshore.com (8.11.2/8.11.2) id g21IkIA28574
	for um-outgoing; Fri, 1 Mar 2002 13:46:18 -0500 (EST)
X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f
Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7])
	by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id g21IkGB28570
	for <um@snowshore.com>; Fri, 1 Mar 2002 13:46:16 -0500 (EST)
Received: from 208.184.79.252.songbird.com (208.184.79.252.songbird.com [208.184.79.252] (may be forged))
	by joy.songbird.com (8.9.3/8.9.3) with SMTP id KAA06439;
	Fri, 1 Mar 2002 10:46:01 -0800
X-Authentication-Warning: joy.songbird.com: 208.184.79.252.songbird.com [208.184.79.252] (may be forged) didn't use HELO protocol
Message-Id: <5.1.0.14.2.20020301103853.032a2300@127.0.0.1>
X-Sender: dcrocker@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 01 Mar 2002 10:42:39 -0800
To: "Glenn Parsons"<gparsons@nortelnetworks.com>
From: Dave Crocker <dcrocker@brandenburg.com>
Subject: Re: [VPIM] ID-ACTIONs on UM
Cc: ietf-fax@imc.org, IETF VPIM List <vpim@lists.neystadt.org>,
   um@snowshore.com
In-Reply-To: <D38D073716F2D411BEE400508BCF629603874F22@zcard04k.ca.norte
 l.com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: owner-um@snowshore.com
Precedence: bulk

<html>
At 11:33 AM 2/26/2002 -0500, Glenn Parsons wrote:<br>
<blockquote type=cite class=cite cite><font size=2>These drafts discuss
some general unified messaging (UM) client issues that I think would be
worth discussing at both the FAX and VPIM WGs.<br>
</font><br>
<font size=2>After some discussion, I suggest we need to decide between
the following:</font> <br>
<font size=2>a) create a new BOF/WG to work on UM</font> <br>
<font size=2>b) recharter VPIM and/or FAX to work on this</font> <br>
<font size=2>c) close and combine VPIM and FAX into a new UM WG to work
on this and remaining VPIM/FAX topics </font></blockquote><br>
It is clear that the VPIM and Fax working groups have been pursuing some
topics that are more generally than the immediate scope of voice or fax
messaging.&nbsp; Consequently, some set of adjustments probably should be
made.<br><br>
However their is a considerable danger in making such changes, namely
that the new/integrated effort might have a scope that is not
sufficiently clear and/or is too broad.<br><br>
Therefore I would strongly suggest that discussion about a change NOT be
based a general discussion but, rather, on a specific proposal in the
form of a draft charter.<br><br>
If we can agree on charter language that specifies a clear, concise and
useful scope of work, then making the change will be obviously
correct.<br><br>
d/<br><br>
ps.&nbsp; I would offer draft text but do not feel that I know enough
about the work that is being proposed.  <br><br>
<x-sigsep><p></x-sigsep>
<font size=2>----------<br>
Dave Crocker&nbsp;
&lt;<a href="mailto:dcrocker@brandenburg.com" eudora="autourl">mailto:dcrocker@brandenburg.com</a>&gt;<br>
Brandenburg InternetWorking&nbsp;
&lt;<a href="http://www.brandenburg.com/" eudora="autourl">http://www.brandenburg.com</a>&gt;<br>
tel +1.408.246.8253;&nbsp; (new)fax +1.408.850.1850<br>
</font></html>

-
This list is maintained by Snowshore Networks - http://www.snowshore.com
All comments on this list are the comments of the message originators and
Snowshore is not to be held responsible for any actions or comments found
on this list. The archives for this list can be found at
http://flyingfox.snowshore.com/um_archive/maillist.html

From owner-um@snowshore.com Sat Mar  2 22:47:34 2002
Received: (from majordomo@localhost)
	by flyingfox.snowshore.com (8.11.2/8.11.2) id g233lXG18680
	for um-outgoing; Sat, 2 Mar 2002 22:47:33 -0500 (EST)
X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f
Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161])
	by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id g233lVB18676
	for <um@snowshore.com>; Sat, 2 Mar 2002 22:47:31 -0500 (EST)
Received: from co7040exch001p.wins.lucent.com (h135-39-1-40.lucent.com [135.39.1.40])
	by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g233lOe25515
	for <um@snowshore.com>; Sat, 2 Mar 2002 22:47:25 -0500 (EST)
Received: by co7040exch001p.milehi.lucent.com with Internet Mail Service (5.5.2650.21)
	id <WLDV7WT3>; Sat, 2 Mar 2002 20:47:23 -0700
Message-ID: <0096D8500C92D211BAEB0008C7F4906C05C5D727@co7040exch002u.milehi.lucent.com>
From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
To: Dave Crocker <dcrocker@brandenburg.com>,
   Glenn Parsons
	 <gparsons@nortelnetworks.com>
Cc: ietf-fax@imc.org, IETF VPIM List <vpim@lists.neystadt.org>,
   um@snowshore.com
Subject: RE: [VPIM] ID-ACTIONs on UM
Date: Sat, 2 Mar 2002 20:47:20 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1C266.1EDC6EA0"
Sender: owner-um@snowshore.com
Precedence: bulk

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_01C1C266.1EDC6EA0
Content-Type: text/plain;
	charset="iso-8859-1"

I would like to see more time at the IETF to discuss the launch of this
effort.  I suggest we find 1/2 day or so for a "rolling bar bof" to organize
potential topics in advance of the formal voice and fax WG meetings.  One
output could be a strawman charter for a new group.
 
I am particularly interested in a working group specifically chartered to
augment, profile, or otherwise create standards that would make it possible
to build a VOICEMAIL telephone user interface that can communicate with a
conforming message store, message submission server, and directory server.
The suported applications would be telephone answering (play greeting, take
message) and message retreival.  In my mind, I envison work on IMAP, SMTP,
and an LDAP schema to replicate the current industry-standard functionality.
 
I am supportive of broading this effort to include telephone user interface
applications to include common unified messaging elements such as the
ability to distinguish between messages of different contexts for the
purposes of sorting, foldering, and notification.
 
If the SNAP work is not completed by then, I would expect that work would
also fit within the charter of this group.
 
What I am not interested in is a general-porpose "unified messaging" working
group focused on the many other problems in this evolving application space.
That said, I believe the extensions we will require for telephone user
interface usage would be generally useful.  I offer this restriction in the
spirit of a narrow focus that has potential to be sucessfully addressed.
 
Greg V.
 

 -----Original Message-----
From: Dave Crocker [mailto:dcrocker@brandenburg.com]
Sent: Friday, March 01, 2002 12:43 PM
To: Glenn Parsons
Cc: ietf-fax@imc.org; IETF VPIM List; um@snowshore.com
Subject: Re: [VPIM] ID-ACTIONs on UM



At 11:33 AM 2/26/2002 -0500, Glenn Parsons wrote:


These drafts discuss some general unified messaging (UM) client issues that
I think would be worth discussing at both the FAX and VPIM WGs.

After some discussion, I suggest we need to decide between the following: 
a) create a new BOF/WG to work on UM 
b) recharter VPIM and/or FAX to work on this 
c) close and combine VPIM and FAX into a new UM WG to work on this and
remaining VPIM/FAX topics 


It is clear that the VPIM and Fax working groups have been pursuing some
topics that are more generally than the immediate scope of voice or fax
messaging.  Consequently, some set of adjustments probably should be made.

However their is a considerable danger in making such changes, namely that
the new/integrated effort might have a scope that is not sufficiently clear
and/or is too broad.

Therefore I would strongly suggest that discussion about a change NOT be
based a general discussion but, rather, on a specific proposal in the form
of a draft charter.

If we can agree on charter language that specifies a clear, concise and
useful scope of work, then making the change will be obviously correct.

d/

ps.  I would offer draft text but do not feel that I know enough about the
work that is being proposed. 



----------
Dave Crocker  < mailto:dcrocker@brandenburg.com
<mailto:dcrocker@brandenburg.com> >
Brandenburg InternetWorking  < http://www.brandenburg.com
<http://www.brandenburg.com/> >
tel +1.408.246.8253;  (new)fax +1.408.850.1850



------_=_NextPart_001_01C1C266.1EDC6EA0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=430551221-02032002>I 
would like to see more time at the IETF to discuss the&nbsp;launch of this 
effort.&nbsp; I suggest we find 1/2 day or so for a "rolling bar bof" to 
organize potential topics in advance of the formal voice and fax WG 
meetings.&nbsp; One output could be a strawman charter for a new 
group.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=430551221-02032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=430551221-02032002>I am 
particularly interested in a working group specifically chartered to augment, 
profile, or otherwise create standards that would make it possible to build a 
VOICEMAIL telephone user interface that can communicate with a conforming 
message store, message submission server, and directory server.&nbsp;The 
suported applications would be telephone answering (play greeting,&nbsp;take 
message) and message retreival.&nbsp;  In my mind, I envison work on IMAP, SMTP, 
and an LDAP&nbsp;schema to replicate the current industry-standard 
functionality.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=430551221-02032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=430551221-02032002>I am 
supportive of broading this effort to include telephone user interface 
applications to include common unified messaging&nbsp;elements such as&nbsp;the 
ability to distinguish between messages of different contexts for the purposes 
of sorting,&nbsp;foldering, and notification.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=430551221-02032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=430551221-02032002>If the 
SNAP work is not completed by then, I would expect that work would also fit 
within the charter of this group.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=430551221-02032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=430551221-02032002>What I 
am not interested in is a general-porpose "unified messaging" working group 
focused on the many other problems in this evolving application space.&nbsp; 
That said, I believe the extensions we will require for telephone user interface 
usage&nbsp;would be generally useful.&nbsp; I offer this restriction in the 
spirit of a narrow focus that has potential to be sucessfully 
addressed.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=430551221-02032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=430551221-02032002>Greg 
V.</SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
class=430551221-02032002></SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=430551221-02032002></SPAN></FONT>&nbsp;</DIV>
<DIV><SPAN class=430551221-02032002></SPAN><FONT face=Tahoma><BR><FONT 
size=2><SPAN class=430551221-02032002><FONT color=#0000ff 
face=Arial>&nbsp;</FONT></SPAN>-----Original Message-----<BR><B>From:</B> Dave 
Crocker [mailto:dcrocker@brandenburg.com]<BR><B>Sent:</B> Friday, March 01, 2002 
12:43 PM<BR><B>To:</B> Glenn Parsons<BR><B>Cc:</B> ietf-fax@imc.org; IETF VPIM 
List; um@snowshore.com<BR><B>Subject:</B> Re: [VPIM] ID-ACTIONs on 
UM<BR><BR></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px"></FONT>At 11:33 AM 2/26/2002 -0500, 
  Glenn Parsons wrote:<BR>
  <BLOCKQUOTE class=cite cite type="cite"><FONT size=2>These drafts discuss 
    some general unified messaging (UM) client issues that I think would be 
    worth discussing at both the FAX and VPIM WGs.<BR></FONT><BR><FONT 
    size=2>After some discussion, I suggest we need to decide between the 
    following:</FONT> <BR><FONT size=2>a) create a new BOF/WG to work on 
    UM</FONT> <BR><FONT size=2>b) recharter VPIM and/or FAX to work on 
    this</FONT> <BR><FONT size=2>c) close and combine VPIM and FAX into a new UM 
    WG to work on this and remaining VPIM/FAX topics </FONT></BLOCKQUOTE><BR>It is 
  clear that the VPIM and Fax working groups have been pursuing some topics that 
  are more generally than the immediate scope of voice or fax messaging.&nbsp; 
  Consequently, some set of adjustments probably should be made.<BR><BR>However 
  their is a considerable danger in making such changes, namely that the 
  new/integrated effort might have a scope that is not sufficiently clear and/or 
  is too broad.<BR><BR>Therefore I would strongly suggest that discussion about 
  a change NOT be based a general discussion but, rather, on a specific proposal 
  in the form of a draft charter.<BR><BR>If we can agree on charter language 
  that specifies a clear, concise and useful scope of work, then making the 
  change will be obviously correct.<BR><BR>d/<BR><BR>ps.&nbsp; I would offer 
  draft text but do not feel that I know enough about the work that is being 
  proposed. <BR><BR><X-SIGSEP>
  <P></X-SIGSEP><FONT size=2>----------<BR>Dave Crocker&nbsp; &lt;<A 
  href="mailto:dcrocker@brandenburg.com" 
  eudora="autourl">mailto:dcrocker@brandenburg.com</A>&gt;<BR>Brandenburg 
  InternetWorking&nbsp; &lt;<A href="http://www.brandenburg.com/" 
  eudora="autourl">http://www.brandenburg.com</A>&gt;<BR>tel 
  +1.408.246.8253;&nbsp; (new)fax 
+1.408.850.1850<BR></FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1C266.1EDC6EA0--

From owner-um@snowshore.com Wed Mar  6 15:27:09 2002
Received: (from majordomo@localhost)
	by flyingfox.snowshore.com (8.11.2/8.11.2) id g26KR9P24504
	for um-outgoing; Wed, 6 Mar 2002 15:27:09 -0500 (EST)
X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f
Received: from eburger (keeper.snowshore.com [216.57.133.4])
	by flyingfox.snowshore.com (8.11.2/8.11.2) with SMTP id g26KR7B24494
	for <um@snowshore.com>; Wed, 6 Mar 2002 15:27:07 -0500 (EST)
Reply-To: <eburger@snowshore.com>
From: "Eric Burger" <eburger@snowshore.com>
To: "IETF UM" <um@snowshore.com>
Subject: Rolling BoF?
Date: Wed, 6 Mar 2002 15:26:52 -0500
Message-ID: <EEEDJPFPPHPFKDDLLMOKMEAKDLAA.eburger@snowshore.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
Sender: owner-um@snowshore.com
Precedence: bulk

>From Greg:


Lets set a first session from 1-3 Monday, and pick up additional timeslots
from there if we find a productive track.   The goal is to determine if we
have a topic of sufficient interest and contributors priority to pursue
chartering as a formal IETF work-group.

I am particularly interested in soliciting attendance by folks tuned into
the latest 3GPP MMS work and standards needs.  

I can't guess accurately a location.  I will pick a spot and post it on the
IETF message board by Monday morning.   I am sure many of us may gather in
the hallway after the Apps area meeting for lunch. 

Greg V.

-----Original Message-----
From: Zmolek, Andrew (Andrew) [mailto:zmolek@avaya.com]
Sent: Tuesday, March 05, 2002 2:49 PM
To: Vaudreuil, Greg M (Greg); dcrocker@brandenburg.com;
gparsons@nortelnetworks.com; eburger@snowshore.com;
vpim@lists.neystadt.org
Subject: RE: Rolling BoF?


I agree with Greg that a "Rolling BoF" would be a good thing,
particularly since the WG is double-scheduled with midcom and I need to
cover at least some part of both. But I'm not sure what a "Rolling BoF"
means (scheduled vs. spontaneous, etc.). What did you have in mind,
Greg?

--Andy Zmolek 
    Technology & Standards Engineer 
      CTO Standards 
        Avaya Inc. 

            zmolek@avaya.com 
              +1 720 444 4001 


From owner-um@snowshore.com Fri Mar  8 01:43:09 2002
Received: (from majordomo@localhost)
	by flyingfox.snowshore.com (8.11.2/8.11.2) id g286h0M22310
	for um-outgoing; Fri, 8 Mar 2002 01:43:00 -0500 (EST)
X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id g286gxB22305;
	Fri, 8 Mar 2002 01:42:59 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.68])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g286he6Y029073;
	Fri, 8 Mar 2002 01:43:40 -0500 (EST)
Message-ID: <3C885D62.A2823530@dynamicsoft.com>
Date: Fri, 08 Mar 2002 01:42:42 -0500
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: eburger@snowshore.com
CC: Robert Sparks <rsparks@dynamicsoft.com>, IETF UM <um@snowshore.com>
Subject: Re: IM and UM
References: <EEEDJPFPPHPFKDDLLMOKMEOADJAA.eburger@snowshore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-um@snowshore.com
Precedence: bulk



Eric Burger wrote:
> 
> Honestly, IM wasn't on the radar screen.  There has been a lot of
> thought on
> the notification side, like Rohan's work on SIP-mwi and Noam's work on
> SNAP.
> Are you're thinking of a short message store in the case of a person
> sending
> an off-line IM?  

Exactly.

> If so, no, we haven't thought about it and yes, we
> really
> should.

Good. Unified is hardly unified if it leaves off a fairly major piece of
messaging. 

-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

From owner-um@snowshore.com Sun Mar 17 23:24:30 2002
Received: (from majordomo@localhost)
	by flyingfox.snowshore.com (8.11.2/8.11.2) id g2I4OT726045
	for um-outgoing; Sun, 17 Mar 2002 23:24:29 -0500 (EST)
X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f
Received: from noc-e.ietf53.cw.net (noc-e.ietf53.cw.net [166.63.177.40])
	by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id g2I4ORB26034
	for <um@snowshore.com>; Sun, 17 Mar 2002 23:24:28 -0500 (EST)
Received: from eburger (unknown [166.63.189.43])
	by noc-e.ietf53.cw.net (Postfix) with SMTP
	id 2443A6A928; Mon, 18 Mar 2002 00:08:58 +0000 (GMT)
Reply-To: <eburger@snowshore.com>
From: "Eric Burger" <eburger@snowshore.com>
To: "Pete Resnick" <presnick@qualcomm.com>,
   "Lyndon Nerenberg" <lyndon@atg.aciworldwide.com>
Cc: <ietf-imap-voice@imc.org>, "IETF UM" <um@snowshore.com>
Subject: [UM] RE: Interesting (gross?) use of CHANNEL
Date: Sun, 17 Mar 2002 23:24:09 -0500
Message-ID: <EEEDJPFPPHPFKDDLLMOKAEPODLAA.eburger@snowshore.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: <a05100314b8ad33fa9aae@[216.43.25.67]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: owner-um@snowshore.com
Precedence: bulk

I have to hop in here:  Is CHANNEL sensible if the end-system does not get
"transformed" data?

Transcoding *HAS* to be a legitimate use of CHANNEL.

Filtering *HAS* to be a legitimate use of CHANNEL.

Why?  If the bytes/packets are not modified, why use anything other than
IMAP?  The WHOLE POINT of CHANNEL is to get the data in a "more useful"
form, possibly from an "easier" place.

I do agree that the semantic content of the data may not be altered.
However, almost by definition the client is requesting alternate format,
possibly done on the fly.  CHANNEL transformations are (1) by client request
and (2) do not change the semantic value of the data.

What is the basis for the objection?

--
- Eric

--------------------------------------------

Lyndon Said, and Pete Replied:
[snip]
>Yuk. No. Again, CHANNEL is NOT alowwed to modify the data content in ANY
way.

What data content is being modified here? You are simply sending the
data (unchanged) to another process which is going to do something
with it. In some cases, that will be "Play the sounds to the user
using a speaker". In my case, it will be "Send this data via SMTP".
What's the problem?

pr
--
Pete Resnick <mailto:presnick@qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102


From owner-um@snowshore.com Mon Mar 18 10:31:31 2002
Received: (from majordomo@localhost)
	by flyingfox.snowshore.com (8.11.2/8.11.2) id g2IFVV503040
	for um-outgoing; Mon, 18 Mar 2002 10:31:31 -0500 (EST)
X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f
Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161])
	by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id g2IFVTB03035;
	Mon, 18 Mar 2002 10:31:29 -0500 (EST)
Received: from co7040exch001p.wins.lucent.com (h135-39-1-40.lucent.com [135.39.1.40])
	by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2IFVNA29155;
	Mon, 18 Mar 2002 10:31:23 -0500 (EST)
Received: by co7040exch001p.milehi.lucent.com with Internet Mail Service (5.5.2650.21)
	id <WLDWA234>; Mon, 18 Mar 2002 08:31:22 -0700
Message-ID: <0096D8500C92D211BAEB0008C7F4906C05DAD101@co7040exch002u.milehi.lucent.com>
From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
To: "Zmolek, Andrew (Andrew)" <zmolek@avaya.com>, dcrocker@brandenburg.com,
   gparsons@nortelnetworks.com, eburger@snowshore.com, vpim@lists.neystadt.org,
   ietf-fax@imc.org, um@snowshore.com, ietf-imap-voice@imc.org
Subject: [UM] Mail Extensions for Unified Messaging / TUI Access to Email BOF
Date: Mon, 18 Mar 2002 08:31:18 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-um@snowshore.com
Precedence: bulk


I would like to have the first meeting of the TUI/UM extensions Bar BOF
meeting TODAY in the 1-3 PM timeslot.  Let's meet at the message board.  If
you arrive and there are no people there, check the board for a forward
location pointer.

Greg V.

-----Original Message-----
From: Vaudreuil, Greg M (Greg) 
Sent: Wednesday, March 06, 2002 2:04 PM
To: Zmolek, Andrew (Andrew); dcrocker@brandenburg.com;
gparsons@nortelnetworks.com; eburger@snowshore.com;
vpim@lists.neystadt.org
Subject: [VPIM] RE: Rolling BoF?



Lets set a first session from 1-3 Monday, and pick up additional timeslots
from there if we find a productive track.   The goal is to determine if we
have a topic of sufficient interest and contributors priority to pursue
chartering as a formal IETF work-group.

I am particularly interested in soliciting attendance by folks tuned into
the latest 3GPP MMS work and standards needs.  

I can't guess accurately a location.  I will pick a spot and post it on the
IETF message board by Monday morning.   I am sure many of us may gather in
the hallway after the Apps area meeting for lunch. 

Greg V.

-----Original Message-----
From: Zmolek, Andrew (Andrew) [mailto:zmolek@avaya.com]
Sent: Tuesday, March 05, 2002 2:49 PM
To: Vaudreuil, Greg M (Greg); dcrocker@brandenburg.com;
gparsons@nortelnetworks.com; eburger@snowshore.com;
vpim@lists.neystadt.org
Subject: RE: Rolling BoF?


I agree with Greg that a "Rolling BoF" would be a good thing,
particularly since the WG is double-scheduled with midcom and I need to
cover at least some part of both. But I'm not sure what a "Rolling BoF"
means (scheduled vs. spontaneous, etc.). What did you have in mind,
Greg?

--Andy Zmolek 
    Technology & Standards Engineer 
      CTO Standards 
        Avaya Inc. 

            zmolek@avaya.com 
              +1 720 444 4001 

----------------------------------------------------------
This message was sent to you, since you are subscribed to
vpim@lists.neystadt.org. You can manage your subscription at
http://www.neystadt.org/cgi-bin/majordomo

From owner-um@snowshore.com Mon Mar 18 18:29:33 2002
Received: (from majordomo@localhost)
	by flyingfox.snowshore.com (8.11.2/8.11.2) id g2INTXR12246
	for um-outgoing; Mon, 18 Mar 2002 18:29:33 -0500 (EST)
X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f
Received: from episteme-software.com (champdsl-25-66.mcleodusa.net [216.43.25.66])
	by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id g2INTVB12241;
	Mon, 18 Mar 2002 18:29:31 -0500 (EST)
Received: from [166.63.185.240] (166.63.185.240) by episteme-software.com
 with ESMTP (Eudora Internet Mail Server 3.1);
 Mon, 18 Mar 2002 17:29:16 -0600
Mime-Version: 1.0
X-Sender: resnick@resnick1.qualcomm.com (Unverified)
Message-Id: <a05100301b8bc273c3918@[166.63.185.240]>
In-Reply-To: <EEEDJPFPPHPFKDDLLMOKAEPODLAA.eburger@snowshore.com>
References: <EEEDJPFPPHPFKDDLLMOKAEPODLAA.eburger@snowshore.com>
X-Mailer: Eudora [Macintosh version 5.1b21-04.02]
Date: Mon, 18 Mar 2002 17:28:44 -0600
To: <eburger@snowshore.com>
From: Pete Resnick <presnick@qualcomm.com>
Subject: [UM] RE: Interesting (gross?) use of CHANNEL
Cc: "Lyndon Nerenberg" <lyndon@atg.aciworldwide.com>,
   <ietf-imap-voice@imc.org>, "IETF UM" <um@snowshore.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-um@snowshore.com
Precedence: bulk

On 3/17/02 at 11:24 PM -0500, Eric Burger wrote:

>I have to hop in here:  Is CHANNEL sensible if the end-system does 
>not get "transformed" data?

Lyndon actually backed off of his original position; it can certainly 
be transformed, but it shouldn't be changed while it's still on the 
IMAP server. However, there is a perfectly legitimate use of 
untransformed data:

>Why?  If the bytes/packets are not modified, why use anything other 
>than IMAP?  The WHOLE POINT of CHANNEL is to get the data in a "more 
>useful" form, possibly from an "easier" place.

You've said it yourself: You might want to get the data from an 
"easier place". That is, you don't want to have to tell another 
system to go to an IMAP server and go through all of the 
authentication and IMAP overhead that you've already dealt with. You 
want to push the data to another process.

I'd like to write up the mailto: use of CHANNEL. Would you be willing 
to include it in draft-burger-imap-chanuse-00.txt?

pr
-- 
Pete Resnick <mailto:presnick@qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From owner-um@snowshore.com Mon Mar 18 21:21:50 2002
Received: (from majordomo@localhost)
	by flyingfox.snowshore.com (8.11.2/8.11.2) id g2J2Lo014335
	for um-outgoing; Mon, 18 Mar 2002 21:21:50 -0500 (EST)
X-Authentication-Warning: flyingfox.snowshore.com: majordomo set sender to owner-um@mail.snowshore.com using -f
Received: from noc-e.ietf53.cw.net (noc-e.ietf53.cw.net [166.63.177.40])
	by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id g2J2LnB14326
	for <um@snowshore.com>; Mon, 18 Mar 2002 21:21:49 -0500 (EST)
Received: from eburger (eburger.ietf53.cw.net [166.63.188.46])
	by noc-e.ietf53.cw.net (Postfix) with SMTP
	id A8B316A901; Mon, 18 Mar 2002 20:21:48 -0600 (CST)
Reply-To: <eburger@snowshore.com>
From: "Eric Burger" <eburger@snowshore.com>
To: "Pete Resnick" <presnick@qualcomm.com>
Cc: "Lyndon Nerenberg" <lyndon@atg.aciworldwide.com>,
   <ietf-imap-voice@imc.org>, "IETF UM" <um@snowshore.com>
Subject: [UM] RE: Interesting (gross?) use of CHANNEL
Date: Mon, 18 Mar 2002 21:21:31 -0500
Message-ID: <EEEDJPFPPHPFKDDLLMOKMEDMDMAA.eburger@snowshore.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)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <a05100301b8bc273c3918@[166.63.185.240]>
Importance: Normal
Sender: owner-um@snowshore.com
Precedence: bulk

Actually, you're right on the "non-transforming" use of CHANNEL.

I can put a mailto: CHANNEL scenario into the next draft.  I know Greg
really wants it.

-----Original Message-----
From: Pete Resnick [mailto:presnick@qualcomm.com]
Sent: Monday, March 18, 2002 6:29 PM
To: eburger@snowshore.com
Cc: Lyndon Nerenberg; ietf-imap-voice@imc.org; IETF UM
Subject: RE: Interesting (gross?) use of CHANNEL


On 3/17/02 at 11:24 PM -0500, Eric Burger wrote:

>I have to hop in here:  Is CHANNEL sensible if the end-system does
>not get "transformed" data?

Lyndon actually backed off of his original position; it can certainly
be transformed, but it shouldn't be changed while it's still on the
IMAP server. However, there is a perfectly legitimate use of
untransformed data:

>Why?  If the bytes/packets are not modified, why use anything other
>than IMAP?  The WHOLE POINT of CHANNEL is to get the data in a "more
>useful" form, possibly from an "easier" place.

You've said it yourself: You might want to get the data from an
"easier place". That is, you don't want to have to tell another
system to go to an IMAP server and go through all of the
authentication and IMAP overhead that you've already dealt with. You
want to push the data to another process.

I'd like to write up the mailto: use of CHANNEL. Would you be willing
to include it in draft-burger-imap-chanuse-00.txt?

pr
--
Pete Resnick <mailto:presnick@qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102


