From simple-bounces@ietf.org Sat Dec 02 15:09:41 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gqb9G-0007oI-8Y; Sat, 02 Dec 2006 15:07:46 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gqb9F-0007oC-9Y
	for simple@ietf.org; Sat, 02 Dec 2006 15:07:45 -0500
Received: from mail.tieto.com ([194.110.47.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gqb98-0005at-NU
	for simple@ietf.org; Sat, 02 Dec 2006 15:07:45 -0500
Received: from viper.eu.tieto.com ([194.110.47.167]) by mail.tieto.com with
	Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Dec 2006 22:07:24 +0200
Received: from sagaris.eu.tieto.com ([131.207.197.143]) by viper.eu.tieto.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 2 Dec 2006 22:07:23 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 2 Dec 2006 22:07:19 +0200
Message-ID: <ED57D60E44F6A549B7122141E9A486CA98BE16@sagaris.eu.tieto.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-simple-xcap: Can node selector separator be encoded?
Thread-Index: AccWTXeg7isLukHfSgiRHOetfpG+eA==
From: <Silvestr.Peknik@tietoenator.com>
To: <simple@ietf.org>
X-OriginalArrivalTime: 02 Dec 2006 20:07:23.0440 (UTC)
	FILETIME=[7AF33300:01C7164D]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Subject: [Simple] draft-ietf-simple-xcap: Can node selector separator be
	encoded?
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org

Hello,=20

I am not sure about following part of the draft:

6.  URI Construction
...
The node selector separator is a path segment with a value of double =
tilde ("~~"), and SHOULD NOT be percent-encoded, as advised in =
Section=A02.3 of RFC 3986 [13]. URIs containing %7E%7E should be =
normalized to ~~ for comparison; they are equivalent.
...

Does this mean that the server will treat %7E%7E as node selector =
separator?


Background info: OMA-TS-XDM_Core specification which uses this draft =
says that the node selector separator shall appear ONLY once. Consider =
following example:

...
<external =
anchor=3D"http://test.com/resource-lists/users/xui/index/~~/foo">
...

If i want to fetch the <external> element based on the anchor value, I =
need to encode /~~/. So I need to know if it is sufficient to encode it =
once (so in XCAP URI it will appear as /%7E%7E/) or do I need to encode =
it twice (%257E%257E), in which case I'd need to have it encoded once in =
the body as well.

I hope that is not too confusing.

Thank you,=20

Silvestr Peknik
Software Specialist
TietoEnator


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Mon Dec 04 04:38:31 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GrAGZ-0001Vw-6Q; Mon, 04 Dec 2006 04:37:39 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GrAGW-0001Vb-O4
	for simple@ietf.org; Mon, 04 Dec 2006 04:37:37 -0500
Received: from rvil-eframer.radvision.com ([80.74.106.104]
	helo=eframer.radvision.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrAGU-00078L-JS
	for simple@ietf.org; Mon, 04 Dec 2006 04:37:36 -0500
Received: (from root@localhost)
	by eframer.radvision.com (8.13.4/8.12.9) id kB49eNQZ022377
	for simple@ietf.org; Mon, 4 Dec 2006 11:40:23 +0200
Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com
	[172.20.2.100])
	by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id kB49eN16022371
	for <simple@ietf.org>; Mon, 4 Dec 2006 11:40:23 +0200
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 4 Dec 2006 11:38:57 +0200
Message-ID: <7579E2B4F92E89429C01EA57E4E6DBBB437CC7@rvil-mail1.RADVISION.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RFC3858: why package parameter in watcher-list
Thread-Index: AccXh82535gbOaZoSs6f53oAABBQyw==
From: "Tamar Barzuza" <TamarB@radvision.com>
To: <simple@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
Subject: [Simple] RFC3858: why package parameter in watcher-list
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1617626146=="
Errors-To: simple-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1617626146==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C71788.05911848"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C71788.05911848
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,

A NOTIFY request containing watcher XML contains also an Event header
that indicates the event package this NOTIFY relates to. However,
RFC3858 instructs us to add a mandatory "package" parameter to each
watcher list of the watcher XML.=20

Why should there be a "package" parameter in every watcher-list? Why is
the event package of the Event header in the NOTIFY request
insufficient?=20

Thank you,

Tamar Barzuza.


------_=_NextPart_001_01C71788.05911848
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	text-align:right;
	direction:rtl;
	unicode-bidi:embed;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1 dir=3DRTL>

<p class=3DMsoNormal dir=3DLTR =
style=3D'text-align:left;direction:ltr;unicode-bidi:
embed'><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Hello,</span></font></p>

<p class=3DMsoNormal dir=3DLTR =
style=3D'text-align:left;direction:ltr;unicode-bidi:
embed'><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>A
NOTIFY request containing watcher XML contains also an Event header that
indicates the event package this NOTIFY relates to. However, RFC3858 =
instructs
us to add a mandatory &quot;package&quot; parameter to each watcher list =
of the
watcher XML. </span></font></p>

<p class=3DMsoNormal dir=3DLTR =
style=3D'text-align:left;direction:ltr;unicode-bidi:
embed'><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Why
should there be a &quot;package&quot; parameter in every watcher-list? =
Why is the
event package of the Event header in the NOTIFY request insufficient? =
</span></font></p>

<p class=3DMsoNormal dir=3DLTR =
style=3D'text-align:left;direction:ltr;unicode-bidi:
embed'><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Thank
you,</span></font></p>

<p class=3DMsoNormal dir=3DLTR =
style=3D'text-align:left;direction:ltr;unicode-bidi:
embed'><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Tamar
Barzuza.</span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C71788.05911848--


--===============1617626146==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple

--===============1617626146==--




From simple-bounces@ietf.org Tue Dec 05 09:07:49 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Graww-0008WO-W7; Tue, 05 Dec 2006 09:07:10 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Graww-0008WJ-4t
	for simple@ietf.org; Tue, 05 Dec 2006 09:07:10 -0500
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grawo-0003ky-CZ
	for simple@ietf.org; Tue, 05 Dec 2006 09:07:10 -0500
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 89476AD9; 
	Tue,  5 Dec 2006 15:06:55 +0100 (CET)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 5 Dec 2006 15:06:55 +0100
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 5 Dec 2006 15:06:54 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se
	[131.160.33.3])
	by mail.lmf.ericsson.se (Postfix) with ESMTP id 7886C259D;
	Tue,  5 Dec 2006 16:06:54 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])
	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 373584DBBD;
	Tue,  5 Dec 2006 16:06:54 +0200 (EET)
Received: from localhost.localdomain (localhost [IPv6:::1])
	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C60364DB90;
	Tue,  5 Dec 2006 16:06:53 +0200 (EET)
From: "Salvatore Loreto (JO/LMF)" <salvatore.loreto@ericsson.com>
To: hisham.khartabil@telio.no, RjS@estacado.net, jdrosen@cisco.com
In-Reply-To: <00E47B21F2156640838B288A86560DB6033CAB3D@esealmw107.eemea.ericsson.se>
References: <00E47B21F2156640838B288A86560DB6033CAB3D@esealmw107.eemea.ericsson.se>
Date: Tue, 05 Dec 2006 16:07:15 +0200
Message-Id: <1165327635.4189.5.camel@n95.nomadiclab.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) 
X-Virus-Scanned: ClamAV using ClamSMTP
X-OriginalArrivalTime: 05 Dec 2006 14:06:54.0776 (UTC)
	FILETIME=[9E803B80:01C71876]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: simple@ietf.org,
	"Ingemar Lindgren \(TN/EAB\)" <ingemar.lindgren@ericsson.com>
Subject: [Simple] OMA TR in xcap-list-usage
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2139468110=="
Errors-To: simple-bounces@ietf.org



--===============2139468110==
Content-Type: multipart/alternative; boundary="=-5YnCFPMcwZavJgfwXUNX"



--=-5YnCFPMcwZavJgfwXUNX
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi Jonathan,


I sent this mail in July, but I didn't receive any answer...
so I am resending it. 


OMA founded a problem in the draft
draft-ietf-simple-xcap-list-usage-05, 
specifically in chapter 3.2 that defines resource-list schema as next:

<xs:element name="resource-lists"> 
<xs:complexType> 
<xs:sequence maxOccurs="unbounded"> 
<xs:element name="list" type="listType"/> </xs:sequence>
</xs:complexType> </xs:element>

There is no definition of minOccurs so default value is 1.

This cause the problem when client want to delete the last URI List from
the index document. 

In this case server will raise "schema-validation-error". So, it is not
possible to have empty index document for resource-lists.

rls-services and common-policy schema allow document to be created
without service and rule elements (allow empty documents) because they
specified minOccurs="0".


I'd like know your opinion about this OMA tr.

thank you in advance 
Sal 



--=-5YnCFPMcwZavJgfwXUNX
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.6.2">
  <TITLE>Any news on OMA TR</TITLE>
</HEAD>
<BODY>
<FONT COLOR="#000000">Hi </FONT>Jonathan,<BR>
<BR>
<BR>
I sent this mail in July, but I didn't receive any answer...<BR>
so I am resending it. <BR>
<BR>
<BR>
<FONT COLOR="#000000">OMA found</FONT>ed<FONT COLOR="#000000"> a problem in the draft draft-ietf-simple-xcap-list-usage-05, </FONT><BR>
<FONT COLOR="#000000">specifically in chapter 3.2 that defines resource-list schema as next:</FONT><BR>
<BR>
<FONT COLOR="#000000">&lt;xs:element name=&quot;resource-lists&quot;&gt; </FONT><BR>
<FONT COLOR="#000000">&lt;xs:complexType&gt; </FONT><BR>
<FONT COLOR="#000000">&lt;xs:sequence maxOccurs=&quot;unbounded&quot;&gt; </FONT><BR>
<FONT COLOR="#000000">&lt;xs:element name=&quot;list&quot; type=&quot;listType&quot;/&gt; &lt;/xs:sequence&gt; &lt;/xs:complexType&gt; &lt;/xs:element&gt;</FONT><BR>
<BR>
<FONT COLOR="#000000">There is no definition of minOccurs so default value is 1.</FONT><BR>
<BR>
<FONT COLOR="#000000">This cause the problem when client want to delete the last URI List from the index document. </FONT><BR>
<BR>
<FONT COLOR="#000000">In this case server will raise &quot;schema-validation-error&quot;. So, it is not possible to have empty index document for resource-lists.</FONT><BR>
<BR>
<FONT COLOR="#000000">rls-services and common-policy schema allow document to be created without service and rule elements (allow empty documents) because they specified minOccurs=&quot;0&quot;.</FONT><BR>
<BR>
<BR>
<FONT COLOR="#000000">I'd like know your opinion about this</FONT> OMA tr.<BR>
<BR>
<FONT COLOR="#000000">thank you in advance </FONT><BR>
<FONT COLOR="#000000">Sal </FONT><BR>
<BR>
<BR>
</BODY>
</HTML>

--=-5YnCFPMcwZavJgfwXUNX--



--===============2139468110==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple

--===============2139468110==--





From simple-bounces@ietf.org Tue Dec 05 14:50:18 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GrgIY-0002CR-P0; Tue, 05 Dec 2006 14:49:50 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GrgIX-0002BF-UD
	for simple@ietf.org; Tue, 05 Dec 2006 14:49:49 -0500
Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69]
	helo=vicuna.estacado.net)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GrgIW-0006TF-Gn
	for simple@ietf.org; Tue, 05 Dec 2006 14:49:49 -0500
Received: from [172.17.2.252] ([172.17.2.252]) (authenticated bits=0)
	by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id kB5JnjVW036149
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Tue, 5 Dec 2006 13:49:45 -0600 (CST)
	(envelope-from rjsparks@estacado.net)
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <DF0C6E39-A81D-4C14-83FB-4A9D7CA7AC78@estacado.net>
Content-Transfer-Encoding: 7bit
From: Robert Sparks <rjsparks@estacado.net>
Date: Tue, 5 Dec 2006 13:49:44 -0600
To: simple@ietf.org
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Cc: 
Subject: [Simple] minutes from IETF67
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org

Not as timely as I would have liked, but the minutes for the San  
Diego SIMPLE meeting are available now at

http://www3.ietf.org/proceedings/06nov/minutes/simple.txt

Please review them and send any needed corrections to list or the  
chairs.

Thanks,

RjS

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Thu Dec 07 16:20:56 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GsQef-0001Et-5X; Thu, 07 Dec 2006 16:19:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GsQeb-0001E9-WB; Thu, 07 Dec 2006 16:19:42 -0500
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GsQea-0007NF-Lu; Thu, 07 Dec 2006 16:19:41 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 352D026E87;
	Thu,  7 Dec 2006 20:50:03 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1GsQBu-0003O2-Mp; Thu, 07 Dec 2006 15:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1GsQBu-0003O2-Mp@stiedprstage1.ietf.org>
Date: Thu, 07 Dec 2006 15:50:02 -0500
X-Spam-Score: -2.5 (--)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: simple@ietf.org
Subject: [Simple] I-D ACTION:draft-ietf-simple-message-sessions-17.txt 
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org

--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		: The Message Session Relay Protocol
	Author(s)	: B. Campbell, et al.
	Filename	: draft-ietf-simple-message-sessions-17.txt
	Pages		: 62
	Date		: 2006-12-7
	
This document describes the Message Session Relay Protocol, a
   protocol for transmitting a series of related instant messages in the
   context of a session.  Message sessions are treated like any other
   media stream when set up via a rendezvous or session creation
   protocol such as the Session Initiation Protocol.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-message-sessions-17.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-message-sessions-17.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: <2006-12-7145003.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-message-sessions-17.txt

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

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


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple

--NextPart--




From simple-bounces@ietf.org Fri Dec 08 08:46:20 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gsg2W-0003kY-Np; Fri, 08 Dec 2006 08:45:24 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsg2V-0003kP-AR
	for simple@ietf.org; Fri, 08 Dec 2006 08:45:23 -0500
Received: from vm01.dns-hosting.info ([81.23.228.143])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsg2Q-0001oc-Rs
	for simple@ietf.org; Fri, 08 Dec 2006 08:45:23 -0500
Received: from [10.0.0.1] (mircea@titan.dns-hosting.info [193.230.183.40])
	(authenticated bits=0)
	by vm01.dns-hosting.info (8.13.7/8.13.7/Debian-2) with ESMTP id
	kB8Dj2rq009223
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
	for <simple@ietf.org>; Fri, 8 Dec 2006 14:45:04 +0100
Message-ID: <45798898.2050909@ag-projects.com>
Date: Fri, 08 Dec 2006 17:45:28 +0200
From: Mircea Amarascu <mircea@ag-projects.com>
User-Agent: Thunderbird 1.5.0.7 (X11/20060927)
MIME-Version: 1.0
To: simple@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Subject: [Simple] XCAP root URI
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org

Hello,

I have a question regarding the XCAP root URI: how is it possible to 
differentiate
it from the document selector (like the node selector separator 
separates the document
selector from the node selector)? Let's take the following example:

For this XCAP root URI : http://xcap.example.com/xcap-root/foo and this 
document selector:
/resource-lists/users/sip:joe@example.com/index, an HTTP client would 
send, in
case of a PUT method:

PUT /xcap-root/foo/resource-lists/users/sip:bill@example.com/index
...
Host: xcap.example.com

Could I consider the list of supported applications (e.g. 
resource-lists), and use it
as a pivot to split the URI?

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Mon Dec 11 11:23:10 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gtnum-0004fp-22; Mon, 11 Dec 2006 11:22:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtnuk-0004ep-TZ
	for simple@ietf.org; Mon, 11 Dec 2006 11:22:02 -0500
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gtnui-0006oE-Jl
	for simple@ietf.org; Mon, 11 Dec 2006 11:22:02 -0500
Received: from [172.17.2.252] (vicuna.estacado.net [72.1.129.69])
	(authenticated bits=0)
	by nostrum.com (8.13.8/8.13.8) with ESMTP id kBBGLu3i041354
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Mon, 11 Dec 2006 10:21:59 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <B2A87D48-27F5-4ECF-B4EC-CFC814E37A80@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Robert Sparks <rjsparks@nostrum.com>
Date: Mon, 11 Dec 2006 10:21:54 -0600
To: simple@ietf.org
X-Mailer: Apple Mail (2.752.2)
Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted
	mechanism)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: simple-ads@tools.ietf.org
Subject: [Simple] WGLC: draft-ietf-simple-imdn-02.txt
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org

This is a SIMPLE WGLC for
http://www.ietf.org/internet-drafts/draft-ietf-simple-imdn-02.txt

Please have your comments to the list by December 25 (more on this  
timing below)

