From simple-bounces@ietf.org Thu Dec 01 01:02:54 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EhhWw-0005Cy-Ha; Thu, 01 Dec 2005 01:02:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EhhWu-0005CV-6E
	for simple@megatron.ietf.org; Thu, 01 Dec 2005 01:02:52 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23412
	for <simple@ietf.org>; Thu, 1 Dec 2005 01:02:05 -0500 (EST)
Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhhrF-0008BY-De
	for simple@ietf.org; Thu, 01 Dec 2005 01:23:59 -0500
Received: from huawei.com (szxga01-in [172.24.2.3])
	by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0IQT002EO20S8Z@szxga01-in.huawei.com> for
	simple@ietf.org; Thu, 01 Dec 2005 14:00:29 +0800 (CST)
Received: from szxml02-in ([172.24.1.6])
	by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0IQT005OD20S9R@szxga01-in.huawei.com> for
	simple@ietf.org; Thu, 01 Dec 2005 14:00:28 +0800 (CST)
Received: from m24697A ([10.164.10.31])
	by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0IQT00BUR23SJY@szxml02-in.huawei.com> for
	simple@ietf.org; Thu, 01 Dec 2005 14:02:16 +0800 (CST)
Date: Thu, 01 Dec 2005 13:52:13 +0800
From: Lunjian Mu <mulj@huawei.com>
To: simple@ietf.org
Message-id: <015501c5f63b$610f8e80$1f0aa40a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-Priority: 3
X-MSMail-priority: Normal
X-Spam-Score: 0.2 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Subject: [Simple] the status of chat document
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="===============1623126495=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1623126495==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_K8jqKnDzmY2i3CioYGhHUw)"

This is a multi-part message in MIME format.

--Boundary_(ID_K8jqKnDzmY2i3CioYGhHUw)
Content-type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7BIT

Hi All,
    Who can tell me the status of documents:draft-niemi-simple-chat-03.txt. A new version will be published or not ?

Thanks and Best regards,
 
Lunjian Mu

--Boundary_(ID_K8jqKnDzmY2i3CioYGhHUw)
Content-type: text/html; charset=gb2312
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=gb2312">
<META content="MSHTML 6.00.2900.2769" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face="Times New Roman">Hi All,</FONT></DIV>
<DIV><FONT face="Times New Roman">&nbsp;&nbsp;&nbsp; Who can tell me the status 
of documents:draft-niemi-simple-chat-03.txt. A new version will be published or 
not ?</FONT></DIV>
<DIV><FONT face="Times New Roman"></FONT>&nbsp;</DIV>
<DIV><FONT face="Times New Roman">Thanks and Best regards,<BR>&nbsp;<BR>Lunjian 
Mu<BR></FONT></DIV></BODY></HTML>

--Boundary_(ID_K8jqKnDzmY2i3CioYGhHUw)--


--===============1623126495==
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

--===============1623126495==--




From simple-bounces@ietf.org Thu Dec 01 03:09:13 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EhjVB-0008QT-Ry; Thu, 01 Dec 2005 03:09:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EhjV9-0008QN-Dl
	for simple@megatron.ietf.org; Thu, 01 Dec 2005 03:09:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04585
	for <simple@ietf.org>; Thu, 1 Dec 2005 03:08:24 -0500 (EST)
Received: from mgw-ext04.nokia.com ([131.228.20.96])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhjpZ-0003eZ-Uf
	for simple@ietf.org; Thu, 01 Dec 2005 03:30:19 -0500
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145])
	by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	jB18402t009571 for <simple@ietf.org>; Thu, 1 Dec 2005 10:09:04 +0200
Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by
	esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 1 Dec 2005 09:56:11 +0200
Received: from mgw-int2.ntc.nokia.com ([172.21.143.97]) by
	esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Thu, 1 Dec 2005 09:56:10 +0200
Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	jB17uAP26999
	for <simple@ietf.org>; Thu, 1 Dec 2005 09:56:10 +0200 (EET)
Received: from [172.21.34.145] (hed034-145.research.nokia.com [172.21.34.145])
	by kusti.research.nokia.com (Postfix) with ESMTP id EF9A193B85
	for <simple@ietf.org>; Thu,  1 Dec 2005 09:56:09 +0200 (EET)
Message-ID: <438EAC99.5090605@nokia.com>
Date: Thu, 01 Dec 2005 09:56:09 +0200
From: Jari Urpalainen <jari.urpalainen@nokia.com>
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: simple@ietf.org
Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-xml-patch-ops-00.txt
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 01 Dec 2005 07:56:10.0772 (UTC)
	FILETIME=[B19CD540:01C5F64C]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: 7bit
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi all!

Changes  since the individual version:
-fixed a bug when replacing a comment or a PI node; a "< " character can 
be present within them, within text nodes it must be escaped
-clarified attribute value and text node replace behavior when the 
replacement text is empty
-added some conventions used in this memo which don't exist e.g. in the 
XPath 1.0 spec
-clarified that the root node of a document as well as the full XML 
prolog cannot be patched with XPath semantics
-absolute location paths in XPath selector values are allowed but not 
encouraged
-added a patch element type for text content patching. This is still 
somewhat controversial mostly because of ipr issues. However, it was 
just added in order to show how to use it if some application really 
wants/needs it. AFAIK vcdiff seems to be the most sane way to handle 
these, but does anybody know whether the ipr limits its usage only to 
e.g. rfc3229 ?
-did not include multi-select "msel" selector which could be used e.g. 
to remove multiple attributes or elements with one patch operation 
request. The reference implementation at 
<http://xmlpatch.sourceforge.net/> includes it, however. The possible 
nested element case has to be handled then, but it is mostly not 
included in the spec because I can't see enough motivation for it. If 
there's really need for it it can be done in an extension later. The 
same can be said e.g. about a move operation.

A couple of other nits here and there but I'd really appreciate some 
feedback/comments.
br,
Jari
 

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



From simple-bounces@ietf.org Thu Dec 01 09:13:25 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EhpBd-0006v1-Ej; Thu, 01 Dec 2005 09:13:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EhpBc-0006ug-M1
	for simple@megatron.ietf.org; Thu, 01 Dec 2005 09:13:24 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24933
	for <simple@ietf.org>; Thu, 1 Dec 2005 09:12:37 -0500 (EST)