Please send your comments to the list and copy Hisham and Eric.
Given the timing, it is especially important for you to respond if  
you think the draft is ready to go with no changes.

IF YOU HAVE A COMMENT TO MAKE BUT DON"T FEEL THIS IS ENOUGH TIME,
send email to the chairs right away. We'll extend this if there's any  
felt need.

Why the timing? :
    First off, I was slow in issuing the last call - that should have  
happened at the beginning of the month.
    Hisham (who has the pen right now) has some travel across the new  
year where he will be less responsive
    than usual. Our take is that this draft has little to no  
controversy left and has undergone a lot of scrutiny.
    If the LC feedback from the group shows it is ready to go, Hisham  
can make any needed minor edits before
    he drops offline and we can start into the request for  
publication process. If the feedback shows more time in
    LC is needed, we'll adjust, moving closure into the new year. In  
order to gauge this, it is very important that you
    respond even if you have no changes to suggest.

If you are not planning to review/comment on this draft, please let  
me know.

RjS

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Mon Dec 11 11:47:20 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GtoIx-0000Dm-At; Mon, 11 Dec 2006 11:47:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GtoIw-0000Dh-D9
	for simple@ietf.org; Mon, 11 Dec 2006 11:47:02 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtoIs-0002bL-0n
	for simple@ietf.org; Mon, 11 Dec 2006 11:47:02 -0500
Received: from sj-dkim-7.cisco.com ([171.68.10.88])
	by sj-iport-6.cisco.com with ESMTP; 11 Dec 2006 08:46:57 -0800
X-IronPort-AV: i="4.09,521,1157353200"; 
	d="scan'208"; a="90170227:sNHT46823688"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
	by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id kBBGkvp5018810; 
	Mon, 11 Dec 2006 08:46:57 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kBBGkcOd027650;
	Mon, 11 Dec 2006 08:46:57 -0800 (PST)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 11 Dec 2006 08:46:39 -0800
Received: from [171.70.246.57] ([171.70.246.57]) by xfe-sjc-211.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 11 Dec 2006 08:46:39 -0800
Message-ID: <457D8B6F.8060502@cisco.com>
Date: Mon, 11 Dec 2006 11:46:39 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mircea Amarascu <mircea@ag-projects.com>
Subject: Re: [Simple] XCAP root URI
References: <45798898.2050909@ag-projects.com>
In-Reply-To: <45798898.2050909@ag-projects.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Dec 2006 16:46:39.0068 (UTC)
	FILETIME=[EDA9A1C0:01C71D43]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1372; t=1165855617;
	x=1166719617; c=relaxed/simple; s=sjdkim7002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jdrosen@cisco.com;
	z=From:=20Jonathan=20Rosenberg=20<jdrosen@cisco.com>
	|Subject:=20Re=3A=20[Simple]=20XCAP=20root=20URI |Sender:=20;
	bh=jwtsaHTX8uorldKwqup9ICBPjjpk/yPj9TiUiYtNzJg=;
	b=SBM5O9nN2I8nhvLmNx3uvpflHY2P9Tir33fnc7rxIq+FpHBPjdicYaf5UYVgZLSVWkJpJ+3i
	Lq9T5NmSIamd3BCQm/kiFRcAvHEJzBGbxPRWlk7Y6AG7t8nS2UKSZvaa;
Authentication-Results: sj-dkim-7; header.From=jdrosen@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim7002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: simple@ietf.org
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org

The idea is that the server would be configured with its root URI, so it 
would know to remove it to get at the rest of the XCAP URI.

-Jonathan R.

Mircea Amarascu wrote:

> Hello,
> 
> I have a question regarding the XCAP root URI: how is it possible to 
> differentiate
> it from the document selector (like the node selector separator 
> separates the document
> selector from the node selector)? Let's take the following example:
> 
> For this XCAP root URI : http://xcap.example.com/xcap-root/foo and this 
> document selector:
> /resource-lists/users/sip:joe@example.com/index, an HTTP client would 
> send, in
> case of a PUT method:
> 
> PUT /xcap-root/foo/resource-lists/users/sip:bill@example.com/index
> ...
> Host: xcap.example.com
> 
> Could I consider the list of supported applications (e.g. 
> resource-lists), and use it
> as a pivot to split the URI?
> 
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Mon Dec 11 14:11:58 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GtqYU-0005FE-9l; Mon, 11 Dec 2006 14:11:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GtqYT-0005DK-LJ
	for simple@ietf.org; Mon, 11 Dec 2006 14:11:13 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtqYR-0004zB-9F
	for simple@ietf.org; Mon, 11 Dec 2006 14:11:13 -0500
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-5.cisco.com with ESMTP; 11 Dec 2006 11:11:10 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kBBJBAID001635; 
	Mon, 11 Dec 2006 11:11:10 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kBBJB9W4027828;
	Mon, 11 Dec 2006 11:11:10 -0800 (PST)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 11 Dec 2006 11:11:09 -0800
Received: from [128.107.100.203] ([128.107.100.203]) by
	xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 11 Dec 2006 11:11:09 -0800
Message-ID: <457DAD4D.9020405@cisco.com>
Date: Mon, 11 Dec 2006 14:11:09 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Salvatore Loreto (JO/LMF)" <salvatore.loreto@ericsson.com>
References: <00E47B21F2156640838B288A86560DB6033CAB3D@esealmw107.eemea.ericsson.se>
	<1165327635.4189.5.camel@n95.nomadiclab.com>
In-Reply-To: <1165327635.4189.5.camel@n95.nomadiclab.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Dec 2006 19:11:09.0672 (UTC)
	FILETIME=[1DBECE80:01C71D58]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1853; t=1165864270;
	x=1166728270; c=relaxed/simple; s=sjdkim1002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jdrosen@cisco.com;
	z=From:=20Jonathan=20Rosenberg=20<jdrosen@cisco.com>
	|Subject:=20Re=3A=20OMA=20TR=20in=20xcap-list-usage
	|Sender:=20; bh=MF8r4T/sapVVRlxlx3fMSwq+lq8GF1D0f/GhQNgzRSw=;
	b=blH/x4+eX2541RO6DRUk3Uw3p1ogtt8bhVa8GelKRXwcQHS48rCYN/rjOjVmpVMQW3t7bDoo
	2D89ga2Ag6n5Ha8Ou3nAXFfJ5okvjhzZY2gxx1hwX74M2Sus5NSXLLWw;
Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim1002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Cc: RjS@estacado.net, simple@ietf.org,
	"Ingemar Lindgren \(TN/EAB\)" <ingemar.lindgren@ericsson.com>
Subject: [Simple] Re: OMA TR in xcap-list-usage
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org

Egads, sorry I missed this last July.

The schema is consistent with the text, wihch does assume that there is 
at least one list in the document. However, I do see how that can be a 
problem in applications where the user removes one list and then creates 
a new one. As such, I think it makes sense to consider this as a bug and 
update the schema and wording in auth48 to allow for zero list elements.

Thanks,
Jonathan R.

Salvatore Loreto (JO/LMF) wrote:
> Hi Jonathan,
> 
> 
> I sent this mail in July, but I didn't receive any answer...
> so I am resending it.
> 
> 
> OMA founded a problem in the draft draft-ietf-simple-xcap-list-usage-05,
> specifically in chapter 3.2 that defines resource-list schema as next:
> 
> <xs:element name="resource-lists">
> <xs:complexType>
> <xs:sequence maxOccurs="unbounded">
> <xs:element name="list" type="listType"/> </xs:sequence> 
> </xs:complexType> </xs:element>
> 
> There is no definition of minOccurs so default value is 1.
> 
> This cause the problem when client want to delete the last URI List from 
> the index document.
> 
> In this case server will raise "schema-validation-error". So, it is not 
> possible to have empty index document for resource-lists.
> 
> rls-services and common-policy schema allow document to be created 
> without service and rule elements (allow empty documents) because they 
> specified minOccurs="0".
> 
> 
> I'd like know your opinion about this OMA tr.
> 
> thank you in advance
> Sal
> 
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Mon Dec 11 15:00:03 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GtrJG-0001Q2-0J; Mon, 11 Dec 2006 14:59:34 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GtrJB-0001Pi-Bz
	for simple@ietf.org; Mon, 11 Dec 2006 14:59:29 -0500
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtrJ8-00057l-UT
	for simple@ietf.org; Mon, 11 Dec 2006 14:59:29 -0500
Received: from sj-dkim-5.cisco.com ([171.68.10.79])
	by sj-iport-4.cisco.com with ESMTP; 11 Dec 2006 11:59:26 -0800
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
	by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id kBBJxQ7O022029; 
	Mon, 11 Dec 2006 11:59:26 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kBBJxKOV001502;
	Mon, 11 Dec 2006 11:59:20 -0800 (PST)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 11 Dec 2006 11:59:19 -0800
Received: from [128.107.100.203] ([128.107.100.203]) by
	xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 11 Dec 2006 11:59:19 -0800
Message-ID: <457DB897.1010706@cisco.com>
Date: Mon, 11 Dec 2006 14:59:19 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Silvestr.Peknik@tietoenator.com
Subject: Re: [Simple] draft-ietf-simple-xcap: Can node selector separator
	be	encoded?
References: <ED57D60E44F6A549B7122141E9A486CA98BE16@sagaris.eu.tieto.com>
In-Reply-To: <ED57D60E44F6A549B7122141E9A486CA98BE16@sagaris.eu.tieto.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Dec 2006 19:59:19.0492 (UTC)
	FILETIME=[D8365840:01C71D5E]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2466; t=1165867166;
	x=1166731166; c=relaxed/simple; s=sjdkim5002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jdrosen@cisco.com;
	z=From:=20Jonathan=20Rosenberg=20<jdrosen@cisco.com>
	|Subject:=20Re=3A=20[Simple]=20draft-ietf-simple-xcap=3A=20Can=20node=20s
	elector=20separator=0A=20be=09encoded? |Sender:=20;
	bh=K+AmjQlzHbcg8Vvq4DcQJtgMN/yIXwQQmJeBZCu46Ag=;
	b=boDYK06J6VaLLMr/Bs/mpm8FQAxnXGv4QU2od8n8cTMKdGek5Xgn+pLS8QwNzrgVpHiRtejw
	u9qjzjuhyz6i7hmvk7ByV5TL15JyGLhPguD+LN9xqnN6skAwDDYHJbun;
Authentication-Results: sj-dkim-5; header.From=jdrosen@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim5002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: simple@ietf.org
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org

Hmm, this is an issue I think. The XCAP server is supposed to unescape 
the URI and then look for the ~~ as the node selector separator. 
However, it will appear twice in the URI in this case - one of them as 
the content of the anchor attribute in the node selector. You can't 
double escape it, since the node matching rules aren't based on URI 
equality, they are based on string equality.

I can think of a few solutions:

1. xcap spec should be clarified to say that the FIRST instance of ~~ is 
the node selector separator

2. xcap-list usage should define an additional attribute of the 
<external> element that can be used as a key for selection, like an "id" 
attribute


I'm inclined for #1, since this is much simpler and less of a change.

Comments?

-Jonathan R.


Silvestr.Peknik@tietoenator.com wrote:

> Hello, 
> 
> I am not sure about following part of the draft:
> 
> 6.  URI Construction
> ...
> The node selector separator is a path segment with a value of double tilde ("~~"), and SHOULD NOT be percent-encoded, as advised in Section 2.3 of RFC 3986 [13]. URIs containing %7E%7E should be normalized to ~~ for comparison; they are equivalent.
> ...
> 
> Does this mean that the server will treat %7E%7E as node selector separator?
> 
> 
> Background info: OMA-TS-XDM_Core specification which uses this draft says that the node selector separator shall appear ONLY once. Consider following example:
> 
> ...
> <external anchor="http://test.com/resource-lists/users/xui/index/~~/foo">
> ...
> 
> If i want to fetch the <external> element based on the anchor value, I need to encode /~~/. So I need to know if it is sufficient to encode it once (so in XCAP URI it will appear as /%7E%7E/) or do I need to encode it twice (%257E%257E), in which case I'd need to have it encoded once in the body as well.
> 
> I hope that is not too confusing.
> 
> Thank you, 
> 
> Silvestr Peknik
> Software Specialist
> TietoEnator
> 
> 
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Tue Dec 12 09:41:12 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gu8nt-0001d5-7U; Tue, 12 Dec 2006 09:40:21 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu8ns-0001cc-3Q
	for simple@ietf.org; Tue, 12 Dec 2006 09:40:20 -0500
Received: from hu-out-0506.google.com ([72.14.214.237])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu8nq-0002IZ-MW
	for simple@ietf.org; Tue, 12 Dec 2006 09:40:19 -0500
Received: by hu-out-0506.google.com with SMTP id 38so1130908huc
	for <simple@ietf.org>; Tue, 12 Dec 2006 06:40:17 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
	b=RWwSHHr2IcuvNWOlIAPGptSUelI1KTLX9Io0Vv5hDSmKXC7Pq36DMovaYw4IZp9FmreBANBQ+fdnwaKogW+l1BAuuBMf8yEe+bEsRD7gSiyLLrhh101vEJPAA4wPAenQF4HiDGwxUNkuyg0HkiW0nx1o+8rAi3zOkWk3U7tBXBM=
Received: by 10.78.136.9 with SMTP id j9mr2278125hud.1165934416794;
	Tue, 12 Dec 2006 06:40:16 -0800 (PST)
Received: by 10.78.206.11 with HTTP; Tue, 12 Dec 2006 06:40:16 -0800 (PST)
Message-ID: <66cd252f0612120640o1b585d50qba485aa7c8c5b709@mail.gmail.com>
Date: Tue, 12 Dec 2006 15:40:16 +0100
From: "Hisham Khartabil" <hisham.khartabil@gmail.com>
To: simple@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Subject: [Simple] Change of contact info
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org

Hi,

Please note that my email address has changed to that shown in the From header.

While the old address will continue to work until end of December, now
would be a good time to update your address books.

Regards,
Hisham Khartabil
SIMPLE WG Co-chair

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Wed Dec 13 06:51:51 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GuSdI-0005jM-9u; Wed, 13 Dec 2006 06:50:44 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GuSdH-0005j6-Bz
	for simple@ietf.org; Wed, 13 Dec 2006 06:50:43 -0500
Received: from mail.tieto.com ([194.110.47.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuSdD-0007Fl-Md
	for simple@ietf.org; Wed, 13 Dec 2006 06:50:43 -0500
Received: from viper.eu.tieto.com ([194.110.47.167]) by mail.tieto.com with
	Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Dec 2006 13:50:24 +0200
Received: from sagaris.eu.tieto.com ([131.207.197.143]) by viper.eu.tieto.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 13 Dec 2006 13:50:24 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Simple] draft-ietf-simple-xcap: Can node selector separator
	be	encoded?
Date: Wed, 13 Dec 2006 13:50:22 +0200
Message-ID: <ED57D60E44F6A549B7122141E9A486CAA0F139@sagaris.eu.tieto.com>
In-Reply-To: <457DB897.1010706@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] draft-ietf-simple-xcap: Can node selector separator
	be	encoded?
Thread-Index: AccdXwG+csAM9CbHQg+jdHtQM9/fHwBSuKnA
From: <Silvestr.Peknik@tietoenator.com>
To: <jdrosen@cisco.com>
X-OriginalArrivalTime: 13 Dec 2006 11:50:24.0471 (UTC)
	FILETIME=[E000DE70:01C71EAC]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
Cc: simple@ietf.org
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org

Hello, comments below. Thank you for the response.

Silvestr

>-----Original Message-----
>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]
>Sent: Monday, December 11, 2006 8:59 PM
>To: Peknik Silvestr
>Cc: simple@ietf.org
>Subject: Re: [Simple] draft-ietf-simple-xcap: Can node selector
separator
>be encoded?
>
>Hmm, this is an issue I think. The XCAP server is supposed to unescape
>the URI and then look for the ~~ as the node selector separator.
>However, it will appear twice in the URI in this case - one of them as
>the content of the anchor attribute in the node selector. You can't
>double escape it, since the node matching rules aren't based on URI
>equality, they are based on string equality.

Silvestr: I am not sure why I cant double-escape it? I thought that I
have it encoded once in the document itself, and twice in the request
uri. So after one un-escaping, string comparison of the node selector in
uri and the value of the anchor attribute in the document would match.

However clients will probably not escape the body, as there is no
indication in specifications that they should do so (afaik).

I will try to get feedback from OMA on this issue.