Received: from smtp4.clb.oleane.net ([213.56.31.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhpW6-0006y7-Iv
	for simple@ietf.org; Thu, 01 Dec 2005 09:34:35 -0500
Received: from Pavillonquatre ([194.3.133.88]) (authenticated)
	by smtp4.clb.oleane.net with ESMTP id jB1ECxKQ026424
	for <simple@ietf.org>; Thu, 1 Dec 2005 15:12:59 +0100
Message-Id: <200512011412.jB1ECxKQ026424@smtp4.clb.oleane.net>
From: "Chantal Ladouce" <chantal.ladouce@upperside.fr>
To: <simple@ietf.org>
Date: Thu, 1 Dec 2005 15:12:25 +0100
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcX2gUEkChhPKa49RHeKanl9/ZWT/g==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 093efd19b5f651b2707595638f6c4003
Subject: [Simple] Wireless/WiFi Convergence Conference - Call for Papers 
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="===============1597133602=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1597133602==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_011D_01C5F689.A3865750"

This is a multi-part message in MIME format.

------=_NextPart_000_011D_01C5F689.A3865750
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The Wireless/WiFi Convergence Conference will be held in Paris on May 16 to
May 19, 2006

 

http://www.upperside.fr/wirelessconvergence2006/wwconvergence2006cfp.htm

 

It is still time to submit proposals. Organizers are looking for UMA papers.

 


------=_NextPart_000_011D_01C5F689.A3865750
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place" downloadurl=3D"http://www.5iantlavalamp.com/"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City" =
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	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
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DFR link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>The <strong><b><font face=3DArial><span
style=3D'font-family:Arial'>Wireless/WiFi Convergence =
Conference</span></font></b></strong>
will be held in <st1:City w:st=3D"on"><st1:place w:st=3D"on"><span =
class=3Dstyle24>Paris</span></st1:place></st1:City><span
class=3Dstyle24> on May 16 to May 19, 2006</span></span></font><font =
size=3D2><span
lang=3DEN-GB style=3D'font-size:10.0pt'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:10.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'><a
href=3D"http://www.upperside.fr/wirelessconvergence2006/wwconvergence2006=
cfp.htm">http://www.upperside.fr/wirelessconvergence2006/wwconvergence200=
6cfp.htm</a><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>It is still time to submit proposals. =
Organizers are
looking for UMA papers.</span></font><font size=3D2><span lang=3DEN-GB
style=3D'font-size:10.0pt'><o:p></o:p></span></font></p>

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

</div>

</body>

</html>

------=_NextPart_000_011D_01C5F689.A3865750--



--===============1597133602==
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

--===============1597133602==--





From simple-bounces@ietf.org Fri Dec 02 06:28:42 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ei95m-0006pb-Dv; Fri, 02 Dec 2005 06:28:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei95k-0006kD-Bj
	for simple@megatron.ietf.org; Fri, 02 Dec 2005 06:28:40 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09967
	for <simple@ietf.org>; Fri, 2 Dec 2005 06:27:52 -0500 (EST)
Received: from hq-smtp-01.telio.no ([82.196.203.118])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei9QO-00034T-Jd
	for simple@ietf.org; Fri, 02 Dec 2005 06:50:01 -0500
Received: from office-srv-04.HQ.TELIO.NO (unknown [192.168.1.221])
	by hq-smtp-01.telio.no (Postfix) with ESMTP id AAEB4194476
	for <simple@ietf.org>; Fri,  2 Dec 2005 12:28:20 +0100 (CET)
Received: from [192.168.1.67] ([192.168.1.67]) by office-srv-04.HQ.TELIO.NO
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 2 Dec 2005 12:27:49 +0100
Mime-Version: 1.0 (Apple Message framework v623)
Content-Transfer-Encoding: 7bit
Message-Id: <5c8b9b01e3f39cd47e410403752cc8fd@telio.no>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: Simple WG <simple@ietf.org>
From: Hisham Khartabil <hisham.khartabil@telio.no>
Date: Fri, 2 Dec 2005 12:27:56 +0100
X-Mailer: Apple Mail (2.623)
X-OriginalArrivalTime: 02 Dec 2005 11:27:49.0062 (UTC)
	FILETIME=[6CCBDE60:01C5F733]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Content-Transfer-Encoding: 7bit
Subject: [Simple] WGLC: User Agent Capability Extension to PIDF (prescaps)
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

The WG chairs would like to start a Working Group Last Call on the  
following drafts:

http://www.ietf.org/internet-drafts/draft-ietf-simple-prescaps-ext 
-05.txt

This WGLC will end on December 16th, 2005.

Please send your comments to this mailing list and to the authors.

Thanks,
Hisham


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



From simple-bounces@ietf.org Mon Dec 05 13:31:14 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjL7K-00021K-Ry; Mon, 05 Dec 2005 13:31:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EjL7J-000214-5P
	for simple@megatron.ietf.org; Mon, 05 Dec 2005 13:31:13 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24213
	for <simple@ietf.org>; Mon, 5 Dec 2005 13:30:21 -0500 (EST)
Received: from mxgate1.brooktrout.com ([204.176.74.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjLSb-0003yL-3D
	for simple@ietf.org; Mon, 05 Dec 2005 13:53:16 -0500
X-IronPort-AV: i="3.99,217,1131339600"; 
	d="scan'208"; a="23679241:sNHT27708192"
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, 5 Dec 2005 13:31:00 -0500
Message-ID: <330A23D8336C0346B5C1A5BB1966664701B8D4E8@ATLANTIS.Brooktrout.com>
Thread-Topic: IMDN Issue #1: Security of IMDN
Thread-Index: AcX5ygqNRz99IFFbS4ezLwACE5TCZg==
From: "Burger, Eric" <eburger@brooktrout.com>
To: <simple@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4
Content-Transfer-Encoding: quoted-printable
Subject: [Simple] IMDN Issue #1: Security of IMDN
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Proposal is that if the body of the message was encrypted or signed, the
IMDN MUST be encrypted or signed, otherwise it MAY be plain text.

Any dissent?

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



From simple-bounces@ietf.org Mon Dec 05 13:32:07 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjL8B-00023C-O2; Mon, 05 Dec 2005 13:32:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EjL8A-000236-5w
	for simple@megatron.ietf.org; Mon, 05 Dec 2005 13:32:06 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24258
	for <simple@ietf.org>; Mon, 5 Dec 2005 13:31:15 -0500 (EST)
Received: from mxgate1.brooktrout.com ([204.176.74.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjLTV-0003zs-R1
	for simple@ietf.org; Mon, 05 Dec 2005 13:54:10 -0500
X-IronPort-AV: i="3.99,217,1131339600"; 
	d="scan'208"; a="23679274:sNHT39027960"
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, 5 Dec 2005 13:32:06 -0500
Message-ID: <330A23D8336C0346B5C1A5BB1966664701B8D4EC@ATLANTIS.Brooktrout.com>
Thread-Topic: IMDN Issue #2: Date Stamp in IMDN
Thread-Index: AcX5yjGbTvHpTktkRoSUg2udUTZnug==
From: "Burger, Eric" <eburger@brooktrout.com>
To: <simple@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31
Content-Transfer-Encoding: quoted-printable
Subject: [Simple] IMDN Issue #2: Date Stamp in IMDN
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Add a date element to the IMDN.  Does anyone care?  I don't, so it goes
in unless someone besides me squeaks.

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



From simple-bounces@ietf.org Mon Dec 05 13:34:01 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjLA1-0002BY-RQ; Mon, 05 Dec 2005 13:34:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EjLA0-0002BQ-S1
	for simple@megatron.ietf.org; Mon, 05 Dec 2005 13:34:00 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24477
	for <simple@ietf.org>; Mon, 5 Dec 2005 13:33:10 -0500 (EST)
Received: from mxgate1.brooktrout.com ([204.176.74.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjLVL-00043x-AC
	for simple@ietf.org; Mon, 05 Dec 2005 13:56:04 -0500
X-IronPort-AV: i="3.99,217,1131339600"; 
	d="scan'208"; a="23679348:sNHT34702308"
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, 5 Dec 2005 13:33:59 -0500
Message-ID: <330A23D8336C0346B5C1A5BB1966664701B8D4F5@ATLANTIS.Brooktrout.com>
Thread-Topic: IMDN Issue #4: Disposition-Notification-To
Thread-Index: AcX5ynUV4F4y0FV2TOOptgnvfffYhg==
From: "Burger, Eric" <eburger@brooktrout.com>
To: <simple@ietf.org>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Content-Transfer-Encoding: quoted-printable
Subject: [Simple] IMDN Issue #4: Disposition-Notification-To
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

IETF 64 SIMPLE meeting consensus in room was to take out 3rd-party or
3rd-party transport notifications *for now*.

Proposal is to simply have the presence of a Disposition-Notification
header, leaving the possibility for adding a URI in the future (and
restoring the mechanism from the current draft).

Anyone need this functionality today?

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



From simple-bounces@ietf.org Mon Dec 05 14:05:18 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjLeI-0002dn-Un; Mon, 05 Dec 2005 14:05:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EjLeG-0002cl-UL
	for simple@megatron.ietf.org; Mon, 05 Dec 2005 14:05:16 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27864
	for <simple@ietf.org>; Mon, 5 Dec 2005 14:04:26 -0500 (EST)
Received: from mxgate1.brooktrout.com ([204.176.74.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjLzb-0005A5-Mv
	for simple@ietf.org; Mon, 05 Dec 2005 14:27:20 -0500
X-IronPort-AV: i="3.99,217,1131339600"; 
	d="scan'208"; a="23680761:sNHT28287576"
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, 5 Dec 2005 14:05:11 -0500
Message-ID: <330A23D8336C0346B5C1A5BB1966664701B8D58E@ATLANTIS.Brooktrout.com>
Thread-Topic: IMDN Issue #5: "deleted" state
Thread-Index: AcX5ztDsaZxE20unQbm1+hx67CEAPQ==
From: "Burger, Eric" <eburger@brooktrout.com>
To: <simple@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Content-Transfer-Encoding: quoted-printable
Subject: [Simple] IMDN Issue #5: "deleted" state
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

I had proposed dropping the deleted state, as it (1) did not make sense
to me in an IM context and (2) has a ton of privacy implications.

HOWEVER, it was mentioned that someone thought someone needed the
"deleted" disposition.  They thought they heard that someone in Paris
(IETF 63) said they needed it.

Speak now, or "deleted" will be deleted from the next draft.

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



From simple-bounces@ietf.org Tue Dec 06 00:17:10 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjVCQ-0007Tv-52; Tue, 06 Dec 2005 00:17:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EjVCP-0007TR-FK
	for simple@megatron.ietf.org; Tue, 06 Dec 2005 00:17:09 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05495
	for <simple@ietf.org>; Tue, 6 Dec 2005 00:16:19 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjVXq-00020V-Ia
	for simple@ietf.org; Tue, 06 Dec 2005 00:39:18 -0500
Received: from sj-core-4.cisco.com ([171.68.223.138])
	by sj-iport-4.cisco.com with ESMTP; 05 Dec 2005 21:17:01 -0800
Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com
	[171.70.93.57])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jB65Gwpf023869
	for <simple@ietf.org>; Mon, 5 Dec 2005 21:16:58 -0800 (PST)
Received: from 10.21.83.244 ([10.21.83.244]) by vtg-um-e2k4.sj21ad.cisco.com
	([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; 
	Tue,  6 Dec 2005 05:16:58 +0000
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Mon, 05 Dec 2005 21:17:04 -0800
From: Cullen Jennings <fluffy@cisco.com>
To: "simple@ietf.org" <simple@ietf.org>
Message-ID: <BFBA5ED0.63B94%fluffy@cisco.com>
Thread-Topic: draft-ietf-simple-xml-patch-ops-00
Thread-Index: AcX6JEtbiip/kWYXEdqgngARJEEJ/A==
In-Reply-To: <E1EhYtu-0006sU-5i@newodin.ietf.org>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
Content-Transfer-Encoding: 7bit
Subject: [Simple] draft-ietf-simple-xml-patch-ops-00
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org


I was somewhat surprised to see this as a WG item. When do we use this and
when do we use xcap?

I was also sort of wondering about how to deal with the issues of elements
that used name spaces inside of the data portion of attributes. For
example... 

if I have namesace xmlns:z="urn:foo"

then I have sel="z:doc"

Would I ever have the case where the some xml parser library changed my
namespace to xmlns:z="urn:foo" (it would do this perhaps because x was
already in use)? If this happened, it seems like the "z:doc" would not get
changed to "x:doc" and things would break badly.

Thoughts? Is this a problem or is it all avoided some how?


On 11/30/05 12:50 PM, "Internet-Drafts@ietf.org" <Internet-Drafts@ietf.org>
wrote:

> 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  : An Extensible Markup Language (XML) Patch
>                           Operations Framework Utilizing XML Path
>                           Language (XPath) Selectors
> Author(s) : J. Urpalainen
> Filename : draft-ietf-simple-xml-patch-ops-00.txt
> Pages  : 21
> Date  : 2005-11-30
> 
>    Extensible Markup Language (XML) documents are widely used as
>    containers for the exchange and storage of arbitrary data in today's
>    systems.  Updates to this data require transporting of the entire XML
>    document between hosts, unless there's a mechanism that allows
>    exchanging only the updates of XML documents.  This document
>    describes an XML patch framework utilizing XML Path language (XPath)
>    selectors.  With the aid of these selector values and updated data
>    content a set of patches can then be applied to an existing initial
>    XML document.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-simple-xml-patch-ops-00.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-xml-patch-ops-00.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-xml-patch-ops-00.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.
> Content-Type: text/plain
> Content-ID: <2005-11-30114220.I-D@ietf.org>
> 
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www1.ietf.org/mailman/listinfo/i-d-announce

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



From simple-bounces@ietf.org Tue Dec 06 16:30:24 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjkOG-0007W3-J0; Tue, 06 Dec 2005 16:30:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EjkOE-0007VE-Pl
	for simple@megatron.ietf.org; Tue, 06 Dec 2005 16:30:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24683
	for <simple@ietf.org>; Tue, 6 Dec 2005 16:29:30 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejkjn-0002FX-LK
	for simple@ietf.org; Tue, 06 Dec 2005 16:52:40 -0500
Received: from [10.240.21.119] (m815f36d0.tmodns.net [208.54.95.129])
	(authenticated bits=0)
	by nostrum.com (8.12.11/8.12.11) with ESMTP id jB6LTtSs060829
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Tue, 6 Dec 2005 15:29:57 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
In-Reply-To: <BFBA5ED0.63B94%fluffy@cisco.com>
References: <BFBA5ED0.63B94%fluffy@cisco.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <E450FB36-CC23-4CAD-B327-A41ECF131D90@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [Simple] draft-ietf-simple-xml-patch-ops-00
Date: Tue, 6 Dec 2005 15:27:44 -0600
To: Cullen Jennings <fluffy@cisco.com>
X-Mailer: Apple Mail (2.746.2)
Received-SPF: pass (nostrum.com: 208.54.95.129 is authenticated by a trusted
	mechanism)
X-Spam-Score: 2.9 (++)
X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a
Content-Transfer-Encoding: 7bit
Cc: "simple@ietf.org" <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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org


On Dec 5, 2005, at 11:17 PM, Cullen Jennings wrote:

>
> I was somewhat surprised to see this as a WG item. When do we use  
> this and
> when do we use xcap?

This draft is intended to be what the group agreed to adopt as the  
solution for
xcap-diff and the partial-* work based on the output of the patch bof  
and the
SIMPLE WG discussion in Vancouver. It went beyond its mandate  
including patch
operations for general text elements - this is something the group  
explicitly decided
to not try to tackle by my memory.

I can see your confusion given that the draft doesn't reference  
partial at all.

Jari - could you provide a revision quicky that includes a section  
pointing to how this
would be used with xcap and with partial?

All - comment on the text modifying proposal quickly. Unless there is  
a very
strong "Oh yeah - we all want to do this this way", and soon,  I will  
ask Jari to remove
this mechanism from this draft and return to exactly the scope we  
agreed to
in Vancouver.

RjS

>
> I was also sort of wondering about how to deal with the issues of  
> elements
> that used name spaces inside of the data portion of attributes. For
> example...
>
> if I have namesace xmlns:z="urn:foo"
>
> then I have sel="z:doc"
>
> Would I ever have the case where the some xml parser library  
> changed my
> namespace to xmlns:z="urn:foo" (it would do this perhaps because x was
> already in use)? If this happened, it seems like the "z:doc" would  
> not get
> changed to "x:doc" and things would break badly.
>
> Thoughts? Is this a problem or is it all avoided some how?
>
>
> On 11/30/05 12:50 PM, "Internet-Drafts@ietf.org" <Internet- 
> Drafts@ietf.org>
> wrote:
>
>> 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  : An Extensible Markup Language (XML) Patch
>>                           Operations Framework Utilizing XML Path
>>                           Language (XPath) Selectors
>> Author(s) : J. Urpalainen
>> Filename : draft-ietf-simple-xml-patch-ops-00.txt
>> Pages  : 21
>> Date  : 2005-11-30
>>
>>    Extensible Markup Language (XML) documents are widely used as
>>    containers for the exchange and storage of arbitrary data in  
>> today's
>>    systems.  Updates to this data require transporting of the  
>> entire XML
>>    document between hosts, unless there's a mechanism that allows
>>    exchanging only the updates of XML documents.  This document
>>    describes an XML patch framework utilizing XML Path language  
>> (XPath)
>>    selectors.  With the aid of these selector values and updated data
>>    content a set of patches can then be applied to an existing  
>> initial
>>    XML document.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-simple-xml-patch- 
>> ops-00.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-xml-patch-ops-00.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-xml-patch-ops-00.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.
>> Content-Type: text/plain
>> Content-ID: <2005-11-30114220.I-D@ietf.org>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www1.ietf.org/mailman/listinfo/i-d-announce
>
> _______________________________________________
> 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 Wed Dec 07 01:44:54 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ejt2s-0001qC-OU; Wed, 07 Dec 2005 01:44:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejt2r-0001oG-AT
	for simple@megatron.ietf.org; Wed, 07 Dec 2005 01:44:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20617
	for <simple@ietf.org>; Wed, 7 Dec 2005 01:44:01 -0500 (EST)
Received: from mgw-ext01.nokia.com ([131.228.20.93])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjtOU-00030F-Cv
	for simple@ietf.org; Wed, 07 Dec 2005 02:07:15 -0500
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213])
	by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	jB76igNF009739; Wed, 7 Dec 2005 08:44:43 +0200
Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by
	esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 7 Dec 2005 08:44:12 +0200
Received: from mgw-int2.ntc.nokia.com ([172.21.143.97]) by
	esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Wed, 7 Dec 2005 08:44:12 +0200
Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	jB76i6525557; Wed, 7 Dec 2005 08:44:06 +0200 (EET)
Received: from xitami.research.nokia.com (xitami.research.nokia.com
	[172.21.50.105]) by kusti.research.nokia.com (Postfix) with ESMTP
	id 714D093B7A; Wed,  7 Dec 2005 08:44:06 +0200 (EET)
Received: from hed034-145.research.nokia.com (hed034-145.research.nokia.com
	[172.21.34.145])
	by xitami.research.nokia.com (Postfix) with ESMTP id 589472E3;
	Wed,  7 Dec 2005 08:44:06 +0200 (EET)
Subject: Re: [Simple] draft-ietf-simple-xml-patch-ops-00
From: Jari Urpalainen <jari.urpalainen@nokia.com>
To: ext Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <BFBA5ED0.63B94%fluffy@cisco.com>
References: <BFBA5ED0.63B94%fluffy@cisco.com>
Content-Type: text/plain
Date: Wed, 07 Dec 2005 08:44:05 +0200
Message-Id: <1133937845.21359.26.camel@hed034-145.research.nokia.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 07 Dec 2005 06:44:12.0028 (UTC)
	FILETIME=[A1EB4BC0:01C5FAF9]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: 7bit
Cc: "simple@ietf.org" <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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

On Mon, 2005-12-05 at 21:17 -0800, ext Cullen Jennings wrote:
> I was somewhat surprised to see this as a WG item. When do we use this and
> when do we use xcap?
Robert answered to this.
> I was also sort of wondering about how to deal with the issues of elements
> that used name spaces inside of the data portion of attributes. For
> example... 
> 
> if I have namesace xmlns:z="urn:foo"
> 
> then I have sel="z:doc"
> 
> Would I ever have the case where the some xml parser library changed my
> namespace to xmlns:z="urn:foo" (it would do this perhaps because x was
> already in use)? If this happened, it seems like the "z:doc" would not get
> changed to "x:doc" and things would break badly.
> 
> Thoughts? Is this a problem or is it all avoided some how?
> 
I had some trouble in understanding the issue, but you can add or change
namespace prefixes of some elements when you use local namespace
declarations within them, as an example:
<replace sel="*"><x:doc xmlns:x="urn..." ...</replace>. However, I
cannot imagine a real use case for it. 

In patch-ops the namespaces within the "body" are changed to to use the
declarations within the initial document and matching is based on
local-names and namespace URIs, so a similar model is adopted what XPath
uses when locating nodes. 

br,
Jari


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



From simple-bounces@ietf.org Wed Dec 07 02:14:19 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjtVL-000122-LS; Wed, 07 Dec 2005 02:14:19 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EjtVJ-00011x-Jy
	for simple@megatron.ietf.org; Wed, 07 Dec 2005 02:14:17 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23811
	for <simple@ietf.org>; Wed, 7 Dec 2005 02:13:21 -0500 (EST)
Received: from mgw-ext03.nokia.com ([131.228.20.95])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejtqo-0003za-2A
	for simple@ietf.org; Wed, 07 Dec 2005 02:36:32 -0500
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213])
	by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	jB77AZ0M019590; Wed, 7 Dec 2005 09:10:37 +0200
Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by
	esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 7 Dec 2005 09:13:03 +0200
Received: from mgw-int2.ntc.nokia.com ([172.21.143.97]) by
	esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Wed, 7 Dec 2005 09:13:03 +0200
Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	jB77Cu504625; Wed, 7 Dec 2005 09:12:56 +0200 (EET)
Received: from xitami.research.nokia.com (xitami.research.nokia.com
	[172.21.50.105]) by kusti.research.nokia.com (Postfix) with ESMTP
	id 088EC93B78; Wed,  7 Dec 2005 09:12:56 +0200 (EET)
Received: from hed034-145.research.nokia.com (hed034-145.research.nokia.com
	[172.21.34.145])
	by xitami.research.nokia.com (Postfix) with ESMTP id F32B22E3;
	Wed,  7 Dec 2005 09:12:55 +0200 (EET)
Subject: Re: [Simple] draft-ietf-simple-xml-patch-ops-00
From: Jari Urpalainen <jari.urpalainen@nokia.com>
To: ext Robert Sparks <rjsparks@nostrum.com>
In-Reply-To: <E450FB36-CC23-4CAD-B327-A41ECF131D90@nostrum.com>
References: <BFBA5ED0.63B94%fluffy@cisco.com>
	<E450FB36-CC23-4CAD-B327-A41ECF131D90@nostrum.com>
Content-Type: text/plain
Date: Wed, 07 Dec 2005 09:12:55 +0200
Message-Id: <1133939575.21359.53.camel@hed034-145.research.nokia.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 07 Dec 2005 07:13:03.0155 (UTC)
	FILETIME=[A9C05030:01C5FAFD]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Content-Transfer-Encoding: 7bit
Cc: Cullen Jennings <fluffy@cisco.com>, "simple@ietf.org" <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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

On Tue, 2005-12-06 at 15:27 -0600, ext Robert Sparks wrote:
> On Dec 5, 2005, at 11:17 PM, Cullen Jennings wrote:
> 
> >
> > I was somewhat surprised to see this as a WG item. When do we use  
> > this and
> > when do we use xcap?
> 
> This draft is intended to be what the group agreed to adopt as the  
> solution for
> xcap-diff and the partial-* work based on the output of the patch bof  
> and the
> SIMPLE WG discussion in Vancouver. It went beyond its mandate  
> including patch
> operations for general text elements - this is something the group  
> explicitly decided
> to not try to tackle by my memory.
> 
> I can see your confusion given that the draft doesn't reference  
> partial at all.
> 
Partial pidf format is referenced and it is also mentioned in the text,
isn't that enough ?
> Jari - could you provide a revision quicky that includes a section  
> pointing to how this
> would be used with xcap and with partial?
> 
reference to xcap-diff could be added, but I didn't do it as there isn't
yet a xcap-diff spec that references patch-ops. 
> All - comment on the text modifying proposal quickly. Unless there is  
> a very
> strong "Oh yeah - we all want to do this this way", and soon,  I will  
> ask Jari to remove
> this mechanism from this draft and return to exactly the scope we  
> agreed to
> in Vancouver.
> 
> RjS
> 
Agreed, those with a "desperate" need for this should speak up. This is
certainly feature creep that doesn't fit to the spec very well. Also, I
don't like reinventing the wheel unless absolutely necessary, but I
don't feel comfortable with the ipr issue of vcdiff. If that doesn't
vanish I'll intend to remove text-patching from the spec. vcdiff and
gdiff have "copy & add" logic, so in order to differentiate one could
propose a "add & replace" logic like: <p>44</p>New text inserted after
char-pos 44<r l="3">100</r>removed three chars from pos 100 and added
this text. But as said this is still reinventing and as partial-pidf or
xcap-diff do not need this (though text-patching is a separate
operation) it should not be in this spec.  

thanks,
Jari 


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



From simple-bounces@ietf.org Wed Dec 07 03:34:48 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EjulE-0003g1-Jh; Wed, 07 Dec 2005 03:34:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EjulC-0003fY-KA
	for simple@megatron.ietf.org; Wed, 07 Dec 2005 03:34:46 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01587
	for <simple@ietf.org>; Wed, 7 Dec 2005 03:33:54 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejv6q-0006J5-Vy
	for simple@ietf.org; Wed, 07 Dec 2005 03:57:10 -0500
Received: from [131.106.56.194] (ip-66-181-12-21.cust.i2bnetworks.com
	[66.181.12.21]) (authenticated bits=0)
	by nostrum.com (8.12.11/8.12.11) with ESMTP id jB78YJ3T011752
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 7 Dec 2005 02:34:21 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
In-Reply-To: <1133939575.21359.53.camel@hed034-145.research.nokia.com>
References: <BFBA5ED0.63B94%fluffy@cisco.com>
	<E450FB36-CC23-4CAD-B327-A41ECF131D90@nostrum.com>
	<1133939575.21359.53.camel@hed034-145.research.nokia.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <86555A6D-CFB0-4595-8FE6-069F768F640A@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [Simple] draft-ietf-simple-xml-patch-ops-00
Date: Wed, 7 Dec 2005 00:32:18 -0800
To: Jari Urpalainen <jari.urpalainen@nokia.com>
X-Mailer: Apple Mail (2.746.2)
Received-SPF: pass (nostrum.com: 66.181.12.21 is authenticated by a trusted
	mechanism)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Content-Transfer-Encoding: 7bit
Cc: Cullen Jennings <fluffy@cisco.com>, "simple@ietf.org" <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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org


On Dec 6, 2005, at 11:12 PM, Jari Urpalainen wrote:

> On Tue, 2005-12-06 at 15:27 -0600, ext Robert Sparks wrote:
>> I can see your confusion given that the draft doesn't reference
>> partial at all.
>>
> Partial pidf format is referenced and it is also mentioned in the  
> text,
> isn't that enough ?

I meant to say xcap there. Sorry for the confusion.

I do think more text pointing to the uses would be helpful. I'll
try to pull something together to contribute.

RjS

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



From simple-bounces@ietf.org Thu Dec 08 07:46:46 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkLAc-0000eL-H1; Thu, 08 Dec 2005 07:46:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EkLA2-0000dB-0H
	for simple@megatron.ietf.org; Thu, 08 Dec 2005 07:46:30 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09266
	for <simple@ietf.org>; Thu, 8 Dec 2005 07:45:09 -0500 (EST)
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkLVi-0006oe-S2
	for simple@ietf.org; Thu, 08 Dec 2005 08:08:40 -0500
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CB0061198;
	Thu,  8 Dec 2005 13:45:50 +0100 (CET)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 8 Dec 2005 13:44:25 +0100
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 8 Dec 2005 13:44:24 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se
	[131.160.33.3])
	by mail.lmf.ericsson.se (Postfix) with ESMTP id AC124236D;
	Thu,  8 Dec 2005 14:44:24 +0200 (EET)
Received: from localhost.localdomain (localhost [127.0.0.1])
	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 728E01AB8EE;
	Thu,  8 Dec 2005 14:44:24 +0200 (EET)
From: "Salvatore Loreto (JO/LMF)" <salvatore.loreto@ericsson.com>
To: simple@ietf.org
In-Reply-To: <1134021749.3365.4.camel@n121.nomadiclab.com>
References: <1134021749.3365.4.camel@n121.nomadiclab.com>
Content-Type: text/plain
Date: Thu, 08 Dec 2005 14:44:24 +0200
Message-Id: <1134045864.3349.4.camel@w189.nomadiclab.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Dec 2005 12:44:24.0958 (UTC)
	FILETIME=[1EA471E0:01C5FBF5]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Content-Transfer-Encoding: 7bit
Cc: RjS@estacado.net
Subject: [Simple] simple-xcap in rfc editor queue
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi all,

I've just checked and the draft draft-ietf-simple-xcap is still in
RFC-Editor's Queue.

When it'll be removed?
Or in other way what is the right process, or the process does the wg
want follow in this case?

thank you 
Sal


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



From simple-bounces@ietf.org Fri Dec 09 04:27:41 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkeXV-0000Pl-3c; Fri, 09 Dec 2005 04:27:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EkeXS-0000P8-9J
	for simple@megatron.ietf.org; Fri, 09 Dec 2005 04:27:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06725
	for <simple@ietf.org>; Fri, 9 Dec 2005 04:26:40 -0500 (EST)
Resent-From: ashutosh_p@spanservices.com
Resent-Message-Id: <200512090926.EAA06725@ietf.org>
Received: from [202.177.174.130] (helo=spanservices.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkeXV-0003rP-AD
	for simple@ietf.org; Fri, 09 Dec 2005 04:27:43 -0500
Received: from [202.177.174.131] (HELO Maya) by spanservices.com (MicroWorld
	SMTP 5.6.2) ; Fri, 09 Dec 2005 14:57:06 +0530
Resent-Date: Fri, 09 Dec 2005 14:57:06 +0530
X-Originating-IP: 202.177.174.131
X-Auth-User: ashutosh_p@spanservices.com
X-Filename: C:\PROGRA~1\MAILSCAN\in\SMT1522471478208.TMP
X-MSReally-From: ashutosh_p@spanservices.com
From: "Ashutosh P - SPAN" <ashutosh_p@spanservices.com>
To: <simple@ietf.org>
Date: Fri, 9 Dec 2005 14:57:03 +0530
Message-ID: <FOEMIOGOHJJIHFMNEBBNKEJGCCAA.ashutosh_p@spanservices.com>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
X-Spam-Score: 1.2 (+)
X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91
Subject: [Simple] Help required in XCAP Server
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="===============1171086160=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

--===============1171086160==
Content-Type: multipart/related;
	boundary="----=_NextPart_000_0019_01C5FCD0.D0BAD730"

------=_NextPart_000_0019_01C5FCD0.D0BAD730
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_001A_01C5FCD0.D0BAD730"


------=_NextPart_001_001A_01C5FCD0.D0BAD730
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

HI,

I am trying to understand and implement a simple XCAP server.
But I dont know exactly where to start my reading.
I have some fundaental knowledge about the Presence server
and have undergone some RFC's and drafts in the simple link page.
But I have some doubts regarding XCAP server.

1. How exactly I can relate an XCAP server to a SIP Presence Server?
   means how exactly they both are related?
  If someone could please give some pictorial architecture of the relation.

2. What all documents are required to go through for an XCAP server?

3. How the repository in XCAP server different from that of a Presence
server?

Any information on XCAP part will be of great help.

Thanks & Regards,
    Ashutosh

SPAN Systems Corporation, Bangalore. 
"Steering Progress, Together" 

--------------------------------------------------------------------------------
This email message and any attachments is confidential and intended only for the use of an individual or entity named above and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email or itsupport@spanservices.com and destroy the original message. Opinions, conclusions, and other information in this message that do not relate to the official business of SPAN, shall be understood to be neither given nor endorsed by SPAN.



------=_NextPart_001_001A_01C5FCD0.D0BAD730
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D812441209-09122005><FONT=20
face=3D"Book Antiqua">HI,</FONT></SPAN></DIV>
<DIV><SPAN class=3D812441209-09122005><FONT=20
face=3D"Book Antiqua"></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D812441209-09122005><FONT face=3D"Book Antiqua">I am =
trying to=20
understand and implement&nbsp;a simple&nbsp;XCAP =
server.</FONT></SPAN></DIV>
<DIV><SPAN class=3D812441209-09122005><FONT face=3D"Book Antiqua">But I =
dont know=20
exactly where to start my reading.</FONT></SPAN></DIV>
<DIV><SPAN class=3D812441209-09122005><FONT face=3D"Book Antiqua">I have =
some=20
fundaental knowledge about the Presence server </FONT></SPAN></DIV>
<DIV><SPAN class=3D812441209-09122005><FONT face=3D"Book Antiqua">and have =
undergone=20
some RFC's and drafts in the simple link page.</FONT></SPAN></DIV>
<DIV><SPAN class=3D812441209-09122005><FONT face=3D"Book Antiqua">But I =
have some=20
doubts regarding XCAP server.</FONT></SPAN></DIV>
<DIV><SPAN class=3D812441209-09122005><FONT=20
face=3D"Book Antiqua"></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D812441209-09122005><FONT=20
face=3D"Book Antiqua">1</FONT></SPAN><SPAN =
class=3D812441209-09122005><FONT=20
face=3D"Book Antiqua">. How exactly I can relate an XCAP server to a SIP =
Presence=20
Server?</FONT></SPAN></DIV>
<DIV><SPAN class=3D812441209-09122005><FONT face=3D"Book =
Antiqua">&nbsp;&nbsp; means=20
how exactly they both are related?</FONT></SPAN></DIV>
<DIV><SPAN class=3D812441209-09122005><FONT face=3D"Book Antiqua">&nbsp; =
If someone=20
could please give some pictorial architecture of the=20
relation.</FONT></SPAN></DIV>
<DIV><SPAN class=3D812441209-09122005><FONT=20
face=3D"Book Antiqua"></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D812441209-09122005><FONT face=3D"Book Antiqua">2. What =
all=20
documents are required to go through for an XCAP =
server?</FONT></SPAN></DIV>
<DIV><SPAN class=3D812441209-09122005><FONT face=3D"Book =
Antiqua">&nbsp;&nbsp;&nbsp;=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D812441209-09122005><FONT face=3D"Book Antiqua">3. How =
the=20
repository in XCAP server different from that of a Presence=20
server?</FONT></SPAN></DIV>
<DIV><SPAN class=3D812441209-09122005><FONT=20
face=3D"Book Antiqua"></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D812441209-09122005><FONT face=3D"Book Antiqua">Any =
information on=20
XCAP part will be of great help.</FONT></SPAN></DIV>
<DIV><SPAN class=3D812441209-09122005></SPAN><SPAN =
class=3D812441209-09122005><FONT=20
face=3D"Book Antiqua"></FONT></SPAN>&nbsp;</DIV>
<DIV><FONT face=3D"Book Antiqua" color=3D#004000>Thanks &amp; =
Regards,</FONT></DIV>
<DIV><FONT face=3D"Book Antiqua" color=3D#004000>&nbsp;&nbsp;&nbsp; =
Ashutosh=20
</FONT></DIV>
<DIV><FONT face=3D"Book Antiqua"></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

<html>
<br>
SPAN Systems Corporation, Bangalore. <br>
"Steering Progress, Together" <br>
<br>
---------------------------------------------------------------------------=
-----<br>
This email message and any attachments is confidential and intended only =
for the use of an individual or entity named above and may contain =
information that is privileged, confidential or exempt from disclosure =
under applicable law. If you are not the intended recipient, you are =
notified that any dissemination, distribution or copying of this email is =
strictly prohibited. If you have received this email in error, please =
notify us immediately by return email or itsupport@spanservices.com and =
destroy the original message. Opinions, conclusions, and other information =
in this message that do not relate to the official business of SPAN, shall =
be understood to be neither given nor endorsed by SPAN.<br>
<br>
<br>
</html>

------=_NextPart_001_001A_01C5FCD0.D0BAD730--

------=_NextPart_000_0019_01C5FCD0.D0BAD730
Content-Type: image/bmp;
	name="span logo.bmp"
Content-Transfer-Encoding: base64
Content-ID: <812441209@09122005-088e>
Content-Transfer-Encoding: base64

Qk2GHQAAAAAAADYEAAAoAAAAtAAAACQAAAABAAgAAAAAAFAZAAAAAAAAAAAAAAABAAAAAQAAXksk
AGVNHgBqTh4AYkcfAGpRHgBtUh4AbFIcAGZTHgBxUx0AZk0hAGVNIwBpTSIAa04kAGNOKgBkUiwA
alIhAGxTIQBtUiIAbVIlAG1UIgBuVSUAalMkAGxVKwBtWiwAaVYlAGVVMgBsVjIAbFs0AG1bOgBl
WTsAcVYlAHFUIgBxVioAclklAHJZKgByWy0AcVszAHFdPABxVjEAc2I8AHZjOAByYTUATE5MAERG
RQBPUU8AUlRSAF5eXQBaXFoAVllWAF5hXgBfYmEAalxBAG5hQQBhYV8AdGRDAHlqSQB4bVMAfnNW
AGVmZQBjZGIAbW5tAGpsagBoaGYAbnFuAHJycQB1dXMAdnZ1AHN1cwB5eHYAenp5AHp9egB+f3wA
fH17AHZ4dwBwcG8AfYB9AH6AgQCCajQAgXFNAIJ0VQCKe1wAh3dZAIl9ZACMgWoAgIB+AI2FcgCR
hGUAmottAJqNcwCVinQAnJR7AJqRdACklnkAgoKBAISFgwCMjYwAh4iGAI6RjgCQkY8AnpaDAJOU
kwCVmZYAm5ybAJiZlwCWj4UApJqEAK6kiQCmopkAsaaKALWrlAC3q5YAvLScALKwlwClpqUAoqOi
AK6vrQCrrKoAqKmnALezqgCysrEAtre1ALO1swC6urkAvr69ALu9uwC3ubcArrGuAJ+goAC/wr8A
wbaYAMW7pgDEvrAAyMKqAMLCvADOy7sAysW2ANLKswDTzLsA2cu4ANnSvQDCwsEAxcXDAMbGxQDC
xcIAycnFAMrLyQDMzcsAxsnGANTNwgDV0sMA09LMANvVxADb1coA3tnFAN7aywDV1dMA09TTANvZ
1QDa29oA3d3bAN7f3QDb3NoA19nXAM/RzwDf4d4A4tvLAOHaxwDj3dQA6OXNAObi0wDh4d8A5ePc
AOrk1ADt6twA7OfaAPHs3AD0898A4eLhAOTk4gDl5uQA4uXjAObp5gDt7OMA6erpAOrt6gDt7esA
7u/tAOvt7QDp6ecA7/LxAPPu4wDy7+oA9PHkAPHx7gD19OwA+fbrAP377AD69eUA8vLwAPHy8QDy
9fIA9fXzAPf39QD19/UA8/X1APT2+QD2+fYA9vn2APb58wD2+fkA9fv7APr39AD6+vIA+fn3APr6
9gD6/fYA/fvyAP369gD+/fIA/v32APr98QD4+fgA+Pv4APr6+AD7+/kA+vv5APv7+gD5+voA+fr8
APn8+QD4/PkA+vz5APr9+gD7/PoA+/77APv++gD5/foA+v38APz7+QD9+voA/Pz5APz8+gD9/fsA
/Pz7AP7++gD8//wA/v78AP///QD+//4A////AP/+/gD9/f0A/fr9APv2+ADu8e4A3+HhAMrO3+Dg
7uDg4ODg4ODg4PHx8fHx8fHx8fHx8fHx8PP84e315PPg5dLR7e3s8uDq5+jo6Ojq6urq6urq6urq
6urq6urq6urq6ujo6PHx8fLy8urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq
6urq6urq6urq6urq6ury8vLy8vHx8fHy8vHx8fHx8fHx8fHx8ejo6Orq6urq6urq6fHx8fHx8fHx
8fHx8s7f3+Dg7uDg4ODg4ODg4PHx8fHx8fHx8fHx8fHx6Ojy8tv09NPT9/ni6PLKv9bq6uXo6Ojq
6urq6urq6urq6urq6urq6urq6ujo6PHx8fLy8urq6urq6urq6urq6urq6urq6urq6urq6urq6urq
6urq6urq6urq6urq6urq6urq6urq6ury8vLy8vHx8fHy8vHx8fHx8fHx8fHx8ejo6Orq6urq6urq
6fHx8fHx8fHx8fHx8t7h4ODg7uDg4ODg4OHg4PHx8fHx8fHx8fDx6enp5efZxKlqTic2Tmql1NvZ
woWQyPLo6Ofq6urq6urq6urq6urq6urq6urq6ujo6PHx8fLy8urq6urq6urq6urq6urq6urq6urq
6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ury8vLy8vHx8fHy8vHx8fHx8fHx8fHx8ejo
6Orq6urq6urq6fHx8fHx8fHx8fHx8tbX39/i49nZ8Nfu4NXb2vT09/T099/n3tTc0Nfm3dnDWCQR
EBQUESApVrDZ5PSGOIf08Ofy8vLy8u3y8vHx8fHq6urq6urq6ujo6Ojo6Ojo6Orq6urq8fHx8eDJ
3ujl6OXO9erq6urq6urq6urq6urq6M7lzujo6urq6uro6Ojx8fHx8fHx8fHx8fHx8fHx8fHx8fHx
8ere3ure5/Hy8vLy8fHx8fHx8fLx8fHx8fHx8fHx6dLS0dHd3dHR5ufw261SUVBQUFBQVavX0vCs
U8PZ3r5QCg8RERARER4gG0/C89nbbg5cwOTz8/Py8vLy8vHx8fHq6urq6urq6ujo6Ojo6Ojo6Orq
6ujo6fHx4PLfopyizt7n6Orq6urq6urq6urq6urozqScosjq6urq6uro6Ojx8fHx8fHx8fHx8fHx
8fHx8fHx8fHx8erOoqK15/Hy8vHx8fHx8fHx8fLx8fHx8fHx8fHx8t/V2dfa2tvawKWJbjgOFhYa
FhsdmtPu24s2NNrR21oMCB8PEBAQDxMhIiRv9NXfrygjTq3x4dLt8vTy8vLx4Onq5fXo6ufo5ejo
6Ojl6uje5eXq5ejo5+Dx8fKMYMmfZPjd6Oro6urq5erl6ufo6OrltEv+t2X46ure6uro3ujy8fHV
8fHx8vHx8fHx8fHg8vHx8fHf3/h+fP5zkeDx8d/g8+Li4vPf4unp8unh8eDx4N/g6dm/p5WDdmxj
W1hXV1tbW1pjY1qL9N/XiyUWNq/Qig0FCAUJEBEQEB8UISJP2OnS1FEmF0+t193t6fDy8uDVqoCc
4+PLjrjosZOf3eikkaTOuMjl5bXLxrffxsGxYaCTMPXn6t633eXo5bjO3efLorTtu2T/sT3Husvn
58ihs97KqrPx1byk4ODGwfHx8eDgycng37qq3/WAk8ePZPbKsbrf4v6348vi3cvd6Le139XK39/+
4dXV4PDW197ezt7l1tvZ2Nvb29vX4dapJRYWFQ5OKAoCAhECBgUTBgUVIiI2wOTk2lYXJzM5w9bt
6fDy8uC5QqJ3dPtyTLh7PaGAunhIsXnIZpHqzj3qe0DydXffLkNInOro58gquuXozju15bg9kWZ9
7T0uOnjoMLXoszp9ebSjeHJ7yWCMZ9VlYvfx8fHgXXjgkF2AQrixLDE7nrdKc3+x1TyRs0njk2L4
c2F5d/k7ubw1usrd3c7LztnT1dX09/f59/fy29bR3cNQDTRXXE8DCREFBQIJBgYGBgUSFCM2w/Dj
w09QrrKnwtvx6erx8eDgxvf4Pflhd/hAo7y6+T2et737f6Pf1Unyjl3ydH35X35y3t7q5csqzvXl
4Ty343lh+b0u4mVmZr3dL7vyf3H5+fvyn0Re8slyOvHJyfHx8eDgXnz5Pbf5dXW6SHST+XJ6+fn2
x2D4t0DLjl7HL935+Pktud234dHR0czL0c3SzcJVUVBQUVFSqdff24M5lfT39fe+WhoPBQUEBgYF
BgUTIRZY9NbnqCRXr9Tx4vzz8ery39/fungvYfVlce1GZnsunkNxfCqef3zx4ETxjTzidHq8K/l+
evXO5c4sfZO44zqe0Xlf+L0xxyrRoF/tL6DdcjxxQXOSL3fx1Sxis9/x8fHx8eDxXoD5PbX1fnGj
Z/ktsX9JcTp0y2Dtuz3RkWC9K3JlMfUsteXl4dHe3tvaw6+lioEXFRYiIhpR1OfYwGjD29vi49/f
06xQCgUIEAQEEBMeIhua6ujaUCAjNm3a2/Lt8/Tx8eDKPmKx3r08P/+gTHFezJ5ecWT7cmJUyVT3
jEFkOrfjXnpLYt7d6MssuqQ9vUNfX9FFeGR7+11+ZEXMMl5ivUWMVLKeZHWc9mCMdPHx8fHx8eDy
XpPnj1+RP7SxRZwqjrdMoz20jDyjui11SXf5Znp0cfkrRnTh6auWh3ZrY1lVU1NXWFlbV1mQ4/Da
ldjn19nU29vu49XabBUEDxAPEBMeF1DU49htCh8eFhZZw+7k8/Tx8fHGPsrLoN50cuf16rn46PXe
uvno3vfJ4KTy1fDGyfLi97X+yOjo6Mgqvbox/svo/vX1tLr16Pi0t/7lyM659t+gyfL2uqrV8d+e
xuDy8vHx8dXVXYDO6rWiyOrouJu4ufP+m8nxsUW7uz//ovHf86Kh8d+8uaTf6djU2NjY2NXKy83N
y9DU1NDj4/DZudPW3tSsmaXAxNvW2IgZEQ8PERQWGabz24oODwYQFSEjbPTk7fTx8fHfqmJfkeXh
y+jq6ujo6Ojo6Orq6vHx30fV3/Hx8fHx6Ojo6Ojo5ctfZ1+R6Oro6urq6Ojo6urq6Oro6Ojg4PLx
8fHx8fHx8fHy4PHy8vHx8ZFFQks/s+Xo6ujl5erl3+Dx4ODx3brRt0rj3eDg4N/g4N/f8d/x6dXO
0dHRzc3d3tfX1+Pm3tbb1vDz5ODagk4WCxUkUW3A9NmIFQkSEh4Wb9v5lBYPEQYPDx4iHKnt5PHx
8eDg8vn49eje6Or16ujo6Ojo6Ovq6/Hx8fng8fHx8fHx8err6Ojo6On5+ff25d7q9eXq6urn6urq
6vXq6Ojy8fLx8fLx4PHx8fHy9uDy8vHx8fb5+fn55+fo6N7r6OXn5+Dx4PHx4uPox5zd8fHg4ODg
8eDg39/g6d/V1dXKy93TwJeZmJiZmb7X4dnb49BpDAwSDBISFhYagsLbiRwVFBZp3MSIGRAFEAQT
DxQgF1ru0tfx8fLx8fHy8uDx8vbx8fHy8fHx4ODy4ODy4PHx8vLx8fLx8vbx8fHx8fHx8eDx6urq
6Ojn8vHy8uDx8fLx8fHy8fLx8eDx8fHy8fLy8fbx8fLx8fLy8vHx4PHx8fHx8fHx8fHg4ODg8fHg
8fHx8e7g4ODg4ODx4ODg6c7OztbU2NvEiA4mIyYkHJXj3vDb2ZkODAsLCQwLDxEUFk+l5IoWDmnT
2WoYBwQEBAQTEBMUIjjC4tfx8fHy8ff5+fn38vLy8vf39/Hy8fH29/fx8fHx4PL29/by9vf38fHx
8fHx8vfp6urq6Ojq8vL39/f28fLx8fHy9vb28uDx8fH29/f28vHx8fHx8vb28vHx8fLy8vb28vHy
8vLg4ODg4PLx8fHx8vHu8fH29vbx4ODg6b6rmpWHb2lVORkaGhobM6fV1+DZ2lYJCwsJCwsJDwIE
Eg8bicSGa9qtVgMGBgIEAgIEBBMeITa+4Nfx8fHfm3JhXl9zouDgynp0gMrx4OCheXrK3/Hx8fGR
eXy6oHiO4PHx8fHjjGTy6urq6OjooHlnZ3V7vPLx8fHgm3uMyfLxyY1zf3F9ofbx8uC5jY2q8fHy
nI6OjYyMjcaejp7g4N/xt7Pg8eDBkpa6qo54eHueyfHg6cO+wL6+r62vr6+2travttPZ2+XRxA0P
AQsLCwsLCwsMEiAUG4Lm45obBwIMAgQBAQQEDxARHja+8vTx8fbJR3Wyxrl3NWTx8nE+m/Hx8t/g
dELx8eDx3/FfOp/KwUqO8fHx3d1iOkD46urq6Oj1X2abt6BkPYD28fHfkTpx4N/3jER6nqpzOl/K
4PHJSkDV4ODxejVIcnN0SHSzOpLy4N+5QGf24NXxRkb+RmSAnHdAQarp6crV1crK3crL0NDf4uHX
3uP02ufSqQAPCQsLCQsMBAQJEhIWWK7015UcCwQGBAQEBAQEBBMSIjfC5PPx8d/V3/fy4NX5Zy6S
33U1n+Dy4ODfukqA8vb297I8Z/LgwUGj8fHyvV81XkT56urq6OjVyffy8vb5Sjq84PHxnC558uDg
svf58uD5fC548uDfQETg4N/fkDWO9/f2+brxQnjy8fdxPj2j8dXfMmW9vPb28vfKSkTG6ePd0c3R
zc3Iq5WXmZimmMLi2N7NpQAKCQsLCwwMBxAMFhtv18Rti9qtNwkGBAoJCQIFEBAIFmnu7fHx8fbK
4N/ozv5zLz6g1XUunuDV39/g33RGj5ORkV88svHuyUCj6Of+XTySjUj38fHx8vHg3/Lg4Ml3NUHG
8fHKoy538d/f8d/g4NWqSDp74PHKSkT23+7ykD6N3+Df8fHVYmTg8aA+Z3RdyfGzMX7q3+Df38t4
O0nI6dXWytPU09bEhBkaJBscHabh197RxQAMCwsLCwsSEg8VNpfaxVcOJZfYrVIBBggFBAYFHyEi
N77i6fDx8fHf8cp9Xjs6ZrHg4HUvoJ93ZIzg38tGZXx9ZDt49vHxxj+j3bRLSpvye0X38fHx8vHx
4MqOYko7Z6rx8fH3cS9Iyt/g4PaxdUU1RI3K8eDVQUXy8e72kDt/gHOg8fHxc1TVyl1AwbpBnPaM
MaLo4PGcZT8xYqTO6cK5raeYhnZqUA4aJiMpHYfKy97h204JCwsSDAwSIA43rNi+UBUeICep28Np
GggFBR8fIhc3mdri8/Dx8eDyoD8wS3rI6uHg338v//L2ezV39uV8Xs7oYUnH4vHxxj+btEM/oN/y
fEf58fHx8vHgs0Q7XXrB9t/g8fKNLmJCZMrf33UuPWSi4Pbx1fbVQV3y8fHyjT5eZ2Gy1fHgjkDB
kT564Pd6XeB/P7rosVQxQnW19d7d6cK/tq2urKiopqWprq6ttsL9yt/W24sNDBIMEhIgFzm/2cM5
DBAIHxQnmdfetm00AA4OGVy+29nf8eDx8d/JVCp8zurl5/Hx1X8vn+DfsjVF1eXLS4+jPnrz4vHx
xkl0P0i48fH3fEX38vLy8fH2ZzWAxvHf4NXy4Jw6YcnBQH/5kTVHutXx8fLg1fHJQlT21eDxjT6Q
8fLf4PHgnz2gQkfK4ODGRXxdSPH5YC98y+ro5ejh8tbf1tbW1tzU0MrRzd3d3dXx59fZ49BYCgwS
ICAgTr7d1FYPAgQGHiEeKYjU4PTarJSXw9vn4Nmr9ufx8fHfdSxms7i0k7zx32YvjKKjYDVz8uX1
kl5IXfv74vH2yEMxXbjd8eD3fUL28vLy8fHxdS5zuca5krnynz1Ewd/gszx0sTpUssrJoKOzn7e8
QUe5uaHKjTp6ubqhxuDxyj1dPaDx4ODgeEU8YuD3YTGTzt7Io87o8uHV3ePRzc3Ny8Kvr6+vrbbD
4e7b0s7EXCYWICAnrtTchAwfEQ8PExQQICRsxNnv4uHf49Hk2b6z6e3x8fHg4ZJdPz0/RrPpxl9J
REVUZJvJ8971tWBenO378+DxkUtfyOjn8enJZEih8vLy8fHyynk/PTw9RLKgXl288dXpyWJBk5te
PEBAP368QUdUREFCQkSdfzxAQUJBsvLxukBAZN/g4ODg4Ec+Z+HxumQ/QEU/PN3e8srV1c7V1dHN
06k0HCcoJzRj2OLi4Ofl3IdQIxlv8OLaTg8SExAPDw8RICEUT4PZ9Obk/OzRvmnC4/Hq6urq6vX1
y73I3uXq5eXo6Ojq+PXo6PXo3d7l6urq6Orozujd6uXq6urd3uXL6urq6uro6PXO/re6yOjIzubq
6Ojo5cjIyOrl/rW1/t7h/srJycnJycnJwcnJycnG4PLgysbJyvLx8fHx8snBwd/x8ffGsZ+yut/g
6N7Qwr+2rayZhGopFxokJho2r9fW4OL80eTaN0/Z29asABMRDwQPEA8EBR8hIhgnbKiwwL+mOJX1
+/Lq6urq6urq6Ojq9ejo9erq6vXl6urq6urq6vXo6Orq6urq5ejl5c646Or16uX16urq6urq6vXo
5+rq6Orl6urq6urq5eXo3ujo6Oro5eXd5fLg8fHy8fHg4PHg4PHg8vL28fLy8fLx8fHx4ODy4PLg
8fHy8fHg4N/h6M61n5qVlIeFhYeGiYaJiYmUtu/f4NSDhKWKG4Hk8NttAQUREw8PEA8QEBMfISEf
EBQjTSgkadvt+/Lq6urq6urq6urq6urq6Orq6urq6urq6urq6urq6urq6urq6urq6uro6urq6urq
6urq6urq6ujq6urq6urq6urq6urq6urq6Ojq6urq6urq6vHx8fHx8fHx4PHx8fHx8fHx8fHx8fLy
8fHx8fHg4PHx8fHx8fHx8fHp6N7X29fa2+/v79nv7tfX69fb2/TV4NqGHRYkJKbS1fRqAQUREw8E
EBQQEhIeIiBqbVYXIRdPwOP28vvq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq
6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6vHx8fHx8fHx8fHx8fHx
8fHx8fHx8fLy8fHx8fHx4PHx8fHx8fHx8fHy6t/f4N7j493h39bfwqWmpaWlpZrD3+/ZghsjJafc
6fSEARAMEBAQBA8RERMUKSWt174nI1HA0tHb29Lq6urq6urq6urq6urq6urq6urq6urq6urq6urq
6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6vHx8fHy
8vLy8vHx8fHx8fHx8fHx8fLy8fHx8vLy8fLy8fHx8fHx8fHy9dXw1tbW4OTk+/r3xDkODQ0ODg5S
xdbR8G0kJYfX4+7FGxEIDxAFBRERFCEhGW/01q0bUq717ezy6u3q6urq6urq6urq6urq6urq6urq
6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq
6urq6urq6urq6urq6urq6urq6urq6urq6ujo6Ojo6ujo6Ojo6urq6urq6urq6PHV8NXWwrCahHBa
UTQZFxcbJSUzU9jWytqCM1Pa/OTbbwoTBBEFCAUeFCMkWNrX1adaxO716urq6urq6urq6urq6urq
6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq
6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ujo6Ojo6Ojo6Ojo6urq6urq6urq6ODg
1byqnZaWo5iYmJiampqlmqaamL/Z4+Hbp1Jt2/v8wmwODxERHh4iFhxqw9fQ59Xb19Lq6urq6urq
6urq6urq6urq6urq6urq6urq6urq6urq6Orq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq
6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ujo6Ojo6Ojo6Ojo6urq
6urq6urq6OLi4O7w8OLu4O7u4OHn5dLS0uXs7e3t7eTk4NqDhr/j/PSVVjcbHCdPaaz06ObX6Pz7
7e3q6urq6urq6urq6urq6urq6urq6urq6urq6urq6ujo6Orq6urq6urq6urq6urq6urq6urq6urq
6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq
6urq6urq6urq6urq6urq6uLi4u7u7u7g4uLi4dfX19fX3u3k6Ojn8vLq5fDXwrrW9OLy2MO+rr7D
2+Xs7Or78uvq9vTq6urq6urq6urq6urq6urq6urq6urq6urq6urq6ujq9erq6urq6urq6urq6urq
6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq6urq
6urq6urq6urq6urq6urq6urq6urq6urq6vj4+Pj4+Pf3+Pr6+Pn5+fr6+vf39/f39/f3+Pj7+fn0
9vf4+Pj6+Pr4+Pj1+Pf59/f39/f4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4
+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4
+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+A==

------=_NextPart_000_0019_01C5FCD0.D0BAD730--




--===============1171086160==
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

--===============1171086160==--






From simple-bounces@ietf.org Fri Dec 09 10:42:01 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkkNl-00052c-EB; Fri, 09 Dec 2005 10:42:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EkkNk-000521-NZ
	for simple@megatron.ietf.org; Fri, 09 Dec 2005 10:42:00 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20661
	for <simple@ietf.org>; Fri, 9 Dec 2005 10:41:07 -0500 (EST)
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkkNn-0008Jd-BR
	for simple@ietf.org; Fri, 09 Dec 2005 10:42:14 -0500
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 32492F5B
	for <simple@ietf.org>; Fri,  9 Dec 2005 16:41:37 +0100 (CET)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 9 Dec 2005 16:41:20 +0100
Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 9 Dec 2005 16:41:20 +0100
Received: from 147.214.118.125 ([147.214.118.125]) by
	esealmw105.eemea.ericsson.se ([153.88.200.68]) via Exchange
	Front-End Server mail.eemea.ericsson.se ([153.88.254.169]) with
	Microsoft Exchange Server HTTP-DAV ; Fri,  9 Dec 2005 15:39:28 +0000
Received: from Caliope by mail.eemea.ericsson.se; 09 Dec 2005 16:41:18 +0100
From: Ignacio =?ISO-8859-1?Q?M=E1s?= "Ivars (KI/EAB)"
	<ignacio.mas.ivars@ericsson.com>
To: simple@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Organization: Ericsson Research
Date: Fri, 09 Dec 2005 16:41:18 +0100
Message-Id: <1134142878.4741.21.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.5.2 
X-OriginalArrivalTime: 09 Dec 2005 15:41:20.0511 (UTC)
	FILETIME=[006B08F0:01C5FCD7]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Content-Transfer-Encoding: quoted-printable
Subject: [Simple] [MSRP v12] Interrupting a SEND of the *same* MSRP session
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org


Hi all!

Reading carefully the latest draft of MSRP we have some small doubts
about the chunking mechanism. The draft says that any message over 2048
octects should be interruptible "to allow multiple MSRP sessions to
share a TCP connection, and for large messages to be sent efficiently
while not blocking other messages that share the same connection."

I understand the previous paragraph in the following way: one MSRP
session starts sending a large file and another MSRP session using the
same TCP connection is able to interrupt the SEND and interleave its
messages... but what if we have *one* single MSRP session, we start to
send a large file and we want to interleave a text message? Can the MSRP
session that started the file send interrupt itself to send another
message and then continue? This is the way I interpret it, but I would
like a confirmation from the group.

It could be good to clarify the paragraph, perhaps adding "...while not
blocking other messages that share the same connection, or even the same
MSRP session"...

Thanks for the help!
/Ignacio


--=20
Ignacio M=E1s Ivars
Service enablers and protocols, Ericsson Research (EAB/TBG/B)
Ericsson AB                     Phone: +46 8 4045580
Torshamsgatan 23                Fax:   +46 8 4049500
SE-164 80 Stockholm, Sweden     mailto: ignacio.mas.ivars@ericsson.com

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



From simple-bounces@ietf.org Mon Dec 12 13:03:12 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Els12-0001Yw-C6; Mon, 12 Dec 2005 13:03:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Els0z-0001YB-AD
	for simple@megatron.ietf.org; Mon, 12 Dec 2005 13:03:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24416
	for <simple@ietf.org>; Mon, 12 Dec 2005 13:02:05 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Els1g-0005Pe-Ih
	for simple@ietf.org; Mon, 12 Dec 2005 13:03:53 -0500
Received: from sj-core-3.cisco.com ([171.68.223.137])
	by sj-iport-4.cisco.com with ESMTP; 12 Dec 2005 10:02:51 -0800
Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com
	[171.70.93.57])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jBCI2mMe018906;
	Mon, 12 Dec 2005 10:02:49 -0800 (PST)
Received: from 10.21.89.0 ([10.21.89.0]) by vtg-um-e2k4.sj21ad.cisco.com
	([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; 
	Mon, 12 Dec 2005 18:02:48 +0000
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Mon, 12 Dec 2005 10:02:55 -0800
Subject: Re: [Simple] [MSRP v12] Interrupting a SEND of the *same* MSRP session
From: Cullen Jennings <fluffy@cisco.com>
To: "Ivars (KI/EAB) Ignacio M=?ISO-8859-1?B?4Q==?=s"
	<ignacio.mas.ivars@ericsson.com>, "simple@ietf.org" <simple@ietf.org>
Message-ID: <BFC2FB4F.64B50%fluffy@cisco.com>
Thread-Topic: [Simple] [MSRP v12] Interrupting a SEND of the *same* MSRP
	session
Thread-Index: AcX/RkbEhZyizms5EdqiaQARJEEJ/A==
In-Reply-To: <1134142878.4741.21.camel@localhost.localdomain>
Mime-version: 1.0
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Content-Transfer-Encoding: quoted-printable
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

On 12/9/05 7:41 AM, "Ivars (KI/EAB) Ignacio M=E1s"
<ignacio.mas.ivars@ericsson.com> wrote:

>=20
> Hi all!
>=20
> Reading carefully the latest draft of MSRP we have some small doubts
> about the chunking mechanism. The draft says that any message over 2048
> octects should be interruptible "to allow multiple MSRP sessions to
> share a TCP connection, and for large messages to be sent efficiently
> while not blocking other messages that share the same connection."
>=20
> I understand the previous paragraph in the following way: one MSRP
> session starts sending a large file and another MSRP session using the
> same TCP connection is able to interrupt the SEND and interleave its
> messages... but what if we have *one* single MSRP session, we start to
> send a large file and we want to interleave a text message? Can the MSRP
> session that started the file send interrupt itself to send another
> message and then continue? This is the way I interpret it, but I would
> like a confirmation from the group.

yes - your understanding is correct.

>=20
> It could be good to clarify the paragraph, perhaps adding "...while not
> blocking other messages that share the same connection, or even the same
> MSRP session"...

Sounds good - I made this change and the net version will have it.

Thanks.

>=20
> Thanks for the help!
> /Ignacio
>=20

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



From simple-bounces@ietf.org Mon Dec 12 13:09:13 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Els6r-0002sd-GP; Mon, 12 Dec 2005 13:09:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Els6p-0002s2-H6
	for simple@megatron.ietf.org; Mon, 12 Dec 2005 13:09:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25017
	for <simple@ietf.org>; Mon, 12 Dec 2005 13:08:15 -0500 (EST)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Els7e-0005b1-QW
	for simple@ietf.org; Mon, 12 Dec 2005 13:10:04 -0500
Received: from sj-core-3.cisco.com ([171.68.223.137])
	by sj-iport-5.cisco.com with ESMTP; 12 Dec 2005 10:09:01 -0800
X-IronPort-AV: i="3.99,244,1131350400"; 
	d="scan'208"; a="240052678:sNHT30953984"
Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com
	[171.70.93.57])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jBCI8wMe020506;
	Mon, 12 Dec 2005 10:08:59 -0800 (PST)
Received: from 10.21.89.0 ([10.21.89.0]) by vtg-um-e2k4.sj21ad.cisco.com
	([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; 
	Mon, 12 Dec 2005 18:08:58 +0000
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Mon, 12 Dec 2005 10:09:06 -0800
Subject: Re: [Simple] IMDN Issue #1: Security of IMDN
From: Cullen Jennings <fluffy@cisco.com>
To: Eric Burger <eburger@brooktrout.com>, "simple@ietf.org" <simple@ietf.org>
Message-ID: <BFC2FCC2.64B53%fluffy@cisco.com>
Thread-Topic: [Simple] IMDN Issue #1: Security of IMDN
Thread-Index: AcX5ygqNRz99IFFbS4ezLwACE5TCZgFfRlYm
In-Reply-To: <330A23D8336C0346B5C1A5BB1966664701B8D4E8@ATLANTIS.Brooktrout.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: 7bit
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

On 12/5/05 10:31 AM, "Burger, Eric" <eburger@brooktrout.com> wrote:

> Proposal is that if the body of the message was encrypted or signed, the
> IMDN MUST be encrypted or signed, otherwise it MAY be plain text.
> 
> Any dissent?

If the IMDN was only signed, but the original message was encrypted, would
the IMDN reveal anything that was not in the unencrypted portion of the
message?

This proposal does seem a little weird - what happens if you can't sign the
IMDN?

Perhaps we might want something like the following 3 rules

Always sign the IMDN if you have a cert.

If the message was singed and encrypted, MUST encrypt repose.

If the message was encrypted, MUST sign IMDN.








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



From simple-bounces@ietf.org Mon Dec 12 13:28:21 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ElsPN-0007kU-KJ; Mon, 12 Dec 2005 13:28:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ElsPM-0007jO-1h
	for simple@megatron.ietf.org; Mon, 12 Dec 2005 13:28:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27548
	for <simple@ietf.org>; Mon, 12 Dec 2005 13:27:24 -0500 (EST)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ElsQB-0006Ji-DK
	for simple@ietf.org; Mon, 12 Dec 2005 13:29:12 -0500
Received: from sj-core-4.cisco.com ([171.68.223.138])
	by sj-iport-5.cisco.com with ESMTP; 12 Dec 2005 10:28:10 -0800
X-IronPort-AV: i="3.99,244,1131350400"; 
	d="scan'208"; a="240057604:sNHT1111519396"
Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com
	[171.70.93.57])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jBCIS4ph013282;
	Mon, 12 Dec 2005 10:28:07 -0800 (PST)
Received: from 10.21.89.0 ([10.21.89.0]) by vtg-um-e2k4.sj21ad.cisco.com
	([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; 
	Mon, 12 Dec 2005 18:28:06 +0000
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Mon, 12 Dec 2005 10:28:14 -0800
From: Cullen Jennings <fluffy@cisco.com>
To: Hisham Khartabil <hisham.khartabil@telio.no>
Message-ID: <BFC3013E.64B60%fluffy@cisco.com>
Thread-Topic: Addition to security section draft-ietf-simple-message-sessions
Thread-Index: AcX/SdApDrxpYWs9EdqiaQARJEEJ/A==
In-Reply-To: <f26eec054347827ce945e241ce535566@telio.no>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
Content-Transfer-Encoding: 7bit
Cc: "simple@ietf.org" <simple@ietf.org>
Subject: [Simple] Re: Addition to security section
 draft-ietf-simple-message-sessions
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org


Thanks - Made both theses changes in next version of document.


On 11/28/05 1:44 AM, "Hisham Khartabil" <hisham.khartabil@telio.no> wrote:

> 
> On Nov 26, 2005, at 7:26 PM, Cullen Jennings wrote:
> 
>> 
>> During a review of this draft by a security AD, we got feedback that we
>> needed to add more about how to use TLS where there was no relays. I am
>> proposing we add an additional section 14.3 with some proposed text
>> below.
>> If you want to see this in the context of the draft, you can look at
>> what it
>> might look like at:
>> 
>> http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple-
>> message-s
>> essions.html
>> 
>> http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple-
>> message-s
>> essions.txt
>> 
>> The text I am proposing to add is ....
>> 
>> 14.3.  Using TLS in Peer to Peer Mode
>> 
>> TLS can be used with a self signed certificate as long as there is a
>> mechanism for both sides to ascertain that the other side used the
>> correct
>> certificate.  When used with SDP and SIP, the correct certificate can
>> be
>> verified by passing a fingerprint of the certificate in the SDP and
>> ensuring
>> that the SDP has suitable integrity protection.  When SIP is used to
>> transport the SDP, the integrity can be provided by the SIP Identity
>> mechanism.  The rest of this section describes the details of this
>> approach.
>> 
>> If self-signed certificates are used, the content of the subjectAltName
>> attribute inside the certificate MAY use the uniform resource
>> identifier
>> (URI) of the user.
> 
> 
> Can you make it clear here that you are talking about the AoR?
> 
>>   This is useful for debugging purposes only and is not
>> required to bind the certificate to one of the communication
>> endpoints.  The
>> subjectAltName is not an important component of the certificate
>> verification.  If the endpoint is also able to make anonymous
>> sessions, a
>> distinct, unique certificate MUST be used for this purpose.  For an
>> client
>> that works with multiple users, each user SHOULD have its own
>> certificate.
>> The generation of public/private key pairs is relatively expensive.
>> Endpoints are not required to generate certificates for each session.
>> 
>> A certificate fingerprint is the output of a one-way hash function
>> computed
>> over the distinguished encoding rules (DER) form of the certificate.
>> The
>> endpoint MUST use the certificate fingerprint attribute as specified
>> in [23]
>> and MUST include this in the SDP.
> 
> 
> A bit more text on how to include it in SDP would be good. Example
> would be great.
> 
> Thanks,
> Hisham
> 
>> The certificate presented during the TLS
>> handshake needs to match the fingerprint exchanged via the SDP and if
>> the
>> fingerprint does not match the hashed certificate then the endpoint
>> MUST
>> tear down the media session immediately.
>> 
>> When using SIP, the integrity of the fingerprint can be ensured
>> through the
>> SIP Identity mechanism [22].  When a client wishes to use SIP to set
>> up a
>> secure MSRP session with another endpoint it sends an offer in a SIP
>> message
>> to the other endpoint.  This offer includes, as part of the SDP
>> payload, the
>> fingerprint of the certificate that the endpoint wants to use.  The SIP
>> message containing the offer is sent to the offerer's sip proxy which
>> will
>> add an identity header according to the procedures outlined in [22].
>> When
>> the far endpoint receives the SIP message it can verify the identity
>> of the
>> sender using the identity header.  Since the identity header is a
>> digital
>> signature across several SIP headers, in addition to the body or
>> bodies of
>> the SIP message, the receiver can also be certain that the message has
>> not
>> been tampered with after the digital signature was added to the SIP
>> message.
>> 

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



From simple-bounces@ietf.org Mon Dec 12 18:50:54 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ElxRW-00033b-7y; Mon, 12 Dec 2005 18:50:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ElxRV-00033S-8L
	for simple@megatron.ietf.org; Mon, 12 Dec 2005 18:50:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15776
	for <simple@ietf.org>; Mon, 12 Dec 2005 18:49:41 -0500 (EST)
Received: from mxgate1.brooktrout.com ([204.176.74.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ElxS9-0003Zw-3V
	for simple@ietf.org; Mon, 12 Dec 2005 18:51:34 -0500
X-IronPort-AV: i="3.99,245,1131339600"; 
	d="scan'208"; a="24073248:sNHT42891624"
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] IMDN Issue #1: Security of IMDN
Date: Mon, 12 Dec 2005 18:50:31 -0500
Message-ID: <330A23D8336C0346B5C1A5BB1966664701C7D74A@ATLANTIS.Brooktrout.com>
Thread-Topic: [Simple] IMDN Issue #1: Security of IMDN
Thread-Index: AcX5ygqNRz99IFFbS4ezLwACE5TCZgFfRlYmAAgUujA=
From: "Burger, Eric" <eburger@brooktrout.com>
To: "Cullen Jennings" <fluffy@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Content-Transfer-Encoding: quoted-printable
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

How about:

1. If UAS has a certificate, MUST sign IMDN.

2. If message was encrypted, MUST encrypt IMDN.  Doesn't encrypting
cover signing?  If not, to encrypt, need cert, so see rule 1.
=20
-----Original Message-----
From: Cullen Jennings [mailto:fluffy@cisco.com]=20
Sent: Monday, December 12, 2005 1:09 PM
To: Burger, Eric; simple@ietf.org
Subject: Re: [Simple] IMDN Issue #1: Security of IMDN

On 12/5/05 10:31 AM, "Burger, Eric" <eburger@brooktrout.com> wrote:

> Proposal is that if the body of the message was encrypted or signed,
the
> IMDN MUST be encrypted or signed, otherwise it MAY be plain text.
>=20
> Any dissent?

If the IMDN was only signed, but the original message was encrypted,
would
the IMDN reveal anything that was not in the unencrypted portion of the
message?

This proposal does seem a little weird - what happens if you can't sign
the
IMDN?

Perhaps we might want something like the following 3 rules

Always sign the IMDN if you have a cert.

If the message was singed and encrypted, MUST encrypt repose.

If the message was encrypted, MUST sign IMDN.






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



From simple-bounces@ietf.org Tue Dec 13 07:42:43 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Em9UR-0002Q7-Pg; Tue, 13 Dec 2005 07:42:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Em9UQ-0002P9-59
	for simple@megatron.ietf.org; Tue, 13 Dec 2005 07:42:42 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17197
	for <simple@ietf.org>; Tue, 13 Dec 2005 07:41:45 -0500 (EST)
Received: from mgw-ext03.nokia.com ([131.228.20.95])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Em9VP-0006Xg-Hd
	for simple@ietf.org; Tue, 13 Dec 2005 07:43:44 -0500
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213])
	by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	jBDCcwXw027791; Tue, 13 Dec 2005 14:39:01 +0200
Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by
	esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 13 Dec 2005 14:42:08 +0200
Received: from [10.162.253.176] ([10.162.253.176]) by esebh001.NOE.Nokia.com
	with Microsoft SMTPSVC(5.0.2195.6881); 
	Tue, 13 Dec 2005 14:42:07 +0200
Message-ID: <439EC19E.2050504@nokia.com>
Date: Tue, 13 Dec 2005 14:42:06 +0200
From: Aki Niemi <aki.niemi@nokia.com>
User-Agent: Thunderbird 1.5 (X11/20051025)
MIME-Version: 1.0
To: ext Cullen Jennings <fluffy@cisco.com>
Subject: Re: [Simple] Re: Addition to security section
	draft-ietf-simple-message-sessions
References: <BFC3013E.64B60%fluffy@cisco.com>
In-Reply-To: <BFC3013E.64B60%fluffy@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 13 Dec 2005 12:42:07.0920 (UTC)
	FILETIME=[A106DB00:01C5FFE2]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab
Content-Transfer-Encoding: 7bit
Cc: "simple@ietf.org" <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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

I took a look at the version with the added text. First of all, the 
fingerprint SDP attribute is not defined anywhere in the document. It 
should.

Second, seems to me that sdescriptions would be the correct place to 
negotiate any security related data like the cert fingerprint in SDP; I 
don't understand why MSRP has to (again) invent its own mechanism. Then 
again, if the described mechanism works, I guess it is ok...

Also, I'd like the text to at least mention, that there are other 
ciphersuites available in TLS that could potentially be used with MSRP. 
For example, ciphersuites defined in RFC 4279 come to mind as something 
worth exploring along with sdescriptions, or MIKEY perhaps. (This should 
be its own specification, though.) I can propose some text, too, if 
you'd like.

Last (but not least), seems like e2e TLS is only possible when there are 
no relays, right? Then, doesn't that mean that NAT/FW traversal and e2e 
security don't work together? Doesn't that really suck, if you have to 
choose one or the other?

Cheers,
Aki

ext Cullen Jennings wrote:
> Thanks - Made both theses changes in next version of document.
> 
> 
> On 11/28/05 1:44 AM, "Hisham Khartabil" <hisham.khartabil@telio.no> wrote:
> 
>> On Nov 26, 2005, at 7:26 PM, Cullen Jennings wrote:
>>
>>> During a review of this draft by a security AD, we got feedback that we
>>> needed to add more about how to use TLS where there was no relays. I am
>>> proposing we add an additional section 14.3 with some proposed text
>>> below.
>>> If you want to see this in the context of the draft, you can look at
>>> what it
>>> might look like at:
>>>
>>> http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple-
>>> message-s
>>> essions.html
>>>
>>> http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple-
>>> message-s
>>> essions.txt
>>>
>>> The text I am proposing to add is ....
>>>
>>> 14.3.  Using TLS in Peer to Peer Mode
>>>
>>> TLS can be used with a self signed certificate as long as there is a
>>> mechanism for both sides to ascertain that the other side used the
>>> correct
>>> certificate.  When used with SDP and SIP, the correct certificate can
>>> be
>>> verified by passing a fingerprint of the certificate in the SDP and
>>> ensuring
>>> that the SDP has suitable integrity protection.  When SIP is used to
>>> transport the SDP, the integrity can be provided by the SIP Identity
>>> mechanism.  The rest of this section describes the details of this
>>> approach.
>>>
>>> If self-signed certificates are used, the content of the subjectAltName
>>> attribute inside the certificate MAY use the uniform resource
>>> identifier
>>> (URI) of the user.
>>
>> Can you make it clear here that you are talking about the AoR?
>>
>>>   This is useful for debugging purposes only and is not
>>> required to bind the certificate to one of the communication
>>> endpoints.  The
>>> subjectAltName is not an important component of the certificate
>>> verification.  If the endpoint is also able to make anonymous
>>> sessions, a
>>> distinct, unique certificate MUST be used for this purpose.  For an
>>> client
>>> that works with multiple users, each user SHOULD have its own
>>> certificate.
>>> The generation of public/private key pairs is relatively expensive.
>>> Endpoints are not required to generate certificates for each session.
>>>
>>> A certificate fingerprint is the output of a one-way hash function
>>> computed
>>> over the distinguished encoding rules (DER) form of the certificate.
>>> The
>>> endpoint MUST use the certificate fingerprint attribute as specified
>>> in [23]
>>> and MUST include this in the SDP.
>>
>> A bit more text on how to include it in SDP would be good. Example
>> would be great.
>>
>> Thanks,
>> Hisham
>>
>>> The certificate presented during the TLS
>>> handshake needs to match the fingerprint exchanged via the SDP and if
>>> the
>>> fingerprint does not match the hashed certificate then the endpoint
>>> MUST
>>> tear down the media session immediately.
>>>
>>> When using SIP, the integrity of the fingerprint can be ensured
>>> through the
>>> SIP Identity mechanism [22].  When a client wishes to use SIP to set
>>> up a
>>> secure MSRP session with another endpoint it sends an offer in a SIP
>>> message
>>> to the other endpoint.  This offer includes, as part of the SDP
>>> payload, the
>>> fingerprint of the certificate that the endpoint wants to use.  The SIP
>>> message containing the offer is sent to the offerer's sip proxy which
>>> will
>>> add an identity header according to the procedures outlined in [22].
>>> When
>>> the far endpoint receives the SIP message it can verify the identity
>>> of the
>>> sender using the identity header.  Since the identity header is a
>>> digital
>>> signature across several SIP headers, in addition to the body or
>>> bodies of
>>> the SIP message, the receiver can also be certain that the message has
>>> not
>>> been tampered with after the digital signature was added to the SIP
>>> message.
>>>
> 
> _______________________________________________
> 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 Tue Dec 13 11:09:48 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EmCiq-0004kz-JX; Tue, 13 Dec 2005 11:09:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EmCip-0004kr-7m
	for simple@megatron.ietf.org; Tue, 13 Dec 2005 11:09:47 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14358
	for <simple@ietf.org>; Tue, 13 Dec 2005 11:08:49 -0500 (EST)
Received: from rwcrmhc14.comcast.net ([216.148.227.89]
	helo=rwcrmhc12.comcast.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmCjq-00060T-8w
	for simple@ietf.org; Tue, 13 Dec 2005 11:10:51 -0500
Received: from s73602 (unknown[65.104.224.98])
	by comcast.net (rwcrmhc14) with SMTP
	id <20051213160932014007ssp1e>; Tue, 13 Dec 2005 16:09:32 +0000
Message-ID: <04b701c5ffff$7a5d10b0$4e087c0a@china.huawei.com>
From: "Spencer Dawkins" <spencer@mcsr-labs.org>
To: <simple@ietf.org>
References: <BFC3013E.64B60%fluffy@cisco.com> <439EC19E.2050504@nokia.com>
Subject: Re: [Simple] Re: Addition to security
	sectiondraft-ietf-simple-message-sessions
Date: Tue, 13 Dec 2005 10:08:37 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Content-Transfer-Encoding: 7bit
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

> Last (but not least), seems like e2e TLS is only possible when there are 
> no relays, right? Then, doesn't that mean that NAT/FW traversal and e2e 
> security don't work together? Doesn't that really suck, if you have to 
> choose one or the other?

This is a principle worthy of the IETF :-) Thanks, Aki, for sending it!

Spencer

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



From simple-bounces@ietf.org Tue Dec 13 12:04:48 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EmDa4-0001Ha-5H; Tue, 13 Dec 2005 12:04:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EmDa2-0001Fd-P0
	for simple@megatron.ietf.org; Tue, 13 Dec 2005 12:04:46 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21206
	for <simple@ietf.org>; Tue, 13 Dec 2005 12:03:44 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmDay-00080a-NS
	for simple@ietf.org; Tue, 13 Dec 2005 12:05:46 -0500
Received: from [172.17.2.252] (dsl001-129-069.dfw1.dsl.speakeasy.net
	[72.1.129.69]) (authenticated bits=0)
	by nostrum.com (8.12.11/8.12.11) with ESMTP id jBDH4JNf047477
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Tue, 13 Dec 2005 11:04:21 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
In-Reply-To: <04b701c5ffff$7a5d10b0$4e087c0a@china.huawei.com>
References: <BFC3013E.64B60%fluffy@cisco.com> <439EC19E.2050504@nokia.com>
	<04b701c5ffff$7a5d10b0$4e087c0a@china.huawei.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
X-Priority: 3
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <28ADC0ED-D4E4-45B4-8EE3-7140E58C0AF8@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [Simple] Re: Addition to security
	sectiondraft-ietf-simple-message-sessions
Date: Tue, 13 Dec 2005 11:04:18 -0600
To: Spencer Dawkins <spencer@mcsr-labs.org>
X-Mailer: Apple Mail (2.746.2)
Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted
	mechanism)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: 7bit
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Of _course_ TLS only gives us e2e when there are not intermediaries  
terminating the TLS relationship.
This additional section of text is describing how you can use TLS to  
your advantage in exactly that case.
It is not defining a new e2e mechanism for the draft, nor is it  
claiming this is the only e2e mechanism
available.

 From elsewhere in the document:

    Since MSRP carries arbitrary MIME content, it can trivially carry
    S/MIME protected messages as well.  All MSRP implementations MUST
    support the multipart/signed MIME type even if they do not support
    S/MIME.  Since SIP can carry a session key, S/MIME messages in the
    context of a session could also be protected using a key-wrapped
    shared secret [26] provided in the session setup.  MSRP is a binary
    protocol and MIME bodies MUST be transferred with a transfer  
encoding
    of binary.  If a message is both signed and encrypted, it SHOULD be
    signed first, then encrypted.  If S/MIME is supported, SHA-1, RSA,
    and AES-128 MUST be supported.



On Dec 13, 2005, at 10:08 AM, Spencer Dawkins wrote:

>> Last (but not least), seems like e2e TLS is only possible when  
>> there are no relays, right? Then, doesn't that mean that NAT/FW  
>> traversal and e2e security don't work together? Doesn't that  
>> really suck, if you have to choose one or the other?
>
> This is a principle worthy of the IETF :-) Thanks, Aki, for sending  
> it!
>
> Spencer
>
> _______________________________________________
> 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 Wed Dec 14 02:13:36 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EmQpU-0008MV-CB; Wed, 14 Dec 2005 02:13:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EmIcO-0006lH-Ur
	for simple@megatron.ietf.org; Tue, 13 Dec 2005 17:27:35 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08434
	for <simple@ietf.org>; Tue, 13 Dec 2005 17:26:27 -0500 (EST)
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 1EmIdL-0005On-O2
	for simple@ietf.org; Tue, 13 Dec 2005 17:28:32 -0500
Received: from [172.17.2.252] ([172.17.2.252]) (authenticated bits=0)
	by vicuna.estacado.net (8.13.3/8.13.3) with ESMTP id jBDMR7BO084669
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Tue, 13 Dec 2005 16:27:08 -0600 (CST)
	(envelope-from rjsparks@estacado.net)
In-Reply-To: <1134045864.3349.4.camel@w189.nomadiclab.com>
References: <1134021749.3365.4.camel@n121.nomadiclab.com>
	<1134045864.3349.4.camel@w189.nomadiclab.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <0F6CC4AF-6F41-43F6-B7A8-AC690E4ED0AC@estacado.net>
Content-Transfer-Encoding: 7bit
From: Robert Sparks <rjsparks@estacado.net>
Date: Tue, 13 Dec 2005 16:27:06 -0600
To: Salvatore Loreto (JO/LMF) <salvatore.loreto@ericsson.com>
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Wed, 14 Dec 2005 02:13:34 -0500
Cc: Robert Sparks <RjS@estacado.net>, "simple@ietf.org list" <simple@ietf.org>
Subject: [Simple] Re: simple-xcap in rfc editor queue
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

The plan is still for it to come off the queue. The gears are turning...

If you haven't seen them already, the minutes capturing the plan are at

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

On Dec 8, 2005, at 6:44 AM, Salvatore Loreto (JO/LMF) wrote:

> Hi all,
>
> I've just checked and the draft draft-ietf-simple-xcap is still in
> RFC-Editor's Queue.
>
> When it'll be removed?
> Or in other way what is the right process, or the process does the wg
> want follow in this case?
>
> thank you
> Sal
>


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



From simple-bounces@ietf.org Wed Dec 14 05:53:39 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EmUGQ-0006gk-W6; Wed, 14 Dec 2005 05:53:39 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EmUGO-0006gY-D5
	for simple@megatron.ietf.org; Wed, 14 Dec 2005 05:53:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04602
	for <simple@ietf.org>; Wed, 14 Dec 2005 05:52:38 -0500 (EST)
From: Amitkumar.Goel@infineon.com
Received: from smtp3.infineon.com ([203.126.106.229])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmUHW-0000Zs-Mm
	for simple@ietf.org; Wed, 14 Dec 2005 05:54:50 -0500
Received: from unknown (HELO sinse212.ap.infineon.com) ([172.17.65.148])
	by smtp3.infineon.com with ESMTP; 14 Dec 2005 18:52:55 +0800
X-SBRS: None
Received: from blrse201.ap.infineon.com ([172.20.20.12]) by
	sinse212.ap.infineon.com over TLS secured channel with
	Microsoft SMTPSVC(5.0.2195.6713); Wed, 14 Dec 2005 18:52:54 +0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 14 Dec 2005 16:22:53 +0530
Message-ID: <D99246B510C34944823191CB90759C8602AC9F19@blrse201.ap.infineon.com>
Thread-Topic: Multiple Media in MSRP SEND Request
Thread-Index: AcYAnIhq01hcwOcoTbKdx3BOVynOHA==
To: <simple@ietf.org>
X-OriginalArrivalTime: 14 Dec 2005 10:52:54.0657 (UTC)
	FILETIME=[89640710:01C6009C]
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Subject: [Simple] Multiple Media in MSRP SEND 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>
Content-Type: multipart/mixed; boundary="===============0817343261=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0817343261==
content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C6009C.8871706F"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6009C.8871706F
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi All,
=20
I am going through the draft-ietf-simple-message-sessions-11.txt and
other related documents. I have one doubt. Is it possible to send
multiple media in a same message? Suppose I am exchanging text messages
to my friend  by using MSRP session. At some point of time I also want
to send some Audio along with the text message.=20
Is this scenario possible in MSRP session messaging? If yes, how will
user create the SEND request?
=20
Regards,
Amit Kumar Goel
Infineon Technology,
11th Floor, Discoverer Building,
Whitefield,ITPL,
Bangalore-560066
Ph: +91(080)41392721
Mobile:9448948977
=20

------_=_NextPart_001_01C6009C.8871706F
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1515" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D751344310-14122005><FONT face=3DArial size=3D2>Hi=20
All,</FONT></SPAN></DIV>
<DIV><SPAN class=3D751344310-14122005><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D751344310-14122005><FONT face=3DArial size=3D2>I am =
going through=20
the <SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: =
AR-SA">draft-ietf-simple-message-sessions-11.txt=20
and other related documents. I have one doubt. Is it possible to send =
multiple=20
media in a same message? Suppose I am&nbsp;exchanging&nbsp;text messages =

to&nbsp;my friend&nbsp; by&nbsp;using&nbsp;MSRP session.&nbsp;At some =
point of=20
time I also want to send some Audio&nbsp;along with the text message.=20
</SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=3D751344310-14122005><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Is=20
this scenario&nbsp;possible&nbsp;in MSRP session messaging?&nbsp;If yes, =
how=20
will user create the SEND request?</SPAN></FONT></SPAN></DIV>
<DIV><SPAN lang=3Den-us><FONT face=3DArial size=3D2><FONT=20
size=3D2></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN lang=3Den-us><FONT face=3DArial size=3D2><FONT =
size=3D2>Regards,<BR>Amit=20
Kumar Goel<BR>Infineon Technology,<BR>11th Floor, Discoverer=20
Building,<BR>Whitefield,ITPL,<BR>Bangalore-560066<BR>Ph:=20
+91(080)41392721<BR>Mobile:9448948977</DIV></FONT></FONT></SPAN>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C6009C.8871706F--


--===============0817343261==
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

--===============0817343261==--




From simple-bounces@ietf.org Wed Dec 14 07:50:29 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EmW5V-0003w4-GI; Wed, 14 Dec 2005 07:50:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EmW5T-0003vX-Fa
	for simple@megatron.ietf.org; Wed, 14 Dec 2005 07:50:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18876
	for <simple@ietf.org>; Wed, 14 Dec 2005 07:49:28 -0500 (EST)
Received: from zproxy.gmail.com ([64.233.162.192])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmW6e-0004tO-O9
	for simple@ietf.org; Wed, 14 Dec 2005 07:51:42 -0500
Received: by zproxy.gmail.com with SMTP id v1so108660nzb
	for <simple@ietf.org>; Wed, 14 Dec 2005 04:50:22 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
	b=rRTN46EF0R7m6PJAesrSv2QN+sDvTxf98/UafGPRk+SmLAzgBTmXFV6a03cvcVxbsuWFs0ZoHvS9kJPjPyKTtpPJYU8grmwB0cBN5HzaE2smV7Ug5CXF16wVYhORWx4a80VY/0ano35OZmbOY7PdipgWE0Rf+NrpywjoWwkr03o=
Received: by 10.65.119.13 with SMTP id w13mr364411qbm;
	Wed, 14 Dec 2005 04:50:21 -0800 (PST)
Received: by 10.65.236.15 with HTTP; Wed, 14 Dec 2005 04:50:21 -0800 (PST)
Message-ID: <22e3bb730512140450i517e163bm8f7e2fa50748f98e@mail.gmail.com>
Date: Wed, 14 Dec 2005 18:20:21 +0530
From: Vinod Joseph <vinod.joe@gmail.com>
To: simple@ietf.org
Subject: Re: [Simple] Multiple Media in MSRP SEND Request
In-Reply-To: <D99246B510C34944823191CB90759C8602AC9F19@blrse201.ap.infineon.com>
MIME-Version: 1.0
References: <D99246B510C34944823191CB90759C8602AC9F19@blrse201.ap.infineon.com>
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
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="===============0498931789=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

--===============0498931789==
Content-Type: multipart/alternative; 
	boundary="----=_Part_31758_18216149.1134564621848"

------=_Part_31758_18216149.1134564621848
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

SIP provides the opportunity for multiple media types in a single session o=
r
in related sessions to stay together, if that is what is desired.



On 12/14/05, Amitkumar.Goel@infineon.com <Amitkumar.Goel@infineon.com>
wrote:
>
> Hi All,
>
> I am going through the draft-ietf-simple-message-sessions-11.txt and othe=
r
> related documents. I have one doubt. Is it possible to send multiple medi=
a
> in a same message? Suppose I am exchanging text messages to my friend
> by using MSRP session. At some point of time I also want to send some
> Audio along with the text message.
> Is this scenario possible in MSRP session messaging? If yes, how will use=
r
> create the SEND request?
>
> Regards,
> Amit Kumar Goel
> Infineon Technology,
> 11th Floor, Discoverer Building,
> Whitefield,ITPL,
> Bangalore-560066
> Ph: +91(080)41392721
> Mobile:9448948977
>
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
>
>
>


--
Vinod Cherian Joseph
SISO

------=_Part_31758_18216149.1134564621848
Content-Type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<div><br>SIP provides the opportunity for multiple media types in a&nbsp;si=
ngle session or in related sessions to stay together, if that is&nbsp;what =
is desired.</div>
<div>&nbsp;</div>
<div><br>&nbsp;</div>
<div><span class=3D"gmail_quote">On 12/14/05, <b class=3D"gmail_sendername"=
><a href=3D"mailto:Amitkumar.Goel@infineon.com">Amitkumar.Goel@infineon.com=
</a></b> &lt;<a href=3D"mailto:Amitkumar.Goel@infineon.com">Amitkumar.Goel@=
infineon.com
</a>&gt; wrote:</span>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div><span><font face=3D"Arial" size=3D"2">Hi All,</font></span></div>
<div><span><font face=3D"Arial" size=3D"2"></font></span>&nbsp;</div>
<div><span><font face=3D"Arial" size=3D"2">I am going through the <span sty=
le=3D"FONT-SIZE: 12pt">draft-ietf-simple-message-sessions-11.txt and other =
related documents. I have one doubt. Is it possible to send multiple media =
in a same message? Suppose I am&nbsp;exchanging&nbsp;text messages to&nbsp;=
my friend&nbsp; by&nbsp;using&nbsp;MSRP session.&nbsp;At some point of time=
 I also want to send some Audio&nbsp;along with the text message.=20
</span></font></span></div>
<div><span><font face=3D"Arial" size=3D"2"><span style=3D"FONT-SIZE: 12pt">=
Is this scenario&nbsp;possible&nbsp;in MSRP session messaging?&nbsp;If yes,=
 how will user create the SEND request?</span></font></span></div>
<div><span lang=3D"en-us"><font face=3D"Arial" size=3D"2"><font size=3D"2">=
</font></font></span>&nbsp;</div>
<div><span lang=3D"en-us"><font face=3D"Arial" size=3D"2"><font size=3D"2">=
Regards,<br>Amit Kumar Goel<br>Infineon Technology,<br>11th Floor, Discover=
er Building,<br>Whitefield,ITPL,<br>Bangalore-560066<br>Ph: +91(080)4139272=
1<br>
Mobile:9448948977</font></font></span></div>
<div><font face=3D"Arial" size=3D"2"></font>&nbsp;</div><br>_______________=
________________________________<br>Simple mailing list<br><a onclick=3D"re=
turn top.js.OpenExtLink(window,event,this)" href=3D"mailto:Simple@ietf.org"=
>Simple@ietf.org
</a><br><a onclick=3D"return top.js.OpenExtLink(window,event,this)" href=3D=
"https://www1.ietf.org/mailman/listinfo/simple" target=3D"_blank">https://w=
ww1.ietf.org/mailman/listinfo/simple</a><br><br><br></blockquote></div><br>=
<br clear=3D"all">
<br>-- <br>Vinod Cherian Joseph<br>SISO

------=_Part_31758_18216149.1134564621848--


--===============0498931789==
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

--===============0498931789==--




From simple-bounces@ietf.org Wed Dec 14 09:08:34 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EmXJ4-0006pA-3x; Wed, 14 Dec 2005 09:08:34 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EmXJ2-0006oj-Pd
	for simple@megatron.ietf.org; Wed, 14 Dec 2005 09:08:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29021
	for <simple@ietf.org>; Wed, 14 Dec 2005 09:07:35 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EmXKG-0008CA-2Q
	for simple@ietf.org; Wed, 14 Dec 2005 09:09:48 -0500
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by sj-iport-3.cisco.com with ESMTP; 14 Dec 2005 06:08:23 -0800
X-IronPort-AV: i="3.99,251,1131350400"; 
	d="scan'208"; a="378132388:sNHT32262520"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jBEE8DQQ020538;
	Wed, 14 Dec 2005 06:08:21 -0800 (PST)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Wed, 14 Dec 2005 09:08:17 -0500
Received: from [10.86.240.38] ([10.86.240.38]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 14 Dec 2005 09:08:16 -0500
Message-ID: <43A02750.2000802@cisco.com>
Date: Wed, 14 Dec 2005 09:08:16 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Amitkumar.Goel@infineon.com
Subject: Re: [Simple] Multiple Media in MSRP SEND Request
References: <D99246B510C34944823191CB90759C8602AC9F19@blrse201.ap.infineon.com>
In-Reply-To: <D99246B510C34944823191CB90759C8602AC9F19@blrse201.ap.infineon.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Dec 2005 14:08:16.0688 (UTC)
	FILETIME=[D4440300:01C600B7]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Content-Transfer-Encoding: 7bit
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

The only constraint over what you put in the messages is the set of 
content types that are negotiated in the offer/answer. If you negotiate 
the use of mutiple mime types that represent different media then you 
are free to use one type in one SEND and a different type in another 
SEND. And if you negotiate the use of multipart then you can include 
multiple types in the same SEND.

	Paul

Amitkumar.Goel@infineon.com wrote:
> Hi All,
>  
> I am going through the draft-ietf-simple-message-sessions-11.txt and 
> other related documents. I have one doubt. Is it possible to send 
> multiple media in a same message? Suppose I am exchanging text messages 
> to my friend  by using MSRP session. At some point of time I also want 
> to send some Audio along with the text message.
> Is this scenario possible in MSRP session messaging? If yes, how will 
> user create the SEND request?
>  
> Regards,
> Amit Kumar Goel
> Infineon Technology,
> 11th Floor, Discoverer Building,
> Whitefield,ITPL,
> Bangalore-560066
> Ph: +91(080)41392721
> Mobile:9448948977
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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 Wed Dec 14 19:37:36 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Emh7o-0007hY-TW; Wed, 14 Dec 2005 19:37:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Emh7j-0007gw-Ac
	for simple@megatron.ietf.org; Wed, 14 Dec 2005 19:37:35 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19666
	for <simple@ietf.org>; Wed, 14 Dec 2005 19:36:24 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Emh8q-0000Tv-13
	for simple@ietf.org; Wed, 14 Dec 2005 19:38:44 -0500
Received: from sj-core-3.cisco.com ([171.68.223.137])
	by sj-iport-4.cisco.com with ESMTP; 14 Dec 2005 16:37:09 -0800
Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com
	[171.70.93.57])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jBF0b7Me023402;
	Wed, 14 Dec 2005 16:37:08 -0800 (PST)
Received: from 128.107.139.242 ([128.107.139.242]) by
	vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft
	Exchange Server HTTP-DAV ; Thu, 15 Dec 2005 00:37:07 +0000
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Wed, 14 Dec 2005 16:37:15 -0800
Subject: Re: [Simple] Multiple Media in MSRP SEND Request
From: Cullen Jennings <fluffy@cisco.com>
To: Paul H Kyzivat <pkyzivat@cisco.com>, <Amitkumar.Goel@infineon.com>
Message-ID: <BFC5FABB.65791%fluffy@cisco.com>
Thread-Topic: [Simple] Multiple Media in MSRP SEND Request
Thread-Index: AcYBD7IN8MetvG0CEdqJKAARJEEJ/A==
In-Reply-To: <43A02750.2000802@cisco.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Content-Transfer-Encoding: 7bit
Cc: "simple@ietf.org" <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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org


Yes, what Paul said. Imagine you wanted to sent a GIF image of yourself, a
vcard with your contact information, and the message "Hello" all at the same
time. You could send these with three SEND requests all at the same time.


On 12/14/05 6:08 AM, "Paul Kyzivat" <pkyzivat@cisco.com> wrote:

> The only constraint over what you put in the messages is the set of
> content types that are negotiated in the offer/answer. If you negotiate
> the use of mutiple mime types that represent different media then you
> are free to use one type in one SEND and a different type in another
> SEND. And if you negotiate the use of multipart then you can include
> multiple types in the same SEND.
> 
> Paul
> 
> Amitkumar.Goel@infineon.com wrote:
>> Hi All,
>>  
>> I am going through the draft-ietf-simple-message-sessions-11.txt and
>> other related documents. I have one doubt. Is it possible to send
>> multiple media in a same message? Suppose I am exchanging text messages
>> to my friend  by using MSRP session. At some point of time I also want
>> to send some Audio along with the text message.
>> Is this scenario possible in MSRP session messaging? If yes, how will
>> user create the SEND request?
>>  
>> Regards,
>> Amit Kumar Goel
>> Infineon Technology,
>> 11th Floor, Discoverer Building,
>> Whitefield,ITPL,
>> Bangalore-560066
>> Ph: +91(080)41392721
>> Mobile:9448948977
>>  
>> 
>> 
>> ------------------------------------------------------------------------
>> 
>> _______________________________________________
>> 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 Wed Dec 14 19:41:41 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EmhBl-0008E8-0l; Wed, 14 Dec 2005 19:41:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EmhBj-0008Dp-Fg
	for simple@megatron.ietf.org; Wed, 14 Dec 2005 19:41:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19996
	for <simple@ietf.org>; Wed, 14 Dec 2005 19:40:40 -0500 (EST)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EmhD1-0000c6-EI
	for simple@ietf.org; Wed, 14 Dec 2005 19:43:00 -0500
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by sj-iport-1.cisco.com with ESMTP; 14 Dec 2005 16:41:29 -0800
X-IronPort-AV: i="3.99,255,1131350400"; 
	d="scan'208"; a="684752265:sNHT31731304"
Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com
	[171.70.93.57])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jBF0fQQK021163;
	Wed, 14 Dec 2005 16:41:27 -0800 (PST)
Received: from 128.107.139.242 ([128.107.139.242]) by
	vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft
	Exchange Server HTTP-DAV ; Thu, 15 Dec 2005 00:41:26 +0000
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Wed, 14 Dec 2005 16:41:34 -0800
Subject: Re: [Simple] IMDN Issue #1: Security of IMDN
From: Cullen Jennings <fluffy@cisco.com>
To: Eric Burger <eburger@brooktrout.com>
Message-ID: <BFC5FBBE.65795%fluffy@cisco.com>
Thread-Topic: [Simple] IMDN Issue #1: Security of IMDN
Thread-Index: AcX5ygqNRz99IFFbS4ezLwACE5TCZgFfRlYmAAgUujAAajVobA==
In-Reply-To: <330A23D8336C0346B5C1A5BB1966664701C7D74A@ATLANTIS.Brooktrout.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Content-Transfer-Encoding: 7bit
Cc: "simple@ietf.org" <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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

On 12/12/05 3:50 PM, "Burger, Eric" <eburger@brooktrout.com> wrote:

> How about:
> 
> 1. If UAS has a certificate, MUST sign IMDN.
> 
that sounds good.

> 2. If message was encrypted, MUST encrypt IMDN.  Doesn't encrypting
> cover signing?  If not, to encrypt, need cert, so see rule 1.
You can encrypt without signing. To encrypt a message from A to B, A needs
to have B's cert but A does not have to have a cert. However, I think that I
agree with your proposal here if message was encrypted, MUST encrypt IMDN
and if you can't encrypt the IMDN then MUST NOT send it.


>  
> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]
> Sent: Monday, December 12, 2005 1:09 PM
> To: Burger, Eric; simple@ietf.org
> Subject: Re: [Simple] IMDN Issue #1: Security of IMDN
> 
> On 12/5/05 10:31 AM, "Burger, Eric" <eburger@brooktrout.com> wrote:
> 
>> Proposal is that if the body of the message was encrypted or signed,
> the
>> IMDN MUST be encrypted or signed, otherwise it MAY be plain text.
>> 
>> Any dissent?
> 
> If the IMDN was only signed, but the original message was encrypted,
> would
> the IMDN reveal anything that was not in the unencrypted portion of the
> message?
> 
> This proposal does seem a little weird - what happens if you can't sign
> the
> IMDN?
> 
> Perhaps we might want something like the following 3 rules
> 
> Always sign the IMDN if you have a cert.
> 
> If the message was singed and encrypted, MUST encrypt repose.
> 
> If the message was encrypted, MUST sign IMDN.
> 
> 

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



From simple-bounces@ietf.org Wed Dec 14 22:45:53 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Emk40-0003uW-5C; Wed, 14 Dec 2005 22:45:52 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Emk3y-0003tW-B9
	for simple@megatron.ietf.org; Wed, 14 Dec 2005 22:45:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05678
	for <simple@ietf.org>; Wed, 14 Dec 2005 22:44:40 -0500 (EST)
From: Amitkumar.Goel@infineon.com
Received: from smtp3.infineon.com ([203.126.106.229])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Emk54-0006PQ-FF
	for simple@ietf.org; Wed, 14 Dec 2005 22:47:00 -0500
Received: from unknown (HELO sinse212.ap.infineon.com) ([172.17.65.148])
	by smtp3.infineon.com with ESMTP; 15 Dec 2005 11:45:17 +0800
X-SBRS: None
Received: from blrse201.ap.infineon.com ([172.20.20.12]) by
	sinse212.ap.infineon.com over TLS secured channel with
	Microsoft SMTPSVC(5.0.2195.6713); Thu, 15 Dec 2005 11:45:12 +0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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] Multiple Media in MSRP SEND Request
Date: Thu, 15 Dec 2005 09:15:11 +0530
Message-ID: <D99246B510C34944823191CB90759C86032E1404@blrse201.ap.infineon.com>
Thread-Topic: [Simple] Multiple Media in MSRP SEND Request
Thread-Index: AcYBD7IN8MetvG0CEdqJKAARJEEJ/AAGYVWw
To: <fluffy@cisco.com>, <pkyzivat@cisco.com>
X-OriginalArrivalTime: 15 Dec 2005 03:45:12.0911 (UTC)
	FILETIME=[F43615F0:01C60129]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Content-Transfer-Encoding: quoted-printable
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org



How other side know abt that all of the three send request belongs to
the same message? Will use continuation flag (+) in the end line solve
this problem?


Regards,
Amit Kumar Goel
Infineon Technology,
11th Floor, Discoverer Building,
Whitefield,ITPL,
Bangalore-560066
Ph: +91(080)41392721
Mobile:9448948977



-----Original Message-----
From: Cullen Jennings [mailto:fluffy@cisco.com]=20
Sent: Thursday, December 15, 2005 6:07 AM
To: Paul H Kyzivat; Goel Amitkumar (IFIN CSW WS)
Cc: simple@ietf.org
Subject: Re: [Simple] Multiple Media in MSRP SEND Request



Yes, what Paul said. Imagine you wanted to sent a GIF image of yourself,
a vcard with your contact information, and the message "Hello" all at
the same time. You could send these with three SEND requests all at the
same time.


On 12/14/05 6:08 AM, "Paul Kyzivat" <pkyzivat@cisco.com> wrote:

> The only constraint over what you put in the messages is the set of=20
> content types that are negotiated in the offer/answer. If you=20
> negotiate the use of mutiple mime types that represent different media

> then you are free to use one type in one SEND and a different type in=20
> another SEND. And if you negotiate the use of multipart then you can=20
> include multiple types in the same SEND.
>=20
> Paul
>=20
> Amitkumar.Goel@infineon.com wrote:
>> Hi All,
>> =20
>> I am going through the draft-ietf-simple-message-sessions-11.txt and=20
>> other related documents. I have one doubt. Is it possible to send=20
>> multiple media in a same message? Suppose I am exchanging text=20
>> messages to my friend  by using MSRP session. At some point of time I

>> also want to send some Audio along with the text message. Is this=20
>> scenario possible in MSRP session messaging? If yes, how will user=20
>> create the SEND request?
>> =20
>> Regards,
>> Amit Kumar Goel
>> Infineon Technology,
>> 11th Floor, Discoverer Building,
>> Whitefield,ITPL,
>> Bangalore-560066
>> Ph: +91(080)41392721
>> Mobile:9448948977
>> =20
>>=20
>>=20
>> ---------------------------------------------------------------------
>> ---
>>=20
>> _______________________________________________
>> Simple mailing list
>> Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple
>=20
> _______________________________________________
> 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 Thu Dec 15 00:04:10 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EmlHm-0007y1-US; Thu, 15 Dec 2005 00:04:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EmlHh-0007wu-1g
	for simple@megatron.ietf.org; Thu, 15 Dec 2005 00:04:09 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13123
	for <simple@ietf.org>; Thu, 15 Dec 2005 00:02:58 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EmlIs-0000hI-Mj
	for simple@ietf.org; Thu, 15 Dec 2005 00:05:20 -0500
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by sj-iport-3.cisco.com with ESMTP; 14 Dec 2005 21:03:46 -0800
X-IronPort-AV: i="3.99,256,1131350400"; 
	d="scan'208"; a="378499471:sNHT34207726"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBF53e72010395;
	Wed, 14 Dec 2005 21:03:43 -0800 (PST)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 15 Dec 2005 00:03:40 -0500
Received: from [10.86.240.38] ([10.86.240.38]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 15 Dec 2005 00:03:39 -0500
Message-ID: <43A0F92B.9020807@cisco.com>
Date: Thu, 15 Dec 2005 00:03:39 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Amitkumar.Goel@infineon.com
Subject: Re: [Simple] Multiple Media in MSRP SEND Request
References: <D99246B510C34944823191CB90759C86032E1404@blrse201.ap.infineon.com>
In-Reply-To: <D99246B510C34944823191CB90759C86032E1404@blrse201.ap.infineon.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Dec 2005 05:03:39.0764 (UTC)
	FILETIME=[E9B6DB40:01C60134]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168
Content-Transfer-Encoding: 7bit
Cc: fluffy@cisco.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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

The way Cullen described they won't be one message - they will be three.

If you want them in one message, put them in a multipart/mixed and then 
into one SEND.

	Paul

Amitkumar.Goel@infineon.com wrote:
> 
> How other side know abt that all of the three send request belongs to
> the same message? Will use continuation flag (+) in the end line solve
> this problem?
> 
> 
> Regards,
> Amit Kumar Goel
> Infineon Technology,
> 11th Floor, Discoverer Building,
> Whitefield,ITPL,
> Bangalore-560066
> Ph: +91(080)41392721
> Mobile:9448948977
> 
> 
> 
> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com] 
> Sent: Thursday, December 15, 2005 6:07 AM
> To: Paul H Kyzivat; Goel Amitkumar (IFIN CSW WS)
> Cc: simple@ietf.org
> Subject: Re: [Simple] Multiple Media in MSRP SEND Request
> 
> 
> 
> Yes, what Paul said. Imagine you wanted to sent a GIF image of yourself,
> a vcard with your contact information, and the message "Hello" all at
> the same time. You could send these with three SEND requests all at the
> same time.
> 
> 
> On 12/14/05 6:08 AM, "Paul Kyzivat" <pkyzivat@cisco.com> wrote:
> 
> 
>>The only constraint over what you put in the messages is the set of 
>>content types that are negotiated in the offer/answer. If you 
>>negotiate the use of mutiple mime types that represent different media
> 
> 
>>then you are free to use one type in one SEND and a different type in 
>>another SEND. And if you negotiate the use of multipart then you can 
>>include multiple types in the same SEND.
>>
>>Paul
>>
>>Amitkumar.Goel@infineon.com wrote:
>>
>>>Hi All,
>>> 
>>>I am going through the draft-ietf-simple-message-sessions-11.txt and 
>>>other related documents. I have one doubt. Is it possible to send 
>>>multiple media in a same message? Suppose I am exchanging text 
>>>messages to my friend  by using MSRP session. At some point of time I
> 
> 
>>>also want to send some Audio along with the text message. Is this 
>>>scenario possible in MSRP session messaging? If yes, how will user 
>>>create the SEND request?
>>> 
>>>Regards,
>>>Amit Kumar Goel
>>>Infineon Technology,
>>>11th Floor, Discoverer Building,
>>>Whitefield,ITPL,
>>>Bangalore-560066
>>>Ph: +91(080)41392721
>>>Mobile:9448948977
>>> 
>>>
>>>
>>>---------------------------------------------------------------------
>>>---
>>>
>>>_______________________________________________
>>>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 Thu Dec 15 06:13:55 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Emr3b-0000io-IW; Thu, 15 Dec 2005 06:13:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Emr3Z-0000ic-HZ
	for simple@megatron.ietf.org; Thu, 15 Dec 2005 06:13:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20317
	for <simple@ietf.org>; Thu, 15 Dec 2005 06:12:44 -0500 (EST)
Received: from mgw-ext01.nokia.com ([131.228.20.93])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Emr4m-0005JM-Iq
	for simple@ietf.org; Thu, 15 Dec 2005 06:15:10 -0500
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143])
	by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	jBFBDWwa020749; Thu, 15 Dec 2005 13:13:36 +0200
Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by
	esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 15 Dec 2005 13:13:31 +0200
Received: from [10.162.252.100] ([10.162.252.100]) by esebh002.NOE.Nokia.com
	with Microsoft SMTPSVC(5.0.2195.6881); 
	Thu, 15 Dec 2005 13:13:31 +0200
Message-ID: <43A14FD9.2080809@nokia.com>
Date: Thu, 15 Dec 2005 13:13:29 +0200
From: Aki Niemi <aki.niemi@nokia.com>
User-Agent: Thunderbird 1.5 (X11/20051025)
MIME-Version: 1.0
To: ext Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [Simple] Re: Addition to
	security	sectiondraft-ietf-simple-message-sessions
References: <BFC3013E.64B60%fluffy@cisco.com>
	<439EC19E.2050504@nokia.com>	<04b701c5ffff$7a5d10b0$4e087c0a@china.huawei.com>
	<28ADC0ED-D4E4-45B4-8EE3-7140E58C0AF8@nostrum.com>
In-Reply-To: <28ADC0ED-D4E4-45B4-8EE3-7140E58C0AF8@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Dec 2005 11:13:31.0216 (UTC)
	FILETIME=[94D9B500:01C60168]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Content-Transfer-Encoding: 7bit
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org


ext Robert Sparks wrote:
> Of _course_ TLS only gives us e2e when there are not intermediaries 
> terminating the TLS relationship.

That doesn't mean you couldn't deploy relay-type NAT/FW traversal while
preserving end-to-end TLS. HTTP proxies do it all the time, TURN
supports that.

> This additional section of text is describing how you can use TLS to 
> your advantage in exactly that case.
> It is not defining a new e2e mechanism for the draft, nor is it claiming 
> this is the only e2e mechanism
> available.
> 
>  From elsewhere in the document:
> 
>    Since MSRP carries arbitrary MIME content, it can trivially carry
>    S/MIME protected messages as well.  All MSRP implementations MUST
>    support the multipart/signed MIME type even if they do not support
>    S/MIME.  Since SIP can carry a session key, S/MIME messages in the
>    context of a session could also be protected using a key-wrapped
>    shared secret [26] provided in the session setup.  MSRP is a binary
>    protocol and MIME bodies MUST be transferred with a transfer encoding
>    of binary.  If a message is both signed and encrypted, it SHOULD be
>    signed first, then encrypted.  If S/MIME is supported, SHA-1, RSA,
>    and AES-128 MUST be supported.
> 

Then why specify this additional e2e mechanism based on TLS, if the 
"real" e2e security story anyway is based on S/MIME?

Cheers,
Aki

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



From simple-bounces@ietf.org Thu Dec 15 10:22:11 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Emuvr-000672-PS; Thu, 15 Dec 2005 10:22:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Emuvp-00066x-Mf
	for simple@megatron.ietf.org; Thu, 15 Dec 2005 10:22:09 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20357
	for <simple@ietf.org>; Thu, 15 Dec 2005 10:21:11 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmuxF-0005yF-3V
	for simple@ietf.org; Thu, 15 Dec 2005 10:23:38 -0500
Received: from [172.17.2.252] (dsl001-129-069.dfw1.dsl.speakeasy.net
	[72.1.129.69]) (authenticated bits=0)
	by nostrum.com (8.12.11/8.12.11) with ESMTP id jBFFLqJN043165
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Thu, 15 Dec 2005 09:21:55 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
In-Reply-To: <43A14FD9.2080809@nokia.com>
References: <BFC3013E.64B60%fluffy@cisco.com>
	<439EC19E.2050504@nokia.com>	<04b701c5ffff$7a5d10b0$4e087c0a@china.huawei.com>
	<28ADC0ED-D4E4-45B4-8EE3-7140E58C0AF8@nostrum.com>
	<43A14FD9.2080809@nokia.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <4F6C581E-9034-4609-B123-537F410957F3@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [Simple] Re: Addition to
	security	sectiondraft-ietf-simple-message-sessions
Date: Thu, 15 Dec 2005 09:21:52 -0600
To: Aki Niemi <aki.niemi@nokia.com>
X-Mailer: Apple Mail (2.746.2)
Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted
	mechanism)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Content-Transfer-Encoding: 7bit
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org


On Dec 15, 2005, at 5:13 AM, Aki Niemi wrote:

>
> ext Robert Sparks wrote:
>> Of _course_ TLS only gives us e2e when there are not  
>> intermediaries terminating the TLS relationship.
>
> That doesn't mean you couldn't deploy relay-type NAT/FW traversal  
> while
> preserving end-to-end TLS. HTTP proxies do it all the time, TURN
> supports that.
>
>> This additional section of text is describing how you can use TLS  
>> to your advantage in exactly that case.
>> It is not defining a new e2e mechanism for the draft, nor is it  
>> claiming this is the only e2e mechanism
>> available.
>>  From elsewhere in the document:
>>    Since MSRP carries arbitrary MIME content, it can trivially carry
>>    S/MIME protected messages as well.  All MSRP implementations MUST
>>    support the multipart/signed MIME type even if they do not support
>>    S/MIME.  Since SIP can carry a session key, S/MIME messages in the
>>    context of a session could also be protected using a key-wrapped
>>    shared secret [26] provided in the session setup.  MSRP is a  
>> binary
>>    protocol and MIME bodies MUST be transferred with a transfer  
>> encoding
>>    of binary.  If a message is both signed and encrypted, it  
>> SHOULD be
>>    signed first, then encrypted.  If S/MIME is supported, SHA-1, RSA,
>>    and AES-128 MUST be supported.
>
> Then why specify this additional e2e mechanism based on TLS, if the  
> "real" e2e security story anyway is based on S/MIME?

This text doesn't specify anything new. It is explanatory text,  
highlighting a possible way to use the
protocol that already existed in the document. We added this  
explanatory text at the request of one
of our Security Area ADs.

>
> Cheers,
> Aki


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



From simple-bounces@ietf.org Thu Dec 15 14:07:26 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EmyRp-00030F-Dl; Thu, 15 Dec 2005 14:07:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EmyPJ-0001nW-7z
	for simple@megatron.ietf.org; Thu, 15 Dec 2005 14:04:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18602
	for <simple@ietf.org>; Thu, 15 Dec 2005 14:03:49 -0500 (EST)
Received: from mgw-ext04.nokia.com ([131.228.20.96])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmyQk-0005oc-Hp
	for simple@ietf.org; Thu, 15 Dec 2005 14:06:19 -0500
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211])
	by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	jBFJ43eb007399; Thu, 15 Dec 2005 21:04:03 +0200
Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by
	esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 15 Dec 2005 21:04:46 +0200
Received: from [10.162.252.77] ([10.162.252.77]) by esebh002.NOE.Nokia.com
	with Microsoft SMTPSVC(5.0.2195.6881); 
	Thu, 15 Dec 2005 21:04:45 +0200
Message-ID: <43A1BE4B.4040501@nokia.com>
Date: Thu, 15 Dec 2005 21:04:43 +0200
From: Aki Niemi <aki.niemi@nokia.com>
User-Agent: Thunderbird 1.5 (X11/20051025)
MIME-Version: 1.0
To: ext Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [Simple] Re: Addition to
	security	sectiondraft-ietf-simple-message-sessions
References: <BFC3013E.64B60%fluffy@cisco.com>
	<439EC19E.2050504@nokia.com>	<04b701c5ffff$7a5d10b0$4e087c0a@china.huawei.com>
	<28ADC0ED-D4E4-45B4-8EE3-7140E58C0AF8@nostrum.com>
	<43A14FD9.2080809@nokia.com>
	<4F6C581E-9034-4609-B123-537F410957F3@nostrum.com>
In-Reply-To: <4F6C581E-9034-4609-B123-537F410957F3@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-OriginalArrivalTime: 15 Dec 2005 19:04:45.0233 (UTC)
	FILETIME=[697A5210:01C601AA]
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-ext04.nokia.com id
	jBFJ43eb007399
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Content-Transfer-Encoding: quoted-printable
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org