>
>I can think of a few solutions:
>
>1. xcap spec should be clarified to say that the FIRST instance of ~~
is
>the node selector separator
>
>2. xcap-list usage should define an additional attribute of the
><external> element that can be used as a key for selection, like an
"id"
>attribute
>
>
>I'm inclined for #1, since this is much simpler and less of a change.
>
>Comments?
>
>-Jonathan R.
>
>
>Silvestr.Peknik@tietoenator.com wrote:
>
>> Hello,
>>
>> I am not sure about following part of the draft:
>>
>> 6.  URI Construction
>> ...
>> The node selector separator is a path segment with a value of double
>tilde ("~~"), and SHOULD NOT be percent-encoded, as advised in Section
2.3
>of RFC 3986 [13]. URIs containing %7E%7E should be normalized to ~~ for
>comparison; they are equivalent.
>> ...
>>
>> Does this mean that the server will treat %7E%7E as node selector
>separator?
>>
>>
>> Background info: OMA-TS-XDM_Core specification which uses this draft
says
>that the node selector separator shall appear ONLY once. Consider
following
>example:
>>
>> ...
>> <external
anchor=3D"http://test.com/resource-lists/users/xui/index/~~/foo">
>> ...
>>
>> If i want to fetch the <external> element based on the anchor value,
I
>need to encode /~~/. So I need to know if it is sufficient to encode it
>once (so in XCAP URI it will appear as /%7E%7E/) or do I need to encode
it
>twice (%257E%257E), in which case I'd need to have it encoded once in
the
>body as well.
>>
>> I hope that is not too confusing.
>>
>> Thank you,
>>
>> Silvestr Peknik
>> Software Specialist
>> TietoEnator
>>
>>
>> _______________________________________________
>> Simple mailing list
>> Simple@ietf.org
>> https://www1.ietf.org/mailman/listinfo/simple
>>
>
>--
>Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
>Cisco Fellow                                   Parsippany, NJ
07054-2711
>Cisco Systems
>jdrosen@cisco.com                              FAX:   (973) 952-5050
>http://www.jdrosen.net                         PHONE: (973) 952-5000
>http://www.cisco.com

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Thu Dec 14 15:51:08 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GuxWn-00089N-RP; Thu, 14 Dec 2006 15:50:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GuxWk-000879-FN; Thu, 14 Dec 2006 15:50:02 -0500
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GuxWk-0008VW-7q; Thu, 14 Dec 2006 15:50:02 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 2A42B32854;
	Thu, 14 Dec 2006 20:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1GuxWk-00088p-00; Thu, 14 Dec 2006 15:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1GuxWk-00088p-00@stiedprstage1.ietf.org>
Date: Thu, 14 Dec 2006 15:50:02 -0500
X-Spam-Score: -2.5 (--)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: simple@ietf.org
Subject: [Simple] I-D ACTION:draft-ietf-simple-message-sessions-18.txt 
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org

--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		: The Message Session Relay Protocol
	Author(s)	: B. Campbell, et al.
	Filename	: draft-ietf-simple-message-sessions-18.txt
	Pages		: 62
	Date		: 2006-12-14
	
This document describes the Message Session Relay Protocol, a
   protocol for transmitting a series of related instant messages in the
   context of a session.  Message sessions are treated like any other
   media stream when set up via a rendezvous or session creation
   protocol such as the Session Initiation Protocol.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-message-sessions-18.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-message-sessions-18.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: <2006-12-14123726.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-message-sessions-18.txt

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

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


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple

--NextPart--




From simple-bounces@ietf.org Thu Dec 14 22:41:36 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gv3wS-0001hJ-Sc; Thu, 14 Dec 2006 22:41:00 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv3wR-0001hE-Al
	for simple@ietf.org; Thu, 14 Dec 2006 22:40:59 -0500
Received: from extmail10.cingular.com ([170.35.225.25] helo=cingular.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gv3wP-0007NQ-W2
	for simple@ietf.org; Thu, 14 Dec 2006 22:40:59 -0500
Received: from ([10.148.14.30])
	by extmail10.cingular.com with ESMTP  id KP-VYFP6.86351982;
	Thu, 14 Dec 2006 22:40:35 -0500
Received: from TBDCEXCH10.US.Cingular.Net ([10.148.14.47]) by
	TD02XSMTP008.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 14 Dec 2006 21:40:35 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Simple] WGLC: draft-ietf-simple-imdn-02.txt
Date: Thu, 14 Dec 2006 21:40:34 -0600
Message-ID: <451C9AB8BFB6B64EA11547A3D966DB3608D34E97@TBDCEXCH10.US.Cingular.Net>
In-Reply-To: <B2A87D48-27F5-4ECF-B4EC-CFC814E37A80@nostrum.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] WGLC: draft-ietf-simple-imdn-02.txt
Thread-Index: AccdQRD2Ni4zNgjSRSqljKJQ/hECJQCtiPSg
To: "Robert Sparks" <rjsparks@nostrum.com>,
	<simple@ietf.org>
X-OriginalArrivalTime: 15 Dec 2006 03:40:35.0369 (UTC)
	FILETIME=[C78F4990:01C71FFA]
From: "Stafford, Matthew" <matthew.stafford@cingular.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
Cc: 
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org

I'd like to raise an issue regarding the statement that "IMDN is not
generally applicable to MSRP". IMHO IMDN's usefulness in the context of
SIP MESSAGE will be compromised if it cannot also be applied to MSRP.

I take the point that, when two subscribers are participating in an
ongoing session, it's odd to talk about IMDN concepts such as read
receipt.

However, "one-and-done" messages can easily exceed the 1300-byte limit
for SIP MESSAGE over UDP, especially when request-contained distribution
lists and/or multimedia attachments come into play. CPIM headers will
further reduce "headroom".=20

To address this limitation, OMA's SIMPLE IM working group has identified
"large message mode" (in addition to page mode and session mode). In
large message mode, an MSRP session is set up to transfer a one-time
message that is bigger than 1300 bytes. But the subscriber is blissfully
unaware of the difference between page mode and large message mode-
nothing at the UI layer reflects that there is an underlying session in
the latter case. The UI just presents a "unified composer" to the
subscriber. If the UI allows the subscriber to request read receipts for
small messages but not for big ones, I think the subscriber will be
baffled. Consider, for example, a case in which the subscriber composes
a text message and checks the "request read receipt" box. Then, on the
fly, he/she decides to add an attachment before sending the message.
It's really awkward to step in at that point and say no, sorry- you can
have one or the other but not both.=20

In summary, I think OMA's taxonomy of messaging modes is very natural-
from the POV of supporting use cases that will make sense to the average
subscriber. IMDN consistency across page and large message modes seems
equally natural to me.

Best,
Matt Stafford
Cingular Wireless

-----Original Message-----
From: Robert Sparks [mailto:rjsparks@nostrum.com]=20
Sent: Monday, December 11, 2006 10:22 AM
To: simple@ietf.org
Cc: simple-ads@tools.ietf.org
Subject: [Simple] WGLC: draft-ietf-simple-imdn-02.txt

This is a SIMPLE WGLC for
http://www.ietf.org/internet-drafts/draft-ietf-simple-imdn-02.txt

Please have your comments to the list by December 25 (more on this =20
timing below)

Please send your comments to the list and copy Hisham and Eric.
Given the timing, it is especially important for you to respond if =20
you think the draft is ready to go with no changes.

IF YOU HAVE A COMMENT TO MAKE BUT DON"T FEEL THIS IS ENOUGH TIME,
send email to the chairs right away. We'll extend this if there's any =20
felt need.

Why the timing? :
    First off, I was slow in issuing the last call - that should have =20
happened at the beginning of the month.
    Hisham (who has the pen right now) has some travel across the new =20
year where he will be less responsive
    than usual. Our take is that this draft has little to no =20
controversy left and has undergone a lot of scrutiny.
    If the LC feedback from the group shows it is ready to go, Hisham =20
can make any needed minor edits before
    he drops offline and we can start into the request for =20
publication process. If the feedback shows more time in
    LC is needed, we'll adjust, moving closure into the new year. In =20
order to gauge this, it is very important that you
    respond even if you have no changes to suggest.

If you are not planning to review/comment on this draft, please let =20
me know.

RjS

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Fri Dec 15 00:34:36 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gv5hu-0002TM-0U; Fri, 15 Dec 2006 00:34:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv5hs-0002T3-Q0
	for simple@ietf.org; Fri, 15 Dec 2006 00:34:04 -0500
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gv5hq-0004bX-Cf
	for simple@ietf.org; Fri, 15 Dec 2006 00:34:04 -0500
Received: from [192.168.1.100] (adsl-68-94-55-103.dsl.rcsntx.swbell.net
	[68.94.55.103]) (authenticated bits=0)
	by nostrum.com (8.13.8/8.13.8) with ESMTP id kBF5Xo0X083880
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 14 Dec 2006 23:33:51 -0600 (CST) (envelope-from ben@nostrum.com)
In-Reply-To: <451C9AB8BFB6B64EA11547A3D966DB3608D34E97@TBDCEXCH10.US.Cingular.Net>
References: <451C9AB8BFB6B64EA11547A3D966DB3608D34E97@TBDCEXCH10.US.Cingular.Net>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <D24387E7-7F9C-42BC-B53C-B4FFF4D7D849@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Ben Campbell <ben@nostrum.com>
Subject: Re: [Simple] WGLC: draft-ietf-simple-imdn-02.txt
Date: Thu, 14 Dec 2006 23:33:44 -0600
To: "Stafford, Matthew" <matthew.stafford@cingular.com>
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 68.94.55.103 is authenticated by a trusted
	mechanism)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b22590c27682ace61775ee7b453b40d3
Cc: simple@ietf.org
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org


On Dec 14, 2006, at 9:40 PM, Stafford, Matthew wrote:

> I'd like to raise an issue regarding the statement that "IMDN is not
> generally applicable to MSRP". IMHO IMDN's usefulness in the  
> context of
> SIP MESSAGE will be compromised if it cannot also be applied to MSRP.
>

Perhaps a better wording in the draft is "We have not fully explored  
the use cases for MSRP, so they are out of scope for this document.  
They may be addressed in a separate work."

I think the real point of removing MSRP from the document was not to  
say that we know categorically that there are no valid uses with  
MSRP. Rather, it was that such uses were not entirely clear, and if  
they are needed they require further exploration. We did not want to  
block progression of the spec on how to do IMDN with page mode until  
we completely understood how to do it with MSRP.


> I take the point that, when two subscribers are participating in an
> ongoing session, it's odd to talk about IMDN concepts such as read
> receipt.
>
> However, "one-and-done" messages can easily exceed the 1300-byte limit
> for SIP MESSAGE over UDP, especially when request-contained  
> distribution
> lists and/or multimedia attachments come into play. CPIM headers will
> further reduce "headroom".
>
> To address this limitation, OMA's SIMPLE IM working group has  
> identified
> "large message mode" (in addition to page mode and session mode). In
> large message mode, an MSRP session is set up to transfer a one-time
> message that is bigger than 1300 bytes. But the subscriber is  
> blissfully
> unaware of the difference between page mode and large message mode-
> nothing at the UI layer reflects that there is an underlying  
> session in
> the latter case. The UI just presents a "unified composer" to the
> subscriber. If the UI allows the subscriber to request read  
> receipts for
> small messages but not for big ones, I think the subscriber will be
> baffled. Consider, for example, a case in which the subscriber  
> composes
> a text message and checks the "request read receipt" box. Then, on the
> fly, he/she decides to add an attachment before sending the message.
> It's really awkward to step in at that point and say no, sorry- you  
> can
> have one or the other but not both.
>

In such a case, the user request for a receipt would be satisfied by  
the MSRP report mechanism, wouldn't it? That is, if the client is  
smart enough to switch to using MSRP rather than page mode, it would  
also be smart enough to request a delivery confirmation using the  
mechanism already in MSRP?


Now, if the use case you describe is one where the IMDN needs to be  
delivered after the MSRP session is completed (for example, the large  
message gets sent to a store and forward server), then we have a  
_very_ good example of something that needs more exploration before  
we try to specify how to do it.

> In summary, I think OMA's taxonomy of messaging modes is very natural-
> from the POV of supporting use cases that will make sense to the  
> average
> subscriber. IMDN consistency across page and large message modes seems
> equally natural to me.
>
> Best,
> Matt Stafford
> Cingular Wireless
>
> -----Original Message-----
> From: Robert Sparks [mailto:rjsparks@nostrum.com]
> Sent: Monday, December 11, 2006 10:22 AM
> To: simple@ietf.org
> Cc: simple-ads@tools.ietf.org
> Subject: [Simple] WGLC: draft-ietf-simple-imdn-02.txt
>
> This is a SIMPLE WGLC for
> http://www.ietf.org/internet-drafts/draft-ietf-simple-imdn-02.txt
>
> Please have your comments to the list by December 25 (more on this
> timing below)
>
> Please send your comments to the list and copy Hisham and Eric.
> Given the timing, it is especially important for you to respond if
> you think the draft is ready to go with no changes.
>
> IF YOU HAVE A COMMENT TO MAKE BUT DON"T FEEL THIS IS ENOUGH TIME,
> send email to the chairs right away. We'll extend this if there's any
> felt need.
>
> Why the timing? :
>     First off, I was slow in issuing the last call - that should have
> happened at the beginning of the month.
>     Hisham (who has the pen right now) has some travel across the new
> year where he will be less responsive
>     than usual. Our take is that this draft has little to no
> controversy left and has undergone a lot of scrutiny.
>     If the LC feedback from the group shows it is ready to go, Hisham
> can make any needed minor edits before
>     he drops offline and we can start into the request for
> publication process. If the feedback shows more time in
>     LC is needed, we'll adjust, moving closure into the new year. In
> order to gauge this, it is very important that you
>     respond even if you have no changes to suggest.
>
> If you are not planning to review/comment on this draft, please let
> me know.
>
> RjS
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Fri Dec 15 08:24:35 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GvD2V-0006dh-2L; Fri, 15 Dec 2006 08:23:51 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GvD2T-0006db-JT
	for simple@ietf.org; Fri, 15 Dec 2006 08:23:49 -0500
Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvD2S-0003Ch-S8
	for simple@ietf.org; Fri, 15 Dec 2006 08:23:49 -0500
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213])
	by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id
	kBFDN93i024562; Fri, 15 Dec 2006 15:23:11 +0200
Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by
	esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 15 Dec 2006 15:17:51 +0200
Received: from [172.21.58.172] ([172.21.58.172]) by esebh001.NOE.Nokia.com
	with Microsoft SMTPSVC(5.0.2195.6881); 
	Fri, 15 Dec 2006 15:17:42 +0200
Message-ID: <4582A076.2040703@nokia.com>
Date: Fri, 15 Dec 2006 15:17:42 +0200
From: Miguel Garcia <Miguel.An.Garcia@nokia.com>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Ben Campbell <ben@nostrum.com>
Subject: Re: [Simple] WGLC: draft-ietf-simple-imdn-02.txt
References: <451C9AB8BFB6B64EA11547A3D966DB3608D34E97@TBDCEXCH10.US.Cingular.Net>
	<D24387E7-7F9C-42BC-B53C-B4FFF4D7D849@nostrum.com>
In-Reply-To: <D24387E7-7F9C-42BC-B53C-B4FFF4D7D849@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Dec 2006 13:17:42.0536 (UTC)
	FILETIME=[66F5A880:01C7204B]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 789c141a303c09204b537a4078e2a63f
Cc: simple@ietf.org
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org

Mathew, Ben:

I think I agree with Ben here, that the spirit of the text is NOT to say 
that "we are in the absolute possession of the truth, and it indicates 
that IMDN does not make sense with MSRP". Instead, the spirit of the 
text tries to say that in those cases we have explored, MSRP conveys all 
the tools for providing IMDN except for the read case. But the read case 
is not applicable to session based messaging where messages are 
sequentially displayed in a chat windows (because the endpoint will 
blindly generate the IMDN-read always, so what is the point?). Please 
not the word "generally" in the text.

Now, it seems that OMA is going on step beyond the "general" use cases 
for MSRP, and I have no problem with that, but we haven't done an 
analysis of those uses cases and the impact of IMDN to those use cases.

The text in the draft also says: "If new requirements arise in the 
future determining the need for IMDN in MSRP, new specifications can be 
drafted". And this is what I would like to see, we know how IMDN is 
useful and can be applied for SIP, so let's finish the document now. I 
don't mind if we simultaneously keep on analyzing the need of IMDN for 
MSRP, and if needed, write a separate spec to apply IMDN for MSRP. Would 
that solve your concern, Mathew?

BR,

      Miguel

PS: I am in the middle of my review of MSRP, I expect to post my 
comments in the following days.





Ben Campbell wrote:
> 
> On Dec 14, 2006, at 9:40 PM, Stafford, Matthew wrote:
> 
>> I'd like to raise an issue regarding the statement that "IMDN is not
>> generally applicable to MSRP". IMHO IMDN's usefulness in the context of
>> SIP MESSAGE will be compromised if it cannot also be applied to MSRP.
>>
> 
> Perhaps a better wording in the draft is "We have not fully explored the 
> use cases for MSRP, so they are out of scope for this document. They may 
> be addressed in a separate work."
> 
> I think the real point of removing MSRP from the document was not to say 
> that we know categorically that there are no valid uses with MSRP. 
> Rather, it was that such uses were not entirely clear, and if they are 
> needed they require further exploration. We did not want to block 
> progression of the spec on how to do IMDN with page mode until we 
> completely understood how to do it with MSRP.
> 
> 
>> I take the point that, when two subscribers are participating in an
>> ongoing session, it's odd to talk about IMDN concepts such as read
>> receipt.
>>
>> However, "one-and-done" messages can easily exceed the 1300-byte limit
>> for SIP MESSAGE over UDP, especially when request-contained distribution
>> lists and/or multimedia attachments come into play. CPIM headers will
>> further reduce "headroom".
>>
>> To address this limitation, OMA's SIMPLE IM working group has identified
>> "large message mode" (in addition to page mode and session mode). In
>> large message mode, an MSRP session is set up to transfer a one-time
>> message that is bigger than 1300 bytes. But the subscriber is blissfully
>> unaware of the difference between page mode and large message mode-
>> nothing at the UI layer reflects that there is an underlying session in
>> the latter case. The UI just presents a "unified composer" to the
>> subscriber. If the UI allows the subscriber to request read receipts for
>> small messages but not for big ones, I think the subscriber will be
>> baffled. Consider, for example, a case in which the subscriber composes
>> a text message and checks the "request read receipt" box. Then, on the
>> fly, he/she decides to add an attachment before sending the message.
>> It's really awkward to step in at that point and say no, sorry- you can
>> have one or the other but not both.
>>
> 
> In such a case, the user request for a receipt would be satisfied by the 
> MSRP report mechanism, wouldn't it? That is, if the client is smart 
> enough to switch to using MSRP rather than page mode, it would also be 
> smart enough to request a delivery confirmation using the mechanism 
> already in MSRP?
> 
> 
> Now, if the use case you describe is one where the IMDN needs to be 
> delivered after the MSRP session is completed (for example, the large 
> message gets sent to a store and forward server), then we have a _very_ 
> good example of something that needs more exploration before we try to 
> specify how to do it.
> 
>> In summary, I think OMA's taxonomy of messaging modes is very natural-
>> from the POV of supporting use cases that will make sense to the average
>> subscriber. IMDN consistency across page and large message modes seems
>> equally natural to me.
>>
>> Best,
>> Matt Stafford
>> Cingular Wireless
>>
>> -----Original Message-----
>> From: Robert Sparks [mailto:rjsparks@nostrum.com]
>> Sent: Monday, December 11, 2006 10:22 AM
>> To: simple@ietf.org
>> Cc: simple-ads@tools.ietf.org
>> Subject: [Simple] WGLC: draft-ietf-simple-imdn-02.txt
>>
>> This is a SIMPLE WGLC for
>> http://www.ietf.org/internet-drafts/draft-ietf-simple-imdn-02.txt
>>
>> Please have your comments to the list by December 25 (more on this
>> timing below)
>>
>> Please send your comments to the list and copy Hisham and Eric.
>> Given the timing, it is especially important for you to respond if
>> you think the draft is ready to go with no changes.
>>
>> IF YOU HAVE A COMMENT TO MAKE BUT DON"T FEEL THIS IS ENOUGH TIME,
>> send email to the chairs right away. We'll extend this if there's any
>> felt need.
>>
>> Why the timing? :
>>     First off, I was slow in issuing the last call - that should have
>> happened at the beginning of the month.
>>     Hisham (who has the pen right now) has some travel across the new
>> year where he will be less responsive
>>     than usual. Our take is that this draft has little to no
>> controversy left and has undergone a lot of scrutiny.
>>     If the LC feedback from the group shows it is ready to go, Hisham
>> can make any needed minor edits before
>>     he drops offline and we can start into the request for
>> publication process. If the feedback shows more time in
>>     LC is needed, we'll adjust, moving closure into the new year. In
>> order to gauge this, it is very important that you
>>     respond even if you have no changes to suggest.
>>
>> If you are not planning to review/comment on this draft, please let
>> me know.
>>
>> RjS

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:miguel.garcia@neonsite.net
Nokia Research Center      Helsinki, Finland

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Mon Dec 18 10:52:30 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GwKmJ-00063T-8E; Mon, 18 Dec 2006 10:51:47 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GwKmI-00063O-Cv
	for simple@ietf.org; Mon, 18 Dec 2006 10:51:46 -0500
Received: from extmail13.cingular.com ([170.35.225.28] helo=cingular.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwKmH-0004Ws-V9
	for simple@ietf.org; Mon, 18 Dec 2006 10:51:46 -0500
Received: from ([10.148.14.30])
	by extmail13.cingular.com with ESMTP  id KP-TRRF8.95260864;
	Mon, 18 Dec 2006 10:51:25 -0500
Received: from TBDCEXCH10.US.Cingular.Net ([10.148.14.47]) by
	TD02XSMTP008.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 18 Dec 2006 09:51:23 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Simple] WGLC: draft-ietf-simple-imdn-02.txt
Date: Mon, 18 Dec 2006 09:51:23 -0600
Message-ID: <451C9AB8BFB6B64EA11547A3D966DB3608D35265@TBDCEXCH10.US.Cingular.Net>
In-Reply-To: <D24387E7-7F9C-42BC-B53C-B4FFF4D7D849@nostrum.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] WGLC: draft-ietf-simple-imdn-02.txt
Thread-Index: AccgCq3zxGbUl/0IQ1GjUqe6bJ5gugCr78eQ
To: "Ben Campbell" <ben@nostrum.com>
X-OriginalArrivalTime: 18 Dec 2006 15:51:23.0693 (UTC)
	FILETIME=[5E6FCDD0:01C722BC]
From: "Stafford, Matthew" <matthew.stafford@cingular.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8
Cc: simple@ietf.org
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org

Thanks for your response. Inline.

-----Original Message-----
From: Ben Campbell [mailto:ben@nostrum.com]=20
Sent: Thursday, December 14, 2006 11:34 PM
To: Stafford, Matthew
Cc: Robert Sparks; simple@ietf.org
Subject: Re: [Simple] WGLC: draft-ietf-simple-imdn-02.txt


On Dec 14, 2006, at 9:40 PM, Stafford, Matthew wrote:

> I'd like to raise an issue regarding the statement that "IMDN is not
> generally applicable to MSRP". IMHO IMDN's usefulness in the =20
> context of
> SIP MESSAGE will be compromised if it cannot also be applied to MSRP.
>

Perhaps a better wording in the draft is "We have not fully explored =20
the use cases for MSRP, so they are out of scope for this document. =20
They may be addressed in a separate work."

I think the real point of removing MSRP from the document was not to =20
say that we know categorically that there are no valid uses with =20
MSRP. Rather, it was that such uses were not entirely clear, and if =20
they are needed they require further exploration. We did not want to =20
block progression of the spec on how to do IMDN with page mode until =20
we completely understood how to do it with MSRP.


> I take the point that, when two subscribers are participating in an
> ongoing session, it's odd to talk about IMDN concepts such as read
> receipt.
>
> However, "one-and-done" messages can easily exceed the 1300-byte limit
> for SIP MESSAGE over UDP, especially when request-contained =20
> distribution
> lists and/or multimedia attachments come into play. CPIM headers will
> further reduce "headroom".
>
> To address this limitation, OMA's SIMPLE IM working group has =20
> identified
> "large message mode" (in addition to page mode and session mode). In
> large message mode, an MSRP session is set up to transfer a one-time
> message that is bigger than 1300 bytes. But the subscriber is =20
> blissfully
> unaware of the difference between page mode and large message mode-
> nothing at the UI layer reflects that there is an underlying =20
> session in
> the latter case. The UI just presents a "unified composer" to the
> subscriber. If the UI allows the subscriber to request read =20
> receipts for
> small messages but not for big ones, I think the subscriber will be
> baffled. Consider, for example, a case in which the subscriber =20
> composes
> a text message and checks the "request read receipt" box. Then, on the
> fly, he/she decides to add an attachment before sending the message.
> It's really awkward to step in at that point and say no, sorry- you =20
> can
> have one or the other but not both.
>

In such a case, the user request for a receipt would be satisfied by =20
the MSRP report mechanism, wouldn't it? That is, if the client is =20
smart enough to switch to using MSRP rather than page mode, it would =20
also be smart enough to request a delivery confirmation using the =20
mechanism already in MSRP?

<<< OK in this use case for _delivery_ notification (but see below), but
what about _read_ notification? >>>

Now, if the use case you describe is one where the IMDN needs to be =20
delivered after the MSRP session is completed (for example, the large =20
message gets sent to a store and forward server), then we have a =20
_very_ good example of something that needs more exploration before =20
we try to specify how to do it.

<<< I think we do have such an example: OMA defines a deferred messaging
function in which the IM server stores messages for later delivery in
the case that an intended recipient is unavailable. So I think you've
put your finger squarely on an OMA use case. >>>

> In summary, I think OMA's taxonomy of messaging modes is very natural-
> from the POV of supporting use cases that will make sense to the =20
> average
> subscriber. IMDN consistency across page and large message modes seems
> equally natural to me.
>
> Best,
> Matt Stafford
> Cingular Wireless
>
> -----Original Message-----
> From: Robert Sparks [mailto:rjsparks@nostrum.com]
> Sent: Monday, December 11, 2006 10:22 AM
> To: simple@ietf.org
> Cc: simple-ads@tools.ietf.org
> Subject: [Simple] WGLC: draft-ietf-simple-imdn-02.txt
>
> This is a SIMPLE WGLC for
> http://www.ietf.org/internet-drafts/draft-ietf-simple-imdn-02.txt
>
> Please have your comments to the list by December 25 (more on this
> timing below)
>
> Please send your comments to the list and copy Hisham and Eric.
> Given the timing, it is especially important for you to respond if
> you think the draft is ready to go with no changes.
>
> IF YOU HAVE A COMMENT TO MAKE BUT DON"T FEEL THIS IS ENOUGH TIME,
> send email to the chairs right away. We'll extend this if there's any
> felt need.
>
> Why the timing? :
>     First off, I was slow in issuing the last call - that should have
> happened at the beginning of the month.
>     Hisham (who has the pen right now) has some travel across the new
> year where he will be less responsive
>     than usual. Our take is that this draft has little to no
> controversy left and has undergone a lot of scrutiny.
>     If the LC feedback from the group shows it is ready to go, Hisham
> can make any needed minor edits before
>     he drops offline and we can start into the request for
> publication process. If the feedback shows more time in
>     LC is needed, we'll adjust, moving closure into the new year. In
> order to gauge this, it is very important that you
>     respond even if you have no changes to suggest.
>
> If you are not planning to review/comment on this draft, please let
> me know.
>
> RjS
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Mon Dec 18 11:08:05 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GwL1u-0003fW-Qo; Mon, 18 Dec 2006 11:07:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GwL1t-0003fO-FX
	for simple@ietf.org; Mon, 18 Dec 2006 11:07:53 -0500
Received: from ug-out-1314.google.com ([66.249.92.171])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwL1q-00085u-Sq
	for simple@ietf.org; Mon, 18 Dec 2006 11:07:53 -0500
Received: by ug-out-1314.google.com with SMTP id 72so1420976ugd
	for <simple@ietf.org>; Mon, 18 Dec 2006 08:07:49 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=aIDhGK8NiuUvpoY4Y0oFsh0RYCEY0Lrl6l4msjvdTGIrLV+buBpeyH34WhyBuy2srZCyNynRB3auD+gmmASNF7J6/EPjSpN64l5jc9oonS9ZgVJGI4URLseHPC7qPiYNdVjc8qQ1bg5ronyPS9qjdEaRNuJbQ1bg2AajBSp9B6c=
Received: by 10.78.201.2 with SMTP id y2mr3221306huf.1166458069514;
	Mon, 18 Dec 2006 08:07:49 -0800 (PST)
Received: by 10.78.206.11 with HTTP; Mon, 18 Dec 2006 08:07:49 -0800 (PST)
Message-ID: <66cd252f0612180807w368ca5f6n257fa2020dfa3908@mail.gmail.com>
Date: Mon, 18 Dec 2006 17:07:49 +0100
From: "Hisham Khartabil" <hisham.khartabil@gmail.com>
To: "Stafford, Matthew" <matthew.stafford@cingular.com>
Subject: Re: [Simple] WGLC: draft-ietf-simple-imdn-02.txt
In-Reply-To: <451C9AB8BFB6B64EA11547A3D966DB3608D35265@TBDCEXCH10.US.Cingular.Net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <D24387E7-7F9C-42BC-B53C-B4FFF4D7D849@nostrum.com>
	<451C9AB8BFB6B64EA11547A3D966DB3608D35265@TBDCEXCH10.US.Cingular.Net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f
Cc: Ben Campbell <ben@nostrum.com>, simple@ietf.org
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org

Matthew,

I appreciate the requirements you are putting forward for IMDNs for
session mode messaging. It was agreed in the last IETF meeting that
this will be for further study and will be kep out of the current IMDN
draft, limiting its scope to page mode IMs.

You have valid use cases for large messages to use MSRP (although the
user doesnt know it is in fact a session) plus the store and forward
IM session (which doesnt make much sense). In any case, you will need
to bring forward those requirements in an internet draft form and we
can discuss those requirements on the mailing list. You are also free
to present them in the next IETF meeting. Once the requirements are
clear, we can start working on the solution.

One solution I can think of for your large message read report problem
is that you can send a page mode IMDN referring to the message ID of
the session, or embedding the session id and message  id into the
Message-ID header. This probably also works fine for store and
forward..

The point I'm trying to make is that it is not as easy as just saying
"this also applies to session mode". Requirements and solutions need
to be studied.

Thanks,
Hisham