ext Robert Sparks wrote:
>> Then why specify this additional e2e mechanism based on TLS, if the=20
>> "real" e2e security story anyway is based on S/MIME?
>=20
> This text doesn't specify anything new. It is explanatory text,=20
> highlighting a possible way to use the
> protocol that already existed in the document. We added this explanator=
y=20
> text at the request of one
> of our Security Area ADs.

Well, to my reading it is specifying a new feature (=E1 la comedia-tls) t=
o=20
enable this out-of-band cert validation for TLS. At least I haven't seen=20
the fingerprint SDP attribute used in MSRP before, but I could've just=20
missed it.

But thinking about this a little more, the new feature seems like a=20
useful and small addition. I would still like to see TLS work e2e even=20
with one or more relays, but that's not going to happen with this or=20
with the relay specs. Maybe in some future extension; one can only hope. =
:)

The only thing that the draft should maybe elaborate a bit is to say=20
when exactly this feature will work. That is, that if the SDP answer=20
contains a path with more than one msrps URL, then the client shouldn't=20
send a certificate in the TLS handshake (because it won't validate at=20
the relay).

If the answer has a single path entry, but no fingerprint, then the=20
client probably should send the certificate. That might help in=20
authenticating the client a little "sooner".

Cheers,
Aki

>> Cheers,
>> Aki
>=20

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