On 18/12/06, Stafford, Matthew <matthew.stafford@cingular.com> wrote:
> Thanks for your response. Inline.
>
> -----Original Message-----
> From: Ben Campbell [mailto:ben@nostrum.com]
> Sent: Thursday, December 14, 2006 11:34 PM
> To: Stafford, Matthew
> Cc: Robert Sparks; simple@ietf.org
> Subject: Re: [Simple] WGLC: draft-ietf-simple-imdn-02.txt
>
>
> On Dec 14, 2006, at 9:40 PM, Stafford, Matthew wrote:
>
> > I'd like to raise an issue regarding the statement that "IMDN is not
> > generally applicable to MSRP". IMHO IMDN's usefulness in the
> > context of
> > SIP MESSAGE will be compromised if it cannot also be applied to MSRP.
> >
>
> Perhaps a better wording in the draft is "We have not fully explored
> the use cases for MSRP, so they are out of scope for this document.
> They may be addressed in a separate work."
>
> I think the real point of removing MSRP from the document was not to
> say that we know categorically that there are no valid uses with
> MSRP. Rather, it was that such uses were not entirely clear, and if
> they are needed they require further exploration. We did not want to
> block progression of the spec on how to do IMDN with page mode until
> we completely understood how to do it with MSRP.
>
>
> > I take the point that, when two subscribers are participating in an
> > ongoing session, it's odd to talk about IMDN concepts such as read
> > receipt.
> >
> > However, "one-and-done" messages can easily exceed the 1300-byte limit
> > for SIP MESSAGE over UDP, especially when request-contained
> > distribution
> > lists and/or multimedia attachments come into play. CPIM headers will
> > further reduce "headroom".
> >
> > To address this limitation, OMA's SIMPLE IM working group has
> > identified
> > "large message mode" (in addition to page mode and session mode). In
> > large message mode, an MSRP session is set up to transfer a one-time
> > message that is bigger than 1300 bytes. But the subscriber is
> > blissfully
> > unaware of the difference between page mode and large message mode-
> > nothing at the UI layer reflects that there is an underlying
> > session in
> > the latter case. The UI just presents a "unified composer" to the
> > subscriber. If the UI allows the subscriber to request read
> > receipts for
> > small messages but not for big ones, I think the subscriber will be
> > baffled. Consider, for example, a case in which the subscriber
> > composes
> > a text message and checks the "request read receipt" box. Then, on the
> > fly, he/she decides to add an attachment before sending the message.
> > It's really awkward to step in at that point and say no, sorry- you
> > can
> > have one or the other but not both.
> >
>
> In such a case, the user request for a receipt would be satisfied by
> the MSRP report mechanism, wouldn't it? That is, if the client is
> smart enough to switch to using MSRP rather than page mode, it would
> also be smart enough to request a delivery confirmation using the
> mechanism already in MSRP?
>
> <<< OK in this use case for _delivery_ notification (but see below), but
> what about _read_ notification? >>>
>
> Now, if the use case you describe is one where the IMDN needs to be
> delivered after the MSRP session is completed (for example, the large
> message gets sent to a store and forward server), then we have a
> _very_ good example of something that needs more exploration before
> we try to specify how to do it.
>
> <<< I think we do have such an example: OMA defines a deferred messaging
> function in which the IM server stores messages for later delivery in
> the case that an intended recipient is unavailable. So I think you've
> put your finger squarely on an OMA use case. >>>
>
> > In summary, I think OMA's taxonomy of messaging modes is very natural-
> > from the POV of supporting use cases that will make sense to the
> > average
> > subscriber. IMDN consistency across page and large message modes seems
> > equally natural to me.
> >
> > Best,
> > Matt Stafford
> > Cingular Wireless
> >
> > -----Original Message-----
> > From: Robert Sparks [mailto:rjsparks@nostrum.com]
> > Sent: Monday, December 11, 2006 10:22 AM
> > To: simple@ietf.org
> > Cc: simple-ads@tools.ietf.org
> > Subject: [Simple] WGLC: draft-ietf-simple-imdn-02.txt
> >
> > This is a SIMPLE WGLC for
> > http://www.ietf.org/internet-drafts/draft-ietf-simple-imdn-02.txt
> >
> > Please have your comments to the list by December 25 (more on this
> > timing below)
> >
> > Please send your comments to the list and copy Hisham and Eric.
> > Given the timing, it is especially important for you to respond if
> > you think the draft is ready to go with no changes.
> >
> > IF YOU HAVE A COMMENT TO MAKE BUT DON"T FEEL THIS IS ENOUGH TIME,
> > send email to the chairs right away. We'll extend this if there's any
> > felt need.
> >
> > Why the timing? :
> >     First off, I was slow in issuing the last call - that should have
> > happened at the beginning of the month.
> >     Hisham (who has the pen right now) has some travel across the new
> > year where he will be less responsive
> >     than usual. Our take is that this draft has little to no
> > controversy left and has undergone a lot of scrutiny.
> >     If the LC feedback from the group shows it is ready to go, Hisham
> > can make any needed minor edits before
> >     he drops offline and we can start into the request for
> > publication process. If the feedback shows more time in
> >     LC is needed, we'll adjust, moving closure into the new year. In
> > order to gauge this, it is very important that you
> >     respond even if you have no changes to suggest.
> >
> > If you are not planning to review/comment on this draft, please let
> > me know.
> >
> > RjS
> >
> > _______________________________________________
> > Simple mailing list
> > Simple@ietf.org
> > https://www1.ietf.org/mailman/listinfo/simple
> >
> > _______________________________________________
> > Simple mailing list
> > Simple@ietf.org
> > https://www1.ietf.org/mailman/listinfo/simple
>
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
>

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Mon Dec 18 11:37:23 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GwLUG-0008BF-19; Mon, 18 Dec 2006 11:37:12 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GwLUE-0008B7-5m
	for simple@ietf.org; Mon, 18 Dec 2006 11:37:10 -0500
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwLUC-0005QU-Sw
	for simple@ietf.org; Mon, 18 Dec 2006 11:37:10 -0500
Received: from [172.17.2.115] (vicuna-alt.estacado.net [75.53.54.121])
	(authenticated bits=0)
	by nostrum.com (8.13.8/8.13.8) with ESMTP id kBIGavXr011994
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Mon, 18 Dec 2006 10:36:58 -0600 (CST) (envelope-from ben@nostrum.com)
In-Reply-To: <451C9AB8BFB6B64EA11547A3D966DB3608D35265@TBDCEXCH10.US.Cingular.Net>
References: <451C9AB8BFB6B64EA11547A3D966DB3608D35265@TBDCEXCH10.US.Cingular.Net>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <ABE976BD-91ED-4590-833C-C5CDE9800EF6@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Ben Campbell <ben@nostrum.com>
Subject: Re: [Simple] WGLC: draft-ietf-simple-imdn-02.txt
Date: Mon, 18 Dec 2006 10:36:56 -0600
To: "Stafford, Matthew" <matthew.stafford@cingular.com>
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
	mechanism)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: simple@ietf.org
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org


On Dec 18, 2006, at 9:51 AM, Stafford, Matthew wrote:

> In such a case, the user request for a receipt would be satisfied by
> the MSRP report mechanism, wouldn't it? That is, if the client is
> smart enough to switch to using MSRP rather than page mode, it would
> also be smart enough to request a delivery confirmation using the
> mechanism already in MSRP?
>
> <<< OK in this use case for _delivery_ notification (but see  
> below), but
> what about _read_ notification? >>>

Yes, "read" notification is an interesting case. For direct (not  
store-and-forward) sessions, this might be doable with an MSRP  
extension adding a "read" state to the sorts of things you can report  
on.

Since it would not help for the OMA store and forward case, it might  
be easier to address with IMDN.

>
> Now, if the use case you describe is one where the IMDN needs to be
> delivered after the MSRP session is completed (for example, the large
> message gets sent to a store and forward server), then we have a
> _very_ good example of something that needs more exploration before
> we try to specify how to do it.
>
> <<< I think we do have such an example: OMA defines a deferred  
> messaging
> function in which the IM server stores messages for later delivery in
> the case that an intended recipient is unavailable. So I think you've
> put your finger squarely on an OMA use case. >>>

Just to be clear, the reason that I have resisted having us to just  
add this use case to the IMDN draft is that we do not have a clear  
understanding (or at least an agreed upon one) on how you would  
deliver an IMDN for a message that was sent in an MSRP session that  
no longer exists. Perhaps you send a page mode message, open an MSRP  
session in the opposite direction, or something completely different.  
There are also issues on how you address and route an IMDN that goes  
out via a different medium.  These are likely to create some spirited  
discussion, which will take a while to resolve.

I am happy to have that discussion, I just don't want to see the page  
mode use of IMDN blocked on it.


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Mon Dec 18 12:35:38 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GwMOO-0008GL-5f; Mon, 18 Dec 2006 12:35:12 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GwMON-0008G6-8i
	for simple@ietf.org; Mon, 18 Dec 2006 12:35:11 -0500
Received: from extmail10.cingular.com ([170.35.225.25] helo=cingular.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwMOM-0007Y2-Pi
	for simple@ietf.org; Mon, 18 Dec 2006 12:35:11 -0500
Received: from ([10.148.14.30])
	by extmail10.cingular.com with ESMTP  id KP-VYFP6.86604379;
	Mon, 18 Dec 2006 12:34:54 -0500
Received: from TBDCEXCH10.US.Cingular.Net ([10.148.14.47]) by
	TD02XSMTP008.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 18 Dec 2006 11:34:54 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Simple] WGLC: draft-ietf-simple-imdn-02.txt
Date: Mon, 18 Dec 2006 11:34:52 -0600
Message-ID: <451C9AB8BFB6B64EA11547A3D966DB3608D35312@TBDCEXCH10.US.Cingular.Net>
In-Reply-To: <4582A076.2040703@nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] WGLC: draft-ietf-simple-imdn-02.txt
Thread-Index: AccgTEmco8QdYx7CTYG+OAVBKa3Y2QCcNpWA
To: "Miguel Garcia" <Miguel.An.Garcia@nokia.com>,
	"Ben Campbell" <ben@nostrum.com>
X-OriginalArrivalTime: 18 Dec 2006 17:34:54.0060 (UTC)
	FILETIME=[D41A9AC0:01C722CA]
From: "Stafford, Matthew" <matthew.stafford@cingular.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bf422c85703d3d847fb014987125ac48
Cc: simple@ietf.org
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org

Inline.

Thanks,
Matt

-----Original Message-----
From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com]=20
Sent: Friday, December 15, 2006 7:18 AM
To: Ben Campbell
Cc: Stafford, Matthew; simple@ietf.org
Subject: Re: [Simple] WGLC: draft-ietf-simple-imdn-02.txt

Mathew, Ben:

I think I agree with Ben here, that the spirit of the text is NOT to say

that "we are in the absolute possession of the truth, and it indicates=20
that IMDN does not make sense with MSRP". Instead, the spirit of the=20
text tries to say that in those cases we have explored, MSRP conveys all

the tools for providing IMDN except for the read case. But the read case

is not applicable to session based messaging where messages are=20
sequentially displayed in a chat windows (because the endpoint will=20
blindly generate the IMDN-read always, so what is the point?). Please=20
not the word "generally" in the text.

Now, it seems that OMA is going on step beyond the "general" use cases=20
for MSRP, and I have no problem with that, but we haven't done an=20
analysis of those uses cases and the impact of IMDN to those use cases.

The text in the draft also says: "If new requirements arise in the=20
future determining the need for IMDN in MSRP, new specifications can be=20
drafted". And this is what I would like to see, we know how IMDN is=20
useful and can be applied for SIP, so let's finish the document now. I=20
don't mind if we simultaneously keep on analyzing the need of IMDN for=20
MSRP, and if needed, write a separate spec to apply IMDN for MSRP. Would

that solve your concern, Mathew?

<<< If incorporating MSRP would indeed cause significant delay, I can
understand your point. If the decision is made to go ahead w/o MSRP (in
this particular document), would it be appropriate to modify the last
sentence of the abstract accordingly? >>>

BR,

      Miguel

PS: I am in the middle of my review of MSRP, I expect to post my=20
comments in the following days.





Ben Campbell wrote:
>=20
> On Dec 14, 2006, at 9:40 PM, Stafford, Matthew wrote:
>=20
>> I'd like to raise an issue regarding the statement that "IMDN is not
>> generally applicable to MSRP". IMHO IMDN's usefulness in the context
of
>> SIP MESSAGE will be compromised if it cannot also be applied to MSRP.
>>
>=20
> Perhaps a better wording in the draft is "We have not fully explored
the=20
> use cases for MSRP, so they are out of scope for this document. They
may=20
> be addressed in a separate work."
>=20
> I think the real point of removing MSRP from the document was not to
say=20
> that we know categorically that there are no valid uses with MSRP.=20
> Rather, it was that such uses were not entirely clear, and if they are

> needed they require further exploration. We did not want to block=20
> progression of the spec on how to do IMDN with page mode until we=20
> completely understood how to do it with MSRP.
>=20
>=20
>> I take the point that, when two subscribers are participating in an
>> ongoing session, it's odd to talk about IMDN concepts such as read
>> receipt.
>>
>> However, "one-and-done" messages can easily exceed the 1300-byte
limit
>> for SIP MESSAGE over UDP, especially when request-contained
distribution
>> lists and/or multimedia attachments come into play. CPIM headers will
>> further reduce "headroom".
>>
>> To address this limitation, OMA's SIMPLE IM working group has
identified
>> "large message mode" (in addition to page mode and session mode). In
>> large message mode, an MSRP session is set up to transfer a one-time
>> message that is bigger than 1300 bytes. But the subscriber is
blissfully
>> unaware of the difference between page mode and large message mode-
>> nothing at the UI layer reflects that there is an underlying session
in
>> the latter case. The UI just presents a "unified composer" to the
>> subscriber. If the UI allows the subscriber to request read receipts
for
>> small messages but not for big ones, I think the subscriber will be
>> baffled. Consider, for example, a case in which the subscriber
composes
>> a text message and checks the "request read receipt" box. Then, on
the
>> fly, he/she decides to add an attachment before sending the message.
>> It's really awkward to step in at that point and say no, sorry- you
can
>> have one or the other but not both.
>>
>=20
> In such a case, the user request for a receipt would be satisfied by
the=20
> MSRP report mechanism, wouldn't it? That is, if the client is smart=20
> enough to switch to using MSRP rather than page mode, it would also be

> smart enough to request a delivery confirmation using the mechanism=20
> already in MSRP?
>=20
>=20
> Now, if the use case you describe is one where the IMDN needs to be=20
> delivered after the MSRP session is completed (for example, the large=20
> message gets sent to a store and forward server), then we have a
_very_=20
> good example of something that needs more exploration before we try to

> specify how to do it.
>=20
>> In summary, I think OMA's taxonomy of messaging modes is very
natural-
>> from the POV of supporting use cases that will make sense to the
average
>> subscriber. IMDN consistency across page and large message modes
seems
>> equally natural to me.
>>
>> Best,
>> Matt Stafford
>> Cingular Wireless
>>
>> -----Original Message-----
>> From: Robert Sparks [mailto:rjsparks@nostrum.com]
>> Sent: Monday, December 11, 2006 10:22 AM
>> To: simple@ietf.org
>> Cc: simple-ads@tools.ietf.org
>> Subject: [Simple] WGLC: draft-ietf-simple-imdn-02.txt
>>
>> This is a SIMPLE WGLC for
>> http://www.ietf.org/internet-drafts/draft-ietf-simple-imdn-02.txt
>>
>> Please have your comments to the list by December 25 (more on this
>> timing below)
>>
>> Please send your comments to the list and copy Hisham and Eric.
>> Given the timing, it is especially important for you to respond if
>> you think the draft is ready to go with no changes.
>>
>> IF YOU HAVE A COMMENT TO MAKE BUT DON"T FEEL THIS IS ENOUGH TIME,
>> send email to the chairs right away. We'll extend this if there's any
>> felt need.
>>
>> Why the timing? :
>>     First off, I was slow in issuing the last call - that should have
>> happened at the beginning of the month.
>>     Hisham (who has the pen right now) has some travel across the new
>> year where he will be less responsive
>>     than usual. Our take is that this draft has little to no
>> controversy left and has undergone a lot of scrutiny.
>>     If the LC feedback from the group shows it is ready to go, Hisham
>> can make any needed minor edits before
>>     he drops offline and we can start into the request for
>> publication process. If the feedback shows more time in
>>     LC is needed, we'll adjust, moving closure into the new year. In
>> order to gauge this, it is very important that you
>>     respond even if you have no changes to suggest.
>>
>> If you are not planning to review/comment on this draft, please let
>> me know.
>>
>> RjS

--=20
Miguel A. Garcia           tel:+358-50-4804586
sip:miguel.garcia@neonsite.net
Nokia Research Center      Helsinki, Finland

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Mon Dec 18 12:38:16 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GwMRF-0000vX-Li; Mon, 18 Dec 2006 12:38:09 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GwMRD-0000uj-P5
	for simple@ietf.org; Mon, 18 Dec 2006 12:38:07 -0500
Received: from wr-out-0506.google.com ([64.233.184.236])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwMRB-0007pa-HG
	for simple@ietf.org; Mon, 18 Dec 2006 12:38:07 -0500
Received: by wr-out-0506.google.com with SMTP id i7so1022198wra
	for <simple@ietf.org>; Mon, 18 Dec 2006 09:38:05 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=UdnAM40KSkzjef6MyY6BPMbbXMG+FHKu8TCcCV9fv8Jx/nZduoH9q1Bzcl2Nv+XA+9e4O+NiaMWz0fYNsoMb2BuyNyOLv7ngZQ/FLA8dwGN2JOGU+23qby4cuk1pc8BCV3GHXqb+g6AtsWhYxn5OPbbGmFVVQ41tyZEaVTv85zA=
Received: by 10.78.171.13 with SMTP id t13mr2536815hue.1166463484050;
	Mon, 18 Dec 2006 09:38:04 -0800 (PST)
Received: by 10.78.206.11 with HTTP; Mon, 18 Dec 2006 09:38:03 -0800 (PST)
Message-ID: <66cd252f0612180938u48376ebcw22e408e524fcd22a@mail.gmail.com>
Date: Mon, 18 Dec 2006 18:38:03 +0100
From: "Hisham Khartabil" <hisham.khartabil@gmail.com>
To: "Stafford, Matthew" <matthew.stafford@cingular.com>
Subject: Re: [Simple] WGLC: draft-ietf-simple-imdn-02.txt
In-Reply-To: <451C9AB8BFB6B64EA11547A3D966DB3608D35312@TBDCEXCH10.US.Cingular.Net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4582A076.2040703@nokia.com>
	<451C9AB8BFB6B64EA11547A3D966DB3608D35312@TBDCEXCH10.US.Cingular.Net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: Miguel Garcia <Miguel.An.Garcia@nokia.com>, Ben Campbell <ben@nostrum.com>,
	simple@ietf.org
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org