From geopriv-bounces@ietf.org Thu Dec 15 16:22:02 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1En0RX-00041q-Uh; Thu, 15 Dec 2005 16:15:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1En0RW-00040R-OP
	for geopriv@megatron.ietf.org; Thu, 15 Dec 2005 16:15:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09304
	for <geopriv@ietf.org>; Thu, 15 Dec 2005 16:14:04 -0500 (EST)
Received: from marauder.andrew.com ([198.17.217.129])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1En0Sn-0003hq-4z
	for geopriv@ietf.org; Thu, 15 Dec 2005 16:16:36 -0500
Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with
	Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Dec 2005 15:14:46 -0600
Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl
	E-mail Filter (4.7); Thu, 15 Dec 2005 15:14:46 -0600
Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with
	Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Dec 2005 15:14:45 -0600
Message-ID: <AF9FCF3C02DB264EAF9872DFB6040FCC10C199E2@aopex5.andrew.com>
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: "Otmar Lendl" <lendl@nic.at>, <geopriv@ietf.org>
Date: Thu, 15 Dec 2005 15:13:19 -0600
Subject: RE: [Geopriv] ENUM input request
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
X-OriginalArrivalTime: 15 Dec 2005 21:14:45.0779 (UTC)
	FILETIME=[92F72E30:01C601BC]
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Content-class: urn:content-classes:message
Thread-Topic: [Geopriv] ENUM input request
Thread-Index: AcYBc9H13tZC4gxsT6mD52vy0mWlGQARot2Q
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: 
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>,
	<mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>,
	<mailto:geopriv-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1387083306=="
Sender: geopriv-bounces@ietf.org
Errors-To: geopriv-bounces@ietf.org

--===============1387083306==
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64
Content-class: urn:content-classes:message
Content-Transfer-Encoding: base64

V2hpbGUgSSBhZ3JlZSB3aXRoIEFuZHkgYWJvdXQgdXNlIGNhc2VzLCB0aGUgcG9pbnQgb2YgaW50
ZXJuYXRpb25hbCBhcHBsaWNhdGlvbiBpcyBleGFjdGx5IHRoZSBzb3J0IG9mIGNvbmNlcm4gdGhh
dCB0aGUgY2l2aWMgZHJhZnQgY2FuIGhlbHAgd2l0aC4gIEF1c3RyaWEgYXBwZWFycyB0byBoYXZl
IGEgZmFpcmx5IHNpbXBsZSBhZGRyZXNzaW5nIHNjaGVtZSwgbGlrZSBBdXN0cmFsaWEsIGJ1dCB0
aGVyZSBhcmUgb3RoZXIgcGxhY2VzIHRoYXQgZG9uJ3QgbG9vayBhbnl0aGluZyBsaWtlIHRoYXQu
ICBKYXBhbiBpcyB0aGUgb2J2aW91cyBvbmUgKGZyb20gREhDUCBjaXZpYyk6DQoNCiAgIEpQIChK
YXBhbik6IEExPW1ldHJvcG9saXMgKFRvLCBGdSkgb3IgcHJlZmVjdHVyZSAoS2VuLCBEbyk7IEEy
PWNpdHkNCiAgICAgIChTaGkpIG9yIHJ1cmFsIGFyZWEgKEd1bik7IEEzPXdhcmQgKEt1KSBvciB2
aWxsYWdlIChNdXJhKTsgQTQ9dG93bg0KICAgICAgKENob3Ugb3IgTWFjaGkpOyBBNT1jaXR5IGRp
c3RyaWN0IChDaG91bWUpOyBBNj1ibG9jayAoQmFuY2hpIG9yDQogICAgICBCYW4pLg0KDQpJJ20g
c3VyZSB0aGF0IHdlIHdpbGwgZW5jb3VudGVyIG1hbnkgbW9yZSBzdWNoIGNhc2VzLCBidXQgdGhh
dCBzb3J0IG9mIHRoaW5nIGlzIHdoYXQgR2VvcHJpdiBpcyBnb29kIGF0IGhhbmRsaW5nLiAgTWF5
YmUgdGhlIEVOVU0gZ3JvdXAgd291bGQgcHJlZmVyIHRvIGF2b2lkIHRob3NlIGNvbXBsaWNhdGlv
bnMuICBUaGF0IHdvdWxkIGJlIHRoZWlyIGNob2ljZSwgb2YgY291cnNlLg0KDQpJbiB0ZXJtcyBv
ZiB1c2FiaWxpdHksIHNsb3R0aW5nIGRhdGEgaW50byBQSURGLUxPIGlzbid0IHRoYXQgaGFyZCwg
cHJvdmlkaW5nIHRoYXQgc29tZW9uZSBoYXMgZG9uZSB0aGUgaW50ZXJwcmV0YXRpb24gd29yayBm
b3IgeW91LiAgQSB1c2VyIGludGVyZmFjZSB3b3VsZCBnZXQgMC8xMCBtYXJrcyBmcm9tIG1lIGlm
IGl0IGxvb2tlZCBsaWtlOg0KDQogIEExOiBfX19fX18gQTI6IF9fX19fX18gLi4uIGFuZCBzbyBv
bg0KDQpUaGVzZSB0aGluZ3MgbmVlZCB0byBiZSBsb2NhbGl6ZWQuICBKdXN0IGxpa2UgbGFuZ3Vh
Z2Ugc2V0dGluZ3MsIGVhY2ggZmllbGQgd291bGQgaGF2ZSBhIG5hbWUgdGhhdCBpcyBtZWFuaW5n
ZnVsIHRvIHRoZSB1c2VyLiAgQSBmYWlyIG51bWJlciBvZiBmaWVsZHMgd291bGRuJ3QgZXZlbiBh
cHBlYXIuDQoNCkkgc2hhcmUgQW5keSdzIGNvbmNlcm4gd2l0aCBzb21lIG9mIHRoZSBleHRyYSBm
aWVsZHM7IEkgcmVhbGx5IGRvbid0IHNlZSBob3cgUExDLCBMT0MsIFJPT00gb3IgU0VBVCB3b3Vs
ZCBhcHBseSBmb3IgdGhhdCBzb3J0IG9mIHVzZSBjYXNlLiAgQWdhaW4sIHRoYXQncyBpbnB1dCB3
ZSBjb3VsZCBwcm92aWRlIHRvIGFzc2lzdCBpbiB0aGVpciBkZWNpc2lvbi4NCg0KTWFydGluDQoN
Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZ2VvcHJpdi1ib3VuY2VzQGll
dGYub3JnIFttYWlsdG86Z2VvcHJpdi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2Yg
T3RtYXIgTGVuZGwNCj4gU2VudDogVGh1cnNkYXksIDE1IERlY2VtYmVyIDIwMDUgMTE6MjkgUE0N
Cj4gVG86IGdlb3ByaXZAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtHZW9wcml2XSBFTlVNIGlu
cHV0IHJlcXVlc3QNCj4gDQo+IE9uIDIwMDUvMTIvMTUgMTI6MTIsIEFuZHJldyBOZXd0b24gPGFu
ZHlAaHhyLnVzPiB3cm90ZToNCj4gPiA+DQo+ID4gPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu
ZXQtZHJhZnRzL2RyYWZ0LWlldGYtZW51bS12YWxpZGF0aW9uLQ0KPiA+ID50b2tlbi0wMC50eHQN
Cj4gPiA+DQo+IA0KPiA+DQo+ID4gVGhlaXJzKSBUaGUgYWRkcmVzcyBpcyBlbnRlcmVkIHZpYSBh
IHdlYiBwYWdlIGJ5IHRoZSByZWdpc3RyYW50DQo+ID4gd2FudGluZyB0byBtYXAgdGhlaXIgUFNU
TiB0ZWxlcGhvbmUgbnVtYmVyIHRvIHRoZWlyIFNJUCBwaG9uZS4gIE1vc3QNCj4gPiBsaWtlbHks
IHRoZXkgaGF2ZSBhIGJpbGwgZnJvbSB0aGVpciB0ZWxlcGhvbmUgY29tcGFueSBoYW5keSBhbmQg
Y2FuDQo+ID4gZW50ZXIgaW4gdGhlIGFkZHJlc3MgZXhhY3RseSBhcyBpdCBhcHBlYXJzIG9uIHRo
ZSBiaWxsLiAgVGhlIGFkZHJlc3MNCj4gPiBpcyB1c2VkIGZvciBjb21wYXJpc29uIHB1cnBvc2Vz
IChkb2VzIGl0IG1hdGNoIHdoYXQgaXMgb24gcmVjb3JkKSB0bw0KPiA+IHZhbGlkYXRlIHRoZSBh
c3NpZ25tZW50IG9mIHRoZSBUTi4gIEFuZCB0aGVyZSBpcyBhIGdvb2QgY2hhbmNlIHRoYXQNCj4g
PiB0aGUgdmFsaWRhdGlvbiBlbnRpdHkgaXMgYXV0b21hdGVkLg0KPiANCj4gQ29ycmVjdC4gT3Vy
IG1haW4gZm9jdXMgd2FzIHRvIGJlIGNvbXBhdGlibGUgdG8gdGhlIGRhdGEgZm9ybWF0cyB1c2Vk
DQo+IGluIHRoZSBkaXJlY3RvcnkgYXNzaXN0YW5jZSBEQiBhbmQgdGhlIHRlbGNvJ3Mgb3duIHBy
b3Zpc2lvbmluZyBkYXRhYmFzZS4NCj4gDQo+IFdlIHJlc2VhcmNoZWQgdGhlIGRhdGEtZm9ybWF0
IHVzZWQgYnkgdGhlIHJlc3BlY3RpdmUgYm9kaWVzIGhlcmUNCj4gaW4gQXVzdHJpYSB0byBhcnJp
dmUgYXQgdGhlIHNjaGVtZSB3ZSBoYXZlIGluIHRoZSBJLUQuDQo+IA0KPiBXaGF0IHdlIGRvbid0
IGtub3cgaXMgd2hhdCBhZGRyZXNzIGVsZW1lbnRzIGFyZSB1c2VkIGluIG90aGVyIGNvdW50cmll
cycNCj4gd2hpdGUgcGFnZXMgYW5kIHNpbWlsYXIgZGF0YWJhc2VzLiBUaGF0J3MgdGhlIHBvaW50
IHdoZXJlIGFueSBpbnB1dA0KPiBmcm9tIGdlb3ByaXYgaXMgYXBwcmVjaWF0ZWQuDQo+IA0KPiAv
b2wNCj4gLS0NCj4gPCBPdG1hciBMZW5kbCAobGVuZGxAbmljLmF0KSB8IG5pYy5hdCBTeXN0ZW1z
IEVuZ2luZWVyID4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQo+IEdlb3ByaXYgbWFpbGluZyBsaXN0DQo+IEdlb3ByaXZAaWV0Zi5vcmcNCj4g
aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZ2VvcHJpdg0KDQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhl
IGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBw
cm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBo
YXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVk
aWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YN
CnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQ0KW21mMl0=



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

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv

--===============1387083306==--



From simple-bounces@ietf.org Fri Dec 16 02:56:34 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EnASA-0004PY-Km; Fri, 16 Dec 2005 02:56:34 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EnAS8-0004P6-L8
	for simple@megatron.ietf.org; Fri, 16 Dec 2005 02:56:32 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15477
	for <simple@ietf.org>; Fri, 16 Dec 2005 02:55:30 -0500 (EST)
From: Markus.Isomaki@nokia.com
Received: from mgw-ext04.nokia.com ([131.228.20.96])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnATe-0003Rb-HQ
	for simple@ietf.org; Fri, 16 Dec 2005 02:58:08 -0500
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213])
	by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	jBG7tdaQ005888; Fri, 16 Dec 2005 09:55:43 +0200
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by
	esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 16 Dec 2005 09:56:13 +0200
Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by
	esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 16 Dec 2005 09:56:13 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Simple] XCAP based PUBLISH
Date: Fri, 16 Dec 2005 09:56:12 +0200
Message-ID: <C84E0A4ABA6DD74DA5221E0833A35DF303816E11@esebe101.NOE.Nokia.com>
In-Reply-To: <4B8DD52AB570D311BEDE0008C7E619880D87E3CB@BOCA212A>
Thread-Topic: [Simple] XCAP based PUBLISH
Thread-Index: AcYBvwRAfZVYmETgT+WBo47lkWWTIQAA97rQ
To: <maulik.vaidya@siemens.com>, <simple@ietf.org>
X-OriginalArrivalTime: 16 Dec 2005 07:56:13.0433 (UTC)
	FILETIME=[2F651E90:01C60216]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: quoted-printable
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi Maulik,

Actually it did make it through, and has been approved as an RFC. The =
latest version can be found here: =
http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-pidf-manipulat=
ion-usage-02.txt. The RFC won't be published, though, until the current =
issues with the XCAP base spec have been solved.

Markus=20

> -----Original Message-----
> From: simple-bounces@ietf.org=20
> [mailto:simple-bounces@ietf.org]On Behalf
> Of ext Vaidya, Maulik
> Sent: 15 December, 2005 23:13
> To: simple@ietf.org
> Subject: [Simple] XCAP based PUBLISH
>=20
>=20
> Dear all,
> Please accept my apologies in advance if this question sounds=20
> extremely
> stupid and ignorant. A while back, there was an IETF draft=20
> out there titled
> draft-isomaki-simple-xcap-publish-usage-00.txt which talked about
> manipulating hard state type of presence information via=20
> XCAP. Upon checking
> the IETF draft status, this has been deemed expired. Do you=20
> guys know of any
> specific reason why this didn't make it through? (I am looking for any
> technical glitches it may have introduced?) Are there any substitutes
> planned for similar functionality?
>=20
> Thanks in advance,
> Maulik
>=20
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
>=20

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



From simple-bounces@ietf.org Sat Dec 17 10:22:04 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Endsq-00027Q-GI; Sat, 17 Dec 2005 10:22:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Endso-00026z-8I
	for simple@megatron.ietf.org; Sat, 17 Dec 2005 10:22:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05183
	for <simple@ietf.org>; Sat, 17 Dec 2005 10:21:00 -0500 (EST)
Received: from zcars04f.nortel.com ([47.129.242.57]
	helo=zcars04f.nortelnetworks.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Endud-0000yi-Hc
	for simple@ietf.org; Sat, 17 Dec 2005 10:23:55 -0500
Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com
	[47.103.123.72])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP
	id jBHFLf804276; Sat, 17 Dec 2005 10:21:41 -0500 (EST)
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: User Agent Capability Extension to PIDF (prescaps)
Date: Sat, 17 Dec 2005 09:21:40 -0600
Message-ID: <E3F9D87C63E2774390FE67C924EC99BB0AB3D4C9@zrc2hxm1.corp.nortel.com>
Thread-Topic: [Simple] WGLC: User Agent Capability Extension to PIDF (prescaps)
Thread-Index: AcX3M7PPG7hMCvBAT16HHhd/kjWQxALYyJNA
From: "Mary Barnes" <mary.barnes@nortel.com>
To: <mikko.lonnfors@nokia.com>, <krisztian.kiss@nokia.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c
Content-Transfer-Encoding: quoted-printable
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

I've reviewed the document and believe it is about ready to forward to
IESG for review, after correction of editorial nits and some discussion
on the security section.  I will add the caveat that I'm not an XML guru
and I'm assuming some sort of tool has been used to validate the schema.


Potential issues:
----------------

- Section 8.  How do the security considerations discussed in RFC 3840
apply to the use of these feature tags in the PIDF?  You have one
general statement in the 2nd sentence of the first paragraph and this
would seem a good place to discuss this. =20

- Section 8.  You have as a SHOULD stength the use of a transport
protocol that provides some level of protection, however, what's the
impact if such a protocol is not used? =20

Editorial nits:
---------------

- Title: Although the title is already quite long, I would think it
would be useful to have SIP in there (i.e. Session Initiation Protocol
(SIP) User Agent Capability Extension to Presence Information Data
Format (PIDF))=20

- Abstract: again, I think SIP should be mentioned somewhere in the
abstract.  Actually, I think you can replace the use of "RFC3840" in the
abstract with "SIP user agent".   This is consistent with not using
references to the IMPP RFCs in the abstract, as well.=20

- Introduction, 1st para, 6th sentence: insert "a" between "taken" and
"very", i.e. the sentence should read:
   "It has taken a very minimalistic approach to support such
operations."

- Introduction, 1st para, last sentence.  I would suggest to replace the
reference to "RFC3863" to "PIDF", as you did earlier in the paragraph
for reference [4]. It's confusing to have a combination of ways for
referring to the same document in this document.  For readers that
aren't as familiar with this area, it could be confusing.=20

- Section 1.1, page 4, 4th sentence.  "represent" should be "represents"

- Section 1.1, page 5, last para of that section: "would contained"
should be either "would contain" or "contained".

- Section 3.2.1, page 6, 3rd sentence: "This element can contain
following..." should be changed to normative language "This element MAY
contain any of the following..." (I'm assuming this rewording keeps the
same intent?)

- Section 3.2.9, 2nd para, page 8: the reference to the MIME spec [19]
seems normative to this document, but it's listed as an informative
reference.  Shouldn't it be a normative dependency? =20

- Section 3.2.11, last para, page 9: The sentence on IANA registration
is a bit awkward.  I would suggest rewording FROM:=20
"  Any value that is register to IANA to SIP Media Feature Tag
   Registration Tree as sip.class media feature tag can be used as a
   value of an extension element.  If appropriate value is not
   registered it SHOULD be registed as defined in RFC3840 [6]."
TO:
  "Any value that is registered with IANA for the SIP Media Feature Tag
   Registration Tree as a sip.class media feature tag can be used as a
   value of an extension element.  If the appropriate value is not
   registered it SHOULD be registed as defined in RFC3840 [6].

- General comment: the previous comment also applies to sections 3.2.12
and 3.2.19

- section 3.2.12, page 9, 1st para: "can only receive..." should be
"only receive" for consistency with the rest of the parts of that
sentence.

- Sections 3.2.14 and 3.2.16, last paragraph.  The sentence on IANA
registration should change from:=20
"  Any value that is register to IANA to SIP Event types namespace
   registry can be used as a value of an extension element."
to:
"  Any value that is registered with IANA for the SIP Event types
namespace
   registry can be used as a value of an extension element."

- Section 3.2.15.3: I would remove the "Value of" from the following
sentence (or preface the sentence with "The"):
   "Value of the "value" attribute is
   used to indicate the exact supported priority value.

- Section 3.2.17, 3rd paragraph, page 10: add "<histinfo>" to thie list
of elements.=20

- Section 3.3, 1st paragraph, 1st sentence: add "the" before "dynamic"
and "PIDF"=20

- Section 3.3, 2nd paragraph: there seems to be a formatting problem
with the namespace identifier (i.e. shouldn't the "urn:" be part of the
element?)

- Section 3.3.2, 1st paragraph, 1st sentence: "point or contact" should
be "point of contact" (2nd occurrence).

- Section 3.3.2, 1ast paragraph, last sentence: "If appropriate..."
should be "If the appropriate..."

- Section 8.  How do the security considerations discussed in RFC 3840
apply to this=20


Mary


-----Original Message-----
From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf
Of Hisham Khartabil
Sent: Friday, December 02, 2005 5:28 AM
To: Simple WG
Subject: [Simple] WGLC: User Agent Capability Extension to PIDF
(prescaps)


The WG chairs would like to start a Working Group Last Call on the =20
following drafts:

http://www.ietf.org/internet-drafts/draft-ietf-simple-prescaps-ext=20
-05.txt

This WGLC will end on December 16th, 2005.

Please send your comments to this mailing list and to the authors.

Thanks,
Hisham


_______________________________________________
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 19 05:52:29 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EoId3-0007Mh-Ap; Mon, 19 Dec 2005 05:52:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EoId1-0007Mb-W9
	for simple@megatron.ietf.org; Mon, 19 Dec 2005 05:52:28 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24404
	for <simple@ietf.org>; Mon, 19 Dec 2005 05:51:25 -0500 (EST)
From: Amitkumar.Goel@infineon.com
Received: from smtp3.infineon.com ([203.126.106.229])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoIfD-0007rf-61
	for simple@ietf.org; Mon, 19 Dec 2005 05:54:44 -0500
Received: from unknown (HELO sinse211.ap.infineon.com) ([172.17.65.149])
	by smtp3.infineon.com with ESMTP; 19 Dec 2005 18:52:05 +0800
X-SBRS: None
Received: from blrse201.ap.infineon.com ([172.20.20.12]) by
	sinse211.ap.infineon.com over TLS secured channel with
	Microsoft SMTPSVC(5.0.2195.6713); Mon, 19 Dec 2005 18:52:05 +0800
content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Date: Mon, 19 Dec 2005 16:22:03 +0530
Message-ID: <D99246B510C34944823191CB90759C8602AC9F1B@blrse201.ap.infineon.com>
Thread-Topic: CPIM Compatibility: Header Support
Thread-Index: AcYBvwRAfZVYmETgT+WBo47lkWWTIQAA97rQALDXbrA=
To: <simple@ietf.org>
X-OriginalArrivalTime: 19 Dec 2005 10:52:05.0068 (UTC)
	FILETIME=[3FE618C0:01C6048A]
X-Spam-Score: 0.5 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Subject: [Simple] CPIM Compatibility: Header Support
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="===============1221315682=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1221315682==
content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C6048A.3F1E6134"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6048A.3F1E6134
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi All,

In CPIM compatibility support there is a paragraph=20

   "All MSRP endpoints MUST recognize the From, To, Date Time, and
Require headers as defined in RFC3862.  Such applications SHOULD
recognize the CC header, and MAY recognize the Subject header.  Any MSRP
application that recognizes any message/cpim header MUST understand  the
NS (name space) header."


Who should provide the header recognize support (MSRP or IM frame work
over MSRP or Application over IM framework) ?=20

Regards,
Amit Kumar Goel

------_=_NextPart_001_01C6048A.3F1E6134
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.6603.0">
<TITLE>CPIM Compatibility: Header Support</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">Hi =
All,</FONT></SPAN>
</P>

<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">In CPIM =
compat</FONT><FONT SIZE=3D2 FACE=3D"Arial">i</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">bility support there is</FONT><FONT SIZE=3D2 =
FACE=3D"Arial"> a</FONT><FONT SIZE=3D2 FACE=3D"Arial"> paragraph =
</FONT></SPAN>
</P>

<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
&quot;All MSRP endpoints MUST recognize the<B> From, To, Date Time, and =
Require</B></FONT><FONT SIZE=3D2 FACE=3D"Arial"></FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">headers as defined in RFC3862.&nbsp; Such applications =
SHOULD recognize</FONT><FONT SIZE=3D2 FACE=3D"Arial"></FONT> <FONT =
SIZE=3D2 FACE=3D"Arial">the</FONT><B> <FONT SIZE=3D2 =
FACE=3D"Arial">CC</FONT></B><FONT SIZE=3D2 FACE=3D"Arial"> header, and =
MAY recognize the</FONT><B> <FONT SIZE=3D2 =
FACE=3D"Arial">Subject</FONT></B><FONT SIZE=3D2 FACE=3D"Arial"> =
header.&nbsp; Any MSRP</FONT><FONT SIZE=3D2 FACE=3D"Arial"></FONT> <FONT =
SIZE=3D2 FACE=3D"Arial">application that recognizes any message/cpim =
header MUST understand</FONT><FONT SIZE=3D2 =
FACE=3D"Arial"></FONT>&nbsp;<FONT SIZE=3D2 FACE=3D"Arial"> the</FONT><B> =
<FONT SIZE=3D2 FACE=3D"Arial">NS</FONT></B><FONT SIZE=3D2 =
FACE=3D"Arial"> (name space) header.&quot;</FONT></SPAN></P>
<BR>

<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">Who should provide =
the header recognize support (MSRP or IM frame work over MSRP or =
Application over IM framework) ?</FONT> </SPAN>
</P>

<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">Regards,</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">Amit Kumar =
Goel</FONT></SPAN>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C6048A.3F1E6134--


--===============1221315682==
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

--===============1221315682==--




From simple-bounces@ietf.org Mon Dec 19 06:37:36 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EoJKi-0007SL-39; Mon, 19 Dec 2005 06:37:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EoJKc-0007RB-Qh
	for simple@megatron.ietf.org; Mon, 19 Dec 2005 06:37:30 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29820
	for <simple@ietf.org>; Mon, 19 Dec 2005 06:36:27 -0500 (EST)
Received: from smtp14.clb.oleane.net ([213.56.31.53])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoJMo-0000zG-1j
	for simple@ietf.org; Mon, 19 Dec 2005 06:39:47 -0500
Received: from Pavillonquatre ([194.3.133.88]) 
	by smtp14.clb.oleane.net with ESMTP id jBJBb8Sv013438
	for <simple@ietf.org>; Mon, 19 Dec 2005 12:37:10 +0100
Message-Id: <200512191137.jBJBb8Sv013438@smtp14.clb.oleane.net>
From: "Chantal Ladouce" <chantal.ladouce@upperside.fr>
To: <simple@ietf.org>
Date: Mon, 19 Dec 2005 12:36:25 +0100
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcYEkHGQ6zYxvt0XQwGsYklCm+NN+Q==
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955
Subject: [Simple] TVoDSL conference 2006 - Paris - France
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="===============1188289569=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1188289569==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_041B_01C60498.D39EFD30"

This is a multi-part message in MIME format.

------=_NextPart_000_041B_01C60498.D39EFD30
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

 

The third edition of the TVoDSL conference will start in one month in Paris
next 24-27 January:

 

 <http://www.upperside.fr/tvodsl2006/tvodsl2006intro.htm>
http://www.upperside.fr/tvodsl2006/tvodsl2006intro.htm

 

FastWeb, France Telecom, Telefonica, VideoNetwork representants will propose
an impressive set of return from experiences, while key industrial players
will address all the technical issues, from network architecture to content
delivery.

It is still time to register to the conference at:

 

 <http://www.upperside.fr/tvodsl2006/tvodsl2006registration.htm>
http://www.upperside.fr/tvodsl2006/tvodsl2006registration.htm

 

Close to the conference, the Triple Play Showcase is sold out. More than 60
international exhibitors will demonstrate their offerings.

 

 


------=_NextPart_000_041B_01C60498.D39EFD30
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"country-region"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place" downloadurl=3D"http://www.5iantlavalamp.com/"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City" =
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	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
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DFR link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>The third edition of the <strong><b><font =
face=3DArial><span
style=3D'font-family:Arial'>TVoDSL conference</span></font></b></strong> =
will
start in one month in <st1:place w:st=3D"on"><st1:City =
w:st=3D"on">Paris</st1:City></st1:place>
next 24-27 January:</span></font><span =
lang=3DEN-GB><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><a
href=3D"http://www.upperside.fr/tvodsl2006/tvodsl2006intro.htm"
title=3D"http://www.upperside.fr/tvodsl2006/tvodsl2006intro.htm"><span
lang=3DEN-GB><span =
title=3D"http://www.upperside.fr/tvodsl2006/tvodsl2006intro.htm">http://w=
ww.upperside.fr/tvodsl2006/tvodsl2006intro.htm</span></span></a></span></=
font><span
lang=3DEN-GB><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><st1:place w:st=3D"on"><st1:City w:st=3D"on"><font =
size=3D2
  face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>FastWeb</span></font></st1:C=
ity><font
 size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>,
 <st1:country-region =
w:st=3D"on">France</st1:country-region></span></font></st1:place><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>
Telecom, Telefonica, VideoNetwork representants will propose an =
impressive set
of return from experiences, while key industrial players will address =
all the
technical issues, from network architecture to content =
delivery.</span></font><span
lang=3DEN-GB><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>It is still time to register to the conference =
at:</span></font><span
lang=3DEN-GB><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><a
href=3D"http://www.upperside.fr/tvodsl2006/tvodsl2006registration.htm"
title=3D"http://www.upperside.fr/tvodsl2006/tvodsl2006registration.htm"><=
span
lang=3DEN-GB><span
title=3D"http://www.upperside.fr/tvodsl2006/tvodsl2006registration.htm">h=
ttp://www.upperside.fr/tvodsl2006/tvodsl2006registration.htm</span></span=
></a></span></font><span
lang=3DEN-GB><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Close to the conference, the <strong><b><font
face=3DArial><span style=3D'font-family:Arial'>Triple Play =
Showcase</span></font></b></strong>
is <strong><b><font face=3DArial><span style=3D'font-family:Arial'>sold =
out</span></font></b></strong>.
More than 60 international exhibitors will demonstrate their =
offerings.</span></font><span
lang=3DEN-GB><o:p></o:p></span></p>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_041B_01C60498.D39EFD30--



--===============1188289569==
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

--===============1188289569==--





From simple-bounces@ietf.org Tue Dec 20 02:10:56 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EobeC-0005XK-71; Tue, 20 Dec 2005 02:10:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EobeA-0005WU-EB
	for simple@megatron.ietf.org; Tue, 20 Dec 2005 02:10:54 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20129
	for <simple@ietf.org>; Tue, 20 Dec 2005 02:09:50 -0500 (EST)
Received: from nproxy.gmail.com ([64.233.182.194])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EobgW-0000Vy-94
	for simple@ietf.org; Tue, 20 Dec 2005 02:13:21 -0500
Received: by nproxy.gmail.com with SMTP id h2so453371nfe
	for <simple@ietf.org>; Mon, 19 Dec 2005 23:10:51 -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:mime-version:content-type:content-transfer-encoding:content-disposition;
	b=C9gr6w5/JmRi7ddckL04UOs6LH6giGZq7sqo+cvNelPn/0taOWlCcVdG3vObfqvFpddAnMcDtJH7RqqZOKljjbQUlJaDGWWDls6/FZPojNfEISVTb8a9hAn2QLvXJJ0yTDk1sakdA88Z/Sd2UJgKyhHHyALxR6FPJc3vTlwsoeo=
Received: by 10.48.225.3 with SMTP id x3mr287470nfg;
	Mon, 19 Dec 2005 23:10:48 -0800 (PST)
Received: by 10.48.236.20 with HTTP; Mon, 19 Dec 2005 23:10:51 -0800 (PST)
Message-ID: <95d59cef0512192310g1a964179icafffb43a3824b7a@mail.gmail.com>
Date: Tue, 20 Dec 2005 09:10:51 +0200
From: "Jussi K. Virtanen" <jussi.k.virtanen@gmail.com>
To: Aki Niemi <aki.niemi@nokia.com>,
	"Miguel A. Garcia-Martin" <miguel.an.garcia@nokia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: quoted-printable
Cc: IETF SIMPLE <simple@ietf.org>
Subject: [Simple] DISTSEND request method in MSRP
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi,

I have some issues related to the DISTSEND request method,
specified in the conference extension [3] to MSRP:

   1) The base protocol [1] requires that the body of a
      non-SEND request shall not be larger than 2048
      octets.

   2) Per the relay extension [2], a relay should, by
      default, treat requests with unknown request methods
      similarly as a REPORT request: the request should
      not be divided into smaller chunks and should not
      generate responses.

   3) As is already mentioned, the conference extension
      [3] introduces a new request method, DISTSEND, for
      private messages. According to the specification,
      the semantics of the request method are similar to
      SEND with the exception of the Distribution header
      field and the notion of privacy.

Clearly, (3) is in conflict with (1) as the body of a
SEND request can be arbitrary large and with (2) as a relay
that does not implement the DISTSEND request method is
naturally unable to obey, for example, the Failure-Report
header field in a such a request.

Finally, I believe that the capability negotiation related
to private messaging in conferences should be done in the
session establishment phase, not during a session.


   [1] draft-ietf-simple-message-sessions-12
   [2] draft-ietf-simple-msrp-relays-05
   [3] draft-niemi-simple-chat-03


BR,

-- Jussi K. Virtanen

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



From simple-bounces@ietf.org Tue Dec 20 07:03:39 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EogDT-0001qo-16; Tue, 20 Dec 2005 07:03:39 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EogDQ-0001qN-NR
	for simple@megatron.ietf.org; Tue, 20 Dec 2005 07:03:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17405
	for <simple@ietf.org>; Tue, 20 Dec 2005 07:02:33 -0500 (EST)
From: Markus.Isomaki@nokia.com
Received: from mgw-ext03.nokia.com ([131.228.20.95])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EogFp-0000zM-6H
	for simple@ietf.org; Tue, 20 Dec 2005 07:06:06 -0500
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213])
	by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	jBKBxisH007754 for <simple@ietf.org>; Tue, 20 Dec 2005 13:59:44 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by
	esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Dec 2005 14:03:33 +0200
Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by
	esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Dec 2005 14:03:33 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 20 Dec 2005 14:03:32 +0200
Message-ID: <C84E0A4ABA6DD74DA5221E0833A35DF303816E25@esebe101.NOE.Nokia.com>
In-Reply-To: <95d59cef0512192310g1a964179icafffb43a3824b7a@mail.gmail.com>
Thread-Topic: [Simple] DISTSEND request method in MSRP
Thread-Index: AcYFNOvJv7fRCl9vQ4aIkIcRF4+yhgAJ4aQQ
To: <simple@ietf.org>
X-OriginalArrivalTime: 20 Dec 2005 12:03:33.0471 (UTC)
	FILETIME=[666636F0:01C6055D]
X-Spam-Score: 0.4 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: quoted-printable
Subject: [Simple] SIMPLE draft status updated at supplementary web site
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi,

I have volunteered to maintain the SIMPLE WG supplementary web site at =
http://www.softarmor.com/simple.=20

One of the most useful sections there is the status info on all SIMPLE =
related drafts: http://www.softarmor.com/wgdb/index.php?wg=3DSIMPLE.=20