On 18/12/06, Stafford, Matthew <matthew.stafford@cingular.com> wrote:
> Inline.
>
> Thanks,
> Matt
>
> -----Original Message-----
> From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com]
> Sent: Friday, December 15, 2006 7:18 AM
> To: Ben Campbell
> Cc: Stafford, Matthew; simple@ietf.org
> Subject: Re: [Simple] WGLC: draft-ietf-simple-imdn-02.txt
>
> Mathew, Ben:
>
> I think I agree with Ben here, that the spirit of the text is NOT to say
>
> that "we are in the absolute possession of the truth, and it indicates
> that IMDN does not make sense with MSRP". Instead, the spirit of the
> text tries to say that in those cases we have explored, MSRP conveys all
>
> the tools for providing IMDN except for the read case. But the read case
>
> is not applicable to session based messaging where messages are
> sequentially displayed in a chat windows (because the endpoint will
> blindly generate the IMDN-read always, so what is the point?). Please
> not the word "generally" in the text.
>
> Now, it seems that OMA is going on step beyond the "general" use cases
> for MSRP, and I have no problem with that, but we haven't done an
> analysis of those uses cases and the impact of IMDN to those use cases.
>
> The text in the draft also says: "If new requirements arise in the
> future determining the need for IMDN in MSRP, new specifications can be
> drafted". And this is what I would like to see, we know how IMDN is
> useful and can be applied for SIP, so let's finish the document now. I
> don't mind if we simultaneously keep on analyzing the need of IMDN for
> MSRP, and if needed, write a separate spec to apply IMDN for MSRP. Would
>
> that solve your concern, Mathew?
>
> <<< If incorporating MSRP would indeed cause significant delay, I can
> understand your point. If the decision is made to go ahead w/o MSRP (in
> this particular document), would it be appropriate to modify the last
> sentence of the abstract accordingly? >>>
>

Yes. That was an oversight. Apologies for that. I will be fixed in the
next version.

Hisham

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Tue Dec 19 02:29:56 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GwZPX-0001VG-SQ; Tue, 19 Dec 2006 02:29:15 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GwZPU-0001UX-Fb
	for simple@ietf.org; Tue, 19 Dec 2006 02:29:12 -0500
Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwZPT-000275-0I
	for simple@ietf.org; Tue, 19 Dec 2006 02:29:12 -0500
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211])
	by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id
	kBJ7SBDL021169; Tue, 19 Dec 2006 09:28:26 +0200
Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by
	esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 19 Dec 2006 09:28:19 +0200
Received: from [10.162.61.207] ([10.162.61.207]) by esebh001.NOE.Nokia.com
	with Microsoft SMTPSVC(5.0.2195.6881); 
	Tue, 19 Dec 2006 09:28:19 +0200
Message-ID: <45879492.5030208@nokia.com>
Date: Tue, 19 Dec 2006 09:28:18 +0200
From: Miguel Garcia <Miguel.An.Garcia@nokia.com>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: "Stafford, Matthew" <matthew.stafford@cingular.com>
Subject: Re: [Simple] WGLC: draft-ietf-simple-imdn-02.txt
References: <451C9AB8BFB6B64EA11547A3D966DB3608D35312@TBDCEXCH10.US.Cingular.Net>
In-Reply-To: <451C9AB8BFB6B64EA11547A3D966DB3608D35312@TBDCEXCH10.US.Cingular.Net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Dec 2006 07:28:19.0022 (UTC)
	FILETIME=[416246E0:01C7233F]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: Ben Campbell <ben@nostrum.com>, simple@ietf.org
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org

Stafford, Matthew wrote:

> <<< If incorporating MSRP would indeed cause significant delay, I can
> understand your point. If the decision is made to go ahead w/o MSRP (in
> this particular document), would it be appropriate to modify the last
> sentence of the abstract accordingly? >>>
> 

Absolutely. I am still reviewing the draft, but I have noticed that the 
draft still has several outdated anchors to MSRP, which should be 
removed. I will have a more detailed comment together with the rest of 
my comments.

/Miguel


-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:miguel.garcia@neonsite.net
Nokia Research Center      Helsinki, Finland

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From oaxjvbk@compugen.com Wed Dec 20 02:09:55 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GwvaN-0007Kw-Au
	for simple-archive@lists.ietf.org; Wed, 20 Dec 2006 02:09:55 -0500
Received: from [59.18.229.234] (helo=[59.18.229.234])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GwvaL-0007cw-SS
	for simple-archive@lists.ietf.org; Wed, 20 Dec 2006 02:09:55 -0500
From:	"assured" <oaxjvbk@compugen.com>
To: simple-archive@lists.ietf.org
Subject: Foster
Date:	Wed, 20 Dec 2006 16:09:57 -0900
MIME-Version: 1.0
Content-Type: multipart/related;
	boundary="----=_NextPart_000_0002_01C72451.4B3A2080"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: AcckUUs6tSJVUXHNS8aqw0Fvztvy3A==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
Message-Id: <2E1045B2CD7546C.AD6BA98E2E@compugen.com>
X-Spam-Score: 3.7 (+++)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc

------=_NextPart_000_0002_01C72451.4B3A2080
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=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2912" name=3D"GENERATOR">
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><STRONG><FONT size=3D3>The hottest gold =
stock pick=20
this year!</FONT></STRONG>&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR><EM>It just doesn't =
get any=20
better than this.&nbsp; Booming sector, tightly held, with an incredible =
PR=20
blitz starting up.&nbsp; Not only that, but the company is set to =
release some=20
smashing news as it moves into the New=20
Year!<BR></EM>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
<BR><STRONG>Drake Gold=20
Resources Inc</STRONG>.&nbsp; =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>Symbol: <STRONG>DKGR&nbsp;</STRONG> <BR>Current=20
Price:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
<STRONG>$.009 (+6% Tuesday!)&nbsp;&nbsp;&nbsp;&nbsp; =
<BR></STRONG>Short-Term=20
Projected Price:&nbsp; =
<STRONG>$.05</STRONG>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>Long-Term Target Price:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<STRONG>=20
$.20</STRONG>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><STRONG>As gold prices are on the rise =
($622=20
oz),</STRONG> Drake has positioned itself well for 2007 with its 1st =
project=20
located in Arizona which has an estimated $102 million in recoverable =
gold @=20
205,000 oz.&nbsp; Short of the BLM permits expected possibly a =
day&#8217;s away it is=20
a screaming buy around a penny.&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR><STRONG>DKGR is =
already=20
hitting it big in the sector</STRONG>.&nbsp; With solid acquisitions =
with hard=20
assets in the ground, and a red-hot sector, DKGR is looking at an =
explosive=20
year.&nbsp; News out after market on Tuesday proves Drake&#8217;s =
mission to expand=20
shareholder value making Drake a multi-property resource =
company.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The new petroleum division spins off on =
the 3rd of=20
January as Drake forms a new company for its oil and gas projects.&nbsp; =
A=20
dividend is promised to all shareholders as of that date.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Based on .10 oz of gold per yard =
running a 100=20
cubic yard an hour plant, earnings would excel projections to help =
justify a .10=20
+ share price based on 10x earnings.&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><EM><STRONG>Check your favorite news =
source.&nbsp;=20
Check your Level 2 market data.&nbsp; You will see that this one is set =
for an=20
explosion.<BR></STRONG></EM>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR><EM>With the huge publicity that is on the way THIS is where you =
want to=20
be.</EM>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial size=3D2><BR><STRONG><U>Make sure you get in =
early on=20
December 20th.&nbsp; Win big with =
DKGR!</U></STRONG></FONT></DIV></BODY></HTML>

------=_NextPart_000_0002_01C72451.4B3A2080--




From simple-bounces@ietf.org Wed Dec 20 10:22:17 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gx3GD-0006Qs-8f; Wed, 20 Dec 2006 10:21:37 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx3GB-0006Qk-G4
	for simple@ietf.org; Wed, 20 Dec 2006 10:21:35 -0500
Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx3GA-0003f8-91
	for simple@ietf.org; Wed, 20 Dec 2006 10:21:35 -0500
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213])
	by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id
	kBKFK82P004030; Wed, 20 Dec 2006 17:20:48 +0200
Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by
	esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 20 Dec 2006 17:20:51 +0200
Received: from [172.21.58.172] ([172.21.58.172]) by esebh001.NOE.Nokia.com
	with Microsoft SMTPSVC(5.0.2195.6881); 
	Wed, 20 Dec 2006 17:20:52 +0200
Message-ID: <458954D3.9080209@nokia.com>
Date: Wed, 20 Dec 2006 17:20:51 +0200
From: Miguel Garcia <Miguel.An.Garcia@nokia.com>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: simple@ietf.org
Subject: Re: [Simple] WGLC: draft-ietf-simple-imdn-02.txt
References: <B2A87D48-27F5-4ECF-B4EC-CFC814E37A80@nostrum.com>
In-Reply-To: <B2A87D48-27F5-4ECF-B4EC-CFC814E37A80@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Dec 2006 15:20:52.0000 (UTC)
	FILETIME=[6F7D2200:01C7244A]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e
Cc: Eric Burger <EBurger@cantata.com>
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org

Here are my comments to IMDN-02.txt

- In several places the draft still has some MSRP leftovers, and should 
be removed:

In the Abstract, replace:

    ... processing and read notifications, for
    page-mode as well as session mode instant messages.

with

    ... processing and read notifications, for
    page-mode instant messages.

Also in the Abstract, replace:

    This document also describes how SIP and MSRP entities behave using
    this extension.

with

    This document also describes how SIP entities behave using
    this extension.

In Section 1, 3rd paragraph, remove the last line:

    The MSRP [11] SEND
    request can also be used to carry Message/CPIM messages.

In Section 1, last paragraph, replace:

    This document also describes how SIP and MSRP entities behave using
    this extension.

with:

    This document also describes how SIP and MSRP entities behave using
    this extension.

In Section 3, last bullet point, replace:

    o  Transport Protocol Message: An IM or an IMDN wrapped in a
       transport protocol like SIP or MSRP.

with:

    o  Transport Protocol Message: An IM or an IMDN wrapped in SIP.

Actually, I think it is even better to remove the definition of 
"Transport Protocol Message", because I think it is no longer used by 
the specification, now that is restricted to SIP.

Delete completely Section 13.


- Comment in the terminology (Section 3). The 'IM Sender' definition 
indicates that the IM Sender might be different from the IMDN recipient. 
Doesn't this create a security threat by allowing endpoints to redirect 
IMDNs to third parties?

- Terminology, Section 3. I would suggest to decouple the IMDN payload 
from the fact that is an XML document of MIME type message/imdn+xml, 
because in the future you could create other MIME types, and still be an 
IMDN payload. So I would suggest to replace:

    o  IMDN Payload or XML Document: An XML document carrying the
       disposition notification information.  It is always of MIME type
       "message/imdn+xml".

with:

    o  IMDN Payload: An document, typically an XML document, carrying the
       disposition notification information.


- Suggestion: add a caption to Figure 1, e.g., "Figure 1: Overview of 
the Protocol Operation", and then in the first line of the first 
paragraph in Section 4, replace:

    The basic protocol flow is depicted in the diagram below

with:

    The basic protocol flow is depicted in Figure 1

- In the paragraph under Figure 1, Section 4. Replace:

    This is specifically true for page-mode IMs where the
    Address of Record (AOR) ...

with

    For example, in page-mode IMs the
    Address of Record (AOR)

- I think Section 4 should also answer the question whether it is 
possible for an IM sender to receive several notifications with respect 
the same IM. I think the answer is yes, especially if there are 
intermediaries storing the message, so it would be nice to answer this 
question to the reader in this Section 4.

- Section 5.2 is about Processing IMDNs. I think we should provide an 
indication of when is the Processing state useful, or when can it be 
generated. Is it the case when there is a gateway or store and forward 
server?

So, replace:

    The processing notification type indicates that an IM has been
    processed by an intermediary.

with:

    The processing notification type indicates that an IM has been
    processed by an intermediary, such as a gateway or a 
store-and-forward server, and the intermediary does not have further 
information about the disposition of the IM.

- Section 5.2 in the first bullet point defines the term "processed", 
but the defined term is part of the definition. This should be avoided. 
The definition should explain with words what "processed" means, perhaps 
adding some example. Suggestion

   o "processed" indicates that a final disposition of the IM is not yet 
known, for example, due to the traversal of a gateway or 
store-and-forward server.


- Section 5.3. We could think of use the term "rendered" rather than 
"read". This is because IMs can carry any kind of message, including 
audio messages, for example. "rendered" is more generally applicable to 
all kind of messages. I would also suggest to replace "Displayed" with 
"rendered" in the first sentence:

    The read notification type indicates whether the IM Recipient
    Displayed the IM to the user or not.

- Section 5.3, in the sake of clarity, replace:

    o  "forbidden" indicate denial by the IM Recipient for the IM Sender
       to receive the requested IMDN.
with

    o  "forbidden" indicate denial by the IM Recipient to receive the 
requested IMDN.

- Section 6.1. Write the namespace (urn:ietf:params:cpim-headers:imdn) 
in a separate line of its own, such as:

    The namespace is:

         urn:ietf:params:cpim-headers:imdn

    As per CPIM [2] requirements, ...

- Section 6.1 reads:

    As per CPIM [2] requirements,
    the new headers defined in the following sections are prepended by
    the string "imdn." in CPIM messages

    The text is partly true only. The prefix is assigned by the NS 
header in CPIM, so one can choose any prefix name other than 'imdn.', so 
it would be nice to have that into consideration. Suggestion:

     The new headers are prefixed by a prefix assigned to the URN 
through the NS header field of the CPIM message. The remaining of this 
specification always assumes an NS header field like this one:

      NS: imdn <urn:ietf:params:cpim-headers:imdn>


- Section 7.1.1 should mention CPIM in addition to the RFC number. So, 
replace:

    An IM is constructed using RFC 3862 [2].

with

    An IM is constructed using the CPIM message format specified in RFC 
3862 [2].

- The second line in 7.1.1 reads:

    The Content-type header
    field indicates the MIME type of the request payload

    which is true, but why do we need to mention Content-type and not 
any of the other headers? This is not relevant at this point in time, so 
I would suggest to delete the sentence.

- Section 7.1.1.3 starts with a strange paragraph:

    In this specification, the IM Sender can request two types of
    delivery notifications: a failure delivery notification and a success
    delivery notification.

   It is strange because it starts describing the type of "Delivery" 
notification, when the title of the section is about "Disposition" 
notification. So, the reader gets a nice mixture of delivery and 
disposition. What about if you replace the above sentence with this one:

    The Disposition-Notification conveys the type of disposition 
notification requested by the IM sender. There are three types of 
disposition notification: delivery, processing, and read. The delivery 
notification is further subdivided into failure and successful delivery 
notifications.

- Section 7.2.1, 3rd paragraph reads:

    An IMDN MUST contain a Message-ID header field.  The same rules of
    uniqueness for the Message-ID header field that appears in an IM
    apply to an IMDN.

    I think it would nice to indicate that the Message-ID of the IMDN is 
different from the Message-ID header of the IM it correlates with.

- Section 7.2.1, what about IMDN-Record-Route headers in IMDN? It think 
they don't make sense in IMDNs, so this section should have normative 
text indicating that cannot be used.

- Section 7.2.1.1, first paragraph reads:

    A delivery notification is constructed in a similar fashion as an IM,
    using RFC 3862 [2].  For delivery notifications, the Content-type
    MUST be of type "message/imdn+xml".  It is an XML document.  The
    schema is described Section 11.  The delivery notification MUST
    contain a Content-Disposition header field with value "notification".
    This indicates to the IM Sender that the message is an IMDN to an IM
    it has earlier sent.

    I think it would be clear of the paragraph is replaced with:

    A delivery notification is constructed in a similar fashion as an IM,
    using a CPIM body [2] that carries a Disposition Notification XML 
document formatted according to the rules specified in Section 11.1. 
The MIME type of the Disposition Notification XML document is 
"message/imdn+xml". The CPIM Content-Disposition header field must be 
set to the value "notification". This indicates to the IM Sender that 
the message is an IMDN to an IM it has earlier sent.


- The example in Section 7.2.1.1 looks a bit strange, because it starts 
with the Content-Type header... The suggestion is either to write a 
complete SIP MESSAGE request or to remove the Content-type header and 
indicate that the example shows only the CPIM body.

- General to all the examples: the XML stuff should be properly 
formatted, so replace:

   <imdn>

   with

    <?xml version="1.0" encoding="UTF-8"?>
    <imdn xlmns="urn:ietf:params:xml:ns:imdn">


- Section 11.1.3, the text reads:

    ... This information is obtained from the To header
    field of the IM.

    It is not clear if the text refers to the CPIM To header or the SIP 
to header. I bet is the CPIM To header. In any case, to achieve 
interoperability, the text should clearly refer to the correct header.


- Section 12.1.1. This section should answer to this question: On 
creating an IMDN, how to populate the Request-URI and the SIP To header?
I think the Request-URI and To header of SIP MESSAGE should set to the 
same (except tags) of the From header field of MESSAGE that carried the IM.