I have updated that page last week, based on e.g. info from auhors of =
individual I-Ds and IETF 64 minutes and subsequent list discussions. =
Take a look at the info, and let me know if you have something to update =
or add. I intend to do major updates at least always sometime after the =
IETF meeting, and try also otherwise to keep the status up-to-date.

Also, please send me any suggestions on how to improve the supplementary =
site.

Regards,
	Markus

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



From simple-bounces@ietf.org Wed Dec 21 03:10:50 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eoz3i-0003GZ-NJ; Wed, 21 Dec 2005 03:10:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Eoz3g-0003FV-UA
	for simple@megatron.ietf.org; Wed, 21 Dec 2005 03:10:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08113
	for <simple@ietf.org>; Wed, 21 Dec 2005 03:09:44 -0500 (EST)
From: Amitkumar.Goel@infineon.com
Received: from smtp3.infineon.com ([203.126.106.229])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eoz6G-0002Cr-Qi
	for simple@ietf.org; Wed, 21 Dec 2005 03:13:29 -0500
Received: from unknown (HELO sinse212.ap.infineon.com) ([172.17.65.148])
	by smtp3.infineon.com with ESMTP; 21 Dec 2005 16:10:34 +0800
X-SBRS: None
Received: from blrse201.ap.infineon.com ([172.20.20.12]) by
	sinse212.ap.infineon.com over TLS secured channel with
	Microsoft SMTPSVC(5.0.2195.6713); Wed, 21 Dec 2005 16:10:34 +0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 21 Dec 2005 13:40:33 +0530
Message-ID: <D99246B510C34944823191CB90759C8602AC9F1D@blrse201.ap.infineon.com>
Thread-Topic: MSRP : Restricting of TCP Connection
Thread-Index: AcYGBgPrETYUmKSRQz+ELFqm4k+FLQ==
To: <simple@ietf.org>
X-OriginalArrivalTime: 21 Dec 2005 08:10:34.0359 (UTC)
	FILETIME=[049CC070:01C60606]
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
Subject: [Simple] MSRP : Restricting of TCP Connection
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="===============1117629689=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1117629689==
content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C60606.03FA25A3"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C60606.03FA25A3
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I was trying to find out why MSRP draft is restricting to the TCP
connection only?=20
=20
There may be situations where use of UDP is good for the system(In
resource point of view).
=20
Here I pointing one situation but there can so many=20
=20
Two employees of a company working on the same project but sitting at
the different location. They need to exchange info all over the day. In
morning they start an IM session and exchange some info. They both know
that they may exchange messages/information some time latter also. Both
of them will avoid to close the session.=20
This can happen to many employees of the company and there can be lack
of resources due to use of TCP(like bandwidth etc).  We can avoid this
situation by using UDP connection.
=20
I know this is a pretty silly question and it may also be  possible that
some discussion was already taken place in past. Can anybody tell me
where I can find out some text regarding this?=20
=20
Thanks in Advance!!!!!!!!!

Regards,
Amit Kumar Goel
Infineon Technology,
11th Floor, Discoverer Building,
Whitefield,ITPL,
Bangalore-560066
Ph: +91(080)41392721
Mobile:9448948977

=20

------_=_NextPart_001_01C60606.03FA25A3
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1515" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D979403207-21122005><FONT face=3DArial size=3D2>I was =
trying to find=20
out why MSRP draft is restricting to the TCP connection only?=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D979403207-21122005><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D979403207-21122005><FONT face=3DArial size=3D2>There =
may be=20
situations where use of UDP is good for the system(In resource point of=20
view).</FONT></SPAN></DIV>
<DIV><SPAN class=3D979403207-21122005><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D979403207-21122005><FONT face=3DArial size=3D2>Here I =
pointing one=20
situation but there can so many </FONT></SPAN></DIV>
<DIV><SPAN class=3D979403207-21122005><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D979403207-21122005><FONT face=3DArial size=3D2>Two =
employees of a=20
company working on the same project but sitting at the different =
location. They=20
need to exchange&nbsp;info all over the day. In&nbsp;morning they start =
an IM=20
session and exchange some info. They both know that they&nbsp;may =
exchange=20
messages/information some time latter also. Both of them will&nbsp;avoid =

to</FONT></SPAN><SPAN class=3D979403207-21122005><FONT face=3DArial=20
size=3D2>&nbsp;close the session.&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=3D979403207-21122005><FONT face=3DArial size=3D2>This =
can happen to=20
many employees of the company and&nbsp;there can be lack of resources =
due to use=20
of TCP(like bandwidth etc).&nbsp; We can avoid this situation by using =
UDP=20
connection.</FONT></SPAN></DIV>
<DIV><SPAN class=3D979403207-21122005><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D979403207-21122005></SPAN><SPAN =
class=3D979403207-21122005><FONT=20
face=3DArial size=3D2>I know this is a pretty silly&nbsp;question and it =
may also be=20
&nbsp;possible that some discussion was already taken place in past. Can =
anybody=20
tell me where&nbsp;I can&nbsp;find&nbsp;out some text regarding this?=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D979403207-21122005><FONT face=3DArial=20
size=3D2>&nbsp;</FONT></SPAN></DIV><!-- Converted from text/rtf format =
--><SPAN=20
lang=3Den-us>
<P align=3Dleft><SPAN class=3D979403207-21122005><FONT face=3DArial =
size=3D2>Thanks in=20
Advance!!!!!!!!!</FONT></SPAN></P>
<P align=3Dleft><FONT face=3DArial size=3D2>Regards,<BR>Amit Kumar =
Goel<BR>Infineon=20
Technology,<BR>11th Floor, Discoverer=20
Building,<BR>Whitefield,ITPL,<BR>Bangalore-560066<BR>Ph:=20
+91(080)41392721<BR>Mobile:9448948977</FONT></P></SPAN>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C60606.03FA25A3--


--===============1117629689==
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

--===============1117629689==--




From simple-bounces@ietf.org Wed Dec 21 03:48:44 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EozeO-0002ug-Ee; Wed, 21 Dec 2005 03:48:44 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EozeL-0002uY-Up
	for simple@megatron.ietf.org; Wed, 21 Dec 2005 03:48:42 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10926
	for <simple@ietf.org>; Wed, 21 Dec 2005 03:47:37 -0500 (EST)
Received: from nproxy.gmail.com ([64.233.182.199])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eozgt-0003AD-Ic
	for simple@ietf.org; Wed, 21 Dec 2005 03:51:22 -0500
Received: by nproxy.gmail.com with SMTP id h2so27806nfe
	for <simple@ietf.org>; Wed, 21 Dec 2005 00:48:36 -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=XiP5QTbfxQW2/nnTwpiMZOLIs50XiYaTkAKS/EffBtk4dTv6+o1zOxoIp7n2LXAljYJgCZhAPT85BBxK1Sswf3RhjyeevszSKnJDSxNuoL2hR9DC4tPlei9oG1lFjqFAwi/TDsXSZjGPohe0JhPg7qQ7O4xPnhJvAbTdyd7Wg2M=
Received: by 10.48.229.6 with SMTP id b6mr20465nfh;
	Wed, 21 Dec 2005 00:48:36 -0800 (PST)
Received: by 10.48.236.20 with HTTP; Wed, 21 Dec 2005 00:48:36 -0800 (PST)
Message-ID: <95d59cef0512210048l4d940024q6d1e8b9d89342136@mail.gmail.com>
Date: Wed, 21 Dec 2005 10:48:36 +0200
From: "Jussi K. Virtanen" <jussi.k.virtanen@gmail.com>
To: Amit Kumar Goel <Amitkumar.Goel@infineon.com>
Subject: Re: [Simple] MSRP : Restricting of TCP Connection
In-Reply-To: <D99246B510C34944823191CB90759C8602AC9F1D@blrse201.ap.infineon.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <D99246B510C34944823191CB90759C8602AC9F1D@blrse201.ap.infineon.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Content-Transfer-Encoding: quoted-printable
Cc: IETF SIMPLE <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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi,

> I was trying to find out why MSRP draft is restricting to the TCP connect=
ion
> only?
>
> There may be situations where use of UDP is good for the system(In resour=
ce
> point of view).

As UDP does not implement congestion control, it is not
suitable for the transfer of potentially large messages
using MSRP. See, for example, Chapter 8 of RFC 3428
"Session Initiation Protocol (SIP) Extension for Instant
Messaging" for a discussion on the topic of using UDP as
a transport layer protocol for instant messaging
applications.


--
Jussi K. Virtanen

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



From simple-bounces@ietf.org Wed Dec 21 15:06:42 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EpAEU-0005uK-Pm; Wed, 21 Dec 2005 15:06:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EpAES-0005si-N0
	for simple@megatron.ietf.org; Wed, 21 Dec 2005 15:06:41 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13711
	for <simple@ietf.org>; Wed, 21 Dec 2005 15:05:34 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpA5y-0004QR-CI
	for simple@ietf.org; Wed, 21 Dec 2005 14:57:55 -0500
Received: from [172.17.2.252] (dsl001-129-069.dfw1.dsl.speakeasy.net
	[72.1.129.69]) (authenticated bits=0)
	by nostrum.com (8.12.11/8.12.11) with ESMTP id jBLJsvbF049317
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO)
	for <simple@ietf.org>; Wed, 21 Dec 2005 13:54:58 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Transfer-Encoding: 7bit
Message-Id: <F9CC6985-0911-45C2-B952-98D466AA38BE@nostrum.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: "simple@ietf.org list" <simple@ietf.org>
From: Robert Sparks <rjsparks@nostrum.com>
Date: Wed, 21 Dec 2005 13:54:54 -0600
X-Mailer: Apple Mail (2.746.2)
Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted
	mechanism)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Content-Transfer-Encoding: 7bit
Subject: [Simple] Next steps with XCAP
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Folks -

In the Vancouver meeting, we looked at several problems that have  
been identified
with XCAP and considered removing it from the RFC editor's queue to  
address them.
Solving some of the problems, particularly conditional insertion,  
would require us to
start at the beginning of the consensus process, taking the result  
through WG and
IETF last call, and through IESG review again before returning the  
document to the
editor's queue. We left the meeting with an outstanding question to  
the group and
to the other organizations depending on this work whether solving  
this problem was
worth the delay in having XCAP available as an RFC.

Subsequent feedback has all pointed towards "yes, we want to solve  
these problems
and we'll deal with the time it takes to do so".  Unless there is  
pressure against this
soon, I will take the official steps to pull XCAP from the queue and  
we will as a group
focus on fixing the outstanding problems that have been identified.

RjS

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



From simple-bounces@ietf.org Wed Dec 21 15:50:58 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EpAvK-0006jl-EZ; Wed, 21 Dec 2005 15:50:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EpAuU-0006MX-Qt; Wed, 21 Dec 2005 15:50:07 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19484;
	Wed, 21 Dec 2005 15:49:02 -0500 (EST)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EpAx8-0006gF-Jk; Wed, 21 Dec 2005 15:52:51 -0500
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1EpAuQ-0005Z8-PG; Wed, 21 Dec 2005 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: <E1EpAuQ-0005Z8-PG@newodin.ietf.org>
Date: Wed, 21 Dec 2005 15:50:02 -0500
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: simple@ietf.org
Subject: [Simple] I-D ACTION:draft-ietf-simple-cipid-07.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>
Sender: simple-bounces@ietf.org
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		: CIPID: Contact Information in Presence Information Data Format
	Author(s)	: H. Schulzrinne
	Filename	: draft-ietf-simple-cipid-07.txt
	Pages		: 12
	Date		: 2005-12-21
	
The Presence Information Data Format (PIDF) defines a basic XML
   format for presenting presence information for a presentity.  The
   Contact Information for Presence Information Data Format (CIPID) is
   an extension that adds elements to PIDF that provide additional
   contact information about a presentity and its contacts, including
   references to address book entries and icons.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-cipid-07.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-cipid-07.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-cipid-07.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: <2005-12-21143901.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-cipid-07.txt

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

Content-Type: text/plain
Content-ID: <2005-12-21143901.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 Wed Dec 21 15:51:16 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EpAvc-0006t6-2Q; Wed, 21 Dec 2005 15:51:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EpAuX-0006NR-0Y; Wed, 21 Dec 2005 15:50:09 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19490;
	Wed, 21 Dec 2005 15:49:04 -0500 (EST)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EpAx8-0006gD-MO; Wed, 21 Dec 2005 15:52:51 -0500
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1EpAuQ-0005Yz-NV; Wed, 21 Dec 2005 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: <E1EpAuQ-0005Yz-NV@newodin.ietf.org>
Date: Wed, 21 Dec 2005 15:50:02 -0500
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
Cc: simple@ietf.org
Subject: [Simple] I-D ACTION:draft-ietf-simple-rpid-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>
Sender: simple-bounces@ietf.org
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		: RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)
	Author(s)	: H. Schulzrinne, et al.
	Filename	: draft-ietf-simple-rpid-10.txt
	Pages		: 40
	Date		: 2005-12-21
	
The Presence Information Data Format (PIDF) defines a basic format
   for representing presence information for a presentity.  That format
   defines a textual note, an indication of availability (open or
   closed) and a Universal Resource Identifier (URI) for communication.
   The Rich Presence Information Data format (RPID) described here is an
   extension that adds optional elements to the Presence Information
   Data Format (PIDF).  These extensions provide additional information
   about the presentity and its contacts.  The information is designed
   so that much of it can be derived automatically, e.g., from calendar
   files or user activity.

   This extension includes information about what the person is doing, a
   grouping identifier for a tuple, when a service or device was last
   used, the type of place a person is in, what media communications
   might remain private, the relationship of a service tuple to another
   presentity, the person's mood, the time zone it is located in, the
   type of service it offers, an icon reflecting the presentity's status
   and the overall role of the presentity.

   These extensions include presence information for persons, services
   (tuples) and devices.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-rpid-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-rpid-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-rpid-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: <2005-12-21135833.I-D@ietf.org>

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

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

Content-Type: text/plain
Content-ID: <2005-12-21135833.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 Wed Dec 21 15:51:23 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EpAvj-0006wM-AH; Wed, 21 Dec 2005 15:51:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EpAuY-0006P7-So; Wed, 21 Dec 2005 15:50:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19523;
	Wed, 21 Dec 2005 15:49:06 -0500 (EST)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EpAx8-0006gH-QG; Wed, 21 Dec 2005 15:52:52 -0500
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1EpAuQ-0005ZH-RE; Wed, 21 Dec 2005 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: <E1EpAuQ-0005ZH-RE@newodin.ietf.org>
Date: Wed, 21 Dec 2005 15:50:02 -0500
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: simple@ietf.org
Subject: [Simple] I-D ACTION:draft-ietf-simple-future-05.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>
Sender: simple-bounces@ietf.org
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		: Timed Presence Extensions to the Presence 
                          Information Data Format (PIDF) to Indicate 
                          Status Information for Past and Future Time Intervals
	Author(s)	: H. Schulzrinne
	Filename	: draft-ietf-simple-future-05.txt
	Pages		: 15
	Date		: 2005-12-21
	
The Presence Information Data Format (PIDF) defines a basic XML
   format for presenting presence information for a presentity.  This
   document extends PIDF, adding a timed status extension (<timed-
   status> element) that allows a presentity to declare its status for a
   time interval fully in the future or the past.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-future-05.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-future-05.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-future-05.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: <2005-12-21144045.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-future-05.txt

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

Content-Type: text/plain
Content-ID: <2005-12-21144045.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 Wed Dec 21 17:30:12 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EpCTM-00042z-JD; Wed, 21 Dec 2005 17:30:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EpCTK-00042J-7U
	for simple@megatron.ietf.org; Wed, 21 Dec 2005 17:30:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20884
	for <simple@ietf.org>; Wed, 21 Dec 2005 17:29:04 -0500 (EST)
Received: from marauder.andrew.com ([198.17.217.129])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpCVy-0000S6-So
	for simple@ietf.org; Wed, 21 Dec 2005 17:32:58 -0500
Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with
	Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Dec 2005 16:29:47 -0600
Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl
	E-mail Filter (4.7); Wed, 21 Dec 2005 16:29:47 -0600
Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with
	Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Dec 2005 16:29:47 -0600
Message-ID: <AF9FCF3C02DB264EAF9872DFB6040FCC111C0078@aopex5.andrew.com>
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: <simple@ietf.org>
Date: Wed, 21 Dec 2005 16:29:45 -0600
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
X-OriginalArrivalTime: 21 Dec 2005 22:29:47.0277 (UTC)
	FILETIME=[0C8BC3D0:01C6067E]
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Content-class: urn:content-classes:message
Thread-Topic: Interpretation question
Thread-Index: AcYGfguqQpKwTFXZRiKrbtHa2Uq73Q==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Subject: [Simple] Interpretation question
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="===============1618731059=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

--===============1618731059==
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64
Content-class: urn:content-classes:message
Content-Transfer-Encoding: base64

UkZDIDM4NjMgb24gdGhlICdlbnRpdHknIGF0dHJpYnV0ZToNCg0KICAgVGhlIDxwcmVzZW5jZT4g
ZWxlbWVudCBNVVNUIGhhdmUgYW4gJ2VudGl0eScgYXR0cmlidXRlLiAgVGhlIHZhbHVlIG9mDQog
ICB0aGUgJ2VudGl0eScgYXR0cmlidXRlIGlzIHRoZSAncHJlcycgVVJMIG9mIHRoZSBQUkVTRU5U
SVRZIHB1Ymxpc2hpbmcNCiAgIHRoaXMgcHJlc2VuY2UgZG9jdW1lbnQuDQoNCkkgY291bGQgcmVh
ZCB0aGUgc2Vjb25kIHNlbnRlbmNlIGFzIG1lYW5pbmcgdGhhdCB0aGUgJ2VudGl0eScgYXR0cmli
dXRlIGNhbiBvbmx5IGNvbnRhaW4gYSBVUkkgd2l0aCB0aGUgJ3ByZXM6JyBzY2hlbWUuICBIb3dl
dmVyLCB0aGUgc2NoZW1hIGRvZXNuJ3QgZW5mb3JjZSBhbnkgc3VjaCByZXN0cmljdGlvbiwgbm9y
IGRvZXMgaXQgc2VlbSB0aGF0IHRoaXMgaXMgcmVxdWlyZWQgdW5pdmVyc2FsbHkgKEkgY2FuIHRo
aW5rIG9mIHNldmVyYWwgZ29vZCByZWFzb25zIHdoeSBVUklzIG9mIG90aGVyIHNjaGVtZXMgd291
bGQgYmUgYXBwcm9wcmlhdGUpLg0KDQpJcyB0aGlzIGp1c3QgbG9vc2Ugd29yZGluZz8gIElzIGl0
IGNsYXJpZmllZCBlbHNld2hlcmU/DQoNCk1hcnRpbiANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJl
Y2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9y
IG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBp
dCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVs
ZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlz
IHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCltt
ZjJd



--===============1618731059==
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

--===============1618731059==--



From simple-bounces@ietf.org Wed Dec 21 18:19:59 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EpDFX-0008UE-HD; Wed, 21 Dec 2005 18:19:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EpDFV-0008Qp-W3
	for simple@megatron.ietf.org; Wed, 21 Dec 2005 18:19:58 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25758
	for <simple@ietf.org>; Wed, 21 Dec 2005 18:18:52 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpDID-0002Cf-4P
	for simple@ietf.org; Wed, 21 Dec 2005 18:22:46 -0500
Received: from [192.168.1.103] (c-24-1-44-191.hsd1.tx.comcast.net
	[24.1.44.191]) (authenticated bits=0)
	by nostrum.com (8.12.11/8.12.11) with ESMTP id jBLNJIJF065193
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 21 Dec 2005 17:19:19 -0600 (CST)
	(envelope-from ben@estacado.net)
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <FCF05B42-66D5-4BA4-B1C3-CA9DF54FF1B9@estacado.net>
Content-Transfer-Encoding: 7bit
From: Ben Campbell <ben@estacado.net>
Date: Wed, 21 Dec 2005 17:19:55 -0600
To: Simple WG <simple@ietf.org>
X-Mailer: Apple Mail (2.746.2)
Received-SPF: pass (nostrum.com: 24.1.44.191 is authenticated by a trusted
	mechanism)
X-Spam-Score: 4.6 (++++)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: 7bit
Cc: Cullen Jennings <fluffy@cisco.com>, Rohan Mahy <rohan@ekabal.com>
Subject: [Simple] MSRP Update
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi,

I just submitted draft-ietf-simple-message-sessions-13.txt. It should  
hit the repository shortly. My understanding is that this version is  
to go to the IESG.

This version primarily addresses the concerns of the Security ADs: It  
includes Cullen's text on using peer-to-peer TLS with self-signed  
certs. It also raises the body size limit on non-SEND requests to 10K  
to give us more room for potential future security related payloads  
in AUTH requests.

We also cleaned up some references to expired drafts and unused  
references.

Thanks!

Ben.



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



From simple-bounces@ietf.org Thu Dec 22 00:59:28 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EpJU7-0006RC-NC; Thu, 22 Dec 2005 00:59:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EpJU3-0006Pi-8X
	for simple@megatron.ietf.org; Thu, 22 Dec 2005 00:59:24 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01764
	for <simple@ietf.org>; Thu, 22 Dec 2005 00:58:17 -0500 (EST)
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpJWn-0005sf-2W
	for simple@ietf.org; Thu, 22 Dec 2005 01:02:15 -0500
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-1.cisco.com with ESMTP; 21 Dec 2005 21:59:08 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.99,281,1131350400"; 
	d="scan'208"; a="17901561:sNHT23748896"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jBM5x5UR020124; 
	Thu, 22 Dec 2005 00:59:05 -0500 (EST)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 22 Dec 2005 00:59:05 -0500
Received: from [192.168.1.102] ([10.86.242.28]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 22 Dec 2005 00:59:04 -0500
Message-ID: <43AA40A8.3030902@cisco.com>
Date: Thu, 22 Dec 2005 00:59:04 -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: "Thomson, Martin" <Martin.Thomson@andrew.com>
Subject: Re: [Simple] Interpretation question
References: <AF9FCF3C02DB264EAF9872DFB6040FCC111C0078@aopex5.andrew.com>
In-Reply-To: <AF9FCF3C02DB264EAF9872DFB6040FCC111C0078@aopex5.andrew.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 22 Dec 2005 05:59:04.0873 (UTC)
	FILETIME=[D0867990:01C606BC]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Content-Transfer-Encoding: 7bit
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

It can be anything. Its commonly sip. It is clarified in the data model 
specification. See section 3.1 and the later discussion on encoding.

-Jonathan R.



Thomson, Martin wrote:

> RFC 3863 on the 'entity' attribute:
> 
>    The <presence> element MUST have an 'entity' attribute.  The value of
>    the 'entity' attribute is the 'pres' URL of the PRESENTITY publishing
>    this presence document.
> 
> I could read the second sentence as meaning that the 'entity' attribute can only contain a URI with the 'pres:' scheme.  However, the schema doesn't enforce any such restriction, nor does it seem that this is required universally (I can think of several good reasons why URIs of other schemes would be appropriate).
> 
> Is this just loose wording?  Is it clarified elsewhere?
> 
> Martin 
> 
> ------------------------------------------------------------------------------------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.  
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> ------------------------------------------------------------------------------------------------
> [mf2]
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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 22 02:12:50 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EpKd7-0008E2-Un; Thu, 22 Dec 2005 02:12:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EpKd5-0008Dx-KL
	for simple@megatron.ietf.org; Thu, 22 Dec 2005 02:12:47 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07009
	for <simple@ietf.org>; Thu, 22 Dec 2005 02:11:43 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpKfr-0007kC-2G
	for simple@ietf.org; Thu, 22 Dec 2005 02:15:40 -0500
Received: from sj-core-4.cisco.com ([171.68.223.138])
	by sj-iport-4.cisco.com with ESMTP; 21 Dec 2005 23:12:38 -0800
Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com
	[171.70.93.57])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jBM7CYpf029313;
	Wed, 21 Dec 2005 23:12:35 -0800 (PST)
Received: from 10.21.112.111 ([10.21.112.111]) by vtg-um-e2k4.sj21ad.cisco.com
	([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; 
	Thu, 22 Dec 2005 07:12:33 +0000
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Wed, 21 Dec 2005 23:12:42 -0800
From: Cullen Jennings <fluffy@cisco.com>
To: Ben Campbell <ben@estacado.net>, "simple@ietf.org" <simple@ietf.org>
Message-ID: <BFCF91EA.6682C%fluffy@cisco.com>
Thread-Topic: MSRP Update
Thread-Index: AcYGxxlWWC5b7nK6EdqVpgARJEEJ/A==
In-Reply-To: <FCF05B42-66D5-4BA4-B1C3-CA9DF54FF1B9@estacado.net>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: 7bit
Cc: Rohan Mahy <rohan@ekabal.com>
Subject: [Simple] Re: MSRP Update
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

On 12/21/05 3:19 PM, "Ben Campbell" <ben@estacado.net> wrote:

> Hi,
> 
> I just submitted draft-ietf-simple-message-sessions-13.txt. It should
> hit the repository shortly. My understanding is that this version is
> to go to the IESG.
> 
> This version primarily addresses the concerns of the Security ADs: It
> includes Cullen's text on using peer-to-peer TLS with self-signed
> certs. It also raises the body size limit on non-SEND requests to 10K
> to give us more room for potential future security related payloads
> in AUTH requests.
> 
> We also cleaned up some references to expired drafts and unused
> references.
> 
> Thanks!
> 
> Ben.

I submitted an update of the msrp-relay. It fixed typos and trivial nits.


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



From simple-bounces@ietf.org Fri Dec 23 16:56:00 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EputM-0001IN-0w; Fri, 23 Dec 2005 16:56:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EputF-0001Ca-6A; Fri, 23 Dec 2005 16:55:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15916;
	Fri, 23 Dec 2005 16:54:47 -0500 (EST)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EpuwL-0003M8-K9; Fri, 23 Dec 2005 16:59:05 -0500
Received: from apache by newodin.ietf.org with local (Exim 4.43)
	id 1EputA-0003Xv-R2; Fri, 23 Dec 2005 16:55:48 -0500
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <E1EputA-0003Xv-R2@newodin.ietf.org>
Date: Fri, 23 Dec 2005 16:55:48 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: simple chair <RjS@estacado.net>, Internet Architecture Board <iab@iab.org>,
	simple mailing list <simple@ietf.org>,
	RFC Editor <rfc-editor@rfc-editor.org>
Subject: [Simple] Protocol Action: 'CIPID: Contact Information in Presence 
 Information Data Format' to Proposed Standard 
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

The IESG has approved the following document:

- 'CIPID: Contact Information in Presence Information Data Format '
   <draft-ietf-simple-cipid-07.txt> as a Proposed Standard

This document is the product of the SIP for Instant Messaging and Presence 
Leveraging Extensions Working Group. 

The IESG contact persons are Ted Hardie and Scott Hollenbeck.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-cipid-07.txt

This document utilizes the extention mechanisms within the
Presence Information Document Format (PIDF) adding optional
elements with additional information about the presentity
and its contacts. 

This extension focuses on providing "business card" like
information in a presence document, including a card element
that can hold a vCard, a display name, a URI for a homepage,
a URI for an icon representing the presentity, a URI for
a map related to the presentity, and a URI for a sound
related to the entity.

Working Group Summary

  This document reflects WG consensus. It is related to, and was
  split out from, the Rich Presence Information Document format
  (RPID) work to facilitate building consensus.  

Protocol Quality

 Robert Sparks was the PROTO shepherd for this document.  Ted Hardie reviewed
 the document for the IESG.

Note to RFC Editor

OLD:

This specification defines extensions to the PIDF [5] XML (Extensible
   Markup Language) [6] document format.

NEW:

This specification defines extensions to the PIDF [5] XML (Extensible
   Markup Language) [6] [7] [8] document format. 


Please add the following normative references, and renumber the 
references following them:

[7] Maloney, M., Beech, D., Thompson, H., and N. Mendelsohn,
              "XML Schema Part 1: Structures Second Edition", W3C
              REC REC-xmlschema-1-20041028, October 2004.

[8] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
              Second Edition", W3C REC REC-xmlschema-2-20041028,
              October 2004.


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



From simple-bounces@ietf.org Fri Dec 23 16:58:37 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Epuvt-0004jq-Ea; Fri, 23 Dec 2005 16:58:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Epuvm-0004fz-QC; Fri, 23 Dec 2005 16:58:30 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17146;
	Fri, 23 Dec 2005 16:57:24 -0500 (EST)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Epuys-0003mU-Ti; Fri, 23 Dec 2005 17:01:43 -0500
Received: from apache by newodin.ietf.org with local (Exim 4.43)
	id 1Epuvl-0004SE-FA; Fri, 23 Dec 2005 16:58:29 -0500
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <E1Epuvl-0004SE-FA@newodin.ietf.org>
Date: Fri, 23 Dec 2005 16:58:29 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: simple chair <RjS@estacado.net>, Internet Architecture Board <iab@iab.org>,
	simple mailing list <simple@ietf.org>,
	RFC Editor <rfc-editor@rfc-editor.org>
Subject: [Simple] Protocol Action: 'Timed Presence Extensions to the
 Presence 
 Information Data Format (PIDF) to Indicate Status Information for Past 
 and Future Time Intervals' to Proposed Standard 
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

The IESG has approved the following document:

- 'Timed Presence Extensions to the Presence Information Data Format (PIDF) to 
   Indicate Status Information for Past and Future Time Intervals '
   <draft-ietf-simple-future-05.txt> as a Proposed Standard

This document is the product of the SIP for Instant Messaging and Presence 
Leveraging Extensions Working Group. 

The IESG contact persons are Ted Hardie and Scott Hollenbeck.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-future-05.txt

Technical Summary

This document utilizes the extention mechanisms within the
Presence Information Document Format (PIDF) adding optional
elements with additional information about the presentity
and its contacts. 

This extension focuses on allowing a presentity to describe
aspects of its historic status for an interval of time in 
the past, or its expected status for an interval of time in
the future (timed-status).

Working Group Summary

  This document reflects WG consensus. It is related to, and was
  split out from, the Rich Presence Information Document format
  (RPID) work to facilitate building consensus. The semantics of
  advertising presence for a time that is not now were thouroghly
  debated and clarified in this document.

Protocol Quality

  Robert Sparks was the PROTO shepherd for this document. This document
  was reviewed for the IESG by Ted Hardie

Note to RFC Editor
 

OLD:

The schema is shown below

NEW:

The XML schema [4] [5] [6] is shown below.

Please also add the following normative references and renumber the subsequent
references.

[4] Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., and E.
        Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)",
        W3C REC REC-xml-20040204, February 2004.

[5] Maloney, M., Beech, D., Thompson, H., and N. Mendelsohn,
              "XML Schema Part 1: Structures Second Edition", W3C
              REC REC-xmlschema-1-20041028, October 2004.

[6] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
              Second Edition", W3C REC REC-xmlschema-2-20041028,
              October 2004.


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



From simple-bounces@ietf.org Fri Dec 23 17:01:27 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Epuyd-0006Ht-9A; Fri, 23 Dec 2005 17:01:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EpuyV-00067J-3P; Fri, 23 Dec 2005 17:01:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17910;
	Fri, 23 Dec 2005 17:00:12 -0500 (EST)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Epv1O-0003zt-Pc; Fri, 23 Dec 2005 17:04:18 -0500
Received: from apache by newodin.ietf.org with local (Exim 4.43)
	id 1EpuyH-00036w-AX; Fri, 23 Dec 2005 17:01:05 -0500
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <E1EpuyH-00036w-AX@newodin.ietf.org>
Date: Fri, 23 Dec 2005 17:01:05 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: simple chair <RjS@estacado.net>, Internet Architecture Board <iab@iab.org>,
	simple mailing list <simple@ietf.org>,
	RFC Editor <rfc-editor@rfc-editor.org>
Subject: [Simple] Protocol Action: 'RPID: Rich Presence Extensions to the 
 Presence Information Data Format (PIDF)' to Proposed Standard 
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

The IESG has approved the following document:

- 'RPID: Rich Presence Extensions to the Presence Information Data Format 
   (PIDF) '
   <draft-ietf-simple-rpid-10.txt> as a Proposed Standard

This document is the product of the SIP for Instant Messaging and Presence 
Leveraging Extensions Working Group. 

The IESG contact persons are Ted Hardie and Scott Hollenbeck.

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

Technical Summary

This document utilizes the extention mechanisms within the
Presence Information Document Format (PIDF) adding optional
elements with additional information about the presentity
and its contacts. This extension includes information
about what the person is doing, a grouping identifier for a
tuple, when a service or device was last used, the type of
place a person is in, what media communications might
remain private, the relationship of a service tuple to
another presentity, the person's mood, the time zone it is
located in, the type of service it offers, and an icon
reflecting the presentity's status and the overall role of
the presentity.

Working Group Summary

  This document has been through many extensive working group
  discussions. It reflects a strong working group consensus.

Protocol Quality

  Robert Sparks was the PROTO sheperd for this document.  Ted Hardie 
  reviewed the document for the IESG.  Interoperable exchange of presence 
  documents using these extensions has been seen at several of the SIP 
  Interoperability Test Events (SIPITs).


Note to RFC Editor
 
OLD:

The Presence Information Data Format (PIDF) definition [8] describes
   a basic presence information data format, encoded as an Extensible
   Markup Language (XML)

NEW:

The Presence Information Data Format (PIDF) definition [8] describes
   a basic presence information data format, encoded as an Extensible
   Markup Language (XML) (SCHEMA-1) (SCHEMA-2)

Please also add the following normative references:

(SCHEMA-1) Maloney, M., Beech, D., Thompson, H., and N. Mendelsohn,
              "XML Schema Part 1: Structures Second Edition", W3C
              REC REC-xmlschema-1-20041028, October 2004.

(SCHEMA-2) Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
              Second Edition", W3C REC REC-xmlschema-2-20041028,
              October 2004.


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



From simple-bounces@ietf.org Tue Dec 27 18:50:19 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ErOaB-00033t-FA; Tue, 27 Dec 2005 18:50:19 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ErOZv-000301-Kq; Tue, 27 Dec 2005 18:50:03 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07051;
	Tue, 27 Dec 2005 18:48:52 -0500 (EST)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1ErOdq-0001np-RW; Tue, 27 Dec 2005 18:54:07 -0500
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1ErOZt-0003RW-W4; Tue, 27 Dec 2005 18: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: <E1ErOZt-0003RW-W4@newodin.ietf.org>
Date: Tue, 27 Dec 2005 18:50:01 -0500
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: simple@ietf.org
Subject: [Simple] I-D ACTION:draft-ietf-simple-message-sessions-13.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>
Sender: simple-bounces@ietf.org
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-13.txt
	Pages		: 58
	Date		: 2005-12-27
	
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 set up 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-13.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-13.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-13.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: <2005-12-27174349.I-D@ietf.org>

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

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

Content-Type: text/plain
Content-ID: <2005-12-27174349.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 Tue Dec 27 18:50:34 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ErOaQ-00036z-7v; Tue, 27 Dec 2005 18:50:34 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ErOZx-00030i-1z; Tue, 27 Dec 2005 18:50:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07063;
	Tue, 27 Dec 2005 18:48:54 -0500 (EST)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1ErOdr-0001ny-52; Tue, 27 Dec 2005 18:54:07 -0500
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1ErOZu-0003Ry-5P; Tue, 27 Dec 2005 18: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: <E1ErOZu-0003Ry-5P@newodin.ietf.org>
Date: Tue, 27 Dec 2005 18:50:02 -0500
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
Cc: simple@ietf.org
Subject: [Simple] I-D ACTION:draft-ietf-simple-msrp-relays-06.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>
Sender: simple-bounces@ietf.org
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-06.txt
	Pages		: 36
	Date		: 2005-12-27
	
The SIMPLE Working Group uses two separate models for conveying
   instant messages.  Pager-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 Sessions 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-06.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-06.txt".

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


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

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

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

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

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

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

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

Content-Type: text/plain
Content-ID: <2005-12-27180345.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 29 03:59:30 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ErtdB-0001DB-Sa; Thu, 29 Dec 2005 03:59:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ertd9-0001Cz-FZ
	for simple@megatron.ietf.org; Thu, 29 Dec 2005 03:59:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22353
	for <simple@ietf.org>; Thu, 29 Dec 2005 03:58:17 -0500 (EST)
Received: from mgw-ext01.nokia.com ([131.228.20.93])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErthL-0002Wg-O2
	for simple@ietf.org; Thu, 29 Dec 2005 04:03:49 -0500
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211])
	by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	jBT8xIO9032498; Thu, 29 Dec 2005 10:59:20 +0200
Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by
	esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 29 Dec 2005 10:59:12 +0200
Received: from [172.21.36.140] ([172.21.36.140]) by esebh001.NOE.Nokia.com
	with Microsoft SMTPSVC(5.0.2195.6881); 
	Thu, 29 Dec 2005 10:59:12 +0200
Message-ID: <43B3A55F.6010401@nokia.com>
Date: Thu, 29 Dec 2005 10:59:11 +0200
From: Aki Niemi <aki.niemi@nokia.com>
User-Agent: Thunderbird 1.5 (X11/20051025)
MIME-Version: 1.0
To: "ext Jussi K. Virtanen" <jussi.k.virtanen@gmail.com>
References: <95d59cef0512192310g1a964179icafffb43a3824b7a@mail.gmail.com>
In-Reply-To: <95d59cef0512192310g1a964179icafffb43a3824b7a@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 29 Dec 2005 08:59:12.0471 (UTC)
	FILETIME=[233F4E70:01C60C56]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Content-Transfer-Encoding: 7bit
Cc: "Miguel A. Garcia-Martin" <miguel.an.garcia@nokia.com>,
	IETF SIMPLE <simple@ietf.org>
Subject: [Simple] Re: DISTSEND request method in MSRP
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi,

Sorry for the delay. Inline.

ext Jussi K. Virtanen wrote:
> Hi,
> 
> I have some issues related to the DISTSEND request method,
> specified in the conference extension [3] to MSRP:
> 
>    1) The base protocol [1] requires that the body of a
>       non-SEND request shall not be larger than 2048
>       octets.
> 
>    2) Per the relay extension [2], a relay should, by
>       default, treat requests with unknown request methods
>       similarly as a REPORT request: the request should
>       not be divided into smaller chunks and should not
>       generate responses.
> 
>    3) As is already mentioned, the conference extension
>       [3] introduces a new request method, DISTSEND, for
>       private messages. According to the specification,
>       the semantics of the request method are similar to
>       SEND with the exception of the Distribution header
>       field and the notion of privacy.
> 
> Clearly, (3) is in conflict with (1) as the body of a
> SEND request can be arbitrary large and with (2) as a relay
> that does not implement the DISTSEND request method is
> naturally unable to obey, for example, the Failure-Report
> header field in a such a request.

Apparently, the size limit was increased to 10 kbytes, but the problem 
still remains.

If indeed relays aren't allowed to re-chunk non-SEND requests, then it 
means that any messaging necessarily needs to always use the SEND method 
and we need to change the chat specification to reflect that.

> Finally, I believe that the capability negotiation related
> to private messaging in conferences should be done in the
> session establishment phase, not during a session.

Agreed.

Cheers,
Aki

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



From simple-bounces@ietf.org Thu Dec 29 16:38:57 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Es5U8-000121-UX; Thu, 29 Dec 2005 16:38:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Es5U7-00011l-7T
	for simple@megatron.ietf.org; Thu, 29 Dec 2005 16:38:55 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21267
	for <simple@ietf.org>; Thu, 29 Dec 2005 16:37:44 -0500 (EST)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Es5YP-0005e7-Du
	for simple@ietf.org; Thu, 29 Dec 2005 16:43:23 -0500
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by rtp-iport-2.cisco.com with ESMTP; 29 Dec 2005 16:37:42 -0500
X-IronPort-AV: i="3.99,311,1131339600"; 
	d="scan'208"; a="78987401:sNHT31225408"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBTLbY4d014364
	for <simple@ietf.org>; Thu, 29 Dec 2005 16:37:40 -0500 (EST)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 29 Dec 2005 16:37:36 -0500
Received: from [161.44.55.129] ([161.44.55.129]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 29 Dec 2005 16:37:36 -0500
Message-ID: <43B45720.8090007@cisco.com>
Date: Thu, 29 Dec 2005 16:37:36 -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: Simple WG <simple@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 29 Dec 2005 21:37:36.0386 (UTC)
	FILETIME=[15B1B620:01C60CC0]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8
Content-Transfer-Encoding: 7bit
Subject: [Simple] XCAP proposal on conditional inserts
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

At the last IETF meeting, I raised the possibility of fixing the current
conditional insert problem as another change to make to the spec while
we are editing it. The problem, to refresh everyones memory, is that
HTTP (and thus XCAP) allows for conditional operations on a resource
only if the resource being operated on exists. Thats because if it
doesn't exist, it doesn't have an etag. So, you can't insert an element
conditioned on the etag of the entire document and all of its components.

So, if you really mean to insert this thing ONLY if the document is
unchanged, you'll need to do the insert "blindly", and then after its
done, you'll find out whether or not the insert was done against the
version you intended. If so, great. If not, you need to somehow undo the
change you just made.

This is far from ideal, but a known issue, and documented in the spec
today. I've been increasingly concerned that this is just not going to
work well, as it substantially raises the bar for getting the system to
work reliably.

I made a proposal at IETF to fix it, and some good comments were
provided. Based on that, here is my modified proposal for how to fix
this issue.

An XCAP resource representing an XML element in a document is said to
exist if the element appears in the document, OR its parent appears in
the document. If the XCAP resource exists but doesn't appear in the
document, it is said to be empty. So, for example:

<test>
   <el1/>
</test>

test/el1 exists and isn't empty. test/el1/el2 exists but is empty.
test/el1/blah-blah exists but is empty. In fact, every single potential
child element of el1 exists - they're just all empty. Because they exist,
they all have etags, which are all equal to the document etag. Based on
this definition, I can now go and insert a new element, which isn't
technically an insertion, but rather a modification: I'm modifying the
element to change it from empty to a specific value.

This does not apply to attributes, however. An attribute exists only if
its physically present in the document (the difficulty in getting this
mechanism to work with attributes was one of the issues raised at ietf).

Now, there are some actual consequences to this change in definition:

* A GET against one of these empty resources will not return a 404 as it
does today. Rather, it would return a 200 OK, with a Content-Type of
application/xcap-el+xml and a Content-Length of zero. This indicates
that the resource is empty.

So, based on the above example, GET test/el1/foobar would return a 200
OK with Content-Length zero.

* A GET against an element which doesnt exist WOULD return a 404. So,
for example, a GET of test/el1/foobar/nothere would return 404.

* A DELETE of an element would be forbidden, and always return a 405. To
delete an element, you need to modify it to be empty. So, you'd do a PUT
with a Content-Length of 0.

* We would no longer have a way to say, "insert this element into the
document if the element is not currently present in the document". In
the current spec, this is done by a PUT with If-None-Match: *. However,
with the proposed change, this condition would always fail, since the
element will now always exist. What we gain instead is the ability to
insert conditionally based on whether the document on the server matches
the one cached by the client.

* There would no longer be a need for the xcap-diff document that is
returned in a 202 Created response. The reason this xcap-diff document
gets sent is to let the client know what the etag was prior to
insertion, so if it didn't match the cached copy, the client could try
to repair the error. Eliminating the need for this would remove the
dependency on xcap-diff, xml-patch-ops, and so on.


It is tempting to take a slightly different approach. Call the approach 
above "approach 1". The idea with approach 2 is to declare that, even 
though a resource doesn't exist, it has an etag, and that etag is equal 
to the document's etag, assuming the document does exist. Approach 2 
would work much like approach 1, except that:

* A GET against a non-existent resource would be a 404, rather than a 
200 OK with CL of zero

* A DELETE would be allowed

Note however, that with approach 2, you still cannot support the 
operation that says, "insert this but only if this element doesn't 
already exist in the document". Approach 2 has the problem that it 
seriously bends (and possibly breaks), an underlying http assumption 
about the scope and meaning of etags. That might have odd and 
unpredicatable interactions with caching systems and other http 
intermediaries. For this reason, I wouldn't recommend it.

So, I would like to make the concrete proposal of moving to approach 1. 
The main drawback I see is the loss of the ability to insert an element 
if an element with that same name/attribute already exist.

Comments?

-Jonathan R.


-- 
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 29 17:50:12 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Es6b6-0006LL-4t; Thu, 29 Dec 2005 17:50:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Es6b4-0006Kb-V6
	for simple@megatron.ietf.org; Thu, 29 Dec 2005 17:50:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28019
	for <simple@ietf.org>; Thu, 29 Dec 2005 17:48:59 -0500 (EST)
Received: from mxgate1.brooktrout.com ([204.176.74.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Es6fO-0007vB-Ma
	for simple@ietf.org; Thu, 29 Dec 2005 17:54:39 -0500
X-IronPort-AV: i="3.99,311,1131339600"; 
	d="scan'208"; a="25077605:sNHT42890040"
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
Subject: RE: [Simple] MSRP : Restricting of TCP Connection
Date: Thu, 29 Dec 2005 17:50:03 -0500
Message-ID: <330A23D8336C0346B5C1A5BB1966664701E464F8@ATLANTIS.Brooktrout.com>
Thread-Topic: [Simple] MSRP : Restricting of TCP Connection
Thread-Index: AcYGBgPrETYUmKSRQz+ELFqm4k+FLQGuTEAg
From: "Burger, Eric" <eburger@brooktrout.com>
To: <Amitkumar.Goel@infineon.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Content-Transfer-Encoding: quoted-printable
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Is the assertion that one packet every 30 or so minutes uses too much =
bandwidth?  If so, you've got bigger problems then whether someone opens =
a long-lived, unused TCP connection.

________________________________________
From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf =
Of Amitkumar.Goel@infineon.com
Sent: Wednesday, December 21, 2005 3:11 AM
To: simple@ietf.org
Subject: [Simple] MSRP : Restricting of TCP Connection

I was trying to find out why MSRP draft is restricting to the TCP =
connection only?=20
=A0
There may be situations where use of UDP is good for the system(In =
resource point of view).
=A0
Here I pointing one situation but there can so many=20
=A0
Two employees of a company working on the same project but sitting at =
the different location. They need to exchange=A0info all over the day. =
In=A0morning they start an IM session and exchange some info. They both =
know that they=A0may exchange messages/information some time latter =
also. Both of them will=A0avoid to=A0close the session.=A0
This can happen to many employees of the company and=A0there can be lack =
of resources due to use of TCP(like bandwidth etc).=A0 We can avoid this =
situation by using UDP connection.
=A0
I know this is a pretty silly=A0question and it may also be =A0possible =
that some discussion was already taken place in past. Can anybody tell =
me where=A0I can=A0find=A0out some text regarding this?=20
=A0
Thanks in Advance!!!!!!!!!
Regards,
Amit Kumar Goel
Infineon Technology,
11th Floor, Discoverer Building,
Whitefield,ITPL,
Bangalore-560066
Ph: +91(080)41392721
Mobile:9448948977
=A0

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



From simple-bounces@ietf.org Fri Dec 30 04:04:04 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EsGBA-0004w0-6k; Fri, 30 Dec 2005 04:04:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EsGB8-0004vv-7N
	for simple@megatron.ietf.org; Fri, 30 Dec 2005 04:04:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21524
	for <simple@ietf.org>; Fri, 30 Dec 2005 04:02:49 -0500 (EST)
Received: from goliath.siemens.de ([192.35.17.28])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsGFX-0001UV-TS
	for simple@ietf.org; Fri, 30 Dec 2005 04:08:36 -0500
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id jBU93uUg015136;
	Fri, 30 Dec 2005 10:03:56 +0100
Received: from mhpahx0c.ww002.siemens.net (mhpahx0c.ww002.siemens.net
	[139.25.165.42])
	by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id jBU93tJm031800;
	Fri, 30 Dec 2005 10:03:55 +0100
Received: from MCHP7R5A.ww002.siemens.net ([139.25.131.163]) by
	mhpahx0c.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 30 Dec 2005 10:03:55 +0100
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: AW: [Simple] XCAP proposal on conditional inserts
Date: Fri, 30 Dec 2005 10:03:54 +0100
Message-ID: <72963DDDF17D7949ABD18DC5DA58E770A8B202@MCHP7R5A.ww002.siemens.net>
Thread-Topic: [Simple] XCAP proposal on conditional inserts
Thread-Index: AcYMwH4UpKHWrQisRWmzWW+Xg2lzZwAXADjw
From: "Schmidt, Christian" <christian-schmidt@siemens.com>
To: "Jonathan Rosenberg" <jdrosen@cisco.com>, "Simple WG" <simple@ietf.org>
X-OriginalArrivalTime: 30 Dec 2005 09:03:55.0709 (UTC)
	FILETIME=[F67BBED0:01C60D1F]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 43317e64100dd4d87214c51822b582d1
Content-Transfer-Encoding: quoted-printable
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>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi Jonathan,

approach 1 sound good to me. Nevertheless, I have a minor issue for =
clarification:

> * A GET against an element which doesnt exist WOULD return a 404. So,
> for example, a GET of test/el1/foobar/nothere would return 404.

This mean, there are still elements, empty elements and not existing =
elements.

> * We would no longer have a way to say, "insert this element into the
> document if the element is not currently present in the document". In
> the current spec, this is done by a PUT with If-None-Match: *. =
However,
> with the proposed change, this condition would always fail, since the
> element will now always exist. What we gain instead is the ability to
> insert conditionally based on whether the document on the server =
matches
> the one cached by the client.

Perhaps we should use conditional insertion:
- If the element exists and is not empty: return 404
- If the element exists and is empty: insert
- If the element do not exist: create and insert
This would clarify the meaning of "matches".

Shouldn=B4t it still be allowed, to delete an element: element > not =
existing element?
Perhaps in deleting an empty branch: test/el1/foobar/? This could remove =
garbage.

Example:
<test>
   <el1>
      <foobar>
         <last-one>
      </foobar>
	<silvester/>
   </el1>
</test>

Delete: test/el1/foobar/last-one would lead to
<test>
   <el1>
	<silvester/>
   </el1>
</test>

What do you think about?

Regards
Christian Schmidt, Siemens COM=20

	Phone: 	+49 89 636-75192
	Mobile: 	+49 178 7700363
	Fax: 		+49 89 636-75577
	E-Mail: 	christian-schmidt@siemens.com




=20

-----Urspr=FCngliche Nachricht-----
Von: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] Im Auftrag =
von Jonathan Rosenberg
Gesendet: Donnerstag, 29. Dezember 2005 22:38
An: Simple WG
Betreff: [Simple] XCAP proposal on conditional inserts

At the last IETF meeting, I raised the possibility of fixing the current
conditional insert problem as another change to make to the spec while
we are editing it. The problem, to refresh everyones memory, is that
HTTP (and thus XCAP) allows for conditional operations on a resource
only if the resource being operated on exists. Thats because if it
doesn't exist, it doesn't have an etag. So, you can't insert an element
conditioned on the etag of the entire document and all of its =
components.

So, if you really mean to insert this thing ONLY if the document is
unchanged, you'll need to do the insert "blindly", and then after its
done, you'll find out whether or not the insert was done against the
version you intended. If so, great. If not, you need to somehow undo the
change you just made.

This is far from ideal, but a known issue, and documented in the spec
today. I've been increasingly concerned that this is just not going to
work well, as it substantially raises the bar for getting the system to
work reliably.

I made a proposal at IETF to fix it, and some good comments were
provided. Based on that, here is my modified proposal for how to fix
this issue.

An XCAP resource representing an XML element in a document is said to
exist if the element appears in the document, OR its parent appears in
the document. If the XCAP resource exists but doesn't appear in the
document, it is said to be empty. So, for example:

<test>
   <el1/>
</test>

test/el1 exists and isn't empty. test/el1/el2 exists but is empty.
test/el1/blah-blah exists but is empty. In fact, every single potential
child element of el1 exists - they're just all empty. Because they =
exist,
they all have etags, which are all equal to the document etag. Based on
this definition, I can now go and insert a new element, which isn't
technically an insertion, but rather a modification: I'm modifying the
element to change it from empty to a specific value.

This does not apply to attributes, however. An attribute exists only if
its physically present in the document (the difficulty in getting this
mechanism to work with attributes was one of the issues raised at ietf).

Now, there are some actual consequences to this change in definition:

* A GET against one of these empty resources will not return a 404 as it
does today. Rather, it would return a 200 OK, with a Content-Type of
application/xcap-el+xml and a Content-Length of zero. This indicates
that the resource is empty.

So, based on the above example, GET test/el1/foobar would return a 200
OK with Content-Length zero.

* A GET against an element which doesnt exist WOULD return a 404. So,
for example, a GET of test/el1/foobar/nothere would return 404.

* A DELETE of an element would be forbidden, and always return a 405. To
delete an element, you need to modify it to be empty. So, you'd do a PUT
with a Content-Length of 0.

* We would no longer have a way to say, "insert this element into the
document if the element is not currently present in the document". In
the current spec, this is done by a PUT with If-None-Match: *. However,
with the proposed change, this condition would always fail, since the
element will now always exist. What we gain instead is the ability to
insert conditionally based on whether the document on the server matches
the one cached by the client.

* There would no longer be a need for the xcap-diff document that is
returned in a 202 Created response. The reason this xcap-diff document
gets sent is to let the client know what the etag was prior to
insertion, so if it didn't match the cached copy, the client could try
to repair the error. Eliminating the need for this would remove the
dependency on xcap-diff, xml-patch-ops, and so on.


It is tempting to take a slightly different approach. Call the approach=20
above "approach 1". The idea with approach 2 is to declare that, even=20
though a resource doesn't exist, it has an etag, and that etag is equal=20
to the document's etag, assuming the document does exist. Approach 2=20
would work much like approach 1, except that:

* A GET against a non-existent resource would be a 404, rather than a=20
200 OK with CL of zero

* A DELETE would be allowed

Note however, that with approach 2, you still cannot support the=20
operation that says, "insert this but only if this element doesn't=20
already exist in the document". Approach 2 has the problem that it=20
seriously bends (and possibly breaks), an underlying http assumption=20
about the scope and meaning of etags. That might have odd and=20
unpredicatable interactions with caching systems and other http=20
intermediaries. For this reason, I wouldn't recommend it.

So, I would like to make the concrete proposal of moving to approach 1.=20
The main drawback I see is the loss of the ability to insert an element=20
if an element with that same name/attribute already exist.

Comments?

-Jonathan R.


--=20
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

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