Additionally, the draft should say that:

"Due to the fact that IM senders can remain anonymous, e.g., by setting 
the From header field of the SIP message to an anonymous URI, anonymous 
IM senders are not eligible for requesting disposition notifications. 
Therefore, anonymous IM senders MUST not request disposition notifications."

- General question, not tied to any section. What happens if the IM 
sender has several devices or SIP instances, sends an IM and requests 
IMDN? The desired effect is that IMDNs are received in the same device 
where the IM was sent out. This is calling for something like GRUU, but 
I don't think we can use GRUU in MESSAGE requests. It would be nice to 
either have a solution or just write the limitations of the 
specification with respect several devices/instances.

- You may want to update your e-mail address in Section 15.3

- You can remove references 8 and 14, they are no longer used.

- You need to run the idnits tool: to reports a few of them.

That's all. BR,

        Miguel
-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:miguel.garcia@neonsite.net
Nokia Research Center      Helsinki, Finland

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From mcvpdyoge@glocalnet.net Fri Dec 22 01:24:38 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gxdpe-0008Ru-Gz
	for simple-archive@lists.ietf.org; Fri, 22 Dec 2006 01:24:38 -0500
Received: from 84-217-4-117.tn.glocalnet.net ([84.217.4.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Gxdpd-0007gY-19
	for simple-archive@lists.ietf.org; Fri, 22 Dec 2006 01:24:38 -0500
From:	"male female" <mcvpdyoge@glocalnet.net>
To: simple-archive@lists.ietf.org
Subject: Call
Date:	Fri, 22 Dec 2006 07:24:38 -0100
MIME-Version: 1.0
Content-Type: multipart/related;
	boundary="----=_NextPart_000_0002_01C7259A.3D0382A0"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: Acclmj0DVT01JbSFRPqJJnsUEq6V3A==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
Message-Id: <4453E1B02EE803F.2F51A405F0@glocalnet.net>
X-Spam-Score: 3.9 (+++)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36

------=_NextPart_000_0002_01C7259A.3D0382A0
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=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2912" name=3D"GENERATOR">
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><STRONG>TTEN Continues Explosive=20
Growth</STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><STRONG><U>TTEN *** TTEN *** =
TTEN<BR>TTEN - Ten=20
&amp; 10, Inc.</U></STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><STRONG>Current Price</STRONG>:=20
08<BR><STRONG>Short Term Target:</STRONG> .50</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><STRONG>TTEN</STRONG> recently =
announced a key=20
development which will enable them to provide Value Added Services to =
the=20
<STRONG>55 million wireless subscribers</STRONG> of ChinaMobile's =
Guangzhou=20
Division through its joint venture with IEC. <STRONG>China Mobile is the =
largest=20
telecommunications provider in China</STRONG>, and the largest among all =
the=20
overseas listed Chinese companies on the Hong Kong and NewYork Stock=20
Exchanges.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><STRONG>TTEN</STRONG> is made up of 4 =
operating=20
subsidiaries:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; Tech=20
10: WIFI and=20
WiMAX<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
Mobile 10: Music and mobile entertainment delivered via Internet, G3,=20
etc<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 Dream=20
Learning Center: Digital Media Learning=20
products<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
Ten &amp; 10 Network: Sales and marketing</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Telecommunications is globally a =
TRILLION dollar=20
industry.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><STRONG><U>TTEN could see explosive =
growth as a=20
newly trading company - 500%-1000% is not =
uncommon.</U></STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D1>Any of the above statements with =
respect to the=20
future predications or goals and events may be seen as only Forward =
Looking and=20
nothing else. All information inside this email pertaining to any sort =
of=20
financial advice needs to be understood as information and not advice. =
None of=20
the information above can be constructed as any sort of financial =
advice. This=20
is a paid advertisement.</FONT></DIV></BODY></HTML>

------=_NextPart_000_0002_01C7259A.3D0382A0--




From simple-bounces@ietf.org Fri Dec 22 08:19:00 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GxkHq-0006Tc-2p; Fri, 22 Dec 2006 08:18:10 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GxkHp-0006TX-52
	for simple@ietf.org; Fri, 22 Dec 2006 08:18:09 -0500
Received: from ug-out-1314.google.com ([66.249.92.173])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxkHn-0005K6-SR
	for simple@ietf.org; Fri, 22 Dec 2006 08:18:09 -0500
Received: by ug-out-1314.google.com with SMTP id 72so2764863ugd
	for <simple@ietf.org>; Fri, 22 Dec 2006 05:18:07 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:mime-version:content-type;
	b=JROjiTeRQDpcnBFSsOLYVEuhfChki6BI+JSHj9W2oeiwtgq3gXfDPSW9osraDnq789UgCLjV3DtYtOmzG8dXKf2dSjezY4UCsVVl1vm8q65e8BBlBTdgL626Soi5M9ndU4Lrx70J+0rxuwVQZypnimf4uG1hQ+kEVgqtcUgvdx8=
Received: by 10.82.120.14 with SMTP id s14mr1816buc.1166793487037;
	Fri, 22 Dec 2006 05:18:07 -0800 (PST)
Received: by 10.82.152.1 with HTTP; Fri, 22 Dec 2006 05:18:07 -0800 (PST)
Message-ID: <2706a4bb0612220518u2b594393hfb9040c84ab49e8@mail.gmail.com>
Date: Fri, 22 Dec 2006 18:48:07 +0530
From: "madan kumar" <mada2k@gmail.com>
To: simple@ietf.org
MIME-Version: 1.0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Subject: [Simple] 500 internal error
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0738866409=="
Errors-To: simple-bounces@ietf.org

--===============0738866409==
Content-Type: multipart/alternative; 
	boundary="----=_Part_59630_27141130.1166793487010"

------=_Part_59630_27141130.1166793487010
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi all,

           Iam testing the IM application . when iam sending a message in IM
message mode which more than 150 characters , invite is generated but when
the ack is sent from the initiator the server is giving 500 internal error .
Can any of u tell me what is the problem in that

iam using siemens server for this purpose

with regards,
Madan

------=_Part_59630_27141130.1166793487010
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div>Hi all,</div>
<div>&nbsp;</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Iam testing the IM application . when iam sending a message in IM message mode which more than 150 characters , invite is generated but when the ack is sent from the initiator the server is giving 500 internal error . Can any of u tell me what is the problem in that
</div>
<div>&nbsp;</div>
<div>iam using siemens server for this purpose</div>
<div>&nbsp;</div>
<div>with regards,</div>
<div>Madan</div>
<div>&nbsp;</div>

------=_Part_59630_27141130.1166793487010--


--===============0738866409==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple

--===============0738866409==--




From otqntsnr@wanadoo.fr Fri Dec 22 10:19:48 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GxmBY-0004EP-Nr
	for simple-archive@lists.ietf.org; Fri, 22 Dec 2006 10:19:48 -0500
Received: from amarseille-256-1-91-70.w90-10.abo.wanadoo.fr ([90.10.98.70] helo=AMarseille-256-1-2-9.w86-219.abo.wanadoo.fr)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GxmBX-0008Ac-5l
	for simple-archive@lists.ietf.org; Fri, 22 Dec 2006 10:19:48 -0500
From:	"Jungle" <otqntsnr@wanadoo.fr>
To: simple-archive@lists.ietf.org
Subject: AOL relaunch
Date:	Fri, 22 Dec 2006 16:19:53 -0100
MIME-Version: 1.0
Content-Type: multipart/related;
	boundary="----=_NextPart_000_0001_01C725E5.0306E330"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: Accl5QMG9IRNgJUNTUSgo6FXp+bJGA==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
Message-Id: <DAF8181F432DA69.F1B3EA01AD@wanadoo.fr>
X-Spam-Score: 4.0 (++++)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36

------=_NextPart_000_0001_01C725E5.0306E330
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=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2912" name=3D"GENERATOR">
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><STRONG>TTEN Continues Explosive=20
Growth</STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><STRONG><U>TTEN *** TTEN *** =
TTEN<BR>TTEN - Ten=20
&amp; 10, Inc.</U></STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><STRONG>Current Price</STRONG>:=20
08<BR><STRONG>Short Term Target:</STRONG> .50</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><STRONG>TTEN</STRONG> recently =
announced a key=20
development which will enable them to provide Value Added Services to =
the=20
<STRONG>55 million wireless subscribers</STRONG> of ChinaMobile's =
Guangzhou=20
Division through its joint venture with IEC. <STRONG>China Mobile is the =
largest=20
telecommunications provider in China</STRONG>, and the largest among all =
the=20
overseas listed Chinese companies on the Hong Kong and NewYork Stock=20
Exchanges.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><STRONG>TTEN</STRONG> is made up of 4 =
operating=20
subsidiaries:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; Tech=20
10: WIFI and=20
WiMAX<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
Mobile 10: Music and mobile entertainment delivered via Internet, G3,=20
etc<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 Dream=20
Learning Center: Digital Media Learning=20
products<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
Ten &amp; 10 Network: Sales and marketing</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Telecommunications is globally a =
TRILLION dollar=20
industry.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><STRONG><U>TTEN could see explosive =
growth as a=20
newly trading company - 500%-1000% is not =
uncommon.</U></STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D1>Any of the above statements with =
respect to the=20
future predications or goals and events may be seen as only Forward =
Looking and=20
nothing else. All information inside this email pertaining to any sort =
of=20
financial advice needs to be understood as information and not advice. =
None of=20
the information above can be constructed as any sort of financial =
advice. This=20
is a paid advertisement.</FONT></DIV></BODY></HTML>

------=_NextPart_000_0001_01C725E5.0306E330--




From simple-bounces@ietf.org Fri Dec 22 15:51:28 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GxrLs-0008Ol-9H; Fri, 22 Dec 2006 15:50:48 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GxrLd-0007x4-0w; Fri, 22 Dec 2006 15:50:33 -0500
Received: from ns4.neustar.com ([156.154.24.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1GxrLc-0003dj-I8; Fri, 22 Dec 2006 15:50:32 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 4F3752ACE5;
	Fri, 22 Dec 2006 20:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1GxrL7-0005Xd-S7; Fri, 22 Dec 2006 15:50:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1GxrL7-0005Xd-S7@stiedprstage1.ietf.org>
Date: Fri, 22 Dec 2006 15:50:01 -0500
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Cc: simple@ietf.org
Subject: [Simple] I-D ACTION:draft-ietf-simple-msrp-relays-09.txt 
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org

--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		: Relay Extensions for the Message Sessions Relay Protocol (MSRP)
	Author(s)	: C. Jennings, et al.
	Filename	: draft-ietf-simple-msrp-relays-09.txt
	Pages		: 37
	Date		: 2006-12-22
	
Two separate models for conveying instant messages have been defined.
   Page-mode messages stand alone and are not part of a SIP (Session
   Initiation Protocol) session, whereas Session-mode messages are set
   up as part of a session using the SIP protocol.  MSRP (Message
   Session Relay Protocol) is a protocol for near real-time, peer-to-
   peer exchanges of binary content without intermediaries, which is
   designed to be signaled using a separate rendezvous protocol such as
   SIP.  This document introduces the notion of message relay
   intermediaries to MSRP and describes the extensions necessary to use
   them.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-msrp-relays-09.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-msrp-relays-09.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: <2006-12-22111046.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-msrp-relays-09.txt

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

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


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple

--NextPart--




From simple-bounces@ietf.org Fri Dec 22 17:13:03 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gxscs-0006tB-Tn; Fri, 22 Dec 2006 17:12:26 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxscr-0006sw-Ue
	for simple@ietf.org; Fri, 22 Dec 2006 17:12:25 -0500
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxscq-0002HQ-MQ
	for simple@ietf.org; Fri, 22 Dec 2006 17:12:25 -0500
Received: from [172.17.2.115] (vicuna-alt.estacado.net [75.53.54.121])
	(authenticated bits=0)
	by nostrum.com (8.13.8/8.13.8) with ESMTP id kBMMCGg2045829
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Fri, 22 Dec 2006 16:12:17 -0600 (CST) (envelope-from ben@nostrum.com)
In-Reply-To: <458954D3.9080209@nokia.com>
References: <B2A87D48-27F5-4ECF-B4EC-CFC814E37A80@nostrum.com>
	<458954D3.9080209@nokia.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <AB816765-D694-4023-A531-499695715E76@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Ben Campbell <ben@nostrum.com>
Subject: Re: [Simple] WGLC: draft-ietf-simple-imdn-02.txt
Date: Fri, 22 Dec 2006 16:12:16 -0600
To: Miguel Garcia <Miguel.An.Garcia@nokia.com>
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
	mechanism)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: simple@ietf.org, Eric Burger <EBurger@cantata.com>
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org

I'm still working on my own comments, but here's a comment on one of  
Miguels

On Dec 20, 2006, at 9:20 AM, Miguel Garcia wrote:

>    o  "forbidden" indicate denial by the IM Recipient for the IM  
> Sender
>       to receive the requested IMDN.
> with
>
>    o  "forbidden" indicate denial by the IM Recipient to receive  
> the requested IMDN.


But the IM recipient does not receive the IMDN, right? Isn't that the  
IM Sender?

I'm also a little confused about the intent of this statement in the  
draft. Who is refusing what to whom? I read it to mean something like  
"Forbidden indicates that the IM Recipient refuses to send the  
requested IMDN". Would anyone ever send that? I mean, if I am going  
to refuse to send an IMDN, I'm not going to tell you that I received  
your message, and refuse to send the IMDN. I'm going to just silently  
ignore the IMDN request.

Is there an information leak here? That is, if I send "refused", you  
know I in fact received the request, right?



_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From dyoletdlt@rr.com Sat Dec 23 01:28:30 2006
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gy0Mw-00048B-0U
	for simple-archive@lists.ietf.org; Sat, 23 Dec 2006 01:28:30 -0500
Received: from cpe-72-134-136-90.dc.res.rr.com ([72.134.136.90])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1Gy0Mu-00023Z-00
	for simple-archive@lists.ietf.org; Sat, 23 Dec 2006 01:28:29 -0500
From:	"father" <dyoletdlt@rr.com>
To: simple-archive@lists.ietf.org
Subject: Billing report changes
Date:	Fri, 22 Dec 2006 22:28:26 +0800
MIME-Version: 1.0
Content-Type: multipart/related;
	boundary="----=_NextPart_000_0002_01C72618.7F66E9B0"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: AccmGH9mOFV/6UTwR4WLPWsn4ukFcg==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
Message-Id: <CF4544FE1901B47.5EBAC67F5E@rr.com>
X-Spam-Score: 4.2 (++++)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9

------=_NextPart_000_0002_01C72618.7F66E9B0
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=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2912" name=3D"GENERATOR">
</HEAD>
<BODY>
<FONT face=3DArial><FONT size=3D2>
<DIV>Michael says: <STRONG>GCME Huge News Release Expected Before Years =
End!=20
</STRONG></DIV>
<DIV><STRONG></STRONG>&nbsp;</DIV>
<DIV><STRONG>Ring In The New Year With Cash!</STRONG></DIV>
<DIV>&nbsp;</DIV>
<DIV>
<DIV><STRONG>GCME</STRONG> is fast becoming a major player in the =
foreign film=20
market. With continuing mergers and joint ventures with the industries =
most=20
influential corporations.</DIV>
<DIV>&nbsp;</DIV></DIV>
<DIV><STRONG>Company:</STRONG> Greater China Media &amp; Entertainment=20
Corp.<BR>Symbol: <STRONG>GCME</STRONG><BR><STRONG>Price:</STRONG>=20
$0.70<BR>Status: <STRONG>BUY ALERT</STRONG><BR><STRONG>5 Day =
Target:</STRONG>=20
$1.45</DIV>
<DIV>&nbsp;</DIV>
<DIV><STRONG>Right now</STRONG> it is at $0.70. We have seen consistent =
price=20
jumps following <STRONG>news releases</STRONG> and we have been told to=20
<STRONG>expect big news</STRONG> before the end of the year. Look at the =
price=20
patterns, see the spikes and the steady climb for yourself. <U>Now is =
the time,=20
grab GCME first thing <STRONG>Tuesday</STRONG>=20
Morning</U>.</DIV></FONT></FONT></BODY></HTML>

------=_NextPart_000_0002_01C72618.7F66E9B0--




From simple-bounces@ietf.org Sun Dec 24 02:29:21 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GyNli-0003xz-18; Sun, 24 Dec 2006 02:27:38 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GyNlg-0003x3-RH
	for simple@ietf.org; Sun, 24 Dec 2006 02:27:36 -0500
Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69]
	helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GyNlg-0001to-83
	for simple@ietf.org; Sun, 24 Dec 2006 02:27:36 -0500
Received: from [10.0.1.3] (adsl-68-94-47-253.dsl.rcsntx.swbell.net
	[68.94.47.253]) (authenticated bits=0)
	by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id kBO7RNvx096545
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Sun, 24 Dec 2006 01:27:28 -0600 (CST)
	(envelope-from ben@estacado.net)
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <06239BA4-97E3-489F-A367-FCD86660F2B4@estacado.net>
Content-Transfer-Encoding: 7bit
From: Ben Campbell <ben@estacado.net>
Date: Sun, 24 Dec 2006 01:27:22 -0600
To: Hisham Khartabil <hisham.khartabil@gmail.com>,
	Eric Burger <EBurger@cantata.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd
Cc: Simple WG <simple@ietf.org>, Robert Sparks <rjsparks@estacado.net>
Subject: [Simple] IMDN-02 WGLC comments
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org

Hi,

Here are my WGLC comments on draft-ietf-simple-imdn-02. Apologies if  
any of these are duplicates or rehash old discussions. Also, I was  
reading linearly, so it may be that some comments are resolved later  
in the draft.


General Comments:

I'm very confused by the intent of the "forbidden" state. I think we  
need some text describing its use in more detail, and perhaps  
describing the motive for its inclusion.


We use the term "address" a lot when we really mean "URI". They are  
not interchangeable terms.

We use the term "header" a lot when we really mean "header field".

Whenever we refer to To and From header fields, we need to be  
_exceedingly_ clear we are talking about CPIM and not SIP. I realize  
that should be obvious from context, but I will bet several beers  
that implementors will screw this up.



Abstract:

Remove MSRP and session mode references.

Section 1 paragraph 3:

Remove MSRP reference.

Paragraph 4:  Remove session-mode reference.

Terminology Section

IM Sender: Didn't we remove the ability to request an IMDN go to  
someone other than the IM Sender? If I recall, allowing a different  
destination was agreed to be an unacceptable security problem. If we  
do allow this, we need to make sure it is discussed in the security  
considerations.

Endpoint and Intermediary: See comment above in "General" section.

IMDN Payload or XML Document: Remove "or XML Document"  from the left  
side of the colon. (I assume we are defining one thing, not two. And  
in any case, leaving it there creates a circular definition.

Transport Protocol Message: I think this one would be better with its  
sense reversed. For example "A SIP or other protocol message that  
contains an IM or IMDN". Also, remove MSRP reference.

Section 4:

Paragraph 1, second sentence is hard to follow. It contains too many  
occurrences of "it" with different antecedents.

Third sentence: Inconsistent use of "or" and commas in the list of  
possible dispositions. Suggest changing to "...user or application  
received, did not receive, read, or otherwise disposed..."


Last Paragraph:

The idea of an IMDN going to someone other than the IM sender needs  
more discussion, perhaps in security considerations. At least, we  
cannot just toss the idea out and then assume it doesn't happen in  
the rest of the document. I _think_ that if the only way this can  
happen is when the From: URI resolves to more than one destination,  
it is ok in the sense that we assume all possible resolutions for the  
AoR represent the same "entity", or at least entities sharing the AoR  
identity.

Section 5.1: Paragraph 1: I think we meant to say "delivered to the  
IM Recipient's User Agent",  or "endpoint", don't we? Otherwise it is  
pretty much the same as for "read"


Section 5.2: I don't understand what "forbidden" means in this context.

Section 5.3: Still unclear on how "forbidden" is intended to be used.

last paragraph: I'm not sure that normative language is appropriate  
here. The point is to say that this mechanism is not sufficiently  
long for non-repudiation, not what you do with the knowledge you get  
from it. As currently stated, it seems to put a normative requirement  
on what _users_ do, which is rather futile. (The security  
considerations gets this right, I think.)

Section 6.1 Last Sentence:  I read this to try to say that you have  
to use the string "imdn" when you declare a CPIM namespace prefix. I  
don't think RFC 3862 intended to say that all uses of a CPIM  
namespace must use the same prefix--merely that you must use the  
string from the NS header in a _given_ CPIM message to prefix all  
header fields from that namespace. It is perfectly valid for me to  
declare "NS: foo <urn:ietf:params:cpim-headers:imdn>", then use the  
"foo" prefix throughout my CPIM message.

6.3: Third to last sentence: I think we meant to say "...mandatory  
when sending an IM that requests an IMDN". Also, should we capitalize  
"MANDATORY"?. Also, should second to last sentence use normative  
language?

Section 6.5:  s/address of that intermediary/URI representing that  
intermediary

Section 6.6: Should this section mention what intermediaries do with  
IMDN-Route?

Section 7.1.1.3 Paragraphs 4 and 5: Last line of each of these  
paragraphs belong together in a separate paragraph, I think, since  
they both talk about multiple request values, and seem like non- 
sequiturs in their current host paragraphs.

Section 7.1.2:  The final sentence is confusing. It seems to say use  
"(recipient-uri or original-recipient-uri) if multiple recipients".  
Don't we mean "recipient-uri or (original-recipient-uri if multiple  
recipients)"? If not, we need to clarify when to match on one verses  
the other.

Section 7.1.3:

I mentioned this on the previous draft, but I missed any discussion  
or change due to that comment, so I will make it again. I don't see  
the value of allowing the sender to request aggregation, considering  
that the list server has no obligation to pay any attention. Since  
aggregation policy has a major affect on URI list server performance  
and scalability, I doubt _anyone_ will configure such a server to pay  
attention to sender preferences for aggregation. IMHO, the ability  
for the sender to request whether aggregation will be used or not  
adds no value to justify the complexity.

Section 7.1.4: This entire section is closely related to 7.1.2, and  
should either be included there, or immediately afterwards.

7.2.1: Second paragraph: put quotes around "processing".

Paragraph 4: What is the motivation for requiring the Message-ID CPIM  
header field in an IMDN, since you can't send an IMDN to an IMDN?

Paragraph 5: s/address/URI/

7.2.1.1 first paragraph: Isn't the content-disposition: notification  
requirement true for all IMDN types? If so, it should be moved to 7.2.1

7.2.1.2: Last paragraph: Can we provide an example of a situation  
where this might occur?

Section 8 first paragraph: I think we need some more text here. We  
need to define what we mean by "gateways".

Second paragraph: Is this specification granting permission to  
intermediaries to change the To header? Or does that come from the  
URI-list work? If the second, we need a reference. If the first, we  
need to discuss the implications in the security considerations.  I  
raise this as a red flag since such a change is likely to break  
digital signatures, which were the primary motivators for CPIM in the  
first place.

second to last paragraph: s/pops that header/pops that value/

8.1: Please quote all occurrences of "processing". Otherwise, it is  
easy to confuse the idea of a "processing" notification with the idea  
of processing an notification.

8.2 Second Paragraph:The "MUST" level requirement is directly  
contradicted by later language giving the intermediary quite a bit of  
latitude about when and if it aggregates. (IMHO, the later language  
is correct, and the MUST is not.)

Third Paragraph: Should the last word of first sentence be IM or IMDN?

Second to last paragraph: It would be nice to see an example  
aggregated IMDN message.

Section 10: Do we reference the constructions for URI and "token"  
somewhere? Also, shouldn't we use a more general construction for  
[ Formal-name ] "<" URI ">"?  (such as addrspec?)

Section 11.1.5 : If there was any normative language requiring the IM  
recipient to do something with <subject>, I missed it.

11.1.8: ditto.

12.1.1: Can we document the motivation for requiring an IMDN to be in  
a CPIM envelope? I hear lots of people saying it should, but I have  
not yet heard a convincing reason for it beyond a general belief that  
all IMs should use CPIM. (Which we don't actually _require_).

12.1.3.1 second and third paragraphs : s/GW/gateway/ for all  
occurrences.

4th paragraph: s/error response/non-2XX SIP final response

12.2:

General for section: A lot of this is not about SIP, and probably  
belongs in the earlier "Intermediary behavior" section.

paragraphs 3 and 4 seem contradictory.

Paragraph 5: If the intermediary receives a negative-delivery report,  
shouldn't it just forward the one it received instead of generating a  
new one? (modulo aggregation)

Paragraph 6: Why "MAY"? are we allowing an intermediary to consume  
"processing" notices from downstream without forwarding them back  
upstream?

Section 13:

I don't think ever meant to say IMDN was not applicable to MSRP.  
Rather, we meant to say that we had not explored how it may be  
applicable, and it is therefore out of scope. The final paragraph  
indicates this, but the first paragraph is somewhat provocative.

I also do not think this spec should be making judgments about  
whether the general concept of "read" status is applicable in MSRP.  
We just should leave MSRP out of scope without making judgments one  
way or another.


































_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From oboclqki@blenterprises.net Sun Dec 24 15:42:02 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GyaAU-0003VH-Bu
	for simple-archive@lists.ietf.org; Sun, 24 Dec 2006 15:42:02 -0500
Received: from [88.226.137.215] (helo=[88.226.137.215])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GyaAR-0006bi-MH
	for simple-archive@lists.ietf.org; Sun, 24 Dec 2006 15:42:02 -0500
From:	"Dems." <oboclqki@blenterprises.net>
To: simple-archive@lists.ietf.org
Subject: Angela's review
Date:	Sun, 24 Dec 2006 22:41:56 -0200
MIME-Version: 1.0
Content-Type: multipart/related;
	boundary="----=_NextPart_000_0003_01C727AC.B71C1E80"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: AccnrLcc0AjEDnTCTpqqYJVpDHUk8g==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
Message-Id: <15A205756AF09A2.E23B36771F@blenterprises.net>
X-Spam-Score: 3.0 (+++)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9

------=_NextPart_000_0003_01C727AC.B71C1E80
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=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2912" name=3D"GENERATOR">
</HEAD>
<BODY>
<FONT face=3DArial><FONT size=3D2>
<DIV>Michael says: <STRONG>GCME Huge News Release Expected Before Years =
End!=20
</STRONG></DIV>
<DIV><STRONG></STRONG>&nbsp;</DIV>
<DIV><STRONG>Ring In The New Year With Cash!</STRONG></DIV>
<DIV>&nbsp;</DIV>
<DIV>
<DIV><STRONG>GCME</STRONG> is fast becoming a major player in the =
foreign film=20
market. With continuing mergers and joint ventures with the industries =
most=20
influential corporations.</DIV>
<DIV>&nbsp;</DIV></DIV>
<DIV><STRONG>Company:</STRONG> Greater China Media &amp; Entertainment=20
Corp.<BR>Symbol: <STRONG>GCME</STRONG><BR><STRONG>Price:</STRONG>=20
$0.70<BR>Status: <STRONG>BUY ALERT</STRONG><BR><STRONG>5 Day =
Target:</STRONG>=20
$1.45</DIV>
<DIV>&nbsp;</DIV>
<DIV><STRONG>Right now</STRONG> it is at $0.70. We have seen consistent =
price=20
jumps following <STRONG>news releases</STRONG> and we have been told to=20
<STRONG>expect big news</STRONG> before the end of the year. Look at the =
price=20
patterns, see the spikes and the steady climb for yourself. <U>Now is =
the time,=20
grab GCME first thing <STRONG>Tuesday</STRONG>=20
Morning</U>.</DIV></FONT></FONT></BODY></HTML>

------=_NextPart_000_0003_01C727AC.B71C1E80--




From simple-bounces@ietf.org Mon Dec 25 02:56:57 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gykfs-0007JR-0S; Mon, 25 Dec 2006 02:55:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gykfq-0007JM-OO
	for simple@ietf.org; Mon, 25 Dec 2006 02:55:06 -0500
Received: from smtp3.infineon.com ([203.126.106.229])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gykfp-0006q3-8p
	for simple@ietf.org; Mon, 25 Dec 2006 02:55:06 -0500
Received: from unknown (HELO sinse301.ap.infineon.com) ([172.20.70.22])
	by smtp3.infineon.com with ESMTP; 25 Dec 2006 15:55:03 +0800
X-SBRS: None
Received: from sinse303.ap.infineon.com ([172.20.70.24]) by
	sinse301.ap.infineon.com over TLS secured channel with
	Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Dec 2006 15:55:03 +0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 25 Dec 2006 15:55:02 +0800
Message-ID: <CA51DF75AEDD5F439DC58E2383F6CE8C9DB2D5@sinse303.ap.infineon.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Response for MSRP abort message request
Thread-Index: Accn+fvT6zlNBuk+TMGi24AlsSMESw==
From: <Amitkumar.Goel@infineon.com>
To: <simple@ietf.org>
X-OriginalArrivalTime: 25 Dec 2006 07:55:03.0190 (UTC)
	FILETIME=[FC056360:01C727F9]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Cc: fluffy@cisco.com
Subject: [Simple] Response for MSRP abort message request
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org

Hi All,

I have doubt-- Which response code is to be sent if the receiver gets
the abort message request (End line flag is #)..There are two scenario..

1. Sender sends the abort message request (containing end line flag #)

Consider the example

   MSRP a786hjs2 SEND
   To-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp
   From-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp
   Message-ID: 87652491
   Byte-Range: 1-8/26
   Content-Type: text/plain

   ABCDEFGH
   -------a786hjs2+

   MSRP a786hjs2 200 OK
   To-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp
   From-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp
   Byte-Range: 1-8/26
   -------a786hjs2+

   MSRP a786hjs2 SEND
   To-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp
   From-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp
   Message-ID: 87652491
   Byte-Range: 9-20/26
   Content-Type: text/plain

   IJKLMNOPQRST
   -------a786hjs2#

   MSRP a786hjs2 ---
   To-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp
   From-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp
   Byte-Range: 9-20/26
   -------a786hjs2#


What will be the response code for the second SEND request? According to
me it should be 200 OK in case there is no error at the receiver side
and 4xx if there is an error, at the receiver side for current chunk.

2)But I am little confused for the second case. sender sends abort
request after receiving 4XX response


   MSRP a786hjs2 SEND
   To-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp
   From-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp
   Message-ID: 87652491
   Byte-Range: 1-8/26
   Content-Type: text/plain

   ABCDEFGH
   -------a786hjs2+

   MSRP a786hjs2 4XX
   To-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp
   From-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp
   Byte-Range: 1-8/26
   -------a786hjs2+

   MSRP a786hjs2 SEND
   To-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp
   From-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp
   Message-ID: 87652491
   Byte-Range: 9-20/26
   Content-Type: text/plain

   IJKLMNOPQRST
   -------a786hjs2#

   MSRP a786hjs2 ---
   To-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp
   From-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp
   Byte-Range: 9-20/26
   -------a786hjs2#


Here receiver sent a 4XX response and sender sends the messgae abort
request. What should be the response code which is to be sent by the
receiver for current chunk?=20
Is it 4XX response (the same response code which was sent in response to
the previous chunk)
     OR=20
200 OK (if there is no error in the current chunk parsing) or 4XX
response (if there is an error in parsing of the current chunk).

Thanks in advance !

Regards,
Amit=20

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Fri Dec 29 15:51:17 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H0Og5-0004SI-4H; Fri, 29 Dec 2006 15:50:09 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H0Ofz-0004Qf-Kg; Fri, 29 Dec 2006 15:50:03 -0500
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1H0Ofy-0005kG-BX; Fri, 29 Dec 2006 15:50:03 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 5101E328DC;
	Fri, 29 Dec 2006 20:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1H0Ofy-0000el-7N; Fri, 29 Dec 2006 15:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1H0Ofy-0000el-7N@stiedprstage1.ietf.org>
Date: Fri, 29 Dec 2006 15:50:02 -0500
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Cc: simple@ietf.org
Subject: [Simple] I-D ACTION:draft-ietf-simple-msrp-relays-10.txt 
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org

--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		: Relay Extensions for the Message Sessions Relay Protocol (MSRP)
	Author(s)	: C. Jennings, et al.
	Filename	: draft-ietf-simple-msrp-relays-10.txt
	Pages		: 37
	Date		: 2006-12-29
	
Two separate models for conveying instant messages have been defined.
   Page-mode messages stand alone and are not part of a SIP (Session
   Initiation Protocol) session, whereas Session-mode messages are set
   up as part of a session using the SIP protocol.  MSRP (Message
   Session Relay Protocol) is a protocol for near real-time, peer-to-
   peer exchanges of binary content without intermediaries, which is
   designed to be signaled using a separate rendezvous protocol such as
   SIP.  This document introduces the notion of message relay
   intermediaries to MSRP and describes the extensions necessary to use
   them.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-msrp-relays-10.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-msrp-relays-10.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: <2006-12-29102603.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-msrp-relays-10.txt

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

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


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple

--NextPart--