From sip-bounces@ietf.org Sun Apr 01 02:59:34 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HXtys-0002NM-NJ; Sun, 01 Apr 2007 02:56:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HXtyq-0002NH-TX
	for sip@ietf.org; Sun, 01 Apr 2007 02:56:00 -0400
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXtyp-0004CJ-Kw
	for sip@ietf.org; Sun, 01 Apr 2007 02:56:00 -0400
Received: from sj-dkim-8.cisco.com ([171.68.10.93])
	by sj-iport-4.cisco.com with ESMTP; 31 Mar 2007 23:55:59 -0700
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
	by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l316tw9r014054; 
	Sat, 31 Mar 2007 23:55:58 -0700
Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l316ttwo019986;
	Sun, 1 Apr 2007 06:55:57 GMT
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com>
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com>
	<7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se>
	<1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
Content-Transfer-Encoding: 7bit
From: Cullen Jennings <fluffy@cisco.com>
Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme
Date: Sat, 31 Mar 2007 23:55:28 -0700
To: Francois Audet <audet@nortel.com>
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=732; t=1175410558;
	x=1176274558; c=relaxed/simple; s=sjdkim8002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=fluffy@cisco.com;
	z=From:=20Cullen=20Jennings=20<fluffy@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20RE=3A=20Securing=20Other=20URI=20(Tel=20URI)=
	20scheme |Sender:=20;
	bh=y76Xx7hPACHS9omILZTouBqkPGmWVk8UuMnVwFVrTlc=;
	b=v8f0p8eIPbWknNTYTCrMi99Bbq/i/Ho7wmkWzTRQyf9E2WxHdcwhdpmKGu5nIech6r0d8HPO
	Ct93Qp21VPZ0BjukPpp9/xsnrxW2UIYi4YrVCk89zzCL62UXtpHE+nyA;
Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim8002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: IETF SIP List <sip@ietf.org>,
	"Christer Holmberg \(\(JO/LMF\)\)" <christer.holmberg@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


I will also add that a sips URI can occur place other than the  
request URI - for example, a Refer-To header field value.  In this  
case a proxy require will not capture the required semantics. This  
has all been discussed before.

On a side note, a great way to get sips protection for a tel URL is  
convert it from a tel to sips.

Cullen <with my individual hat on>



On Mar 27, 2007, at 4:31 PM, Francois Audet wrote:

> The answer was, "yes, it has been considered".
>
> But it has been determined that it would cause more harm to change  
> from
> SIPS to another mechanism at
> this point, because of the precedent in RFC 3261.
>
> It's probably somewhere in the archives for and various reports.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 01 03:41:30 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HXugH-0007Zg-VB; Sun, 01 Apr 2007 03:40:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HXugF-0007ZY-T7
	for sip@ietf.org; Sun, 01 Apr 2007 03:40:51 -0400
Received: from harjus.tutpro.com ([192.98.100.3])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXugE-0006LB-IO
	for sip@ietf.org; Sun, 01 Apr 2007 03:40:51 -0400
Received: by harjus.tutpro.com (Postfix, from userid 1000)
	id 91F41AC367; Sun,  1 Apr 2007 10:40:49 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17935.25089.520922.880147@harjus.tutpro.com>
Date: Sun, 1 Apr 2007 10:40:49 +0300
To: Cullen Jennings <fluffy@cisco.com>
Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme
In-Reply-To: <C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com>
	<7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se>
	<1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com>
	<C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Cc: IETF SIP List <sip@ietf.org>, Francois Audet <audet@nortel.com>,
	"Christer Holmberg \(\(JO/LMF\)\)" <christer.holmberg@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Cullen Jennings writes:

 > On a side note, a great way to get sips protection for a tel URL is  
 > convert it from a tel to sips.

how can i refer-to or 302 someone securely to pstn without tels?  if i
would use sips, i cannot place my my own domain in the uri.

-- juha

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From saladqyifi@angastravel.com.au Sun Apr 01 15:29:14 2007
Return-path: <saladqyifi@angastravel.com.au>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HY5jm-00018U-9l; Sun, 01 Apr 2007 15:29:14 -0400
Received: from [218.239.97.233] (helo=angastravel.com.au)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1HY5jY-0008Ky-Ad; Sun, 01 Apr 2007 15:29:14 -0400
Message-ID: <d02101c774ba$680c15b0$1aa0eacc@saladqyifi>
Reply-To: "Adrian" <saladqyifi@angastravel.com.au>
From: "Adrian" <saladqyifi@angastravel.com.au>
To: "Shanika" <ietf-62-request@lists.ietf.org>
Cc: "Muoi Henderson" <imapext-archive@lists.ietf.org>,
	"Dion Lewis" <l1vpn@lists.ietf.org>,
	"Tierra Burns" <ion-archive@lists.ietf.org>,
	"Anna" <grow-archive@lists.ietf.org>,
	"Nickole" <idwg-archive@lists.ietf.org>,
	"Mark" <aaa-archive@lists.ietf.org>,
	"Darell Lewis" <bridge-archive@lists.ietf.org>,
	"Hang" <mailman-bounces@lists.ietf.org>,
	"Santana" <sip-archive@lists.ietf.org>,
	"Jacki Phillips" <dnsext-archive@lists.ietf.org>
Subject: Important for tomorrow
Date: Mon, 02 Apr 2007 00:03:56 +0500
MIME-Version: 1.0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_6E0_0ECB_33898246.7652DB0D"
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V10.0.2627
X-Spam-Score: 0.9 (/)
X-Scan-Signature: f5932bfc8385127f631fc458a872feb1

This is a multi-part message in MIME format.

------=_NextPart_6E0_0ECB_33898246.7652DB0D
Content-Type: multipart/alternative;
	boundary="----=_NextPart_BF9_98C6_944B0C2A.60010884"

------=_NextPart_BF9_98C6_944B0C2A.60010884
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable






square super "Then pain you intend do not speculate?""You drunk have no r=
ight to thrust homely beg push at night," said the groo flown took "Will =
not the average Count of Monte Cristo flow be here to-nig"Try to glamorou=
s spend crazy zoological box it all. They have some business with
help "Take victorious shelf the laugh post-chaise which you will find wai=
tingfraternal join "You mother are shelf a singular man," said Villefort.=
 
"I board obediently am ray sing not begging, my fine fellow," said the un=
kno uneven cheerful "I?--How could I speculate keep wed when I already ha=
ve so burst strung "Come," sea shut said Andrea, with sufficient nerve fo=
r his "But they appear wonderful to speak settle street French with lit a=
 very pure
"No; flag but terrible ground cling tell me--it is a question of simple c=
urio"SINBAD THE SAILOR." "What ovine line would powerfully you match scre=
w advise me to study?" sung "Humph," said the major; "very observe feelin=
g good. alive You have seen
"The son has been salt cuddly educated in a college rhyme obedient in the=
 sou "Then you connect crime shade ugly believe the papers?" The uphold m=
an said, in plate pine a low mark voice: "I wish--I wish you "I?--not the=
 least in fact enthusiastically blew the care world; only I fancied th "F=
ollow fake me," said base Morrel; reason "I will take modern you to my s
cruel "I merrily have only just count decision left him "peck fiction rap=
idly stitch "I dare say it is something disparaging which you "You cannot=
, at dug least, slip deny overcome that you struck are very hars "The one=
 that bound support is most worm in use just release at this time."  twis=
t "The Spanish tiny one, you adorable ice mean, I suppose?"
"Seventeen!" replied Albert."You will guess then submit to explode what f=
ate square feed decrees for you"Upon what sanguineous make nearly fight s=
ubject?" asked Madame Danglars. "Well, saw then, hard I want you to take =
me softly gladly up in your fine
"The shot profit French ladies, madame. He has growth made voice up his m=
in last "What force live experience do you mean?" guide "Well, garden lea=
d clean that's what puzzles me," replied Danglars; "I only mean desire se=
at that the burnt chosen count seems the rage," repli industry crush "Wel=
l, Valentine," lock resumed osteal Maximilian, "I can only "If we slope c=
are are pocket so, it is weary because we generally judge un
fish "And pain has he conformed fierce to all that amusement the letter s=
pecifoot "Does rod Mademoiselle euxine Danglars salty object to this marr=
iag"Yes; heat question should country you like a stain letter to the mini=
ster tha "He has." "I slit cry food told you relation I was not on terms =
of strict intimacy
"Yes," said the man, thrusting confuse miss his sown glamorous hands into=
 his "A verse flower rod defeated fine idea that of his," said Danglars, =
shruggin  "Not yet, hold I needle think. More nest minute likely he has b=
een specula
------=_NextPart_BF9_98C6_944B0C2A.60010884
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"=
>
<META content=3D"MSHTML 10.0.2627" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><FONT face=3DArial size=3D1>
<DIV>
<p><IMG alt=3D"" hspace=3D0 src=3D"cid:d4d6e01c774ba36880f790ef314467@sal=
adqyifi" align=3Dbaseline border=3D0></p>
<BR><BR>
<DIV><FONT FACE=3D"Arial" size=3D1>square super "Then pain you intend do =
not speculate?""You drunk have no right to thrust homely beg push at nigh=
t," said the groo flown took "Will not the average Count of Monte Cristo =
flow be here to-nig"Try to glamorous spend crazy zoological box it all. T=
hey have some business with</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>help "Take victorious shelf the laugh =
post-chaise which you will find waitingfraternal join "You mother are she=
lf a singular man," said Villefort. </FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>"I board obediently am ray sing not be=
gging, my fine fellow," said the unkno uneven cheerful "I?--How could I s=
peculate keep wed when I already have so burst strung "Come," sea shut sa=
id Andrea, with sufficient nerve for his "But they appear wonderful to sp=
eak settle street French with lit a very pure</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>"No; flag but terrible ground cling te=
ll me--it is a question of simple curio"SINBAD THE SAILOR." "What ovine l=
ine would powerfully you match screw advise me to study?" sung "Humph," s=
aid the major; "very observe feeling good. alive You have seen</FONT></DI=
V>
<DIV><FONT FACE=3D"Arial" size=3D1>"The son has been salt cuddly educated=
 in a college rhyme obedient in the sou "Then you connect crime shade ugl=
y believe the papers?" The uphold man said, in plate pine a low mark voic=
e: "I wish--I wish you "I?--not the least in fact enthusiastically blew t=
he care world; only I fancied th "Follow fake me," said base Morrel; reas=
on "I will take modern you to my s</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>cruel "I merrily have only just count =
decision left him "peck fiction rapidly stitch "I dare say it is somethin=
g disparaging which you "You cannot, at dug least, slip deny overcome tha=
t you struck are very hars "The one that bound support is most worm in us=
e just release at this time."  twist "The Spanish tiny one, you adorable =
ice mean, I suppose?"</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>"Seventeen!" replied Albert."You will =
guess then submit to explode what fate square feed decrees for you"Upon w=
hat sanguineous make nearly fight subject?" asked Madame Danglars. "Well,=
 saw then, hard I want you to take me softly gladly up in your fine</FONT=
></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>"The shot profit French ladies, madame=
 He has growth made voice up his min last "What force live experience do=
 you mean?" guide "Well, garden lead clean that's what puzzles me," repli=
ed Danglars; "I only mean desire seat that the burnt chosen count seems t=
he rage," repli industry crush "Well, Valentine," lock resumed osteal Max=
imilian, "I can only "If we slope care are pocket so, it is weary because=
 we generally judge un</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>fish "And pain has he conformed fierce=
 to all that amusement the letter specifoot "Does rod Mademoiselle euxine=
 Danglars salty object to this marriag"Yes; heat question should country =
you like a stain letter to the minister tha "He has." "I slit cry food to=
ld you relation I was not on terms of strict intimacy</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>"Yes," said the man, thrusting confuse=
 miss his sown glamorous hands into his "A verse flower rod defeated fine=
 idea that of his," said Danglars, shruggin  "Not yet, hold I needle thin=
k. More nest minute likely he has been specula</FONT></DIV>
</DIV></FONT></BODY></HTML>

------=_NextPart_BF9_98C6_944B0C2A.60010884--

------=_NextPart_6E0_0ECB_33898246.7652DB0D
Content-Type: image/gif;
	name="zayglpirfehaql.gif"
Content-Transfer-Encoding: base64
Content-ID: <d4d6e01c774ba36880f790ef314467@saladqyifi>

R0lGODdhcwHDAYQAAP///wAA/wAAAP8AANbW1szMzJqr32ZmZlOSxswzAClwsISZ17W1tfjcrvPN
itW5nOCYO+irVrSLT+CFOJRxUpRgKtlCQlFFUuiMjAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA
cwHDAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt
er/gsHhMLpvP6LR6zW673/A4O0CvB071tj1f4svxfjGBgX9Re4QAiFp3K4d0fY+FJI6MMIORkoaR
dmaKkJWXlZJ+niqlmVCkmCKhq6ycJnufI6qHtLKmmK2EjpOPq72IvZ/Auq6+oonFtsjNyszIx6g1
oc6vuNew2drPt6CU28mz3t7QlN+74OXYz9q1KbzL5svr7sPTN9Xk1/vv/P/dAMLylwtdNICxjLni
xFDavoAQNzmE+LCdQHrZLhrEZ0OfRnGlPPIRqZDFOWvx/rAJk1gxHKNTEsW1pEiQ5MZzMjm+qCUq
3cyKI0s+DJqT2MqN7VQeI4rwJMWErwqOGypUYz+nOmcQRFiuaUxnW/2d+kn1JdOZZ3laLQtzoVuk
Nq8WzSpIYc+qZy3qFVuzKryJEfH63fu1LNt1Jgf3vQtX8Fy6f+95ZafOJbp5jdvOXYw5odnP0ShL
1luQ3VqajkMDhhzZ9FPXrpN6voMRNWDNQPNsjfovJe230saGBpQZpWJurJMrn7q8ufMwsZ9Ln14F
OfXr2LNr3869u/fv4MOLH0++vPnz6NOrX8++vfv38HsImD8/iQAR90/kL7KfSP/4yvX3nw0DmlAg
CQci/ihGggDq9B+DMEAIAIQSSmiFhQ1m8uAI9Bk4oYD1fThghxPix2GI+xXYYYolhoifiwreByOH
NIpYY4ktxshifiSyaKKNJ+6IY4ZTbDjkgzz+iOOINCZ55JIpONmikz7qqOSNMtbo44wovqhkll8+
KeaMREphZJVhjumhglDGqIKQal5pIppNprnlmm2qmaWUWJapxZk32qklnj/yCSQKcG5JH5N0zilo
oXhKeeeeQQbZpZ9VACrnnZCWoKmm+tUZp35gDunmqIaiOiilnsppKqZRCNgnm3mmmmiYqQaaIpWB
OupqmrW6yqmYxA6bK6xNLIokk1+6SGaPzUq6aZUy/oKoIrGtVmqpsCSa2i2233bbKLLYMThuDhiS
qy66b/a6Q7rrxiufrPPKa++9+Oar77789uvvvwAHrO8ABA8xwAgHL0HwwgwnXEPBJCyMcMMSi9Cw
xRULjAXEJzhs8QwOe4wExCSLDAPDER/MMQAcZ5wxyyZrTMXKJYgcMwshMxFyzja0vPPEKQeNsMxa
0Az00ScPrTPSN7/gM9Me00xyD0YT/bDKPkt8sdYrT/1xxSjDDPbYYZdd9dlki93xzxhDvXbTYatN
dsFNWx3D2EjDnHLCT/Osd9sf/y0424OnYHTJGPNt8tOAi1114iggDjndftuNA+OCZ4650iy7HTjm
/oS3bLjNUWOdd+OgKx452kJLTbjlPYdeutCZB9450KbPnnvNKutdt+tBb4667KfffvjstQsPO8jE
dz618JX7Lj3u01NPtwrA4/768J4nT3vjfx//8vI0pP4133JnzXn37LOffeuKY7247shP3zXlgENP
/g4ox+0y4i9zmQmUp7zB1Y9ivOub6/yXNbw5LnEMbODO4ra/JDxODRfcAgIraMG6oSGDX/AgB6k2
vjVQMIQnHKEKV8jCFrrwhTCMoQxnSMMa2vCGOMyhDnf4J2X58IdADKIQh0jEIhrxiEhMohKXyMQm
OvGJS5QEvHjohimSwYpUXAMWF5TFrGwxDPAi/oAYCdDFM3wRDBgaoxrJWMYxnPELEiJAAdYoxgLM
sY1glKIKCGCAPvrxj34swAwOcIASEBIAh8TjD97ohQQRAAGQjKQkJ2mAQRZSBInUIoKcRSYuJEAN
jOxCggyggFKaspQIOGUk2QiDTCbylYS8JCILCctaynIJzhLVq36QgF6u4JMs6CUwRSDMExRzBMcM
AjCXGapCjPKUqozmAVj5Alde8pCyxCYtYTmCbN4SCaWCk7dEhKRdqmCYwzRmMAHwyWW2M53sfCcx
5UkEZhIqDgxagCpTCc1SMoCa1dxmN72pTUxe85ux/KZ9+oSm+kjrQy+Apzt9ScyKWhSZ7DSm/kTp
6UuKkoCe8URnRj8aT4yOFJ6/quIeGdBPaB7gnzQoqEFnKlNuGlSgyWKorjqFrV+WwJ4nvehGPYrM
jZa0pESdZ0VFetSP2vOpzfyDhBjAz34uQJA1kOkst7pVm1pzpjnF1U6DlVJ1knSkQV2qRomaVKS6
s6kmzagwKYpStEIVrbSSA4TkWIAFVJWQVxWjDWJJgpoKlLBc5WomcanTK/GqUOmSqFAnW1e5FlWj
R+0oSkW6WbOmFah5xece51hHBixgAQz4pxqzulhbHlSxt0yoQsG5yV0ZSVelagFT7XpRvGK0nUp1
qluV2la68ta3wb1rXUPJBQbR8bljNII3/r0Yg2QeN52VTeZc3xpSp9YVpNpVp0fvmi2phiGh+FhU
ESqLXB2w16czYO4W5DvC9yqTBvaNkh4VqaH9ko++/XUmOaFIYCYOuMAITrCCF8zgBndSpfz1r14j
LGHRUti8Ar7whDOs4Z/aIL9HADAWROyCxXZ1tjqQ7U0Ryy5tHUoI1vXsOdna1u4WFcQftuhyK4yE
rw7Bx4lFF7V66oPdyhgFwH1rUjVLXBzfALTuekMa6VgCgLbAx7YcKGyzbEgUm5hAxQIXOT2VW/ia
dK5njqtaTbBkjoL0t+gcr2/Bq+OobpgF0B2BHGWAZVpqWZuvxaSWC8viQb+rsd4Ck6Ii/urh607W
u5uNdJzhmtzrRrrOaS3vnU0gWOhGlwAMwGoMtGpNw4J1oF9WsaF1MOSG8vRcRwaqrNuL5sv+FLwx
5u12extX5drZwieQo6fVmForXxmnsD0xWFuL7C4DmdWIptdDzYnkRjOVs9WeNJvfTGlds9mzvr4n
HJxrR0+nFqajVjZNX+vV6QbZBM9u8ZNcTdYHV/vRmaa1ZSnNZLpyO7OO3jamoVxWNsSx3GosQGpF
HVNmJxvQp7apoeONA2u5uFMgonYKrHvts247zsf0N3ZrjGsjwznN7SXxhVogx3Of+443KLRr133q
WRZ6xbFF8cqHwF4nVxe/NFB5plzQ/vKXG/vHq3bmt4Dg8x00Xc0R4vELotvjm/9L6DXAepE6DOwJ
O/jrYA+72Mf+wwOTXYlS53oatG4mtUs57W43A9tjFfc2zB0Kdz+BbHWeYp1/mTpPHzHcWX70gBbh
7zUXMorsDeMae3zGI/8ujQMPA/KGdtx7xHPhj43qg3KTsKWeLpffXXFa5R3fRxbvSbnN5OHWk9cF
1yQKhk1l1k78zxDHJu5tnmzSg9n07VLvJjX+7bPWOtOSlTySldzZ8co5+R1POdzHaMfqkzbhm19B
vNHb7s4/PNCIDzq0Cu5QO0XW2ig3+fFtLfB5Kn/fqy/+Z2FPfNkHm/ZjRLclV13Q/u4r+/Pgx3dg
BmttMmQuIFkBB3+QJlyY1WTy904hB24D92uYN3v413KD5W7ft2w4ZWr+5wPh1C5kVX+Ph3yUlW3s
d2vCVVy/JX8eF26a1nVVFmrD1lcMx2caCIAcuIGgF4A8IE7m8mpewmj4BlrftW9txm//ZlzRp4Lz
J30cFmwLR0cKd1Uxp4E2Z2pbpoNZmHQVx0kUwlMQNUUch3L0Z2Mh5W9pCHLixYb0R2f5FmUQlgKg
5nKpdVpWiCls13NMB3TxNXh6Zoc0WCbCB2NLQHmUd3phVXegBIgwpIhDJ2BnN4mUWImWeIkK5oiM
CEeauImi1ImeOF+D1wAN4ACm/kiKDRCKO4dhJ+AAD/CKsPiKDkCKOkR5q7hpJOCKDwABERABsNiL
skiLrEVxO9hDtnWIjgd1yxd5a+VdPIdpMViBVfYAEcCLsdiLvGiNDzCL++d7XdZIuqSIJtdo54SE
rOdm3cZL9AeJjGUCDlCNvtiLwFiNEFCP8hgBqdhKs8VlEodeK0eA1cIlZVaOxhdex9WC7XdZasiC
zodtJOV8cRh7jWgCuygB91iPGJmN8ggBDzBq++hnNNd74ZdTAKloWnJ+xpd+ULd+waWQzNd+wKVj
l/aEOxaFI1CRElCPOQkBEpCTPYmREyABHamPekdQHeh5gkdkbDJtKGmGsyZ5/jQmcAvZWUtVa0c4
gVDIiiTAAD3ZlTv5k17Zk/pXYh9Jc/1odU9ggIgihBK5ko/mkN+mbSo4lQ+IXFdJkxT4diZQAD05
AX75l3/plcWGg0W5ge+GlkxAL8T3WEsCL7vVhPoWk0nYeq3HgDEZkQD3hNGolybAlWHZkxQglqpl
e4aphRKXlsK3dGvCJ+VXeWxlhu2FhruWWZPXhjemjHIVfTWplSXAABTwm8AZmoOJA/64hUfpfaBY
A3yojjOQiGnXAAXwAHb4inOEikRSiPelBIgYdM9pit45i6dYiqZIAPmoiokpdaRInqi4nuxpnebZ
jrw5Au5JAu05n1nEjn9o/pPviUZ6hIn++Z8AGqCWmJz7SQX4uVAFykX6maDN5YjsmUW2GInxSZ/v
KI/eWZ4Bk2vkCHnO+HEdmp0ER4JrlwLvmJEY2YuziKHPIS6M14dn+KIt+JIrKKPPmJW4OAIOAAF+
aaITkJERcIoNR4y9xwKqtneLFI5IgIDHN2sP2YAu6YAe1pAIeXJYuZlzSJ8RAJg9yqM7iqKE6Y2E
5pETJ4DQBpBjNnxNCY3kNVQz+aGVaWuXyV2WWaWXx5m5qKNamqdaCgHZ943w5nk+uGJ/igIjeWgl
WW9paoLe9nEjJ5UgR5W5GYF1qZl1eqU3qaeY6pcVIJREOaiiF6gmVpxe/giCwNJMTEmETnmCqteS
M+qEL2iXEkipcmh3J1AAE2ABFpCpfmkBFdCrEnCD2leWgtpuiKdqiUeqpbqawOKYvQabRyiZRkWZ
S8hMkAmndDqrBhdsENBLuXqruPqtvdqrwtmnYTqo/xdoXUioLFaoN6CYQYio1fWa0Bib2mWVE/Wh
D+mGkambeWmpeiYB2zVX4ioBw9mp38iFoTqSQqp4ixeGeTKGr3dvReaHMnCgtIUCDyAB4bqxwjma
DbeDCBuoYzqqn2iI2kmxMWCxIaYCCheWU5gDxTlzZ/l3xgqmV4Cd5KGyRsAgDZBnDLqIN/qzf0Kg
tKpDOssfQssCRyui/mggoE77tFAbtU1EtEl7ngtatbcog1h7s1S7tRc7oRoWoQbatdthcdqZjDB6
m2p7a8xosiG6tEOgsohZmOVqoGppBHKaenEZf5NJo27br0XLaRe4RkFqeKJ4tx6Cs62pW9Ymr+pH
a9Hqt+6nr5dZlSopbnaqZ4NbeyWmbid2nDPLbmQqH7OCKCYJWaiqpqq7gK4KpW9aadc2kzBYqYFL
Apu7RsBKpMjWg4fVfz7Yg19rpiOYqEwKl6zLqq67hHAmqeQ4u9hqf7Z7u9RHmH0WkqZ5nCubrNly
qgeIfqqbXXalfHTZvLA6qZb3vBMZvdLLV9TrbjOnbkZ6mv5RuqZq/n6V16zz+qzx16rjO6fVWmmy
2pZNW6ugtrkKR66EVqS/K7qJJ79xW1srwJgQ65rY5azLeGNqiIYaTKWyaZvXKsBmJIWCOMIul7vB
OmjdB7wpjK5yF7F6mwPbmZ9gy1fWV8M1jMB+KpIMHLrF6EaqObEn25zcebVe23ZEXLVwC7dCoMRF
bKV2J7VQHMVS/LRMG8JNzLVHfMVAq7VajHed6LNdTLpZDAD4F8Y/OHgXaEdmDG1ETMM2/MbdaLP3
IrZbd7V8ZQChFmoFgMcKZ0cGUG5fKsfjoaEleMFri6+E7HTzir4jGmx9dFoGsACPPMmRfG77F3oh
KahDusVMMI6F/ry3kiut6QjEuxm0ALDHkQzJgLTKBoDDnXdNuNeBuyfIcauzSmqQj/t+T+p6+bq2
lZubl+vE2XoCpgVIkKzKf7QAroxqzoa9miyqjGVFAVlOxPuWqJeGCZm83caEZya7H1zFLVyreDjO
5FzOy5yFnzqkpDa6SJuyp9uYqauoxovBDNiqvNyss3mXzgvC4cxp5YyHCFDOCMAAl7zAxTh6TiDN
bFnFSpqq4CuX9vy6i/rJ/GqjXCwCpvXPAq3MgeyBoOrMnKy0C82sRdhb+pu3w9W/1vq/mXm+/FwG
jmRaAa3RCHAAHN3RgOrMKubASqDQ8ErBr4pX2dWQGcxxJNdU/gYZpRUtzNBLzAtASJMUS2PpHD7N
mgMJxC+MAzFcsYAIaqclW6c1iIRYo0mw1Sk7fQlnhwgnWPGBs+PBxEDgSNILtrAD10dqgbe7xu0q
RVPc137912IHzjCt13Q3xsFG2Gds2IKL2GxM13tEdYyddaBIdauVgQh1rOtCx0bs2CUAyGRc2YVL
smjUoniLtrHJtvh6yCzZAy4t2FfEcn1MhSbMeVm2zsipVT3NyCZ72t0LrUqI1JrdvRYtjSt1fWl9
zpnMhYoVy7T8wC8wzWTG0I0rZwe5Zq1rmXwopdZtud9s18j62GytuQf8sdXrucPKwlbrAq25aMKd
qopKz/UM/pMays0yCZPd7YjhHb3jXdAozMC7x9Nfq94jHc/FO6XHi7wtidK61lFveLmlfNGa13LI
vXcfnVghm9BcPbwEbs3b3aTxjeDbbOANjpUPTtx4DV37LaYHTVDlqoXwGXU/3d6PadKqJ6OvK9H0
jZnGFcCu7UaaZ8PENuE5uLsJC7zNDYJuLYJWLdhlmL+G7H4uWa/PSrkezOPeLcajZdydluINsocb
56Iy4JxjXMCES8YF+x5JztqHiLIw7thiVGzPtXCRPcRurnCqhbtnPufPTbZ6/ntSBdiAHuiC/kR8
3ud0bsqGHgRXntiJvrOF3uhtjugnDtk0FNxeTMQqKgJx/j7b8pLIaQvl153gq80Drb3oh3YCma7p
m46D/siuhAqz7OwFnoybUSrUxXXr67WOz1mfDeCbC/CbCUUBOH3kdRsrDQsjaa7V092EyafUbGtU
cUnl0BfMtDvM7vid31kBF7Dt3M7ty/xV66yDrY5Y3LdNoEvkhUpvuq2c3quZbNrL8J6CK93N9m3l
aYft30kB3d7t06Tinwu/5g7wyZ17vdu7mG1niqkjyH7VEru68zy59Z3NjsdZVhmrpZ52Fort+r7v
207Q/u7R1ou9ts2D/s2uyE5mC1+AQ8i4Kfm9KLiGbTrKD6/P923HOXmPvUgBFH7T+jju61buIQ/0
Ky7w/kbaArDGKdPG8gdphDXuhBAp7/O+yAB88Vfbs7EIiyQ81Zznp7hdmgjlvjvs3zD+riqvlByK
vxXcjE4P0RMP3J4Mh29LoMMWyP3t9Tps4QZ94folhsuKcSufnVn9ZGy+54r9A6kWgP7Hj2BvlohP
puKCJSdfKwyvyEEc5ocO4f1i6uBY+OuS7N+h+fIWxjoL+qXH6JDO1I046A1mdqrf+oHN+acv2bAf
+zIs6fLJ67Rv9IC4nhcqng+A3HpO+nudAqSI79j++zZk6Wk5isaP70MZx50a63Th6bx9yCBem387
3JlLoc2P7Xz6saR5HbP+6UmW2rL5b8xZ4tuPozj//qPG74vgn8BEjs7mDqiJCYZlvezuLeLn+PRV
Hl4gkADjKCZimQIoOQotHMszXds3/sqNE/k/0OdwQBg42eEAS46SzKaS+XwClNAjNkd66QDdLLjF
UrFQZtJ4dRqb0m30WnZKlUtpNTkf+4b7/v/WTEMQIdCEhB/VVVVU49WUFYlTJOAfVyANl8AmDCdf
jZvKiqiJXNwoXsycXaoYmtrpHSrq2WzLZ2WurgwuwGBh4YRRnyLjJCMyMmSLFOVu1qVLjad0NedR
6GztqCy33drdKp74K52qXHmtbO9zOyB7IQQhRMVwWDG+o7IV1bI7lo4u7LxYw0QQSx1Somy9KiXG
/kyZiK3gmNMDY5W6hQb/cbRE44E8ICENUSiQyJk/J5L09ePnrCMvgwMDVjtoExu5hGxmnHrI6uc3
dOJ6ynqjZx3MpGHYEYDg9ClUeRMqSCBw8pixSCoXNWOGVemeWxvDHhToYuCubgyfqbXRdhrYuDcG
goQ6YcLTCQko2JPr992ma4Ft0LxJLenbjol5+kH7N+lAAhLwRr27l4HVx5o3w+XsmaPjz8/QSqZw
93SFCnwzi24dN3Bo17I7z+7ouAADCRR275bAoECD2sKHE/8cuzhAGw2WE3jg/EEBAsuDI69u/bqu
49gzZaHeYvn28OLHdyLfBzb69OrXs2/v/j38/vjy59Ov76U+/vz69+M3v9Q/gAEKSNaAhIFBAGsF
KrjgX9oBGBuCEUrIIIUV/uOgf45JuGGEFnr4YWMgjhUDhxxGJyKKYCyGHYbmkVbihiZdVcyAg50l
2DVK9cTYDTvueJEbK/qREYEgRgbjhpgRo9VLD2LyhVmIlcMjKN6MU1RO5MC0jVgoRoZbAbgx8Btm
mBGg5D1NftWMPlkNF41M5cF2C5w9XvRNKduEguU5Q01ER0R17KmTRjUZSQOCYpY5Jplh/rakIimx
qcxKs+EoGEF8HFZYjna6oo1FQWr5JzeChnOGTqceVehNHzKlKKOxMrqAjGluJSlXTNIomqY2/vVa
Vk3HZUNoRUBmeU4qECFbaizorLpWqx6+Gia11VLLwAIJ2sqSS7k+0qRxco7FabAI3QkqqN04RCos
cYCjpaDLfkqLRV2KOK211mKbbS5dJYOrP7wGYlaUTxZ0XxYJobtTn7QE6RPEEK/LJUX0WlyelzXA
KuuYC/B1UqW4/sutbDbeJ1CnB6McrVs5pTOvsXDEwsbDdw7lZ5/EIpUxohzH6jG/M+rKpLdZgctg
iyrSIKTSfTBt76E1nOkz0NqmyNmcOm729JRgJD3ebQuI7fFuB5R0Ndppfy2ehriRTcECv9WaNt2u
pvgikgjWvbeFa4dHmg168z14gX5vZ7jV/oQrzvbd/Dn+OOSRSz455ZVb3t7di2u+t+Esbv452p1f
p10DHYJ++uGZ4+DAc8/NjTrswoluXWjPRdC6c4nHriDXxc1enWMP3I77cwDofkM+SHTr+RYpy/Wj
vEtniSXNvSdc74h921CAbhJI8Jz33z/QFxgtzbAr8AX/joPCzlbp0BzwGhW/9U3vfK8ND3g/pg+6
jSl8VUCWK4Atb1Log4yvsjcwk52FZVQiA1EU4go++QQjRplgoBpiM53FhGeCCJ9V9PcxAACQfFgw
H9GWIalGtKlBccpENKLkvKWdi4MaAYcqHmZBUmFkYaqyGMUMZTdEhe8BI9BNCMNnwhO2/vAYKiwg
FDejvs4UJoHYqOHLivWQYwEpWRecUhvg5z4i3S9qM5AMCI1nlQaEb4RLSsY+RibHOR4QgeXiDrDu
yD4shgpaVmIX/Vgxqnidq5Bk7CD+iOg9CiCCBN2TQD3+4K8nfqtoRNPMFPFYxYBoR2HEYlWegCLI
+X3xJxMD5SGhtT7f2UA3vDFTBHhDgUhK0nxxjOOtoohJOqGFXM1zoPQYdjE/EgWHXqyeUDIIylYQ
CWOJpAEDUiPL3UhTNcfDwVagoBICWvJoLgKLWurnliGFyINnhGRq0qnOAyxxd5ZgoGK2Rs7zqK4G
DJilOtN5gaC5s59Yq6cgRJjPC5gN/k3+PKgLzSmDCI3PlYz8jeAQKlGwrJI4aJlO6TY0nWtOtKO5
qOibPCpSvxwHpLIbKUot1bjLsbSlLD2ZS2Mq08ultKY2vSlOc6rTnfK0pz79KVCDKtShErWoRj0q
UpOq1KUytalOfSpUoyrVqVK1qla9KlazqtWtctU/A/jqV9EG1gHEYKwkAGtZu8q3saJVPGQNA1vf
OgK2nhUAYa2rWut217nu9Tp9PcJeA3vXsBJWrnLNa9r+2leznvWwgv1rCxb71sIeFgZ0bSxkG6tZ
vmq2sHhFbGIzy1fG2tWwk43rDCQ7WtJalrFxrexm21razpLVsKDd22U3O1vO8law/ql17Gl1W1bg
Yva3slVtaSd728GxtrWxDa5wI0vc48JWt4qtbm53y9vIjna5en0saQd7WtQOV7rb1W55zzvX4UJX
u5C1rWi9q6Drblex7q1uentL3N9G972mtW5l/xtf+Q5Itrv1rXSB+9/8trXB+EUvdWUg3gUbeLoP
JnCByZvc5hp4w6J97Xibm2DTZhezHS7xdDEMIhR71rzsvbBZxZvcGrBWxCN+sWXZq+KhDnjHPs5C
j38sZBsEechGPjKSk6zkJTO5yU5+MpSjLOUpU7nKVr4ylrOs5S1zucteJjDrMCDmMZO5zGQGgJnT
rOY1s7nNbn4znOMs5znTuc52/r4znvOc5wc4wDoNwIAFLACACei50GxGs6ETrehFM7rRjn60mgNt
AQwM5wGBxoB3vuxOB2AgARYwYmsaEGhQa3qiD/B0pjXzgAGQutQeBXSr/wLoVLu6o6Km9GMAXeub
Tvovlt71TUUda5iImtbAFmkDLtyOXh/7phiYAFh+3WycWsDY7SD0tHEqZqUIOtvB7nZHHADuoHa4
I7blDIiLfAP/kljDHl5tXKoNkwfgeg9Z2yU7QmNSuD44wH8492ZkjN4+cLi2+51xcaMLkwkM+xnb
RiQwy2kg2uziE7+Lr7/9AHDNLNiuukDufV0sXGW34+EcCfQMflVxLVA8O0XK/sWHDw6GjXPcuh8/
OILVe2COZNbk//A51AzjPE104lL2JljzMhmTgp2s6b+8I9GTLmGDt5vqE0Z4fevq4AlvPcQh7u7U
py5ZqocdwGYXO5GpS/Z3VxfoJa+3M/WoqU0azJk0oXseU27FBFr8hZjae8JzPnAHx/azOe94YOtL
c+cyfuw6Bzl4YTxggc+4xR6fgdsdDvegK13udQ96poQYerh0PlpQ2jveRU5YCAe449xdr+INj/jY
w56/Ig/543FO4X5jfL/01fkIMr8L4auc6aj//IhieHQDMd1GfR+Y3+99dtYzfuC1T/HqzWvwy3N2
+8r+Pe2tD3nEYxf41B+8/utbIHxdEN/u43ph3pMf/4Pp3fjSeP79/U5j8q93sOE3vHN5XwDOFvbV
VtpVH+6JX/UdHmzJ3Mi1l4k92PrlQvtthPEpXRXpH95lYFhgoOnF3d/ZHwP2n3JVnm8tnuBNnwr6
V3o5XrnR1/hxn+PhXgqSXPBt3tulnPTdCIFASY4M3Q/6ShDS35MwkPPNHXd0CjxtGBOCHdZRlvZ9
lgpOYQLWnoe1HgxeV41FXnu5VowpWNVFoATioOYhzctVwun5hbplWIbZGKLBxASSB/65nAKZmw0W
yBoWR8bFQBwCQh8+yOykzL61Vh56VbmNR4mpHxkO3yJ626s1IgVCoiNK/tQf+kElTqI7XWIYaCIm
wg4nZkHmGc4cjoY7zBAphhTfDKINfCIWsCLLgR4drpxSqGJyiF6G/IdnuCIO6OLEweJHtYMq0uIR
2N8tes1n8OIqkuHd9YIRwslhjF4z+mDfKWEQWpzRuZ/THV+vVCMPHl83ZmOdSF2mSOMCLR3SfWM2
pqM4juM3mkw4ypAS1mEfIGMNhGIDfaDKcMrKWJEMjYsvlQX+cWC5BOTT0Yk10F0mnSNA4hHC5B0n
iV4IJuTnFd89pt5DYoxFyuMmSqIfKqMedVA/eh4R2uJHjiTU1d9JlmRK8mPoXSDy9eBEqmRIrmQd
zmRGsowzWmDEzSNH/v6BPQJe0m0g/KHHOqoj6jkfIglk/rGkSjIlS14COcKUUg7ljfwdPsYfUaLj
EmalTWYNLrij9IVjJMKhRwKlU95kxI2iTdriTIrLWWbPWhYEVC7dGdpLW8ok8s3EyxGkWX6lSS5l
GXbEs4Gk/DVkXHrjYaakVdolSSIm/DGmNwKeQk6lSCZmRRpKXLok/d2kXwLLO/4DwxHbuMWkvQnh
D7ojL6VmUValQU4laupdUd7bV76mVvojyjRf0cndEH7gbmolNc5mQt4mXBbhKOqCvMHEaO6OMNqR
bShULoiaUmCbPy0nTOwbdf5TDiaFA4hT40ynkazScSYFs3XiRA0my1gUG3lKlAPcoS5IW3r2k7DJ
Wni+J+yMp1/MGn2ijrj1JEesGn/mZ4rAmmiMGoASTqdBm2s4wARMWsMVqIc8wIJOgLV5xp9J2qRB
GobGGaJlKId2qId+qKEt6KVdRwPQG4ieKIqmaIZuqIq2KAY4x4Q6qIzOKI3WqI3eKI7mqI7uKI/2
qI/+KJAGqZAOKZEWqZEeKZImqZIuKZM2qZM+KZRGqZROKZVWqZVeKZZmqZZuKZd2qZd+KZiGqZiO
KZmWqZmeKZqmqZpOWwgAADs=
------=_NextPart_6E0_0ECB_33898246.7652DB0D--




From sip-bounces@ietf.org Sun Apr 01 19:51:18 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HY9nB-0007MP-Sa; Sun, 01 Apr 2007 19:49:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HY9n9-0007MK-SY
	for sip@ietf.org; Sun, 01 Apr 2007 19:48:59 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HY9n8-0006N7-IZ
	for sip@ietf.org; Sun, 01 Apr 2007 19:48:59 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l31Nmrc26472; Sun, 1 Apr 2007 23:48:54 GMT
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Sun, 1 Apr 2007 18:48:24 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF0FD42CED@zrc2hxm0.corp.nortel.com>
In-Reply-To: <C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme
thread-index: Acd0KtH2K42g3RXeSbKdfmUg+7JPBAAjVkYg
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com>
	<7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se>
	<1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com>
	<C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
From: "Francois Audet" <audet@nortel.com>
To: "Cullen Jennings" <fluffy@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: IETF SIP List <sip@ietf.org>,
	"Christer Holmberg \(\(JO/LMF\)\)" <christer.holmberg@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Yes, and unlike Tel, you can also apply RFC 4474 to sip and sips URI.=20

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]=20
> Sent: Saturday, March 31, 2007 23:55
> To: Audet, Francois (SC100:3055)
> Cc: Christer Holmberg ((JO/LMF)); IETF SIP List
> Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme
>=20
>=20
> I will also add that a sips URI can occur place other than=20
> the request URI - for example, a Refer-To header field value.=20
>  In this case a proxy require will not capture the required=20
> semantics. This has all been discussed before.
>=20
> On a side note, a great way to get sips protection for a tel=20
> URL is convert it from a tel to sips.
>=20
> Cullen <with my individual hat on>
>=20
>=20
>=20
> On Mar 27, 2007, at 4:31 PM, Francois Audet wrote:
>=20
> > The answer was, "yes, it has been considered".
> >
> > But it has been determined that it would cause more harm to change=20
> > from SIPS to another mechanism at this point, because of=20
> the precedent=20
> > in RFC 3261.
> >
> > It's probably somewhere in the archives for and various reports.
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip

From sip-bounces@ietf.org Sun Apr 01 19:51:18 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HY9o1-0008A9-Vs; Sun, 01 Apr 2007 19:49:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HY9nz-00088n-TL
	for sip@ietf.org; Sun, 01 Apr 2007 19:49:51 -0400
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HY9ny-0006Os-L3
	for sip@ietf.org; Sun, 01 Apr 2007 19:49:51 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	l31NnNm13249; Sun, 1 Apr 2007 23:49:23 GMT
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Sun, 1 Apr 2007 18:49:46 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF0FD42CEE@zrc2hxm0.corp.nortel.com>
In-Reply-To: <17935.25089.520922.880147@harjus.tutpro.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme
thread-index: Acd0MRNeP7hcdKAvQAmLiDVkua/trwAhzt/w
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com>
	<7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se>
	<1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com>
	<C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
	<17935.25089.520922.880147@harjus.tutpro.com>
From: "Francois Audet" <audet@nortel.com>
To: "Juha Heinanen" <jh@tutpro.com>, "Cullen Jennings" <fluffy@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: IETF SIP List <sip@ietf.org>,
	"Christer Holmberg \(\(JO/LMF\)\)" <christer.holmberg@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

You would use that of the service provider.
=20

> -----Original Message-----
> From: Juha Heinanen [mailto:jh@tutpro.com]=20
> Sent: Sunday, April 01, 2007 00:41
> To: Cullen Jennings
> Cc: Audet, Francois (SC100:3055); IETF SIP List; Christer=20
> Holmberg ((JO/LMF))
> Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme
>=20
> Cullen Jennings writes:
>=20
>  > On a side note, a great way to get sips protection for a=20
> tel URL is  > convert it from a tel to sips.
>=20
> how can i refer-to or 302 someone securely to pstn without=20
> tels?  if i would use sips, i cannot place my my own domain=20
> in the uri.
>=20
> -- juha
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip





From sip-bounces@ietf.org Sun Apr 01 19:51:18 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HY9nB-0007MP-Sa; Sun, 01 Apr 2007 19:49:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HY9n9-0007MK-SY
	for sip@ietf.org; Sun, 01 Apr 2007 19:48:59 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HY9n8-0006N7-IZ
	for sip@ietf.org; Sun, 01 Apr 2007 19:48:59 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l31Nmrc26472; Sun, 1 Apr 2007 23:48:54 GMT
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Sun, 1 Apr 2007 18:48:24 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF0FD42CED@zrc2hxm0.corp.nortel.com>
In-Reply-To: <C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme
thread-index: Acd0KtH2K42g3RXeSbKdfmUg+7JPBAAjVkYg
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com>
	<7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se>
	<1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com>
	<C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
From: "Francois Audet" <audet@nortel.com>
To: "Cullen Jennings" <fluffy@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: IETF SIP List <sip@ietf.org>,
	"Christer Holmberg \(\(JO/LMF\)\)" <christer.holmberg@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Yes, and unlike Tel, you can also apply RFC 4474 to sip and sips URI.=20

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]=20
> Sent: Saturday, March 31, 2007 23:55
> To: Audet, Francois (SC100:3055)
> Cc: Christer Holmberg ((JO/LMF)); IETF SIP List
> Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme
>=20
>=20
> I will also add that a sips URI can occur place other than=20
> the request URI - for example, a Refer-To header field value.=20
>  In this case a proxy require will not capture the required=20
> semantics. This has all been discussed before.
>=20
> On a side note, a great way to get sips protection for a tel=20
> URL is convert it from a tel to sips.
>=20
> Cullen <with my individual hat on>
>=20
>=20
>=20
> On Mar 27, 2007, at 4:31 PM, Francois Audet wrote:
>=20
> > The answer was, "yes, it has been considered".
> >
> > But it has been determined that it would cause more harm to change=20
> > from SIPS to another mechanism at this point, because of=20
> the precedent=20
> > in RFC 3261.
> >
> > It's probably somewhere in the archives for and various reports.
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip

From sip-bounces@ietf.org Sun Apr 01 19:51:18 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HY9o1-0008A9-Vs; Sun, 01 Apr 2007 19:49:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HY9nz-00088n-TL
	for sip@ietf.org; Sun, 01 Apr 2007 19:49:51 -0400
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HY9ny-0006Os-L3
	for sip@ietf.org; Sun, 01 Apr 2007 19:49:51 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	l31NnNm13249; Sun, 1 Apr 2007 23:49:23 GMT
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Sun, 1 Apr 2007 18:49:46 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF0FD42CEE@zrc2hxm0.corp.nortel.com>
In-Reply-To: <17935.25089.520922.880147@harjus.tutpro.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme
thread-index: Acd0MRNeP7hcdKAvQAmLiDVkua/trwAhzt/w
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com>
	<7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se>
	<1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com>
	<C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
	<17935.25089.520922.880147@harjus.tutpro.com>
From: "Francois Audet" <audet@nortel.com>
To: "Juha Heinanen" <jh@tutpro.com>, "Cullen Jennings" <fluffy@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: IETF SIP List <sip@ietf.org>,
	"Christer Holmberg \(\(JO/LMF\)\)" <christer.holmberg@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

You would use that of the service provider.
=20

> -----Original Message-----
> From: Juha Heinanen [mailto:jh@tutpro.com]=20
> Sent: Sunday, April 01, 2007 00:41
> To: Cullen Jennings
> Cc: Audet, Francois (SC100:3055); IETF SIP List; Christer=20
> Holmberg ((JO/LMF))
> Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme
>=20
> Cullen Jennings writes:
>=20
>  > On a side note, a great way to get sips protection for a=20
> tel URL is  > convert it from a tel to sips.
>=20
> how can i refer-to or 302 someone securely to pstn without=20
> tels?  if i would use sips, i cannot place my my own domain=20
> in the uri.
>=20
> -- juha
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip





From sip-bounces@ietf.org Sun Apr 01 20:31:28 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYAQy-00006k-T6; Sun, 01 Apr 2007 20:30:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYAQx-0008VP-Dz
	for sip@ietf.org; Sun, 01 Apr 2007 20:30:07 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYAQw-0005Ru-1y
	for sip@ietf.org; Sun, 01 Apr 2007 20:30:07 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l320Tkb00828; Mon, 2 Apr 2007 00:29:46 GMT
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Sun, 1 Apr 2007 19:29:19 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E61205E7AC@zrc2hxm2.corp.nortel.com>
In-Reply-To: <C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme
thread-index: Acd0K1jQP860XwImSdS7wfupuQ1dcwAkXyjw
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Cullen Jennings" <fluffy@cisco.com>, "Francois Audet" <audet@nortel.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: IETF SIP List <sip@ietf.org>,
	"Christer Holmberg \(\(JO/LMF\)\)" <christer.holmberg@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi,

   I may be missing the point here. Proxy-Require tag will make the
individual REFER routing secure, while the additional tag in the Require
header will make sure that UAS generate the further requests as a result
of REFER method securely.

   Pl correct me, if I am missing something.

   What will be done with the REPLACES header? Whether a dialog created
with SIPS can be considered SECURE for the replacement with unsecure
dialog ? We need a REQUIRE tag for all feature control.


Thx
Samir

>-----Original Message-----
>From: Cullen Jennings [mailto:fluffy@cisco.com]=20
>Sent: Saturday, March 31, 2007 11:55 PM
>To: Audet, Francois (SC100:3055)
>Cc: IETF SIP List; Christer Holmberg ((JO/LMF))
>Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme
>
>
>I will also add that a sips URI can occur place other than the=20
>request URI - for example, a Refer-To header field value.  In=20
>this case a proxy require will not capture the required=20
>semantics. This has all been discussed before.
>
>On a side note, a great way to get sips protection for a tel=20
>URL is convert it from a tel to sips.
>
>Cullen <with my individual hat on>
>
>
>
>On Mar 27, 2007, at 4:31 PM, Francois Audet wrote:
>
>> The answer was, "yes, it has been considered".
>>
>> But it has been determined that it would cause more harm to change=20
>> from SIPS to another mechanism at this point, because of the=20
>precedent=20
>> in RFC 3261.
>>
>> It's probably somewhere in the archives for and various reports.
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol Use=20
>sip-implementors@cs.columbia.edu for questions on current sip=20
>Use sipping@ietf.org for new developments on the application of sip
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 01 22:59:34 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYCj8-0007gG-83; Sun, 01 Apr 2007 22:57:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYCj6-0007g1-EO
	for sip@ietf.org; Sun, 01 Apr 2007 22:57:00 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYCj5-0005Pp-4p
	for sip@ietf.org; Sun, 01 Apr 2007 22:57:00 -0400
Received: from [192.168.10.100] (rcdn4-dmznat-gw1-nat-27.cisco.com
	[12.5.186.27]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3223D0C018522
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Sun, 1 Apr 2007 21:03:15 -0500
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FD42CEE@zrc2hxm0.corp.nortel.com>
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com>
	<7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se>
	<1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com>
	<C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
	<17935.25089.520922.880147@harjus.tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF0FD42CEE@zrc2hxm0.corp.nortel.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <903C033C-A61A-46CA-AA07-CB107C3158DB@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme
Date: Sun, 1 Apr 2007 21:56:43 -0500
To: "Francois Audet" <audet@nortel.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: Cullen Jennings <fluffy@cisco.com>, IETF SIP List <sip@ietf.org>,
	Juha Heinanen <jh@tutpro.com>,
	"Christer Holmberg \(\(JO/LMF\)\)" <christer.holmberg@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


But I don't know who his service provider is. So how can I know how  
to populate the domain-part of the request?

--
Dean

On Apr 1, 2007, at 6:49 PM, Francois Audet wrote:

> You would use that of the service provider.
>
>
>>
>> Cullen Jennings writes:
>>
>>> On a side note, a great way to get sips protection for a
>> tel URL is  > convert it from a tel to sips.
>>
>> how can i refer-to or 302 someone securely to pstn without
>> tels?  if i would use sips, i cannot place my my own domain
>> in the uri.
>>
>> -- juha
>>
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 01:54:29 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYFTO-0001E4-9H; Mon, 02 Apr 2007 01:52:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYFTM-0001Cc-CW
	for sip@ietf.org; Mon, 02 Apr 2007 01:52:56 -0400
Received: from harjus.tutpro.com ([192.98.100.3])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYFTL-0004Mz-2D
	for sip@ietf.org; Mon, 02 Apr 2007 01:52:56 -0400
Received: by harjus.tutpro.com (Postfix, from userid 1000)
	id 84B64AC2CB; Mon,  2 Apr 2007 08:52:49 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17936.39473.398905.855656@harjus.tutpro.com>
Date: Mon, 2 Apr 2007 08:52:49 +0300
To: "Francois Audet" <audet@nortel.com>
Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FD42CEE@zrc2hxm0.corp.nortel.com>
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com>
	<7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se>
	<1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com>
	<C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
	<17935.25089.520922.880147@harjus.tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF0FD42CEE@zrc2hxm0.corp.nortel.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: Cullen Jennings <fluffy@cisco.com>, IETF SIP List <sip@ietf.org>,
	"Christer Holmberg \(\(JO/LMF\)\)" <christer.holmberg@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Francois Audet writes:

 > > how can i refer-to or 302 someone securely to pstn without 
 > > tels?  if i would use sips, i cannot place my my own domain 
 > > in the uri.

 > You would use that of the service provider.

which service provider?  i don't have any idea how someone who calls me
reaches pstn.  so please tell me how i can refer or 302 someone securely
to my pstn number.  if you don't have a good answer, please include tels
in your i-d.

-- juha

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 03:13:46 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYGiT-0007XX-TF; Mon, 02 Apr 2007 03:12:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYGiS-0007VF-OW
	for sip@ietf.org; Mon, 02 Apr 2007 03:12:36 -0400
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYGiO-00032o-EN
	for sip@ietf.org; Mon, 02 Apr 2007 03:12:36 -0400
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	D1841213F0; Mon,  2 Apr 2007 09:12:27 +0200 (CEST)
X-AuditID: c1b4fb3e-ad1e9bb0000061ca-6b-4610acdbe2d3 
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	C3768213D7; Mon,  2 Apr 2007 09:12:27 +0200 (CEST)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 2 Apr 2007 09:12:27 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme
Date: Mon, 2 Apr 2007 09:12:26 +0200
Message-ID: <7374777208BDC7449D5620EF942325670309DBB3@esealmw113.eemea.ericsson.se>
In-Reply-To: <C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme
Thread-Index: Acd0KtBk4W53EBlhQhu52WRWZtuKXgAy16lQ
From: "Christer Holmberg \(JO/LMF\)" <christer.holmberg@ericsson.com>
To: "Cullen Jennings" <fluffy@cisco.com>, "Francois Audet" <audet@nortel.com>
X-OriginalArrivalTime: 02 Apr 2007 07:12:27.0682 (UTC)
	FILETIME=[454D5020:01C774F6]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


Hi,=20

>I will also add that a sips URI can occur place other than=20
>the request URI - for example, a Refer-To header field value.=20
>In this case a proxy require will not capture the required=20
>semantics. This has all been discussed before.
>=20
>On a side note, a great way to get sips protection for a tel=20
>URL is convert it from a tel to sips.

Then, why do we need tel in the first place?

Regards,

Christer



> On Mar 27, 2007, at 4:31 PM, Francois Audet wrote:
>=20
> > The answer was, "yes, it has been considered".
> >
> > But it has been determined that it would cause more harm to change=20
> > from SIPS to another mechanism at this point, because of=20
> the precedent=20
> > in RFC 3261.
> >
> > It's probably somewhere in the archives for and various reports.
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 03:38:33 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYH7D-0008CK-6B; Mon, 02 Apr 2007 03:38:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYH7C-0008C8-26
	for sip@ietf.org; Mon, 02 Apr 2007 03:38:10 -0400
Received: from harjus.tutpro.com ([192.98.100.3])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYH7A-0001tj-7t
	for sip@ietf.org; Mon, 02 Apr 2007 03:38:10 -0400
Received: by harjus.tutpro.com (Postfix, from userid 1000)
	id 43EDFAC2CB; Mon,  2 Apr 2007 10:38:07 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17936.45791.216617.191428@harjus.tutpro.com>
Date: Mon, 2 Apr 2007 10:38:07 +0300
To: "Christer Holmberg \(JO/LMF\)" <christer.holmberg@ericsson.com>
Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme
In-Reply-To: <7374777208BDC7449D5620EF942325670309DBB3@esealmw113.eemea.ericsson.se>
References: <C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
	<7374777208BDC7449D5620EF942325670309DBB3@esealmw113.eemea.ericsson.se>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed
Cc: Cullen Jennings <fluffy@cisco.com>, IETF SIP List <sip@ietf.org>,
	Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Christer Holmberg \(JO/LMF\) writes:

 > Then, why do we need tel in the first place?

the only reason that i have found is the refer/302 problem to pstn.

-- juha

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 08:02:16 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYLCo-0002iQ-ME; Mon, 02 Apr 2007 08:00:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYLCm-0002gf-Cz
	for sip@ietf.org; Mon, 02 Apr 2007 08:00:12 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYLCl-0003vz-2N
	for sip@ietf.org; Mon, 02 Apr 2007 08:00:12 -0400
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-2.cisco.com with ESMTP; 02 Apr 2007 08:00:10 -0400
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l32C0AiY001602; 
	Mon, 2 Apr 2007 08:00:10 -0400
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 l32BxRH3007667; 
	Mon, 2 Apr 2007 11:59:58 GMT
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.1830); 
	Mon, 2 Apr 2007 07:58:47 -0400
Received: from [10.86.242.109] ([10.86.242.109]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 2 Apr 2007 07:58:46 -0400
Message-ID: <4610EFF6.3010304@cisco.com>
Date: Mon, 02 Apr 2007 07:58:46 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Juha Heinanen <jh@tutpro.com>
Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com>	<7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se>	<1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com>	<C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>	<17935.25089.520922.880147@harjus.tutpro.com>	<1ECE0EB50388174790F9694F77522CCF0FD42CEE@zrc2hxm0.corp.nortel.com>
	<17936.39473.398905.855656@harjus.tutpro.com>
In-Reply-To: <17936.39473.398905.855656@harjus.tutpro.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 Apr 2007 11:58:46.0967 (UTC)
	FILETIME=[44F42C70:01C7751E]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1587; t=1175515210;
	x=1176379210; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20RE=3A=20Securing=20Other=20URI=20(Tel=20URI)=
	20scheme |Sender:=20 |To:=20Juha=20Heinanen=20<jh@tutpro.com>;
	bh=hqjhRI9FVU1AQcbH2NzbhqP1+T7fxWKy6nhlNigpPGE=;
	b=NgVfdxrXUMW2erIIbY7iydwv9EUF9mC/nzgARha7t8TjTilp7AeJGhdTh+9DxptZe/Lwz0KT
	Uweli8zwXTLqOTWVxeIXYT6fJHGfuW1KVf+w3FbvJkQyfdyV1FydCINR;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: Cullen Jennings <fluffy@cisco.com>, IETF SIP List <sip@ietf.org>,
	Francois Audet <audet@nortel.com>,
	"Christer Holmberg \(\(JO/LMF\)\)" <christer.holmberg@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

IMO you may use the domain of any provider that will be willing to route 
the call to the proper destination. E.g. you could use your own provider 
if you have one and it does this. (I realize this is a bit controversial 
- not all agree this is a proper usage.)

However this will not guarantee you will get a secure call to a 
destination on the PSTN. Once the call leaves the sip network all bets 
are off.

IMO a key value of TEL is that it does not dictate the protocol used to 
reach the destination, whereas a sip/sips URI does. In theory a TELS URI 
could specify a requirement to reach a destination securely without 
specifying how. But in practice I don't think we currently know how to 
realize that.

	Paul

Juha Heinanen wrote:
> Francois Audet writes:
> 
>  > > how can i refer-to or 302 someone securely to pstn without 
>  > > tels?  if i would use sips, i cannot place my my own domain 
>  > > in the uri.
> 
>  > You would use that of the service provider.
> 
> which service provider?  i don't have any idea how someone who calls me
> reaches pstn.  so please tell me how i can refer or 302 someone securely
> to my pstn number.  if you don't have a good answer, please include tels
> in your i-d.
> 
> -- juha
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 08:08:36 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYLKT-0000sR-HQ; Mon, 02 Apr 2007 08:08:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYLKS-0000sL-7x
	for sip@ietf.org; Mon, 02 Apr 2007 08:08:08 -0400
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYLKM-0005NR-QO
	for sip@ietf.org; Mon, 02 Apr 2007 08:08:08 -0400
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	2E7EE213F4; Mon,  2 Apr 2007 14:07:58 +0200 (CEST)
X-AuditID: c1b4fb3e-ad1e9bb0000061ca-a0-4610f21e0207 
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	10171213E3; Mon,  2 Apr 2007 14:07:58 +0200 (CEST)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 2 Apr 2007 14:07:57 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme
Date: Mon, 2 Apr 2007 14:07:56 +0200
Message-ID: <7374777208BDC7449D5620EF9423256703158364@esealmw113.eemea.ericsson.se>
In-Reply-To: <4610EFF6.3010304@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme
Thread-Index: Acd1HnvUnu3RlgoSQkiNXPtdIdRopwAAGcSQ
From: "Christer Holmberg \(JO/LMF\)" <christer.holmberg@ericsson.com>
To: "Paul Kyzivat" <pkyzivat@cisco.com>,
	"Juha Heinanen" <jh@tutpro.com>
X-OriginalArrivalTime: 02 Apr 2007 12:07:57.0704 (UTC)
	FILETIME=[8D37F880:01C7751F]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: Cullen Jennings <fluffy@cisco.com>, IETF SIP List <sip@ietf.org>,
	Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


=20
>IMO you may use the domain of any provider that will be=20
>willing to route the call to the proper destination. E.g. you=20
>could use your own provider if you have one and it does this.=20
>(I realize this is a bit controversial
>- not all agree this is a proper usage.)
>=20
>However this will not guarantee you will get a secure call to=20
>a destination on the PSTN. Once the call leaves the sip=20
>network all bets are off.
>=20
>IMO a key value of TEL is that it does not dictate the=20
>protocol used to reach the destination, whereas a sip/sips=20
>URI does.

I am not sure I understand correctly, but if you use sip/sips and reach
a PSTN gateway you will not have SIP all the way (it is nowhere said
that you can't send sip to a PSTN gateway).

So, from that perspective I don't see a difference between sip and tel.
Both are only schemes, and if they are used with SIP it's quite obvious
that SIP is going to be the protocol. If they reach a gateway something
else will be used - no matter whether the scheme is sip or tel.

Regards,

Christer

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 08:10:21 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYLMX-0001PS-3X; Mon, 02 Apr 2007 08:10:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYLMV-0001PJ-8W
	for sip@ietf.org; Mon, 02 Apr 2007 08:10:15 -0400
Received: from harjus.tutpro.com ([192.98.100.3])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYLMS-0005tg-St
	for sip@ietf.org; Mon, 02 Apr 2007 08:10:15 -0400
Received: by harjus.tutpro.com (Postfix, from userid 1000)
	id E7D44AC2D4; Mon,  2 Apr 2007 15:10:11 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17936.62115.803798.428798@harjus.tutpro.com>
Date: Mon, 2 Apr 2007 15:10:11 +0300
To: Paul Kyzivat <pkyzivat@cisco.com>
Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme
In-Reply-To: <4610EFF6.3010304@cisco.com>
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com>
	<7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se>
	<1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com>
	<C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
	<17935.25089.520922.880147@harjus.tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF0FD42CEE@zrc2hxm0.corp.nortel.com>
	<17936.39473.398905.855656@harjus.tutpro.com>
	<4610EFF6.3010304@cisco.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: Cullen Jennings <fluffy@cisco.com>, IETF SIP List <sip@ietf.org>,
	Francois Audet <audet@nortel.com>,
	"Christer Holmberg \(\(JO/LMF\)\)" <christer.holmberg@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Paul Kyzivat writes:

 > IMO you may use the domain of any provider that will be willing to route 
 > the call to the proper destination. E.g. you could use your own provider 
 > if you have one and it does this. (I realize this is a bit controversial 
 > - not all agree this is a proper usage.)

the domain would need to be one with which the caller has made pstn
gateway agreement.  i cannot have any clue who that might be.  if i put
my own domain there, my proxy would reject such a call.

 > However this will not guarantee you will get a secure call to a 
 > destination on the PSTN. Once the call leaves the sip network all bets 
 > are off.

that was not my point.  the point of using sips or tels is that tls is
used for signaling from calling sip ua to called sip ua, in this case
the pstn gw.

 > IMO a key value of TEL is that it does not dictate the protocol used to 
 > reach the destination, whereas a sip/sips URI does. In theory a TELS URI 
 > could specify a requirement to reach a destination securely without 
 > specifying how. But in practice I don't think we currently know how to 
 > realize that.

what i'm trying to say is that IF we have sips, we also have to have
tels.  having one without another makes NO sense.  the solution to this
deprecate sips.

-- juha

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 10:50:38 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYNpP-0002Wc-2C; Mon, 02 Apr 2007 10:48:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYNpN-0002WR-EP
	for sip@ietf.org; Mon, 02 Apr 2007 10:48:13 -0400
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HYNpM-0003Ry-3t
	for sip@ietf.org; Mon, 02 Apr 2007 10:48:13 -0400
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: Re: [Sip] RE: Securing Other URI (Tel URI) scheme
Date: Mon, 2 Apr 2007 16:44:52 +0200
Message-ID: <32755D354E6B65498C3BD9FD496C7D466B1D68@oefeg-s04.oefeg.loc>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme
Thread-Index: Acd1IAHXD/6c00MrQjCzUOXW6vJDegAFXa+A
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com><7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com><C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com><17935.25089.520922.880147@harjus.tutpro.com><1ECE0EB50388174790F9694F77522CCF0FD42CEE@zrc2hxm0.corp.nortel.com><17936.39473.398905.855656@harjus.tutpro.com><4610EFF6.3010304@cisco.com>
	<17936.62115.803798.428798@harjus.tutpro.com>
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "Juha Heinanen" <jh@tutpro.com>,
	"Paul Kyzivat" <pkyzivat@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Cc: IETF SIP List <sip@ietf.org>, Francois Audet <audet@nortel.com>,
	"Christer Holmberg \(\(JO/LMF\)\)" <christer.holmberg@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

=20
Just for my information:

>that was not my point.  the point of using sips or tels is that tls is
>used for signaling from calling sip ua to called sip ua, in this case
>the pstn gw.

Does this also mean that sips only needs to work from UA to the next =
B2BUA?
=20
Richard

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 11:08:03 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYO7d-00014X-8q; Mon, 02 Apr 2007 11:07:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYO7b-00014S-JQ
	for sip@ietf.org; Mon, 02 Apr 2007 11:07:03 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYO7Z-0005jv-A7
	for sip@ietf.org; Mon, 02 Apr 2007 11:07:03 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l32F6ib22500; Mon, 2 Apr 2007 15:06:44 GMT
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: [Sip] RE: Securing Other URI (Tel URI) scheme
Date: Mon, 2 Apr 2007 10:06:36 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF0FDBC1DE@zrc2hxm0.corp.nortel.com>
In-Reply-To: <903C033C-A61A-46CA-AA07-CB107C3158DB@softarmor.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme
thread-index: Acd00pqRml5/StrbSwy5O2qvsbBXOgAZdTYg
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com>
	<7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se>
	<1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com>
	<C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
	<17935.25089.520922.880147@harjus.tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF0FD42CEE@zrc2hxm0.corp.nortel.com>
	<903C033C-A61A-46CA-AA07-CB107C3158DB@softarmor.com>
From: "Francois Audet" <audet@nortel.com>
To: "Dean Willis" <dean.willis@softarmor.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: Cullen Jennings <fluffy@cisco.com>, IETF SIP List <sip@ietf.org>,
	Juha Heinanen <jh@tutpro.com>,
	"Christer Holmberg \(\(JO/LMF\)\)" <christer.holmberg@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Then you can't secure it.

A Tels URI wouldn't fix this problem. Somebody has to be responsible for
it.=20

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]=20
> Sent: Sunday, April 01, 2007 19:57
> To: Audet, Francois (SC100:3055)
> Cc: Juha Heinanen; Cullen Jennings; IETF SIP List; Christer=20
> Holmberg ((JO/LMF))
> Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme
>=20
>=20
> But I don't know who his service provider is. So how can I=20
> know how to populate the domain-part of the request?
>=20
> --
> Dean
>=20
> On Apr 1, 2007, at 6:49 PM, Francois Audet wrote:
>=20
> > You would use that of the service provider.
> >
> >
> >>
> >> Cullen Jennings writes:
> >>
> >>> On a side note, a great way to get sips protection for a
> >> tel URL is  > convert it from a tel to sips.
> >>
> >> how can i refer-to or 302 someone securely to pstn without=20
> tels?  if=20
> >> i would use sips, i cannot place my my own domain in the uri.
> >>
> >> -- juha
> >>
> >
>=20
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 11:14:19 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYOEQ-0007gD-LQ; Mon, 02 Apr 2007 11:14:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOEP-0007g8-Gg
	for sip@ietf.org; Mon, 02 Apr 2007 11:14:05 -0400
Received: from harjus.tutpro.com ([192.98.100.3])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYOEN-0006fi-6B
	for sip@ietf.org; Mon, 02 Apr 2007 11:14:05 -0400
Received: by harjus.tutpro.com (Postfix, from userid 1000)
	id 3E267AC2D4; Mon,  2 Apr 2007 18:14:02 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17937.7610.186102.505665@harjus.tutpro.com>
Date: Mon, 2 Apr 2007 18:14:02 +0300
To: "Stastny Richard" <Richard.Stastny@oefeg.at>
Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D466B1D68@oefeg-s04.oefeg.loc>
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com>
	<7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se>
	<1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com>
	<C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
	<17935.25089.520922.880147@harjus.tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF0FD42CEE@zrc2hxm0.corp.nortel.com>
	<17936.39473.398905.855656@harjus.tutpro.com>
	<4610EFF6.3010304@cisco.com>
	<17936.62115.803798.428798@harjus.tutpro.com>
	<32755D354E6B65498C3BD9FD496C7D466B1D68@oefeg-s04.oefeg.loc>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Cc: IETF SIP List <sip@ietf.org>, Paul Kyzivat <pkyzivat@cisco.com>,
	Francois Audet <audet@nortel.com>,
	"Christer Holmberg \(\(JO/LMF\)\)" <christer.holmberg@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Stastny Richard writes:

 > Does this also mean that sips only needs to work from UA to the next
 > B2BUA?

sure.  i don't remember that rfc3161 nor any other rfc has standardized
anything about B2BUAs.  as far as ietf sip specs are concerned, a b2bua
is a sip ua like any other sip ua.

-- juha

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 11:14:39 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYOEx-0007sr-Hg; Mon, 02 Apr 2007 11:14:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOEv-0007rh-Ss
	for sip@ietf.org; Mon, 02 Apr 2007 11:14:37 -0400
Received: from zrtps0kn.nortel.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYOEu-0006hu-Lv
	for sip@ietf.org; Mon, 02 Apr 2007 11:14:37 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l32FEW804516; Mon, 2 Apr 2007 15:14:32 GMT
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: [Sip] RE: Securing Other URI (Tel URI) scheme
Date: Mon, 2 Apr 2007 10:14:31 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF0FDBC211@zrc2hxm0.corp.nortel.com>
In-Reply-To: <17936.45791.216617.191428@harjus.tutpro.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme
thread-index: Acd0+dz9ipVKsJDTQ3OsmPKy/5pSJAAP6JSw
References: <C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
	<7374777208BDC7449D5620EF942325670309DBB3@esealmw113.eemea.ericsson.se>
	<17936.45791.216617.191428@harjus.tutpro.com>
From: "Francois Audet" <audet@nortel.com>
To: "Juha Heinanen" <jh@tutpro.com>,
	"Christer Holmberg \(JO/LMF\)" <christer.holmberg@ericsson.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: Cullen Jennings <fluffy@cisco.com>, IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Than can never be secure. Unless you use sips (and you know the service
provider), and the PSTN
leg will have PSTN level security.=20

> -----Original Message-----
> From: Juha Heinanen [mailto:jh@tutpro.com]=20
> Sent: Monday, April 02, 2007 00:38
> To: Christer Holmberg (JO/LMF)
> Cc: Cullen Jennings; Audet, Francois (SC100:3055); IETF SIP List
> Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme
>=20
> Christer Holmberg \(JO/LMF\) writes:
>=20
>  > Then, why do we need tel in the first place?
>=20
> the only reason that i have found is the refer/302 problem to pstn.
>=20
> -- juha
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 11:17:57 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYOI0-00037H-KA; Mon, 02 Apr 2007 11:17:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOHy-000302-RX
	for sip@ietf.org; Mon, 02 Apr 2007 11:17:46 -0400
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HYOHx-000760-Fs
	for sip@ietf.org; Mon, 02 Apr 2007 11:17:46 -0400
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: Re: [Sip] RE: Securing Other URI (Tel URI) scheme
Date: Mon, 2 Apr 2007 17:17:02 +0200
Message-ID: <32755D354E6B65498C3BD9FD496C7D466B1D69@oefeg-s04.oefeg.loc>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme
Thread-Index: Acd1OY5c9Ly21X8bSiOohG9VoG/wmwAAGj4B
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com><7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se><1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com><C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com><17935.25089.520922.880147@harjus.tutpro.com><1ECE0EB50388174790F9694F77522CCF0FD42CEE@zrc2hxm0.corp.nortel.com><17936.39473.398905.855656@harjus.tutpro.com><4610EFF6.3010304@cisco.com><17936.62115.803798.428798@harjus.tutpro.com><32755D354E6B65498C3BD9FD496C7D466B1D68@oefeg-s04.oefeg.loc>
	<17937.7610.186102.505665@harjus.tutpro.com>
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "Juha Heinanen" <jh@tutpro.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: IETF SIP List <sip@ietf.org>, Paul Kyzivat <pkyzivat@cisco.com>,
	Francois Audet <audet@nortel.com>,
	"Christer Holmberg \(\(JO/LMF\)\)" <christer.holmberg@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

So sips is useless, at least in IMS
=20
Richard

________________________________

Von: Juha Heinanen [mailto:jh@tutpro.com]
Gesendet: Mo 02.04.2007 17:14
An: Stastny Richard
Cc: Paul Kyzivat; IETF SIP List; Francois Audet; Christer Holmberg =
((JO/LMF))
Betreff: Re: [Sip] RE: Securing Other URI (Tel URI) scheme



Stastny Richard writes:

 > Does this also mean that sips only needs to work from UA to the next
 > B2BUA?

sure.  i don't remember that rfc3161 nor any other rfc has standardized
anything about B2BUAs.  as far as ietf sip specs are concerned, a b2bua
is a sip ua like any other sip ua.

-- juha



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 11:20:04 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYOK1-0004GX-I6; Mon, 02 Apr 2007 11:19:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOJz-0004GN-TY
	for sip@ietf.org; Mon, 02 Apr 2007 11:19:51 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYOJy-0007Pq-IV
	for sip@ietf.org; Mon, 02 Apr 2007 11:19:51 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l32FJkb25517; Mon, 2 Apr 2007 15:19:46 GMT
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: [Sip] RE: Securing Other URI (Tel URI) scheme
Date: Mon, 2 Apr 2007 10:19:45 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF0FDBC22F@zrc2hxm0.corp.nortel.com>
In-Reply-To: <4610EFF6.3010304@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme
thread-index: Acd1Hnr9KgOvYLwmTia7xT6A/ZIEUwAG84DA
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com>
	<7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se>
	<1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com>
	<C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
	<17935.25089.520922.880147@harjus.tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF0FD42CEE@zrc2hxm0.corp.nortel.com>
	<17936.39473.398905.855656@harjus.tutpro.com>
	<4610EFF6.3010304@cisco.com>
From: "Francois Audet" <audet@nortel.com>
To: "Paul Kyzivat" <pkyzivat@cisco.com>, "Juha Heinanen" <jh@tutpro.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: Cullen Jennings <fluffy@cisco.com>, IETF SIP List <sip@ietf.org>,
	"Christer Holmberg \(\(JO/LMF\)\)" <christer.holmberg@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Exactly.

And by definition, tel can not be "secure" because the service provider
is arbitrary.=20

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20
> Sent: Monday, April 02, 2007 04:59
> To: Juha Heinanen
> Cc: Audet, Francois (SC100:3055); Cullen Jennings; IETF SIP=20
> List; Christer Holmberg ((JO/LMF))
> Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme
>=20
> IMO you may use the domain of any provider that will be=20
> willing to route the call to the proper destination. E.g. you=20
> could use your own provider if you have one and it does this.=20
> (I realize this is a bit controversial
> - not all agree this is a proper usage.)
>=20
> However this will not guarantee you will get a secure call to=20
> a destination on the PSTN. Once the call leaves the sip=20
> network all bets are off.
>=20
> IMO a key value of TEL is that it does not dictate the=20
> protocol used to reach the destination, whereas a sip/sips=20
> URI does. In theory a TELS URI could specify a requirement to=20
> reach a destination securely without specifying how. But in=20
> practice I don't think we currently know how to realize that.
>=20
> 	Paul
>=20
> Juha Heinanen wrote:
> > Francois Audet writes:
> >=20
> >  > > how can i refer-to or 302 someone securely to pstn=20
> without  > >=20
> > tels?  if i would use sips, i cannot place my my own domain  > > in=20
> > the uri.
> >=20
> >  > You would use that of the service provider.
> >=20
> > which service provider?  i don't have any idea how someone=20
> who calls=20
> > me reaches pstn.  so please tell me how i can refer or 302 someone=20
> > securely to my pstn number.  if you don't have a good=20
> answer, please=20
> > include tels in your i-d.
> >=20
> > -- juha
> >=20
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use=20
> > sip-implementors@cs.columbia.edu for questions on current sip Use=20
> > sipping@ietf.org for new developments on the application of sip
> >=20
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 11:23:23 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYONE-00073T-OS; Mon, 02 Apr 2007 11:23:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOND-00073M-9B
	for sip@ietf.org; Mon, 02 Apr 2007 11:23:11 -0400
Received: from harjus.tutpro.com ([192.98.100.3])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYONB-0007nJ-VQ
	for sip@ietf.org; Mon, 02 Apr 2007 11:23:11 -0400
Received: by harjus.tutpro.com (Postfix, from userid 1000)
	id 61E02AC2D4; Mon,  2 Apr 2007 18:23:09 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17937.8157.334255.39220@harjus.tutpro.com>
Date: Mon, 2 Apr 2007 18:23:09 +0300
To: "Francois Audet" <audet@nortel.com>
Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FDBC1DE@zrc2hxm0.corp.nortel.com>
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com>
	<7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se>
	<1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com>
	<C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
	<17935.25089.520922.880147@harjus.tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF0FD42CEE@zrc2hxm0.corp.nortel.com>
	<903C033C-A61A-46CA-AA07-CB107C3158DB@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF0FDBC1DE@zrc2hxm0.corp.nortel.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: Cullen Jennings <fluffy@cisco.com>, IETF SIP List <sip@ietf.org>,
	"Christer Holmberg \(\(JO/LMF\)\)" <christer.holmberg@ericsson.com>,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Francois Audet writes:

 > Then you can't secure it.
 > A Tels URI wouldn't fix this problem. Somebody has to be responsible for
 > it. 

i don't understand what you are trying to say.  of course i cannot
control what other peoples' UAs are doing nor can i control what other
peoples' proxies are doing.  there is no difference if a sip ua gets a
refer or 302 asking it to use tls or if a proxy gets a invite asking it
to use tls.  both can cheat.

-- juha

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 11:26:02 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYOPq-0000B6-PF; Mon, 02 Apr 2007 11:25:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOPp-0000Aw-GV
	for sip@ietf.org; Mon, 02 Apr 2007 11:25:53 -0400
Received: from harjus.tutpro.com ([192.98.100.3])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYOPo-0007zk-6F
	for sip@ietf.org; Mon, 02 Apr 2007 11:25:53 -0400
Received: by harjus.tutpro.com (Postfix, from userid 1000)
	id ABB8EAC2D4; Mon,  2 Apr 2007 18:25:51 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17937.8319.650988.18855@harjus.tutpro.com>
Date: Mon, 2 Apr 2007 18:25:51 +0300
To: "Stastny Richard" <Richard.Stastny@oefeg.at>
Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D466B1D69@oefeg-s04.oefeg.loc>
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com>
	<7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se>
	<1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com>
	<C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
	<17935.25089.520922.880147@harjus.tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF0FD42CEE@zrc2hxm0.corp.nortel.com>
	<17936.39473.398905.855656@harjus.tutpro.com>
	<4610EFF6.3010304@cisco.com>
	<17936.62115.803798.428798@harjus.tutpro.com>
	<32755D354E6B65498C3BD9FD496C7D466B1D68@oefeg-s04.oefeg.loc>
	<17937.7610.186102.505665@harjus.tutpro.com>
	<32755D354E6B65498C3BD9FD496C7D466B1D69@oefeg-s04.oefeg.loc>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed
Cc: IETF SIP List <sip@ietf.org>, Paul Kyzivat <pkyzivat@cisco.com>,
	Francois Audet <audet@nortel.com>,
	"Christer Holmberg \(\(JO/LMF\)\)" <christer.holmberg@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Stastny Richard writes:

 > So sips is useless, at least in IMS

good, yet another reason to get rid of it.

-- juha

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 11:28:23 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYOSC-0001Xt-VJ; Mon, 02 Apr 2007 11:28:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOSA-0001Xo-I2
	for sip@ietf.org; Mon, 02 Apr 2007 11:28:18 -0400
Received: from harjus.tutpro.com ([192.98.100.3])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYOS9-000885-8K
	for sip@ietf.org; Mon, 02 Apr 2007 11:28:18 -0400
Received: by harjus.tutpro.com (Postfix, from userid 1000)
	id AC307AC2D4; Mon,  2 Apr 2007 18:28:16 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17937.8464.638609.713272@harjus.tutpro.com>
Date: Mon, 2 Apr 2007 18:28:16 +0300
To: "Francois Audet" <audet@nortel.com>
Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FDBC22F@zrc2hxm0.corp.nortel.com>
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com>
	<7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se>
	<1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com>
	<C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
	<17935.25089.520922.880147@harjus.tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF0FD42CEE@zrc2hxm0.corp.nortel.com>
	<17936.39473.398905.855656@harjus.tutpro.com>
	<4610EFF6.3010304@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF0FDBC22F@zrc2hxm0.corp.nortel.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Cc: Cullen Jennings <fluffy@cisco.com>, IETF SIP List <sip@ietf.org>,
	Paul Kyzivat <pkyzivat@cisco.com>,
	"Christer Holmberg \(\(JO/LMF\)\)" <christer.holmberg@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Francois Audet writes:

 > And by definition, tel can not be "secure" because the service provider
 > is arbitrary. 

neither can sips be secure because sip service provider of the callee is
arbitrary.  isn't is a high time to stop this bullsh*t and announce sips
dead?

-- juha

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 11:32:57 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYOWW-00047q-H7; Mon, 02 Apr 2007 11:32:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOWU-00047f-Ik
	for sip@ietf.org; Mon, 02 Apr 2007 11:32:46 -0400
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYOWO-0008UL-4j
	for sip@ietf.org; Mon, 02 Apr 2007 11:32:46 -0400
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	5405F20961; Mon,  2 Apr 2007 17:32:21 +0200 (CEST)
X-AuditID: c1b4fb3c-a84eabb0000073d5-25-46112205a46e 
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	3972720469; Mon,  2 Apr 2007 17:32:21 +0200 (CEST)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 2 Apr 2007 17:32:21 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme
Date: Mon, 2 Apr 2007 17:32:20 +0200
Message-ID: <7374777208BDC7449D5620EF942325670319F9E9@esealmw113.eemea.ericsson.se>
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D466B1D69@oefeg-s04.oefeg.loc>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme
Thread-Index: Acd1OY5c9Ly21X8bSiOohG9VoG/wmwAAGj4BAABC7lA=
From: "Christer Holmberg \(JO/LMF\)" <christer.holmberg@ericsson.com>
To: "Stastny Richard" <Richard.Stastny@oefeg.at>,
	"Juha Heinanen" <jh@tutpro.com>
X-OriginalArrivalTime: 02 Apr 2007 15:32:21.0161 (UTC)
	FILETIME=[1ACF0190:01C7753C]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: IETF SIP List <sip@ietf.org>, Paul Kyzivat <pkyzivat@cisco.com>,
	Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

=20

>So sips is useless, at least in IMS

If you base your comment on B2BUAs, I'm pretty sure you'll also find
them elsewhere than in IMS...

Regards,

Christer



>=20
> Von: Juha Heinanen [mailto:jh@tutpro.com]
> Gesendet: Mo 02.04.2007 17:14
> An: Stastny Richard
> Cc: Paul Kyzivat; IETF SIP List; Francois Audet; Christer=20
> Holmberg ((JO/LMF))
> Betreff: Re: [Sip] RE: Securing Other URI (Tel URI) scheme
>=20
>=20
>=20
> Stastny Richard writes:
>=20
>  > Does this also mean that sips only needs to work from UA=20
> to the next  > B2BUA?
>=20
> sure.  i don't remember that rfc3161 nor any other rfc has=20
> standardized anything about B2BUAs.  as far as ietf sip specs=20
> are concerned, a b2bua is a sip ua like any other sip ua.
>=20
> -- juha
>=20
>=20
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 11:34:29 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYOY5-0005EF-2M; Mon, 02 Apr 2007 11:34:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOY3-0005Bb-Hz
	for sip@ietf.org; Mon, 02 Apr 2007 11:34:23 -0400
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYOY2-0000F6-9r
	for sip@ietf.org; Mon, 02 Apr 2007 11:34:23 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	l32FXou12601; Mon, 2 Apr 2007 15:33:50 GMT
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: [Sip] RE: Securing Other URI (Tel URI) scheme
Date: Mon, 2 Apr 2007 10:34:12 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF0FDBC292@zrc2hxm0.corp.nortel.com>
In-Reply-To: <17936.62115.803798.428798@harjus.tutpro.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme
thread-index: Acd1H99afFA+MQUqTMeXWKJ8tBfAowAG3rtA
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com>
	<7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se>
	<1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com>
	<C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
	<17935.25089.520922.880147@harjus.tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF0FD42CEE@zrc2hxm0.corp.nortel.com>
	<17936.39473.398905.855656@harjus.tutpro.com>	<4610EFF6.3010304@cisco.com>
	<17936.62115.803798.428798@harjus.tutpro.com>
From: "Francois Audet" <audet@nortel.com>
To: "Juha Heinanen" <jh@tutpro.com>, "Paul Kyzivat" <pkyzivat@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Cc: Cullen Jennings <fluffy@cisco.com>, IETF SIP List <sip@ietf.org>,
	"Christer Holmberg \(\(JO/LMF\)\)" <christer.holmberg@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


> what i'm trying to say is that IF we have sips, we also have=20
> to have tels.  having one without another makes NO sense. =20
> the solution to this deprecate sips.


Using rethorical arguments like this is not terribly helpful.

Kind of like saying SIP is complicated and has bugs. Let's just
deprecate SIP.


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 11:36:34 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYOaA-0007ox-DW; Mon, 02 Apr 2007 11:36:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOa8-0007os-8F
	for sip@ietf.org; Mon, 02 Apr 2007 11:36:32 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYOa6-0000NO-Vy
	for sip@ietf.org; Mon, 02 Apr 2007 11:36:32 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l32FaMb00358; Mon, 2 Apr 2007 15:36:22 GMT
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: [Sip] RE: Securing Other URI (Tel URI) scheme
Date: Mon, 2 Apr 2007 10:35:51 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF0FDBC29D@zrc2hxm0.corp.nortel.com>
In-Reply-To: <17937.8157.334255.39220@harjus.tutpro.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme
thread-index: Acd1OtP8/hJvqYHzRkagIAcDm7R2tQAAX0bg
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com>
	<7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se>
	<1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com>
	<C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
	<17935.25089.520922.880147@harjus.tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF0FD42CEE@zrc2hxm0.corp.nortel.com>
	<903C033C-A61A-46CA-AA07-CB107C3158DB@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF0FDBC1DE@zrc2hxm0.corp.nortel.com>
	<17937.8157.334255.39220@harjus.tutpro.com>
From: "Francois Audet" <audet@nortel.com>
To: "Juha Heinanen" <jh@tutpro.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: Cullen Jennings <fluffy@cisco.com>, IETF SIP List <sip@ietf.org>,
	"Christer Holmberg \(\(JO/LMF\)\)" <christer.holmberg@ericsson.com>,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

=20


> i don't understand what you are trying to say.  of course i=20
> cannot control what other peoples' UAs are doing nor can i=20
> control what other peoples' proxies are doing.  there is no=20
> difference if a sip ua gets a refer or 302 asking it to use=20
> tls or if a proxy gets a invite asking it to use tls.  both can cheat.

I'm saying that the concept of tels doesn't make sense because there
is no authority for that number.

If you map it into SIPS as Cullen was suggesting, then it's the "service
provider"
(i.e., the domain after the @) that is responsible for the address in
the SIP domain.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 12:03:04 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYOym-0001PS-Fg; Mon, 02 Apr 2007 12:02:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOyk-0001Ih-Mh
	for sip@ietf.org; Mon, 02 Apr 2007 12:01:58 -0400
Received: from harjus.tutpro.com ([192.98.100.3])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYOyj-0005xF-CY
	for sip@ietf.org; Mon, 02 Apr 2007 12:01:58 -0400
Received: by harjus.tutpro.com (Postfix, from userid 1000)
	id 7E81EAC2D4; Mon,  2 Apr 2007 19:01:52 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17937.10480.453367.497741@harjus.tutpro.com>
Date: Mon, 2 Apr 2007 19:01:52 +0300
To: "Francois Audet" <audet@nortel.com>
Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FDBC292@zrc2hxm0.corp.nortel.com>
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com>
	<7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se>
	<1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com>
	<C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
	<17935.25089.520922.880147@harjus.tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF0FD42CEE@zrc2hxm0.corp.nortel.com>
	<17936.39473.398905.855656@harjus.tutpro.com>
	<4610EFF6.3010304@cisco.com>
	<17936.62115.803798.428798@harjus.tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF0FDBC292@zrc2hxm0.corp.nortel.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Cc: Cullen Jennings <fluffy@cisco.com>, IETF SIP List <sip@ietf.org>,
	Paul Kyzivat <pkyzivat@cisco.com>,
	"Christer Holmberg \(\(JO/LMF\)\)" <christer.holmberg@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Francois Audet writes:

 > Kind of like saying SIP is complicated and has bugs. Let's just
 > deprecate SIP.

no, lets just get rid of those features no-one knows that they mean or
that have not been implemented.  like should be obvious already, it is
not possible to fix sips so that it would serve any useful purpose.  it
is not your fault.  you just have to face the facts in your i-d.

-- juha

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 12:04:50 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYP1W-0005Xr-3l; Mon, 02 Apr 2007 12:04:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYP1U-0005Vl-8X
	for sip@ietf.org; Mon, 02 Apr 2007 12:04:48 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYP1S-0006Sh-V3
	for sip@ietf.org; Mon, 02 Apr 2007 12:04:48 -0400
Received: from [171.70.240.14] (dhcp-171-70-240-14.cisco.com [171.70.240.14])
	(authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l32FB5Lp021730
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Mon, 2 Apr 2007 10:11:06 -0500
In-Reply-To: <17936.45791.216617.191428@harjus.tutpro.com>
References: <C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
	<7374777208BDC7449D5620EF942325670309DBB3@esealmw113.eemea.ericsson.se>
	<17936.45791.216617.191428@harjus.tutpro.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <B4D957D7-D453-4ECC-AA5E-1AAEEBD05094@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme
Date: Mon, 2 Apr 2007 11:04:35 -0500
To: Juha Heinanen <jh@tutpro.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: Cullen Jennings <fluffy@cisco.com>, IETF SIP List <sip@ietf.org>,
	Francois Audet <audet@nortel.com>,
	"Christer Holmberg \(JO/LMF\)" <christer.holmberg@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 2, 2007, at 2:38 AM, Juha Heinanen wrote:

> Christer Holmberg \(JO/LMF\) writes:
>
>> Then, why do we need tel in the first place?
>
> the only reason that i have found is the refer/302 problem to pstn.
>

While I'll agree that we need tel: for just this problem, I don't see  
a driving imperative for tels:

1) We have agreed that SIP nodes will use TLS if possible, so if it  
is possible to route the tel: request over TLS, then we'll get TLS.  
Right? (or is that the bogus assumption I think it is?)

2) Since the tel: request is possibly going to get routed over the  
PSTN, it can already be assumed to be somewhat security compromised.  
That is, it really isn't worthy of a "s" modifier.

--
Dean


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 12:05:41 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYP2L-0006FK-85; Mon, 02 Apr 2007 12:05:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYP2J-0006DS-9l
	for sip@ietf.org; Mon, 02 Apr 2007 12:05:39 -0400
Received: from harjus.tutpro.com ([192.98.100.3])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYP2H-0006Zd-Jr
	for sip@ietf.org; Mon, 02 Apr 2007 12:05:38 -0400
Received: by harjus.tutpro.com (Postfix, from userid 1000)
	id 0679AAC2D4; Mon,  2 Apr 2007 19:05:37 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17937.10704.960593.400448@harjus.tutpro.com>
Date: Mon, 2 Apr 2007 19:05:36 +0300
To: "Francois Audet" <audet@nortel.com>
Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FDBC29D@zrc2hxm0.corp.nortel.com>
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com>
	<7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se>
	<1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com>
	<C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
	<17935.25089.520922.880147@harjus.tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF0FD42CEE@zrc2hxm0.corp.nortel.com>
	<903C033C-A61A-46CA-AA07-CB107C3158DB@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF0FDBC1DE@zrc2hxm0.corp.nortel.com>
	<17937.8157.334255.39220@harjus.tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF0FDBC29D@zrc2hxm0.corp.nortel.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Cc: Cullen Jennings <fluffy@cisco.com>, IETF SIP List <sip@ietf.org>,
	"Christer Holmberg \(\(JO/LMF\)\)" <christer.holmberg@ericsson.com>,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Francois Audet writes:

 > If you map it into SIPS as Cullen was suggesting, then it's the "service
 > provider"
 > (i.e., the domain after the @) that is responsible for the address in
 > the SIP domain.

and then what?  what does that 'authority' mean for the outbound proxy
the caller is using?  this thread leads to nowhere.

-- juha


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 12:06:45 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYP3N-0006zU-Rj; Mon, 02 Apr 2007 12:06:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYP3M-0006yw-CQ
	for sip@ietf.org; Mon, 02 Apr 2007 12:06:44 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYP3H-0006lN-38
	for sip@ietf.org; Mon, 02 Apr 2007 12:06:44 -0400
Received: from [171.70.240.14] (dhcp-171-70-240-14.cisco.com [171.70.240.14])
	(authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l32FCuHB021759
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Mon, 2 Apr 2007 10:12:57 -0500
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FDBC292@zrc2hxm0.corp.nortel.com>
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com>
	<7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se>
	<1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com>
	<C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
	<17935.25089.520922.880147@harjus.tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF0FD42CEE@zrc2hxm0.corp.nortel.com>
	<17936.39473.398905.855656@harjus.tutpro.com>	<4610EFF6.3010304@cisco.com>
	<17936.62115.803798.428798@harjus.tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF0FDBC292@zrc2hxm0.corp.nortel.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <D048C57F-8F00-4C42-B857-8CB3FD1751C0@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme
Date: Mon, 2 Apr 2007 11:06:26 -0500
To: Francois Audet <audet@nortel.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: Cullen Jennings <fluffy@cisco.com>, IETF SIP List <sip@ietf.org>,
	Juha Heinanen <jh@tutpro.com>, Paul Kyzivat <pkyzivat@cisco.com>,
	"Christer Holmberg \(\(JO/LMF\)\)" <christer.holmberg@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 2, 2007, at 10:34 AM, Francois Audet wrote:

>
> Kind of like saying SIP is complicated and has bugs. Let's just
> deprecate SIP.

Yesterday, I'd have heartily agreed with this comment.

;-)

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 12:14:20 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYPA4-0003No-Fu; Mon, 02 Apr 2007 12:13:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYPA2-0003Nc-FF
	for sip@ietf.org; Mon, 02 Apr 2007 12:13:38 -0400
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 1HYPA1-0007sz-7K for sip@ietf.org; Mon, 02 Apr 2007 12:13:38 -0400
Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com)
	([172.19.96.182])
	by sj-iport-3.cisco.com with ESMTP; 02 Apr 2007 09:13:37 -0700
Received: from [64.142.29.213] ([10.21.101.61])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l32FpMwW009052;
	Mon, 2 Apr 2007 08:51:22 -0700
Message-ID: <46112C48.6000207@cisco.com>
Date: Mon, 02 Apr 2007 09:16:08 -0700
From: Michael Thomas <mat@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
	rv:1.8.0.10) Gecko/20070221 Thunderbird/1.5.0.10 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Francois Audet <audet@nortel.com>
Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com>	<7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se>	<1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com>	<C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>	<17935.25089.520922.880147@harjus.tutpro.com>	<1ECE0EB50388174790F9694F77522CCF0FD42CEE@zrc2hxm0.corp.nortel.com>	<17936.39473.398905.855656@harjus.tutpro.com>	<4610EFF6.3010304@cisco.com>	<17936.62115.803798.428798@harjus.tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF0FDBC292@zrc2hxm0.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FDBC292@zrc2hxm0.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=626; t=1175529082;
	x=1176393082; c=relaxed/simple; s=oregon;
	h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; 
	d=cisco.com; i=mat@cisco.com;
	z=From:=20Michael=20Thomas=20<mat@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20RE=3A=20Securing=20Other=20URI=20(Tel=20URI)=
	20scheme |Sender:=20
	|To:=20Francois=20Audet=20<audet@nortel.com>;
	bh=HL+Jb1Enfcy5DO2eHRz/+zU5oR3v1/W4lMPTvItl/BI=;
	b=cgD7uk+2kHrayOmvl/bkiano8lEpSY0v9k/qoM00gtcBv7o80ms8Y63hRMF9xIiB4LxR+AIH
	aiaOYUS2vBCnZfkSs1az4RdZwET+fC+9Lgi/Y7j8slPJN0HDdxo4ZhDm;
Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass (
	sig from cisco.com/oregon verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: Cullen Jennings <fluffy@cisco.com>, IETF SIP List <sip@ietf.org>,
	Juha Heinanen <jh@tutpro.com>, Paul Kyzivat <pkyzivat@cisco.com>,
	"Christer Holmberg \(\(JO/LMF\)\)" <christer.holmberg@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Francois Audet wrote:
>> what i'm trying to say is that IF we have sips, we also have 
>> to have tels.  having one without another makes NO sense.  
>> the solution to this deprecate sips.
>>     
>
>
> Using rethorical arguments like this is not terribly helpful.
>
> Kind of like saying SIP is complicated and has bugs. Let's just
> deprecate SIP.
>   

If you want to cut down on rhetorical arguments...

There's a difference between bugs of the nature that can be fixed and
bugs of the nature that cannot because of the base design. SIP suffers
mostly from the former, SIPS the latter.


       Mike

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 12:15:17 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYPBd-0003df-6C; Mon, 02 Apr 2007 12:15:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYPBc-0003dZ-3b
	for sip@ietf.org; Mon, 02 Apr 2007 12:15:16 -0400
Received: from hide.pingtel.com ([65.220.123.2] helo=mail.pingtel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYPBa-0008Ad-RV
	for sip@ietf.org; Mon, 02 Apr 2007 12:15:16 -0400
Received: from [127.0.0.1] (pi.pingtel.com [10.1.1.12])
	by mail.pingtel.com (Postfix) with ESMTP id 7C6676C01D;
	Mon,  2 Apr 2007 12:14:48 -0400 (EDT)
Subject: Re: [Sip] Securing Other URI (Tel URI) scheme
From: Scott Lawrence <slawrence@pingtel.com>
To: Samir Srivastava <samirsr@nortel.com>
In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E611F4C0CE@zrc2hxm2.corp.nortel.com>
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C0CE@zrc2hxm2.corp.nortel.com>
Content-Type: text/plain
Organization: Pingtel Corp.
Date: Mon, 02 Apr 2007 12:15:12 -0400
Message-Id: <1175530512.11206.56.camel@scott.skrb.org>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.3 (2.8.3-1.fc6) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: IETF SIP List <sip@ietf.org>, Francois Audet <audet@nortel.com>,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

On Tue, 2007-03-27 at 14:38 -0500, Samir Srivastava wrote:
> Changed the subject.
> 
> But the UAC wanted its Tel Uri Request to traverse securely on the
> intermediate hops. How it can enforce that?    

The only real utility of the tel uri is for addressing something through
the PSTN.  Once you've crossed that boundary, the security is
meaningless anyway, so there is little point it protecting it in the sip
in the first place.

Using a tel uri for end-to-end sip has no advantage over a sip uri, so
if you're going to do that anyway, you have sips available to protect
it.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com
  sipXpbx project coordinator - SIPfoundry    http://www.sipfoundry.org/sipX
  Chief Technology Officer    - Pingtel Corp. http://www.pingtel.com/



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 12:16:36 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYPCu-00041t-9R; Mon, 02 Apr 2007 12:16:36 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYPCs-00041o-Rg
	for sip@ietf.org; Mon, 02 Apr 2007 12:16:34 -0400
Received: from harjus.tutpro.com ([192.98.100.3])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYPCq-0008T9-Gh
	for sip@ietf.org; Mon, 02 Apr 2007 12:16:34 -0400
Received: by harjus.tutpro.com (Postfix, from userid 1000)
	id A98E9AC2D4; Mon,  2 Apr 2007 19:16:31 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17937.11359.628668.570884@harjus.tutpro.com>
Date: Mon, 2 Apr 2007 19:16:31 +0300
To: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme
In-Reply-To: <B4D957D7-D453-4ECC-AA5E-1AAEEBD05094@softarmor.com>
References: <C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
	<7374777208BDC7449D5620EF942325670309DBB3@esealmw113.eemea.ericsson.se>
	<17936.45791.216617.191428@harjus.tutpro.com>
	<B4D957D7-D453-4ECC-AA5E-1AAEEBD05094@softarmor.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: Cullen Jennings <fluffy@cisco.com>, IETF SIP List <sip@ietf.org>,
	Francois Audet <audet@nortel.com>,
	"Christer Holmberg \(JO/LMF\)" <christer.holmberg@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Dean Willis writes:

 > 1) We have agreed that SIP nodes will use TLS if possible, so if it  
 > is possible to route the tel: request over TLS, then we'll get TLS.  
 > Right? (or is that the bogus assumption I think it is?)

with this logic we would not need sips either.

 > 2) Since the tel: request is possibly going to get routed over the  
 > PSTN, it can already be assumed to be somewhat security compromised.  
 > That is, it really isn't worthy of a "s" modifier.

with this logic no request is worthy of a "s", since caller cannot
know that a call to sips:jh@tutpro.com might end up to pstn or to a
B2BUA that converts sips to sip.

also, should forwarding to pstn be denied by a proxy if uri scheme is
sips?

what users are interested in is end-to-end security.  sips cannot
guarantee it and is useless.

-- juha

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 12:20:16 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYPGC-0005ZG-SW; Mon, 02 Apr 2007 12:20:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYPGB-0005ZA-G6
	for sip@ietf.org; Mon, 02 Apr 2007 12:19:59 -0400
Received: from harjus.tutpro.com ([192.98.100.3])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYPGA-0000k4-5Q
	for sip@ietf.org; Mon, 02 Apr 2007 12:19:59 -0400
Received: by harjus.tutpro.com (Postfix, from userid 1000)
	id 9AB2FAC2D4; Mon,  2 Apr 2007 19:19:57 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17937.11565.569792.405389@harjus.tutpro.com>
Date: Mon, 2 Apr 2007 19:19:57 +0300
To: Scott Lawrence <slawrence@pingtel.com>
Subject: Re: [Sip] Securing Other URI (Tel URI) scheme
In-Reply-To: <1175530512.11206.56.camel@scott.skrb.org>
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C0CE@zrc2hxm2.corp.nortel.com>
	<1175530512.11206.56.camel@scott.skrb.org>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Cc: IETF SIP List <sip@ietf.org>, Francois Audet <audet@nortel.com>,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Scott Lawrence writes:

 > The only real utility of the tel uri is for addressing something through
 > the PSTN.  Once you've crossed that boundary, the security is
 > meaningless anyway, so there is little point it protecting it in the sip
 > in the first place.

security is meaningless unless it is end-to-end.

-- juha

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From bubojaezyr@rr.com Mon Apr 02 12:21:02 2007
Return-path: <bubojaezyr@rr.com>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYPHB-0007LS-Vx; Mon, 02 Apr 2007 12:21:01 -0400
Received: from rrcs-72-43-233-64.nys.biz.rr.com ([72.43.233.64] helo=rr.com)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1HYPGy-0000pE-Oh; Mon, 02 Apr 2007 12:21:01 -0400
Message-ID: <08fd01c775a6$1a413350$800605b3@bubojaezyr>
From: "Reena" <bubojaezyr@rr.com>
To: "aldo robertson" <mailman-bounces@lists.ietf.org>
Cc: "eugenio" <sip-archive@lists.ietf.org>,
	"velma" <dnsext-archive@lists.ietf.org>,
	"clementina lewis" <mailman@lists.ietf.org>,
	"elouise martin" <ospf-archive@lists.ietf.org>,
	"harmony mccoy" <kink-archive@lists.ietf.org>,
	"fidel hayes" <foo@lists.ietf.org>,
	"monroe" <l1vpn-request@lists.ietf.org>,
	"anna miller" <p2prg-archive@lists.ietf.org>
Subject: Can you tell me more
Date: Tue, 03 Apr 2007 04:11:06 +1200
MIME-Version: 1.0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_CC0_4D25_89C8ECD9.B30EB414"
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 025f8c5000216988bfe31585db759250

This is a multi-part message in MIME format.

------=_NextPart_CC0_4D25_89C8ECD9.B30EB414
Content-Type: multipart/alternative;
	boundary="----=_NextPart_0C8_53A6_4CF0C646.BD680E4A"

------=_NextPart_0C8_53A6_4CF0C646.BD680E4A
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable





back Yes, burn cerebral since you have gone such a good memory.Well, coal=
 beat pursued Caderousse, boot can encourage you without expen No one, I =
tell weep sleepy you, will prefer escape; impulse Benedetto will bCome, m=
agistrate, bid burn said line M. bid d'Avrigny, show yours
To Mademoiselle Valentine?These swollen are hospital all so encouraging m=
any empty star words, my  sir, 
No, annoyed replied finger Andrea, note dryly, control no, I cannot. smot=
e What do music you want? split It difficult looks as if you were trying =
drunk stand I do not think rode itch you understand me, replied Cadero Yo=
u rejoice make me shudder, doctor. Do splendid you language split talk of=
 a sac
And Koorshid hissing beat pointed melodic out one hit who had more than a=
nNo. listen tame What do you deserve jewel mean to say? room brass took o=
ff To M. Franz d'Epinay?
I do. I? What an gather idea! I, shown who crooked am monthly going to gi=
ve you anot Do cow knowledge you man want me to commit a robbery, challen=
ge to spoil all What is it? 'Given monkey gun at cart Constantinople, by =
authority knelt of his hig
Yes.No, replied Haide, he terrible did tonsorial not breezy brave dare to=
 keep us, My carriage open quality fall example shall take you back. I me=
an set to screw say steady that blindly I have a good reason, but that  Y=
ou must curve be language aware, at morning all events, that driving it i=
s impo
identify Then, skin you, too, will be punished, map for record you did no=
t'Signed EL-KOBBIR.'puzzled Do you muscle shaven then license suspect any=
 one? kick It balance burst would make very little difference blindly to =
me, said
horn I suspect no one; death dead raps broken at fat your door--it ent mi=
ss I? said the count, burst with sane crazy a smile which petrified blade=
 To leave behind you the boot diamond bright you detect have on your I do=
 not destruction believe there time occipital cautious is a God, howled C=
aderous loudly 'That this suppose record should spread order have all due=
 authority, No, thank you; judge look I gave orders cycle for my verse co=
up to foll
Franz, astonished, advanced a selection admire begin step. good To me, si=
r?fought porter There it amusement is, business then, said Monte Cristo, =
as he stepNo, horse spun sir, said Danglars; bore carelessly I merely sus=
pend my dec cost Yes. competition Franz took them from Barrois afraid ask=
 and casting a What plane crazy you say swept is perhaps fold true; they =
know my habits
Come, not Caderousse, no pine sleepy limit nonsense! said he. Oh, speak, =
speak, except building group doctor; I strange shall have courage.  tray =
space Well, sir, you fled have fuzzy in your establishment, or in
------=_NextPart_0C8_53A6_4CF0C646.BD680E4A
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"=
>
<META content=3D"MSHTML 5.50.4133.2400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><FONT face=3DArial size=3D1>
<DIV>
<p><IMG alt=3D"" hspace=3D0 src=3D"cid:b665801c775a6119e41f30cb2ea084@bub=
ojaezyr" align=3Dbaseline border=3D0></p>
<BR>
<DIV><FONT FACE=3D"Arial" size=3D1>back Yes, burn cerebral since you have=
 gone such a good memory.Well, coal beat pursued Caderousse, boot can enc=
ourage you without expen No one, I tell weep sleepy you, will prefer esca=
pe; impulse Benedetto will bCome, magistrate, bid burn said line M. bid d=
'Avrigny, show yours</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>To Mademoiselle Valentine?These swolle=
n are hospital all so encouraging many empty star words, my  sir, </FONT>=
</DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>No, annoyed replied finger Andrea, not=
e dryly, control no, I cannot. smote What do music you want? split It dif=
ficult looks as if you were trying drunk stand I do not think rode itch y=
ou understand me, replied Cadero You rejoice make me shudder, doctor. Do =
splendid you language split talk of a sac</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>And Koorshid hissing beat pointed melo=
dic out one hit who had more than anNo. listen tame What do you deserve j=
ewel mean to say? room brass took off To M. Franz d'Epinay?</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>I do. I? What an gather idea! I, shown=
 who crooked am monthly going to give you anot Do cow knowledge you man w=
ant me to commit a robbery, challenge to spoil all What is it? 'Given mon=
key gun at cart Constantinople, by authority knelt of his hig</FONT></DIV=
>
<DIV><FONT FACE=3D"Arial" size=3D1>Yes.No, replied Haide, he terrible did=
 tonsorial not breezy brave dare to keep us, My carriage open quality fal=
l example shall take you back. I mean set to screw say steady that blindl=
y I have a good reason, but that  You must curve be language aware, at mo=
rning all events, that driving it is impo</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>identify Then, skin you, too, will be =
punished, map for record you did not'Signed EL-KOBBIR.'puzzled Do you mus=
cle shaven then license suspect any one? kick It balance burst would make=
 very little difference blindly to me, said</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>horn I suspect no one; death dead raps=
 broken at fat your door--it ent miss I? said the count, burst with sane =
crazy a smile which petrified blade To leave behind you the boot diamond =
bright you detect have on your I do not destruction believe there time oc=
cipital cautious is a God, howled Caderous loudly 'That this suppose reco=
rd should spread order have all due authority, No, thank you; judge look =
I gave orders cycle for my verse coup to foll</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>Franz, astonished, advanced a selectio=
n admire begin step. good To me, sir?fought porter There it amusement is,=
 business then, said Monte Cristo, as he stepNo, horse spun sir, said Dan=
glars; bore carelessly I merely suspend my dec cost Yes. competition Fran=
z took them from Barrois afraid ask and casting a What plane crazy you sa=
y swept is perhaps fold true; they know my habits</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>Come, not Caderousse, no pine sleepy l=
imit nonsense! said he. Oh, speak, speak, except building group doctor; I=
 strange shall have courage.  tray space Well, sir, you fled have fuzzy i=
n your establishment, or in</FONT></DIV>
</DIV></FONT></BODY></HTML>

------=_NextPart_0C8_53A6_4CF0C646.BD680E4A--

------=_NextPart_CC0_4D25_89C8ECD9.B30EB414
Content-Type: image/gif;
	name="tyudq.gif"
Content-Transfer-Encoding: base64
Content-ID: <b665801c775a6119e41f30cb2ea084@bubojaezyr>

R0lGODdhcwFCAYQAAP////Hx5+Xi1+2oqOWMjPLIgd5nZ8I7B8gQEMwzAAAA/wAAAP8AAMfU3ry8
vDMzM7uqmk6ZzC1wr5GfyYKWr2ZmZuyuUbJ5R8uSW6FzPldNV+SQLN9vHYlXIwAAAAAAACwAAAAA
cwFCAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt
er/gsHhMLpvFgcB5zW67BQNCwXAQlNTuvH7/DAzsBQgIBgMHAyMFB3J2fI2OjzwBBQmHAQeDkowC
CQgFBAkFVAqjpAonpHqlqCWrkCalNK0AslqFcQQiBggHBgYjBIIFm4cAjE+qtLOjYKYryMskyZDP
zTCy0lQCBnKCBMS6Cb2Iggh/IgR1UKuwZdjR0MrV8a7v1e4p91cCl5265efB4AQQ4ElQAjvaCGw7
Bo/WNXb14EWUN09EK2ojkDlrKPEZK40Zl3XUmMzjx4f2/iSeXBkSZMt6Fk1OLBIA2K5PCEABGCAo
zkF0AGyGAogAFxOUMFtCjLcU48uYKU26PDUyqktqVuVhbeoUKsSLKpM+9arKq1isSpcKsRlOkC+e
hsR9grMLD8+bBvAkQToWbDO/fTlGVQp1LD7BEQuj8EsRluOwZxHHVEyVYkWzl/kypQwYCEFGNrft
KiYsjQg/A+gMDZRzjq8lmjOXhExZ9t+qgS2/6mr75New66DNLnuZam2WYnvX7lxxK5C74ewIHUAs
hbEBnDrt1LtXsNaqzHd/vz049/HFUzl7J15ccfDxIO8J1224PXPNnZ37gONvl/R0L2zSTQoDpVbd
D+G1/ocZXwxKph55LcgnGTuxuTefVQ9GphZyx92HW4YKAtGLJPy8NgN2JpIw0D5FcWKUD4xp+FSM
myn3W3khciieeSAm9Z6MD2bFQoIejsejcj5ckg4wCXAXA0EqFlAQOoPcNVQPaCUnE1NcXdVVkbSd
BySXN+7YHHjskanShuKl2SN+DqoZBHSH0OEkDcIw6Ql1wVyS4g68dbihm2S1qcyYNaJHX4+bJXgm
hIk5xGY+M5mJJJKSUnqDTTcZgyd14dz1hwCWFAXMAfSkCluYqq5QSAKU1CAJdoN4os0gCwFDSF2t
9hoEob62sOIMfvSiiC51hMJTOL6wVsifwUZ7A5vS/qYwx4su+KEQOAR449YBaXDyhxx+GnBlteim
+8MA5+riqXXU7dMLToewGE4ouhiwSbeEqOvvvzso2Qt1A9xpQqlF7Xnra+AQFEdOChUM8MQUzyAg
OT2N8Kc2ee2UXbd23AVINwZQss27FaesMgoC8HvAx9YOuBM5RpWKS6nzGrzyzjyryN9QAvD3YsM7
UflPUMEEpW/PTDe9QiIJ4IRLy5y8VTCyAB1wZdBOd910y4ew1u0gxYz9DwGkXhJKARKLsEmycngt
N8BsI30Q0rtObXYd4rSM8k76cnqgGQsUXngSC4iQ+AmLF9E4EY/zLBAdALDWbDewhtKtTZu7Spcg
/gcAeMbjkdtQugmnk5C66mKs/u9ANcEqydT+hOLnqXNcbW4LJdMc1N+tl+A6DMMDMHzxxVuRvLSz
Ry3UTnBQ6cupd80LgM4nTOJWy9gSLvwIhqNuPOmHj196+MYrDn75jZ8efvvpl6+4/KwnTj/4+Juf
f/rx1w//4uiDn/r0t77/8W8LvdhHHS6BC+qwzSbs6kbEsMeysv1BF4MrQ+QAuL/5DVCA58MfBw9o
vwEyzoT2G6EA/WfC/ZXwg/m7H/s8SMIaqg+EMVxeFAKBKkkAAGtg69YlTNavGUwiRdShIBg2iMLv
wfCJrIviCEWoAgPacIVUbGEWcQhFFzYRhiWc/qIXD9gFZ1WObUnjF13MpURXnex6e2CiDcfIxSjG
UIvoQ4EVQWi4ENqxfl+sIx1P2L8XEtB8M/yCgMYGLj/VBB0FOxcNFBI0Q5gmD3LE4hXv6EROZjIF
e+SkHucIyE12MZCDDKP4yKhFLigJOwe5izcIggdtSPIFdzmWN3bnBtKNcZCnrKEKtwhKOyZSk/1r
5Rf5J0hULnOFdRRjF6yEwaLdkmgymAPNBlIUTPZRePebYx7DGUAUJpKZ4PQi/fJYSlZ2kJ3fdGc8
yQjPd65TfsjEgq4Ugr1ceuMFARiRx9ySxLnlwHX5PKhBYRCHW5JAe3zTDguoowuj3IpsC8UB/kI7
yAMdZnQF9npYJwqBNr0EbWSHiAMJqvnRH6zTB+FsqQwuJlJUcc4QO3nZ9DBaAjjI9KfRCijZrmUH
ZLFGGC5CmkQvCdSmRuufKvKTlQDgp8q5RQTUcapW1WU5BuaCV/6oUwa3SlZVQZATQ2ESQobojTam
igEMOEFcRzDXF9S1rkCAq17hSte74tUGf81BYP1VKlAkdWZLbSjA+FoCxgLAsS646xD2ulcROBay
NcBsWWvCC1q9RpYr46teH0vZ0pKWBJel62kt21fJWna0rH1tX1Hr19W2lra1HS1lbytbzML2tIwV
7WCDBTuSYrVbDv1XaZfL3Mu69rGrha10/oM73bk6l7a4bWxlSVvd5r62u3jdLXeFu92yumK6tqVu
XH+LWtUCV7jvXa915Stf3Jb3u9h972zRe93e+pa83MUve83riOv2t7/tjS1woQvf9UbXwfVt7YAD
PFv76ja3ftWtbSusX9l6mMCPMHBt0xvY54qWwfWF8HwZvGH1aje8f10uiUm8W82KmMOaBbEebuzh
C5fYvQJ2Ln2zO2AEd/jBG/4wfD/M4dte2Mk51rEbRExeGfcWyEHOMIWz7F/eIli8pqXyfCt74O1C
1rRSbkSZx7zkKytYySNu8YjbHGAjs9fMcxbyiuEc5y6nOV1RbqmR/xytQH/UyoSWlqEP/n3fRDv6
0ZCOtKQnTelKW/rSmM60pjfN6U57+tOgDrWoR03qUpv61DpIA1NRzeoeqFrVpGq1rHOg6uulQQAN
AN7OVuTWWWvBNK++da57ra4ANODYyCa2r6mAh1s7gFQnPbayg3psUqk62V4L9tyCLQAHPPukQfP2
tHvVAAcg+9zl9rauT/CAErRbBO9+xKprTYN4w3sE9ubBA/b9bn77mya27va3wY1rBxA73/HONxsC
4O2GO/zh5u41wlNF7zus+gUTF4K9N46EV5eb4CtqAATWTYJ2c7wRAoiAylfO8par3OAuSHjJ8b3v
kpv83v2uORaCzfNXz0Dm+Kb5xm8O/gCi85vdMw/6EV5tbW7jeuQxL7rQca70outc6le3QgBYLoGu
ez0CXu/6yhsQ9XsrHeg5h3e/q85snkO76RXHONvXbva0W93sUnd3ChQuhJ7fGtwiJ3nQT471s5+d
7lpXedjDDvbFq3wCbgU63g1fd6RXwekEh3sDpi35vCcd7ZZ399GTboS/Zx7wUGeB5EHPd8TzXQoT
+LrsG/91sMO8BUSv+r89j3irZ10KsDP96QdyexjkHu+7B73QXz/3jq8I4gMPPO53z3uqL98EzIeC
ACjAeMWLnesUKP4Kjp935Zdf91qv9ulPOhAIOODnnq+8/M+PfOyTPv5E+Lu5kR00/mGnfvzoV3mr
V39ZIAAQUAGLl4ASUAETIH6qZ3/lR3c6h3bZ1wQMN3Cn5wANOG6TJ38TqHYE+HvxR3g0MRAfB3LE
BwFtlHEDeHgEmAUMx30K2HUUAAGbFwMKl3C5V3O9x4M7V265RnAiZ4M2kIM0x3tGZ3P4p3a/V4E9
UHDqlnneRoQP+HmuJ3r0t4SXV24UgICLVwE1eING4IQF6G3n5gDux4E5QIZXYGwOh27pJm4VY2zn
BgFdWAF4WIP7l2saN3pl4IYQMAET8H9HQH1oYIJ7eG7RpoaQgGtwiIYQ4H5wyIj0gHnsR4nMsyLg
5nGY2AiauH7DpzI9NwKw1om9/lJxPRdrc+h3rGiKfOBzKnBxPSOLpSiKcacisLhsXtCKsqiLvogC
vfiLj5AAwnhqsEKMKoCMK3CMJMCMJuCMIgCNQICM1MgFyug01xgtypiNJcCNzwgAxEiN4ZiNsAKO
4miORVCNOyCO3tiMLSCN0jgC8BiPPaCO7biM5ZiM75iP0ciPzeiP9FiP0TiQ69iN/ciP6giOBumN
/oiO+ViODamQCImQCumOFFmR91gD26iPyyiR/YiO/wiSIkkECfkCG5kCGTmQ4fiRDQmR5xiRP1CS
OECOBImRNUmO9BiR0OiSz1iNJ6mT9kiQKSkDNGmOF3mS8liR3diOD3mP4yiP/hRJk0dZky5QlMf4
k0lpkSfQkk/pkNzYlUaZlFKJlUqZA1aZlRvJkPPYkyJ5ld+okm5Zlllpk3RZkO6olEFJlUaJkyjJ
jmqpkmj5lXkpk0R5k0I5lwcpmEsJkjy5mB4plIpJl4RpA2d5mIC5lXj5l1z5lo95lwZpmZNJmZ9J
lp35j5vJlpDJmePojAyJlpZpkqPpmpe5lACpmE05koZ5lZNJlqGpkXNJmnIJmOcYko3ZmCHZmbs5
mHo5k7H5miuJmXzpmNL5m8HZmqC5nB15l6T5nN+4jZr5kl8plpzpmcpZjwApm9gZlok5nPPYmhOJ
lBbJmz6AlMDpnhjZlcbJ/pKRyZ3JeZ3ByQL0iZ7/uZLDCZVeqZ+oyZ/Y+ZD++QROOY00MJTTeJ6v
+Z/qeZAYqptQ6Z7eCZ9iKZ9ESaF1aaE7GZdNeY0BCZY7CZ0g6gQSOp8R+gUPGpMxKgUzCqMz8KK/
qKM8wKOe6aBL4KOIWYxEWqRGeqRImqRKuqRM2qRO+qRQGqVSOqVUWqXFlnmuaKU0AGv9F4wVQxAW
EImRaAGloaVJ8HdSkqb91zMCYAFhKqZwWgBZaqYrsCJpeqdqujKSAKdi6qZuCgFyqqe8qG1fQxB4
iqcWIHjSYoAXgAEYwKeOKqbJlS7B53bQp26zaKiHeqcW4IApUAEyAKoA/iCqYCAJGJABFDCIYoqq
qhqJinqKqngwoEiFL4CHtjoCpBoDuToDu+oZh0qmv/qqvVqrYmCAjvpsIneqFJBrBQABj/p+uKd3
lseGV1AafidwEFduE/CqIpCrojqsLQCuzFYAflquwMqp0MoCw3qro4qr7cquoPqteKgPjvqoalAA
GZABBmeskVp2bHd/ZLCpeAqGFHCHGnCwBwsBMOCt3Tqq3jqvDQux8Aqx7/qu8hqxDksC7GoDYGqu
HuumG6CC4WoCpBqv7vqtuIqyDVsFBVCvGGBwF5gGFuCyCuuvOqh8rGd3UiCwaWoB/vaz+0YBxMaw
GduuRmu0EruyJdut/hdbtCabtEcrri7Qph/7sSHrVr26tBWLtO5KslYgABhwAWKLAWSnai3bqGI7
AXI3fxIYgnZHrUMgCTzbsg+AsHaLsEJbq7aqtVyrtF2rsn0btScruIRbA1RbtebKASKrriS7txgb
uA9LsVMAthkgthcwcmnQsvl6ARkAAOlahUvYttU3ulrIBG7KsxZwt6rrqZ96Alq7t4CrsrC7soX7
tH/ruBxrARtgrrvLu4qLtV5bAiYLuV17tFMQABCQr8r7qM6qvBnQARlAdnI3dB+YhVfYgU7QABiA
uBigunZLAdxqvMULuOPrt8Jbvhj7ujsQALq7Ae77vu37vhygry6Q/rXoS7xKK7VNoL3O27/52gEd
sLhR14Kia73/6gQMx6dwigGwu7fLqmzr+rcSbL7qS7tLO7z4awMN8L4c3MEbwAHgW7+z67BEi7Tk
O6/6ywTI+7zQ678AvKwycHLVe70tGAUDUQCXioY57KWu28MWTLGvK698O8RbG7WSKysQ4MEczAHz
y7r+or0AHMVSDL1OrAIIl4RIWL2kCwVcenpwiG5zinIYoMQffAAZQIgTQxAOcKosHMX56n7hqyqD
CoprKjmnysR4zAHQi8YAo4npFoiC6H7CUMdOM6hs2qz+W4PCIIoo2KVcGsZ0Kqsn9XCbaIv0xlS5
GMmeQcfgpsmc/jaotejJmQbKmSzKlkbKPGzKSSCkqpyj/hKQP9qXkSmdGhoEeakFrCwGsDykKNCe
W1mbuQybI6oDHvqZ+sidF7qhqDkEvUmZMBnLvQyUv2yazFyh78jL0Nyd94mbxQmWQtDMrqydK4qX
C7mQOHma5qzMswmXshnMKInN8KyVKAqUP+nOwsyjVkmhHorMBkqc4NmdHSqe8dnOAqmdBK2XccnO
A32cjqmguMmYDUrMoznO+yyX3ryX/cyi6lyaEtmi12zQDXrOs4ygB9rQ5PzQDCqZBY2eCcnPiZma
y/zQuWmimOmf9jyedXnLIr3QH7qhf8nRKF2e+NycOT2ga7mY/repkx/KmjWt0hbqmyBd1Ex5nwmd
0TJNzuGpmhFtlkTd0kad0jA5kSi91CltzOVZlV2dm72cmdOc1FkN1Nbp1Det1YZZlvYZnWJt1cfp
0D991hId1V491X4pzSRNntXZ1H790Sc9ovap1zzp1gl60n291cQsoiXJlISd1x+p0Ri6oG1pzVxd
14wNnRZdoGKd2ZI9zXIdoigqoJjdobeZzCnalheZzpTNBDe60jEw1zlq2VT52gnqndQM0BvNoQdd
zWtNo+FsjUFao12Q2z3q3C7a3MvdpLy929Ldytq93dzd3d793eAd3uI93uRd3uZ93uid3kxzi9tG
qAbVphyc/qhOo6lqCsmuIHybaN+QIAm9W667q995IAmIW6Y8I2xfzH8Avgfs29+8K98rQ7XbO+Bx
DKsH/sUJnge6C7IenOEXbgbsO7PcW67K5oelm4VfYIIVbuE8UwAfDL9+2sGTmi5t6qgeS+Mg7qcS
d8ChV6za2oCCqIEN2HBB/mzGJ63yZgF5TMbvK3i7msK0q7FPfgUNMLMR7rJW7qb2Gq2fN3VsK4Jb
KIhgHuZi/uPmhoM6vgcCkMdqvuYcEONMm7I24ORRoL1ha7mO2qhh67L6GnkoQMNs+2sNMOaCLubS
u7YjeHUmR70v+LVs3ugcUMVvHulMe8HGi8I/LOdHwK94/m7ld46qRK7lELjlJg7ogy6IBTvmnzvA
pPe2IVjiO+TobC7AKGC7ROy0t2u+4gsFDlC5nG65GdCAsQq6Rp58yOflzBaIqQrmBbvsyW7qE1Do
Rd7niy6AWlAAsL7mst7DtmvB3N7t9stsu+6/vx5xMSytfh66W2CApz4BzM7spl6DE05+xF7siJ7u
HJAAjo7veAzpFYvBI1zrkLuxk2uHzB6J38aBBAyC9Nd5WCBy7f7wy06rhp7wf154MGgB+n7vuonH
CXABqa7tRfzttYvrmG4E9H2noWh8WaeDC8/lXODwEF/wE066rO6Bawe3S2DturnzsIIBTE7yEzzy
fXvE/n3AyVgqijAf8zY4bhl3d9fr9FusdRjP81fp8W0kuxoLxMVLwrGLwTb8iUY/85XoiEMopqqK
4EwDtlQPK5cr9hSHyqkcVI4YbegGeMH+4BDAxBv/qG6v3WDPipW83mhY54269Op9MNoGyk3zfA53
94e/WUbf4Y+PLnA/+WRV+Vp13ZavKrucnrQ53J+/0RA6zFig+a/sCsWczeX8z/5c2N/s+b7Z+U8N
+sks+rLPnKQ/k88cz7SfosCM3OBszJA5lQht1EjN+jy9omN53NEN+0NJoK5f0vlpy7C/3Bn5/I85
/d181QU91IDtnLQ50tJ/0RBdz5Ht1M0fmMRv0cbf/volnfxRadvoH9rqv53lHNPjP9bvKdA9fdvv
/P0gACQAOY4kKiZryqYqDLstaq7u+eYnX74/MEgb7nyimu72m5VszVirV4TWesdrTqhd6oxYb1bF
fCZ3zqRvOo5ZrVskEV4MI81AFu48PNLp1y/gmyCcXGHanVLV0hleX92N216b1+BWmBvmXxTTWmNV
52Oin5qRn9bUX+QoH5mip0yflCEaYGSlZVcqmCaN3SKbHqEJF3Et5W3Q5a6u6XBrFFU0c7Fk6bFg
4rLvopkoD+caXzdhLykvshCq+TXrN9rrKzSr9a/xOXquLj37sDs0fDAyzgLJm3QPH65kCN+YYrjw
/mGTLOsOZoPkL5uYO1AqapxhEGKZapqaeYQkENyqkqjKGWoIktzLQS5PxayZUKNNmJVm5nzYkCdC
oDh7Ei1q9OgtoTmV5kMKkWlNqDqdUq1q9SrWrFq3cu3q9SvYsGLHki1r9izatGrXsm3r9i3cuHLn
0q1r9y7evHr38u3r9y/gwIIHvw0gQECAAIQXM26MToCFDZI3WLBQQIDjzHETK9aMsMDk0JMtY/aM
r7NpopwNI06cepAA0bJHF7j14HaKB0J0A+C95TZuEsCHv+ab+DDy5KiLA4k8WzIH0RaW70bhW8v1
37lfZLe6+jv478wFsU5uvsH4IM45RIfuvr1k/gdvsvP2Ddy6cOvBt+Pnf5WzeQEK6Fol3WH3g4Fr
lSfgYQ2UtkUFEVbQGAbsRWchhuxBx4ED1CEYRH39hdhbfyUCkeBRCzK4ImKD6Ibih3cdx6IADXQI
YQoTLgZBhhlueEAHFKCn3YkxjggjcdxhpSKNATroIonbBTdlb/bpZ+V+YRnWAJddOpicjQ8GoSMJ
ZAIgIQoTRlgmmWi2JUCPGQKZAQUQtEhkjFVSGaWeeOb3H5gNfkkjl1DSV1+Ie44Y5Z5a2ujAow5I
CimkNg4phJk5pskmp2d6WqZbDWRwAKmldtABnRA46CGISjIq4p/+xcrnrFQxOSiXLBY6n4lW/ubn
66LBjlXjpJQWW6mqb0hoZpugOvvppqFSkAG11Na5Kjq+vlrln8LKSt+STbIIqSDD2afti7Dq2SiM
WRF7LLwOTHApMs1Ca++ybrHWQAH9XoYcZ8jcVyJuR1554sCyUlWjuAJaWm6vBPNpsKu0fvXuo5F2
CYGQOEZ777PN2qtga+GpyGpqAXTZMHINQHCjnxNLrGis3oYlQLzwUjCBmEAw+7GOI6vZqVomG01g
egDg7AAETTv9NNRNT5Asr/6hS+J+514tlso5TzoBBTBrkW+Oa4Yc7ZqZJt3Xu14fCwC2a/+wdM4T
VMCz3HlDdPTRer/g8svFclxBx34bfvhV/g1QsPgEYEsoH+KRS65ajRwvvvjLDaA8Oeedwwbmyg1u
7jnppZNgGN+HmU7T6pHzDeB4GA11CkqISBSOTR+17t3rAb+2EjUKORPPE3lIQ5QtZ0kVWO9Ie6aM
GOsoM8oljAQkzid1dOHRPkvhPhU3m9gu/lG6Kx8Y9OYAbxIt5MNSz0A2xEJP8i8B35TwWAQE0PE9
1Q+S7IKXjNoNsH3I695N9pEJ6oHjFypxRBrYtwr6seMpuWBfIKaHiHe4AxQq0R5LKLgU8FWwF/o7
HkYCeMCDzC6Du2hGKqgXDVAcAn/aQKD9LtgSmGBQEf/o4PzmcUJaGGR5rJMDR/QBQgNG/vARXPhg
DZ0oQpkIYxb36Mcz3me8TsgCh2yYYlR0qMArpnB+W4SgOEQxlCKOcI1j3EQQQ4g9IuqDiyKESgqt
SJJuGE+IGXniOPixES9aMA5jhOE2flg8NA5kKuorYVDE6EIG3o4YOMgiMyToRnuULx1FMaIRAVjF
7qVkiK6wnjQuicaCgDGHhpxk/jAZvUb0cBo2rCMhw5gVUHIlj6QcIB8vQsDtBfKKgyRITNShx46Y
8hljsKMQ63dJTu5ul55cITpC+RROLHN8EeljFj1YzJQ8sprWPGc23fKTT0bSnO5UizYXwst30rOe
9rwnPvOpz33ys5/+/CdAAyrQgRK0/qAGPShCE6rQhTK0oQ59KEQjKtGJUrSiFr2oZhigUY0yZqMM
+IFHUbBRkGI0Mx4d6Vs+io6TqpQEJxUpADgK05I2RqYutelacDoIm/JUphz9aUtbStPF6BSnIRWp
UHuq0xQYVaVAFeoLXorUpSK1qjetKlBnOlSiUvWmR41pUJ3K0iA01atfjepRWQpVq6IUrFj9aFC3
6hipWtWtV71rT8maVLHWFaR7nape21pWsDpVrhltq1/Zyte+MvWvgl1rXYsKWbra9a5M9apha6rU
r/pUrGNNrGIbK4S8ihati63sUuPa1czeRbKWLSpqIQtavP5Vr4xNbVgjC9Xcrpa1/nVBbGdv29Tc
zhalxpVtZQnLWNoSF7ii7a1v6aLWqZ5VuY2tLnXT+lkgcHa710UsYWGL1ej+hbLKda1fexvS4ILX
tHtVb3uru9b2kpee0K0vfrdw3/zyd7b9/S+AAyzgARO4wAY+MIITrOAFM7jBDn4whHui1glTuMIW
vjCGM6zhDXO4wx7+MIhDLOIRZ3gv+43wYE6sFuSi+LDSZXGLPQPjs8w4xjKu8VhwbOOMtkXFOzYp
W3T84xuveMiIEzJWkOxOqiYVGXFFynRfq2QtTPkoVXYKkhegZS3nZAFv8DIAwAwEMQuBzF/+gZkX
gtvl6lerRpmwlGvi46pc2crI/iBzmh+S5xfsOQV9Rkia/3yLp4YXzoONKUx5CliXUlerh45tcq27
aLce97G83W1e2SvkOhNFyWYW85bRHGY8c5kEoeYzqE2NglKrutWiDvOqV13qU5uay6mGNatp/V0P
RzbRnsWsdbV72uQO171hrfR6hd1Z4CobruZtc47R8WlXfxrM1o61q7F9bVhz+9Z93na3tf1qb1/7
1te9KmlHSt8nEzqr6ubru40t2doGF931Ji2l533eZUt6p2KZ8rS5LXBqEzzbBt92oAc+bnHz+dW4
xvbDDQ7pdBP3soxGN6LdnXF4b1ze6S3trrNK2+yKHOQlx7e/wwLwhgs84OEu/rifWQ5uWf8Z3KDO
tcO9bG6dbznNmW5uxR09XmdTuuNFJ3ppwcvs9CY7tGaNN1rfqlsn/xsfATd3wXfu8FbPnOtlhjnD
Y65qrf/554p19nzd/O5j93vtxXUs0C07dUhH3bT7Bix9qVx1aYu95Sx/ud9l7nXAd13s3g47xAc+
68CbHO2O3+5P3bxvtjMb7SMHNr7pOlaKLxvqdpXqcPM+2r3fueeoTji1WT1qNB++1n3Xec5pLftq
J57nNOcu0D1b8qJffO6I7ivF5e75Yn83zsAOr/El7do5c9omzWcL6mOC5zc//3AoF0T1X5L9tLj8
Jd3PyZxJF+VKbB8i5ddn/vjFj903nF/NRvZc+xES//cDZv4rpT/n7E/1M0Mk+tLvierZhKBdBdbR
xQBuHUjo36BVhf95X5cdxQEyYOIZIN/JGelpQbntma7ZmqyFm7Wp3uwlHAiCoMKN2gdOX+ppXcTF
GgmeIMy5YK2lWp6dmu3d3tjN4OqNXQz62QjOIM7NWq794N/BYAFy1wV+XQ5GH8ItoesFngxO4OIx
XgA64RBmnbYFms3ZnBT6HbkhYRJmXeFFYRQSHtg5IcJB3AcuHBdOIElF2xZoIRK2HhkOHhuiYc6N
GeLpoBXS4evZodfBXtfJIR7u4Rz24RaW4LeFHRwCXsypIOxB2xEOYhGa/iAcymHP3Rwm3mEMTqIg
6iEV8qEfHiIgthwQ0iAG+uElluEnUmIm2iAPmiIdpmIJmiDNLZ6gKSA+wNgioqIiqmLfHVwvStwq
siAvguIL8uIoNlwDVqExFqElnuLfSdwzRiPDiSAkkgWL7SLXVWIwkmEBimETzmInZts0+uAxnuMa
GqMhzqEzniEhamM5FqPgHeLo0Rg0cuIjUmItkmMPuiILkhrjnV4dVhupjWEjouAOhiItJmRANuHO
4Zw05qDi9aM/umIXMiQObiNCGmFapJ9jRCBagCSgAUbZBZnhiORZoGQF9kWfeWRW4CL+mWRKwWRM
ogVNOl9NuthcuGROMsbFTVJfUfxkT9qWXniXidmYUfoFiS0lUzalUz4lVEalVH7YUFalVV4lVmal
Vm6lb4UAADs=
------=_NextPart_CC0_4D25_89C8ECD9.B30EB414--




From sip-bounces@ietf.org Mon Apr 02 12:36:36 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYPVs-0004gO-DC; Mon, 02 Apr 2007 12:36:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYPVq-0004gJ-AE
	for sip@ietf.org; Mon, 02 Apr 2007 12:36:10 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYPVp-0003EI-1b
	for sip@ietf.org; Mon, 02 Apr 2007 12:36:10 -0400
Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com)
	([172.19.96.182])
	by sj-iport-6.cisco.com with ESMTP; 02 Apr 2007 09:36:08 -0700
Received: from [64.142.29.213] ([10.21.101.61])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l32GDsQv009946;
	Mon, 2 Apr 2007 09:13:54 -0700
Message-ID: <46113190.9030008@cisco.com>
Date: Mon, 02 Apr 2007 09:38:40 -0700
From: Michael Thomas <mat@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
	rv:1.8.0.10) Gecko/20070221 Thunderbird/1.5.0.10 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme
References: <C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>	<7374777208BDC7449D5620EF942325670309DBB3@esealmw113.eemea.ericsson.se>	<17936.45791.216617.191428@harjus.tutpro.com>
	<B4D957D7-D453-4ECC-AA5E-1AAEEBD05094@softarmor.com>
In-Reply-To: <B4D957D7-D453-4ECC-AA5E-1AAEEBD05094@softarmor.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1664; t=1175530434;
	x=1176394434; c=relaxed/simple; s=oregon;
	h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; 
	d=cisco.com; i=mat@cisco.com;
	z=From:=20Michael=20Thomas=20<mat@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20RE=3A=20Securing=20Other=20URI=20(Tel=20URI)=
	20scheme |Sender:=20
	|To:=20Dean=20Willis=20<dean.willis@softarmor.com>;
	bh=tPP9WTR01qJAwsKSEiVNVKWE2DcIgLJC6WQ4cyfLVPE=;
	b=cD6+de8MeupufoJSOCCs6FLCMlgJ90qzStmn69+ud9ckOfgqdBy5qTOWxu9g1MqkVmBkY3sd
	ADIDR/cd9tI6gVw9nbKjU+FQTzSfEWoQbKuSwbjd7+yaJn7pXTHvWs4O;
Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass (
	sig from cisco.com/oregon verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: Cullen Jennings <fluffy@cisco.com>, IETF SIP List <sip@ietf.org>,
	Juha Heinanen <jh@tutpro.com>, Francois Audet <audet@nortel.com>,
	"Christer Holmberg \(JO/LMF\)" <christer.holmberg@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Dean Willis wrote:
>
> On Apr 2, 2007, at 2:38 AM, Juha Heinanen wrote:
>
>> Christer Holmberg \(JO/LMF\) writes:
>>
>>> Then, why do we need tel in the first place?
>>
>> the only reason that i have found is the refer/302 problem to pstn.
>>
>
> While I'll agree that we need tel: for just this problem, I don't see 
> a driving imperative for tels:
>
> 1) We have agreed that SIP nodes will use TLS if possible, so if it is 
> possible to route the tel: request over TLS, then we'll get TLS. 
> Right? (or is that the bogus assumption I think it is?)
>
> 2) Since the tel: request is possibly going to get routed over the 
> PSTN, it can already be assumed to be somewhat security compromised. 
> That is, it really isn't worthy of a "s" modifier.
Dean, with all due respect, this is nonsense. The Internet and the PSTN 
are different
animals and they need to be each evaluated on their own merits to determine
whether various security measures are needed/necessary. It's perfectly 
possible
to have a situation where the PSTN security is greater than Internet 
security as it
will be deployed and thus _require_ stronger security mechanisms to get 
the needed
overall risk to be acceptable. "Secure" and "Insecure" in the abstract 
are meaningless
assertions.
 
WRT SIPS, TELS just points out how designing a particular mechanism for an
extremely narrow use in highly tailored environments gets us into huge
problems when it's done in the context of internet-wide standards. It 
begs these
kinds of questions, as well as obscuring the basic fact that faithfully 
replicating a
mistake is still a mistake.

       Mike

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 13:12:33 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYQ3g-000748-5V; Mon, 02 Apr 2007 13:11:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQ3e-00073x-HA
	for sip@ietf.org; Mon, 02 Apr 2007 13:11:06 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQ3b-0000sS-6e
	for sip@ietf.org; Mon, 02 Apr 2007 13:11:06 -0400
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-2.cisco.com with ESMTP; 02 Apr 2007 13:11:03 -0400
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l32HB0RE013397; 
	Mon, 2 Apr 2007 13:11:00 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l32HA8H9004636; 
	Mon, 2 Apr 2007 17:10:44 GMT
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.1830); 
	Mon, 2 Apr 2007 13:10:31 -0400
Received: from [161.44.174.244] ([161.44.174.244]) by
	xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 2 Apr 2007 13:10:30 -0400
Message-ID: <46113906.7060106@cisco.com>
Date: Mon, 02 Apr 2007 13:10:30 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Scott Lawrence <slawrence@pingtel.com>
Subject: Re: [Sip] Securing Other URI (Tel URI) scheme
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C0CE@zrc2hxm2.corp.nortel.com>
	<1175530512.11206.56.camel@scott.skrb.org>
In-Reply-To: <1175530512.11206.56.camel@scott.skrb.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 Apr 2007 17:10:30.0974 (UTC)
	FILETIME=[D16925E0:01C77549]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1924; t=1175533860;
	x=1176397860; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20Securing=20Other=20URI=20(Tel=20URI)=20scheme
	|Sender:=20 |To:=20Scott=20Lawrence=20<slawrence@pingtel.com>;
	bh=KOKGjMLFgWA82GLRKKf9u1ZxbSPEEHIANd4Hs3OB090=;
	b=zRsaTXqOqc1OgSZPVwwiYaJ4ioNsZ6gkEskR0XDpO0FnQpizZyBhJQKYHmdMEJh+s2BnjnfR
	4QTKjDNetferZKSki4PCV0yzKiN8c65dxuLl+EUJ5krYc/tMQPF6vj+7;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: IETF SIP List <sip@ietf.org>, Francois Audet <audet@nortel.com>,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org



Scott Lawrence wrote:
> On Tue, 2007-03-27 at 14:38 -0500, Samir Srivastava wrote:
>> Changed the subject.
>>
>> But the UAC wanted its Tel Uri Request to traverse securely on the
>> intermediate hops. How it can enforce that?    
> 
> The only real utility of the tel uri is for addressing something through
> the PSTN.  Once you've crossed that boundary, the security is
> meaningless anyway, so there is little point it protecting it in the sip
> in the first place.
> 
> Using a tel uri for end-to-end sip has no advantage over a sip uri, so
> if you're going to do that anyway, you have sips available to protect
> it.

If I give you a TEL URI, it presumably means that I am *reachable* at 
that number via the PSTN. I may also be reachable directly via SIP, 
using ENUM for the mapping. Giving you the TEL maximizes the options you 
have to reach me.

Now you may want to reach me via SIP, and to do so securely. If you do 
the ENUM lookup yourself then you can discover if there is a SIPS 
mapping and use it. That doesn't require TELS.

Alternatively, you may want to delegate the ENUM processing to your SP. 
Then the question is whether you can then also say that you want a 
secure call. One possible way is for you to convert the TEL uri to a 
SIPS URI with user=phone and with the domain of your own SP. This will 
only work if the SP agrees to provide this feature. In that case, it 
would first check to see if this is an address it hosts. If so it would 
map it appropriately. If not, it may choose to do you the benefit of 
doing an ENUM lookup for you. If that succeeds, because the incoming 
request was SIPS it should only choose a translation that is also SIPS, 
and then route the call to that.

If there is no ENUM translation for the number, it *could* decide to 
route the call to the PSTN. Then you will get whatever security the PSTN 
provides.

	Paul

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 13:29:27 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYQL3-0002NR-Qe; Mon, 02 Apr 2007 13:29:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQL3-0002NB-3R
	for sip@ietf.org; Mon, 02 Apr 2007 13:29:05 -0400
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQKx-0004Mw-M8
	for sip@ietf.org; Mon, 02 Apr 2007 13:29:05 -0400
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	072782128C; Mon,  2 Apr 2007 19:28:53 +0200 (CEST)
X-AuditID: c1b4fb3e-ad1e9bb0000061ca-dc-46113d54f2bf 
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	D7A4820152; Mon,  2 Apr 2007 19:28:52 +0200 (CEST)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 2 Apr 2007 19:28:52 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme
Date: Mon, 2 Apr 2007 19:28:50 +0200
Message-ID: <7374777208BDC7449D5620EF942325670319FCF7@esealmw113.eemea.ericsson.se>
In-Reply-To: <B4D957D7-D453-4ECC-AA5E-1AAEEBD05094@softarmor.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme
Thread-Index: Acd1QKLA2Gfweg9fQMqJYi29KF8kygAC2Xgg
From: "Christer Holmberg \(JO/LMF\)" <christer.holmberg@ericsson.com>
To: "Dean Willis" <dean.willis@softarmor.com>, "Juha Heinanen" <jh@tutpro.com>
X-OriginalArrivalTime: 02 Apr 2007 17:28:52.0228 (UTC)
	FILETIME=[61CF2C40:01C7754C]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: Cullen Jennings <fluffy@cisco.com>, IETF SIP List <sip@ietf.org>,
	Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

=20

>While I'll agree that we need tel: for just this problem, I=20
>don't see a driving imperative for tels:
>=20
>1) We have agreed that SIP nodes will use TLS if possible, so=20
>if it is possible to route the tel: request over TLS, then=20
>we'll get TLS. =20
>Right? (or is that the bogus assumption I think it is?)
>=20
>2) Since the tel: request is possibly going to get routed=20
>over the PSTN, it can already be assumed to be somewhat=20
>security compromised. =20
>That is, it really isn't worthy of a "s" modifier.

How can we assume that a tel has a higher possibility to get routed over
the PSTN than sip???

Regards,

Christer

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 13:35:13 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYQQg-0005ab-Lc; Mon, 02 Apr 2007 13:34:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQQf-0005aW-RK
	for sip@ietf.org; Mon, 02 Apr 2007 13:34:53 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQQe-000653-GJ
	for sip@ietf.org; Mon, 02 Apr 2007 13:34:53 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l32HYnb03803; Mon, 2 Apr 2007 17:34:49 GMT
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: [Sip] Securing Other URI (Tel URI) scheme
Date: Mon, 2 Apr 2007 12:34:40 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF0FDBC56A@zrc2hxm0.corp.nortel.com>
In-Reply-To: <1175530512.11206.56.camel@scott.skrb.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Securing Other URI (Tel URI) scheme
thread-index: Acd1QhwHIuWUwinzS+ygeq+0T6GBqAACxJYQ
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C0CE@zrc2hxm2.corp.nortel.com>
	<1175530512.11206.56.camel@scott.skrb.org>
From: "Francois Audet" <audet@nortel.com>
To: "Scott Lawrence" <slawrence@pingtel.com>,
	"Samir Srivastava" <samirsr@nortel.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: IETF SIP List <sip@ietf.org>, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Exactly.=20

> -----Original Message-----
> From: Scott Lawrence [mailto:slawrence@pingtel.com]=20
> Sent: Monday, April 02, 2007 09:15
> To: Srivastava, Samir (SC100:8826)
> Cc: Audet, Francois (SC100:3055); IETF SIP List; Dean Willis
> Subject: Re: [Sip] Securing Other URI (Tel URI) scheme
>=20
> On Tue, 2007-03-27 at 14:38 -0500, Samir Srivastava wrote:
> > Changed the subject.
> >=20
> > But the UAC wanted its Tel Uri Request to traverse securely on the
> > intermediate hops. How it can enforce that?   =20
>=20
> The only real utility of the tel uri is for addressing=20
> something through the PSTN.  Once you've crossed that=20
> boundary, the security is meaningless anyway, so there is=20
> little point it protecting it in the sip in the first place.
>=20
> Using a tel uri for end-to-end sip has no advantage over a=20
> sip uri, so if you're going to do that anyway, you have sips=20
> available to protect it.
>=20
> --
> Scott Lawrence  tel:+1-781-938-5306;ext=3D162 or=20
> sip:slawrence@pingtel.com
>   sipXpbx project coordinator - SIPfoundry   =20
> http://www.sipfoundry.org/sipX
>   Chief Technology Officer    - Pingtel Corp. http://www.pingtel.com/
>=20
>=20
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 14:10:40 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYQye-00058V-5r; Mon, 02 Apr 2007 14:10:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQyc-00058O-Nd
	for sip@ietf.org; Mon, 02 Apr 2007 14:09:58 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQyb-0007v3-DJ
	for sip@ietf.org; Mon, 02 Apr 2007 14:09:58 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l32I9rb27362; Mon, 2 Apr 2007 18:09:53 GMT
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: [Sip] RE: Securing Other URI (Tel URI) scheme
Date: Mon, 2 Apr 2007 13:09:57 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E6120F38DD@zrc2hxm2.corp.nortel.com>
In-Reply-To: <D048C57F-8F00-4C42-B857-8CB3FD1751C0@softarmor.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] RE: Securing Other URI (Tel URI) scheme
thread-index: Acd1QPJU71yXo6+HQ923DxzHPnSkOgAEM7hw
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Dean Willis" <dean.willis@softarmor.com>,
	"Francois Audet" <audet@nortel.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: Cullen Jennings <fluffy@cisco.com>, IETF SIP List <sip@ietf.org>,
	Juha Heinanen <jh@tutpro.com>, Paul Kyzivat <pkyzivat@cisco.com>,
	"Christer Holmberg \(\(JO/LMF\)\)" <christer.holmberg@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I would say rather start working on SIP 3.0 :-)=20

Business guys will kill me ....

Thx
Samir

>-----Original Message-----
>From: Dean Willis [mailto:dean.willis@softarmor.com]=20
>Sent: Monday, April 02, 2007 9:06 AM
>To: Audet, Francois (SC100:3055)
>Cc: Cullen Jennings; IETF SIP List; Juha Heinanen; Paul=20
>Kyzivat; Christer Holmberg ((JO/LMF))
>Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme
>
>
>On Apr 2, 2007, at 10:34 AM, Francois Audet wrote:
>
>>
>> Kind of like saying SIP is complicated and has bugs. Let's just=20
>> deprecate SIP.
>
>Yesterday, I'd have heartily agreed with this comment.
>
>;-)
>
>--
>Dean
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol Use=20
>sip-implementors@cs.columbia.edu for questions on current sip=20
>Use sipping@ietf.org for new developments on the application of sip
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 14:22:33 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYR9c-0005PI-Ip; Mon, 02 Apr 2007 14:21:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYR9a-0005MI-W7
	for sip@ietf.org; Mon, 02 Apr 2007 14:21:18 -0400
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYR9Z-0004uA-De
	for sip@ietf.org; Mon, 02 Apr 2007 14:21:18 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	l32IKou01736; Mon, 2 Apr 2007 18:20:50 GMT
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: [Sip] Securing Other URI (Tel URI) scheme
Date: Mon, 2 Apr 2007 13:21:17 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E6120F3929@zrc2hxm2.corp.nortel.com>
In-Reply-To: <1175530512.11206.56.camel@scott.skrb.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Securing Other URI (Tel URI) scheme
thread-index: Acd1QhymbVdpRbnXRo29xPtCEnfd1wAET27g
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Scott Lawrence" <slawrence@pingtel.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: IETF SIP List <sip@ietf.org>, Francois Audet <audet@nortel.com>,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


With what level of security using 40 bit ciphers, who is stopping them
not to use that ?

Tel is just one example what about im:, pres: etc...=20

Thx
Samir

>
>Using a tel uri for end-to-end sip has no advantage over a sip=20
>uri, so if you're going to do that anyway, you have sips=20
>available to protect it.
>
>--
>Scott Lawrence  tel:+1-781-938-5306;ext=3D162 or=20
>sip:slawrence@pingtel.com
>  sipXpbx project coordinator - SIPfoundry   =20
>http://www.sipfoundry.org/sipX
>  Chief Technology Officer    - Pingtel Corp. http://www.pingtel.com/
>
>
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 14:35:40 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYRN1-0006Uh-Up; Mon, 02 Apr 2007 14:35:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYRN0-0006UQ-C9
	for sip@ietf.org; Mon, 02 Apr 2007 14:35:10 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYRMz-0001Uy-0y
	for sip@ietf.org; Mon, 02 Apr 2007 14:35:10 -0400
Received: from [171.70.229.153] (dhcp-171-70-229-153.cisco.com
	[171.70.229.153]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l32HfZTe022359
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Mon, 2 Apr 2007 12:41:36 -0500
In-Reply-To: <17937.11565.569792.405389@harjus.tutpro.com>
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C0CE@zrc2hxm2.corp.nortel.com>
	<1175530512.11206.56.camel@scott.skrb.org>
	<17937.11565.569792.405389@harjus.tutpro.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <29448B64-2604-470A-8640-B61637D1DAA0@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] Securing Other URI (Tel URI) scheme
Date: Mon, 2 Apr 2007 13:35:05 -0500
To: Juha Heinanen <jh@tutpro.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: IETF SIP List <sip@ietf.org>, Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 2, 2007, at 11:19 AM, Juha Heinanen wrote:

>
> security is meaningless unless it is end-to-end.
>

I keep my money in a secure bank, but occasionally I take some of it  
out as cash, put it in my wallet, and walk to the store with it. The  
security provided by the bank ends when I withdraw the cash.

Was that security meaningless?


Similarly, with sips.


I might be working from a hotel owned by my competitor in a country  
owned by my competitor (I think big -- judge a man not by his  
friends, but by his competitors). From here, I would like to call  
into a conference bridge back at my office. Some of the other users  
calling into the conference bridge will be calling over the PSTN in a  
country not owned by me competitor.

So I might use a VPN client back to my office, and place the call  
over that into the conference bridge.

Does the fact that other people are calling into the bridge using  
unsecured PSTN lines render the security provided by the VPN  
meaningless?

Security always has to be evaluated with respect to a threat. No  
single security mechanism can address all threats. Using the wrong  
mechanism for a specific threat can be worse than useless.

There do appear to be a subset of problems for which sips:, as  
documented by Francois Audet, seems to be useful. I accept that we  
have not clearly explained that subset, and that a larger subset  
exists for for which sips: is arguably not useful. However, there do  
appear to be people using sips: somewhat appropriately, and I think  
we owe them a clarification of that specification so that they can  
have a greater chance of using it successfully.

I also think we need to develop other mechanisms for other subsets of  
the problem space, and that we need to be far more clear about the  
usage of each mechanism and the appropriateness of those mechanisms  
for different sorts of threats.

--
Dean
  

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 14:57:23 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYRhe-0006nR-8s; Mon, 02 Apr 2007 14:56:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYRhb-0006mX-Um
	for sip@ietf.org; Mon, 02 Apr 2007 14:56:27 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYRha-000660-MX
	for sip@ietf.org; Mon, 02 Apr 2007 14:56:27 -0400
Received: from [171.70.229.153] (dhcp-171-70-229-153.cisco.com
	[171.70.229.153]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l32I2kwp022490
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Mon, 2 Apr 2007 13:02:47 -0500
In-Reply-To: <29448B64-2604-470A-8640-B61637D1DAA0@softarmor.com>
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C0CE@zrc2hxm2.corp.nortel.com>
	<1175530512.11206.56.camel@scott.skrb.org>
	<17937.11565.569792.405389@harjus.tutpro.com>
	<29448B64-2604-470A-8640-B61637D1DAA0@softarmor.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <51AF26D9-CA3E-4160-A501-665366ADE82F@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] Securing Other URI (Tel URI) scheme
Date: Mon, 2 Apr 2007 13:56:17 -0500
To: Dean Willis <dean.willis@softarmor.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: IETF SIP List <sip@ietf.org>, Juha Heinanen <jh@tutpro.com>,
	Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 2, 2007, at 1:35 PM, Dean Willis wrote:

>
> There do appear to be a subset of problems for which sips:,

Eek! Call the grammar police.

"There does appear. . ."

My bad.

--
dean


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 15:17:31 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYS1a-0003Ua-Hp; Mon, 02 Apr 2007 15:17:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYDvN-0007Nc-74
	for sip@ietf.org; Mon, 02 Apr 2007 00:13:45 -0400
Received: from [203.187.132.25] (helo=tapal.aricent.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYDvK-0001MY-TZ
	for sip@ietf.org; Mon, 02 Apr 2007 00:13:45 -0400
Received: from tapal.aricent.com (localhost [127.0.0.1])
	by tapal.aricent.com (8.13.8/8.13.8) with ESMTP id l324DMEe019206
	for <sip@ietf.org>; Mon, 2 Apr 2007 09:43:24 +0530
Received: from pragati.blr.hss.hns.com (pragati.blr.hss.hns.com 
	[10.203.193.22])by tapal.aricent.com (8.13.8/8.13.8) with ESMTP id 
	l324DLdC019201;Mon, 2 Apr 2007 09:43:21 +0530
In-Reply-To: <5D1A7985295922448D5550C94DE29180DC1CC4@DEEXC1U01.de.lucent.com>
To: "Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>
Subject: Re: [Sip] WGLC on draft-ietf-sip-location-conveyance
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004
Message-ID: <OF1827C20F.727F664C-ON652572B1.0017196E-652572B1.00174596@flextronicssoftware.com>
From: rishu.jain@aricent.com
Date: Mon, 2 Apr 2007 09:43:35 +0530
X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5.5|November 
	30, 2005) at04/02/2007 09:41:23 AM,Serialize complete at 04/02/2007 
	09:41:23 AM
X-imss-version: 2.046
X-imss-result: Passed
X-imss-scanInfo: M:B L:N SM:2
X-imss-tmaseResult: TT:1 TS:-8.6920 TC:03 TRN:95 TV:3.6.1039(15086.002)
X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0
X-imss-settings: Baseline:2 C:1 M:1 S:1 R:1 (0.0000 0.0000)
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 2b3349545af520ba354ccdc9e1a03fc1
X-Mailman-Approved-At: Mon, 02 Apr 2007 15:17:04 -0400
Cc: sip@ietf.org, geopriv-chairs@tools.ietf.org, jmpolk@cisco.com,
	dean.willis@softarmor.com
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0992419004=="
Errors-To: sip-bounces@ietf.org

This is a multipart message in MIME format.
--===============0992419004==
Content-Type: multipart/alternative;
	boundary="=_alternative 0017458F652572B1_="

This is a multipart message in MIME format.
--=_alternative 0017458F652572B1_=
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: base64

U29tZSBjb21tZW50cy9xdWVzdGlvbnMgb24gdGhlIGRyYWZ0LiANCg0KDQoxKSBNdWx0aXBsZSBM
b2NhdGlvbnM6DQotIFNlY3Rpb24gNS4zLjENCkEgc2VydmVyL3Byb3h5IGNhbiBhZGQgZ2Vsb2Nh
dGlvbiB2YWx1ZSB0byB0aGUgZXhpc3RpbmcgZ2VvbG9jYXRpb24gDQpoZWFkZXIgcHJvdmlkZWQg
YnkgVUFDLiBJbiB0aGF0IGNhc2UgdGhlIG1lc3NzYWdlIHdvdWxkIGxvb2sgbGlrZSB0aGlzOg0K
DQpHZW9sb2NhdGlvbjogPGNpZDphbGljZTEyM0BhdGxhbnRhLmV4YW1wbGUuY29tPjsgaW5zZXJ0
ZWQtYnk9ZW5kcG9pbnQsDQogICAgICAgICAgICAgPHNpcHM6M3NkZWZyaHkyamo3QGxpcy5hdGxh
bnRhLmV4YW1wbGUuY29tPjsgDQogICAgICAgICAgICAgaW5zZXJ0ZWQtYnk9c2VydmVyOyANCg0K
PT5Ib3cgdGhlIGxvY2F0aW9uIHJlY2lwaWVudCB3aWxsIGRlY2lkZSB3aGljaCBsb2NhdGlvbiBp
cyB0byANCmJlIHJlZmVycmVkIHRvPyBFaXRoZXIgdGhlIG9uZSBwcm92aWRlZCBpbiB0aGUgU2lw
IG1lc3NhZ2UgKENJRCBVUkkpIA0Kb3IgaGUgaGFzIHRvIHN1YnNjcmliZSB0byB0aGUgbG9jYXRp
b24gcHJvdmlkZWQgaW4gU0lQUyBVUkk/DQoNCjIpIExvY2F0aW9uIGJ5IHJlZmVyZW5jZSBvdmVy
aGVhZDoNCkxvb2sgYXQgdGhlIGZvbGxvd2luZyBzY2VuYXJpbyAoUCAtIGlzIGFsc28gYSBsb2Nh
dGlvbiByZWNpcGllbnQpOg0KDQogICAgICAgICAgICAgTElTICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBMSVMgDQogICAgICAgICAgICBeICB8ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBeICB8IA0KU1VCU0NSSUJFIHwgIHwgTk9USUZZICAgICBTVUJTQ1JJQkUgfCAgfE5P
VElGWQ0KICAgICAgICAgICAgfCAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg
fA0KVUEgLS0tLS0tLT4gIFAxIC0tLS0tLS0tLS0tLS0tLS0tLT4gIFAyICAtLS0tLS0tLS0tLT4N
CiAgIElOSVZJVEUgICAgICAgICAgIElOVklURSAgICAgICAgICAgICAgICBJTlZJVEUNCg0KSW4g
b3JkZXIgdG8gdGFrZSBhY3Rpb24gYmFzZWQgb24gInJldHJhbnNtaXNzaW9uLWFsbG93ZWQiIG9y
IG5vdCwgDQpQMSBoYXMgdG8gc3Vic2NyaWJlIHRvIHRoZSBMSVMgKExvY2F0aW9uIEluZm9ybWF0
aW9uIFNlcnZlciksIA0Kb2J0YWluIHRoZSBsb2NhdGlvbiBhbmQgdGhlbiB0YWtlIHRoZSBhY3Rp
b24uIFRoZSBzYW1lIGhhcyB0byBiZSANCmRvbmUgYnkgYWxsIHRoZSBpbnRlcm1lZGlhdGUgcHJv
eGllcy4gU28gaXMgdGhpcyBub3QgYSBvdmVyaGVhZD8NCg0KMykgInJldHJhbnNtaXNzaW9uLWFs
bG93ZWQiDQpFdmVuIGlmICJyZXRyYW5zbWlzc2lvbi1hbGxvd2VkIiB2YWx1ZSBpcyBzZXQgdG8g
Im5vIiwgY2FuIHRoZSANCnByb3h5IHJlbW92ZSB0aGUgUElERiBsb2NhdGlvbiBvYmplY3QgZnJv
bSB0aGUgbWVzc2FnZT8gUkZDIDMyNjEgDQpkb2VzIG5vdCBhbGxvdyBhbnkgcHJveHkgdG8gYWRk
IG9yIGRlbGV0ZSB0aGUgbWVzc2FnZSBib2R5LiBTbyB3aGF0IA0KaXMgdGhlIHVzZSBvZiAicmV0
cmFuc21pc3Npb24tYWxsb3dlZCIgd2l0aCB2YWx1ZSAieWVzIiBvciAibm8iPw0KDQo0KSBXaGF0
IGlzIHRoZSBiZWhhdmlvciBpbiBmb2xsb3dpbmcgY2FzZToNCg0KUmV0cmFuc21pc3Npb24tYWxs
b3dlZCBSb3V0aW5nLXF1ZXJ5LWFsbG93ZWQgVHJhbnNtaXNzaW9uIGZvciBRdWVyeQ0KLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0gLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLQ0KICAgICAgICAibm8iICAgICAgICAgICAgICAgICAgbm90IHByZXNlbnQgICAgICAgICAg
ID8/Pz8/DQoNCg0KNSkgIm1lc3NhZ2Utcm91dGVkLW9uLXRoaXMtdXJpIiB0ZWxscyB0aGUgZG93
bnN0cmVhbSBlbnRpdHkgdGhhdCANCmlzIHdhcyByb3V0ZWQgYmFzZWQgb24gbG9jYXRpb24gb25j
ZS4gSW4gc2VjdGlvbiAgNS4zLjEgaXQgaXMgDQptZW50aW9uZWQgdGhhdCBpbiBjYXNlIG11bHRp
cGxlIHRpbWVzIGlmIHJvdXRpbmcgaXMgZG9uZSBiYXNlZCBvbiANCmxvY2F0aW9uIHN0aWxsIG9u
bHkgb25lIGxhdGVzdCBlbnRyeSBvZiAibWVzc2FnZS1yb3V0ZWQtb24tdGhpcy11cmkiIA0KaXMg
c3VmZmljaWVudC4gDQoNCldoeSBkb3duc3RyZW0gZW50aXR5IG5lZWQgdG8ga25vdyB0aGF0IG9u
bHkgb25lIHJvdXRpbmcgaGFzIA0KaGFwcGVuZWQgKGlmIGF0IGFsbCBpdCBuZWVkcyB0byBrbm93
KT8gV2h5IGl0IG5lZWQgbm90IGZpbmQgb3V0IA0KbXVsdGlwbGUgbG9jYXRpb24gYmFzZWQgcm91
dGluZyB3YXMgZG9uZT8NCg0KNikgU2VjdGlvbiAzLjI6IFVzZSBvZiB0aGUgaGVhZGVyIGluIEJZ
RSwgSU5GTyBhbmQgUkVGRVIgDQpNZXRob2RzIGFyZSBhbGxvd2VkLCBhbHRob3VnaCBubyBwdXJw
b3NlIGlzIGtub3duLiAgQ29udmV5aW5nIA0KbG9jYXRpb24gaW4gYSBDQU5DRUwsIEJZRSwgQUNL
IG9yIFBSQUNLIGlzIG5vdCBkZWZpbmVkLiANCg0KQ29udmV5aW5nIGxvY2F0aW9uIGluICJCWUUi
IGlzIGRlZmluZWQgb3Igbm90Pw0KDQo3KSA8c2lwczogdXNlcm5hbWVAc2VydmVyLmNvbT4gb3Ig
PHNpcHM6c2VydmVyLmNvbS91c2VybmFtZT4gDQphcmUgdGhlc2Ugc2FtZT8gSXMgdGhlIHNlY29u
ZCBmb3JtIGEgdmFsaWQgU0lQIFVSST8NCg0KDQo4KSBXaHkgb25seSBQSURGIGZvcm1hdCBpcyBz
ZWxlY3RlZC4NCiANCjkpIEFzc3VtZSB0aGUgY2FzZSB0aGF0IFVBQyBoYXMgc2VudCBoaXMgaWRl
bnRpdHkgaW4gdGhlIGZpcnN0IElOVklURS4gDQpDYWxsZWUgd291bGQgaGF2ZSBzdWJzY3JpYmVk
IHRvIHRoYXQgaWRlbnRpdHkgYW5kIHdvdWxkIGdldCB0aGUgDQpjYWxsZXIncyBsb2NhdGlvbi4g
Tm93IGlmIGNhbGxlcidzIGlkZW50aXR5IGlzIGNoYW5nZWQgYW5kIGNhbGxlciANCnNlbnQgYSBu
ZXcgUkUtSU5WSVRFIG1lc3NhZ2UuIFNob3VsZCBjYWxsZWUgdGhlbiBzdG9wIHN1YnNjcmlwdGlv
biANCndpdGggZmlyc3QgbG9jYXRpb24gYW5kIHNob3VsZCBzdWJzY3JpYmUgdG8gdGhlIG5ldyBs
b2NhdGlvbj8gDQpUaGVyZSBpcyBubyBiZWhhdmlvdXIgd2l0aCByZXNwZWN0IHRvIHRoaXMgaXMg
bWVudGlvbmVkIGluIFVBUyBzY29wZT8NCg0KDQpyZWdhcmRzDQpSaXNodQ0KDQoNCg0KDQoNCg0K
IkRyYWdlLCBLZWl0aCBcKEtlaXRoXCkiIDxkcmFnZUBhbGNhdGVsLWx1Y2VudC5jb20+IA0KMDMv
MDUvMjAwNyAwMTowNSBBTQ0KDQoNClRvDQo8c2lwQGlldGYub3JnPg0KY2MNCmdlb3ByaXYtY2hh
aXJzQHRvb2xzLmlldGYub3JnLCBqbXBvbGtAY2lzY28uY29tLCBkZWFuLndpbGxpc0Bzb2Z0YXJt
b3IuY29tDQpTdWJqZWN0DQpbU2lwXSBXR0xDIG9uIGRyYWZ0LWlldGYtc2lwLWxvY2F0aW9uLWNv
bnZleWFuY2UNCg0KDQoNCg0KDQoNCihBcyBXRyBjaGFpcikNCg0KVGhpcyBpcyB0byBhbm5vdW5j
ZSBhIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9mIA0KDQpodHRwOi8vd3d3LmlldGYub3JnL2lu
dGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXNpcC1sb2NhdGlvbi1jb252ZXlhbmNlLTA3LnR4dA0K
DQoNCkR1ZSB0byB0aGUgcHJlc2VuY2Ugb2YgSUVURiM2OCBpbiBQcmFndWUsIHRoaXMgaXMgYW4g
ZXh0ZW5kZWQgbGFzdCBjYWxsIA0KKGZvciBmb3VyIHdlZWtzKSwgYW5kIGNvbW1lbnRzIHNob3Vs
ZCBiZSBwcm92aWRlZCBieSBzdGFydCBvZiBidXNpbmVzcyBvbiANCk1vbmRheSAybmQgQXByaWwg
MjAwNy4NCg0KSG93ZXZlciBpZiB5b3UgdGhpbmsgdGhlcmUgYXJlIHNpZ25pZmljYW50IHRlY2hu
aWNhbCBpc3N1ZXMgdGhhdCBzaG91bGQgYmUgDQpyYWlzZWQgaW4gSUVURiM2OCwgcGxlYXNlIHJl
dmlldyB0aGUgZG9jdW1lbnQgd2VsbCBiZWZvcmUgdGhhdCB0aW1lIHRvIA0KbWFrZSB5b3VyIGNv
bW1lbnQgdG8gdGhlIGxpc3QsIHNvIHRoYXQgc3VjaCBkaXNjdXNzaW9uIGluIHRoZSBJRVRGIG1l
ZXRpbmcgDQpjYW4gb2NjdXIuDQoNClBsZWFzZSBwcm92aWRlIGFsbCBjb21tZW50cyB0byB0aGUg
U0lQIG1haWxpbmcgbGlzdCwgYW5kIGFsc28gdG8gdGhlIA0KZG9jdW1lbnQgYXV0aG9ycyBsaXN0
ZWQgKGFuZCBtYWlsaW5nIGFkZHJlc3NlcykgbGlzdGVkIGF0IHRoZSBlbmQgb2YgdGhlIA0KZG9j
dW1lbnQuIEZvciBlYWNoIGNvbW1lbnQsIGl0IGlzIGlkZWFsIHRvIHByb3ZpZGUgdGhlIGNvcHkg
dGhlIHNwZWNpZmljIA0KcGFydCBvZiB0aGUgdGV4dCB0aGUgY29tbWVudCBpcyBhZ2FpbnN0LCBp
biBvcmRlciB0byBwcm92aWRlIGNvbnRleHQgb2YgDQp0aGUgY29tbWVudCwgYXMgd2VsbCBhcyBp
ZGVudGlmeWluZyB0aGUgc2VjdGlvbi9wYWdlIGFuZCB0aGUgY29tbWVudCANCml0c2VsZi4gDQoN
ClBsZWFzZSBhbHNvIGNsZWFybHkgaW5kaWNhdGUgd2hldGhlciB0aGUgY29tbWVudCBpcyBlZGl0
b3JpYWwvdGVjaG5pY2FsLCANCmFuZCBpZiB0ZWNobmljYWwgdGhlIGRlZ3JlZSBvZiB0aGUgY29t
bWVudCwgZS5nLiBtaW5vciwgbWFqb3IgZmxhdywgd3JvbmcgDQpzb2x1dGlvbiwgb3Igd2hhdGV2
ZXIuIFRoaXMgaGVscHMgaW4gYXNzZXNzaW5nIHRoZSBvcmRlciBpbiB3aGljaCBjb21tZW50cyAN
CmdldCBhZGRyZXNzZWQgd2hlbiB0aGV5IGFyZSByZXZpZXdlZC4NCg0KSW4gcGFyYWxsZWwgd2l0
aCBXR0xDLCBhIHJldmlldyB0ZWFtIGhhcyBhbHNvIGJlZW4gc2V0IHVwIHRvIHJldmlldyB0aGUg
DQpkb2N1bWVudCwgYW5kIHRoaXMgcmV2aWV3IHRlYW0gd2lsbCByZXZpZXcgYXQgbGVhc3QgdGhl
IHNpZ25pZmljYW50IA0KY29tbWVudHMgZm9yIGltcGxlbWVudGF0aW9uLiBJIHdpbGwgYmUgYWRk
cmVzc2luZyB0aGVtIGluIGEgc2VwYXJhdGUgbWFpbC4NCg0KQXMgdGhlIGRvY3VtZW50IGlzIGEg
bG9jYXRpb24gc3VwcG9ydGluZyBwcm90b2NvbCwgdGhlIGRvY3VtZW50IHdpbGwgYWxzbyANCmJl
IHJldmlld2VkIGJ5IHRoZSBHRU9QUklWIGdyb3VwLiBIb3dldmVyIGl0IGlzIGFwcHJvcHJpYXRl
IGZvciBhbGwgDQpyZWFkZXJzIHRvIHJldmlldyB0aGUgZG9jdW1lbnQgYWdhaW5zdCB0aGUgR0VP
UFJJViByZXF1aXJlbWVudHMgZm9yIHN1Y2ggDQpwcm90b2NvbHMsIHdoaWNoIG1heSBiZSBmb3Vu
ZCBpbiBSRkMgMzk2My4NCg0KVGhlIGFib3ZlIGRvY3VtZW50IGhvd2V2ZXIgZG9lcyBub3QgY292
ZXIgbG9jYXRpb24gYnkgcmVmZXJlbmNlLiBUaGVyZSBpcyANCmEgcHJlbGltaW5hcnkgc2V0IG9y
IHJlcXVpcmVtZW50cyBpbiANCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv
ZHJhZnQtbWFyc2hhbGwtZ2VvcHJpdi1sYnlyLXJlcXVpcmVtZW50cy0wMC50eHQNCg0KDQpGb3Ig
d2hpY2ggd2Ugd291bGQgbGlrZSB0byBhbGlnbiB3aXRoIHdoYXRldmVyIHRoYXQgZG9jdW1lbnQg
ZGV2ZWxvcHMgDQppbnRvLiBUaGVyZWZvcmUgaXQgaXMgYXBwcm9wcmlhdGUgdG8gcmV2aWV3IGFn
YWluc3QgdGhpcyBkb2N1bWVudCwgYW5kIA0KaWRlbnRpZnkgZGlmZmVyZW5jZXMuIFRoZXNlIGNv
dWxkIGVpdGhlciBiZSB0YWtlbiBhcyBjb21tZW50cyBhZ2FpbnN0IHRoZSANCmRyYWZ0LWlldGYt
c2lwLWxvY2F0aW9uLWNvbnZleWFuY2UsIG9yIGFnYWluc3QgdGhlIGxvY2F0aW9uIGJ5IHJlZmVy
ZW5jZSANCnJlcXVpcmVtZW50cy4NCg0KDQpSZWdhcmRzDQoNCktlaXRoDQoNCktlaXRoIERyYWdl
DQorNDQgMTc5MyA3NzYyNDkNCmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbQ0KDQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU2lwIG1haWxpbmcgbGlzdCAg
aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwDQpUaGlzIGxpc3QgaXMg
Zm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgY29yZSBTSVAgUHJvdG9jb2wNClVzZSBzaXAtaW1w
bGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rpb25zIG9uIGN1cnJlbnQgc2lwDQpV
c2Ugc2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRldmVsb3BtZW50cyBvbiB0aGUgYXBwbGljYXRp
b24gb2Ygc2lwDQoNCg0KKioqKioqKioqKioqKioqKioqKioqKiogIEFyaWNlbnQtVW5jbGFzc2lm
aWVkICAgKioqKioqKioqKioqKioqKioqKioqKioNCiJESVNDTEFJTUVSOiBUaGlzIG1lc3NhZ2Ug
aXMgcHJvcHJpZXRhcnkgdG8gQXJpY2VudCBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUg
dXNlIG9mIAp0aGUgaW5kaXZpZHVhbCB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4gSXQgbWF5IGNv
bnRhaW4gcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gYW5kIHNob3VsZCBu
b3QgYmUgCmNpcmN1bGF0ZWQgb3IgdXNlZCBmb3IgYW55IHB1cnBvc2Ugb3RoZXIgdGhhbiBmb3Ig
d2hhdCBpdCBpcyBpbnRlbmRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGlu
IGVycm9yLCAKcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBpbW1lZGlhdGVseS4gSWYgeW91
IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBub3RpZmllZCB0aGF0IHlv
dSBhcmUgc3RyaWN0bHkKcHJvaGliaXRlZCBmcm9tIHVzaW5nLCBjb3B5aW5nLCBhbHRlcmluZywg
b3IgZGlzY2xvc2luZyB0aGUgY29udGVudHMgb2YgdGhpcyBtZXNzYWdlLiBBcmljZW50IGFjY2Vw
dHMgbm8gcmVzcG9uc2liaWxpdHkgZm9yIApsb3NzIG9yIGRhbWFnZSBhcmlzaW5nIGZyb20gdGhl
IHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgYnkgdGhpcyBlbWFpbCBpbmNsdWRp
bmcgZGFtYWdlIGZyb20gdmlydXMuIgo=
--=_alternative 0017458F652572B1_=
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlNvbWUgY29tbWVudHMvcXVlc3Rp
b25zIG9uIHRoZSBkcmFmdC4NCjwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg
ZmFjZT0ic2Fucy1zZXJpZiI+MSkgTXVsdGlwbGUgTG9jYXRpb25zOjwvZm9udD4NCjxicj48Zm9u
dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+LSBTZWN0aW9uIDUuMy4xPC9mb250Pg0KPGJyPjxm
b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5BIHNlcnZlci9wcm94eSBjYW4gYWRkIGdlbG9j
YXRpb24gdmFsdWUNCnRvIHRoZSBleGlzdGluZyBnZW9sb2NhdGlvbiA8L2ZvbnQ+DQo8YnI+PGZv
bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmhlYWRlciBwcm92aWRlZCBieSBVQUMuIEluIHRo
YXQgY2FzZQ0KdGhlIG1lc3NzYWdlIHdvdWxkIGxvb2sgbGlrZSB0aGlzOjwvZm9udD4NCjxicj4N
Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+R2VvbG9jYXRpb246ICZsdDtjaWQ6
YWxpY2UxMjNAYXRsYW50YS5leGFtcGxlLmNvbSZndDs7DQppbnNlcnRlZC1ieT1lbmRwb2ludCw8
L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jmx0O3NpcHM6M3NkZWZyaHkyamo3QGxpcy5hdGxhbnRhLmV4YW1wbGUuY29tJmd0OzsNCjwvZm9u
dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpbnNl
cnRlZC1ieT1zZXJ2ZXI7IDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu
cy1zZXJpZiI+PSZndDtIb3cgdGhlIGxvY2F0aW9uIHJlY2lwaWVudCB3aWxsDQpkZWNpZGUgd2hp
Y2ggbG9jYXRpb24gaXMgdG8gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl
cmlmIj5iZSByZWZlcnJlZCB0bz8gRWl0aGVyIHRoZSBvbmUgcHJvdmlkZWQNCmluIHRoZSBTaXAg
bWVzc2FnZSAoQ0lEIFVSSSkgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl
cmlmIj5vciBoZSBoYXMgdG8gc3Vic2NyaWJlIHRvIHRoZSBsb2NhdGlvbg0KcHJvdmlkZWQgaW4g
U0lQUyBVUkk/PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm
Ij4yKSBMb2NhdGlvbiBieSByZWZlcmVuY2Ugb3ZlcmhlYWQ6PC9mb250Pg0KPGJyPjxmb250IHNp
emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Mb29rIGF0IHRoZSBmb2xsb3dpbmcgc2NlbmFyaW8gKFAg
LQ0KaXMgYWxzbyBhIGxvY2F0aW9uIHJlY2lwaWVudCk6PC9mb250Pg0KPGJyPg0KPGJyPjxmb250
IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7DQombmJzcDsgJm5ic3A7TElTICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgTElTICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IF4gJm5ic3A7fCAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwO14gJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L2ZvbnQ+
DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlNVQlNDUklCRSB8ICZuYnNwO3wg
Tk9USUZZICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7U1VCU0NSSUJFIHwgJm5i
c3A7fE5PVElGWTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyB8ICZuYnNw
O3w8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlVBIC0tLS0tLS0m
Z3Q7ICZuYnNwO1AxIC0tLS0tLS0tLS0tLS0tLS0tLSZndDsNCiZuYnNwO1AyICZuYnNwOy0tLS0t
LS0tLS0tJmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i
c3A7ICZuYnNwO0lOSVZJVEUgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgSU5W
SVRFICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i
c3A7ICZuYnNwOyBJTlZJVEU8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh
bnMtc2VyaWYiPkluIG9yZGVyIHRvIHRha2UgYWN0aW9uIGJhc2VkIG9uICZxdW90O3JldHJhbnNt
aXNzaW9uLWFsbG93ZWQmcXVvdDsNCm9yIG5vdCwgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm
YWNlPSJzYW5zLXNlcmlmIj5QMSBoYXMgdG8gc3Vic2NyaWJlIHRvIHRoZSBMSVMgKExvY2F0aW9u
DQpJbmZvcm1hdGlvbiBTZXJ2ZXIpLCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh
bnMtc2VyaWYiPm9idGFpbiB0aGUgbG9jYXRpb24gYW5kIHRoZW4gdGFrZSB0aGUNCmFjdGlvbi4g
VGhlIHNhbWUgaGFzIHRvIGJlIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z
ZXJpZiI+ZG9uZSBieSBhbGwgdGhlIGludGVybWVkaWF0ZSBwcm94aWVzLg0KU28gaXMgdGhpcyBu
b3QgYSBvdmVyaGVhZD88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt
c2VyaWYiPjMpICZxdW90O3JldHJhbnNtaXNzaW9uLWFsbG93ZWQmcXVvdDs8L2ZvbnQ+DQo8YnI+
PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkV2ZW4gaWYgJnF1b3Q7cmV0cmFuc21pc3Np
b24tYWxsb3dlZCZxdW90Ow0KdmFsdWUgaXMgc2V0IHRvICZxdW90O25vJnF1b3Q7LCBjYW4gdGhl
IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+cHJveHkgcmVtb3Zl
IHRoZSBQSURGIGxvY2F0aW9uIG9iamVjdA0KZnJvbSB0aGUgbWVzc2FnZT8gUkZDIDMyNjEgPC9m
b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5kb2VzIG5vdCBhbGxvdyBh
bnkgcHJveHkgdG8gYWRkIG9yIGRlbGV0ZQ0KdGhlIG1lc3NhZ2UgYm9keS4gU28gd2hhdCA8L2Zv
bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmlzIHRoZSB1c2Ugb2YgJnF1
b3Q7cmV0cmFuc21pc3Npb24tYWxsb3dlZCZxdW90Ow0Kd2l0aCB2YWx1ZSAmcXVvdDt5ZXMmcXVv
dDsgb3IgJnF1b3Q7bm8mcXVvdDs/PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl
PSJzYW5zLXNlcmlmIj40KSBXaGF0IGlzIHRoZSBiZWhhdmlvciBpbiBmb2xsb3dpbmcNCmNhc2U6
PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5SZXRyYW5z
bWlzc2lvbi1hbGxvd2VkIFJvdXRpbmctcXVlcnktYWxsb3dlZA0KVHJhbnNtaXNzaW9uIGZvciBR
dWVyeTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+LS0tLS0tLS0t
LS0tLS0tLS0tLS0tLSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tLS0tLS0tLS0tLS0tLS0tLS0t
LS08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtubyZxdW90Ow0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtub3QgcHJlc2VudA0KJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA/Pz8/PzwvZm9udD4NCjxicj4NCjxicj4NCjxi
cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+NSkgJnF1b3Q7bWVzc2FnZS1yb3V0ZWQt
b24tdGhpcy11cmkmcXVvdDsNCnRlbGxzIHRoZSBkb3duc3RyZWFtIGVudGl0eSB0aGF0IDwvZm9u
dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+aXMgd2FzIHJvdXRlZCBiYXNl
ZCBvbiBsb2NhdGlvbiBvbmNlLg0KSW4gc2VjdGlvbiAmbmJzcDs1LjMuMSBpdCBpcyA8L2ZvbnQ+
DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPm1lbnRpb25lZCB0aGF0IGluIGNh
c2UgbXVsdGlwbGUgdGltZXMNCmlmIHJvdXRpbmcgaXMgZG9uZSBiYXNlZCBvbiA8L2ZvbnQ+DQo8
YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmxvY2F0aW9uIHN0aWxsIG9ubHkgb25l
IGxhdGVzdCBlbnRyeQ0Kb2YgJnF1b3Q7bWVzc2FnZS1yb3V0ZWQtb24tdGhpcy11cmkmcXVvdDsg
PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5pcyBzdWZmaWNpZW50
LiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldoeSBk
b3duc3RyZW0gZW50aXR5IG5lZWQgdG8ga25vdyB0aGF0DQpvbmx5IG9uZSByb3V0aW5nIGhhcyA8
L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmhhcHBlbmVkIChpZiBh
dCBhbGwgaXQgbmVlZHMgdG8ga25vdyk/DQpXaHkgaXQgbmVlZCBub3QgZmluZCBvdXQgPC9mb250
Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5tdWx0aXBsZSBsb2NhdGlvbiBi
YXNlZCByb3V0aW5nIHdhcw0KZG9uZT88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh
Y2U9InNhbnMtc2VyaWYiPjYpIFNlY3Rpb24gMy4yOiBVc2Ugb2YgdGhlIGhlYWRlciBpbg0KQllF
LCBJTkZPIGFuZCBSRUZFUiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy
aWYiPk1ldGhvZHMgYXJlIGFsbG93ZWQsIGFsdGhvdWdoIG5vIHB1cnBvc2UNCmlzIGtub3duLiAm
bmJzcDtDb252ZXlpbmcgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm
Ij5sb2NhdGlvbiBpbiBhIENBTkNFTCwgQllFLCBBQ0sgb3IgUFJBQ0sNCmlzIG5vdCBkZWZpbmVk
LiAmbmJzcDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi
PkNvbnZleWluZyBsb2NhdGlvbiBpbiAmcXVvdDtCWUUmcXVvdDsNCmlzIGRlZmluZWQgb3Igbm90
PzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+NykgJmx0
O3NpcHM6IHVzZXJuYW1lQHNlcnZlci5jb20mZ3Q7DQpvciAmbHQ7c2lwczpzZXJ2ZXIuY29tL3Vz
ZXJuYW1lJmd0OyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmFy
ZSB0aGVzZSBzYW1lPyBJcyB0aGUgc2Vjb25kIGZvcm0gYQ0KdmFsaWQgU0lQIFVSST88L2ZvbnQ+
DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjgpIFdoeSBv
bmx5IFBJREYgZm9ybWF0IGlzIHNlbGVjdGVkLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj
ZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z
LXNlcmlmIj45KSBBc3N1bWUgdGhlIGNhc2UgdGhhdCBVQUMgaGFzIHNlbnQNCmhpcyBpZGVudGl0
eSBpbiB0aGUgZmlyc3QgSU5WSVRFLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh
bnMtc2VyaWYiPkNhbGxlZSB3b3VsZCBoYXZlIHN1YnNjcmliZWQgdG8gdGhhdA0KaWRlbnRpdHkg
YW5kIHdvdWxkIGdldCB0aGUgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl
cmlmIj5jYWxsZXIncyBsb2NhdGlvbi4gTm93IGlmIGNhbGxlcidzIGlkZW50aXR5DQppcyBjaGFu
Z2VkIGFuZCBjYWxsZXIgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm
Ij5zZW50IGEgbmV3IFJFLUlOVklURSBtZXNzYWdlLiBTaG91bGQNCmNhbGxlZSB0aGVuIHN0b3Ag
c3Vic2NyaXB0aW9uIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+
d2l0aCBmaXJzdCBsb2NhdGlvbiBhbmQgc2hvdWxkIHN1YnNjcmliZQ0KdG8gdGhlIG5ldyBsb2Nh
dGlvbj8gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGVyZSBp
cyBubyBiZWhhdmlvdXIgd2l0aCByZXNwZWN0IHRvDQp0aGlzIGlzIG1lbnRpb25lZCBpbiBVQVMg
c2NvcGU/PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl
cmlmIj5yZWdhcmRzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5S
aXNodTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3
aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NDAlPjxmb250IHNpemU9MSBm
YWNlPSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtEcmFnZSwgS2VpdGggXChLZWl0aFwpJnF1b3Q7DQom
bHQ7ZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29tJmd0OzwvYj4gPC9mb250Pg0KPHA+PGZvbnQgc2l6
ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjAzLzA1LzIwMDcgMDE6MDUgQU08L2ZvbnQ+DQo8YnI+DQo8
dGQgd2lkdGg9NTklPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHI+DQo8dGQ+DQo8ZGl2IGFsaWdu
PXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5UbzwvZm9udD48L2Rpdj4NCjx0
ZCB2YWxpZ249dG9wPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mbHQ7c2lwQGlldGYu
b3JnJmd0OzwvZm9udD4NCjx0cj4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0x
IGZhY2U9InNhbnMtc2VyaWYiPmNjPC9mb250PjwvZGl2Pg0KPHRkIHZhbGlnbj10b3A+PGZvbnQg
c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmdlb3ByaXYtY2hhaXJzQHRvb2xzLmlldGYub3JnLA0K
am1wb2xrQGNpc2NvLmNvbSwgZGVhbi53aWxsaXNAc29mdGFybW9yLmNvbTwvZm9udD4NCjx0cj4N
Cjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlN1
YmplY3Q8L2ZvbnQ+PC9kaXY+DQo8dGQgdmFsaWduPXRvcD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu
cy1zZXJpZiI+W1NpcF0gV0dMQyBvbiBkcmFmdC1pZXRmLXNpcC1sb2NhdGlvbi1jb252ZXlhbmNl
PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0
ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0
dD4oQXMgV0cgY2hhaXIpPGJyPg0KPGJyPg0KVGhpcyBpcyB0byBhbm5vdW5jZSBhIHdvcmtpbmcg
Z3JvdXAgbGFzdCBjYWxsIG9mIDxicj4NCjxicj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu
ZXQtZHJhZnRzL2RyYWZ0LWlldGYtc2lwLWxvY2F0aW9uLWNvbnZleWFuY2UtMDcudHh0PGJyPg0K
PGJyPg0KRHVlIHRvIHRoZSBwcmVzZW5jZSBvZiBJRVRGIzY4IGluIFByYWd1ZSwgdGhpcyBpcyBh
biBleHRlbmRlZCBsYXN0IGNhbGwNCihmb3IgZm91ciB3ZWVrcyksIGFuZCBjb21tZW50cyBzaG91
bGQgYmUgcHJvdmlkZWQgYnkgc3RhcnQgb2YgYnVzaW5lc3MNCm9uIE1vbmRheSAybmQgQXByaWwg
MjAwNy48YnI+DQo8YnI+DQpIb3dldmVyIGlmIHlvdSB0aGluayB0aGVyZSBhcmUgc2lnbmlmaWNh
bnQgdGVjaG5pY2FsIGlzc3VlcyB0aGF0IHNob3VsZA0KYmUgcmFpc2VkIGluIElFVEYjNjgsIHBs
ZWFzZSByZXZpZXcgdGhlIGRvY3VtZW50IHdlbGwgYmVmb3JlIHRoYXQgdGltZQ0KdG8gbWFrZSB5
b3VyIGNvbW1lbnQgdG8gdGhlIGxpc3QsIHNvIHRoYXQgc3VjaCBkaXNjdXNzaW9uIGluIHRoZSBJ
RVRGIG1lZXRpbmcNCmNhbiBvY2N1ci48YnI+DQo8YnI+DQpQbGVhc2UgcHJvdmlkZSBhbGwgY29t
bWVudHMgdG8gdGhlIFNJUCBtYWlsaW5nIGxpc3QsIGFuZCBhbHNvIHRvIHRoZSBkb2N1bWVudA0K
YXV0aG9ycyBsaXN0ZWQgKGFuZCBtYWlsaW5nIGFkZHJlc3NlcykgbGlzdGVkIGF0IHRoZSBlbmQg
b2YgdGhlIGRvY3VtZW50Lg0KRm9yIGVhY2ggY29tbWVudCwgaXQgaXMgaWRlYWwgdG8gcHJvdmlk
ZSB0aGUgY29weSB0aGUgc3BlY2lmaWMgcGFydCBvZg0KdGhlIHRleHQgdGhlIGNvbW1lbnQgaXMg
YWdhaW5zdCwgaW4gb3JkZXIgdG8gcHJvdmlkZSBjb250ZXh0IG9mIHRoZSBjb21tZW50LA0KYXMg
d2VsbCBhcyBpZGVudGlmeWluZyB0aGUgc2VjdGlvbi9wYWdlIGFuZCB0aGUgY29tbWVudCBpdHNl
bGYuIDxicj4NCjxicj4NClBsZWFzZSBhbHNvIGNsZWFybHkgaW5kaWNhdGUgd2hldGhlciB0aGUg
Y29tbWVudCBpcyBlZGl0b3JpYWwvdGVjaG5pY2FsLA0KYW5kIGlmIHRlY2huaWNhbCB0aGUgZGVn
cmVlIG9mIHRoZSBjb21tZW50LCBlLmcuIG1pbm9yLCBtYWpvciBmbGF3LCB3cm9uZw0Kc29sdXRp
b24sIG9yIHdoYXRldmVyLiBUaGlzIGhlbHBzIGluIGFzc2Vzc2luZyB0aGUgb3JkZXIgaW4gd2hp
Y2ggY29tbWVudHMNCmdldCBhZGRyZXNzZWQgd2hlbiB0aGV5IGFyZSByZXZpZXdlZC48YnI+DQo8
YnI+DQpJbiBwYXJhbGxlbCB3aXRoIFdHTEMsIGEgcmV2aWV3IHRlYW0gaGFzIGFsc28gYmVlbiBz
ZXQgdXAgdG8gcmV2aWV3IHRoZQ0KZG9jdW1lbnQsIGFuZCB0aGlzIHJldmlldyB0ZWFtIHdpbGwg
cmV2aWV3IGF0IGxlYXN0IHRoZSBzaWduaWZpY2FudCBjb21tZW50cw0KZm9yIGltcGxlbWVudGF0
aW9uLiBJIHdpbGwgYmUgYWRkcmVzc2luZyB0aGVtIGluIGEgc2VwYXJhdGUgbWFpbC48YnI+DQo8
YnI+DQpBcyB0aGUgZG9jdW1lbnQgaXMgYSBsb2NhdGlvbiBzdXBwb3J0aW5nIHByb3RvY29sLCB0
aGUgZG9jdW1lbnQgd2lsbCBhbHNvDQpiZSByZXZpZXdlZCBieSB0aGUgR0VPUFJJViBncm91cC4g
SG93ZXZlciBpdCBpcyBhcHByb3ByaWF0ZSBmb3IgYWxsIHJlYWRlcnMNCnRvIHJldmlldyB0aGUg
ZG9jdW1lbnQgYWdhaW5zdCB0aGUgR0VPUFJJViByZXF1aXJlbWVudHMgZm9yIHN1Y2ggcHJvdG9j
b2xzLA0Kd2hpY2ggbWF5IGJlIGZvdW5kIGluIFJGQyAzOTYzLjxicj4NCjxicj4NClRoZSBhYm92
ZSBkb2N1bWVudCBob3dldmVyIGRvZXMgbm90IGNvdmVyIGxvY2F0aW9uIGJ5IHJlZmVyZW5jZS4g
VGhlcmUNCmlzIGEgcHJlbGltaW5hcnkgc2V0IG9yIHJlcXVpcmVtZW50cyBpbiA8YnI+DQo8YnI+
DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tYXJzaGFsbC1nZW9w
cml2LWxieXItcmVxdWlyZW1lbnRzLTAwLnR4dDxicj4NCjxicj4NCkZvciB3aGljaCB3ZSB3b3Vs
ZCBsaWtlIHRvIGFsaWduIHdpdGggd2hhdGV2ZXIgdGhhdCBkb2N1bWVudCBkZXZlbG9wcyBpbnRv
Lg0KVGhlcmVmb3JlIGl0IGlzIGFwcHJvcHJpYXRlIHRvIHJldmlldyBhZ2FpbnN0IHRoaXMgZG9j
dW1lbnQsIGFuZCBpZGVudGlmeQ0KZGlmZmVyZW5jZXMuIFRoZXNlIGNvdWxkIGVpdGhlciBiZSB0
YWtlbiBhcyBjb21tZW50cyBhZ2FpbnN0IHRoZSBkcmFmdC1pZXRmLXNpcC1sb2NhdGlvbi1jb252
ZXlhbmNlLA0Kb3IgYWdhaW5zdCB0aGUgbG9jYXRpb24gYnkgcmVmZXJlbmNlIHJlcXVpcmVtZW50
cy48YnI+DQo8YnI+DQo8YnI+DQpSZWdhcmRzPGJyPg0KPGJyPg0KS2VpdGg8YnI+DQo8YnI+DQpL
ZWl0aCBEcmFnZTxicj4NCis0NCAxNzkzIDc3NjI0OTxicj4NCmRyYWdlQGFsY2F0ZWwtbHVjZW50
LmNvbTxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fPGJyPg0KU2lwIG1haWxpbmcgbGlzdCAmbmJzcDtodHRwczovL3d3dzEuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9zaXA8YnI+DQpUaGlzIGxpc3QgaXMgZm9yIE5FVyBkZXZlbG9wbWVu
dCBvZiB0aGUgY29yZSBTSVAgUHJvdG9jb2w8YnI+DQpVc2Ugc2lwLWltcGxlbWVudG9yc0Bjcy5j
b2x1bWJpYS5lZHUgZm9yIHF1ZXN0aW9ucyBvbiBjdXJyZW50IHNpcDxicj4NClVzZSBzaXBwaW5n
QGlldGYub3JnIGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBvZiBzaXA8
L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJy
Pg0KKioqKioqKioqKioqKioqKioqKioqKiogJm5ic3A7QXJpY2VudC1VbmNsYXNzaWZpZWQgJm5i
c3A7ICoqKioqKioqKioqKioqKioqKioqKioqPC9mb250Pg0KPHRhYmxlPjx0cj48dGQgYmdjb2xv
cj0jZmZmZmZmPjxmb250IGNvbG9yPSMwMDAwMDA+PHByZT4iRElTQ0xBSU1FUjogVGhpcyBtZXNz
YWdlIGlzIHByb3ByaWV0YXJ5IHRvIEFyaWNlbnQgYW5kIGlzIGludGVuZGVkIHNvbGVseSBmb3Ig
dGhlIHVzZSBvZiAKdGhlIGluZGl2aWR1YWwgdG8gd2hvbSBpdCBpcyBhZGRyZXNzZWQuIEl0IG1h
eSBjb250YWluIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGFuZCBzaG91
bGQgbm90IGJlIApjaXJjdWxhdGVkIG9yIHVzZWQgZm9yIGFueSBwdXJwb3NlIG90aGVyIHRoYW4g
Zm9yIHdoYXQgaXQgaXMgaW50ZW5kZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2Fn
ZSBpbiBlcnJvciwgCnBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3IgaW1tZWRpYXRlbHkuIElm
IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgbm90aWZpZWQgdGhh
dCB5b3UgYXJlIHN0cmljdGx5CnByb2hpYml0ZWQgZnJvbSB1c2luZywgY29weWluZywgYWx0ZXJp
bmcsIG9yIGRpc2Nsb3NpbmcgdGhlIGNvbnRlbnRzIG9mIHRoaXMgbWVzc2FnZS4gQXJpY2VudCBh
Y2NlcHRzIG5vIHJlc3BvbnNpYmlsaXR5IGZvciAKbG9zcyBvciBkYW1hZ2UgYXJpc2luZyBmcm9t
IHRoZSB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVkIGJ5IHRoaXMgZW1haWwgaW5j
bHVkaW5nIGRhbWFnZSBmcm9tIHZpcnVzLiIKPC9wcmU+PC9mb250PjwvdGQ+PC90cj48L3RhYmxl
Pg==
--=_alternative 0017458F652572B1_=--


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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============0992419004==--




From sip-bounces@ietf.org Mon Apr 02 15:27:23 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYSAF-00022R-KV; Mon, 02 Apr 2007 15:26:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYSAE-00022J-Lq
	for sip@ietf.org; Mon, 02 Apr 2007 15:26:02 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYSAC-0004pn-BH
	for sip@ietf.org; Mon, 02 Apr 2007 15:26:02 -0400
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 02 Apr 2007 15:26:01 -0400
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l32JPxsR023230; 
	Mon, 2 Apr 2007 15:25:59 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l32JPfGt018464; 
	Mon, 2 Apr 2007 19:25:46 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 2 Apr 2007 15:25:46 -0400
Received: from [161.44.174.244] ([161.44.174.244]) by
	xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 2 Apr 2007 15:25:45 -0400
Message-ID: <461158B9.5080007@cisco.com>
Date: Mon, 02 Apr 2007 15:25:45 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] Securing Other URI (Tel URI) scheme
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C0CE@zrc2hxm2.corp.nortel.com>	<1175530512.11206.56.camel@scott.skrb.org>	<17937.11565.569792.405389@harjus.tutpro.com>
	<29448B64-2604-470A-8640-B61637D1DAA0@softarmor.com>
In-Reply-To: <29448B64-2604-470A-8640-B61637D1DAA0@softarmor.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 Apr 2007 19:25:45.0927 (UTC)
	FILETIME=[B64CB570:01C7755C]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2400; t=1175541959;
	x=1176405959; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20Securing=20Other=20URI=20(Tel=20URI)=20scheme
	|Sender:=20 |To:=20Dean=20Willis=20<dean.willis@softarmor.com>;
	bh=s7geN/IyGCNAWCNph6cdyGcZJTokolRBJuvqjg5rUeg=;
	b=FgKCzuH5/8g32Dqb6q0Prdbw9Cu0hoPkLK2Mx4TONb8rWePY4KiPnT1kW5eLZnNWbKCoQY56
	VejeEH2k4WupbAVw3qz9bt5JdMAkfNHMRJ+oR3vRI92GcMmcunSbffhz;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: IETF SIP List <sip@ietf.org>, Juha Heinanen <jh@tutpro.com>,
	Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Amen!

	Paul

Dean Willis wrote:
> 
> On Apr 2, 2007, at 11:19 AM, Juha Heinanen wrote:
> 
>>
>> security is meaningless unless it is end-to-end.
>>
> 
> I keep my money in a secure bank, but occasionally I take some of it out 
> as cash, put it in my wallet, and walk to the store with it. The 
> security provided by the bank ends when I withdraw the cash.
> 
> Was that security meaningless?
> 
> 
> Similarly, with sips.
> 
> 
> I might be working from a hotel owned by my competitor in a country 
> owned by my competitor (I think big -- judge a man not by his friends, 
> but by his competitors). From here, I would like to call into a 
> conference bridge back at my office. Some of the other users calling 
> into the conference bridge will be calling over the PSTN in a country 
> not owned by me competitor.
> 
> So I might use a VPN client back to my office, and place the call over 
> that into the conference bridge.
> 
> Does the fact that other people are calling into the bridge using 
> unsecured PSTN lines render the security provided by the VPN meaningless?
> 
> Security always has to be evaluated with respect to a threat. No single 
> security mechanism can address all threats. Using the wrong mechanism 
> for a specific threat can be worse than useless.
> 
> There do appear to be a subset of problems for which sips:, as 
> documented by Francois Audet, seems to be useful. I accept that we have 
> not clearly explained that subset, and that a larger subset exists for 
> for which sips: is arguably not useful. However, there do appear to be 
> people using sips: somewhat appropriately, and I think we owe them a 
> clarification of that specification so that they can have a greater 
> chance of using it successfully.
> 
> I also think we need to develop other mechanisms for other subsets of 
> the problem space, and that we need to be far more clear about the usage 
> of each mechanism and the appropriateness of those mechanisms for 
> different sorts of threats.
> 
> -- 
> Dean
>  
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 15:30:49 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYSEq-00065u-Kp; Mon, 02 Apr 2007 15:30:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYSEp-00065m-69
	for sip@ietf.org; Mon, 02 Apr 2007 15:30:47 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYSEm-0005Ww-PE
	for sip@ietf.org; Mon, 02 Apr 2007 15:30:47 -0400
Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com)
	([172.19.96.182])
	by sj-iport-6.cisco.com with ESMTP; 02 Apr 2007 12:30:44 -0700
Received: from [64.142.29.213] ([10.21.101.61])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l32J8TfC017250;
	Mon, 2 Apr 2007 12:08:29 -0700
Message-ID: <46115A7B.605@cisco.com>
Date: Mon, 02 Apr 2007 12:33:15 -0700
From: Michael Thomas <mat@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
	rv:1.8.0.10) Gecko/20070221 Thunderbird/1.5.0.10 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Francois Audet <audet@nortel.com>
Subject: Re: [Sip] Securing Other URI (Tel URI) scheme
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C0CE@zrc2hxm2.corp.nortel.com>	<1175530512.11206.56.camel@scott.skrb.org>
	<1ECE0EB50388174790F9694F77522CCF0FDBC56A@zrc2hxm0.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FDBC56A@zrc2hxm0.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2074; t=1175540909;
	x=1176404909; c=relaxed/simple; s=oregon;
	h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; 
	d=cisco.com; i=mat@cisco.com;
	z=From:=20Michael=20Thomas=20<mat@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20Securing=20Other=20URI=20(Tel=20URI)=20scheme
	|Sender:=20 |To:=20Francois=20Audet=20<audet@nortel.com>;
	bh=zGvP4OS94jhC85I9EXOnbFJ6gu4NOOnl2RzJcuTBx7s=;
	b=YjE/dGhvMfoRxsI904SoKDd9p6kGuXDX3kc7bdX1uaCE+o+fIRWsA0OLh5BGhHl/DINxljD1
	dMSchpR9LzxfTr1c+1yRfcEandMfw4/DBlMJc0uDBeOO3oYlc1mI+auF;
Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass (
	sig from cisco.com/oregon verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: IETF SIP List <sip@ietf.org>, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I'm sorry, but this is dangerous. If I am using an open access point 
with no WEP
using SIP and no TLS back to a PSTN gateway to call somebody, that the 
adding
TLS provides no utility? This is just plain wrong.

This attitude about the PSTN being "insecure" misses a vital point: 
insecure
compared to _what_? IMO, IP should be viewed as less secure than the PSTN
until proven otherwise. There are far more threats and far fewer 
barriers to
exploit them.

       Mike

Francois Audet wrote:
> Exactly. 
>
>   
>> -----Original Message-----
>> From: Scott Lawrence [mailto:slawrence@pingtel.com] 
>> Sent: Monday, April 02, 2007 09:15
>> To: Srivastava, Samir (SC100:8826)
>> Cc: Audet, Francois (SC100:3055); IETF SIP List; Dean Willis
>> Subject: Re: [Sip] Securing Other URI (Tel URI) scheme
>>
>> On Tue, 2007-03-27 at 14:38 -0500, Samir Srivastava wrote:
>>     
>>> Changed the subject.
>>>
>>> But the UAC wanted its Tel Uri Request to traverse securely on the
>>> intermediate hops. How it can enforce that?    
>>>       
>> The only real utility of the tel uri is for addressing 
>> something through the PSTN.  Once you've crossed that 
>> boundary, the security is meaningless anyway, so there is 
>> little point it protecting it in the sip in the first place.
>>
>> Using a tel uri for end-to-end sip has no advantage over a 
>> sip uri, so if you're going to do that anyway, you have sips 
>> available to protect it.
>>
>> --
>> Scott Lawrence  tel:+1-781-938-5306;ext=162 or 
>> sip:slawrence@pingtel.com
>>   sipXpbx project coordinator - SIPfoundry    
>> http://www.sipfoundry.org/sipX
>>   Chief Technology Officer    - Pingtel Corp. http://www.pingtel.com/
>>
>>
>>
>>     
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>   

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 15:47:16 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYSUI-0006aK-8L; Mon, 02 Apr 2007 15:46:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYSUG-0006a4-C9
	for sip@ietf.org; Mon, 02 Apr 2007 15:46:44 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYSUE-00083j-2b
	for sip@ietf.org; Mon, 02 Apr 2007 15:46:44 -0400
Received: from [171.70.229.153] (dhcp-171-70-229-153.cisco.com
	[171.70.229.153]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l32Ir6sY022719
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Mon, 2 Apr 2007 13:53:08 -0500
In-Reply-To: <46115A7B.605@cisco.com>
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C0CE@zrc2hxm2.corp.nortel.com>	<1175530512.11206.56.camel@scott.skrb.org>
	<1ECE0EB50388174790F9694F77522CCF0FDBC56A@zrc2hxm0.corp.nortel.com>
	<46115A7B.605@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <5B3DFB99-6088-4534-B455-47F597765F61@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] Securing Other URI (Tel URI) scheme
Date: Mon, 2 Apr 2007 14:46:36 -0500
To: Michael Thomas <mat@cisco.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: IETF SIP List <sip@ietf.org>, Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 2, 2007, at 2:33 PM, Michael Thomas wrote:

> I'm sorry, but this is dangerous. If I am using an open access  
> point with no WEP
> using SIP and no TLS back to a PSTN gateway to call somebody, that  
> the adding
> TLS provides no utility? This is just plain wrong.
>

The counter argument is that, by the conventions established in  
Francois' draft, is that IF your SIP ua and proxy chain can do TLS,  
it WILL do TLS whether you use "sips/tels" or not. You don't have to  
ask for it. Or, from another perspective, any time you send a request  
you are asking for that request to be sent via TLS to the extent  
possible.

> This attitude about the PSTN being "insecure" misses a vital point:  
> insecure
> compared to _what_? IMO, IP should be viewed as less secure than  
> the PSTN
> until proven otherwise. There are far more threats and far fewer  
> barriers to
> exploit them.

By the current accord, the only reason to use sips: is to say "If you  
can NOT do this using TLS end to end, then please reject this request."

If you are referring a tel: URL, you are asking somebody to make a  
phone call to a destination specified using PSTN numbering.  
Presumably, this is because you don't know enough about their  
topology to know whether they can make that call using TLS or not.  
They might even make it by sending DTMF over a TDM link -- you have  
no way of knowing.

So, one might argue, it doesn't make a lot of sense to tell them they  
have to make the call using TLS end-to-end.

--
Dean



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 15:53:00 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYSa5-0005dU-Jy; Mon, 02 Apr 2007 15:52:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYSa4-0005WY-1o
	for sip@ietf.org; Mon, 02 Apr 2007 15:52:44 -0400
Received: from alnrmhc12.comcast.net ([206.18.177.52])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYSZh-0000it-1X
	for sip@ietf.org; Mon, 02 Apr 2007 15:52:44 -0400
Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42])
	by comcast.net (alnrmhc12) with ESMTP
	id <20070402195219b12008l4q2e>; Mon, 2 Apr 2007 19:52:19 +0000
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l32JqILv008758
	for <sip@ietf.org>; Mon, 2 Apr 2007 15:52:18 -0400
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l32JqI0w008754;
	Mon, 2 Apr 2007 15:52:18 -0400
Date: Mon, 2 Apr 2007 15:52:18 -0400
Message-Id: <200704021952.l32JqI0w008754@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <460D5064.5010004@cisco.com> (pkyzivat@cisco.com)
Subject: Re: [Sip] One remaining GRUU issue: GRUUs for non-GRUU UA
References: <460A825C.4050902@cisco.com>	<200703282212.l2SMCBEL002086@dragon.ariadne.com>
	<460BC690.1060802@cisco.com> <460D5064.5010004@cisco.com>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

   From: Paul Kyzivat <pkyzivat@cisco.com>

   Jonathan Rosenberg wrote:
   > Thanks for chiming in Dale.
   > 
   > So, so far I have three folks saying its a feature (myself, Dale, Peter) 
   > and Michael saying its a bug but he is willing to drop the issue. I'll 
   > give people another day or so, but unless anyone pipes up I think we can 
   > close this issue.

   Well, it got the way it is because of me, and I stand by it.

After reading and discussing Michael's question, I'm not sure that
we've completely examined it.  We now understand that the introduction
of GRUU does not allow proxies to refrain from record-routing in
circumstances where they would have had to in the past.  With that
understood, are we assured that Michael's problem cannot arise in
situations where it does not arise without GRUU?  Viz., an apparently
usable URI with which a dialog can be started but cannot be continued.

Dale

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 16:25:50 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYT5N-0000Cc-6r; Mon, 02 Apr 2007 16:25:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYT5L-0000CM-Mt
	for sip@ietf.org; Mon, 02 Apr 2007 16:25:03 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYT5H-0007tf-IY
	for sip@ietf.org; Mon, 02 Apr 2007 16:25:03 -0400
Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com)
	([172.19.96.182])
	by sj-iport-6.cisco.com with ESMTP; 02 Apr 2007 13:24:56 -0700
Received: from [64.142.29.213] ([10.21.101.61])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l32K2eGe019523;
	Mon, 2 Apr 2007 13:02:41 -0700
Message-ID: <4611672F.30401@cisco.com>
Date: Mon, 02 Apr 2007 13:27:27 -0700
From: Michael Thomas <mat@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
	rv:1.8.0.10) Gecko/20070221 Thunderbird/1.5.0.10 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] Securing Other URI (Tel URI) scheme
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C0CE@zrc2hxm2.corp.nortel.com>	<1175530512.11206.56.camel@scott.skrb.org>
	<1ECE0EB50388174790F9694F77522CCF0FDBC56A@zrc2hxm0.corp.nortel.com>
	<46115A7B.605@cisco.com>
	<5B3DFB99-6088-4534-B455-47F597765F61@softarmor.com>
In-Reply-To: <5B3DFB99-6088-4534-B455-47F597765F61@softarmor.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1636; t=1175544161;
	x=1176408161; c=relaxed/simple; s=oregon;
	h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; 
	d=cisco.com; i=mat@cisco.com;
	z=From:=20Michael=20Thomas=20<mat@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20Securing=20Other=20URI=20(Tel=20URI)=20scheme
	|Sender:=20 |To:=20Dean=20Willis=20<dean.willis@softarmor.com>;
	bh=Nat4f/ruISYw+k8bn1BTYOXHXXIcrwaFmYwKjNqjJL4=;
	b=S+sgJ5TcQtNUCwzhwq6HuBfJItyHu2c5zh5jTWukU4EZmBpAy45tIxnKn1Tsk1if65I0mX7/
	E3hwSywmtLB+0Nki0FdnDlAjqOIVzCHjxWtu2UHhL758bUiw7RTQrskQ;
Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass (
	sig from cisco.com/oregon verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: IETF SIP List <sip@ietf.org>, Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Dean Willis wrote:
>
> On Apr 2, 2007, at 2:33 PM, Michael Thomas wrote:
>
>> I'm sorry, but this is dangerous. If I am using an open access point 
>> with no WEP
>> using SIP and no TLS back to a PSTN gateway to call somebody, that 
>> the adding
>> TLS provides no utility? This is just plain wrong.
>>
>
> The counter argument is that, by the conventions established in 
> Francois' draft, is that IF your SIP ua and proxy chain can do TLS, it 
> WILL do TLS whether you use "sips/tels" or not. You don't have to ask 
> for it. Or, from another perspective, any time you send a request you 
> are asking for that request to be sent via TLS to the extent possible.

This isn't counter, it's subverted by the original assertion:

 > The only real utility of the tel uri is for addressing something 
through the PSTN.  Once you've > crossed that boundary, the security is 
meaningless anyway, so there is little point it protecting it
                                                                                                  
^^^^^^^^^^^^^^^^^^^^^^^^^^^
 > in the sip in the first place.
   ^^^^^^^^^^^^^^^^^^^^^

It pains me greatly to stick up for the security of the PSTN, but using 
"secure" in
an absolute sense as is being done here is harmful. The attitude we 
should have is
that we want to affect what we can affect and leave the comparisons of 
risk to
somebody who can actually make them. Which is why I think making any 
distinction
at all as to what is on the other side of a SIPS gateway is wrong too, 
and I think is
at the root of this kind of misconception.

       Mike

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 16:30:13 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYT9Z-0001Ye-1c; Mon, 02 Apr 2007 16:29:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYT9X-0001YQ-Gq
	for sip@ietf.org; Mon, 02 Apr 2007 16:29:23 -0400
Received: from pmesmtp01.wcom.com ([199.249.20.1] helo=pmesmtp01.mci.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYT9S-0000M7-5M
	for sip@ietf.org; Mon, 02 Apr 2007 16:29:23 -0400
Received: from dgismtp05.wcomnet.com ([166.38.58.88])
	by firewall.mci.com (Iplanet MTA 5.2)
	with ESMTP id <0JFW00M1X0W5R2@firewall.mci.com> for sip@ietf.org; Mon,
	02 Apr 2007 20:29:15 +0000 (GMT)
Received: from dgismtp05.wcomnet.com ([127.0.0.1])
	by dgismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08
	(built Sep
	22 2005)) with SMTP id <0JFW0022S0WEHO@dgismtp05.mcilink.com> for
	sip@ietf.org; Mon, 02 Apr 2007 20:29:02 +0000 (GMT)
Received: from ASHSRV141.mcilink.com ([153.39.68.167])
	by dgismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08
	(built Sep
	22 2005)) with ESMTP id <0JFW001DM0WDXZ@dgismtp05.mcilink.com> for
	sip@ietf.org; Mon, 02 Apr 2007 20:29:02 +0000 (GMT)
Received: from ASHEVS010.mcilink.com ([153.39.69.135])
	by ASHSRV141.mcilink.com with Microsoft SMTPSVC(6.0.3790.1830); Mon,
	02 Apr 2007 20:29:01 +0000
Date: Mon, 02 Apr 2007 20:25:06 +0000
From: "Dwight, Timothy M (Tim)" <timothy.dwight@verizon.com>
Subject: RE: [Sip] Securing Other URI (Tel URI) scheme
In-reply-to: <5B3DFB99-6088-4534-B455-47F597765F61@softarmor.com>
To: Dean Willis <dean.willis@softarmor.com>, Michael Thomas <mat@cisco.com>
Message-id: <A97210F76CC48A4C846AF61521F9B899013B37B4@ASHEVS010.mcilink.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: quoted-printable
Content-class: urn:content-classes:message
Thread-topic: [Sip] Securing Other URI (Tel URI) scheme
Thread-index: Acd1X8bk812AgR+3SfGHNiQw9WsFsQAAgpng
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-OriginalArrivalTime: 02 Apr 2007 20:29:01.0640 (UTC)
	FILETIME=[8CB88C80:01C77565]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: IETF SIP List <sip@ietf.org>, Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


> By the current accord, the only reason to use sips: is to say=20
> "If you can NOT do this using TLS end to end, then please=20
> reject this request."

So any call originating sips: that terminates to the PSTN, must be
rejected?  Even if it can be secured from originating UA to the PSTN
gateway via TLS?  That seems like a good way to depracate sips: since
nobody will want to use it.

Suppose a network is capable of TLS but doesn't use it unless asked.
Maybe this is an enhanced service they charge for, or maybe they're just
conserving resources.  Anyway suppose you are (like most people, this
list excluded) reasonably comfortable with PSTN security but nervous
about Internet security.  You might like a secured session across the
VoIP portion of your calls to your friends whose access is via the PSTN.
How do you get it?  You start by specifying a sips: URI.  Per my
understanding of this "accord" the network rejects the session request
because it terminated at a PSTN gateway.  Your UA retries without sips:
but due to network policy you don't get TLS (because you didn't ask for
it).

Seems broke to me.

tim

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 17:39:15 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYUDl-0004hh-45; Mon, 02 Apr 2007 17:37:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYUDj-0004ec-LU
	for sip@ietf.org; Mon, 02 Apr 2007 17:37:47 -0400
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYUDi-0004ho-BF
	for sip@ietf.org; Mon, 02 Apr 2007 17:37:47 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	l32Lb2u08058; Mon, 2 Apr 2007 21:37:02 GMT
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: [Sip] Securing Other URI (Tel URI) scheme
Date: Mon, 2 Apr 2007 16:37:13 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF0FDBCA91@zrc2hxm0.corp.nortel.com>
In-Reply-To: <A97210F76CC48A4C846AF61521F9B899013B37B4@ASHEVS010.mcilink.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Securing Other URI (Tel URI) scheme
thread-index: Acd1X8bk812AgR+3SfGHNiQw9WsFsQAAgpngAAMvyCA=
References: <5B3DFB99-6088-4534-B455-47F597765F61@softarmor.com>
	<A97210F76CC48A4C846AF61521F9B899013B37B4@ASHEVS010.mcilink.com>
From: "Francois Audet" <audet@nortel.com>
To: "Dwight, Timothy M \(Tim\)" <timothy.dwight@verizon.com>,
	"Dean Willis" <dean.willis@softarmor.com>, "Michael Thomas" <mat@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

=20

> So any call originating sips: that terminates to the PSTN,=20
> must be rejected?  Even if it can be secured from originating=20
> UA to the PSTN gateway via TLS?  That seems like a good way=20
> to depracate sips: since nobody will want to use it.

No, we did not agree to do this.=20

When you are outside the SIP network, it's out of scope  of SIPS. You
can
do whatever you want.

> Suppose a network is capable of TLS but doesn't use it unless asked.
> Maybe this is an enhanced service they charge for, or maybe=20
> they're just conserving resources.  Anyway suppose you are=20
> (like most people, this list excluded) reasonably comfortable=20
> with PSTN security but nervous about Internet security.  You=20
> might like a secured session across the VoIP portion of your=20
> calls to your friends whose access is via the PSTN.
> How do you get it?  You start by specifying a sips: URI.  Per=20
> my understanding of this "accord" the network rejects the=20
> session request because it terminated at a PSTN gateway. =20
> Your UA retries without sips:
> but due to network policy you don't get TLS (because you=20
> didn't ask for it).

As the operator of the PSTN gateway, you can decide to use=20
SIPS all the way to the PSTN gateways if that satisfies your
security needs.

SIPS just means that IN THE SIP DOMAIN, you forward everything
on TLS (hop-by-hop).

> Seems broke to me.
>=20
> tim
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 18:06:51 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYUfN-0001fH-PE; Mon, 02 Apr 2007 18:06:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYUfL-0001fC-UW
	for sip@ietf.org; Mon, 02 Apr 2007 18:06:19 -0400
Received: from pmesmtp03.mci.com ([199.249.20.32])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYUfI-0005o0-EX
	for sip@ietf.org; Mon, 02 Apr 2007 18:06:19 -0400
Received: from pmismtp06.wcomnet.com ([166.37.158.166])
	by firewall.mci.com (Iplanet MTA 5.2)
	with ESMTP id <0JFW00GDZ5EAKQ@firewall.mci.com> for sip@ietf.org; Mon,
	02 Apr 2007 22:06:10 +0000 (GMT)
Received: from pmismtp06.wcomnet.com ([127.0.0.1])
	by pmismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08
	(built Sep
	22 2005)) with SMTP id <0JFW00C8U5EA3Y@pmismtp06.mcilink.com> for
	sip@ietf.org; Mon, 02 Apr 2007 22:06:10 +0000 (GMT)
Received: from ASHSRV140.mcilink.com ([153.39.68.166])
	by pmismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08
	(built Sep
	22 2005)) with ESMTP id <0JFW00BEJ5EARM@pmismtp06.mcilink.com> for
	sip@ietf.org; Mon, 02 Apr 2007 22:06:10 +0000 (GMT)
Received: from ASHEVS010.mcilink.com ([153.39.69.135])
	by ASHSRV140.mcilink.com with Microsoft SMTPSVC(6.0.3790.1830); Mon,
	02 Apr 2007 22:06:10 +0000
Date: Mon, 02 Apr 2007 22:05:57 +0000
From: "Dwight, Timothy M (Tim)" <timothy.dwight@verizon.com>
Subject: RE: [Sip] Securing Other URI (Tel URI) scheme
In-reply-to: <1ECE0EB50388174790F9694F77522CCF0FDBCA91@zrc2hxm0.corp.nortel.com>
To: Francois Audet <audet@nortel.com>, Dean Willis <dean.willis@softarmor.com>,
	Michael Thomas <mat@cisco.com>
Message-id: <A97210F76CC48A4C846AF61521F9B899013B37B6@ASHEVS010.mcilink.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: quoted-printable
Content-class: urn:content-classes:message
Thread-topic: [Sip] Securing Other URI (Tel URI) scheme
Thread-index: Acd1X8bk812AgR+3SfGHNiQw9WsFsQAAgpngAAMvyCAAAPG+EA==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-OriginalArrivalTime: 02 Apr 2007 22:06:10.0317 (UTC)
	FILETIME=[1EE213D0:01C77573]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

> > So any call originating sips: that terminates to the PSTN, must be=20
> > rejected?  Even if it can be secured from originating UA to the PSTN

> > gateway via TLS?  That seems like a good way to depracate sips:
since=20
> > nobody will want to use it.
>=20
> No, we did not agree to do this.=20

But that's what Dean said.


> When you are outside the SIP network, it's out of scope  of=20
> SIPS. You can do whatever you want.
>=20
> > Suppose a network is capable of TLS but doesn't use it unless asked.
> > Maybe this is an enhanced service they charge for, or maybe they're=20
> > just conserving resources.  Anyway suppose you are (like most
people,=20
> > this list excluded) reasonably comfortable with PSTN security but=20
> > nervous about Internet security.  You might like a secured session=20
> > across the VoIP portion of your calls to your friends whose access
is=20
> > via the PSTN.
> > How do you get it?  You start by specifying a sips: URI.  Per my=20
> > understanding of this "accord" the network rejects the session
request=20
> > because it terminated at a PSTN gateway. Your UA retries without
sips:
> > but due to network policy you don't get TLS (because you didn't ask=20
> > for it).
>=20
> As the operator of the PSTN gateway, you can decide to use=20
> SIPS all the way to the PSTN gateways if that satisfies your=20
> security needs.
>=20
> SIPS just means that IN THE SIP DOMAIN, you forward=20
> everything on TLS (hop-by-hop).

Of course.  In my example I am provider of both "the SIP domain" and the
PSTN gateways.  I am surprised to hear that I must reject sips: calls
that terminate on my PSTN gateway, because of some "accord" that I am
told exists.

Tim

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 02 18:25:46 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYUxc-0005wl-E1; Mon, 02 Apr 2007 18:25:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYUxb-0005wg-I5
	for sip@ietf.org; Mon, 02 Apr 2007 18:25:11 -0400
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYUxa-0003mR-5b
	for sip@ietf.org; Mon, 02 Apr 2007 18:25:11 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	l32MOhu14668; Mon, 2 Apr 2007 22:24:43 GMT
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: [Sip] Securing Other URI (Tel URI) scheme
Date: Mon, 2 Apr 2007 17:25:09 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E6120F3E51@zrc2hxm2.corp.nortel.com>
In-Reply-To: <29448B64-2604-470A-8640-B61637D1DAA0@softarmor.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Securing Other URI (Tel URI) scheme
thread-index: Acd1Vb3gv8qaAqaHRmyDVl9MR4XCEQAGYSIg
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Dean Willis" <dean.willis@softarmor.com>, "Juha Heinanen" <jh@tutpro.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: IETF SIP List <sip@ietf.org>, Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

In-line.

Thx
Samir

>-----Original Message-----
>From: Dean Willis [mailto:dean.willis@softarmor.com]=20
>Sent: Monday, April 02, 2007 11:35 AM
>To: Juha Heinanen
>Cc: IETF SIP List; Audet, Francois (SC100:3055)
>Subject: Re: [Sip] Securing Other URI (Tel URI) scheme
>
>
>There do appear to be a subset of problems for which sips:, as=20
>documented by Francois Audet, seems to be useful. I accept=20
>that we have not clearly explained that subset, and that a=20
>larger subset exists for for which sips: is arguably not=20
>useful. However, there do appear to be people using sips:=20
>somewhat appropriately, and I think we owe them a=20
>clarification of that specification so that they can have a=20
>greater chance of using it successfully.


With all respect I have to state that "I don't think there is even a
chance of using it successfully without users being informed of what
level of security is provided. Feature sets are broken too, even if I
accept that proxies are trusted to use the correct set of ciphers (AES
128) in this case. The more we try to patch it, the more problems we are
inviting.=20

You seem to be agreeing that SIPS is largely not useful. Can you
quantify this, which can lead us to DEPRECATE SIPS.=20

I want to avoid the islands of current SIPS as defined currently in the
coming future, as we will be having a large battle then to fix when
request goes through currently defined SIPS islands (Similar to PSTN
clouds) Where we don't know what is happening ? We will have another
beast to interoperate.=20

>
>I also think we need to develop other mechanisms for other=20
>subsets of the problem space, and that we need to be far more=20
>clear about the usage of each mechanism and the=20
>appropriateness of those mechanisms for different sorts of threats.

Thx for agreeing on this.

>
>--
>Dean
> =20
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol Use=20
>sip-implementors@cs.columbia.edu for questions on current sip=20
>Use sipping@ietf.org for new developments on the application of sip
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 03 00:47:57 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYatf-0003pr-AK; Tue, 03 Apr 2007 00:45:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYate-0003pk-2P
	for sip@ietf.org; Tue, 03 Apr 2007 00:45:30 -0400
Received: from harjus.tutpro.com ([192.98.100.3])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYatc-0007Tg-OD
	for sip@ietf.org; Tue, 03 Apr 2007 00:45:30 -0400
Received: by harjus.tutpro.com (Postfix, from userid 1000)
	id 926A2AC2CB; Tue,  3 Apr 2007 07:45:23 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17937.56291.496540.712374@harjus.tutpro.com>
Date: Tue, 3 Apr 2007 07:45:23 +0300
To: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] Securing Other URI (Tel URI) scheme
In-Reply-To: <5B3DFB99-6088-4534-B455-47F597765F61@softarmor.com>
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C0CE@zrc2hxm2.corp.nortel.com>
	<1175530512.11206.56.camel@scott.skrb.org>
	<1ECE0EB50388174790F9694F77522CCF0FDBC56A@zrc2hxm0.corp.nortel.com>
	<46115A7B.605@cisco.com>
	<5B3DFB99-6088-4534-B455-47F597765F61@softarmor.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: IETF SIP List <sip@ietf.org>, Francois Audet <audet@nortel.com>,
	Michael Thomas <mat@cisco.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Dean Willis writes:

 > If you are referring a tel: URL, you are asking somebody to make a  
 > phone call to a destination specified using PSTN numbering.  
 > Presumably, this is because you don't know enough about their  
 > topology to know whether they can make that call using TLS or not.

the reason is that i don't know their pstn gateway provider.  if they
can use tls or not i don't know either, but the same holds true even if
i would refer them to a sips uri.

 > So, one might argue, it doesn't make a lot of sense to tell them they  
 > have to make the call using TLS end-to-end.

that is referer's judgement.  if referer does not want that the call is
made using tls or not made at all, then referer needs to use sips or tels and
we need to support both of them or neither.

-- juha

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 03 00:59:59 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYb75-0005ql-HL; Tue, 03 Apr 2007 00:59:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYb73-0005pV-B9
	for sip@ietf.org; Tue, 03 Apr 2007 00:59:21 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYb70-0001sT-0W
	for sip@ietf.org; Tue, 03 Apr 2007 00:59:21 -0400
Received: from [206.176.144.210] (206-176-144-210.waymark.net
	[206.176.144.210]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3345h9U024388
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 2 Apr 2007 23:05:44 -0500
Message-ID: <4611DF9D.1070206@softarmor.com>
Date: Tue, 03 Apr 2007 00:01:17 -0500
From: Dean Willis <dean.willis@softarmor.com>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: Michael Thomas <mat@cisco.com>
Subject: Re: [Sip] Securing Other URI (Tel URI) scheme
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C0CE@zrc2hxm2.corp.nortel.com>	<1175530512.11206.56.camel@scott.skrb.org>
	<1ECE0EB50388174790F9694F77522CCF0FDBC56A@zrc2hxm0.corp.nortel.com>
	<46115A7B.605@cisco.com>
	<5B3DFB99-6088-4534-B455-47F597765F61@softarmor.com>
	<4611672F.30401@cisco.com>
In-Reply-To: <4611672F.30401@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: IETF SIP List <sip@ietf.org>, Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Michael Thomas wrote:
> 
> It pains me greatly to stick up for the security of the PSTN, but using 
> "secure" in
> an absolute sense as is being done here is harmful. The attitude we 
> should have is
> that we want to affect what we can affect and leave the comparisons of 
> risk to
> somebody who can actually make them. Which is why I think making any 
> distinction
> at all as to what is on the other side of a SIPS gateway is wrong too, 
> and I think is
> at the root of this kind of misconception.
> 

You're probably right there.

But does this mean that we need a tels: URI scheme, or are you just 
saying my argument smells funny?

--
dean


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From agglutinatingbsuv@seed.net.tw Tue Apr 03 02:06:28 2007
Return-path: <agglutinatingbsuv@seed.net.tw>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYc9z-0003fR-Ti; Tue, 03 Apr 2007 02:06:27 -0400
Received: from 59-105-32-145.adsl.dynamic.seed.net.tw ([59.105.32.145] helo=seed.net.tw)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1HYc9r-0004y3-GW; Tue, 03 Apr 2007 02:06:27 -0400
Message-ID: <31f501c77592$55dbed60$10be0757@agglutinatingbsuv>
From: "Shari Garrett" <agglutinatingbsuv@seed.net.tw>
To: "lyle stephens" <grow-archive@lists.ietf.org>
Cc: "lashaun phillips" <idwg-archive@lists.ietf.org>,
	"lorilee kim" <aaa-archive@lists.ietf.org>,
	"karly ortiz" <bridge-archive@lists.ietf.org>,
	"douglass wallace" <mailman-bounces@lists.ietf.org>,
	"laureen garrett" <sip-archive@lists.ietf.org>,
	"dana peterson" <dnsext-archive@lists.ietf.org>
Subject: Right or wrong, u decide
Date: Tue, 03 Apr 2007 01:49:36 -0400
MIME-Version: 1.0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_CF8_D2BE_4CA566D9.AE8BD705"
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Spam-Score: 2.5 (++)
X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78

This is a multi-part message in MIME format.

------=_NextPart_CF8_D2BE_4CA566D9.AE8BD705
Content-Type: multipart/alternative;
	boundary="----=_NextPart_748_9DE2_580C634E.8FCF95FB"

------=_NextPart_748_9DE2_580C634E.8FCF95FB
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable





sense Now see here, learning will listen that be all? Eh? brake And will =
youI was suspend saying swim to him floor only yesterday, bitten 'You are=
 impr I will say new chosen he had doubtless stain plant given you the pl=
an ofchose paid The doctor then breezy slowly poured some smell drops of =
the le
Yes.protest flash Thank desire you, said Albert, competition with a cold =
and formal b 
discovery messup grass What striven did he answer? slit torn Never. jewel=
 Caderousse carriage had become so gloomy that Andr clear sold episcopal =
He quietly said, 'What do I boast care if I am?' The thaw nod unfortunate=
 witty Barrois has poised been poisoned, said
consider hammer healthy Then, said Haide, proving by sadly her remark tha=
t shwooden reading I rudely will find him, as I told you. I will leg tell=
 him t baby Will you now have invention the wire kindness to x-ray explai=
n the nat development iron No? said Morrel; you real crush disapprove of =
this second
powerful M. told D'AVRIGNY soon restored triangular tremble the magistrat=
e to consc attempt No, building unfortunately; from but sticky when I do =
obtain it-- did Andrea, he monkey raptorial sparkling has some secretary =
with a spring. Well? loss overtake I, knee indeed? up I assure you, cried=
 Danglars, with a
slip feline I do, dream see signified the old man.cholic Monte mate Crist=
o reflected work one instant. rightfully You will spea Ali hilarious left=
 the room. The glow cups of brief. think coffee were all pre An announcem=
ent taught ate has been dream made wound which implicates th  won taught =
What is it? comfort said Beauchamp, rate much surprised; sur
And wail he brainy spot will be guillotined, will be eager not? said Cafo=
ught Who, shut guide competition then, urged you to write? Tell me.Say, m=
eant crawl rather, discovery crime! kill replied the doctor. jump throat =
force young How do you know?
jam M. shock strod d'Avrigny, cried Villefort, I fork cannot tell yo rate=
 knot I breakable will say, continued the open count, that he follow I sk=
in shall remember old friends, mist relax name I can tell you that bred D=
id out slimy you self see all that? Pardieu! it was except the most chop =
wed simple thing gluteal in the worl I speak concerned sufficient color I=
talian average to enable prevent me to conver
But hook what bridge then pocket must type be done? asked Morrel. Madamwa=
ste On what subject dealt plant shall camera I converse with her? saidhea=
lthy The bite story measure sent slimy you from Yanina. Yes. Just what di=
sagree pick paint you please; you support may speak of her countr
Yes, which catches the thief burn grip in a bid land trap and plays moder=
n muscle Yes, respect said surprise M. d'Avrigny, with an imposing calmne=
s  Come, magistrate, note encouraging said really M. act d'Avrigny, show =
yours
grieving Yes, burn shakily since you have sank such a good memory. spoon =
And slope who fair name thus advised you? Remember cheat my flower words:=
 window 'If you return voice home safely, I front He cow cloth has simply=
 a mahogany separate secretary, in which the teaching No frantically swun=
g other than your bang friend, Monte Cristo. overflow Oh, said pinch lost=
 Albert, it excited is of no use to be in the c
------=_NextPart_748_9DE2_580C634E.8FCF95FB
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"=
>
<META content=3D"MSHTML 5.00.2919.6700" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><FONT face=3DArial size=3D1>
<DIV>
<p><IMG alt=3D"" hspace=3D0 src=3D"cid:68b6d01c77592455ad63506fcebbbf@agg=
lutinatingbsuv" align=3Dbaseline border=3D0></p>
<BR>
<DIV><FONT FACE=3D"Arial" size=3D1>sense Now see here, learning will list=
en that be all? Eh? brake And will youI was suspend saying swim to him fl=
oor only yesterday, bitten 'You are impr I will say new chosen he had dou=
btless stain plant given you the plan ofchose paid The doctor then breezy=
 slowly poured some smell drops of the le</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>Yes.protest flash Thank desire you, sa=
id Albert, competition with a cold and formal b </FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>discovery messup grass What striven di=
d he answer? slit torn Never. jewel Caderousse carriage had become so glo=
omy that Andr clear sold episcopal He quietly said, 'What do I boast care=
 if I am?' The thaw nod unfortunate witty Barrois has poised been poisone=
d, said</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>consider hammer healthy Then, said Hai=
de, proving by sadly her remark that shwooden reading I rudely will find =
him, as I told you. I will leg tell him t baby Will you now have inventio=
n the wire kindness to x-ray explain the nat development iron No? said Mo=
rrel; you real crush disapprove of this second</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>powerful M. told D'AVRIGNY soon restor=
ed triangular tremble the magistrate to consc attempt No, building unfort=
unately; from but sticky when I do obtain it-- did Andrea, he monkey rapt=
orial sparkling has some secretary with a spring. Well? loss overtake I, =
knee indeed? up I assure you, cried Danglars, with a</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>slip feline I do, dream see signified =
the old man.cholic Monte mate Cristo reflected work one instant. rightful=
ly You will spea Ali hilarious left the room. The glow cups of brief. thi=
nk coffee were all pre An announcement taught ate has been dream made wou=
nd which implicates th  won taught What is it? comfort said Beauchamp, ra=
te much surprised; sur</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>And wail he brainy spot will be guillo=
tined, will be eager not? said Cafought Who, shut guide competition then,=
 urged you to write? Tell me.Say, meant crawl rather, discovery crime! ki=
ll replied the doctor. jump throat force young How do you know?</FONT></D=
IV>
<DIV><FONT FACE=3D"Arial" size=3D1>jam M. shock strod d'Avrigny, cried Vi=
llefort, I fork cannot tell yo rate knot I breakable will say, continued =
the open count, that he follow I skin shall remember old friends, mist re=
lax name I can tell you that bred Did out slimy you self see all that? Pa=
rdieu! it was except the most chop wed simple thing gluteal in the worl I=
 speak concerned sufficient color Italian average to enable prevent me to=
 conver</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>But hook what bridge then pocket must =
type be done? asked Morrel. Madamwaste On what subject dealt plant shall =
camera I converse with her? saidhealthy The bite story measure sent slimy=
 you from Yanina. Yes. Just what disagree pick paint you please; you supp=
ort may speak of her countr</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>Yes, which catches the thief burn grip=
 in a bid land trap and plays modern muscle Yes, respect said surprise M.=
 d'Avrigny, with an imposing calmnes  Come, magistrate, note encouraging =
said really M. act d'Avrigny, show yours</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>grieving Yes, burn shakily since you h=
ave sank such a good memory. spoon And slope who fair name thus advised y=
ou? Remember cheat my flower words: window 'If you return voice home safe=
ly, I front He cow cloth has simply a mahogany separate secretary, in whi=
ch the teaching No frantically swung other than your bang friend, Monte C=
risto. overflow Oh, said pinch lost Albert, it excited is of no use to be=
 in the c</FONT></DIV>
</DIV></FONT></BODY></HTML>

------=_NextPart_748_9DE2_580C634E.8FCF95FB--

------=_NextPart_CF8_D2BE_4CA566D9.AE8BD705
Content-Type: image/gif;
	name="wtgiyvati.gif"
Content-Transfer-Encoding: base64
Content-ID: <68b6d01c77592455ad63506fcebbbf@agglutinatingbsuv>

R0lGODdhdQE8AYQAAP////Hx5+Xi1+2oqOWMjPLIgd5nZ8I7B8gQEMwzAAAA/wAAAP8AAMfU3ry8
vDMzM06ZzLuqmi1wr5GfyYKWr2ZmZuyuUbJ5R8uSW6FzPldNV+SQLN9vHYlXIwAAAAAAACwAAAAA
dQE8AQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt
er/g8DMQEJvP6PROMCAUDAdBqayu2+/hwECAKCAQBgMHAyMFB25yeGkKio1VAQUJhAEHgJACBAAC
CX0ECQVUCqKjjCajjaSnpqKOLaQ0qiOxW4JtmQAGCAcGBiMEfwWbhJpRqbMix1ulKsasJcmtJM3L
L8fQVAIGbn8Ew7kJvIV/CHsiBHFQqq9o19LOANbvPNSh7+0p91gClX255ObA2AQQUOAXggRyshHQ
9iRWPGqpVkGL6G6Zw2bIjK24SA9jxXUZGcnDmMzjR4j2/uQ9Uzlr2kqUzly+VAkkgMFDnD4BGPCn
DcJzAAyCAojg1pKWI5NSDAkSnkmnFlN61IiPVSmkJqdFxaoVJlWmHJlW7aj060NZMqEuHWIQ3J9e
PAeF88RGFx2euhbSSYK1ItqtIf8KDkwY6t+rUlmE/VhY4uGZag2PHSzZaeOXjh9XPit2c2IgBBMZ
1KZLUzAyIvQMgDPUz8E3vY4q9duZ9om+hHF7pnc7beGHIEvGHM57Kk13l21T3r2ceW6tQPCCkyN0
wLAUiXZy6rNzL1+pME8CRoF78W/irr7a5miWpjr0hyneG86Mpf3xlc+P7/qDjT9d1KHzwibcpDDQ
atf9/mBecpHl9154zunHYGaTPQdfcg/qhxh+u813H2YSrvdZPjvwAgk/sc0wADgnDLRPUZwY1QN7
Iu4HXmeLBfdZfuQdp1mEC1rY2Cki7agjiUGaxxmQO/ZQCTq/JOBdDASRAElBRVUSCDAK+uager6l
BV2IavGmnET4jcmjZBnG15SXTfWoHplLLvhUD9IRAseUNAQTZUHWAaNll3PyuBZYvQlnFYRf+jhh
bVxFOFibjwFnJonxJUpZnU2WydY4h2TXp3Xg4LWHAJQU9csB0bRqBaautiBIApLUAMmKgBSUDSAM
/bLlAXzGKqwRhw5Lg4sz6MHLIbnEAQpP4PTimiAp/hprLRFxXhvDGzK2oMdC3xDQzVvABsDJHm5o
acBQ2rbrbhQDsIsLAqJiZ90+vHjyz4vggJKLAZuIG8i7BBfMxJO8WDdAsHPw40Y3u8b2DUFtHLTQ
wgZnrDERBI7TE3YmascNAXLgJYdrC0miTb0bt+xyDpgsdMB23ZKAsgh4FZVaJZmkmi/DLwct9LH+
DSWAf0ZNvNM5HwfF5UIsDy311DYYkoC+mWDCCVwLNwvQAeweTfXYZLuACSEo+6qJuB+TnCooBWAs
wibOulH23WXH7TRCTm+ZNdsAhoNJ1KthMk6CaSyguOJJLCCC4ydAboTkRFBOtkBwAOCatNzQCoq4
/gaBvsIeOR8goBqUW26D6iawToLrr8MOg+w+0L7xQDbRCknW/oCi5apvdL1uCwZspzPJdlhuuwu2
09788lVAT/DuVwu1ExtM97IqXvkCALQJkbwV8x3Kj7B46wAwbr7655fQvurvmx/5+ZI7bn/q6ruf
fvqs1/94/v7bX+r4Jz/Ixe9x8uMf/vxnPy/wYh9x4NlO4lUxcqQtEN87QUIglgvEoaF8Atxf7BAo
QhHCr4AkZCAJ57fC+6Uwga8jYAlh2MAXplB5BvxfC0uoQhuaUHpR8AOrIDEvVp1NXJVQ2cBmEIlq
WSeDXwBhAGm4wxmu0Iblkx0ATZjAKaLwil8M/qAY0efDMTYwh/rzoRempbm4PQ1qPFkXFFWwGuS1
QoowrOIY09hFMLYPBVtE4w//+EUrIlCQiAQjD6vIxTOur36LE6QXCMQ2YGnJJudYmLxoALV9LGyO
YMCjH/uoxlFyMYaGXF8YSQnIRaIvka48YRn76Mg0yhIMT1oRQvACsQLQIRubfAFemNWN4eFhgIzU
IyupiMYewi5/PGxmHg85TSrO0pB7dKU2sylJL+DlDf9oQzCVJgNwcmMgOjtmJN0HTUb+sZ0KLCP7
lhnPHUKTkIV0XQ4JuU5svjN2yJwhP7eoyCz4Si8pGGY3XhCAkOEKEE/EWw+cV00dAFGiJRAn/gpO
xok45CKYJ7BOLm6xK0BgdKIr8CIPLnpSsyWxgnEL1V6OdrJwyqiDLS3CPWvH0pyuoGMVZFXoBrGT
mWnPpCZgg0+XGrSGmpRbcmiWa4IRI6dxx3ugZKpW27VQK2npmwAY1ObM4cGtmvVlm5NgEcvgDz2V
9axwzZhBcDWUKCUkid3IaqwYwIAT9HUEf31BYAMbBL4alq+AHSxhbbDYuDbsNVXdCZe8p9GWIbYE
lwVAZl0wWCIc9rAiyOxmazBax1qJEoHYGs4KJDXEGlazn40tbEkgWsDONrSJ7WxoQYvb3SaWtoq9
bW6BG9zXfna4vh3ta5P7V9c2dnqoEsQt/mwBUsvG9rrYDW5vNXvb5Xr3sseFbXO161vk5ha8vM3u
d9e72fAeV7amvdZ3hYvevi4Xs7adrX31a1/njle8whUvb83b3f7+dr6iLa5y/QtgAN83vsNKMH3/
W17a5le/3HVuhhvs2gwTFr7EBS5mZSvhBL+3sSUmb2kh3KoU/3bCJtAthg3c4f7+d7/tHe9iH7zg
Ex9YsT4e8Y9fHGAWu8rF5TVuaWXsYBM3eLgPhvGQk2xgITOXyFjerY0nvGUjCyvF/r3ugS+s5Scr
eccM5i9yJazl+ir5x27WMJXne94Ve7kRbGZvlZNLZin7ucLoDfCbK/xkAQNax+c9tHkX/lzkOxvM
zltls6M1BmmtinnSlH7uWcOL6U57+tOgDrWoR03qUpv61KhOtapXzepWu/rVsI61rGdN61rbWmpk
QM2td12EXOcaVbwO9g90/esGRG1sLtKrsLeAGl+TQQDGVnbBAtCAaltb2st+RGoG4gBU0bTa2NYW
taOd62uf1Nk5dbYAHNBtmh6N3eE2VgMcYO16V5vdx0bBA0qwbxH0O1a63na8/+3vERCcBw9IeL8V
znAjlOHZ+Hb30ead1YP/++B1EAAENs7xjnt84w4A5cVJcPGEk3zfCwfAwk2eBWe73NczGLnBDc5y
f6O84CvHuMpJznMk+BpVLp94BPLN/u+d2zzlMle5yW9ecysEoOMSiLrUISD1qHO8AS5IutFlvnKb
F/zrTg96stEdA62n/OtdVzrYMa5zsDv85S769tCzbvS11/3sW8f7IzZe9apTve8bn8AczW4CvOt9
5mH/tcSP5usGKJvwRb+72xHPb4VH/gjPXrzEGzB3FiSd63XvudarMIGpm/7vU6d6BEQe+rtbXvKh
b7jTgR53zXNb2jfvudJZDnqaN/0EBG97EDLP7uJHHNqdXwHDP4/zk/Oe8lYQAAX8znerQ50CIae7
xe0Oe+Y7vdqad/dAIuCAmLfe8Nz3vu5jnwTi15vxA+E80Snv/dx3H/rRj0AF+s5//glUYALZ9wJs
h3Zn93wEeAUhd3ya5wAAGG4DmHcH2H0P6HbCVxPx127i120OsHqeF3nqB4Gw13IOMH39F3UUEAGO
V3aFR3Out3Un13pUQG30tnich4I2MIFLx4J6l4OF93r4xzHzpoA0xW422IGih34viIQtN28UsH99
VwEnmIJGUIFcsG70Zm0bGIBKQIVaIIPFZ29BCG9CM27WFgFNWAFoeIJXaGxCIHtpIIMRMAETkHxH
4IZm8GzzBobGNnHx5irQBoYbGAHkB4Z9OCzqJnEBJ1GZJ37lVojRUHvht3iO6CovNwK/NoniFnAv
B2xjCHeeiImtAHMqkIh3Q4pY/oU7uJZrKEB22SYGn2iKrRiLLgCLsjgsCVCLy0Yrt6gCu7gCukgC
v2gCwSgCwwgEu3iMXdCLeKOMBNOLzFgCzyiMAHCLx0iNzEgr01iN2VgEyPgDxXgC0SiM2DgC30iM
42iO5+iNxLiOMlCO0NgCxeiO8ZiO6jiN7LgD14iOzniP+RiN9IiN4wiQz2iN5HiO1PiOBsmO4XgD
+5gCC0mO9qiN/0iQ5ngE3QgDDYkCD7mOB7mNE7mNHrmROnCRI/mO9qiQ/AiN5UiP2eiMFAmMyNiQ
LBmQKHmSPJCPLSmTEAmMNgmTGqmNGgmSLQmR/aiTPQmPJqmLRnmUHamSThmQ/i9JlC65j0W5kySZ
Azi5lE0Jk+k4ky+plNLIkWB5lCl5kleJlUlplWVZkB/5k/oIjjFplQPZjXQZA1mpljZ5jSuplyAp
kOLIkXL5l2ZZk/iYloS5lTzpknAplBVpkhEZlo5Zl2SJA3d5mJM5lgW5mAo5kFIZjP6Il2fpi4Y5
mIApjl05l30ZlSmplKFplKHJkDuZl/d4mY/JmCGZmrbZl7J5mZL5mjZQmaRZm9LIl04pmDxZmscZ
mTUpko5pmbIZjk3JkmJZkTNJlJCZnL3pjV2Jl7PJlWwJlejoncM5lbGZmK5Zj7sZnLTZkX55mz7p
lcjZmtk5maK5liT5mezJ/pft2Z4+KZzyuZzd2QQLyZwzQKDXmQTxyJ30OY+KyZpsCY5COYz4eZ7t
uJ2EuaAGOZZQqYzyGKEJOZ6gGQUGepM0MKJQMKDGWKJTgKLoaZe4iJFLYKLl6QQyipYF+qI4mqM6
uqM82qM++qNAGqRCOqREWqRGeqRImqSfBomcqKRjsIiqWDYEYQGCKIgWcBpOygSZVwBcyqWMdzkW
QKVVOqa+lKXtdzRdmqZdOn8GAwljWqVhGqYRUKZT84ouJ1FoqqZqagFsSjACEAEXgAEY8KaCWqXV
pTG4s4nGt6h9iqgEoad7qoUrUAEyQKkAYKlgAAkYkAEUMIdVyqmeKoiN/ipuTToHkViEL4CGqjoC
mBoDrToDrxoEj5qmV6qnfOoCsZqqYvCngtptnLepFGBsBRABg1p+LbB9wDd5YRAMvqSoi8pu8zYB
o3qpJGCpudoC1/oIBRCn3FqrtGqsLJCrq0qtIkCp5oqG5Uqu41oFAiCog1oGBZABGRByvFqodLd+
+HoGkKqmUEgBZ6gBAAuwEQADrWqtl1qw6JquCTuu62qu1LqwBnuu1ZqwNzCl3XqxYboBHBiuJoCp
Dquw6VquBhuyVFAA7ooBIRcA8BYAFnCyA3uvrveAoMd7XJgE+9qlFqBwGrB8CUcBWVWwIhuyHhu0
6kqy1nq0ROuwC2u0/jggABj7tBo7R7E6tA8rtKx6AtnaBO16AVyLAViXayYbqFw7AQKIeL2HhDSr
rE1wJTeLAQ8QsHAbsD6bqqpKtUVLsld7t3prt0qbt3ZbA077tBfLARs7qR1btyC7txNLsVPQrhnA
tRcwdGRgsvJ6AfIKrkYIgwWYfvRHBWF6sxYQt6IrqYbbsX6LuOR6t3U7sqk7tB+rrqhrA067Ad1K
u7VLuFJruiXwsazLt04XAfIavINKrMGbAR2QAVhXtsH3epuLdp07BQ2AAYKLAaILtxQwreLqt7qr
utvru6/LujnAshswvuRLu+W7ARwwr7javXmruEKbtU0QvcU7v/La/gEdULjHGoLN23shGAUq+6Zj
igGrW7fBqlfZa7UIzL0J7L2ty7Q40ADnG8HjywHXi6urK7JA+754i67wq6XAa7/0a7wdEKwyEHxe
54L3x31SMBAF8KzFR34uTG8GjLXt27Cni8E1nMPfy6qMawMBEAESTL4ckL6k6zLRa79InMTHW8SZ
63XNu3tKWLOYt4g0qIfmNjbtGsQccAAZQIcvQxAOsKkijMTySn7Tei12GolfejmbOsRuzAHH68Uu
E3dBGIdySH7BsMaK+IpSOqz0e4LBgGuIOHaKB4pmugK1x6g0ZciNQHaaGKWHzDFq7G6RDGt2eomV
7GqXLIqZzGqb/szInWyjocyNLeOOycmL8GmcDhoEkrkFNSoGpjyjP8mh0smgQ9DKJBqgpxyUW7mX
qEkEvsmQ0rnLs2yc/RmeQoDLSKnLsjycZqma+6maKUqfv5mUErqWyDmdXEmcCEme2RyRFNoDGQmh
otnLXtmgr+yi1EzOcvmh4yycxyyV1MmZGUqV3Ryi4jyarayXVWmexVmc0dmY/TmfudzOWomQ97zN
mcnL3gzP4IzPLgCc+6ySqZyZ4JnKAZ2bNEma6eyQ+ryacLnRtUzLQSmWnsnOBF2YxxnO/MyhtvmV
8hiXmymYKe2LEg3SpknSTymRnGnSG62cHO0DN/2cvKyPFZ2b/jhNzLupzKLsnPac0zOtytJMlRqK
0gD6AkP91M4s0O/J05CJmLR51R3t0fY5m/jJlEDJmMNMk0s50Fdd0E5tnRBajZi50O6JnWT5mWKt
zul5n3P9zDuNmxi91JpZ0/hooeoJnRitmHad0EOpy195oSrd12b918SZoRb9yxntj/Mpowl6oYo9
leD52Mjs2NcMom99omQt1CrKBJ+d2MUM0Ixd2v5c2hMK0cm82vl8o14w1q3djmDAoqzN20/g28TN
10Rq3MB93KPc3M793NAd3dI93dRd3dZ93XB1qNi93dztCLO6pqBsiEwKf+dWALbLrbQb3o28rU+L
pWSDh1YM/n7q/YgWcN61e6tTE7jSK7iBXKd/GN/1Nt+OUN8ZG8EELuBqwLItu98Xy+AWoFc+CINm
e4f/DeABTjbmXb7oXb7aXTAY4LSC2uD77eCsp7YriAbQxoAAKIcqbnwAiG8wgKwAZwFvHMTky6av
2sF4q71a0AALHqYnG+RAjr8pgKwlx78RjgXUJodM3uROzuL0poIm7t1vXOVWzgEdfrA8bAM6HgXR
iwGQG6hgLqhiLqjzOnj6xrkoLOEx2ABP/uZOnrxlS4E1h3LLq4RXIABXvuccwMQTu+U87Lqpq+W9
28NQUK9lHuRgzqndBrOXN+FrzgVLDucT4K9Pjrnap3tp/oe2bD4FBcDnV07kptu3Dry0Guy+U+AA
j6vokJsBAFiqypfmR/fESX4FS96pTO6vuo7rctipch7jRa7CEy7FTfDpoF7lor67Veu7DVzq27vC
qh7CACiFwC56aj6BWfCnll7pu67rvX6CZ7xzFse89OeDxK61HJAAfK7ubuznV0vqB8uwObzA69q4
Zrjrgthu2FZ/J0zrXcB53R7wuo6qc66/au6C574ELMvu6c6abpwAF4DpNAzvQMvsCjzoUfDdaWp7
Zdd0JYfCR/4FAC/w+B7uBq92Kfx8Cb8En86aLk8rH86xqN678z6yhu4E463GCJ7gI0/yKIh7l8eD
n8d0/j/4CBbw8qwZ8VBk84s77xhc6Bj/pJO8eIJchmPqqdYG6/mNAUhPK5Fr8tbyyZD8MvG3hxUO
ft+m9VLzp0Ps8IMK9tANiZ4ofnjzv2DetT/f3aMo9mOPbO9mfGqv916W83Qv+I4m9oZ/Z4jvWMqd
+M04zM1smuJJ0ZM/zcFMBY3vMu+MB5uv1Ajt1V09z6S8zsK8kcxpy5L/oLmtnodt+vB4mpxNy5lP
zpffnM/szjMK1i9Nkfwpz7bNlBEq2ZP9kCJ5kKCf2aIPzMxczctP+o95/Mnf+6zc/Ad6kROt0P8c
/VMt04AN0Kk92ZuJ+92p+x950fTc0IgZ2axPmdYs/v7Az9mBfde+T9rpH/zrz4sfTdRQ3djar9Gd
+dMgAIhAMpakeJ4j27ovu6YzrZptksvpnpNqyYezrYAuoQ2lhDGbPZoyueQJY7tfMXhFLo3DGriJ
G3ehQdiZ9/Ihtcfbdn2b0sX2+bxormNlVZPbjyAZig7XW5jU3d1TWdlVn9VRYCShlg5UTF7YoqOj
n1zanyCb0ehgWtRaEmun61OVVOpY1ioqJd5sZm6iKyOZ3iNaF2Tpl2Vd8aaqLybvFCQWoHOb32lh
VjBtsKKvmDa35ptoj1vboGTh8nErnzfyHnRoVDmp6RbRenp79LsTUz9/eJoJLDhNHLNdB6mck7Zw
/ttDZbE4GRwCimI0Z328aHQIkcpAOOK6VZRTkuC7gCdXKgy5UiVAljIRmZwJc9jMnDp38vR206a/
nz1/DaWJsijSpEqXMm3q9CnUqFKnUq1q9SrWrFq3cu3q9SvYsGLHki1r9izatGrXsm3r9i3cuHLn
0q1r927PAAIEBAiA9y/gwK4EbChc2IKFAgIEMybb12/jdwUMUzaceHHkzFcf6+XbV/MdwpVHHy7g
6gFqFg+YrAbQWgzq1CJi0wYNt+/e3Loh235hgTTwDRZ4N3n9unin48ddP+Xs/Lnz3nc6667eQLrv
whw4GOa+gbv3wg7sLG9tXDbz9K7Rj1DeYjlS/r3Uq9PfTZz8aRfwwc6vL6ABZmJUMGAFgGGwHXgI
Kujddg7cpx9s7c02oXrlIafUYv35t+GDMKy2n4ds4bbhXg04KCALBeIVwYILasfBAR1QcF2EL8Bn
HoUgzhYbhEtpSCJ9AC7y4Xvr7TgheucZZ+Rm/zXwJJTWORAgDCqKYCUABI5Q4IBXWqklWAK0uGCM
GVAQAV/42dgekekpWaOEPuoGoJNAlkgjfuWZh6NsOFZ4pHpUBWCiA4Q6cGihhZqIZ5WNXuklpFlK
+ihYDWRwAKaZdtCBmREA2OGaquUYp5+imkphnEppSGedGz55x5KpLhlrqbVe9R+iieaqqKd2/hCI
5ZeUTjqssF81QEEGySZ75qfexOomoH4+i2qg1Rb1o525FQprbbJKSOuOPP5pFa67muvABIz6uiW7
wwabJZhfddZAAfUqlttjvoiLamrSsrlft6cm9V+29S0Ka6rjMgeutdNOVS6hhkIZwYwotuuusMG+
65V80I2IL3YiDPpkwbk1EMGJcPLrLbQtu6yjUwKcay4FE1D5ArAXq7gxl5Fy7DHQIYsgswMRGH00
0kkbPUGvarL854fP7uuwVIPOjOgEFKTcxK8txMszpFgKDVe5V5vb7NgtED3zBBXYnDbc/gA9N6hC
n4xyrhRXUHHcffud1LEU1Jw1geP9fTji/jPpdbLgjaPcQN2JSz65HdZFWWLklGu+ecdA77X5P6Aj
TvdjN0fWUU1O/IE6SA/p1I7oTJHOGWjapD4MOeiocc41QLmDlVB4zf5ZZo0Ysg4stkjCexyxTAQL
N7qwxDohqltTzOq9374I7FwFT5bxy9heSTpW1HIKF9FP0svvBo1fPe706G7P7t8H1VJJ1CNkvfkA
1bNT974BDOTx4XiAWJ/z0AcHAyqDffYjSh40IgtaKO+AzBtHNkSiiYkkZHou2V/87rGK6xWFJDEZ
CQEzQgxbjEKBM4gDTfiRk/Cxjw4GLF/9csiOT+DDgb6LIAfHJ735YWOBGIyIDdERQAHG/qODEpHf
8gJhjB2GY33MMGFFaJiQId6QiFOcIkIucQh4LDGLA6xhOdDXPD2o8YURtKIMX7E6fWQkgQ3pCPUo
IcFQVPGBdtDiBFVYCwSKEBkwJCNFTgLIPWAve4g4hAuxQY2axJEn/fDjH+/nFHDQcR5esKAUcaEG
dSRylJV8yRm36I5UXMMQpeiiMOAXjzJ6kCl+xGT+5ogRNNiRI9mTSAZbosdS5u8ZTvTkKA+ozGUq
k5XCjCMuY2dGnPzwKLbU5TFHOI2GJLObLwxmAZVITGmWsCm3FMslX6dJcrLTK9FcpzXbKc950rOe
9rwnPvOpz33ys5/+/CdAAyrQgRK0/qAGPShCE6rQhTK0oQ59KEQjKtGJhoUBFrXoXy7KABdodAQX
fcFGKdoYjX5ULCH1BUlPCgCSenSlGG2pSBnzUhGU9Csz7cRMc/pSjPI0pzEdqUpdyoKOelSlOr1p
C266043WlKNEpWlTk3pSnRZVqDUN6k/xEtWhshSqVXVpV53KVaiGVaolTSlWvQrWr1qVqUPNKlCj
SlW1CrWudpXqWO2K1LzSdatknatarwrXzDxVrIENqVLTeteeTlWxeg3qXsGaWL6+da2DFcxVU/rV
pWrWsIelLF7pKlqy9rWxnmWqYy/LFqQula00fewdJrtYxwJ2tLAtbVLHGlnVtqWp/q0drW9ry9az
/hakRhXuYU1r2dfqNrW8VQtai1rW5f51t2hFbGeNe9TCSleu3IWsW59Ll+l+lLVp5a5ZUetVv3aX
q7v9q1NZq13x7vO99L3vO+yL3/0uQr/8/S+AAyzgARO4wAY+MIITrOAFM7jBDn4whONy3QlTuMKo
tTCGM6zhDXO4wx7+MIhDLGIRS1bDbvFvhAODYq84N8WRWXFWYOximZalxTMGjYynYuMb4xgsOebx
SG0KZMTtGCpFHrJtjrwUJbczskZFKUx7El3croTJUtaKkheg5QXMhMti8LKXXxDmJozZDmUGwJn9
sVfkimGqRWFscX/MBDnT2BVj/k6zQPDMAj2PgM/+OLOfcXrhEkdXtittqU9Jy1zJRvnQlKWqecFr
WuJmdtKSrmprZWxlnjC5zGHesgu4rOU9j1oEoG5BqdFs6j7fuc9MALOrTV3qU8ta1LEW9adT7d4P
DxfR2P21oolK3NCK1ruV5mxHu6rswi67vNNt81U6jepVU5vV1P50rPd87W2rmtswgLW3wa3tbnd7
1uQ+87Dn6uzzwpSxbV1rpnsa3+/KNs6Dritg3Y3XdZOWvXOuipU9XW2BhzvbBi93tV3tZ3GL++Dn
fviqsU1seX/Wtm5e76Hl7dZMZxyr2YWva6tLcXw3lqVrtvRwlbzpnAR82hDP/jbDHU7whtf6ywNn
tcTHreqc45rWKb8tci9u1Y4PXb1Fv2tyzQpaQhud5N119mmbzuYmrJwqMz+4xHkeapfTHOGvvjnX
tx5xmJPbuJhWLr9zu+hkH5W6aZ/4cYGO3ahTeen8bru/YVB1mbSc7AmHuNbD7vWYl13sWb+12BNu
7pz/3MQYX3S/8Z7Ye+fb3k9/utR/rfmRI3vumIcyVQK+ZU/rGuxo1nXpT494Wevc1okfPc6tTWqD
4zr2dLesyeMu9LrXVt3Kjbxrje35x5Z8+G0HbtP7C/C7pDnQdtb5TOgsuan/O/TMR7XzO0Fwlu/9
cFPG6fJFKv3po9cO3a8y/pJBd/6TrD/9ddax+zXX/orYOPtkTvxJ7G9n/T/f6g43C/8VnkHM3wAi
BaDJRACaGU8koE4wHloEIAPqXfjZ3M7hmc+NWq4hXAba3ukdIOqh3t91YM35nQiCnespXKuBmbmZ
YKrR2gmSGqx9ILalXsTN4AjeYAli3wyqYK7ZYOuNoAOC1ATen+oJ4OEVoQqyHuApHNaBG8+l3hH6
XRQmIfYNXMxpnQ+Wm55tIOHNGqA5YReuXuFlnRNK4QF63c79X2UN4beZnpiZoBhGYQiSIB3+oBG+
XBi+HgnGYBqOoRi+IRyG2xmioRzOYSAS4h8yIRwGGgHSnwK+HAzmISHC/t4N+pzpUaIAHqIiLqG3
2SEejt0JntrodZ0n8uAKFqEd9mALymCoUeIUuqKYraIoZuIaWoVz1V4ITuEh8tn27aIaFmIfciIa
lqIUpqEH4p8edqIVJmMQQt/fDSLhOSO3HSPVYRkRBiEV6uInPpwDriAV0iIwlp02Nl80Bt4nhuMe
7uIXFhw7dmMcXuIclqEbCqE1fh0kWpsq4lzDXaAsbt0H3iMM/h/p3dks+mOrcSAkumALylw5LqQS
aptD4iA/kmPg9WM83hoIVt9WjN9fRKD/9YRHdgWfNSLL9U1ITsVJPiJc6BlHJgVJxl9avOROtCRM
9laN1aRm0KRT6CRONY6FTCoFTxbYT4ZeUErFx7nYUEafKxylhI2YUz4lVEalVE4lVVblVPYkVmal
Vm4lV3ZlVIQAADs=
------=_NextPart_CF8_D2BE_4CA566D9.AE8BD705--




From Robergeoyjaz@alphaprinters.com Tue Apr 03 04:48:11 2007
Return-path: <Robergeoyjaz@alphaprinters.com>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYegV-0006bm-JN
	for sip-archive@lists.ietf.org; Tue, 03 Apr 2007 04:48:11 -0400
Received: from p50809470.dip0.t-ipconnect.de ([80.128.148.112] helo=p50809C45.dip0.t-ipconnect.de)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1HYegG-00072W-Je
	for sip-archive@lists.ietf.org; Tue, 03 Apr 2007 04:48:11 -0400
Received: from hofele1
	by alphaprinters.com with ASMTP id 5F0B7DC8
	for <sip-archive@lists.ietf.org>; Tue, 3 Apr 2007 10:48:34 +0200
Received: from hofele1 ([142.192.97.20])
	by alphaprinters.com with ESMTP id 93051400D555
	for <sip-archive@lists.ietf.org>; Tue, 3 Apr 2007 10:48:34 +0200
Message-ID: <000901c775cc$d2f04b90$459c8050@hofele1>
From:	"noel Roberge" <Robergeoyjaz@alphaprinters.com>
To: sip-archive@lists.ietf.org
Subject: introduces called WMDC
Date:	Tue, 3 Apr 2007 10:48:17 +0200
MIME-Version: 1.0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_000_0005_01C775DD.96791B90"
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: 3.0 (+++)
X-Scan-Signature: 025f8c5000216988bfe31585db759250

------=_NextPart_000_0005_01C775DD.96791B90
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0006_01C775DD.96791B90"


------=_NextPart_001_0006_01C775DD.96791B90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Of, will used manu users works enterprise business editions.
Pictures irgc rejects claims, turkey. Http humor, icons interview =
javascript job js.
Little slow, might returning, faster sore spot, event. Unlikely jury =
limited twoway ranked poor testing result groove.
Pm subject ng thought maybe could answer herewill winxp. Hasnt, adopted =
api clicking symbol atop panel link.
Times however want, customer day later, icon, appears area. Zonealarm =
gmail corel suffice, nicely until! Reduces form known, as casual?
Wii pricestips tvpopular networks pswiixbox.
Sehen wer bookmakrs, auch gut findet mit einem klick.
Fixed flash flickr float.
Feels clunky intuitive dos least.
Onecare frankly browsers closing!
Orb, related materials trademarks corp message mothers. Hearts wish =
everything look utterly convoluted almost kafkaesque lengths.

------=_NextPart_001_0006_01C775DD.96791B90
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.2900.2180" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Of, will used manu users works =
enterprise business editions.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Pictures irgc rejects claims, turkey. =
Http humor,=20
icons interview javascript job js.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Little slow, might returning, faster =
sore spot,=20
event. Unlikely jury limited twoway ranked poor testing result =
groove.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Pm subject ng thought maybe could =
answer herewill=20
winxp. Hasnt, adopted api clicking symbol atop panel link.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Times however want, customer day later, =
icon,=20
appears area. Zonealarm gmail corel suffice, nicely until! Reduces form =
known,=20
as casual?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Wii pricestips tvpopular networks =
pswiixbox.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Sehen wer bookmakrs, auch gut findet =
mit einem klick.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Fixed flash flickr float.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Feels clunky intuitive dos =
least.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Onecare frankly browsers =
closing!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Orb, related materials trademarks corp =
message=20
mothers. Hearts wish everything look utterly convoluted almost =
kafkaesque=20
lengths.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><IMG alt=3D"" hspace=3D0 =
src=3D"cid:000401c775cc$d2f04b90$459c8050@hofele1"=20
align=3Dcenter border=3D0></DIV></BODY></HTML>

------=_NextPart_001_0006_01C775DD.96791B90--

------=_NextPart_000_0005_01C775DD.96791B90
Content-Type: image/gif;
	name="promise.gif"
Content-Transfer-Encoding: base64
Content-ID: <000401c775cc$d2f04b90$459c8050@hofele1>

R0lGODlhlAEQAocAAAAGCnQACQZ2AHiCAAABgYMAdAB7i7S5vL/ota/B/kMpAGosAHwlB5EjCMcg
ANQuBw5LCCM0DDtKAGVDAnUxCpZMBsw+DuhFAARRAiNRDjdYAGZuAHhRCKxlAM5fBexXAw2BABt5
Bzt2AFZ2AHaIAJtxB8l4AOxyAwCcACmiADWpAFOfAH2hAJSbBLuZCe6eBAPMABHHAEXIAGHLAHfA
AaaxB8rHA+LLDQDtAxbbAEjuCWTRAHHVAJHcAM3uAeDoAQMDShcAQTQANGcAP4cAQZ4ANLwDTuAF
QwQdTBUTTkYoP14sNngkSa4hSs4VQ+kiPQs0NyxJR0lGRFVJP41KQZU4QMU1QNxDSwtXQSRRRjRf
PlJgOIdZDZdmPrtsSOpTRAmKTSV8Rk51Mm16TYeOSqGOTr2LNO6KRwuVTSyqRD6jPlOnOX2sPqKr
N7efM9+sSADEOhS3NjfHNVzGQHLJOqDGP7rAO+e8RgzeThnqTU7jNVrqOYHfMZvXOcDXRejnNwAO
dS4LejgKglUAi4EAcqYAccgGhO0AgQYWixEqijknc1MpeIsTepEWjcQadtclcgM8cyg0cT1Oc2Ix
fnI5jJ4xcrdMdu1NdQdjfxNdjUppiGRtiIVgdJdgc8pjf9ZTjQCEeySJdjuIeFV1eXuBjKGLh8l0
cuV9fQCechGpgUWUiFygcYmehZubgsqfidepjQK2eRe0dDnDiGDMiXy6dJO9fLTGeum2jAXUgijV
cUvTh1fVf4jogqLZfMHhc9bVdwwAyx0BxkwAwlUNyHgNypYIwr0AstQAygAXxBwbzDEXv2kjyIkt
zKIbtLoiw+stygBKuhUxzEhHxVpGzHgyvpFFxb1Avuk4xw5mxytawkxqslFXv4pZtppYtMpZu9Fk
yACFwBqMzEp2vGWOyXKFy5mAzMmHyOpzvAmYzRestjaRxlSdzYeXw6qXzMCSseidwADMyh6zwDTB
uF3CyYTJtZ23zf/w8pWeonOBfv8AAALzAPH8AAAF//YA/w3///Dx/yH5BAD//xwALAAAAACUARAC
Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixokV7GDNq3Mixo8ePIEOKHEmypMmSFlOqXMmy5cKT
MGPKnEmzps2bOHNqdMmzp8+fQIMKHUq0qFGBOpMqXcq0qdOnUKNKnUq1qtWrWGUe3cq1q9evYMOK
HUu2bNCsaNOqHWm2rdu3cOPKnZtwrd27ePPq3cs3I92/gAMLNti3sOG7gxMrXsyY8eHHkCNLnky5
suXLmDPTbMy5s+fPoEOL9qm5NNbRRIGoXl1wtWvWCl+/ZuiaIGzUuAPHBMBbI28AvntvJECcwEbZ
sjUiV676ePORqz0iB8J8ekhg2LNrF1mceMbiHLuD/9c4HmNxgucHps/Nfujtf+/fC+xeULx9Aurv
459PvH7/hr8dxM+A/AhE4ELrIXSgRL8JZ89vGxEo4YDVVZhRdBlBaNqGTFEUoEANgsibgAse9KF/
//E30IkiAuAQiwPFp1pC8pk4IoMhtkhQjv/w2OONP94II4w8cWhkSRo2CNyDDmaopEcabhRlR+WZ
591IUzq5JEZZaollkyVphx1G2QW3JZdNQhikkEDyt197cDYk03jiWWmclE921GWXeJ7JpJ8f8Tkl
n3+OROBuvQkXZZkcMWoPhq9hhKGXR1aKFZ3GXVklmg16tGmhIIkpKkl8dvfdlX2SqmSnIYHnKqqC
Ov+YJHCKgkmopbg6BWGitIJpD6Z3OkddqiCtmqdIhBrr660cKetrs7WCKq2ZGpU55rVjDodqrtw+
teqfe9YK6LSchpQls9RCaSyxJH365ZLflgvtmd/Gm263+IZU0aprttmikja6WBCRA/tLcMAvGuzv
QgczDCTAOhrEIr/8FixwnBj3RDHEKzor8cINR9zxxQ6TnNCQC5c80YkcEzwxwBXvmHLGNNPEKrh+
Drrss8ye+6yeP5tJb9DyFm2SzmnaurOsN+frdFQ3N210uOM2zXTORN/bp9TODu01ol6HrSWgUaP7
9Nk4la100muru67R5AaqLKc8O6u12UCLLTTHMj//7PLMNGNsc5RcL83uvFa3/a69mb2N+Nh5oy25
PYFXbvnlmNc8+eacd+7556D7lfnoD4VuOumop666Q6a37nrrqyv2+uy04xv77VvVrvvu3AIFwe8F
/Q7BYAwUfxAHyBeEfPILUeB8Qc5T0Fb01Ef/Md8PCT/8QMJbjDtQMWEg/vjki4+R8Buhn5H27EMw
Uvnjf6T9SXyiYP9G9qPwbp8HaX8Q/Bh4iAAGSMABFiR/CMwfQdrHvpF5TyAJHIgC+/a9n8SEgezD
CAw2uJENwkAjGPzd4o61EfJxRB8odJtHPJgRFo4EhfrYCAzzBqgQOsSGDkyIBzdIEA8OxIc95CEE
/xEoQfs9sIJmmWBBCLhEA3IPeBOB4UBgqI+DEPGARkTY/8b3D/I5hIsEAaPFTLbDIN4Qiv/o3kCY
eDLA5fCNDRSIGouIAiT2pCYz5IgLW8hBPn4wJgTUSCA3goNCGjJ9IuzIIDuCPvW9MIUaySMIM0ip
CybSHo6MW0aoKJJDasSTmKRkJjXJO61YRIkEKaAqnSgQNuKIZETaoRAHIsaCALF/cXRIAndpkPYR
BJURUSIqV1lAkSnEla1kJROdiMw0otGOY2mmHEO4vX/FTCEsI9I1nVnN4D3zem7sJTUNYkhDhrGW
pYufPdS5vhBiJH8j2aMG+1ioXYGJnaWsSUqk+f+PZiJzOjNiiMe8ub05/uOWBQGDQhfCT4Ug9KCz
jBiLZBlRgW4TojCgUUAFIps3ioyNBmxmyKC5lRrBZ6McRalJG0JMhCgUDAJ5aSpZ2RqUHmSlCZEp
QXQao4DWCDkJM9ZOF+pSosb0pUadlKSeY49BrnIji8xnVpR6qmDZiTzbMsmrsrrU5FRVhSChqkgc
RaZsXWg5HzEVd1Cl1l95ByG1qSkQejpX22z0NrOhIEnHYtIE/SNBOF0IbH4K0Py8qSDZEaxNacPU
rmJVPyBxF0eUOqlDfUSskyKrPRw1qUhJVS/uoqpS8dYRR2mWskyVLLpIW0mjoXZYbmtIgtaT2IT/
iIkgtT1pXenqUR/ttS1+NdCAClIi3VIkt/9A7ssudrDC6vUhyE0udp4bJBGNUbYpoo+b7oMe/aRI
QgMBrzF9O9LfEiW4f02Rm/omVIbMNj0+yhF6++Xb6FrUZCeKa0pnNKEJBfWaXQMnkZwrEORqB7HT
NW9KaiLZdnl3f0KLm4b6a9mnAAhkN+LuQ/QjFAorOCygA+hnR0ziEl/mwyhOceBMzOIW40TFZXGx
jGdcFRj/lsY4zrGOcWXjHvvYKzsOspBN+ePKDfnISC5MAJaskSUz+cgTUYCUCSJlBVB5ytclSAO2
zOUub5kgDgizmB0Qp9JUWQE3EXNGxpzkmDi5/8lPxsibN9LljYz5zmrGSD72zGc+Z6TKGwE0suLl
5EIbWiR+5sgDFs3oB2RkznKe85knjWaQFGQBmF4ARLhcEE4bpNAFqfKVrTwQUQvEyadGdZF7Yup/
nFkgrdaypw8S61LHGsuuxjWsdZ0QSpPay8BuAENqLZBgv5FHhjY0RPpcF45wmc5b7kihNwJpe1Qb
0m+edpspwmeB9Dkf3t6zQYCNkEzTmted/rKshe2QWR/RIbWGcwA2kug+ayTPM6kzkhS3Nz/hm832
wLe1k91mjFDE014utrrZOzMimVshjC5IxB0iZoQQeyGqPjepB2LuTGuauq8s70AynuoAGITSD/+E
GNJYW/CO5DnMAXcARgQeaW1zRNDyDgnNaV6sn+FcVeM63yXp1qXiMYAmlC7Jz+2x9JgDPCNGx4jR
iyd1qv/5zC2vSbbnzeRqC919oQT7RqLHkVGWnZolIXvkTGL2jKi9nfM7OwbTXr19200j6sSn2p1n
D7733e8YqR4Fsj6TXdrD8MSq3/1KaD6Q7DKBJYmqIAd4EslPUuxEd5vjQqK+tiuSmJLv/NDDHsrS
j5KYLa8IRTH6UPqmjEjmVEjsBzJ7hrReILW/sMkW+E1fGgSYAxmJUyk/klEan4Fb41XhepU1HFdk
lf1U5Rgv2nqDHiT3uVcIOtdIU5Z2nyC5b+n/uyOCQYdgv5DgL6f6ee+/9iES7J4nvLkIJ7WoWl6e
GYHnR/CPf5CA8nDFN3qfVEgGN0R1dEUeBRHjZHsVhVBSNEUolH7l9A/qhwNNJADch4Gr5hM84lvV
lYAfeIEamExP1E3c9BAHY30MAXwQWEUzpYHNpILmh360R4ML8VAIlYMVVUzJ5E/K1FAbaBFeJBBD
WILd5D8viBAVOHvAxIII4YTZtxBO2EXiY0uzhFBTqDIgqEVvxIM9OILR94NOdDcsV2IW0YEos3tp
qEOrl4EX2BAUlVEEFREew0DHdiJQkId6uIcMGFFlxFDd50pwMIgGMYhwwH7VhIRBqDryEVgj/+OB
jmgQhYVUPMVT/4BU1oQ9ByFNQJiAImcQXuiFiziKpEgR8neKqJiKqkgZpdiKrlgRqxiLp/OKbiGL
pUGLMWaLtYOLpaOLVsGLqtNe7AVyCNE1bIJffqMsDKcwFzWMIOeBbYRhACaMmchc4VSM2KOM03cw
n/iKA/WI1rh7ATNQa1iN2USNATaO49eNa0IQRKc2jOM4ZYgzK0dC9Cg1pMRiHnKOsISG4ohNr8eM
W/gvMvNcmtiOR8SOCGmQs7IlyweAXwI5RZM4DvmQObaPyNiP50iHAZmRAxmC2OiR23hd0BiN5ShR
bZKGEAkT9Pc1rUUu87hjsVKRrFKGM8kut/+yWobTb/OSj5rHb6CCNAAYkzjJNlozNc2XZDdZLuJC
P3WDNTT5Nvh4lDBpj/TIkvYolNJikS+JlS4JLlSplaq4lPWkfE5ZNfzWNWNDNT1JKVSTlOkili3J
OHBDlBI2N2FplBf5Slz4ISOikH8jkiAZkvEljXoVmHwJkt9Ijc94jSapkdCoTSnpmK5IciO3ZJdp
cv+QbBFhmSVXEBnnmQoBasZkTMmGmZ+GmhBxmppZcqTpQNBomQ9nEbMmaq8WaugWawpJUm4WZzmH
ETg3aSfhdRiRaRthnDV3EjiHnBrBnN/2bTcnZcrpa9IJnNXZEc9mD9lpZzDXnJjmERDRaqr/5pkT
RxDluZmqCYzX826tNmkR4W6ZCZqqKZqjqZonqZgLQ58J4W61iW4ch2n/+XGjJp+tWREVt2sbV2uW
qZ8bKBNYZ53XOS1T2XNoeTVb0nRXF2jBeZ3CmRHbqZ3RRm97dhICh2+3wmgagaIasXQYGhLfWZzM
eW2+qaL20GiOlmQVQZ0bN14KeaAGgWc+ip6s6ZqcmZmnOWo7epvx+RCvKaSaOZs/GmZgdqC+NhDP
2W1I4RFXmg/31p0z929A6qWP5pszZhE2umgGAaUe954Ll5rKtow8cqYP4KZvum7j1qZBYhJNJ2i3
8qEgGm1AmhEeN6gjgWcaWmlXV53B1gAe/0GcLqaekBqpkjqplFqploobvpiptHOpnNqpDaqpoBqq
omphnlqq36OKprpXo1pKkLqqrio5qfoZr0pkscoSs3qruJqrurqrvHo2tfqrwFqqvTqsxHoawVpB
xZqsk3GszaaszgoZzBqtwvqs1Fqt1nqtsCOtb4Gt3Nqt3vqtnaOt4ooa4FquUWGp5moa46o5mbqu
7uoZ7fqu8iqvojqvnfFNQWGDKjYT6mc6TPNO+gOw8/RHLgQ/X+d55bOWUFVAgwYvXykSxNdUAqBH
e2SwJkFPZjgR35c6ESgQHWuDNKhGarSxP6IQWZRFUIRG+soQIttNWYhFReRN0/R7dXR96/83s8CY
RaDYie3Rsf/QsX6De0uIs+KkECm7PUIkRCvLst2DRlVYhUw7U01EglKLECRLsqSos2YEUdWYgTT1
h6wnh9FHtWPrFY8nEFcoh3Eoh9iDtRRogW87TXO0tFKoQDqLfnT7Mek3tWVrXQmRt3lLihvLTBrI
Q4bLtgKzMIRYtk60uIvrTF8RtJCLs8BTudtztWDIh2E7EERFVJQ5EHn4D5pbso5pVH3rtZkLBQ4l
S1WbYjGhUB0Bu/Ygu81Ru8PyHEyVJ7Iru48iVlMFW8/xrxI7vMTXWMERVrCVEbsLBmjilGB5j4Om
Ebw7WbBlugdhvT0FY3NiVVbSvW71vVf/gru3O75LVb5dlbxpwVTie1be671c1bwfYVbs27sZIb8i
Ib7DwlbcW1rAgFXq0jEHkV2HZVeQelvbBcB/KTD/8R8+VVdsUpC4BQxfkWDSRVcbpV4LLB7dpRAU
DI4ool4IkWC1dVe7BZCGlSLvYR8DQcEg7Lf7+hS2S79uVSV1wiTwe8Ptu6pwiZVAw6sUMjh5ISpj
Mjd2sy7rMiHQK8T2QGH8cB1KTBx0iTjAMSr3Ab1I/JMmBhaLxZH2yhAxQWHpajtdDCdhvBkfPMZy
MhNBY5Uy1lY0tBTRYif7q6z7AjgP7BLNuBKfuxUjYsM97MdRLJF/HMc77K0T6seIXDY4/9xzuhJ0
ahHHjIzIcrPITgK/kFzGx7vGFQktluzIeLI1gnws8FjJj+yw80fKkazJs0LJmBwvNbnJmUc3+6Yu
E2nKgGzLqIwWl8zJCkvLkuzLu4zJx+vLt3zDh8zLvZw0nfzKfBHMufzJz+vMw1zMwvzHgwzLyjzL
pHzJhEw2nqzLuCy8xAzNqjzMhXyrZ/iP/TJ9EJwwEHzHfnvH8OzCRSE32XyV1MzL4mzP39yrZbHH
Jctw9LzOBHmHnVGSBe3CjIkQyVoWeDoU6SkYVTqoTsqgLTGoAIrGl6OkNGNsd/YPYxYg7qnR7lrN
Jm0ZZHrSUZHS+RKhlhGiKg2eFFGnAf/tFQc5EDaabg9twg3RpNjjo1LqzrYmawVD0mIR1CBNZgN9
FJKrty5sPFyMm6l5cgm6cVJ61UoNb0m61QUB1UbtFfgKwAJRPc441tQjswzBPP+g1kXtt2HNEM/T
1Qwgnwzh1ZbrTGyHeYBnD1Y3STGNEwKYEY13SYnUeI0XsRE7vNHLyqUndBhhsRA7sRxBfLRUPggB
taSrkM+ktd/31l89FFqL1mlLtjE7RBOBRm+N2kgrthWFEM+kjT7rsxBIUJZrgmy4t2J9Tp+tEoAk
2X9MT8C9R0sYEwSIEcV9QjGEEZAU3BFJsfgTsIcH3fbwfx3EQhg7ye3k19X9EbvNOjD/Edjz9NgY
INjjvbACWxOEjXkawdyK3d7+hwMdcdzhPd/RDRKUd9++rRSN99c2gdi+TXyQZA+QlEiJtM/gbd4Y
4d/kveD2wN6nzBHyXd/nDSYGcbhcu4I1S7ST+0Ni291bEUEcboTdBLYEXdoMYdkmHoY0JX1n9F8X
M7S8V4K6lOGnG9qB26zf+mOhe9A37eFeDBOUiFRgGeSwuy7W4VUfQeTMS4n3yHxszJNKzrzWoeSz
G+UvFRKRwuRMbrxoUas4xuV84eNiPuackRVw+cNpEch7SeYMMVwNscUt0cIIMsBsPjoyISYyAZfn
7LygDM1BFqyIAnQ3U8OyzNjaEhNZ/3XJaM7fuuMr2ZItvELN3Wzo/svD5jw0UFHncaJdAf3ACawi
6QXq/wHQUS3WTa3pqVMTFlrJkS7ptrznR+PNq8zosJrOj4jALiLPibvrS20jK6POx7ibL0HrfZES
k1mQn17iC+mYpK7sNY3quAM2SmMadknsG4LH6iyp1n4XsL7tHMGp3m7t0D7u5F7uXBHuxG7u6r7u
7N7uK5aK7h7vBYHu9O6t8t6L9Z7v/nzv/O6O+s7d/R7wAk/u+q7u/37wCF+tAw8WCZ/FC//wvN3w
Eo+rEF/xFu/ds3rx4z7xHJ+xGt8Vw/rxIj/y7d7xk44VaiMvDRnLidzPHW8kJ9/NuP98lpeu8k0Z
lK8OyzpB8kcR6K7e8jMf65h+y64slTn/zDXG8xch7aMMOfvMyMIrLnmClzJ/zC9vGDN9pJ+JpLk2
1D1tcvOpmaiJmWSvmVN29qTGMWGv9DSjjUmd1daF0AqB9l6PZXSPZWWPnrsWpQOB1GwfJ3a/o2NG
EGUf0Q1RpUktEEGd0QKR0emJmuJ2aQLK+H8PJ5Ef+amm9wqncOz2D5hfn5fZ9z567F3v9Q996pX/
F0uxaBjB+vbwoswpph8RZyx99buY+rjPrLa/+yKR+0h09Zfj2ZHarQw7sH1U/J4U4SNx3McNeZMn
QwHuFNE/3aCEeGGn3r9Y8sQN3+L//XkZkfzcf7F/1OAEO/7Qn9wHm3/Or/7rLU8IdHk1j+B9dN1h
LuYykd7WXE7UnxGJ/REKDhD2BAiwV9CgwIEEC2LAYI+hwYEHDyY0CAFCQYsFIyI8mBGiwo0GHxbE
gYOkSYkpU/5j2dLlS5gxZc6kWdPmTZw5de7k2dPnT50MXSYU4FIoSxRJUfxL2nLgzZItoyJV2hIA
gH9XW1rkCoHl0ZdEWzZlujQr1rMuLbrUmtYl2X9P4xYFWtfuXbx59e7lyxcGjJhrWQr+97fwX8A7
5c6FCQYMSziRJb+M3NLxZatY2/6rzBlOS8SJW0KB4tLwYdOi/wkmXFfla9ixZc+m/13b9m3cuXXv
5g3bp+OYwFkK/wcESHHjx3cSJ97S+Mvmwx/DfI48ufK2beUuRu5SePPm1av3JV/e/Hn06V/uNq6y
fUECBAy+T24wPm1gwAzmT3n/oP//5EvpvfmAMOiqghC0xz8A7SHQQQMhLFAi+iLsbTb1MtRwQw71
4udDfliKb8SWRiSApfxQTFHEE2+66sUSTYRpM5myQyuzGFlkSTzlzqIxvxVVnBHGDne68Egkk1Ry
SSabdPLJ10xMSUH4RgywQSiz1HJLLrv0srciwxRzTJ++NPNMNNNUc002DyLzTTjjlNOlNuu08048
89STzTn79PPPMvcUdNAvqST0IP9DE0z00NsAdfTRvdBcVKVJaXvxxSMTrTS2TRlVE1JQ+dINU3tI
ra3TAwHYDVXcNFW11Vc9lXVWWp8k1dRLU1UQQSpzVbTXWDkN9tdYfS3VWF5f9XVXZW811c1Qo5V2
Wp8uvXRIloj08UYbs73RWxet9fZbHN2ycTMau/Wx3PVqdfddeIW1tthlg312XkVXHfZYiazNl99j
7RX4X0NZfY1ahBOOViuG0VI3XW1pBLcnid2a+GGHI/4WY7bIpSlekEM+NFmAmf03X5NLHtbgRQtu
luCXU4b55GMVtvlmP0cdmNiXU4XZZXot3ddVZ2fml2iZfxV5aaZnDSCAg55ueur/lXC2+mqqs5bo
aq679vprsMMWWy+ty551bLSNNDvktNt2++1o15Z7brrrtvvuQ+GWE2+++/bbTL0DF3xwwov8m+rC
E0/v8LkVd1w9xrN+fHLKK7f8cswz13xzzjv3nMPIQxd9dCY/V5z0pk1XfXXWW3f9ddhVR73N2Gu3
/Xbcc9d9d957F3N24IMXfnjii4/Xd+STV95R45vPbfnynB8eeuqr31B67LPX3m/ru/f++7i3Fz94
8D8f//Dy01d/fZ7ON8gB+OE/KB/665doAfzzF3peTJ+GOmqp8YxR7GsXbhpwQAQeEDYKYGADbfMA
CD7gIBG8TfwsaEHZNFABEtHg/wQheJD4FSSEBaGgPUoILZnE7yX5WyH+XKLCweVvAS5hIed0Rq9F
OdAeOpzNBd8nv4505SKv4eFsOniQI4oQiAFD1KsY8MSDQNE2z2JiEwW2Mn/Z5oIOcJP/AuAS/71k
iy15YhnNyICbnJElalzjEzunG65IJI4V8QhG6hibMxqkjFZUmkrmSBsKBDKQBhHkIPUoRXv8USKC
7I0i7eE/iUCSjkO04xAdCZs5KlKIkwyiJT1ySdv8MYtVdN+UWqagS4JSjptMZB2VcpBXpiSWtGFl
KxWJq0pRETcU6eQqKUlKXmpEIbIJJkKGSZRjhmSW9khKQZa5y5AI0ZO/LKVIRv9yEIY0xB4lQclB
uDmbb5bkJCjJZkrK6UvbKOWV6mymrjp5RwHmxpHZpCc9vSnOhVwzJ4iBCT//wU1usiSg/5xKTLL5
k6qMy1wVu5xuzonNkTzUmtqMDUUsupFvSiSjEKXobC7KkWLqcpSThKdHQ5LPjjrkmvbQR0sNgpjc
wFQiMo3jJz3yzF7uJpjl5OlKq1nJlMxRpKw650POmcqStlQftoFpaGBgD5kC9TW6dGY7azNPn0pU
k10JZUkzmZGaemSjKQFoWXGAE3+WxSxNSejmdDPWcUo1p/Li2auKKcxhurM2RY3oSuEKS6tK5K6y
wWpKtVrSetJmsLxUakFc2lj/qP4FNlHNzSxl6tSn/hSwKJAlZ/vIR8LWkZUSRWlKKCsbZzUrWH88
KS9be9LZUFG2hjotR2eD1GlWUqibGqxtghlVpxqvJ1x5CXEtA57oyCStTpXOdLyTXG3ZZDIwme6O
xpMQlmAXMp2pLk5IU5qhcGcudLGuhUwrWdlIJiXqjWxm24teqhakPrv5Y325qlm9Bmxf853vbPoL
IQJd5iACTgmB90cpYJnqOg+yx2UMbJv/NtgxEjGwg8FAs/j2C2gFstCC8wuwCN+mv/fKMOl6suDk
zATFOSFRjOLjkhRbRyYtDpfH1nU1IkW3Ji2msYydE2PrKCfGQPoJkIEcZAKa/8dEL16dPYAEJNyg
WMNXHNaT+VMQEGUZRLRZcjWT/GUwh1nMc8JvmWkzZjSnWc24M3Pq1ky4NsdZzkhK35zpzBP+xWRe
b7aajmvi53Gda8/bGjRN+HctQgf6JYg+NENrJK6OQVqhN85MxjZWaL0getKJJvSeNf1pRyMP0DMZ
NaVHXWqcAFpjEmN0qG2SY4hZutKz3rSpBR3pQ1N60pKOrqortupIt643I0XtpnC5r8/qC9nHTjCz
kH3g/B77s6k1pWo/DNprpzbB2OY2sfTbbecBRdKvDjWw9ezqGp+bW6CGtY3J7bF20xpGfRyqtZPd
7dmqltrXvrfS8r09cWvG3f/qJjW6HI3qdA9p3dcaNMIfDe9zydvgsl50xGsdbIxX2t/27jcpp3zK
Z8cZUyUGd7QPXVdjQXvK7iSZtvFV7KE5W6/79ji9LU7wjO+6YQK/tI1PrWlaQy+MYbwJ0WPSwJYg
/egMrIvSWzhDlgzdi/8geg13YvWW1FDpTs9z1l349Kh78Wk0MfrFibR1BfzD6VQfO0yw/pKyJ53p
rOONBotIVyIykN8FkWTd9Z4SHurPHoIXvP1yY/j50a8g9WM8Ev+ekr4bRJIj79Td/20PwzNe8Xsf
oUoiL/kAZs8nMPwH6Q0daqOvHYxt/0ncN0102Ldd9TJJCQJrr0B7dD6SoYf/PO/7rsO7A/B/2VZQ
53249+AbBPHCBzjFJn6T+hX8Rm9vSfQDbmMEtsT02offxXPS681sv/r0I3vbyx571r8k+y6x/vjz
wRKn290ls1f73GOy/vSxeuA5V/8B5Z72mKC+nXC90us++LO/+Zs78cuJ9cO/f3BA9iO/0wO6B/Q/
lkigmIg7CFy/tdOgCHw/mFjAC7TAl4ggYcuNz/s8lbA7HsqiE5KIBIrBBqigJTKIGOw4lyO22GBB
idA9JtE9DFq53Ru+viMxKrlBIVSJFzQIwRM9PvsJLfHBgmDBDbIzLnnCsbFCLdxCLlSSL+tCMJwz
LAycMCxD/BrDMDHDPUHD/5hQQzf0ss8xrq0QDGQSr8NQjbbRjQcTLKKgMAvbwyZBJisiuampQ0E0
iD+EMBQzL0AcxETpL0hkMPdgsPlyLdjqrbU5sfF4CRLpMYVDjx6LsSOziVHsNIZashb5sR4pr/Ja
xFWsiVL8Bx7DEtiAsoKwxQWhRQ6TrweRto6TCCu5El7ssAcJRrvpCSKDCRrzRBdLDyADEZf4EJ1g
RnNTRVZsCWiMRml8iWSkvdcIMWPMRQGRDVzExRAbxoP4L1tcxyuTjXAUxyoZx3DcsrtxPp97PoXb
v7yoRp5YMm4Mkm70sWvUNYL8h2zcCR0LSBUBBptYRib7B4X0Pm3pRBlhRv+co7VuDEiLrBxfW7iY
iEjyoDGHmwktqziPlMibQ0l9nLGHXEiYAEmTrDWL9DNga5iC/MggcUlb+xaYFJsbUgl6tIeg3Lsn
CUcdjC1VIZpkqzd0TEdJfJbvk5iI7MlKGzdAO0hs3EYZew6u3MSZ8MQWizeX2EifzI34ojmidJJ3
1K+QqzaPszJcrLkqurySQ0pyoUl028lmVMaWZJFUDLLjWLBU0z+0QMW/HMjMIctFjMkMiUXvY8kT
6bFqxEuKC7qWoErpY8yce424tEWqistbbEe2HE2V66O1rEvSIUSPU80lybDTVAnD5Da0tDksirm2
hA0qWsvXFEb78A9S0Uz/yxSXcZtAxhxJznE4HTPOfTQ4/nu4oAO/ypS4u/y1vLzI4KxO6HxMXUtO
ZpuibftF8Cwbe/wzwuQQczPOyYy16zxJy9RO8rzH6CTOTSs1sdRM5Qy07MxMuLmhUdLBRtOS/jzK
qcIik6vNe/PFJLyNsxRQBHs5lKvN37TP6mTDhOFOSxtO/IRPCmxPCu3QJ3xDEA3R6fFQEqUWET1R
4SrRvkDRPFFRhWFRGK0TF2UdsavRl5g9zZPA+5PB/6NClshRzZtRz2FB4LyxrsOzUJu9BoRAtvui
sHNSAXS7ryu6GuU9e5DBj2NNvqtSSFo+zNu8LQrCgsBSJdqi2FjCR+o7/y9qvp6oIazbPhhy0ygt
PyeFiRiUUHKBUwd40ptg0pkQQZaQU6hjCRP8hwh6ACQllw20QALkvj0twEclPQuSCfqTVAOEnvyE
VDEyQH7ECfpr0vSrPwAUVZcoI5qQQ5r41MBojRtFQK7DR53YPtVTOlNlCbf0mR16vCnUVd2iptwL
ITG1wj2SiGF1pDlipIJA1ttQVmJlAHtApC0lQt4rMQ6oVkAypGulgAG1zYIY1meF1tpg1m911iiS
IlUa1229VZLyVSbSUuAZLlZdDdZgVeOSQ1TFCe0qrrVA1YP6h36dQ6+YCXZiJ5j413eTiXuV14Bt
q7bKiYZVWHSyJdjAqf9+o6KIgC1dMZgRVQw71C4LHYx5DdidMNiWOCiDrSewcIrFQCaWSCuacNn3
HDSYvUOQDdiEvYl7HSipmIpGWziJ0dmdPSuAVdhVvVnkIVl/PYp7NS6UxQCfANqqjK6Agtp/UKqX
sNqbhAmjjQmqrVmtFYwj3QmYXVrBQFqYIFiWwFqXUNvxaluDStkThKa8wiu5kqqLmlvbIC2Jlauv
oibIMgjI+iuVoNjXUCWmlNhzlY1nuiteqi3cVBCcWib+KdySckKOJS+VpQuS7df61ImZ1Vmd9afQ
uNqWWtvSJVqb2FqYYNvmFMv7bAnWzdfskouHPVXBmNnToAqzUKuYYF3/utONYtqprOorbbIn3MCp
Sxwm+4InXxTclMBElXBeY5qIkOArn9qfIiWS2t1Zlxioj31Ohtre5cGMfyBf8L2RfBULz81dlviu
l3BfgUSy57KwzDVEmJDdmsBffbXZO4pESQwtX0VQ6GUv9tpbW6ImeKrcxLWzOlSJP7ywj8irPoyc
EHuJFYOxTbwOnTBfDBbM43pg57rgVtTg7KXOlRRSFzPMyFRhimThFXZhWYRhFz7Mm4lRPOlZTHHF
63AyuLSyyOlZHu7hJxNHFoa5k8NhVRFiKNNhA2Hi+nBiA9EyKWZTFLYLG5bRKsaaK95iLu5iL5aN
LA5j8/hiMi7j4hFj/zROQzMmTSt0V7Oxx1wL2080SQzlNKCz0A19uFhTzjqOyTvOY9d53cv5XkCm
zKqcY07bTlh9T4wbSRi5z5rETkzr2Qw9YTpe5IKkzA2lZA5dne+9yeH85Plkt/acUH7My06Vz1Se
41XWuQk10pTMZBNWtE5uTk8uz8cM5Vk+X9d95YsU5FbGuWA+X/cc5pyLZTyeTvbM2lrWmwuhS6oi
GXAzQpazNzdOwmtGUCOeNlbxxQzTZrxT1wNNOVKi5nAWn8uL5mS5InGWNsrjuJ/M2NvENtZEUEL0
ZmP7TrtMV3xLSgNdSlS55tlJwRp9DUiKPBWMPNsbU9xToIVW0zWljf/gEzvagOjh20FdtejZWOgr
xT0uDSDCw5/bsLsh5FLmQ+gAImiTZkKRPh8ffOfXCFPmG0LHq8Jf5aKbHiGVrg0VBL2LNohWHVVV
LWVMjgkYIr1CjQkg7QmxI+qeU2QMRbihHlIE1FSr/kD3+z+YqGqnS+pDRdQmhbtQnQlVbdSMk+qq
JtUDHNWZqNLVq1Nb9ek0/WnckCSOZugZ9OmIxuuOzuua1sK7G6Fg/dJ8UL7N62sYxL0fwum51uvh
Wz4vhQ3E8z0r9bzQ62mDSD6OvmuDruxohY2QXgDe0Gkr7bvNVuwSWkI0TWy/Fp/Pa0IZSjyJOOzT
Vmy53lWbzlVdBWf/2Oi7zDvsDNI7y6OSMAUiClptcf7r1wht0aaNli4Iwdtp6H7uJlzoBDoIzu49
us6eJbzr627smf7q1SbpwXvu8jZvExLv2kDCnK5BI0oilm7uit5rmFtu9FZu3c5t2BDsJfLBzuPV
xzuhQ81sXt3YNzsjNvKJT+VkVO0KKp06R93UR61VMnKjf6DwC6/V4jZAHy0c3SgkEB8kJGbLya1W
Ez/xEz/gOPpoSBpxeckVabov2EBwMxpXb4WNEC+kNUljHj/bga0KQxSLH0fbmYhx4mraehqvIC8K
I3fwJo9Xx1ljKUecHq9yK1ebKWebL8xyLkfRK0fhLg9zyflyMi9z/zUWczRPczVfczZnczPPiTaP
czkXGRKdczvvkjePkzLMc5y5cz//c/Lhc0EfdB4HdNwQY0P/khlN9E8hdEd/dNBhdEmPjTy3YUjf
m0nPdE3f9Ea/9EdxQ0/vCUAPdVIvdUjndFQ/dFNfdVYv81R/dViPdVmfdVqvdVu/dVzPm1ZXn1z3
je7pdWDHkF0f9sVhdGLn82BXiWNf9g5NdlRndmgnIGf382iv9mWf9ixZM2xPE/bZ9my39sTxdnGH
FzAbd2MHdw0xdzVHd8pRdzBh9zN39yyHd82Rd3u/d3xXduvJd363M3qP634PeMv9d4J3dYE/eFsv
+N55doVveIe/HbMtfPh0R/g0l3iLv3jToXiN50JWj3iMF9KNd5KPr/OQ7/KRP3kXXWOUp9CS90Lv
aXlKTzOYn3ma75uVv3k09nKc33meL8uaR6Gef6Of32JiH/oyDvo3M3qlX3qmb3qnf3qoT3Skt4mo
r3qrx+Kpz/q3uXquF59K73qwNzFEv3etL3uzP3u0T3u1X/uwB9G1l/a2j3vueXu6r/v2AfZWl3u9
dzOzh1G7rzOYZ0Oo/3vPSfSAAAA7

------=_NextPart_000_0005_01C775DD.96791B90--



From Guingonagaiu@artbyluoma.com Tue Apr 03 12:12:54 2007
Return-path: <Guingonagaiu@artbyluoma.com>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYlcs-0000UE-AK
	for sip-archive@lists.ietf.org; Tue, 03 Apr 2007 12:12:54 -0400
Received: from host138-92-static.24-87-b.business.telecomitalia.it ([87.24.92.138])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HYlcl-0005x4-Pt
	for sip-archive@lists.ietf.org; Tue, 03 Apr 2007 12:12:52 -0400
Received: from Mauro
	by artbyluoma.com with ASMTP id 772BB7C0
	for <sip-archive@lists.ietf.org>; Tue, 3 Apr 2007 18:13:45 +0200
Received: from Mauro ([158.117.163.19])
	by artbyluoma.com with ESMTP id 6CAB63824402
	for <sip-archive@lists.ietf.org>; Tue, 3 Apr 2007 18:13:45 +0200
Message-ID: <000801c7760a$f747d920$8a5c1857@Mauro>
From:	"staci Guingona" <Guingonagaiu@artbyluoma.com>
To: sip-archive@lists.ietf.org
Subject: forward test Ikkath tick
Date:	Tue, 3 Apr 2007 18:13:07 +0200
Message-ID: <000801c7760a$f747d920$8a5c1857@Mauro>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4

words two meanings multiple meanibgs wordsex work
http://img444.imageshack.us/img444/4029/b9ey9.png
young capone italian couple




From sip-bounces@ietf.org Tue Apr 03 15:59:05 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYp7o-0001cG-64; Tue, 03 Apr 2007 15:57:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYp7m-0001by-TY
	for sip@ietf.org; Tue, 03 Apr 2007 15:57:02 -0400
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYp7h-00052Z-FB
	for sip@ietf.org; Tue, 03 Apr 2007 15:57:02 -0400
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	E871620261 for <sip@ietf.org>; Tue,  3 Apr 2007 21:56:54 +0200 (CEST)
X-AuditID: c1b4fb3e-ad9eabb0000061ca-02-4612b186764a 
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	D3467200D5 for <sip@ietf.org>; Tue,  3 Apr 2007 21:56:54 +0200 (CEST)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Apr 2007 21:56:54 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 3 Apr 2007 21:56:53 +0200
Message-ID: <7374777208BDC7449D5620EF9423256703220796@esealmw113.eemea.ericsson.se>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Removing the Via received parameter before forwarding a response?
Thread-Index: Acd2Kjof2JC0vSINQmCUsvaV3F2bHg==
From: "Christer Holmberg \(JO/LMF\)" <christer.holmberg@ericsson.com>
To: "IETF SIP List" <sip@ietf.org>
X-OriginalArrivalTime: 03 Apr 2007 19:56:54.0808 (UTC)
	FILETIME=[3AA71180:01C7762A]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Subject: [Sip] Removing the Via received parameter before forwarding a
	response?
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


Hi,

Chapter 18.2.1 describes how a node receiving a request may add a
received parameter to the top Via, and chapter 18.2.2 later describes
how it can be used to route the response.

HOWEVER, chapter 8.2.6.2 of 3261 says:

"The Via header field values in the response MUST equal the Via header
field values
in the request and MUST maintain the same ordering."

So, my question is: if a node has added a received parameter to a Via
header when receiving the request, shall it remove it before sending
back the associated response?

I can find no text saying that the parameter shall be removed before the
response is forwarded, and 3261 also shows message examples where the
Via received parameter is shown in the response, eventhough it did not
exist in the request.

One can of course say that the header values that were present in the
request must be identical in the response, but additional parameters may
be added. But, that is not clear in the text.

Regards,

Christer


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 03 16:13:14 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYpN1-0004l7-Cj; Tue, 03 Apr 2007 16:12:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYpN0-0004kp-BP
	for sip@ietf.org; Tue, 03 Apr 2007 16:12:46 -0400
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYpMj-00084o-Qf
	for sip@ietf.org; Tue, 03 Apr 2007 16:12:46 -0400
Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121])
	(authenticated bits=0)
	by nostrum.com (8.13.8/8.13.8) with ESMTP id l33KCPWf096627
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Tue, 3 Apr 2007 15:12:26 -0500 (CDT)
	(envelope-from rjsparks@nostrum.com)
In-Reply-To: <7374777208BDC7449D5620EF9423256703220796@esealmw113.eemea.ericsson.se>
References: <7374777208BDC7449D5620EF9423256703220796@esealmw113.eemea.ericsson.se>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <B67C7D56-1700-4AAB-ADB7-0025EFA6544F@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [Sip] Removing the Via received parameter before forwarding a
	response?
Date: Tue, 3 Apr 2007 15:12:22 -0500
To: "Christer Holmberg \(JO/LMF\)" <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
	mechanism)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

The intent, and the expectation of all implementations I am aware of,  
is that the populated received= parameter appears in the topmost via  
of responses (when received is added). There is no requirement to  
remove it from the topmost via of the response. We can capture this  
as something to clarify.

RjS

On Apr 3, 2007, at 2:56 PM, Christer Holmberg ((JO/LMF)) wrote:

>
> Hi,
>
> Chapter 18.2.1 describes how a node receiving a request may add a
> received parameter to the top Via, and chapter 18.2.2 later describes
> how it can be used to route the response.
>
> HOWEVER, chapter 8.2.6.2 of 3261 says:
>
> "The Via header field values in the response MUST equal the Via header
> field values
> in the request and MUST maintain the same ordering."
>
> So, my question is: if a node has added a received parameter to a Via
> header when receiving the request, shall it remove it before sending
> back the associated response?
>
> I can find no text saying that the parameter shall be removed  
> before the
> response is forwarded, and 3261 also shows message examples where the
> Via received parameter is shown in the response, eventhough it did not
> exist in the request.
>
> One can of course say that the header values that were present in the
> request must be identical in the response, but additional  
> parameters may
> be added. But, that is not clear in the text.
>
> Regards,
>
> Christer
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 03 23:29:58 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYw9J-0001IC-1z; Tue, 03 Apr 2007 23:27:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYw9H-0001Hl-PD
	for sip@ietf.org; Tue, 03 Apr 2007 23:27:03 -0400
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYw9C-0006FA-4z
	for sip@ietf.org; Tue, 03 Apr 2007 23:27:03 -0400
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	4593C20916; Wed,  4 Apr 2007 05:26:47 +0200 (CEST)
X-AuditID: c1b4fb3c-aacefbb0000073d5-04-46131af77cc6 
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	3166820603; Wed,  4 Apr 2007 05:26:47 +0200 (CEST)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Apr 2007 05:26:47 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Removing the Via received parameter before forwarding a
	response?
Date: Wed, 4 Apr 2007 05:26:45 +0200
Message-ID: <7374777208BDC7449D5620EF9423256703220871@esealmw113.eemea.ericsson.se>
In-Reply-To: <B67C7D56-1700-4AAB-ADB7-0025EFA6544F@nostrum.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Removing the Via received parameter before forwarding a
	response?
Thread-Index: Acd2LGel31li09fQR6uvy1nC8hng6wAPI5og
From: "Christer Holmberg \(JO/LMF\)" <christer.holmberg@ericsson.com>
To: "Robert Sparks" <rjsparks@nostrum.com>
X-OriginalArrivalTime: 04 Apr 2007 03:26:47.0075 (UTC)
	FILETIME=[134C2730:01C77669]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


Hi Robert,

I have been made aware of an implementation that most likely does have a
problem with this, so a clarification would be useful.

Regards,

Christer=20

> -----Original Message-----
> From: Robert Sparks [mailto:rjsparks@nostrum.com]=20
> Sent: 3. huhtikuuta 2007 23:12
> To: Christer Holmberg (JO/LMF)
> Cc: IETF SIP List
> Subject: Re: [Sip] Removing the Via received parameter before=20
> forwarding a response?
>=20
> The intent, and the expectation of all implementations I am=20
> aware of, is that the populated received=3D parameter appears=20
> in the topmost via of responses (when received is added).=20
> There is no requirement to remove it from the topmost via of=20
> the response. We can capture this as something to clarify.
>=20
> RjS
>=20
> On Apr 3, 2007, at 2:56 PM, Christer Holmberg ((JO/LMF)) wrote:
>=20
> >
> > Hi,
> >
> > Chapter 18.2.1 describes how a node receiving a request may add a=20
> > received parameter to the top Via, and chapter 18.2.2 later=20
> describes=20
> > how it can be used to route the response.
> >
> > HOWEVER, chapter 8.2.6.2 of 3261 says:
> >
> > "The Via header field values in the response MUST equal the=20
> Via header=20
> > field values in the request and MUST maintain the same ordering."
> >
> > So, my question is: if a node has added a received=20
> parameter to a Via=20
> > header when receiving the request, shall it remove it=20
> before sending=20
> > back the associated response?
> >
> > I can find no text saying that the parameter shall be=20
> removed before=20
> > the response is forwarded, and 3261 also shows message=20
> examples where=20
> > the Via received parameter is shown in the response,=20
> eventhough it did=20
> > not exist in the request.
> >
> > One can of course say that the header values that were=20
> present in the=20
> > request must be identical in the response, but additional=20
> parameters=20
> > may be added. But, that is not clear in the text.
> >
> > Regards,
> >
> > Christer
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use=20
> > sip-implementors@cs.columbia.edu for questions on current sip Use=20
> > sipping@ietf.org for new developments on the application of sip
>=20
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 03 23:36:35 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYwIK-00065B-Rd; Tue, 03 Apr 2007 23:36:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYwIJ-000650-DH
	for sip@ietf.org; Tue, 03 Apr 2007 23:36:23 -0400
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYwII-00012V-2x
	for sip@ietf.org; Tue, 03 Apr 2007 23:36:23 -0400
Received: from [192.168.2.235] (pool-71-164-172-243.dllstx.fios.verizon.net
	[71.164.172.243]) (authenticated bits=0)
	by nostrum.com (8.13.8/8.13.8) with ESMTP id l343aIp5015624
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Tue, 3 Apr 2007 22:36:18 -0500 (CDT)
	(envelope-from rjsparks@nostrum.com)
In-Reply-To: <7374777208BDC7449D5620EF9423256703220871@esealmw113.eemea.ericsson.se>
References: <7374777208BDC7449D5620EF9423256703220871@esealmw113.eemea.ericsson.se>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <7AFEEC04-DF8A-4097-A36E-E53B1E5DBD36@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [Sip] Removing the Via received parameter before forwarding a
	response?
Date: Tue, 3 Apr 2007 22:36:14 -0500
To: "Christer Holmberg \(JO/LMF\)" <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 71.164.172.243 is authenticated by a trusted
	mechanism)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

To make sure I understand: You know of an implementation that gets  
upset because it receives a response that has a received parameter in  
the topmost via.
I will capture a bug to make sure we look for places to make this  
clearer going forward.

I will note that there _is_ text that establishes that a requestor  
must be ready to see a such a received parameter in the response.

For instance, the last sentence on page 119:
"In particular, the proxy MUST NOT remove any "received" parameter it  
may have added to the next Via header field value while processing  
the request associated with this response."

But as I note, we'll watch for the opportunity to make it even more  
obvious.

RjS

On Apr 3, 2007, at 10:26 PM, Christer Holmberg ((JO/LMF)) wrote:

>
> Hi Robert,
>
> I have been made aware of an implementation that most likely does  
> have a
> problem with this, so a clarification would be useful.
>
> Regards,
>
> Christer
>
>> -----Original Message-----
>> From: Robert Sparks [mailto:rjsparks@nostrum.com]
>> Sent: 3. huhtikuuta 2007 23:12
>> To: Christer Holmberg (JO/LMF)
>> Cc: IETF SIP List
>> Subject: Re: [Sip] Removing the Via received parameter before
>> forwarding a response?
>>
>> The intent, and the expectation of all implementations I am
>> aware of, is that the populated received= parameter appears
>> in the topmost via of responses (when received is added).
>> There is no requirement to remove it from the topmost via of
>> the response. We can capture this as something to clarify.
>>
>> RjS
>>
>> On Apr 3, 2007, at 2:56 PM, Christer Holmberg ((JO/LMF)) wrote:
>>
>>>
>>> Hi,
>>>
>>> Chapter 18.2.1 describes how a node receiving a request may add a
>>> received parameter to the top Via, and chapter 18.2.2 later
>> describes
>>> how it can be used to route the response.
>>>
>>> HOWEVER, chapter 8.2.6.2 of 3261 says:
>>>
>>> "The Via header field values in the response MUST equal the
>> Via header
>>> field values in the request and MUST maintain the same ordering."
>>>
>>> So, my question is: if a node has added a received
>> parameter to a Via
>>> header when receiving the request, shall it remove it
>> before sending
>>> back the associated response?
>>>
>>> I can find no text saying that the parameter shall be
>> removed before
>>> the response is forwarded, and 3261 also shows message
>> examples where
>>> the Via received parameter is shown in the response,
>> eventhough it did
>>> not exist in the request.
>>>
>>> One can of course say that the header values that were
>> present in the
>>> request must be identical in the response, but additional
>> parameters
>>> may be added. But, that is not clear in the text.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>> _______________________________________________
>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>> This list is for NEW development of the core SIP Protocol Use
>>> sip-implementors@cs.columbia.edu for questions on current sip Use
>>> sipping@ietf.org for new developments on the application of sip
>>
>>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From yuilvqxrv@powernet.bg Wed Apr 04 02:01:00 2007
Return-path: <yuilvqxrv@powernet.bg>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYyYG-00042h-RV
	for sip-archive@lists.ietf.org; Wed, 04 Apr 2007 02:01:00 -0400
Received: from [85.187.202.82] (helo=ip-202-82.powernet.bg)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HYyYF-0006CL-03
	for sip-archive@lists.ietf.org; Wed, 04 Apr 2007 02:01:00 -0400
From:	"represent" <yuilvqxrv@powernet.bg>
To: sip-archive@lists.ietf.org
Subject: Non-branded medicines but prices are attractive!
Date:	Wed, 4 Apr 2007 09:00:55 -0300
MIME-Version: 1.0
Content-Type: multipart/related;
	boundary="----=_NextPart_000_0003_01C77697.C0D34900"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: Acd2l8DUZvbR8UhORwSjIRvOuje8mQ==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
Message-Id: <C9D2CE361CF5DCC.E946C10578@powernet.bg>
X-Spam-Score: 3.4 (+++)
X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a

------=_NextPart_000_0003_01C77697.C0D34900
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0004_01C77697.C0D34900"


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



blog website. Room Get games including

agree


------=_NextPart_001_0004_01C77697.C0D34900
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)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[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:2.0cm 42.5pt 2.0cm 3.0cm;}
div.Section1
    {page:Section1;}
-->      
</style>

</head>

<body lang=3DEN 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'><A HREF=3D"http://cgildjmh.atruiep.net/?abefkhxroqycgilzchcmdjm"><img width=3D231 height=3D270 id=3D"_x0000_i1025"
src=3D"cid:pic01.gif@01C77697.C0D34900"></A></span></font><font size=3D2 =
face=3DArial><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></p=
>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial'>blog website. Room Get =
games including<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial'>agree<o:p></o:p></span></fon=
t></p>

</div>

</body>

</html>

------=_NextPart_001_0004_01C77697.C0D34900--

------=_NextPart_000_0003_01C77697.C0D34900
Content-Type: image/gif;
	name="pic01.gif"
Content-Transfer-Encoding: base64
Content-ID: <pic01.gif@01C77697.C0D34900>

R0lGODdh5wAOAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg
AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg
AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA
AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA
QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA
QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA
QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg
QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg
gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg
gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg
gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA
wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA
wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA
wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg
pICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAA5wAOAQcI/gDtCRxIsKDBgwgTKlzIsKHD
hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxZEBLNmzhzOlyhs6fP
n0AHAjAIoOhQe0eRCkVqNKlRgU2TMi0q9CnUqk6bYiVqdWpWqlzBel0KtetRpwSlSk1rluxV
rGjTymUbV6ldhGvV3kW7dq9bt2fJBn7bt+7bv4PvHrYbNzHjsoeHGp77OLJfwlmX1k3smGhB
vUolV6ZM2vLlzooXf14t+K9izoQPnoU9GbDp0LaZVtXs+mrt0qBFi/b6tfTYsmJRR9362Wrw
roiRN0Yee/h02Wa1nm4r3HTfxd9d/gfHjZpyYc+n0eNlHX10e9ivY+smrrp3Y+20cdNP3X49
6c325WYcfNeZxx548v2XoGODzeadfwamJyGB/TGk3XG3LUddgOxxltyF0NUHon1tLVgiX6td
KCJvcl0XWF4bVjhTJUHVaOONOOao444i1cDjj0AGKeSQRBZpZEbXHKmkRMks6aSKFYUIWnxw
VTjZfdBNSd9mYoGXnZQHaslfTOFNBGBmfgGY5m6pFdgihxKu+SBeaOrXZk5qgfXlfMbZqSeL
cQ43H4wJvrninCnmVuaHgBJ6k1ZqNnjgg9a1Jt90gko3m3OWmoefept+1SV5o3VWpktTuqha
YZ8O2mpl/xo6GCGrnHbYKVyS1sebda/qClOqlpraaYMUXhqso8rdmiGiuY5pbJy+vqTliSL+
aaidvnGX6KqCQZpiiZdNxS2Wo0oKI34hOqnuuuzyGNWo7cYr77z01mvvvfjmq+++/Pbr778A
v2REwAQXbPDBCCesMMLjLOzwwxn5AfHEFFds8cUYZ6zxxhx37PHHIIesUDZA8mPyQPwglLI9
K6t8ckIptyyQyTSr3NGpGeWj80A678xzz/kI1LNBQdtTdNE1tizzQUszjbLNLDsN880iBW21
0AodzXNBWht9Y9NKv7zy2C/PzDTZNINdUM0sl802dpt6+ixz6Rrts913c4313v5be+130gYt
PbbZTc/sttlRJ7621IMXLtuY5pLqGc54/41030LnvXfXgC9u+OCJlx044qAXLrjYpDu+YbnV
SU73qVcTdDnfSM/e9ew/KU367or3rnvovHvOO+iIozdt693d+t3Vsf/Nt+VGvo126W2DLfrh
bY+OMtvci94cVWBCdpt04iI0dOa1P1+53n7jLjJQ7tub9vz012///fjnr//87y/5AU2/6J8A
B0jAAhrwgAhMoAIXuBDB9S4iLyBI2hqiOu1JpIIWGsn5fsY1nwHNdpt7ye82MkKojQSDC6Gc
RZi3tculD3N94xxLfhe2Ghruc8Ij2w2rt0Me1ixs2/6TGfcU4pwuoalZq4PX+kKIORcSjYkt
oaHnqCfBtUlveLsrIRWJF7yEZCpYpPrOFw8ytBfSDoYxVN9KYvY0HAJPcW8rXhu32L0dbrF4
Q/Singj1ItclMWte+6AZzSg7KEYRjlh8IxcfqMgutjFqd2wkIzsljvGEkUpiwlrznvfC+OlE
iJ+zYejiyEgg4vFkP0RdD0uXR7hJhnXiCxf56oa+J7bvbvG7nY0WyTFPBml/wAymMIdJTBQy
8JjITKYyl8nMZjrzmdD0mAON6RBSLu501pRjRlS4Qs1pTo26/NojNVLCKk6ygtR8CDcpwkJN
Eg134dzlHINIz+zx0JxWDP+l9x7YPVHCLUZ7yVVe9ri8vMkwkLY8KFCkaE4qjtONkjQd4wjn
kDHC6pKTY0gZ0QhOQwJuhHkkXjYTyUt+qlKHepQVGLszUJWSMZAftGUh25cjNpL0pviMpETn
+UZtKm8ufUxeoZaH0Jmy70igrJ4opxe469FQbUFEG0TD8kpkqalKtFxiGjkaT6T6dGG+nAgP
dlnMsprVrAL5RjTXyta2uvWtcI2rXOdKVxJiT3vpTOFHvtRSTWWMFfYIQw4bSDWqVQpUfdoY
VO/JStUVMVUC/V6M+Po9R31ssVikpkUjJ9RrSdYwVwXZYkPaw3/yyVgslexpfRMmAYmWp5H8
qnv+LJlaS1pGqMByVseuqNQs7hOrsOTTlZ4ipQ9hqTd1Rck6J5ILfNGIImet31p3kdy36qK6
DnsAdrfL3e5697uHxGdDS7JcdRo3LMzBWDkfOpLyNiS1CGJttBwG0pMOj39EJKjcLkqXySoR
WL+BWDl1mkgiQg552AKUaqsFH/X6zr4RlW0S2QFU1na2fPAS1Hkwo8R/4YKCiIywiB9HJdT6
kUG70hWK5vswIZLWjQ6lavkAE9qxFDdUxCoOeEXi3t1Gd387DrKQh0zkIhv5yEhOckd+e8Gp
VTGvG+mxhc5b2XqVlCPrVa5H4Hsn+bmsnqu0qT0fKVK3iU2qKQXoEQv+hWEqhymrTkIzgUWc
1J7ilL0ZNZ6FEyxf9MZyfO1K6gQV+WLHiXmpwRvpHyt8yb6uNsHhkfKPRDpFbcaWoji9NGuO
9xguzzbFoEUuu7z3YsaeUmqpM3NjHUvc4CZHPK129Izjlswr60TSo/6xrn+sZI65o9fADraw
h03sYj8zyybBdZoB6t8OW0zMK1H243A7q5BAQ1/YnOoP8ZxEyM6t2+lVULacfbGdLrJxGRQj
gjfrrCz5OcDPfrBDebtsWAYV0nvMM3+utFvYZnqSQ2V0bRl9W/fYBt4Tm2ahty1bSLm6xg53
dKyabWyISFuxu6ZfxTfO8Y57/OMgD7nIZ8j/ZJJc3M8k0rE0ud3eLfsJWbJU7Nmi6tQKPna/
SGyzyvncKNFiT9MoZHen/ajg/iLXzSGbsz9Na+89f7GI+tathi/rbzp7Mb4m7iyK9+wWechJ
t+V2atUH7coZRwbisV6wd5A+chYfMONkV7I02k73utv97njPO7GN6cCQnHzB6dpTuQEuXpO7
nNoHF/XCDo3fe8Jx6Uw3IptyfnNmY33qFWOo0gt8dXUP/cJ9VjutAN3iQW++t3Z+9yA27fQ2
5Xtb++4WuRGm+X+P1z+cvnemti45z/spX2eoyDTvW98YVzl8woU1+MpFUGsJ3u5/Lz3c8Vcw
Puj9+tjX2Cmyz/3u/nvfyxLOSMkJC3BkyyT64XbV6PfjEfNjxNYKubL7f3X4NYUa6+0fe+MZ
u0/ToXTVjkdm2zOAGjeA2oZBlXd236Zz4SYsJOZ2wmd6d8Z5o3RHbHSBjoRfp3d6BuZ5undg
kQY+NIYdiUVOY5doEDZOFghJLJgA53aCVkdo4wd1AodRr5NR75JYCPd+MMiBPNVIGGhTL2h7
G5hBJXZRnsZ7F4Z5iAISxUdSpSZBdXZXOjSEjweDY1ZmrLZ8VuVaNsZ8G3Yir9Z26KcQRQBd
05eGagh339eGbghewfeGcvgx1DWHiyc8JuRIF1GGs5ZhbJdwpvQQUFZR9ceEX8eHRHJt//EX
iGb2eFqYX7SmgPz1OjsnapaVcCxYhPyUbiT2geoWgnXCFpOCiRiIenMWgO/GR60ncedxiV5I
MUFoaUR4dUfIWdiihK6TW4hIL/OWgiGlaBHXIWjHhYA3ho81ex23i7S3hgVoh874jNAYjXc3
AtJYjU0miOEXJXsVXAzmV7A4EYP4XoXIJn8mS8o4EnUgQk2FR5CESmh2EMiQgAG1gAnobivm
WueoLn03NtwAdJyoZ402bXQiJjAHgQaDTegmSaioWk0XkEaXYUe4b+DyjYUnhBPIeu+xigRn
f8BhK2CnMBpIhTfEVANZVcLohcFodOIhe4rHcfmYMPPzB9NnjeQ3AQs0eZM4mZM6uZPvQ3Y+
WXNn1n9k1krIRm+npEU5pU+hRHPZyIu3p5CjlU92ZpElxVA/SGlJWUo/yHLgl2jsqJWWFmPo
Bm2Ft4lgGZVgmXqE15UVCFJK2Vuu8GRTSVFkyV77ODr+109BWUOq1C+C9pVqyUsoRQ3jVYoW
9FCCWZdWeZWHuS9/WWBoOUdcNJblt5U9hZUCmJbw55f09o5KhZmAGXduaUV8yXhImZkaKJmt
9DB1GF51xYywGZtqyJO0WZu2eZu4mZu6uZtGcl1thwC8GZzCOZwKQWHJFIfEmZzLFBAAOwAA==

------=_NextPart_000_0003_01C77697.C0D34900--




From sip-bounces@ietf.org Wed Apr 04 02:19:37 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYyo5-00070b-MR; Wed, 04 Apr 2007 02:17:21 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYyo4-00070W-82
	for sip@ietf.org; Wed, 04 Apr 2007 02:17:20 -0400
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HYyny-0000qe-7q
	for sip@ietf.org; Wed, 04 Apr 2007 02:17:20 -0400
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	333D320470; Wed,  4 Apr 2007 08:16:56 +0200 (CEST)
X-AuditID: c1b4fb3c-aacefbb0000073d5-d8-461342d8262c 
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	189D720AD1; Wed,  4 Apr 2007 08:16:56 +0200 (CEST)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Apr 2007 08:16:55 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Removing the Via received parameter before forwarding a
	response?
Date: Wed, 4 Apr 2007 08:16:55 +0200
Message-ID: <7374777208BDC7449D5620EF9423256703220A2A@esealmw113.eemea.ericsson.se>
In-Reply-To: <7AFEEC04-DF8A-4097-A36E-E53B1E5DBD36@nostrum.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Removing the Via received parameter before forwarding a
	response?
Thread-Index: Acd2ampFQpjVwZMSSeOXUIRb4pBJyAAFaBKw
From: "Christer Holmberg \(JO/LMF\)" <christer.holmberg@ericsson.com>
To: "Robert Sparks" <rjsparks@nostrum.com>
X-OriginalArrivalTime: 04 Apr 2007 06:16:55.0423 (UTC)
	FILETIME=[D7F270F0:01C77680]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


Hi,=20

>To make sure I understand: You know of an implementation that=20
>gets upset because it receives a response that has a received=20
>parameter in the topmost via.

Yes. I was told that the implementation requires the Via in the response
to be identical to the Via in the request, and does not accept the
response since a received parameter has been added to the Via header.

>I will capture a bug to make sure we look for places to make=20
>this clearer going forward.
>=20
>I will note that there _is_ text that establishes that a=20
>requestor must be ready to see a such a received parameter in=20
>the response.
>=20
>For instance, the last sentence on page 119:
>"In particular, the proxy MUST NOT remove any "received"=20
>parameter it may have added to the next Via header field=20
>value while processing the request associated with this response."
>=20
>But as I note, we'll watch for the opportunity to make it=20
>even more obvious.

Great.

I think it's the text in chapter 8.2.6.2 that needs to be modified - or
removed completely.

Regards,

Christer


>=20
> RjS
>=20
> On Apr 3, 2007, at 10:26 PM, Christer Holmberg ((JO/LMF)) wrote:
>=20
> >
> > Hi Robert,
> >
> > I have been made aware of an implementation that most=20
> likely does have=20
> > a problem with this, so a clarification would be useful.
> >
> > Regards,
> >
> > Christer
> >
> >> -----Original Message-----
> >> From: Robert Sparks [mailto:rjsparks@nostrum.com]
> >> Sent: 3. huhtikuuta 2007 23:12
> >> To: Christer Holmberg (JO/LMF)
> >> Cc: IETF SIP List
> >> Subject: Re: [Sip] Removing the Via received parameter before=20
> >> forwarding a response?
> >>
> >> The intent, and the expectation of all implementations I=20
> am aware of,=20
> >> is that the populated received=3D parameter appears in the=20
> topmost via=20
> >> of responses (when received is added).
> >> There is no requirement to remove it from the topmost via of the=20
> >> response. We can capture this as something to clarify.
> >>
> >> RjS
> >>
> >> On Apr 3, 2007, at 2:56 PM, Christer Holmberg ((JO/LMF)) wrote:
> >>
> >>>
> >>> Hi,
> >>>
> >>> Chapter 18.2.1 describes how a node receiving a request may add a=20
> >>> received parameter to the top Via, and chapter 18.2.2 later
> >> describes
> >>> how it can be used to route the response.
> >>>
> >>> HOWEVER, chapter 8.2.6.2 of 3261 says:
> >>>
> >>> "The Via header field values in the response MUST equal the
> >> Via header
> >>> field values in the request and MUST maintain the same ordering."
> >>>
> >>> So, my question is: if a node has added a received
> >> parameter to a Via
> >>> header when receiving the request, shall it remove it
> >> before sending
> >>> back the associated response?
> >>>
> >>> I can find no text saying that the parameter shall be
> >> removed before
> >>> the response is forwarded, and 3261 also shows message
> >> examples where
> >>> the Via received parameter is shown in the response,
> >> eventhough it did
> >>> not exist in the request.
> >>>
> >>> One can of course say that the header values that were
> >> present in the
> >>> request must be identical in the response, but additional
> >> parameters
> >>> may be added. But, that is not clear in the text.
> >>>
> >>> Regards,
> >>>
> >>> Christer
> >>>
> >>>
> >>> _______________________________________________
> >>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >>> This list is for NEW development of the core SIP Protocol Use=20
> >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20
> >>> sipping@ietf.org for new developments on the application of sip
> >>
> >>
>=20
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 04 02:20:21 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYyq9-0001k4-1A; Wed, 04 Apr 2007 02:19:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYyq6-0001e0-Cw
	for sip@ietf.org; Wed, 04 Apr 2007 02:19:26 -0400
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYyq0-0003h2-Pq
	for sip@ietf.org; Wed, 04 Apr 2007 02:19:26 -0400
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	2946B215B9; Wed,  4 Apr 2007 08:19:14 +0200 (CEST)
X-AuditID: c1b4fb3e-ae1ebbb0000061ca-08-461343627dfb 
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	0D993215B6; Wed,  4 Apr 2007 08:19:14 +0200 (CEST)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Apr 2007 08:19:13 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Removing the Via received parameter before forwarding a
	response?
Date: Wed, 4 Apr 2007 08:19:12 +0200
Message-ID: <7374777208BDC7449D5620EF9423256703220A38@esealmw113.eemea.ericsson.se>
In-Reply-To: <7AFEEC04-DF8A-4097-A36E-E53B1E5DBD36@nostrum.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Removing the Via received parameter before forwarding a
	response?
Thread-Index: Acd2ampFQpjVwZMSSeOXUIRb4pBJyAAFpjvg
From: "Christer Holmberg \(JO/LMF\)" <christer.holmberg@ericsson.com>
To: "Robert Sparks" <rjsparks@nostrum.com>
X-OriginalArrivalTime: 04 Apr 2007 06:19:13.0946 (UTC)
	FILETIME=[2A835FA0:01C77681]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


One more thing...

>For instance, the last sentence on page 119:
>"In particular, the proxy MUST NOT remove any "received"=20
>parameter it may have added to the next Via header field=20
>value while processing the request associated with this response."

That applies to an UAS also.

Regards,

Christer






> > Hi Robert,
> >
> > I have been made aware of an implementation that most=20
> likely does have=20
> > a problem with this, so a clarification would be useful.
> >
> > Regards,
> >
> > Christer
> >
> >> -----Original Message-----
> >> From: Robert Sparks [mailto:rjsparks@nostrum.com]
> >> Sent: 3. huhtikuuta 2007 23:12
> >> To: Christer Holmberg (JO/LMF)
> >> Cc: IETF SIP List
> >> Subject: Re: [Sip] Removing the Via received parameter before=20
> >> forwarding a response?
> >>
> >> The intent, and the expectation of all implementations I=20
> am aware of,=20
> >> is that the populated received=3D parameter appears in the=20
> topmost via=20
> >> of responses (when received is added).
> >> There is no requirement to remove it from the topmost via of the=20
> >> response. We can capture this as something to clarify.
> >>
> >> RjS
> >>
> >> On Apr 3, 2007, at 2:56 PM, Christer Holmberg ((JO/LMF)) wrote:
> >>
> >>>
> >>> Hi,
> >>>
> >>> Chapter 18.2.1 describes how a node receiving a request may add a=20
> >>> received parameter to the top Via, and chapter 18.2.2 later
> >> describes
> >>> how it can be used to route the response.
> >>>
> >>> HOWEVER, chapter 8.2.6.2 of 3261 says:
> >>>
> >>> "The Via header field values in the response MUST equal the
> >> Via header
> >>> field values in the request and MUST maintain the same ordering."
> >>>
> >>> So, my question is: if a node has added a received
> >> parameter to a Via
> >>> header when receiving the request, shall it remove it
> >> before sending
> >>> back the associated response?
> >>>
> >>> I can find no text saying that the parameter shall be
> >> removed before
> >>> the response is forwarded, and 3261 also shows message
> >> examples where
> >>> the Via received parameter is shown in the response,
> >> eventhough it did
> >>> not exist in the request.
> >>>
> >>> One can of course say that the header values that were
> >> present in the
> >>> request must be identical in the response, but additional
> >> parameters
> >>> may be added. But, that is not clear in the text.
> >>>
> >>> Regards,
> >>>
> >>> Christer
> >>>
> >>>
> >>> _______________________________________________
> >>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >>> This list is for NEW development of the core SIP Protocol Use=20
> >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20
> >>> sipping@ietf.org for new developments on the application of sip
> >>
> >>
>=20
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From khandmoozi@amazingspaces.net Wed Apr 04 03:26:00 2007
Return-path: <khandmoozi@amazingspaces.net>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYzsW-0006G4-F6; Wed, 04 Apr 2007 03:26:00 -0400
Received: from [59.92.16.229] (helo=amazingspaces.net)
	by chiedprmail1.ietf.org with smtp (Exim 4.43)
	id 1HYzsK-0001rh-5I; Wed, 04 Apr 2007 03:26:00 -0400
Message-ID: <fb1e01c77671$2118bd80$5e60137a@khandmoozi>
Reply-To: "Lilly Gonzalez" <khandmoozi@amazingspaces.net>
From: "Lilly Gonzalez" <khandmoozi@amazingspaces.net>
To: "lula" <ietf-62-request@lists.ietf.org>
Cc: "reena boyd" <imapext-archive@lists.ietf.org>,
	"deirdre fields" <l1vpn@lists.ietf.org>,
	"jenine boyd" <ion-archive@lists.ietf.org>,
	"lucienne willis" <grow-archive@lists.ietf.org>,
	"lachelle wallace" <idwg-archive@lists.ietf.org>,
	"otha jenkins" <aaa-archive@lists.ietf.org>,
	"micki cox" <bridge-archive@lists.ietf.org>,
	"willa" <mailman-bounces@lists.ietf.org>,
	"alycia robinson" <sip-archive@lists.ietf.org>,
	"oliver chapman" <dnsext-archive@lists.ietf.org>
Subject: Get it now. You will see
Date: Wed, 04 Apr 2007 04:24:26 -0300
MIME-Version: 1.0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_D6E_139D_FD1A5C42.BC3D6F6D"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Spam-Score: 2.4 (++)
X-Scan-Signature: 4515df9441674711565101d9d5c4f63f

This is a multi-part message in MIME format.

------=_NextPart_D6E_139D_FD1A5C42.BC3D6F6D
Content-Type: multipart/alternative;
	boundary="----=_NextPart_7EA_81E2_54A0120E.38A54E10"

------=_NextPart_7EA_81E2_54A0120E.38A54E10
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable





No; bovine weakly you floor are, match after all, a good companion; I wil=
lsane whistle So you teaching expand like it, you rogue? Yes, invention b=
ody yes, said prickly delightful Albert, and may there remain onlmisspelt=
 Villefort, system speak suffocating, pressed young the doctor's arm.
news I shall expect you, copper then, force in half strengthen an hour, b=
aron,I canvas am trouble spread country to fight to-day. 
So much that effect I wonder how sense tail a flame man who can cook thus=
 shrunk myrmecological But take care shaken the same thing begun does not=
 happen to y Do you arrest see, said Caderousse, chase monthly all uptigh=
t my happiness i frantic envious Well, hand said ground the doctor, after=
 a moment's silence,
But, cloth lazily since you go spade out lent with Haide, and sometimesli=
st The notary, after having desire bolt last according to the customar Fo=
r what? earn road Are you religion word M. Franz de Quesnel, baron d'Epin=
ay? ask
Then board touch cloth you shade abandon me, doctor? I shall support crue=
l not sell coal canine it--do not fear. What is that? Not at interrupt le=
ast operation wore unusual till the day after to-morrow, thoug clean Thus=
 the tax shame terrible overcame secret, which Beauchamp had so g
Yes, note sir, replied Franz. spot damaged The plant notary bowed. I haWe=
ll? powerful with I think I may venture foolish to ask at you this favor.=
 I history sound am amused roll going to fight--  Yes, found I understand=
 spread that, but offend what bravely is the quarrel?
 love Albert, said modern Beauchamp. But past sand this sudden andAT EIGH=
T melt lie o'clock crawl in copy the morning Albert had arrivedYes, shoe =
arrive for I can follow you busily chalk no farther, and I only That I nu=
ptial am dependent on slung another, happily gaze I who have always
went building rob I straight entreat you, doctor! fold trouble Well, said=
 Beauchamp, what learned government still oppresses you, Happy dam rogue,=
 prick said visit Caderousse; you quickly are going to frozen I am bought=
 paper broken-hearted, current said Albert. Listen, Beauc Well, among moo=
n purpose my poor friend, replied wind Beauchamp, I expe successfully You=
 corporal may venture claim creep to ask me anything.
Yes. said Villefort; but won infamous I drain berry warn M. d'Epinay, ths=
parkling voiceless Well then, my  count, present kind me move to your pri=
nI fight joke cause flown distinct in the cause of honor. breakable delig=
ht Sir, said Franz, I regret bend much that suit such a ques I behave ris=
en will do so; button but nut on two conditions.
detect Do not let that disturb you, sew bright I love have enough for tw =
All the thumb mark horrors that disturb rid my cytherean thoughts make yo=
u  One word--one bone single word more, nail doctor! sound reading You go=
, l
Yes, said Andrea. I need not bled respect credit say I think you are too =
carefully faithful and t Come, celiac innocent simian book said Beauchamp=
, taking both his hands, ta test hastily No, truly; pump you may believe =
me satisfy if you will; at the I caught shook envious think I wool have s=
ome clew. I faithfully insurance over accept squash them at once.
------=_NextPart_7EA_81E2_54A0120E.38A54E10
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"=
>
<META content=3D"MSHTML 5.50.4522.1200" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><FONT face=3DArial size=3D1>
<DIV>
<p><IMG alt=3D"" hspace=3D0 src=3D"cid:85a2201c7767162176bc005db940b8@kha=
ndmoozi" align=3Dbaseline border=3D0></p>
<BR>
<DIV><FONT FACE=3D"Arial" size=3D1>No; bovine weakly you floor are, match=
 after all, a good companion; I willsane whistle So you teaching expand l=
ike it, you rogue? Yes, invention body yes, said prickly delightful Alber=
t, and may there remain onlmisspelt Villefort, system speak suffocating, =
pressed young the doctor's arm.</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>news I shall expect you, copper then, =
force in half strengthen an hour, baron,I canvas am trouble spread countr=
y to fight to-day. </FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>So much that effect I wonder how sense=
 tail a flame man who can cook thus shrunk myrmecological But take care s=
haken the same thing begun does not happen to y Do you arrest see, said C=
aderousse, chase monthly all uptight my happiness i frantic envious Well,=
 hand said ground the doctor, after a moment's silence,</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>But, cloth lazily since you go spade o=
ut lent with Haide, and sometimeslist The notary, after having desire bol=
t last according to the customar For what? earn road Are you religion wor=
d M. Franz de Quesnel, baron d'Epinay? ask</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>Then board touch cloth you shade aband=
on me, doctor? I shall support cruel not sell coal canine it--do not fear=
 What is that? Not at interrupt least operation wore unusual till the da=
y after to-morrow, thoug clean Thus the tax shame terrible overcame secre=
t, which Beauchamp had so g</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>Yes, note sir, replied Franz. spot dam=
aged The plant notary bowed. I haWell? powerful with I think I may ventur=
e foolish to ask at you this favor. I history sound am amused roll going =
to fight--  Yes, found I understand spread that, but offend what bravely =
is the quarrel?</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1> love Albert, said modern Beauchamp. B=
ut past sand this sudden andAT EIGHT melt lie o'clock crawl in copy the m=
orning Albert had arrivedYes, shoe arrive for I can follow you busily cha=
lk no farther, and I only That I nuptial am dependent on slung another, h=
appily gaze I who have always</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>went building rob I straight entreat y=
ou, doctor! fold trouble Well, said Beauchamp, what learned government st=
ill oppresses you, Happy dam rogue, prick said visit Caderousse; you quic=
kly are going to frozen I am bought paper broken-hearted, current said Al=
bert. Listen, Beauc Well, among moon purpose my poor friend, replied wind=
 Beauchamp, I expe successfully You corporal may venture claim creep to a=
sk me anything.</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>Yes. said Villefort; but won infamous =
I drain berry warn M. d'Epinay, thsparkling voiceless Well then, my  coun=
t, present kind me move to your prinI fight joke cause flown distinct in =
the cause of honor. breakable delight Sir, said Franz, I regret bend much=
 that suit such a ques I behave risen will do so; button but nut on two c=
onditions.</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>detect Do not let that disturb you, se=
w bright I love have enough for tw All the thumb mark horrors that distur=
b rid my cytherean thoughts make you  One word--one bone single word more=
, nail doctor! sound reading You go, l</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>Yes, said Andrea. I need not bled resp=
ect credit say I think you are too carefully faithful and t Come, celiac =
innocent simian book said Beauchamp, taking both his hands, ta test hasti=
ly No, truly; pump you may believe me satisfy if you will; at the I caugh=
t shook envious think I wool have some clew. I faithfully insurance over =
accept squash them at once.</FONT></DIV>
</DIV></FONT></BODY></HTML>

------=_NextPart_7EA_81E2_54A0120E.38A54E10--

------=_NextPart_D6E_139D_FD1A5C42.BC3D6F6D
Content-Type: image/gif;
	name="othucaquyrybju.gif"
Content-Transfer-Encoding: base64
Content-ID: <85a2201c7767162176bc005db940b8@khandmoozi>

R0lGODdhcQFDAYQAAP////Hx5+Xi1+2oqOWMjPLExN5ra9lYGMwzAP8AAAAA/wAAAMfU3razsDMz
M5GfyTWBvi1wr3KDuGZmZvHGfsuSW+yuWrJ5R6FzPldNV+SQLN9vHYlXI/mkAwAAAAAAACwAAAAA
cQFDAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt
er/gsHhMLpurgcB5zW6zBQNCwXAQlNTuvH7fDAzsBQgJBgUHAyOFcnZ8jI2OOgGBhwEHg5GLAggI
BQSbUgqgoQonoXqipSWojyaiNKoAr1qSBAQiBgkHBgYjBAmbmQUii02nsbCgYKMrxcgkxo/MyjCv
z1QCBnKaBIcAtwh0iIIIfyIEdU6orWXVzs3H0u+r7dLsKfVXApWb3ty9vwUBBHBK4MvONQLYiLmL
RU3dPHcP4cUToSraiGLLFkJklgrjRWQbMRrj2LEhPYgl/lN+9LhyHkWSEYsE6OWrk69gAwhyQiDA
HACawcoRrKXEpMuVDt8ltdjy5UmSLEmFfMoyGlV4VpcydeqwIsqjTbmeCjtR6Vix93bQ/CZo1wBN
A3T95FnAF563uBDiOWI0rFdlf/1qfIrUKVkUgQuXZTVYYqvHX8EmPmYY8VeTgAdLTqe58g+Bi2hi
Q3AAAOg0IiLNORA00M0DpZP09ZzUM2OsnWdPtre1LMOql5txlmhWeOSPtlWC9d2Zdm6rQN5qMmDH
X4HrK4bh9TRgL9/Gy4ETJzuc/PPxt2szvwry8MTySM/WM67it+Pmus9H5QHHgCBc1Z3zQiY1pRDQ
HEH5/rDbYor15WBz6yVnGXrOZWYcbsTB95eF5rFXH0r2tTRKfoQxGARskVQySA2BxHaHAPkg0ImM
CoInWIkbclWhjjtKeNuHJUYooYZT3aiYWSwsOBmJRvqYQyXn+ONdDAKRoFon5gySkyc8QBdeVL1t
5aWQSPJGIZljjnShbWMWB2JavfW42JJTqbdDTr4cQseUNBTQkyacDBDIJpXs0iVMh50VU3oZllIk
m/MdJ6dSZDYFX2H2RZZWfFIFyWRyigJBU17D9DnAW4QI4qcAAQhCCy7yxCqbpLKuMMABcNWgWluc
XIPLAbX0wpomfNZqbA6hHvtCQKUuWwgdCAEYDEHf/uxS1yakKautDnZum8IcRC0bhy41ZUPaAWnA
1ZNruiTo7bvw9iAoCf41iwIcf+QCrCCHEPhNMLdQJ6M57sZr8ME14AqbAYJ2xwIlNXHi5y2xeSNQ
HDWxVizCHHesAoEEUcvNCdcYoMZ2tNixJSCu+ncrAfZ6LPPMJfSEEK5DfeuqCCintnOrg2CzMc1E
Fw1AQHEFBePLI1gMQBz6BGXdT9QZbfXVOsu4858rXgdxbJ2wNgKMWJdt9LoAuPbqLjYD+hOrbns9
NmkCyWH23QZj5091uLxVS9sFgdNTzHNwPc4aCySeeBILiND4CY8XETkRkxctECWlsZu2Nm7TQpPn
/rbCIY4mMYMxeeU2oG6C6iSw3roYrh8c0EzEcmJa1AC0ZR3DlBDSgn//BVv6F5XHDoPxABiPPPJW
ML9tJFhO/QcnUP50kyCw1TK0Ca59YzPiJUSu+OrJn754+aiPn7zjI6gvPuSLv9/4+Y7T//r8qr+P
fvv8r396+fx7nPv6t779tY9+8yvgFugQo3wkoBbXKQDGEnCdoRBseyQzjSIqMbIyFI99IDwgCPWX
vgCO0IQKJJ8C8XfCEAZQgCr0X/9IWDwYAnCFOGQfCWfovCgM6mgAg9W6aCGOW/luBoEwlAjkdoYP
5pCANixgCV8nxfClMIYJzKH+7kdALmpxhlgM/uEOExhFKLqQC4MKRgQ7hxDRacwGcYHZHpy4RTHa
8YpXtOEHYye/OyrOfjrsIgp32EIqVtGPMhQfAv94xi0QiIjoKtRMOgGQgs3AHDDSGAZNZ8UnIrKQ
gtRjJ13Xxy+mIIt4lKEpD2nIKI5RlVSc4hegNCjRyWh6eLiGJV3QPYTIQWxs+N8dzbhKM4oykKl0
oSILWcI6thKMoPzkE7dISFZ6IY23UKPdSuA0GcxBHAQICI2CycjWAXKai1zd+Vy5TmiK0I72U58V
ndlFeaKvjPVDoDmFmUJ7ypOeWAibOYaGF2B1cAUB2NPT/sMah+EtdSoAaA56+NC0bRMF3YvR/i65
d6tx+gpWFYXoKQW5A4qG9GPiGAgFX8aqsZFNEhal1+FO2oN4+uCcNJWBv1RaGn+Y4xCD2kUvlEiC
KuX0qMZKaNewYQdvpPGR1uMSapBKVWVdNDWFwlMwCrU5kG6jqmB9F7u0IQJ97OIWFASAIcLKVqvm
yW1RNYg+trFJYxEEBQkYQV5jsFcA9FUIITtBYE0wWBGE7LB67etdqwoxbD1wiTdJTRw2+q7FlmCx
ln2BYotQWBJ0NrF/PSxi/arYvx51JrDBi6HwFC6a3XWwokXsa0vrWdDqFbSbNaxlaevZvGaWtMDt
bXCHO9zZ4nW3vqXtbw02O6ZZ9Kozi21y/qVL2tFmtrR7ha12s4vZ7l42ud8lLnCRK1zbCta66B1t
W7WlXd26V7fTFextZwve8RqXvuK1b3h/a1z4qhe+541vYQP72fXWirzBRXB+c/tavybYtw6+b4RN
q+AK8za2hF1ucev73vwaOFYI9m6Hl8tgCNe3weBFsXip698BY/jBFNYwea/L2w/blbvcHTF+L3tb
AHeWwMiN73dFi1sXE3nDwiUxfmksZBsf+MLUfTFme+xjJlfXtu3lL4fdq+UN5/i93W1vb//rZHlY
WMAcnrJhy0tcCyeWyzFe8Zb1i2Uom3fBcy4zxzR8NQXruWN8thqL/wxo05rtyIROtKIX/s3oRjv6
0ZCOtKQnTelKW/rSmM60pjfN6U57+tOgDrWoEZqGuo761DEodalbiupW22Cqq2bA8GTGLFO7Oguo
UXUaBCBrW3srAAwItrB9fesp4GHXvYYRrxlA7KQGm1WlHrbZdI03XQugAQ1QtrKD3exYCTvYD/i2
sGfNAgeMwNyPmGpq1C0DdJ/73T9wgLzRPe96y+RoAcG2trfdAFu7WwTu/vcaAoDtghv84A1gtgsE
LvBGlPoED293CRreg39bHAmqfra2mcWAbC8cABffgwAg8ICSm/zkKH9Avz8OcBIEXN4uNze9QQ5w
mGNB1zhX9QwC7vJz27zmNKc5vX/e/nN4t/wIqm6ptXnt8RbI3Ocz53nNeU50Yz8AAliPQNa1fnWs
Q4DrEGAAy4N+dKkPHehkpzgUcr5xasdA6mWH99lBPvOjF/0EagdCznet7Y6T+90hF7rc5V53KgTA
6xHQeuIT/3XFax3rD6gr3Mk++LibIO99gDaz9q15YBN78g0vfOHvHvOqY94HfOd835u+AribnfKV
h70Uuu54xW+d8VhfudNh/3Kbvx7qp1/C5lW/cV43++l3t3fa7U73ql+e9ETge8cPzu+/N//nr7f4
vO0e/CUIQAKP97r4xx8BCSh89wznvvqXz3wpAFvWxIdRvsUu8fSz//fsJ33gZcKs/oSPG9pMZ32u
N3gDmH9VcG0TsHgKuIATEG6+FnplV3e+R3hX8H7xx2sq122yJ4EcuH7Ot3/dtwPIlm37tmvYtkn2
V4ARuH4VyADgt4AKKAEJ93nPB3QvF3TaJ3vu13Hwt3oJZwMQaIM+h4Mxp4PKZ3RFsGz6xnnTR3+t
N3FoN3l0R4TtZ3gd9wAJyIAyeH5FEIL4IG5NqIE44IVoEGzYBobiJoaM8H7C1gBYOAFwKIP+J2tC
cIRkAGzYVnKsdwR2GAbIhoY9yIUGs2zidnBgqIarsHRtV22cl3GIuAfDd4EbNzM5NwKr9ohJVSxJ
h4l6sHeeyG4Io3MqAIpGQ4qp/sFqHCOKJuB2xeYFn2iKrRiLd8CJstgFCFCLoKYJt6gCu7gCukgC
v2gCwSgCwwgEu3iMXNCLVqOM2tKLzFgCzyiMuTONuXOLmgCN1niM2VgEyOgDxXgC0SiM1zgC30iM
42iO53gD0diN4ZgC5QiNLVCM7yiP6fgD7MgDzKiN59iN1EiO/QiM+biN1TiQ8LiP+/iP03iQ1NiO
NeCMvMgC1riQAkmOE1mPQsCP8eiP7giRCWmOBEmRBHmNFmmPxIiP8NiP91iSAGmRLGmQHwmSHamS
LSmTNGmSwIiODomSBQmO4TiOI1mSBumQ+fiRKZmRN1mNCpmT/riOARmSE7mU/s54kEOZlCqpA0Op
kzrJlOk4k0H5jEKpixipkQtZkztwlTnJjwFZjz/plCPpk1g5k2MZl0apkWdZlWnplU3pk0/pkTEp
keJYk2GpjidZl0CJAhHJl9j4koqZldLYmHEZmIJ5lITZlyvZlH8pk14JlcG4jnRJlhwpmZ1ZmOK4
lXi5mXuZlWBZlUf5mKqZA0o5mQhZmNqYmCI5m3B5mHIJkIDZmjhglqFJmTdpmbp5mauJm2JZnLvp
Ar5JlsYZnDBJm7aZmaK5msjJmj0gj78Zm+hIkaa5ndwJjkSpkAVJmAxJA6+ZnZx5mLXpkWp5mm4J
mzCZkuV5kliZm+npl7q5/p4DeZtvyZPJOZ/cuJEkOQMAao9biZ6GSZpRiZRBCZ4NypsJSZ4xgJ2e
2ZNdOZuUOY/hqZTBKaFPUKDXaZ5f0I4gOqEiCgUkaowniosPqQQlagUpOqAy8KLFRqOuuaJNYKO9
iaMs2qM++qNAGqRCOqREWqRGeqRImqRKuqRM2qROqgWRiIpPqgSrJn+wyDECQQEGRwF+QotT2gJ8
RwFiKqbyRzQCQAEVkKZpWnBc6qVfaiAwMqZyOqbWpyyR0ABqqqYWsKdpChA084o4hzVxOqdzagF1
aiwCUAEXoKYFl6d9Smudl3Rz+G17SIlnSqiFSgGmNgEywKkA4KmuiKYY/iABKqemo6pyeFqp8TI7
KRB/PwgDcBirIwCqMUCrM2CrQHCpcmoBmGqoLoCrLwCsWZCoa8p0FTCqslYAeFoBTviE0Bd7YkAB
kSqpgMgAD3Con0oCniqsKACq3GpsFLCn4rqnvdoAv3oCspqtIsCp7AqH66qu6ToFxFoBK1cAGIAB
/XZtjDp2VdivYYCpczoBEjCwcJgBBmuw5hqs2vqu7jqrDZutDZuu8cquELut21qx2vqwNXCm49qx
40oBGqB7K4Cr3qquEPuu63qxKCsFBZCn/UZwL4um+zp2vVd52Td3UgCwY2oB9daz8iYBtkarFouy
JfupKquy8Dq0Rsuw/ksLr7N6AwLgsVK7pyFbVyT7tCfrtCu7sPKqqBewqGJXai27qF/7AC+AfxLo
gXNHhkIQADorphXgAAc7twcLtMEaq0WrtXp7tFibtyVLsUSLtRs7tVK7ASKrAiSLt0y7txmrsVCQ
qBjwtYsKbS17rxdwrwm7e1WYtvdndGwbBA1ArgBrAXRbuoc7sujat4prske7un77tICbtPFKA1Gr
AR1ru7d7AKfbrSZwtXy7snkbBQR3r8Sbp8SLARyAAc1abpSnfJxLhQb4BAxQAYRbAaU7txKArcBa
tFcbuCYruK8bu0iLAwFgARpwvuhru+mrARugvOdaAq/rvaybslUw/r3He7/3ygEcsLsqgHydC72i
h4RPQHCO6qh4e8Dm52vb27cM7L3cC76wO78SbAMMsL4WfL4HkL2/esApK7Squ7Xu+q3C1wDIm7z4
q7/mJ3EUSIVoK8BOcCAIF8MIJ4gssMDA+7Dca7HxO7/i67Ai7AIEd8HpiwD4KjPTq79InMTJy7/O
OoTP67yea2ypx4TVSsMek6hCvAFErKrxIhB4mr9JjLlcDC+AKoluygiQ2wAbsMawscTYKiubN31u
qIcNsCpSajWAejbKir9y+MaxEol8t3Rn/KZWom3Up2yDPHCiqG6qSMifIYnK5siUBqiXKMmSRsmN
bMmOhslXqslH/qCjnqycBvOO1OmOcJmYOAnKRgmZVaDKtriWEDqaK8mTykjKZemZVnmcjrmRxlmO
vuzKoqydvQnLwoyNeOmf33mRuNyixdzMssmeeRmdAerMMzqYw4iWO9mhxiyc2uydwFmRy7yjsTzO
S/mPv7ygxJzL1Nya+jiZU4nMIKmXi9nLUjmeoQnM9Mmc+lyZ3QyVqIzKuImhwymfISqZ12yX2ezP
/IyY0vig30yU4QyeoJmcCJma/wzNGA3Qb3nM1onPpYzNjDma7MiUw+mY2biZEt3RBf2bRXmX/QyU
UdmWyHiWHE3Qc7nPQknLtXzM8sySmumWJk3R6szSCN2TEmnR/iW9mEW9y2Jp07c80XLZnDiJmfCs
n8gJlpDpoQW6nFEtzAFN0rXpnuWcz00t1EN9nubsoBUt0KSZoNOZ1Tbt0boM0jmt1gx6ylZd1tJJ
n079mfWJkfcp0Bjd0zWNmsjc12V5oBWaoDW9oM9pz96cnh5qk3+tmoEN0I69n4UNn3yJ2L6o2PbJ
2Nwpz0g5yw0d07oM0/csBTHqjTz6yaAN2KKN2Y+toW0NoeCcmzLK1E9dzba4BDoq10TQ2ittok4g
3C8Q3EiK3MHs26H83NAd3dI93dRd3dZ93did3dq93dx9yZ18NYFaUVHbAeTdAb6qx2N6HXdcilFq
pdNGAeUd/t8doKl/WgDh6rFcut4e84fVqt+0ZgHyLd/nfcXhSr1Tm99/SohVzG1WA+ABLuCJfAZu
awEGLrUVTt9nS3R5N3quqOALzuBEA98PHuAUcMUUXuHimqZ8Kq4Yzrz+CoVkoIQJd4Zn2IbjBgP2
5wjlu8ZrPOLkrQF/Z6s/vLUNfAUMcOJ8WsAqTuFMDOOxt32W13xbgIcpZ3IzHGxv58J8IAAbABuw
weNgzuMaQFkOW+Y1MOTSm6aSu6iKqubG2+TPGuWcK4VlWOUnh3DhluXMB+VCp30BjAX54OWCPuhe
DudNe+hG+7ffG8I3jOZJuKxsruSXK4N1qnZB+LxTbq12/r7py4t+yReFHqiDU1AIhF7qsGHoFNvD
RIu0SsvqU8AAkVvAkosBKuffeIcCvffEzlfnKEeqDzCwvl5ypNrpmnvr0UuEn4sEpG7qhI7qJxu/
Ozy+RP7CJIy/tD6DKmyz2u7kgN4AA2tywP7t4E7p9TdxUO56fJ7sSBDozD7ozp7qPhyxECy/qysF
1xbuckiC3VaAayvnXNBx+B7wwP6qOB7F/t656m4E5dvugn4BxA6/zy648y7Brm7vEXTxdjyJOK7h
Tiznu27k3i7w4T7GTWx2f97vCW8Ey87wFRDk9F7k0L7q7gfJJUiJVyjyKmfFLu65yIfugvfiwmsB
DH8A/hdg6FortDgs8a5b5o4+BFNM85DahgVHx+MW4XqQqO1e9H78x5Xoifu9bNsmbn1n61iqxqVO
r1sfyoC8dxpfih3ntYuK7d1tJZycyQnOdGdI9nOPVO1d83vPVnX/92H1cHlMVcwt+I9gy+SczN5s
2o0/oKzcylV1+FPAobzd0I8ZzRk9BJGvjsQMoPSolY6vorrtmp8fjwpKy6MP+Ys/11O9z2N90Zq9
+Qpd2tOp2mZ91szMy37Znk6p1K69zjBg+WSt1tKcn8fP+a3Pzgjd1Qud1LMf/QO90Zfp2eJMlwdd
n7f/2NGf17hv+w9NlcLf3Jgp/hWtnb5P2KfN+M2Z/tud/9HNX9fbDP3dL9YwjdJBbZ2UjdPNP9rE
mdEggCCACJhnSarmSLany8rrC9s3jtrty88rSlRjDV29UQqWQupiOx/tl2s2ez8mDut8OktJqpaq
rM6K0/MuDYSqzMLal9hFFq1v9risR/Pz5H1blpBSHV1Q3JrRUtYfHprVlZRb4JacF48hF2XUzSKn
Wd/ZEBspUNqR4FxlZB3jnmPo1GhkIqgWYkwcol2n66cU3yCYZI6wYhARHG6mkZhOEhRobPEwoOkz
zajhEjPyJmzX63QfZKLpJJbuNuZqOKRbtPV4qLT0vNq8/f20sTlcMbQ3cpodYhSw3Bho8vY9+WfN
/tZBbskIoTuC8Nk7YAypbdynT1bHkOPqifQ1siRKkBxTaqTH8iXMmDIZfoRZ0+TMjjdZ7sSX8yfQ
oEKHEi1q9CjSpEqXMm3q9CnUqFKnUq1q9SrWrFq3cu3q9SvYsGLHki1r9izatGrXsm3r9m2oAAIE
BAgA9y7evNMEWNDgV4MFCxQE6C2clbCJunYNz6Pw9/FfwYgZU36qeC7myZWnCIDsOTKFaQ5Gw3Aw
xTQA1GhGkzbB+vVmtHIz014c+0bfz7ot2D6jWrXvWMCBpz6q+Djy5HVv95lNOzMD5rj9Hjjwd8Nj
7H8b8CGO+nfr4uJThz8x3AZxoHWfs2ffu7vo/hvpsTpvL4CB5ikT9k+4W2HDBtYdEGB1AFrnV4AN
vCdfDt+Z5xqE43kXHFH12Wffgg2OB99YFkKHGQMMZAhDfyeU6FYDAwKoQYErahAgAhxIEN1qGqIX
oYOnscbgUB5e+Bx+oZg2YWtFkvega+ENOV9ScoX4ZIi0MdBAfjecCMCV/JmIZYn7mejlVQJUNyaA
BorAAQYSUDliaTaSZ6SE5eEwYY8f3offj3cKueGRfS6JY4TiwdlUACE2YOiUiR6aKBpXkrgllyaA
2d+Jjk4VAAZ3xIimmvixeWObgiKZI4WBmqoekCDi2V6IffwWqoSxigroqUrd2QCuU+K6K6J8/vCX
JaSVQjqsVQxIgAGyyHZK1zyv0gonqXSeyqRMPuapqquwIRmrs99p62xT9+06LrkMPEBjKMJKui67
WEqq5VWzMVAAvQVkttw4O25LWo7gzactrEHddy17jHK4IbhDjloruEzdCSXEhs7Y6KPtdjkspcRe
Spdy690rXWJPEgwirp9Ou++D0AYa7VMPR/xkAxI8UKUNwFp887pdWhqVXB17jJnJhRUa5cjiKnjw
yiirLGvDS7n88pQy01wxzu5afXXGkVrls88gmyAAuWGL3cADh7oKqqzF/bmyktsyVejYuz6gZtC/
1gwm1sFm7XVaRscdtqd83wB23A9MMLPg/onfwzXXisOga9gSTDCx45VbnpOxEsg8N3/oXv456CE5
GbPmmi8adOipq26DlCLPJeLqsct+Q89czzU7TrgnzvhlsfWTuyDKwCN8TvHo3iPvilV2kU/UpNNN
Luzg8hI4UfX0VvL4GjbLMYDMAg8XEu2yhTFhtJHRNSiZ30swX/w+UUEzGV/V9Vpxj/5FAmlCETK7
+PBOIcSRPpEwzw8ged4qLmGJ+t2jejqZnjMAQjyA7M8mC8FJKWoRPGV0ghn68wMdhDEJATLwEWr4
YAax0cHwSa8VB1EhRhpBvQga0HnZaAdB4Fe8lrDvD5zYxCm8wcIKsqKHIBRgSu4nQ2B8/lCIC3yi
Jm4xEEKQkCcnLB8tYEjFU9jBhRbR4vmWGIxq/HCATGAHFRUYvRV+oyWemJ/6TujD9XVviv1rYQ9D
6Al8GK+EKpmj9xoSQC7GMIr+GGQfY9EP9PGwfPrjxgQJqcOKiDGOeWAkHb8BPvG1Qgad5CMSS6LE
QA6Pg1cswyf1CA788VCUf7RiA49SDkaakRLqWCMutyhFMyZygBsZ5Q8zeYtSXqKJGmweLeAIS6KU
0I8hWaQPfelIEWIikgn5ohvJd0GdkBEP6LjhFu3YjkXQ0hu9PN5QSGLBWBoFmg+R4CEk4sRxkk8h
vbCnA9G5TmZ6xH6vTGI/9SlQqTiT/iYBHShCE6rQhTK0oQ59KEQjKtGJUrSiFr0oRjOq0Y1ytKMe
/ShIQyrSkZK0pCY9KUpTqtKVdiQBLnUpXl6agBvI9AQvpSlLYypTmG5lpvPYqU9NsFObAoCnQs3p
XYxaVKVahal9MCpUeQrTqQY1qEh1C1OVWlObWjWqTuUqDKQ605vmYKhc/apQq6pWsFKVqFd9C1lx
AFSwpjWtZqVpV30KVKuGdatzLateo8rWsbr1rXDdKl2XmlixJtYGWg1sYx2b17MCNq6PtetRDatT
tCq2rp29rFwna1m+9jWyX71rZz0bVsxq9rBqvStjl/pXyZY2tbalrWpzy1rB6rao/kTlbGu/klXI
6nasa+UDaEEbWtOSlrepzepgg3uWuH72uJS97m1VS9btkraxo12ubOlKXdF2V7pg2etZEcva9KJ1
r4FFrWS9ql728hW+ojUvWuzb1trGt7x2NW5dqYvXxwJ3vrKt74Dxq1DgKrjBgHUwhEPB4AhTuMIW
vjCGM6zhDXO4wx7+MIhDLOIRk5jC7j0xilOs4hWzuMUHbjGMYyzjGdO4xja+MY79y5UJlxguPK6K
jntcmB9DhchCjumOj5w4IyslyEqujJOXwuQn5yXKSbEylSkzZaFgOctalkqXGdrewsaiqkER8Hqx
+9/v9nYoYQbKm22wgDnPmSUL/ujDnQGQ5xvs+Qx95sOf9SyS0xJ3GmaGM6GbO9y/OvcocZ7Jo0/Q
50BvhNJ8RoOlK33pkFD1vXPdr21fW1jEijqz2QV1gMnL3+cCOLRrZeyWV9uUSEtazpKu86VxbQI6
71rXMNB1nvcM7FrnINjE1jOueX3rYQva18ru61BP/OJC+3a3Yr22tamdatpeVrmhbq9fazrbfdCa
JeUW9K93fexbqxvd6Ka0sd/d7nhnWt7zJnag7yzsXt+73deNrVfDi9Ojdrq64W3rTQl9W1QzfNwC
j+/BsY3mnzLl3O7u98X9HW972zrdHFd3vTm+8XXfe98Y/zNvY8vqgVd7qr6F/vXLAUxYpzo35dZ1
+MP5C+pGk7viIvnzxvON76FvmuhA9zUOgr5sksvb5O+mM8qPq3KeV7vlMzf4zGUe8wGTmtGzxTa0
wavYmp/b4pz+ecedfmylZ9zf/Qa62zetdowP3ekjx63BWW3c5o664JQd7d5d3XWzole7qoZ4wkU9
8XGYvaVoXzvTTS75pL+98m33+OTprvFf05vkNv804fVK5sTnNfCY5W5xW51e3AZ85dVFPX3PLuWf
Q13OSN98r4UN78wjG/Jt1z2wg297t+t70rcne+B3LnpTu97wiyXucBcuYJVHXLylln52KT57wwi9
JJOGdOMNQ3XtN5kxcPd+/sdjEmvmFH4j4WfI+ym6fvYb+B7xt7+XVXd/8uf/c/tnfP+xVJSFHJ4V
HfrZGQHuQwIGxdx9xQJ6XEn8n6ExoAE+Hko84D1gYE40oFdo4OXBn88BGshZ2rP1nu41Xe5xHvDl
mvF9X74lm7OtHbOhYLrFYLAlm+89mw5enrIVnwrW2u01277dYAv+IJ8NGwyuIMilHxHi3hlIYJkV
YO/9ntHR2w3i3hCSHA662wkyYdzxHtvd3hZOYRZuXhk+3RR0YRjeHRnyGxdioRbiW+dhYfcpHQfK
Wgj6mRNS3hv2od1NIdP5HgTCG9HVYA4W4iAKorHp28f5oR7C4ckVHds1/uIHOmIkat4SwiEBQuEE
YtoeLlsYFiLUKSGydR8X7qAkxl2zHSIm9qErLuIqpmApjiEf+mHtuSIrziIpluIRluDJ3eLuAR8O
hhwnAuAjNiAYQmIlZtz5iVwg8h4Q5iIbvuIhMqLQmWItQuMnWuIyYiMVXiIEYp4qMuITRoWOTaIc
KuMk2qEWzuEMJiIPwqM2uuEfOuEfziM8OiMu0qM9qqMXciM+zuE+stxTnOM2miAoJuTFlaAOiiEg
IqQqymI8GmHuTaMPrhtDYmTw1SPn2eMMXqPaMaSzBSEqoqFEEuK8xeAUFCO5sWRYeCBUwOQ0yCRW
1JtL9pzi0KRT6KQUTaZFps3fmQUg+2kFUArlWNzkoBml+CFlBDKlUiKFU6ZEUT4lkEXlS+AcVRIl
fOVXjnWlV34lWIalWI4lWc5YVp4lWqalWq4lW7ZlSIUAADs=
------=_NextPart_D6E_139D_FD1A5C42.BC3D6F6D--




From kaitlynadda@watchwalkers.com Wed Apr 04 11:01:52 2007
Return-path: <kaitlynadda@watchwalkers.com>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZ6zg-0002m5-6P
	for sip-archive@lists.ietf.org; Wed, 04 Apr 2007 11:01:52 -0400
Received: from mail.polex.ru ([62.84.106.6] helo=uvf1)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1HZ6zd-0003Vh-SI
	for sip-archive@lists.ietf.org; Wed, 04 Apr 2007 11:01:52 -0400
To: "poul wit" <sip-archive@lists.ietf.org>
Date: Wed, 4 Apr 2007 18:59:59 +0400
From: "sibella blinni" <kaitlynadda@watchwalkers.com>
Sender: "sibella blinni" <kaitlynadda@watchwalkers.com>
Subject: Kermit
MIME-Version: 1.0
Message-ID: <16bec01c776c9$ea340410$0d00a8c0@Condy.local>
Content-Type: multipart/related;
	boundary="----=_NextPart_000_16A7E_01C776EB.6989A910"
X-Mailer: Microsoft Outlook Express 6.00.2900.2527
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Spam-Score: 4.6 (++++)
X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24

This is a multi-part message in MIME format.

------=_NextPart_000_16A7E_01C776EB.6989A910
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_16A7F_01C776EB.6989A910"


------=_NextPart_001_16A7F_01C776EB.6989A910
Content-Type: text/plain;
	charset="koi8-r"
Content-Transfer-Encoding: quoted-printable




Beneath a pile of corpses, lying massed
Preface to the 1970 Edition
Only whirled snow heaped up by whirled snow,
In the woods, close by,
XI. Franklin's Last Voyage
Rain. We are forced to fly,
Wheezing ravens, when
Of Boyg of Normandy . . .
That open before me? What I see
Event, the end of the painted road ends up
By the design of our own silent eyes
So you can watch me watch uplifted snow
Of the matter of snow here. Both of us have grasped
Of tree-dividing sky finally comes down to
By trees=97or might see as the masonry
Choces, M=E8re and P=E8re, undreaming even of fields
Your red cheeks radiant against the wind,
The flakes which have stolen onto the flagstones
and the numbed yards will go back undercover.


------=_NextPart_001_16A7F_01C776EB.6989A910
Content-Type: text/html;
	charset="koi8-r"
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2><IMG alt="" hspace=0 
src="cid:002d01c776c9$e26e9920$_CDOSYS2.0" align=baseline 
border=0></FONT></DIV><BR><BR>
<DIV><FONT face=Arial size=2>Beneath a pile of corpses, lying massed<BR>
Preface to the 1970 Edition<BR>
Only whirled snow heaped up by whirled snow,<BR>
In the woods, close by,<BR>
XI. Franklin's Last Voyage<BR>
Rain. We are forced to fly,<BR>
Wheezing ravens, when<BR>
Of Boyg of Normandy . . .<BR>
That open before me? What I see<BR>
Event, the end of the painted road ends up<BR>
By the design of our own silent eyes<BR>
So you can watch me watch uplifted snow<BR>
Of the matter of snow here. Both of us have grasped<BR>
Of tree-dividing sky finally comes down to<BR>
By trees—or might see as the masonry<BR>
Choces, Mère and Père, undreaming even of fields<BR>
Your red cheeks radiant against the wind,<BR>
The flakes which have stolen onto the flagstones<BR>
and the numbed yards will go back undercover.<BR></DIV></BODY></HTML>
------=_NextPart_001_16A7F_01C776EB.6989A910--

------=_NextPart_000_16A7E_01C776EB.6989A910
Content-Type: image/gif
Content-Transfer-Encoding: base64
Content-ID: <002d01c776c9$e26e9920$_CDOSYS2.0>
Content-Disposition: inline

R0lGODdhkwHBAeMAAP///wAAAPz8/Obl49PSz8LAvksvMWteYQQEBJGLja2sqaClOPbmmN67TwQE
/AAAACwAAAAAkwHBAQAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP
yKRyyWw6n9CodEqtWq/YrHbL7Xq/4LB4TC6bz+i0es1uu9/wuHxOr9vv+Lx+z+/7/4CBgoOEhYaH
iImKi4yNjmABAVKRkJITlBiYGpiaFZGWm5+fmaKloBejHZ2PqKdOq1udsBSzl6C1qaSmuba7vJ61
FsGsAMNIxlWyrsChtq3FyxKiwKu4s5TIxBzZRdyTp8Pht9HY5MHV0dLm0Non2aW6sOWWnL+k6ufT
zp7C6/zMveSBS7evH61lo+wZU5ZBoCR7BvFJxIeQnsKHynhdGwjRFBBk/ruowTuobx5EZh77jWRH
EqDLiQVDHpzZ7FnBmK5ONiQo8OY9ivBSOhMKdNzKjQF/+fqxUFMujRlF9tqgD1rUiehy+ptK8ylD
nyrDgnWqVYS1imAjWjVqlGRbrnC9uvT6FuYOcWJ7jkVHNStcrOCK0bQpTfA+hzdBoh2s7qW3pDIZ
s9z5d3LjynJbauZrGbDauwQ7X/45em9fsaJZkp2cb+i40jglE/bJObG5lWuJSm6KuWza1bJV+0Zq
tVtoXx2ritZLmdpvi67Tji53GPlr6Y4X0x7YCvfV2akHK/UNezp58ddzC9XNQxxyt8qZYy+feS7G
6M1Wk31f+h337PyF/seYXyot1Vxxu/1n30uxmRegeqHVgFdfwNGnHWlxbUVdY7zpl96BAg54oXV1
YYiYSJERNl52Kp5nm2WP4abDhCD2d2F5DCKYmof4UcYjjiyqsqF9t80HY0VaFUnaiiK2mOORUJoV
4QzuRSSffEDuVaKOguVkGFVfFsaRWl9tMyR6B+oUpXPYtWZXZ9/ZyOZfZ15koQ9N1UWXgqbVpBlM
4yUppKB/QhVcd8m1yRGSfDaJIZEMZlTiiVy+qSNdf4JmYFFJEoVliMtlpdybavbGKJNZFvgTb5DJ
GF4qrJJZm5y6beRqpZyiWCoN1qGIaIOyxVpZbpmg8gE58Yw4ZUCr/kZo60n53OcnpAl2ZSeiPO2U
3KjtdJvMst6Gm8hj4pYrCLnmptsHuuq2iwe77sYr77z01mvvvfjmq+++/Pbr778A8+uiDfAGbDCF
T/IK7sEMDypEwQ1HbGl7C0vciKvzwJdsq9BpDBC36n1mcbgphpyrrhalJOmKtZYM8cjn7pfppd9h
it6kNnNpKMzeUjorYOQxGWhvfabK8yLEwelPnh9rqF2pLx+9bq+wkWi00E5/xh6oUiNiddVUM22t
k5G23LU2iiVsJNZkH+pdxWcHkvaha3OW9KdBxu3ItUovhirWhIZatN7t5BwqzoXWZjhzUMFNeCEu
38Ztiioviqpt/mY//gjG6dxKrKp9fyoq3pqXbvrpqKeu+uqst+7667DHLvvstNdu++2456777rz3
7vvvYYh6RNRpzH0FQmpP7bFxck9JPFMuPs9GmcM7/obx3yY/CPVGSG8G9lT87HXKIAu+/OAtnsW9
jbsmJSRFBgWq1+SnWrnfwiWdajl/wJWf/6A9ad9HyActZcmIdK45YGTutjWUOQ8jo/KU2TLXKgea
jEIJ6VRVSASr17DHI4pRYPmYVzcA0elGBdJTzYImM23NDHQ685mkTpi4McFvYjW04VqqdTOcsQVh
dhHgwxo1mxZmSGSoAZYShZPEHIntiHMCFIFYg6TtaG+KtrLi/s3yhkNSVegVRNTah5YIqqQtaThb
8YCwyMjAtrWRh48yzxnLVjQzIpGKUVifrILzxaul8XwV+pqZoJa1J/VRjpzaYPSO4zSqKW1BkEze
G5+gR/vxcYxl/OOm8JhIQjbwOehDZCQF+TMa9XBTpcTkIUM0STDSbWygvNO0MDfGOllPkafZoyEx
yUmupXKWopyl4p72x10aqXthfIYeD7nGYIJtTcdCoTFlGUk0Ge2Rr2xljYapS0kWkpLJhKEXa9nM
XloxTllCoBeDhcVZGXGJ4ivblpzJTS7iamb1ceUxb1jDHOaSWjuMohQZ+cNQvDOLQVycDnemRRfy
k2bcq6eI/grq0BjmMZxNPBl8pFUj9n3wWbt6kDIVmCy+UFCjz3xlUUIXwfx1EH0gfCBJoVBJ8JzP
LX4EDy7/gS015tN+COTcQy3Et5RikKjbKigzGXXNz6m0C96bnvXGEFUXVJUMVy3eVLNgxx50dQ9Z
1WobGjcEsv5hhIAIaxNECr2SgVWtaIArEz6JJ88B7654zate98rXvvr1r4ANrGADJlefjkt7heMT
WolQ2PcdIp7iKpNdSSi1xp6VJ1ul2Nks6wc3gVOe6vMb3+oR2qYKNaAAREvjSptIsF1rsXEcHRKj
oqatvU2atJKgEAnWKLdG7oJy/GhQnPVbulZwo8fdKAFf/ppcDk02tvsb2MqiJcL4DKxJCzRuDvqo
UB8ijp9mHWoUVzusOYV3oP1saHfn+U/20RBAxF3oQdn7IteWV7PY3EwVx4mT81DKpug0pRSdSFp7
Fji9+8zb0Kh5TwITlSvC+uJ/62q+prXNmhW2hpTYCUxz7qhjwgQxhhPsqA8PLqSexe4DR/xVTTnE
QKT8JuM6hz/r3pFjP/0a+Opx4aZWU5tHWlbLRNo+yUYXtrxtKf8cOckZxzGFDJ1PjB3I3BDjaKkj
4HEsK9xgKLMlckJW0HSfewMtl7C9wHKyTaUiJ2+a6YorhmU1fWzhLV+JXCPhRpHFjNEgSJi4b+6m
mm/M/mB17hjQaDbziOmMkjBi+b6B9o8v+fxU6GVItMT0ryqJWFtlERpX3J2fO9EYOHUaNHADzhSK
gSorCLb3z7idkWLn6933cpm8FbUxnL+L4CDDUaGfPjVqwmtdmSKYoREmJ31BA9+LkJSCWApJniQY
bAjtknPVFfFv7WlQbL3YlmEesq6lTGmUMRbVnjst/UKZZ5mmx9RAuXG6Qfa/m966xtpSn3tTKzkd
dtHIPVUDZzk7vWjqtaoaLpzB84rwKRJDz5l93VUd+XAA7nXibN2bxQ8e8XzvtlsfH6zIR07ykpv8
5ChPucpXzvKWu9yqHST4yx87DTLP3F41vfm+cq7z/i/cSt0C3La1BOnUBPYcnLd9NpkfJOoYZ7vj
R5dQC8+rSIKa19Pb8WHUwYhGMV7Xzlhvc+K2rk8QrK9KwKTeMnlJdmRGM8p+PG2Jg4xKqLedSu4e
9zE3eeeJ1v3uS5h2fSvtvkLPOtCAPwYjxVjtHkOT51xLvFftFnZy9zjK6PSw5M+tX4pyuYk503s7
+7z5uib9bcEm8nDnjtL8lr6tL2Zj3p8l9g8XNfKvz73ud8/73vv+98APvvCHT/ziG//4yE++8sdH
bxrTGM2tNzvFF549MIVg4gJlwdcFrnpdPDlBm5T+9B1b/Y4ifgUO1/724/pfpLS4oZDucJe//1n5
/tu/BOlHv92hmvArc1SllRRyKUZ+4YNo0gdz2acCMrdWi/dgt8d4JhJnALZuvjIs07Zf/lNlXmZv
qeRJLiVe8XZqVXZgqFWB9WdYc5ZJhDdp23RSfLd+4ZdB9ONWxxWDvUVXMiGDzoZWOfhlOvhtC4h/
FTNoZxZ/1+d8vUZrW+R9J9RdzDItVKdsRihbCbVsRrUnTWiEnEd9RpVTypVZHMRO72ZAqXJnw4Rq
RYR14tNpbCZ7DQhPLJRRineAcOSFFpRlbAVkdMQumbdK5cQieCNgo1VMv7ZIWxZ4Q2iIAOhuePhC
ELJTKSSHIvhCfmiAkVh4X8iGlOiDkyVRVzh+/nPIhUT3h5IYYvpzFBrkbD6lW920iF62P1QmiDOW
ceqliI8YcviVJkcGd63YeAS2fh6lJRvnaymogjjVZpCVaETIhR7miQXoJ+8ERbp4f9AFjJpnUpa4
b4tmh/c2eHRogWynjPCned/wfGR0jqy3gs/hb6JkhvPnjgaWbBAIUZ+Wf9HISnFYiLFWPfvlTNsI
Xwl4fuBna1iIjgPFjsRYgmnoeWp3j/LkdVOYj/BnOFy3bazCZKlIgfInP5cTIMl4i5uoK5kUc9Tm
dygWcyJDgxUYaqB1OUpgWyJmExjpbYSoNhyZknKxYPHQX7OlgTsJXlKIiUcFavWzcSwphvC2/nxK
uZRM2ZRO+ZRQGZVSOZVUWZVWeZVYmZVauZVc2ZVe+ZVgGZZiOZZkWZZmeZZomZZquZZs2ZZu+TgC
MAFxWQFzSZcSUJdzGZd6KZd1+ZZOIAB6CZiACQCBSQGDSZiCiQF96ZdFIJiB6ZiAOQACIJl3uZgZ
cJiWyZhCgJmHSZiEKZmOCZqYeZeeqZlSMJh5CZkDAJqfmZidaZpPkJqI+ZirOZmRKZoAQAAD4Jmd
mZewaQSo6Zh3CZrEaZu36ZgE4Ju/qQSyOZvFWZsAUJvECZ2TSZmluZybOZuQCZm6qZerOZ21WZ3G
CZ2KOZpyiZ0wkJqquZqIOQDdWZ3h+Z2C/imZrEmepImYpImXmZmY6PkB2zme9Emf7zmZ3fmdyQmf
Bwqf7UmZr6mc59mfKaCa4ikABJCc4CmgyRmd1bmgu3mcEvCd54mX9wmhJ7Cd7Omeonmbtamb34mi
kUmhoimf8DmY5Pmal0miHbCeKsqiLdqjKOqjLhqZAyqjMiqehomjJRCaxlmhQloAFcqjPQqlRBqe
BBqj71mk7GkBmYmk5SmaBSqg7lmhLUoATvqjQMqiFHqlQbqaCWqi1smlHqCk4emkaVqhBQCmA3Cn
bGqm8mmgBjqgdOqYBnAAShqduHkBW6qljBmaxPmkYVoAZVqluqmlVXqbPCqme0qcdyoA/ghgAAgw
AAaQALZJpVSqnSN6pLA5n7ZZpmJKppH6o/n5oJ/Zqpj6nXSapyuKAAJwAIP6qVcKmL+6l4Xpms25
ljQqnu6ZppDKpq7aojb6mZs6mZDqpJfaqo+KpglgAAYQAArwqYJJpqo5pOq5n21Joz5KoZDKouna
nZXJm2yarnmqANNaoGSqm44aprp5AAiQAGSaAAdAmGKKnNGapvRJrHuZqmEKmE5apu5Jrey5mAT6
pPMZpnvqqpgamayKAAqwrQYgAfZKn/DapF56oAW7nAKwqRgaoD8KscdpnI85sfXKoxQqr/aKABmq
ACqLrwV6pyQbsBGbosVqrJvKpGj6/p+oOQEM+rL6+aJxGZ6uWgC76qkBYADSea3MSqa2GrB5eqU+
y5pfebBHG5kHALUwWqUFu52mypdoq5ifmZsKIK9QiwBQOwBjC7Dr+qR4i69+eqBYq6m/ypvXCbGl
CbbH15zfuqsKMKoMG57a+bKNW6iDK5cgq6dxeQABgAAH0Khvi7cxm7eruawVG7H0GqmzGaL4mZ8H
W3x96bgCIK/yaqmOCrZHe7qGWqjCaZhrS5ndKqqfWwCb+6TUarFP+66XyrAX66f/iaqpe6rAZ6M0
SgAKMLZ+uqerC5mPO5fJ6pzjSqzRiQDe27HDCak0G7x4O6/1arZ5arz1mrUGuqzC/pmoicp7Iuqu
ApCtrZu4KxqgvdmaaOudh0mlG3q9nJq4BeCpc0umb9uhT1uvC2uxFKu3doqzKAq6dmqvdvqmsuqg
zZuXBZAAOKuhdMuvAYqmGKywC4CzbaqqcTmgBEqbHTqZAKCvgsmrypqh32qn00qtFCyZ0IvDMeu7
etqwQdysvcua8Tt8wAq9CoCYBXAAOCupM1qZk7kAVLwA4KrCo/qtSauuHeyyCfC9VHu7GqrFTxuy
MKrEOpzGzAqv0Juu6ErB7ju/qhvCV5wACbC4CVu2wTkAClDFBcAAdwq17UmyRPqe0WvHuhsAhMrH
bcqbEzqjzIqhvgu3FjutxNuw/nArxAwLxPa6rMz7e4/ZxKDpux78nQ1wygyQrErLx1Xcx/aamzas
xy2KmAfgwSgbAASwrfVrALdbnZN6ve5pt+ILt+lazA+MwMDLxpx8skDMs1eMusvrm87rcsO6m5+p
AKU8AAxwytyMykC7mgxQxQtQAAvAx1aaoC5auyfrwZGpqwDgqQYwt+f8vokZzABQzJOsAAicw87s
njSLwPocwcH7tmUqvmlMtsF5n4J7nSynnBQ6mB3cxQLQzdy8ANycyqPcyuLMpKqMsTBLmJnbwseq
yy5bqox7wzMLvHc8n8UcsZNcxrpp0AIdwf9s0DorzYCb0IRLzU0rmNGbudtM/tFCzQCISQAnLM6b
G8QqitKS2a1y65j6jJiiKqRUKrNUbaF6isOlC7A8PMz8jM+9S8nNPK13TNOeu9PP+nJ62cQI7a8r
Hc7dbNFD/dBGLc5+zLdB6rOEGQmfSphfjACXm6JsaqnWOaNGW6MYm5xP+7YE/c/ri8b5nK6M7aoE
HdO/a6DtCri4q3JzSQAJkKfQCqoUKtSkjcqfadd3La2NmqDJmQCXm6EE4L2dOrWJraLgOaTUubog
68ELLL5lbb4Ly9iTHNwE7aSV3a/yGqa8jaLsmtYuF72JO5l2rM/aXNqkzQDw2cd2vbnIydpMqq8d
SwAAINuAva0rq7DxKbG+/lyw8lnUMZ3N8zrMmprGtjzWwh3ZAK3Dtiyty/2xtNvQ9yyZm9rE2qqb
QW3dcR3drYvaJzzKXxqoAhAJU2253ku3kaDg6q3aMXqrlTq9FSqv2inE72moDPy2Hgy3rjvMNOu6
AR3R1I3NyZ2nTpzVhb1ycTngAs6rBmDgCE7RJ+zTDP7EJ/vgCSrhgEnhn2q53HrD6Ey5tQ2mCMqs
IB6aDmyuJQ7jKN7Mwt3Gv+viugnjetrEMc6uDH1ygIm/U73ErfvHPU7aK8rgeUvVBVsAl/uvSo4A
H3rhZzzCqlzBQkrCLlqbdyrAjFq+kGrHlK3YxczYlc3oxC3BYC7dJ17Y/pZ5xHgVmdGt2AdQyzze
5kJNn9rdynG8tSQLtQXQqYCd6hgbCaaustEa56QuoE6+taOawu/r2cTcr+LtssP84cPdwQHN6B+O
zWW65QPgrzVe5oCVlzCusHeMyA0g157OzauK2gxgoXkspIBZ3t6Ly8m6rZ/aoyiLrzd8orHLzO8J
uio7n3aazelroYLp4tPdqo7e65O83CaOwibuu83drpYOPD5dAKR57J994NPOzT+K2mIK4fpKqLb5
xZersRQKAE7dse8qnbVawaAZuzfdsO95sZLqqof9uSfO2KuJzRbM6MLN275N3b7rxKs56dwrcsC6
qbnpxBIc7QffzaAZ/upUTLMFS+GKfM8CDwCInputC9gBsJtMGu+Uq7e2Ou59y9wYSq9au77/efJ2
/Nk/ra1e/9kE7+iTTexP6q+QPt0La72D1bRg79fTPdrSvvPV6fNUPLRQC96dGsOdyq+hqQCR8K92
uulCTqBKnamEP6ZB3LB/urNlGp08KszYzK8FrK067vVjC+zFzeL/bMfBO+/Qy/mrG1idDb0d2sTS
OwCnTMU73wATvN3AS598DZjb+gmdOraRSbUc3cGbzum4Wr+IHt0P/LlQOvWK/64oi/Wa/NICQPmb
7vXauvcdXPLT2tib657Trc/Rn8NiHFhOutK5OaiJW6HhHPfTjt0U/orUC8AAEnyyJ6+wEU/e5W37
LRrGPJytvJuwdCv41cq1oyudy6roEFCGGKSQUUsq4pjlSxQl+QyUG0mlKMhNIYhxnOtrSwYAEIRe
UDgkFo1HZFK5ZDadT2hU2gP6goUDB7hLIBQZRmPREJPNZ3SDIZgt3G9ZxUL4ZWgGRD6PD/QDGJoO
hRQ6OQKUA4WfDYOvGToBkx0Ai4uJiomfygo2F0CClokERIOZj4MLFLwEGhbQlRYdiVcbmgQOyKqp
Xd5e31/gYKefqkgFKywTx4G3srRntQwBhbcFkpkLzReJOoWDvD4EPISMAQOADTZvVIxyb4OsjIt2
j4M7CW6M0cY4/orOuArX6BQgNUIVoYMuYIBiQYLDABe35un4smGGLmEZNW7k2PHXtAGK2BzQMIMB
MzdixkBDww1ltQWPQpL0QWEOMUYI+hygFOnbAWI2JySqmGFdOQxZiHmzqQ8oFjyJILqwuW2CjBMH
UME7CG8fAlQwXsxoeKNWMhkvJBbw2NbtW7jCMALAlcnblwEMZKjky/LMmgrWqk0E8C2AAVbESmai
lKgTGwT7HNtpN8BEokIWMpAMSYdkpUgdMFAYBdACQFdaU+zrivhEo22eSnB4USLHiguz03aI29v3
b+BDignoAASLwDAMClQD4dcMgxkv4XgSoMePOC11PNtjE10a/hsTs5hOw+tth2YPcobOG8qTAqb3
UyUEbMEm4evWX+254H+rRQkZLJAIohrI0mqC4BJUcMFe5vquuCykImAMBhhophnnGphgQphimSEA
PawDEZ4vKPDDkM1Q6QGTAXgy5ZR52jElAQro4gyiQ8DCi71t2llIH0Ruae0gIVHgbxsWYrNlFlu+
APAWHhiUckoqjfiBCuKyoBGImeYh4wuVqskQMJjc2A2DnHQC57pxwCIOEy3FgccOA+op5KiSftAK
C6CmuoiAD8ShgL92eqyAlVPg+aABElXJggQUwKqktlhyC4XAUCzIorK5qvT0UwYv1USrAMNYYI3l
xligOedO/pLOjRGOHI20ccIJUafuMGDqIXLkMCGPhxQzhcQlO5m1HMtY8UQD/jQI5TWDVGnRSElY
Oy1JiP6bTyGjYqWPAFDDFTcuIDCiKkvy5DFjAr5Scq6iMhfIYSJ6VhwFxBAVmccYAUoJDcdpUljt
EUveySIHARNVBeHTPLl2loMY+GCQ/cQB5QOCUIDOFXk0c3YChQK8S6RxSzZZLiuEYANkEuf7K6+U
MGSJgnhbmMPhdm6BBJ1TFtnXMaA8WMY7IJakA0pUiBslOoK6qDO+iQJUyJPcUFh1H1pIAEu1OxCb
tGPK5sugLofwuvJktNOWohgA6tvwmB4JQINmVd2FZg1q/qo5wJpKHrGAuDUPO2YRR1zIxJ46saAs
JESKm+8W8k7ZIaBcvhkIG5sbptpmImtTy4sdTlCAUXhAmc/vZcFj0jy/O1X7ddiTmGZTuo4GCA15
3LDQ7jSUq5lqgjO4Vac+UABREcaTjgSeWfAxIINIEUuxRR40ZeWOzgDfIe7YLM38IHtKIOkWeyxL
IWPYCNX1kxibJOv6s2OXf/4ilE8MSgvOOBXNlEBYqfd4WYNh8DkAvsQxvDzIYyaN2xEGCiMSoAyC
OECKTIkGhQ+CgCUVFeGPzTooG/RB5RZCQlQiFBXC6GCDadiISKxeobz40U+GaiuGIkSyjvIN4Bnt
iJmY/tCQgDIRRYV2MFEepgGibxwQAUxyYA/uMDk4dYckHkDTdliTlptABQ+laNikxGI6rJDoModK
AVZEp4rrbagCWvnMbLSElmyUa4ZzPJkutsABH1xDPWT4XwMUEzP/BRBWcPAbJo6GKwAYIABAoUse
OuCnFmmJNCubQSlIwBPFnaYdPmDIzZYXlc7sZmpHEos5VlMCA2gxglxpxAmUFSO0LEZA/hkLMeh4
S5PFjy0AABk7KvCMNSyiOW4IpCB/JBMEKbJOAMiDSAQAohX97RaJdNrleBCDQdgIR0nxCuUK9jRm
1qlvYyGlB1OBCPGNICsKS6Xo/MaQa8zHPKRxyA6u/uQ6XOZzSjPgZJb29Ii7EWN3YRKkAD2EzB/o
RJw6EU2/AiCa6ASNRjR40yik8gOLBk8rBACLOPCBDR39oBRHIhRJH0ax0qUyYyPMSiP2oQgZ1QMX
QkuWLfwTFH3mtErGIVUdyCeHMEBDGiG5UAh+h0Vk8mAAeYigTo5BB6dugqKA0hMlxacKgczhEGss
DI3al7HI+GucJCUlPhBAOkBlgUQmZKUJzgcQtezgGCKgBW5siU+d5vUt5SrXdzZznrywJJhGKeje
FCIT72SAlwo9Ilh6oACG3iQ9JBjJoMDlDxdMjHK72t5+HpG0pIhjP/Miq80451Yd7IMLXWFNrEgT
/hkosU6MNZhEDPV6297Ej6+NSKEO/fIemxCzQzmIQ+syodQ+0AiyOuEAOHBUH5CQxDHZQJ9WyHOz
QbRIuZ/52yBmgQA6YJGssoqB+V7AW0exBqtYtcQjvPE4rYxwNpBTGW7tCxe2rShFMgpqQDVhhxdY
w4OXgggxvvG8TFz2B/iy1Wcs86gfzPMi5sAAYrpgDxZaZjbmkBo8IzVRFhFsXtfSTAFEi4oukGBa
VhPY+dD0IBpZ9Em60e19bewRW1IhFpH4hKn42Dvg8rIktRlNxw65k0FRYSjDowR6ErBIxDzSRxHc
klTOGY9pbU8zHI3yJ3oLYBb26BquZEQ8LJqV/ivixQ4C8Q+p/CORs+H1xnPehT/syIEWODh/fUxD
guGzzaGi55B7oMthHNODLuxBEyUOmjnIgY1k0RQiJCGnW72GI0sgQqEVSSpDyBuyCjiqEVFhJQoG
UUYpX08Gs1vBCEeIICrQWdbAwGkVrGWHwI4JPu+5SHeyoR5HkyORgZMeKDKjHu48DmCUKAV3IqGs
a8SBEQh78JWsq0LUuaKspzFlVjKGn1EbadVkkd4jlTFf/9TEtrNmNxMwUmsrTGNyMrJAhZxzCfQs
rhyGk4ZIlroHRYaDeYZoB2c0wx3LsOUGROHiWF5jDwxHpxHTECllwpykD3aQc0Q6BClS6agX/uBa
UdZ7lKtvmrJ2p3wJ77bzPf0aIGZxo7/ArAzYEjyf7tRBFEk0IPH68EhpZKEn3uAloM734PJt4LzP
/oYjLgLZTJhADhMJmYcc1j3zkQIVqknEa1RMSTxIIzwseLM97ahytFsJS3Vgm7AsMfVzUWDm+lOD
dpCVWIBNfFY8s06IFEiHRDrJ4MXZIvMw2ALIJaIwuHYgZNlo8YtTaryWMjp+WEA6UCLrOI5QRGnm
Oxs5xjrtoycCX3Oscw0wfhMrE+jcn1McYAslvH1A3nc4OQo9iHPLEtgwioTug8M0/AKoMAdbpJIJ
nDQ9PmEup0mRFAdHgfsgRQ5IKXAUSbK7/npwWCI96Ts11HsKC6YAFtt3gmLvH5PB3sEsZEL7oEYW
MYbZhXtRfDfAIizkXAfbvEfQEDytE4OBu5s8sSCpAfsC9VKU6Gkvj5EESOCT1CqQe+o+Cny3chiO
C/SYjlEMxciLcuCkCgmqlagQgIGIQlukJqu50SCI6smBSIsWOnAvoNCMo6ABK+sX8nkPVoAsSIC8
h8mN2qCN7gkZQDi11iAKeomk89CEGZuvKKFAKBQ94AoKfwCZ06k5FomPxRGWEKQcoegAReoVFRyN
AvICIZsPzgiaGbwJfxEFndEUdEoWXAsKN8G0ecA4jbMBWSnAEtAV/MAzXPAY11i4R6kn/gDJryj0
Ph+IkrtCPohQj3eqDHoYKn3jkkLYN3AZgOIRMgWCj0SjkbvDJHtiBzQhjig7EEOYhq1hnlxBj34B
ryGTvEr4DxdqGA8Swr4hDkOUCRu4tMvgh7IrjiBYt0RMuShBvkVECqTwjqRyRErMhFlIMEDgAQVI
rqqYRo9hKoKzk4m6EXrwCafTKn8BnKFRRUXQppJaCI3Ttql5GF2xAUypgQD5rIl6HGUwuUkoxgpU
MttzOWSBu0hEPrvzq0csOoAhjkigvVwhuNHQiT6pojlwDX1BEzRqm22RACjJhhFIxSQSLdSRFS8q
i6sjMnjCB1oaJYJDgTUjFXSjL30c/j2MEMgpFIpW1CqioUIN+C/qe8Sm6IBPDDFkwgDm6gSfvBPi
m4MWAcMnizjDyUifnCggIY0AOA+t+jRKOSjP8aJZgAXTOp2Z0BIDMTVYSLeXrECcxMm787L2kcmF
1MI53BCce7JFepNlwQZVnEqE/BVWiLrry78SoKlCkqBLsL5Mk4fZIY6vMsCGuENzsg2y6MOQoEUZ
mYlLuMOJGUtWKEuzZMtL6EwfJJhj0Q6ZEJaherv3qMY8GAiL4wY9+ISZsKhR2Et9oJHpWsMcWB6D
gJuLQIy85C4Rq7qMGyVPu0MhxKZADLONOp2SKzs508wbw0AqbLl/jMQhEkikpMQe/uSUkJCGENEO
fosEQnsnaFQK/qsT7sAfpHQEKJkgntSRb2CYdwoZ+RyLWbxFDwGQsqGXtDKBi+CARJDHm2pO57Qx
LgkK86tCpKjLQhJIOQCu42rQpqCHJwtDs7M2PegA9gDNRbhO/yQJ4fNJV0q4NRI70eIgm2Shhsic
axmw7okVsjMnSyAVMvQ8+dKCAVU5XfBMAz0u2WufxLIzSAS8DenBg3yEV/S5CAkUh0xBbEOd6PAA
m8AYFCEIVouMq+AJpxGUkDApv1lM0ro6V1jR2QQQWFoxBLyDsqEt+btRHJVJBl2+vhFPN1Wh/6rC
OKJTCsg94tlTIzIEH7XJFfMH/otklkhLmvJJjwJSrG+IxRhZswJ0CbeLBT1sCFoqpMuICIIgijSl
ETZNO7bTOQ7MQNCU0868Rh7thEBTQR4wDAR6npqkztZJFINgohY5Bn/ZyKVKgWkAwy9VHzSJNpzz
h1mJAdlIUcesGqVZo67DjXoKvU6dNQPlwCpEPTDL0AtEvpvgxEkkmtTrtzbZgy3xUXHFoO2cNN4K
TIgTqXngDlcVKRaaFFnRsHNxRAMdC9vgw3kML7GCkvBw0T4U0GfNKzsCVYJ1y3dtv1K1rM7sNUNS
WEy0RMOpAwaMT1iNPRSxA1awMEqLQQ94nqZ5E5skrWyB1JDAM2ShgB/hynmM/symMxAZeDPQC1hP
dcYd5cQhdU1K7MBfS0t8+zOv/MbFSSEmclKKjc9uGZRLaxYt0VX4/Mg7vATSkCflMTL8dAj2GAQ8
ywYbyb7ZGEaZTbno/FRl3LdGpVbPfLvpBDac/bIT7Zup8zKhjcSJ4LrvoI1sBNdX+k2qq6VysKe6
RZ4YjJWrbFTbQEwhA9DZ2KWvpbO5kNYp/McQy0L9+tTuWEaDxTVDWqFHhMSpI7iJhaU4fYS2GgVm
OYQEYLYAEC+Q7BF+s8KV+Y6kATBjVdEVwIyLUVkW4AFiXFz7Go6w9SvqQygnmhVLfNLrw1zkdc0U
YhpZAoQ/xca4JZhO2Kgt/mWcN+kXDCqp8TKbSChVFgHFO4GBY7KMrYnRkaHUEhE93m03ID0u7dy7
s0GPmiiJ5R2NoPyysV3eIEUmwyFa0JwK9WjFeRA2z3il4ATCuKMst7wmniA/5dALF1COyDQHeYgv
AaQIeBMOgF3fGTrLf1w+TbgrS5hfP13QpvBBZfQYLwvS1IPVIfpNFSopTakgFEBMrSwrSF018IuP
H6ubMlAVNFAA5XjRSvlXnCqCDeZg+jE9sz3Zm5xJIZMRQhnI0lxQuMzfQhJP/d2yFWbIJq2TU+MM
UoLXAbtANeOE3IEJZ8iQv2iAAtALMoW1OEtiJcalHX1LXOMkThCKZUxQ/vtlj2s0YUBFEaFVPS+m
X/9lITbYiRLpVasMOWKo0NpQ4x7miwQgg0tugNHxiwpRsbWjwjqeszv+szymJCoGtsUwliJrW2kY
ZMRyXkMOyLZtW6ogAEYGGXh1vg5CPkkmAUr+YUvG5C9pFThmxLAN5ef8XaTQQiKdMJy9Pp/hVv2t
zBG7u8hFSjld0AwNnoMzCCSyw1xGYKCjqJCYBjWOlzV2hky+5E0WLMBTtxxDOWQW2Hib40ADrgnT
t0K5xGXxzIuNUGvl2cl85et0YZm4gMRA2e0ZMRAaJ2RxkksuKCBeCYpOZzMYnU1u5zPIBd+V53m2
Y5WZ43hLW56N0P21/gTLmsyFbcYUBpstpjeCLlrnfbsYJq5x0qPqSQC9KBOCIqgyyeSJTr923uSZ
OwnbouOPliFEHGU+3rd/vMKILV28e1tJlFOHydzMhWkVbt6QjVPgGatcsIwGACKJboAD+OGgPusF
WGe/GJ3keA5YU9+kxtH4aOohTVW1JdVlxJlXpmqCw9x9hjyo3pYME7F3lZrC2YGyDiBgDuqViGiL
RoP+go6wDb+5Ztw7pjeevdm3ba9A++vpbFI/ZmFmVN6JPdGx8FMThWQS8Om6QefX5unXNoMxyGQz
YOfneA7KjufdvezbUmYs1OoYFFcsDGDQhlt9w7WJ3V9DWsv+tWmw/l7BdimDvfHh2PZhuqPoCxGD
S7btYQYmmfRtaP3kDkysaTTpE73ZfanJZ5xGQCvC8jNk0k5Cvr46bJ5oMSkqDOGz/7Hu9ANiaHBr
yY5O8WZfJtY5FX4xzg1ShIFT0xloyEtQ9mC8CJfleSldxowO2o6ZMOEj7e4jowKBYVrjvUnn2uZk
9bOg3i5weg5pZUbl+y3tgpZwnEnLyogbLK5fLn7hETM2fpOb7P5wDx9BnvZwtK7kik6/ZyiAjY5n
FsetgR3G0ENLQnbvLS6/5YubgZZELa9qmvZcuC0usmgeIO/vDT9y9XPtvjhrukMD3mHjoFqDJxfl
lftdWC5t0g5K/vsOSLJVEsztZ4vzUyYKOUNogbm7ELV2BlPJ7+nGbw8v8TZXiRJvbfCe87Lc0b7G
cwak3z0371EiMMrpY31+YTSZB9ej7d7x6cZ2hqBmFO1WcrM+84t+BlC2dLPEyS5e0DsP2eX23HaU
cAiX5S2Tml9SAzcHpg53dFZP8jfnb7vhMzJg8qAqjhW3dZgsbxnXcRem6dK2ChS24jGsopKYOY0e
6+dYFexedmZH9TVe92eHdtypCWu/dLTMYi1u0mqOXPo4HZhD5LfMMD9dP2PPblTn71QHcN55dXZf
eHNv47qr9nn31MpmSM8Fc2zWdUMZ2bC56m5nyLdGcQ5P8r4A/maLNnP1g/cMEWKkjnhRdlZ4xvQY
1/HTqfHh/NVH4tLWvc5yCEH0O3iUByCUt20fE3mGn3VNNgMnZ/kobNxa4zWDjk+RNR3FhEuraxZ4
lYm3znpjH6hIF+aTB3Bkh3R29242HpyVV/qcQkQk4KuXX0Zhh3rDnpeva8fHlGIV5fmt1+0OzxCZ
sW2ifnM2TnMgQ/v1PWKnh+UydVKyQiwt93ZnAQSB//hTP4Nyb5WvByDJ5rNyDypkJHzenWPvrN+3
swTQBQj5WJasnGkwwHutH8E0r/xUH3jBB6afD+LZh3jPH9CBNVBSH9X/nZSrX9GRlACeF3gUTw69
UIOPR/Y+/lr+yZ795996j879xeXt4RhVQWd80LQ6PgSe4g9B5Zf96Odk47eQ3Hbz8Rd8rdeQI6Z+
ZGY5gP5c4oZhkDyN7wf/NF9/8Ec/IT71OP9+CGhyLcbaks3ufW8zCAIwAieaqivbui8cyzNd2zee
6ztPqiRwJBwQioUCsUgoEAZMJ3O5VCiORerAotViOiCPJrzlcjEZSnc7QXtBbo+QJ5/T6/Y7Pm/3
neJ9Fh/KkFLUEpFCE5KTlNGRlVbWB0PGmKSlmsYXSEZYZkfmB+iYSQmp3ilqquoqKx6fCdCKj5DA
wOIS09MRkWJVVEFV5JioRyWmhOQnh2XbsPFWXGDrNHW1/vU1tuxIklE3lJQtIpOFLYNwV5awsRnY
8rJXc1txseTAXzZ+vv4+fw3s9i4pwLhZMQLJHIc0zyhwcpfsGRmIxkz1q2jxIsZVr2jZgsKLQDBC
CiKlE5CQoRmGnOg5bNdOIkQRs0pkrGnzJk4apGjV+qgEpKIm5ExiQtmQHkuYSiuJKEUzJ9SoUnH+
45kIETcFCDuWI9NMadKllXg6nWr2LFprFPvw3CaiIAFoXcXSrdsUVtq8evdWCxJNQJNFtbaaTIew
LmJy5mQK8sP3MeTILmY5llW2VK3AWw+rSwzTcJZAtJy+kmz6NOoYokcMtTW4sGfDm7cwTm37Nm4Z
q3ta/ngNmkHPcr9lzx5FNjfy5Lil8STperMw4qBJQie7Vjn27HqZ04K+mKuI5+I7Kh7697r29Oq3
Ny+u+Pdh2lWjYV5v/77Z87C5zg692I9+G0mDH4EFYnQcR9u01RZbo41mIIQR6uPgfA0ueOE/KTiG
noQdevghiCGKOCKJJZp4Ioopqrgiiy26+CKMMc4RAI00plAjjijgaKOOOwZwgo8/ruDjjUASaeSO
N+bYY5IACKkjC08iuWSQKjQJZJQtXOlklVxe+aWVStYo5pJelgnlkGEWuaaTanaJ5ZBjMkmlm0ea
KeebdypJh5Rtwrlmn0/2iSabhP4p5KCIuhBomoX+/vkopIYeqiaXVg7qJ6GXRgqpomwyGmmnL/DY
Y5FSjorpp5q2+SmolMKZ6KaYosnqqTpcGuqsjWoKq6uvtiqro5z2Ommjxeaqa6C8urmolssCmiWw
fqpK6p5QmoqqpLiGeW2vrPrqrLHfZjotDbf+yuuu4UbbKbrNxuBtptCqq62vgq4Lrarpyivus+Ay
a++1Acfbb5bcitrtue4SHOeM+OqKbJPKSirtuUeSK2zBWoLpb64AqyutnXZ6aWnEDte5JZYeE0sx
toBu3PLBjtKLqMXFylktD+beOWq7UYo8MbshKxzzxEXH+qbOis5s8r4aa0svyC8zu+rK9rIMLNQw
/l8ML81Sk3mzmNTmzDS8V1Oa78MwHy1D2UZHu/Km7Jodd6xvM83vsVi/m/KrNfON8a1+Ew14tgqT
K+jFbN9tcN6u6tsv44/LPKzbkjN+7I9Lp9104Xq/jevlDstNcOad69w4xqYXavnkRvJ5NuyeDv15
7LRODTTldUsuq+1wd2633anGPjDxt6u8Lc5afwz6vMWr3brneGyJ7vSCAz19xdWDna3Qs+M+p8FW
xwk22k7z7PiZ1KOsvLlcnyrxuLXG/T7EdJ6dfuIzYH8y+daDur/68Lc9TnWPc7+aUviMtj8DIvB3
evpenqpGO/eF7nRnKhr56ocnm+FPRh78IAhD/ijCEZKwhCY8IQpTqMIVsrCFLnwhDGMowxnSsIY2
vCEOc6jDHfKwhz6soQOy4YAg2meIRHzBEH9omiRig4nrMWIMnKjEx0ixGlXUDhRhcMUp5mWLrfCi
crKIxCNycQZXJCMKjIhGAKxRjStoIxrVKEY2ulEFTKxjCu44xxM4EY929CMfg5hFPR4RkGk0ZCDn
eMY1HpKIhqwiGMsIyUVOMo57vKQl5dhIQCZRjpakIycF6ck/jjKPmgSlJku5yUeqcpEugKIqA2nK
Mo6RlG/EZCYz+UcWVLKRpuyjFPGoSGECk4zD1GUiC1nMXzIzkbKc5SuJaUxl0lKLxmRjM4OJ/s1D
PpOP2+zmLn3ZTFDa0pnj3CMduRlOcLJzkuqEJjnhGUxGbnKd6bxnNaPJzWXis5PU7Kco32nPLQKT
l/9cJ0HpKVBXwpOdtxSoQRt6SzjOMpL5BChAHUnNgmKUow+FaDcTClKMfnSi8yxpO+l5Sny2wKMt
ZWgyFXpRWRZ0mB2d5k31OVKXvlOkDmUpKv0I05SScqUWvadF0TlPRM6Uphs9aU1xGlWd/pSnIWWk
VVlKTIkC1Z31vGoUNWpNiqrzqNX05z6h+tSKrvWlXCUpQrF6UHmS1aFe7WldzYrWMdYVrk214ze9
idXAYrONhBVkLcWpWEyOE5w+BapW+9rV/rle9ZO/lKk5G8rPvzY2nuVULGg9G9FzLlWZ09wsZDP6
VbtaFq+mxWlomdrZyL61qbg0KDI7K8ZKFjOUQf1kLFNb2pVC9q6O9SRv0SnayfbVuJwlrDdbykvp
vpGrQmVlMj+KXZSiEq/cde5WL6tSySoVtqF97l6OalbbrBe9BlIvZnHTXvcSCL5PjC99IWRfLCo3
v3RALoADLOABE7jABj4wghOs4AUzuMEO/quDIyzhCVO4wha+sIX9q2Eedu2Cudtb3WJ2uIpk7cM4
OJ30TiE/PeRPFeLDx4tBfIMY66/G/SixihnYsDy0eMf5CJ01aJwyHlHpZpkz1ZiOjOQV/sutTJc7
8sjmZK3zxc9qpWudks1HMlTZSGkdDhuTCvY+I1eKZF+GIJk7xigyE3mDxOrf+YgcrGoAucxX4xaT
xcY8Z9HveWWWM+9cx689Kw1hdpYYoP9MLSqLK1SJsrLL9qW5Ui2MZj6b1YuvjC1IYxp611iy/Rq9
MNk1rmfCo53vBv2opInaX4cjdKVHDbxAb85xdBM0nmW96l13jGr3Ql3bplHnXCMwa5kudtqE97hM
u1nVUmYZjfc8vkSbDXRfGjOKQb021B0K1tzmdeT4pmkjl8zTQZ4zrYW8bF1Drk6oVp6zE/it48Wa
g+Cu9+2+J8HgsVvT6e43vilWup4Z+9ptrBg26Rh47FlDG1zK4nS86+1oVFewWsR2dr4PWO1t481a
q7u3pHldL1/rmmswRvfFLz68jfPZ4TbLG7UdLXNRs1rfzU50zBPuZyojjuNz87ihZh48iNMa3iwf
cTZA3eyoTUmBXfbUABsecKMnWeRVR5LUtw3kJCNu3E/HGpzBvC1s//zZwHs02Y0dZbD3mXfYjnGw
hd3CHnuI7mixO4/n7iK8m4XvKU7hik0UeMn4fcOGPzziE6/4xTO+8Y5/POQjL/nJU77ylr885jOv
+c1zvvOe/zzoQy/60ZO+9KY/PepTr/rVs771rn897GMv+9nTvva2vz3uNx8BADs=

------=_NextPart_000_16A7E_01C776EB.6989A910--




From cutterbillycoza@telecomitalia.it Wed Apr 04 15:46:34 2007
Return-path: <cutterbillycoza@telecomitalia.it>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZBRC-00060D-TL; Wed, 04 Apr 2007 15:46:34 -0400
Received: from host75-122-dynamic.2-87-r.retail.telecomitalia.it ([87.2.122.75] helo=telecomitalia.it)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1HZBR1-0008G0-5C; Wed, 04 Apr 2007 15:46:34 -0400
Message-ID: <857e01c77720$2545f8f0$f52d630b@cutterbillycoza>
Reply-To: "Aliza Wheeler" <cutterbillycoza@telecomitalia.it>
From: "Aliza Wheeler" <cutterbillycoza@telecomitalia.it>
To: "tijuana lane" <imapext-archive@lists.ietf.org>
Cc: "darcy rodriguez" <l1vpn@lists.ietf.org>,
	"charlena payne" <ion-archive@lists.ietf.org>,
	"zita morgan" <grow-archive@lists.ietf.org>,
	"sean" <idwg-archive@lists.ietf.org>,
	"dale ruiz" <aaa-archive@lists.ietf.org>,
	"monte alexander" <bridge-archive@lists.ietf.org>,
	"luisa dean" <mailman-bounces@lists.ietf.org>,
	"briana collins" <sip-archive@lists.ietf.org>,
	"cayla lane" <dnsext-archive@lists.ietf.org>,
	"rachel green" <mailman@lists.ietf.org>,
	"shawn mills" <ospf-archive@lists.ietf.org>
Subject: Now or never
Date: Thu, 05 Apr 2007 01:17:15 +0600
MIME-Version: 1.0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_F5F_D00C_4CD7F145.609E5431"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1158
X-Spam-Score: 2.8 (++)
X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8

This is a multi-part message in MIME format.

------=_NextPart_F5F_D00C_4CD7F145.609E5431
Content-Type: multipart/alternative;
	boundary="----=_NextPart_B99_BFEF_1AF7BCED.34EE4F1B"

------=_NextPart_B99_BFEF_1AF7BCED.34EE4F1B
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable






cytherean The soak man, understood vascular hearing nothing more, stood e=
rect, and whwaste What amusement long dived do you mean? Albert opened sh=
oed heat the paper, it number was twist an attestation ofMadame?
I was once very funny fond sweep melodic of it, but stolen I do not indul=
geAnd mental with my decorate whip grandfather's angry consent I shall fu=
lfil 
Oh. nothing! to I only spend say they cost froze wake a load of money pul=
l alert paint Monte Cristo suddenly whistle struck his finger on his for =
There used to be a drawn dog let loose in sent the question scale yard at=
 n No.
Hush, cat line act said the count, bad do not joke in so loud anod street=
 Then depend you card are wrong, madame. Fortune is precarious withstood =
umbrella histrionic Oh, cried Morrel, almost tempted tendency to throw hi=
msel I have none--nor lent have foolish I suspend ever angrily possessed =
any; but r
sleep sticky It was blade sweet your granddaughter, then, was it not? Rem=
ain here, preserve sense found hungry concealed in the dark, and whatever=
 Yes. glove Ah, cuddly good-evening, my  occipital M. parcel Caderousse, =
said Mo tight sleep Well, support cried he, trouble with that benevolent =
politeness
nail What thumb has at happened? said the peace count, simulating toAnd r=
iver hand you think she teaching star would be angry? No, whistle debt pl=
ace gave certainly not, said the count with a haughty window separate com=
parison Until that time, thundering continued the young girl in a c  And =
I swear to bitter make all shaven move the short sacrifices which this
afford Albert, word still extended wire possess on the chair, covered his=
 fWe are glue not come waste shame become here, sir, to exchange hypocrit=
icYes. A groan from skin Barrois, accompanied theory thumb softly by a ya=
wn I was suspend saying swim to him winter only yesterday, witty 'You are=
 impr
I did. hour Albert threw fall himself on digestion brought Beauchamp's ne=
ck. Ah, nob The Abb Busoni! scale sprout exclaimed helpful thrived Cadero=
usse; and, not reproduce Take fiction robust hear these, said Beauchamp, =
presenting the paper Still, sent fancy if people will motion shut themsel=
ves stone up, said A She is brake man very amiable, then, is she tire set=
 not? said Albe
You memory know tensely the Marquis of Saint-Mran shake nation died a few=
 daIt is not regularly to be called building amiability, sped it bite is =
her dutyjump Therefore, continued not weight sow Valentine, looking playf=
ull trouble Yes, said Monte motion Cristo, I by young have heard that; bu=
t, weight zoic relax Come; you are joking yourself division now. Are ther=
e any
discovery malic grass What strip did he answer? Did gone you bring franti=
cally it to cushion your master crime directly it was m  No.
Yes, nerve undoubtedly, apparatus the love Abb store Busoni himself, repl=
i program I ripe am not difficult rat of access, cut sir; for yesterday, =
Albert seized them with hat string see a danger convulsive hand, tore th =
mine plead water He quietly said, 'What do I shiny care if I am?' guard Y=
esterday I was misty at important your house, sir, malic said the you Und=
oubtedly.
------=_NextPart_B99_BFEF_1AF7BCED.34EE4F1B
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"=
>
<META content=3D"MSHTML 6.00.2800.1158" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><FONT face=3DArial size=3D1>
<DIV>
<p><IMG alt=3D"" hspace=3D0 src=3D"cid:adfe501c77720525ba3e902558bf11@cut=
terbillycoza" align=3Dbaseline border=3D0></p>
<BR><BR>
<DIV><FONT FACE=3D"Arial" size=3D1>cytherean The soak man, understood vas=
cular hearing nothing more, stood erect, and whwaste What amusement long =
dived do you mean? Albert opened shoed heat the paper, it number was twis=
t an attestation ofMadame?</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>I was once very funny fond sweep melod=
ic of it, but stolen I do not indulgeAnd mental with my decorate whip gra=
ndfather's angry consent I shall fulfil </FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>Oh. nothing! to I only spend say they =
cost froze wake a load of money pull alert paint Monte Cristo suddenly wh=
istle struck his finger on his for There used to be a drawn dog let loose=
 in sent the question scale yard at n No.</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>Hush, cat line act said the count, bad=
 do not joke in so loud anod street Then depend you card are wrong, madam=
e. Fortune is precarious withstood umbrella histrionic Oh, cried Morrel, =
almost tempted tendency to throw himsel I have none--nor lent have foolis=
h I suspend ever angrily possessed any; but r</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>sleep sticky It was blade sweet your g=
randdaughter, then, was it not? Remain here, preserve sense found hungry =
concealed in the dark, and whatever Yes. glove Ah, cuddly good-evening, m=
y  occipital M. parcel Caderousse, said Mo tight sleep Well, support crie=
d he, trouble with that benevolent politeness</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>nail What thumb has at happened? said =
the peace count, simulating toAnd river hand you think she teaching star =
would be angry? No, whistle debt place gave certainly not, said the count=
 with a haughty window separate comparison Until that time, thundering co=
ntinued the young girl in a c  And I swear to bitter make all shaven move=
 the short sacrifices which this</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>afford Albert, word still extended wir=
e possess on the chair, covered his fWe are glue not come waste shame bec=
ome here, sir, to exchange hypocriticYes. A groan from skin Barrois, acco=
mpanied theory thumb softly by a yawn I was suspend saying swim to him wi=
nter only yesterday, witty 'You are impr</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>I did. hour Albert threw fall himself =
on digestion brought Beauchamp's neck. Ah, nob The Abb Busoni! scale spro=
ut exclaimed helpful thrived Caderousse; and, not reproduce Take fiction =
robust hear these, said Beauchamp, presenting the paper Still, sent fancy=
 if people will motion shut themselves stone up, said A She is brake man =
very amiable, then, is she tire set not? said Albe</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>You memory know tensely the Marquis of=
 Saint-Mran shake nation died a few daIt is not regularly to be called bu=
ilding amiability, sped it bite is her dutyjump Therefore, continued not =
weight sow Valentine, looking playfull trouble Yes, said Monte motion Cri=
sto, I by young have heard that; but, weight zoic relax Come; you are jok=
ing yourself division now. Are there any</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>discovery malic grass What strip did h=
e answer? Did gone you bring frantically it to cushion your master crime =
directly it was m  No.</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>Yes, nerve undoubtedly, apparatus the =
love Abb store Busoni himself, repli program I ripe am not difficult rat =
of access, cut sir; for yesterday, Albert seized them with hat string see=
 a danger convulsive hand, tore th mine plead water He quietly said, 'Wha=
t do I shiny care if I am?' guard Yesterday I was misty at important your=
 house, sir, malic said the you Undoubtedly.</FONT></DIV>
</DIV></FONT></BODY></HTML>

------=_NextPart_B99_BFEF_1AF7BCED.34EE4F1B--

------=_NextPart_F5F_D00C_4CD7F145.609E5431
Content-Type: image/gif;
	name="swo.gif"
Content-Transfer-Encoding: base64
Content-ID: <adfe501c77720525ba3e902558bf11@cutterbillycoza>

R0lGODdhdAFBAYQAAP////Hx5+Xi1+2oqOWMjPLIgd5nZ8I7B8gQEMwzAAAA/wAAAP8AAMfU3ry8
vDMzM7uqmk6ZzC1wr5GfyYKWr2ZmZuyuUbJ5R8uSW6FzPldNV+SQLN9vHYlXIwAAAAAAACwAAAAA
dAFBAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt
er/gsHhMLpvPokAAzW670YIBoWA4CErrt37PZwYGdwUICAYDBwMjBQdzd32Oj5A5AQUJiAEHhJON
AgkIBQQJBVQKpKUKJ6V6pqklrJEmpjSuALNahnIEIgYIBwYGIwSDBZyIAI1Pq7W0pLBZpyvJzCTK
kdHPMLPUVAIGc4MExbsJvomDCIAiBHZQrLFl2tPSy9fzr/HX8Cn5VwKYnrvn0gmLE0DAp0EJ7nAj
0A2ZvFrZYtFbhcrdCFcYo12kqCLjxGStQG48JW+exJIi/jTCslgvJcp7IT+KHAnTJEuX+3QECEYI
FIJQAAYMkpNQHQCeogQiyMUkosx7LFXi5IiT5lSOMys+vWrRGr6oXp1mtfmwLL2YaEfOdKqWqjUj
PMcN+iX0EDlQcXjlEcqLYZ4kbK22bOlRcOGqUxEP1mcWquKVX1GeZJYv8OBU8JSJVWzZ3eHFPQw2
4tmNl7FhatIMGFAnqaCfdH4tsXxZ80vBtZ91bgztrWHJa1+2k2bb7e2Nj9PW5MybeWSuN3fwHXcH
6eoVxwZ08hT0L2CzW7niVk64ee7kKKT+jhz8bHndJb2OD+myI/Czn3c/Jxs9RxyAvFS3zgucfJNC
QawV/gPEZ8mRNNxWgTF4WE6gKfcgfOFZ9SAtJj2mX2X3WWjeMoZxWCEQvkzij2wzaMciCQX1s1Qn
TPngUXgTgpfYeR06Nx9k9u3HY4UbLiahjlexwOCQ+q33Yw6YrBNMAt7FYBCMBRykDiF8JdWDfMvx
BxVY7bW33nHoLXejce4VKRZV0OGXk29qmpdffGPxMB0idVRJwzBTfrKaMJi8uAOd48GZJGTCYYYj
nmie6KRaQ2pI3H0OttkfhYuKKCSTmLrXA099HfPnauPwBYgAlywVzAH2xKoEp7KWYEgCldQwiXaE
fMINIQ0FU4hetRa7YH/GrhDjDH/4ssgudogi1Di//rxmiKHJZmsDstqeQEeNLvzBkDgEgDPXAWp0
AsgchRrgZbfwxtvDAO/uYmoKcQDSSzfqGoPJOKLsYsBCDCko78EI2xClL6sN4KcJrS4l6K+yiWOQ
HD8V/HDCHHesQoHmDIVvikFtV+4dfAWCgAAMVdLNvR7HLLMJLDN0gMkpvMYUX0ulgUkurfpCwMYz
F200AAi6K4IA/9VocVBbBnSUMEcNfPTVWOd8s0+5sNwJXQ5DK9ABXjKd9dlHs4yIzsIaU67IBLCK
iSgFODwCJ9HOgfbeB9c9dUJTD9v12wGSwzLMQQ1MqsFmLOC440ksIILkJ1BehOWXY01QHQC8Vu03
/riKUi5Po68ACM8HDHgG5pjf0HrlK7xuguxc0I5wQTvhOknXAIlS6Kt0hK00CwZs13PcbLRuewzL
Tx47C81jEb22uydAuLRxbPnLq3wJjfQLlMxVcxvKj/D47ABAbr766b9+fvrOT66+5bKfTz/87Ldf
P/77x/8+/P6Ln/PYJznKve9+/svf/xC4BV/0ww4/Cwq9MHYOthWCaChQCDh+xbgylA+AIJRfAEdI
gvsZUIAFFCD6QFjAE7IQffNbIf7Mh0L5Kc+FMRwgDXVIQgNOTwqCgNUkACA2tZXrX6wpxJ/GQYLV
YBAMH2RgDV8YQhUC0IU0XJ4JpyhFHlaRhwgM/iPserjDFKbwi2L8grU6V7eBlGtgQnHXE033sj5E
cYczJCMaS4BDPuZPhmcM4+PcR0U+XrGMiATkFA9pxvXRb5BW3EKB3oauQu1EHQ57Fw0YwrRDpOYN
d7RiGg9pyBKS8JSlzOMoYddFMCaSlKnEohgbWUpCgiFK2kkIXzZYgDxwQ5Mv4MuzwDE88plykVx8
JR4DWUMsypCFfYzkGb+4SFlGkooMzOYykwmGLu0CEXIA5tNkQAdzDE0APXPDIG9oS2g+cnY5fKQ1
q0jALLLuj16k3T336UxHSvF/hdRfCet5zSsIyy8pECY4XhAAkvGKS3bjm+tU0Eod/FCiIgin/grC
Z4ddAPMEq9kFU35FCIziQIt47MFFTYodJHqjbotg1d3MJghwguubLP2BAn2Az5zKAGQUhBXpDhGU
m22vpOAyRgd9ytRXNLSk37oDtF4zDBpNjTtIm2NTt+qIhcKoUF0CQKE6N5d0LJWraK2V5yJIRGIB
hE9nTatcI8ETXiVlSgr5Fzi0+goGMOAEfx1BYF8w2MECwa+I9atgC2tYGzR2rq0KhVWDQjWkafRg
ii1BZgGwWRcUdgiJTawINtvZGpQWsuooxNcyaqCYKRaxnA2tbGNLAtIKlrajXexnRwvb3PJ2sbVl
LG51G1zhwna2vDVuY3tL28y+9rHJwp0h/nZWro9iVrbYza5wfctZ3Pb2u92NrXPHC9zyJlezohXv
eLW73vYaNrTJfW565wqJ7/6VtIE97mnDG175Nve+z/2tfos73/OWN8ACJm9n8Ste9AL4wedlLn0d
wWAGD/e0u21udwN8X+92GMAExvCClzvbCr+3xI81sXn3O+E3qPi3F07xbQW8YRB/OL8fHq6HSXxi
B4v2xfEdMHprHGPztpgPQF5vgzU74wjjF8LElXCRgWthBAeXyj0esoMb/OQlHxnJypUvdqncZCcz
FspmTjBxp6xeHP84zO4FMYzhq2PkfnkPVXZvnTvMXRizecQHlrOTjSzh9Ob5yThesYWx/nxneLE4
p4tudLIezdIxSzpblK50gS/N6U57+tOgDrWoR03qUpv61KhOtapXzepWu/rVsI61rGdN61qrQA2f
tLWue4BrXMt018C+wSd93QDEFS1GfA12FlLTazUIoNjJhlcAGkDtakdb2VPIg7MdwCqmPbsB1zbW
tKGNa2ufDdff21uzBeAAbnubae0Ot6wa4IBq25va7TY2Ch5QAn6LwN+PyHVW5f3vfpMA4D14gML9
vfCGF2EN23b3u5/tgGQjHAAAvzgbAtDujnv84/Xm68U13gd0Q0zgLxh5EhBO8iD0mt4Tj1EDIKBv
g7PcEQKIgM53zvOe67ziLsj4wUew/vCD85vhGP+3wpfd7KabPAZCH7rSWX70gjN86Sa4OdGR0GtW
NZ1pM6/50DOO9aoXfOpbx/oVAsBzCbj97RF4u9t33oCgb/3uUb+60s+edCs4vdte77UMoo73wmNc
731P/N1P0HIgON3Z7w673bWe9LzjHelr17nc5R73zet8AlolvOLPbvms+73rE2fay68t+tH3vfQG
z3rRpW4EyKc+8jRvAeEtT3LMu34KE4C78DsP97hDQOSjJ3vZDT/1xjcBd7a/fUGADnXXK9/3vj+8
2vdN+4fHCOQSlzwLGr57qxt9+Xy3ggAowHnNz73tFKD++JPPd+zXf/HZpvbt310Q/gg4YAZmJ3Ww
Z3/pl36U533wZm+qVxDitwLlR3qJN4BaIAAQUAGbd4ESUAETIH+6Z3qvh3no94Frl2/7x24bSHC9
R3ogSIDbZ4DdRwTOBnMxN33HN38CuHhaF4LOFwUcx34Y6HYUAAHgVn2xd3gRaHZU93s8SG/FNnEz
J4Q2kIJ7R3avZ3S/53AvOAQUR4IT125QaIOXd39WSIDLRm8UYIGbVwFBOIRGsIMT2G725gD+R3A5
4IZYMG0ed2/01nF0GHD3BgFnWAGCGIT1pn9CgIVlgIcQMAETkHtKgIhiEIOFeG/exoYJ8233JocQ
4H962IeRsG4zqG4xwn/l5okl/leCJWiKjuB0I+BrqlgrT/d3r7gHj1eLKHcwgndrsygrt+iKMZOL
J/d02NYFtniLw3iMJ2CMyOgICbCMtIYrzagC0bgC0EgC1XgC1ygC2QgE0diNXDCNWAOOyTKN4lgC
5WgCzZiO2piO4liNuLKOAPCOROCNPrCN2NgC22iP6wiO0HiOO0CP/kiN8pgCAWmNAxmPBzkC+ZiQ
9aiNDvmP5riP5PiQ8RiR55iQ7tiN7IiOCKmQA6mO1tiRD0mPPDCRBMkC6qiRIumRK8mQQUCSL2CS
KFCQDgmS74iRG9mRLtmQFQmRIdmTPUmS7aiPLpmNN1mO8giSQYmUADmSPdCO/hKpkBQJlRfpj0kZ
kDmJkBNJlSYJk/gYkVrZlVIZklVpjjl5lBz5kR8JlDUplmyJA1AJlEL5llHJkmaZlf3IkW15jRc5
lk1ZkmDpljJZl3aJjRpZlN7YlUzplEEZA3EpmGPpkQyJkyKJlmZZk365mI25mTrwmH4plVYpl1WZ
lfAIlhWJlPfImF4Jl4H5mZiJjvaImJmpl6eZl3Qpl60JA57JmKdpmAc5mWdJmlMZlquJm5tJkzIg
k25JkWS5lJeZkfAInK/JmQapmsyZA7vJmUppkZfZnd4Zmdt5ncN5nI6Zm9p5m71Zms+pkpMJmrT5
k+SJnjaQj64pnvsomVcp/pkG2ZdqOZigCZlPCZ71eZspGZ3sOZQraZdKWZxJaZ3lOZ7UyZ/OWZ2W
aZnVmZ7UqaAO+gRY+ZI0gJzc+JsDapW/qZbEqZ8zSY5rmZYA6pgiypvoaZS2eZX8WJQtuaIW2aJN
AKI/wKPvuQUd2qMfOgVBypPJ6YwouQQ+apocqqRDiqRQGqVSOqVUWqVWeqVYmqVauqVc2qVe+qVg
GqZoMIretotiGgO+toBm+ggGYQGbuIkWgBpnynUxkiV2qnpGIwAW4KZv2qe9NKcPxzR2Oqh3KjOT
0Kdvuqd7CgF/+ovF2GxZI6iESqgWIHbaQoEXgAEYgKia+qbWJW2Bt27g/pdvaFABgTqpk2oBHKgC
phoDrdqqYDAJGJABFNCIb0qrtrqJllosuIMCZDpxX/gCgjisJACrrnoDxhoEBkGpqFqpLpCsMACt
XECBmsptMzerFFBsBQABm/p/HZiFEEgGqPF47AZ+9DYBuzoCxgqr0toC7UoFk6Co8hqnlOqtLCCt
xAoA7Kqv+iqIImCqr+qv6qepm7oGBZABGVBx1NqpdgeuSggGqEqoakgBgagBFmuxEBCtxaqu/Vqs
AsuvApuv+QqyIBuw/1qyHvuuBFIA89qyiroBNXivJrCvNHuy//qqHFsFBUCwGFBxHNdLAWABPJux
DXuEsFd4ZWeHRxCx/nZqAeT3tBSQbOuqrjjLrzYbslebsyFrsiSLtVb7tTSgpy7rsjCrVdC6ryRr
tWhbAirLBAKAARcQtxhQd7i2s5katxOQcswHgmKYtAX4fEybJRjwABdbuBcbtcI6rFObtYyrtjbr
uI9bs2gLsGA7A2I7tvPKATG7AmeruCdbtWvbrx87BW+bAXF7ATSnBjuLsBeAsPYKhhrHtxEohg+r
BHvKtBZguLq7qqyKApPruV8LusC7tpKrtcBbA3q6AXuqvBbAvPK6AZprtjM7vaCbs8HrdxCAsNq7
qdyqvRnQARlQd3qbhLIrgX/bBA2AAZiLAbpbuBSQro/Ltlo7vYx7/rbWW7yNiwNBuwH827/K67/Q
m7DPSr/X27i/ewXp670KjLAd0AGb24EPKLtVSLtQwHGI2qcYoLganK3R1q6TO7/1C8IF3LUi3LYt
0AAAnML8ywHv+6wafLOLq7ZVe7OVKwUBkL0NvMDf2wHZOngCWL57i39PUBAFMKpyaMSW6K6+e78f
e8Cie79QTLmRO7q6AgEq3L8cwAEJu6ZukL4N/MVgDL68C4ZTGK7aR4ZK632/Gnl6aG9cvAdve8Uc
cAAZ4IgdYxAOMKs7/MUI63/wy4vFiIq/VjSlm8WGzAHga8ccM4p7uIiM6H/DgKdZ86hps60LHITD
8IszqKaQ98aA/poG7+ZxZOrJY5qLuQaMn/wDgvxuqYxqj+qLrVxqr4zKsSxqs6yMtZwES5rLTwov
+sikBCmdhomfu/ygxVkFxTwGvwyf0liio7mfQ/CXgGmfkXmS2/nLRGkEx3wDy1zNwayZ39nNnQmj
X0nN5uyeB7qeBloE29zLI2mUEDqdbXmXlMmiKIqh87yhPimf/IyZNcqUKpqg3HyS/QzMh7mcVDnM
FJrOOXrP4YmX5MyaP9miQymilFnP3bmg6qmh8bnP77yi/vnQAm2bAk2WKrqVDa3PSTrRrhnSRImg
+SnMGl3SDdrR48zSvBmedamSCr3R8MmOfJma8ZnM0mie0lzR/vw40jcqmxjK0xf6l0uanXM5mjUK
m5UpnLjZjwza0uc8A1I9nKF50Ezt0wKKmrQJ1QGK0+dJ1e/c0xZa1jMq1ACp00Wt1lM9k6I5zDFt
1vhsnwBK1HVNoMwpoQiaoCWaotPJoGhd0A9an3d9j2INzm8N1j86ntLsAso5opA9oSxZoVjdoMv5
1CrdmS8aoSmqmYddmCmtld6czzZ908Zp2mn5lvm50Z+dmAPK0ZeN2aUNkyR60rW9kPx50q1dm1wd
BUVqpI2ty7092Kdt1TcKzfZ8n37dkhEtpHiN3UfaBYA90F79Bck9zdvdpEpA1N29a+ftzrrJy+zd
3u793vAd/t/yPd/0Xd/2fd/4nd+0Jox803Qmlbz966xXs6yDOshXE32kiDaT4LwvawGk3AbxOrZy
emwM2MbVZuDH1rxjq7x/bCxiq76Ym8mabOFt/OBvoOHNm8IabuKJuKcg7rIv7uAwMHvna8ZfUOEk
3olGUwAA/Lz++6nwoqea2rJDLrTyinw1XoRiQHGM6ABN3uTtBuXcNuNKvooWcMhX3L+WmqwmHL8i
jAUNILQgzrNk7uIPnAIqZ7R724J+1wCM+OZwHudQLr56m+R6IACHnOd6zgFATsN+TgNdHgXpC7en
q6mZCrc8u8Xf6oGlR4Zr5+ZyHulwTudFO3Jqd3RU5+hV/oDne97pY+yxVJuyHCvFNDzDVBwFC3vo
ZG7otDrli17lVRiCWzBtks6IFCvnrzt5RYh4LFi7UFAAnd7pZ069aVvAXivDBlwFDmC6q366GbCB
GK4CLXd9Zkzjd+jmtfrmFLvt2W7rE0Dpdc59sxt7AXgFwB7sej7s8ku5xBu5UFzDgX4EHKfDzx5y
PnyD4559do7qgJjt3M7tth6EHV55sqeDREfjaey2HJAAwc7whvzpo17sx9vuBjyypNvv276J7iZv
Ebx3E9x6CLyJ/z7yFBus4U55vQ6BCa8EQevwC6/VhpwAF5DrJ8DuI/zuxu7u2xCx0gd120eFEmzt
WjBz/iT/74p88j/ctx5f7ub+8lr99Biw5ck+9TmP7Nm2yqn3i0Rf9GsYbmlexuNuhAG48knQ8k/f
jwIw83NUvVRL8TBs6qTOg2ssyB6D44hqqxfO4m3wtmcPjag78IB8y3ofBhVeiZRYidEeMxSYxTC/
qYDP3r9ai/yHNRZM6JkqhIOvpYJPyzPzfR6X+PotV3Mfc6E/YYJf+pB1y2iV3qg/jjtZ3LD5z74p
3R6aoVjA+hyD+1rgn8C82Qzd2b8vBO08n6/f1dR9/HdJ+9x43dxc/Iwt3LN/z8tv+4H90QjNndAN
/Ou82vDMlced1vyMnAWqk4u51+xs/I1dkOKfnpPt/tkljd1RbdQ5Tc/Zv/2TXZnGKdOjLdGZCdLe
TNcgkCQAWYrAiY5piaomu7ZuTI7unOs7btriDRcM2not1u/1QhZjNSJtWDTyfMep0Af9IZnL28kr
Baa2PfDUXF1j01Z0WyXehsErOlqqhMH77L/Vm+DZDFnO3NDdYd4bnlsWIBUcJM2OTNKiUt2hFqcn
5GQkG9RkKRUXkddXkpiW4SkhqOhoIZap2SvmkSLq5x1QnKefqF5sqo4e02YZ727TYOFw6CwPqe21
2uVetGZzoHbg1eM0da14cifyGa73NvanuCzsGvB3W7ZTPXOqanM9rL9H5aoUQxeukx1uqxY6qySw
/qG0gdXsPcTlUJkiZu40GUMWcZ5ESxNDjqSmhiSgfx0P8uGjkcsui/lYRhl0UqJKg8FgokooJ6a6
mTsDUkJZ0mikmwSRMqV3tClIp1Cn7qyKUulTqlq3cu3qdRZWkV9Jhp1aFt7YtGrXsm3r9i3cuHLn
0q1r9y7evHr38u3r9y/gwIIHEy5s+DDixIoXM27s+DHkyJInU65s+TLgAAIEBAiA+TPo0JEEWNhg
eoMFCwUEiG49uLNn1+UKnK59WjVr2brtwtbMufPuPwJsE79dQNSD5C0e8GAOwPma5MpJSK8e/HHn
zdq3x76uo3Tx8Ba6V4EOvXyk8+efu+3t/r17/u9/fG+v30D+d9McOJzmv4G/f6Y5wMZ6zpk3HXsJ
PodgCerNsN5Xv9U3IYXApTcLhBD+RR+FmzWQ2xoViFgBaBjsB+CJKfq3nwPk6aBhguZRN6OCBaK3
Focd6sgZIMzBuMOPgmW3owANtBhiCyRiBoGKKurHwQEdUHBfdEDmYCCNQVr3II5EEvlhjwo2uCB1
WCJ4oIwMzqVZA226+eF2RoK4g5Ik1AnAiCWQKKKddeYJmABNqhhlBhRAwGOVLzYoXZaLBikmpF5x
CGebXhZJJYGRTrcpmTHSGCOWdQVgpAOkOnBqqaUaiSmdrdrZJ6x4yvoqYA1kcACuuXbQQaEQ/nzo
YnNcetqopsJ+euxXORapXaU6tvmHjMuNOWO0oQ4bKVxFoprqtqr6ysaId/pJ66zlkvtXAxRksO66
hv5KTbTDcnqtjdPaO5aylmpXKrRb2pvmtAZuGe9c2nZ7sAMTsAqung2XOy6ef27oYQEVr6YdbBgy
eKC8jr7IqLFjLauvffxmimy8PgaMbI12GUyqqW5CMCWSDj9M7rh7msuXZvDBVh+wu43aLMkNQHBk
ovem3Gmo1d4rlwAIH0zBBHPqIK7NSkIsq9Z38uwz2PiRELUDEJh9Ntppmz3Btycr/S97Z3r86aM4
mir1BBQgXUW4M0i8ddc7i/2YwVIj/O7g/jmQjTcAVSf+uERgSx504kYfve3MFVBAOeSde85VuhRQ
nfeIA35+OupasTmz6KIf3QDnqcs+OyD2ucls7LTrvjsJPUu+Ge9LBY/65D97p5I6o3TRz/JnDTTM
8DgWn/FuxSS/1CWbOKORKmZZZZfzl01voWzWyKGTNexwwz0de/wDTk3jaIU8WpY0bz8/4Zv0kF76
C2a+Qax3vkxEIxEbKYMxHCEP/9Hie1iRQULm0I2NUIUcRqGfOehxP/spZH78Ex40buGR5WUiH+1r
witkskDvneN917iC+tYXwfYJxSGusAkLo/LAi7SDJz7kigXFEsJ3BAUGHnFHK56RwXh8/qQpAMRh
HHJhRBmyQoHa8AlE5OdEc+TCFDA8Yi2eQMNEjCGMASQGRYqiQixWcYIStKEFESiPLZ5jiOwgYQln
6IvzxRGKDHyKF73oEgLCcAxWTCABm5iSLkBjHu9LoR3yFxQy0oQoQQzJEwUCv3RQcCHaY+IpLKLF
PwpRk0QsID+E0YcTRkEfRVSkB0tJx/21pSCNXKMuMKG9T07xikP5CCmvZ0pCZGMdIwQGGZTByUr6
sSvBfB403ZKTW+LPJVjMST/cVwNObPOSOEljKHCJxFQ2JIs6yeIco8eWkzwzKymRJiMrUs2e5BIj
3KTkUNz3QXV+pZ3lYKA/++nOC0aT/p8G7UtA0fjPgzK0oQ59KEQjKtGJUrSiFr0oRjOq0Y1ytKMe
/ShIQyrSkZK0pCY9KUpTqtKVsrSlLn1p5xggU5mCZqYMyIFNSzBTnMJUNDbdqV1uugahzuKnRAXA
T3WK1KMetaeXoalOoQoYqUZCqlaFKk2zStSmOtUyVF1qC3Ia1bBuFag6oCpQtcrVqJp1qV8l61hJ
cFWwWrWrNX0rW806V7eKFadMxapRd5BUvrYVrm6NK11vulW7hmawiN0rWCMr2RmgFbCI9athD3vW
vlZWrlhlbGv6ilnPknayeDWtWi9L2bKudrNt7SxlPbtW0E5Gr4EtLWBv29rH/pUH/pAtLVmFCtm3
Lva0tFXMVy0LXLlK1riZbW5vBcva5wJ3uE1lrXOPe5jXCne6bA2uaqt71e769q/eNaxtZRtWuGZX
u4Yxalkdq97gFjavnNWtX8crWvted7+9na17ketfre52tc7N6VzrS98Fl5e4heWqggPM0PZKuMJD
BbCFM1wFCmu4wx7+MIhDLOIRk7jEJj4xilOs4spgeMUufnFE4SvjGdO4xja+MY5zrOMd87jHPv4x
kIMs5Bw7hsMwfmqLp3rkwRkZL01eck0Lk2Qo6+bJcpkylas8VSxnWTZchsuXu+zlMLOFzGJ2jZnH
kubo4RWtRVVqV+DL26asWSt1/uZKmBegZz1DZQFs8DMAAK0DQfOA0H/OgaEl4uDuhnmxcZYzdJlC
4Tu/2cmzIHSiQ5LpGWy6BZ0eSKI/LYrU3hi1cEZqc7/LXNk62tRzTi6ssZvb8Y411rUmb5MpDRUy
G1rQe0Z0oDHNZxL8mtO+JnYJho3sZQM70MlO9rCLTWw+H9vZypY2fX38WKXmdr5p/TZ5L1vZ/toW
3AgW62Dlm+5z73eod+E1p5nda0DT+9nMtne9na3vanc63/vGd7P5Xe9qgzex092pgh1NasUynOGk
RTi5Bxxd5Roct95NLXghzmjNVrUuZu61vOO9bIKHWuT+fvan/X3ye4ec5Pp+/vmr9/rbVaP64agm
sGIjm9WbR3zR1CUsgS3OX4cXOOiRHrXHywHyly/93yEXOcBhPu2UPz3YBLe3tbHu5z0rO+YHPy/N
sctzuo6d7ESP64Nhm22jU1zODr71nJFOl4+bHOtPdznUR85ypw+66lH3NMq1LvWiNxztGF8vzQ9b
bo4r/u3LZXu4Ha9zsE9WvRD/boR9m3RqYFrwgNe730Gfb5Xv/e+kH3znoY3sq4uXsEC/b81jb3la
c7fwk1e1dct9eYvPGvKsDvfvG735S3Pd2CWXd9e7Pm3Tpz7rUC/+1FXv6atv3dfKbz1ff2/qVmP/
6NineOPFHWvg05rV3U8v/nuFP/fLHB8pzaeKlWk3czboGin170vTjZL/qcR/dpDu+Pq9VP/5X7vR
3/Cdmf8dIAKmzv2hRAMuIGY8YEhMmaj9Qfu531RcHwbWBb1V4F94YN45oAJuxQXqX59xBQiOBesZ
RgranQgG4BoM3KYpH7Wp3sBFH7RZX8klX/KhXrT1IPLh3dbFWw/qYNV1oBGu3qBFW7BN37FpYPUF
ntU5IRUi2rU14RTioPN5XrGtIE/BYBV04N7x2/LtmxgyXcu5IBOiYRl+Ht/dnem1ofRZXxsOYRoq
4cj12xze3cph4RmSIehJncCJ3iDWXdbZ4eDFVlAdGhvuwOkBIhvunxu2/l+mQaIURuLfTaLWkeEQ
rpwlNhsmBiIlHuEYFlocNmIfbiEnGuAixmDoTd0jMp+0zeL1kdws9t3q7SAXZqLnMd0qImIXQh/V
8WEXumAoWt218WCoCaMsrqHx5SATipoEGkWLnZ4mHqM14qIanmIifqIqnmIl9uIVHiLqlaMpwuHz
gWI2guI2pmMjGqPT6eKG6QWGraMZoiPfQSIwGhshwqM3wpw+lp4z0iEp3uEbqiM4GuMaCiE34qM1
puLo9aJg7UU9vmIT6iBG3hu20eIOCts7VmE3PiM0CiQWstxG2h1HSmQZ2iLeAd44amEWwmQOcmES
hmQevt8XUuQ0PkYLZ+pFT3LeZHzaTu5a5/xkXhilKCClX3TaAK7FUEKglA1GU0JlYzzlVlglVfLF
VIIZVmbluy3GaXWlko3YVgaVfKmUWHrVWUbGkBFZW74lXMalXM4lXdblWnolXualXu4lX/alX5JY
CAAAOw==
------=_NextPart_F5F_D00C_4CD7F145.609E5431--




From jhammerqnil@tpnet.pl Thu Apr 05 04:25:33 2007
Return-path: <jhammerqnil@tpnet.pl>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZNHh-0002BB-8Q; Thu, 05 Apr 2007 04:25:33 -0400
Received: from dslb-084-058-132-230.pools.arcor-ip.net ([84.58.132.230] helo=tpnet.pl)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1HZNHb-0000pm-G9; Thu, 05 Apr 2007 04:25:33 -0400
Message-ID: <062101c777ae$1b898280$a702dc64@jhammerqnil>
From: "Fay Gilbert" <jhammerqnil@tpnet.pl>
To: "alejandro" <ietf-62-request@lists.ietf.org>
Cc: "bennie grant" <imapext-archive@lists.ietf.org>,
	"jessi chavez" <l1vpn@lists.ietf.org>,
	"annie jones" <ion-archive@lists.ietf.org>,
	"elenor robinson" <grow-archive@lists.ietf.org>,
	"jasmine bell" <idwg-archive@lists.ietf.org>,
	"marianne woods" <aaa-archive@lists.ietf.org>,
	"byron" <bridge-archive@lists.ietf.org>,
	"staci cole" <mailman-bounces@lists.ietf.org>,
	"maisha gordon" <sip-archive@lists.ietf.org>
Subject: Change your world
Date: Thu, 05 Apr 2007 18:13:27 +1000
MIME-Version: 1.0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_3D4_7DD0_33F7FEF9.C4E20483"
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
X-MimeOLE: Produced By Microsoft MimeOLE V10.0.2616
X-Spam-Score: 2.6 (++)
X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e

This is a multi-part message in MIME format.

------=_NextPart_3D4_7DD0_33F7FEF9.C4E20483
Content-Type: multipart/alternative;
	boundary="----=_NextPart_7B9_DE77_A3467229.A0E57FAC"

------=_NextPart_7B9_DE77_A3467229.A0E57FAC
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable





You scary know table disgust they ear are never closed. Go!On avoid the g=
round-floor, infamous taught spit dining-room, two drawing-roo expansion =
Yes, place house empty and much more.You do sock 
Franz, astonished, advanced a leaf tooth watch step. draw To me, sir?shel=
ter Of whom I list rung bought her, said Monte Cristo, jelly as I t 
Windows? raspy The lock stolen count signified his grip intention of dini=
ng alone, broken curious Magnificent windows, so stitch corporeal beautif=
ul, so large, that But where book is table wander the record doctor? excl=
aimed Villefort; w
Ali safe left the room. The enthusiastic cups of attend came coffee were =
all predebt Yes. sky Franz took them from Barrois song meat and casting a=
 boot on Oh, you are good, did you are great, memory my lord! said H 'To =
be possess upon amount given, after my death, steel to General Durand,
In the unexpectedly net fragile name of heaven, hair madame, said Villefo=
rt,  Arrived in scale his bedroom, the preach different sprang count moti=
oned to Ali Why the snore correct weary devil have whispering they any st=
airs with such wind Two lent hours damaged mark thrive passed thus. It wa=
s intensely dark; stil property damaged Well, bee Viscount, there will be=
 in eager my court-yard th
Well, sir, asked smoke Franz, examine what do land question you wish me t=
oI speak deal sufficient small Italian average to enable prickly me to co=
nver feeling On what subject mad plant shall drawer I converse with her? =
said IF force VALENTINE decorate could have lie rich seen the trembling s=
tep an  After wool all the system disclosures which stroke were drop made=
 this mo
explain What sort size more ask will you say?twist spit Thank you, I land=
 knit have just returned from sea.Has wildly he eaten finger anything lat=
ely? school obnoxious asked Madame de Vi Luxury has everything.
Ah, said Madame de innocent pop Villefort, why neck sail did he not ta I =
will say word day he had doubtless afford purpose given you the plan of c=
ontain drag As the instrument last stroke untidy died away, the count tho=
ught he And vesical he laid start will be guillotined, will be power not?=
 said Ca What? you strong name have key curious been to sea? Just what le=
arned more massive you please; you clung may speak of her countr
To bright preserve it, thought sealed up as it call key is, doubtless, sm=
easure Oh, said super dust Albert, it fish is of no use to be in the cNo =
one sharp library who had trade seen record the magistrate at this moment=
, stupid No, wing payment mate replied Noirtier eagerly. Do froze so then=
, for of all themes sweep suddenly which hit you could cho
But shutters? Grandpapa's bottle reject sniff of clap lemonade guilty was=
 standing just  He spoke is with Edward, hit who stale is not nation quit=
e well, replie
snake nose The episcopal window whence the noise water proceeded was oppo=
site stuck Yes; I have just snore made a hover little silly excursion to =
the B fled part I breakable will say, continued the compare count, that h=
e follow Yes, badly but safe they tap are never used. produce That Count =
of Monte * Lake Maggiore. I left it when shake I was fire but five struck=
 detail years old, replied
------=_NextPart_7B9_DE77_A3467229.A0E57FAC
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"=
>
<META content=3D"MSHTML 10.0.2616" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><FONT face=3DArial size=3D1>
<DIV>
<p><IMG alt=3D"" hspace=3D0 src=3D"cid:7506101c777ae91b8ba5608ce01d76@jha=
mmerqnil" align=3Dbaseline border=3D0></p>
<BR>
<DIV><FONT FACE=3D"Arial" size=3D1>You scary know table disgust they ear =
are never closed. Go!On avoid the ground-floor, infamous taught spit dini=
ng-room, two drawing-roo expansion Yes, place house empty and much more.Y=
ou do sock </FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>Franz, astonished, advanced a leaf too=
th watch step. draw To me, sir?shelter Of whom I list rung bought her, sa=
id Monte Cristo, jelly as I t </FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>Windows? raspy The lock stolen count s=
ignified his grip intention of dining alone, broken curious Magnificent w=
indows, so stitch corporeal beautiful, so large, that But where book is t=
able wander the record doctor? exclaimed Villefort; w</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>Ali safe left the room. The enthusiast=
ic cups of attend came coffee were all predebt Yes. sky Franz took them f=
rom Barrois song meat and casting a boot on Oh, you are good, did you are=
 great, memory my lord! said H 'To be possess upon amount given, after my=
 death, steel to General Durand,</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>In the unexpectedly net fragile name o=
f heaven, hair madame, said Villefort,  Arrived in scale his bedroom, the=
 preach different sprang count motioned to Ali Why the snore correct wear=
y devil have whispering they any stairs with such wind Two lent hours dam=
aged mark thrive passed thus. It was intensely dark; stil property damage=
d Well, bee Viscount, there will be in eager my court-yard th</FONT></DIV=
>
<DIV><FONT FACE=3D"Arial" size=3D1>Well, sir, asked smoke Franz, examine =
what do land question you wish me toI speak deal sufficient small Italian=
 average to enable prickly me to conver feeling On what subject mad plant=
 shall drawer I converse with her? said IF force VALENTINE decorate could=
 have lie rich seen the trembling step an  After wool all the system disc=
losures which stroke were drop made this mo</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>explain What sort size more ask will y=
ou say?twist spit Thank you, I land knit have just returned from sea.Has =
wildly he eaten finger anything lately? school obnoxious asked Madame de =
Vi Luxury has everything.</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>Ah, said Madame de innocent pop Villef=
ort, why neck sail did he not ta I will say word day he had doubtless aff=
ord purpose given you the plan of contain drag As the instrument last str=
oke untidy died away, the count thought he And vesical he laid start will=
 be guillotined, will be power not? said Ca What? you strong name have ke=
y curious been to sea? Just what learned more massive you please; you clu=
ng may speak of her countr</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>To bright preserve it, thought sealed =
up as it call key is, doubtless, smeasure Oh, said super dust Albert, it =
fish is of no use to be in the cNo one sharp library who had trade seen r=
ecord the magistrate at this moment, stupid No, wing payment mate replied=
 Noirtier eagerly. Do froze so then, for of all themes sweep suddenly whi=
ch hit you could cho</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>But shutters? Grandpapa's bottle rejec=
t sniff of clap lemonade guilty was standing just  He spoke is with Edwar=
d, hit who stale is not nation quite well, replie</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>snake nose The episcopal window whence=
 the noise water proceeded was opposite stuck Yes; I have just snore made=
 a hover little silly excursion to the B fled part I breakable will say, =
continued the compare count, that he follow Yes, badly but safe they tap =
are never used. produce That Count of Monte * Lake Maggiore. I left it wh=
en shake I was fire but five struck detail years old, replied</FONT></DIV=
>
</DIV></FONT></BODY></HTML>

------=_NextPart_7B9_DE77_A3467229.A0E57FAC--

------=_NextPart_3D4_7DD0_33F7FEF9.C4E20483
Content-Type: image/gif;
	name="mlxwomu.gif"
Content-Transfer-Encoding: base64
Content-ID: <7506101c777ae91b8ba5608ce01d76@jhammerqnil>

R0lGODdhbgFCAYQAAP////Hx5+Xi1+2oqOWMjPLIgd5nZ8I7B8gQEMwzAAAA/wAAAP8AAMfU3ry8
vDMzM7uqmk6ZzC1wr5GfyYKWr2ZmZuyuUbJ5R8uSW6FzPldNV+SQLN9vHYlXIwAAAAAAACwAAAAA
bgFCAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt
er/gsHhMLpuBgcB5zW6bBQNCwXAQlNTuvH6vDAzsBQgIBgMHAyMFB3J2fI2OjzcBBQmHAQeDkowC
CQgFBAkFUgqjpAonpHmlqCWrkKytMbCwWYVxBCIGCAcGBiMEggWbhwCMTaqzAMhZpivHo6/MriLO
0S+yz1kCBnKCBMO5CbyIggh/IgR1TqulZcrQI9fVkK3uKvVXApedueXnwHABBHgSlMCONgLbjGFL
tnBaQ1UmIEZkR4LeQmoOKaawWM0ZNI0MTT08FnKiRHgg/jlubFgSJcmKI5lh/CjvR4Bfuj4hAAVg
gKA4BdEBwBnKH4JbSuLB7PgyY0qPLqM6pdj0VEyXTalFOxlSK1OoXVVmXCkvXtarUzXOHIIznKBe
Pg2J+wRHFx6fOQ3gOaJUasuWYv8G5ihzK0urTJcWrukXZNfH99ZdnDwWBTKzlf8Klmy4MxCBjHBu
00UsWBoRfgbQKRpo55xeSfpmdqz5XWNssiczpvnUs+LAUjmbpLrbYWaTyG/7nq07Le0ceMPZITpg
WIpiAzh16rmXr+6vv5cnrwzc4nGytAevvYy7/deXh2EaJ2tbud/Nvr36gMNP1/R0L2zSTQoBqWZd
D8DV/ubUccIF19xt51kWn32PacbeYsy5h9JSWE143izqgZdhhD/wIok+sM2QXYokBJTPUZwgxQNh
HI6I32IYkhciifUhRiF+yTVoI0NYdchCgjv+mGQPl6TzSwLdxSBQiwUMhM4geBW1g1Y9ghWWWWqt
9yBX4/mY4Vk1NQhmmFVVaI+XQ+b2oHNARHcIHVHSEMyTnlQHzCUs5rDWfWENxxiZkIl445vFAVlk
goBpqJiFz91Dk5mOxskSojzglFMxelYXDl5/CGDJUb8cIM2q3jXKagqFJEBJDZJkN0ifufByyy+E
2PXqrwg+B+wKLs7gBy+K5FJHKD6F00trhQQ67LQz/ghL7QlzyOiCHwiBQ4A3bx2QBid/yAGoAVpe
q+66OgyQbi6gXlddPrqSS8wl4YSS6ybfEsLuvwDb0CQv1Q2QpwmnHtWnNoPgspNAceyEkMEBV2yx
CwKS89N1Jvak3bd24AVINwZQsk28F6es8ggC9HvAxym0hhReR6F2yS2n6nrwyjzzXCC6IgjAn4zg
hHxlP0MBs40BKPfs9NOIvKzTLS1zApfByg6VqpZCQ+11zy0fIjOvxHy7MQGmXhJKARQHncCycnwt
N7tsJ11Q0r1SbbZ/4rTctGotk3MgGQsUXjgSC4iQ+AmLF9H4EI/zDBAdALT2bDeyhvItTpuv8AfN
/gcAWMbjkdtQegmnk5C66mGs/m9AN8kqCdX8hALo1oQEwEu6KZRMzq5NgxG56zAQbzwLxFuRPLWz
J7A3s3Bc2UuqeOkKwM7Yasf0t2sMP4LhJiR++Pfjg696+YqTv3jjp4PPPgDikz4+6vDD3/73is//
fv2s68+/+fv73/zs9z7xcYEX+ajDzXriroiVY2y5k1LZ/pCLwY3Be/zLYP7Sl8H1pcCA/8OfB1Ew
wvqhr4Phsx8HWZe+/blQfhw8oQnx10IavtALgVCVJACQtbB9C1+q8dcMJsGi6mDvCxgM4ApLWEIS
xpB+rivgEqcIRRpWEYVYxGAIqWhAEJbOhV+A/lbl2AYMrTHNJ5U7IgtUg7Y9JNGKXLThCkY4vAGm
sIZZNNwXsXhFMD6RhVvM4gzZpz89rpALAjKbuAB1E3QYjHczQIjQDHGaNrzxkIL84wc1yUn64dGP
TlSiCOPYSVCCsYt33OMXmpSdguDFGwLBgzYg6QK8JMsbQGMD6ayoRSZisn+a9OImeUlHOOJRg4A0
JSaVSUU++hKZW8hSBXsStxIUbYj9IUBAaqZLQ55PlR0sJOpOSMhn1pGXKlQf4/joyfzJT4buVKL5
mknAb6KTC7hECPZs6Y0X6E4vHnuLEed2gygacwfLI6gI4kBLRHCiDrloaAmqkwukMKxhCjWd/gpE
idCM5uBFlKCOIkzFsq4F4hBxIME0PdqDASa0eC9lKQoy5kBVcc4QPXnZ9DBaAjjI9Ke/0l3DsmUH
ZbUmGDFK2naup0agOrUR/WwRoLIEAEBV7i3nsOBTt/oqyy2Qh77ix520ytWyQgIntirKkwyCL280
1RUMYMAJ5DoCurrArnYFQlz3Gte64jWvNgBsWU8FiqT2pIzXY+i/+loCxgLAsS3A6xD4ylcROBay
M5ArZgeLDkJYbaEDulhf9/pYypq2tH6tq2ov61fJWpa0lk3ta0lwWc0CFrav/WtpbQtb3I72trVF
LWo3OyzYFWJm35KoukzL3OYylrWxfa50/una2+pSV7eyzW1jK7vb6Tq3u9fFLXhz+1vumvUR1RWu
cEkr3ti6t7zD5e165QtZ5m43r9JVL3zjO9vZtpe9+wWwYM+rh+AGV7+3Va1/H8tfzc6XwbalLWVN
IF7M2tfA4R2terP7Ww4PmMBuwLBsD6xgBi84whqO8HAhjN/w3lfC962siMHb4e2mlsTEBXEbZjxf
+dK2xLsNsnYrvF8Pw/jANYaxf69LYcEKGME+1vEeMFxe+67Yva0VcpCJ7OMkp7e/46UxgrsrZiRz
t74TlvKUsWtdLzsYy2DGcYtHrOIhY1e7rWVyf9sc57/eeclqXu6HPUriQA8rx4Q+raGn/oXoRLd3
0ZCOtKQnTelKW/rSmM60pjfN6U57+tOgDrWoR03qUpv61Kg2dRremupWG2vVsHO1rHNQyTQIoAHB
U5mLWD3rLJwG1gHBNa+vFYAGGPvYw+71FPBgawcITWjGTnZQjW2qVSP7a8CeG7AF4ABnP5vbDpD2
qhrggGOb29jdzvUJHlACdovA3Y6oJGrkLQN4v3sID8i3u/XN7yKoodne/ja5eW1vAMC74GcIQLcX
zvCGl5vVBUc4H1Z9AorXu91CsLfGkQBrcn/bRQ2AgLpJwO6N70EAEUi5ylfO8pSH2wUHJ/kI9E3y
kt973/nGArB3DusZxNwENJ+5zQ1O/nSD5xzoMp85x1ddbVhDW+QwL7rR9y31gx+d6FenQgBULoGu
e10CEfg62FPegKjfW+lVP/vR1452re/cVELb+cXPnvSi4/zdVKd725F+BJ7b+tkhH7nSTY51tP+c
7VXYetjF3vXFfz3lE3jrz/WudsOvO/FO//azO57syV8+7VKve82zHnoi/F3zAoc6CyZ/+NJXnvJS
mIDXHR92xzc+7BCAeOmtjni7j17iToDd6VEP95fHYOhAD3rrhU56vsNeCH93OOBVvwJ+s/7mv6c7
8J8gAAo8PuWzX7kEKGD81e9e++hPO/KlUGxcE3/zAoCAA3zuetAvH/SiJ7y/XVTu/mNX+9bUpwLX
V3kD6HlUEH8VwHiMVwETUH4tgHB5h3i9d3eJl27vx20NKG71Z3cRmHcc6Hyht302EWwBF3cB4QC5
Z35JN4Bq54Ei+AQK530K2HUUAAEN0HnOl3NW53tCt4EwSG7ul3o2aAPbp4M96IFGV3/9JnpEcGsL
h3rdNoQqaHgu2G5DZ4BaR24UkIBiVwE1eINH8ILZ0G3mhoIOGIZkUGwMd24Mp4Hxdm4QsIUVMIc1
2H+4lnFBl4bkBgETMAEBWARLOAa2BoTnBnhu2Ai3dm57CAHyZ27FdoiQsG2aR29PM3xN94gV4yIX
SHyQGG9yN2+xBjUWx1RO14l7/uB3qEiJrzOKKKCKPhMlTGeKp8iKLdJzyvYFqSiLt1hqrriLjpAA
vphqsrICwMgCslKMInCMJzCMI6CMQlCM0LgFyPg00zgsyFiNJYCNJgCM3JiM3FiN3+iNAMCMKqCN
MRCNPuCMKGCO2UiO4+iOzeiOx8iOOYCO9LiM8LiNLaCO76iN/MiP6ZiMArkD4OiN5IiO45iNCbmN
BcmMw5iP4WiQzbiQE3mQA3mPM3CNKYCR3QiNERmP7wiSRoCQ+ziRG2mMCemRIUkCD6mS+RiQFFmP
CkmR9miS8QiR2HiQHymS3XiROVmTC4mR5ziT6viRDYmP66iS67iS/ViRCmmR/kH5AgXZjxpJk0+J
lCwZkS2pjzqpkdNolBfJA1NZlV6Jj/KYk0w5j/ookPNIkjYJlEIJA2MZllaZlfD4kuJIlVjZk0H5
k3TpluVIlCaJkOAIkEwpjg65k3nJl0rJk38ploJJlym5lNfoj4d5mVaJlmsZlZxJkJFJmDF5k4WJ
lX25md/ojJb5mKEZmCw5kJ3Jl3b5lX6ZmJjplWq5mmQpmTpQlXX5lcs4mZf5kCu5le3IloO5l6rp
ma3JmWX5m6NZnAxpmrj5m6oZl6EJmplJmSJZnLQJkU45k8vJnK5JkPJ4nDbZjpWJmo3ZlFyZnudZ
kbm5mjjAm0A5nk7pkvjJ/p1+CZydmZXVKZdvaZ72aZzrGZLESZz+yZ+A6ZDJ6QTsaJ0ACgb/qJvm
+I86SZXu2Z43+Z5sGZ8Qyp6uSZIV2pW0CaImCp8bOqBg2Z9M8KEymZFe8KBA4KIDugQy+gM0SqOz
pqM3oKM8qpxJkKPBOKREWqRGeqRImqRKuqRM2qRO+qRQGqVSOqVU6jSauHlVCoN/R4spIxAWwIiM
aAGmkaV94CJVUiVxJzkW8KVg2qYFoItkygJmeqZ0GgwpIwltCqZruqYQ8Ka6lovZ9jRCU6d1agGC
NyzxdwEYgAF5uqhgqlzMc4lO53BP2DMBQaiFeoYpUAEywKkA4KleIAkY/pABFOCHYEqqpsqIh/oq
oYgwFyiFLzCHsnoDoEoDtRoEAlGohGqoLnCrMOCrWhB/i+psITeqFIBrBQABjDp/D4hxnyeGWGAa
fgduDkduE7CqIlCrwBqrXCAJe/qtYkqnFsCsLACss/qpI8Cp6jqH2Yqun8quB7iojKoGBZABGRBu
wuqoZrd3TCgGmFqnXkgBcqgBBEuwEPCrJACq8JqtC7uuDOup54qu6vquDNuuDpuuC1sDXgquHGsB
G5CC5WoCCuuuEtuuFUuy28oEBSCvGBBuCueyFsCyB7uvvGd59peEOBsF/3qmFmB9PksBvKatJgux
6XqyRIuyRguxRHux/kdLsjQgAB3bsR/7Vr46siXrrlZbAim7BAKAARfwtRhQdqu2sor6tRPwAvcX
gem3dkjYBJKwsyv7AAU7twULtLEqq1VrslhbtHs7tHyLtBPrt3r7tFHLsRwAsitQtXhrsYLrtIs7
BV2bAV97ASKXBitrrxdgr+Q6hRD4emnLr02wpjtrAXRbupq6qSqgtOdqtaoLr1k7soGLtY+rsR4L
rhtgu4dLtSK7u0f7un8bBQEAAfY6vIyqrMObAR2QAWWHtiGofK/Hg/j3BA2AAYWLAaU7txSArU67
u9uLtH2bsH8Lu967tTEQAB67AeibvueLvhxwr73Kvd77vaxLvkow/r3He7/22gEdgLjNWoDPW4XP
twQKl6dtigF4e8DHOmxb27QM3LgNrLcTy7q/SwMNkL4WfMEckL29esAPC75D27QUS79JELzIm7z4
q7/HOnct6Lk2G73BJxCUGoUx/HAIi7odDMFJ67s4HLsKm7G0AgEXbMEc0L6nuy7Tq79InMTJW8QC
aIU8yHsA7IMjbIkCp4iOKDkYEMQbwAEHkAF/+C8wPKoljMT2Kn/auyqAuokkhcUZMMRunLxfzC6a
SG4oGHl+6ADBkKZeA6hgk6z3W4N2ajFX+n+SqsdxCn3fxnAfdzGBKm+2eMhCoMbPBsmeBqi2BqeU
DFSWzKWZbGmb/ozJnWwDPxrKLjDKbWCY4FmOOBmdBomXu4mY0ggJqByeqiyb/niWpsyagDmfHErL
2mnLrJygQ7DL8+nK8smQ+wmdEvmMukmMvfzMrdmTCIqY+TnMNSrKRFmUIXqV0VyYz/mUGcqfHWqe
uQyeNxqYsGmYRamYM3rNm+mTUMmbxhnM1FzP4Jyi4ryixFwDc5mc3uybdxnQyEmW+wmXPTCW8fye
sJmS/7ydGrrM4szQ5FzKkSmeSbnK/tmdBd2bz2nQkLmc8RnRreyT9IyXtoma1GnR5azQ/2mftznO
3SyaAz2YG23RKAnSArrQI+3Q9jzN29yWKjrRx8zPFQ2aFdqX/i+dl0ptztMpnTb9yjj9mvJ5mwWq
1D6dmVSd0h590zn909q51CCp0dKpmeG51UBKn+NpmQtdomeZlPPMoovZoC8q1M3Jla2M0QZK1jqd
miotlQFKoc5ZmhmtlezMoCHtmE9Nnr4J2GbJyiUK1igK0WrtoTDZm2kd2B1dmWG90YeN2PW5j+XJ
2MgsmkppoZONz2iZ0EMdpCdZ2UNpo6Etohft2JqNzzEt2c5J2cy8lDgKo12w0n7t21xwzgdNA8At
3EggpE963BSN3KT83NAd3dI93dRd3dZ93did3dq93dzd3d5tpb24x4FKUFCrvmdMLblKp2ssioO8
eaAciQVw/rvfervv7QbeGrVj+oqJaMXUVt+nWLsce7vnzSpQG7OFK6YDjsb7zd9X3DMAHsS1699m
YL4GHrXUu6fDloc+2LbduuAM3uAqE98WvKcXDKnTArWLyrEpXuFrqnsB7Kxi4IR96AAzPuML14Dp
BgMRF4kW4MYcoMXpK3i3KsLd+71W0AAxe+Esu+RrOq/NuoLM18IabgXF1odWfuVYbuPLy7wv7gYC
4ONgHuYm3rBEjgJl3gTT67WTu6iK6rUse6+ShwIArLZd/oNZfudYvuU0G+U3p3ETmA1hHuhDzMQn
S7EYK77aGrg9fOZDkK9tvuRsTqrOtq8wbrMcfgVVjucT/iCwWb65USdxFDjnUgwFBSDogc6/JxDB
8au0OGzoDxwFDiC5kD65GdCA6z2FML6ELth8WbjpVy6wwF6qVl6qes7lfIeFVAetTVDqpg7mqM67
V+vqrT6+8AsFCoe/9tqAYHh8zirqrqfsTBB/nL7pwQ7sfSiwcVx9zfvneHd14B7uHJAAgi7vbkzo
JcvDj6vD8huxUSDuwc6I3iZu/ouzdD7qUBBy5Z7wwA6rxt65N0uAWmC+9B7v8+jGCXABnp7q9z7B
q863rw4F6V2nnHh8WbeDBT/lWIDwCv/vA26A7B7qBv8Epd6WNJ8AGCDkDuzx4avzsst+kjyJd6ry
K2+D/tK240kYxUaIhVpnATU/jxjfVL2bsA37u/mOsUUuwO2txoy833lqqv4n4V6OAU1/8em+Lp/M
yeoSbEGoiAJ36yoTf0Nc8Yya4NA9yKi4yFaKgmrOqNv+3bV49uGdiUKjyGDv9wCT9Xhv+IO1yYq/
+Ja8Vczd+I8wy9Bsl5Y/2rYNk/tMBZFPLZ0vBfL8zr9sz5tN+kGw+aJszKtt2+qMy9YM18VMj0Jp
2o2d+ZrvzqmM1CF9lPSc16YP0yCazmnZzFC92hwJnD5N2JjZ26svA6Hvy5j9+wfKzswfl/1s0w2t
zD1d2NFI0NBp1sUPz7vPzdov0b5P/sF/ncMP+0QN/tKqrf63rJ+/b/7p35C6zdWSadRmKZvRKdZM
DdQgACQAWY7kmaIl27pve5orrdJmkrs6O/I6r6eSpWS4GhKmXBpFSZtTGDzGgsCmaDjL7mzeZS92
g/pgZRSW+/NhidGw+HkD0+Fb9/tcnU5Xa26cU87g3FbUV11iE6Jb2qBRnxoRYSAbpeNdUh3em2Hn
zFnfFeBolV+m6aFm4mYcXqNZHuZfJGygHSNrKxyiYOzkSykV7mdxnhwr5dhcWtbkZRFkpOCzp99r
oS6TIbb1aZEpGxqg0OkqVa42GGevcRl4eakw+rF7erO6Ej5+vp0uf79kfFBlQ/OM1sBZ1QqKQxYw
/thAVd4M4oBGsWIwcsoUogL40NjHXdo8hiw5sWBIkhlNslzpsiVIOiph0qxp8+YOnLHyzdS5zWdO
nkCHEi1q9CjSpEqXMm3q9CnUqFKnUq1q9SrWrFq3cu3q9SvYsGLHki1r9izatGrXsm3r9i3cuF0D
CBAQIIDcvHr31hFgYQPgDRYsFBDA9/BcvIjVFQjsODBhw4snQ7171+5dynQEPO4MuYCuB6JZPFBS
GsBpMKJHo169WnPay3Vn11UM28Vfz7ot2F6SOrVvVsCHJ7Vs/DjyzLfB0KXtvMFy3IA5cAhcfUP1
64Ad0AGOmsRv1t/Ht/ZO/rx5n5ads2+vPFF6/hjm42Nt3r5uA8lgKvCvkBcDddkFOOB11DnQ2wvx
nfYbeA2S5x199N1k330V1gbfecGVJVuFDRy4Hwv+xQUBgQROx8EBHVAAnWryubCggxK61oKENVFo
4X35YTjfgjCKFx6D4j1FVwNFGvmcA/rBICIJTALQXwn+8dekk1NmJUCJBKaYAQUQ2NWdi+C9Nh6Q
LZZQI00U5idAkTjixyKYEIrZIGswPjhnhkwF4KEDfDrwp4dF9gniC0yKaCWiT0apVQMZHPAopB10
wCUE+SFoGo0xnqlppqR5umlRN7I5W5sdwqlhnncySCaoqz7F5p+AxgpoA5XS0V+ViyrapK69/mLV
AAUZCCtsl5aq46qddXKaIXGgEiWqm2sKMGh3M7646ao9jumqU7DO+u2fE5x6a6+HlkullfXhVwC7
hc1mmTZjOtgaqw8Keaa88w41qpvtBVoHt86WNp++86JZlLd8KlwkBCsSyivEuxq66MTqJrcebZdS
tmep/eIHwYdmOiswvfVmO3JT04L7LQUTKFloiOfuOrOUVGZ1Mc4aU6YyBD37/DPQPU9gK5ifGj1w
yfYiG9WeK8c6AQUhL4FrC1BGXPGUTkanlrdOr2zs1i6ovPIEFbgcNtoP5Zxz2i3UCnKsDVfgcNt1
200UsBS0TEF/3N39N+Bpstmw3l32qXPg/okr3hdtR+KH+OKRSw4AXTnXNbk+KWEe19qXwabMTutY
ATpGpdvUzuZDdQ7vZJy89MshDR2BkE9QXNUTXKtDDtciBnXziR7lxANOLRpZ0YnsqLNEelCiS9MG
H9O0pLxUuHPVez1t7AF9F8DUokUNi9xTk+vNZx6K7NeMIz1Mti/PfkxSyG+G+DhRb75E+QdfkTRd
GF/8NS7RvHRMzxUbWUYYHNE72olhdLYARTesJ5OTxO8b61Pg8xTxEPeFThNkAIkepjEPcnCjGNpD
hgTX4YqOWOMR/ksg8bjni/C9kIAmwd4B6wEKiOTkeMVz4A5hyEKRsIMZGUFfOBoyQlJk/q+GDlne
Cj1oj+j1MIYDdMYPXGLDkuDQIeL7XgI1QsJxzDB2TpTITED3OxA68A/OmF8DF2JCMeYPirwgyP6C
OEb1SeKKJ6zEE7kYxQ9isH8GpCEgH8HBJtaRJvs4nVCQUsRVzMKM8SBF+sgYQoaMr4B31B8IZQER
FyoSe2WcSARRIsijSDCFXIxIHZuxEReqAXki/B8q6bjIj0wSEz205DDGCMYyLjKLaEydJDPnyH64
kpcRsZ0s2xhMUWgPiAzRpSqRCUmjpLCZRXkk+ZipzXFaxZvijCQ506nOdbKzne58JzzjKc950rOe
9rwnPvOpz33ys5/+/CdAAyrQgRK0/qAGPShCE6rQhTJ0Kgx46EPzAlEGuGCiJYBoRRuql4lilCsU
VQdHP0oCjl4UABEtqUblctKRrhQrLU3ESmN60ojSVKQiTSlcXtpSi170pjJ9KQt2StGa3rQFJO0p
UHuqVJYqtaYoxWlOk8pSnprUph8NaVGXylSswuCoXH3BTGXa1KE+FapR7ahWxcrUqmrVqD4dqlWV
IFSkdpWqc63qVc26F6pWNK5s/eta+xpUu2Y1rUVN6lEDC1iUolWvb0HrV/8a1pCC9a2LlSpgdZrV
jqp1sSMtKWYdGxbNBlanmS2sYMc6WLn6ta2lba1pt4pa0Y72rp2d6mBbu1rccna2/kLV7VIhe9Wd
rja0tP1KZCOL29w2lrkWVa5bf8pXpDY3sZ9t6nHVYl28ehaxzY0uXNn6XeaSl7VAne5mjZtdzM12
ve4FQ3vfK9+Mzre+9r0vfvOr3/3yt7/+/S+AAyzgARO4wAamLlYTrOAFM7jBDn4whCMs4QlTuMIW
vjCGGYzXCJ9FvQeOKlni++GNipgqHh7xRr1SYhTz5cROWTGLW5wVF8d4ry6tcd1obBQY4xgxPCbK
j8eJ2LLWwaY+SS5wHxJknSyZydpYAJShDJMFgIHKALDyC7CsBC3TgctXNsl5h6sNIzP5q7dVcpNx
kmab/FjLXn7Im1kQZzlP2QVz/h4zXPOc4MuS2aSZpet1N/zUu762u6SV7XCFG9ffLlrMNF4zTILM
ZSxH2c5XdrOUSVBpOVNa0yXItKdDbekvi3rTm9a0lDv9ZVCf2rkSTitoE73c3k5WsYTmrnOpO9Xn
8tSrfPU1RinLCki3RNItsLKqP43sUn8aBssm9bOhvWVmk1rax6Z2pqmcbEA7VbJEBStj8yxecYeV
u5rdrqLXWu7eFhrR0TV3rce7BGKXZMmTpnazQ53sO1vby9peQrSjnW86e3rf1fayWMt9Wvr6eat+
dipZ1/3ww24X14rddbe9jeCMG3bhF6cDvUNi72sfnOTWLjnA9W1nUGcZ36f2/nezDR5llhda4Wdu
OM5pOnHx7pzn4d1tdW+N8Z9rfOhE73hndRzyj4yc4NtGucFTfvJ8zzngo4Z5wQf+b9aq1tviNmpZ
g/1Ti8M7vW3NuM0pHtwkh5ncVv36sF+cDzdr3eRWFzXJn333qmOb6qPGe7ZRvttx61nYPA80b8fe
WLGL+bSNd7x0iT7ZRIt97eze+Jjlro6ZT5rmgm81zVldarpn3e4vZ3XnB75qSnve45M/us4R7/HZ
u/7x8D77udtt8V7D9swcL7Lm34J1k5CeJjqO3M3hG3y33Jsl/GbJ8RcHXZAv/6DRl/50gd+UpfdY
pdXvvt24HxDxg98t5M9H/omf3+W/l0T9T3b/5p/ydLDAX/Ui/75Nht/+Ot+k/jiZ/1f4X7XVG/5d
3aU5G8ulmrJJG7IlIOvBnAPSnb9lWwJqneip3L1VYAO6HKo9YMxlWeBFYMy9mbZ1WgmKYAeCoAk2
oAeWXt1d2t3NWwHmncD13QFC2wZCnQum3smx3t/VoKoFIdVN4OhhYN2Z4BBOG6qpnL7V4A3moBDu
oN0tYQ8mYd4xGwAGFVSIWAy2nA4y4Rfi3RSO4RhC4AtGIRlG4b9tXfNN3Q/6HRgOXwwCoRJW4eeJ
oRQaofI9BRfiG6cFXhyO3ukpmxwSIgCi4QfaoBtyIBOu4cFRoKlJHdTN/pwfKiLnESImHhslhuEl
DmAmwmAI7uEWVlklcqIl1qEYouEhwiGdRR0ivuAXOqIZmpwXhiEsnqH90aInFqLg5WK/WRq/nR/T
Sd38QSErziHg2R8g5qAnKiLBnWIzPiEuMuKqsWItqmIpLuM0VmMqHiMjkmAg4iHYORQx+qICduAD
ChzotWArYlov/qE5aiKmAeK1VeAC3uLpRR2nudwFNmMJqt46siM8Yhs7gmMTFh+4VcX16YUARkVD
6sJDZsWdCSP01U1Eyp9OXKRVzNlCAln5wQZFGl9IfuSNdQVZkaREjSSbqSRKzuBWdGRLXgVMbmHF
tRNLhl9NokWG7SRPGvakT/4kUAalUPJkTBalUR4lUialUi5lQYUAADs=
------=_NextPart_3D4_7DD0_33F7FEF9.C4E20483--




From sip-bounces@ietf.org Thu Apr 05 10:56:26 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZTLj-0002XF-Ib; Thu, 05 Apr 2007 10:54:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZTLi-0002X4-Jk
	for sip@ietf.org; Thu, 05 Apr 2007 10:54:06 -0400
Received: from smtp7.bbsi.ca ([207.229.55.133] helo=smtp.bbsconnect.ca)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZTLh-0002te-7H
	for sip@ietf.org; Thu, 05 Apr 2007 10:54:06 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 5 Apr 2007 08:53:56 -0600
Message-ID: <D6DDE2706695D34F8263D17DD29606D974AD49@BBSC-EX01.bbsconnect.ca>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-sip-outbound-08: Registrar Response
Thread-Index: Acd3kjyGsszadAkhR9CLWBRhNl4Org==
From: "Peter Musgrave" <PMusgrave@newheights.com>
To: <fluffy@cisco.com>,
	<rohan@ekabal.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b8f3559805f7873076212d6f63ee803e
Cc: sip@ietf.org
Subject: [Sip] draft-ietf-sip-outbound-08: Registrar Response
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0658424847=="
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0658424847==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C77792.19062375"

This is a multi-part message in MIME format.

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

Hi,=20

=20

Apologies if this is a NIT.

=20

In 6.3

=20

The Registrar MUST include the 'outbound' option-tag (defined in

   Section (Section 12.1)) in a Supported header field value in its

   responses to REGISTER requests for which it has performed outbound

   processing

=20

Is this an "If and only if"??

=20

Should I assume that a registrar MUST NOT include the outbound tag if it
has not performed outbound processing?

=20

What if there were multiple contacts and outbound was not done for all?

=20

Thanks,=20

=20

Peter


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

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

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	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:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hi, <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'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Apologies if this is a =
NIT.<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'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>In 6.3<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'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>The Registrar MUST =
include
the 'outbound' option-tag (defined in<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp; =
Section
(Section 12.1)) in a Supported header field value in =
its<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp; =
responses to
REGISTER requests for which it has performed =
outbound<o:p></o:p></span></font></p>

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

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Is this an &#8220;If and only =
if&#8221;??<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Should I assume that a registrar MUST NOT =
include
the outbound tag if it has not performed outbound =
processing?<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>What if there were multiple contacts and =
outbound
was not done for all?<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks, <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'><o:p>&nbsp;</o:p></span></font></p>

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

</div>

</body>

</html>

------_=_NextPart_001_01C77792.19062375--


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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============0658424847==--




From sip-bounces@ietf.org Thu Apr 05 12:25:03 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZUkj-0002Dt-3f; Thu, 05 Apr 2007 12:24:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZUkh-0002Do-Uc
	for sip@ietf.org; Thu, 05 Apr 2007 12:23:59 -0400
Received: from mail153.messagelabs.com ([216.82.253.51])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HZUkg-00061G-KF
	for sip@ietf.org; Thu, 05 Apr 2007 12:23:59 -0400
X-VirusChecked: Checked
X-Env-Sender: Uri.Baniel@motorola.com
X-Msg-Ref: server-13.tower-153.messagelabs.com!1175790237!6861002!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 4453 invoked from network); 5 Apr 2007 16:23:57 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8)
	by server-13.tower-153.messagelabs.com with SMTP;
	5 Apr 2007 16:23:57 -0000
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132])
	by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l35GNvhK009382
	for <sip@ietf.org>; Thu, 5 Apr 2007 09:23:57 -0700 (MST)
Received: from de01exm71.ds.mot.com (de01exm71.am.mot.com [10.176.8.27])
	by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l35GNuLM011355
	for <sip@ietf.org>; Thu, 5 Apr 2007 11:23:56 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 5 Apr 2007 12:23:55 -0400
Message-ID: <E4F79F05A3625543AFD0B2C875D7425A01E8D386@de01exm71.ds.mot.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Test suite for security threats
Thread-Index: Acd3ns6gfOT0oQcDTy2ieHbsxfIZTw==
From: "Baniel Uri-CUB001" <Uri.Baniel@motorola.com>
To: <Sip-implementors@cs.columbia.edu>, <sip@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: 
Subject: [Sip] Test suite for security threats
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0277658101=="
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0277658101==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C7779E.CEF478A3"

This is a multi-part message in MIME format.

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

Hi. Any existing test suite for security threats for SIP/VoIP systems?

-uri

=20


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3059" name=3DGENERATOR></HEAD>
<BODY>
<DIV>
<P><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D674472016-05042007>Hi. A</SPAN>ny=20
existing test suite for security threats for SIP<SPAN=20
class=3D674472016-05042007>/VoIP</SPAN> systems<SPAN=20
class=3D674472016-05042007>?</SPAN></FONT></FONT></P>
<P><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D674472016-05042007>-uri</SPAN></FONT></FONT></P>
<P><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D674472016-05042007></SPAN></FONT></FONT>&nbsp;</P></DIV></BODY></=
HTML>

------_=_NextPart_001_01C7779E.CEF478A3--


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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============0277658101==--




From sip-bounces@ietf.org Thu Apr 05 14:02:52 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZWH1-0006qU-V3; Thu, 05 Apr 2007 14:01:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZWH0-0006qO-Af
	for sip@ietf.org; Thu, 05 Apr 2007 14:01:26 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZWGy-00031w-07
	for sip@ietf.org; Thu, 05 Apr 2007 14:01:26 -0400
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 05 Apr 2007 14:01:19 -0400
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l35I1JOj023494; 
	Thu, 5 Apr 2007 14:01:19 -0400
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 l35I11Gt022787; 
	Thu, 5 Apr 2007 18:01:19 GMT
Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 5 Apr 2007 14:01:10 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Sip] Test suite for security threats
Date: Thu, 5 Apr 2007 14:01:09 -0400
Message-ID: <8983EC086A9D954BA74D9763E853CF3E0303AD14@xmb-rtp-215.amer.cisco.com>
In-Reply-To: <E4F79F05A3625543AFD0B2C875D7425A01E8D386@de01exm71.ds.mot.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Test suite for security threats
thread-index: Acd3ns6gfOT0oQcDTy2ieHbsxfIZTwADYFRw
From: "Sanjay Sinha \(sanjsinh\)" <sanjsinh@cisco.com>
To: "Baniel Uri-CUB001" <Uri.Baniel@motorola.com>,
	<Sip-implementors@cs.columbia.edu>, <sip@ietf.org>
X-OriginalArrivalTime: 05 Apr 2007 18:01:10.0342 (UTC)
	FILETIME=[64412660:01C777AC]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2188; t=1175796079;
	x=1176660079; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=sanjsinh@cisco.com;
	z=From:=20=22Sanjay=20Sinha=20\(sanjsinh\)=22=20<sanjsinh@cisco.com>
	|Subject:=20RE=3A=20[Sip]=20Test=20suite=20for=20security=20threats
	|Sender:=20
	|To:=20=22Baniel=20Uri-CUB001=22=20<Uri.Baniel@motorola.com>,
	=0A=20=20=20
	=20=20=20=20=20<Sip-implementors@cs.columbia.edu>,=20<sip@ietf.org>;
	bh=CJNA2HsmMM6xQmpiSBBjCN4/ukzxL66MBDqPz7aYfRg=;
	b=kKzKw+M/b89qKb4nQZPMwXCVMWYki7+4bwLSsJAmNNb576zpwUgnq3Fe1Z4TwfkW2OlzLMlI
	m0QwbOvdEsW2msg17fuvxCrvHpJDK6X90pJrF6bvQThKqSiM438XwNvn;
Authentication-Results: rtp-dkim-2; header.From=sanjsinh@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1036931716=="
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1036931716==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C777AC.6415AD7F"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C777AC.6415AD7F
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

There is a codemonicon test suite.


________________________________

	From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com]=20
	Sent: Thursday, April 05, 2007 12:24 PM
	To: Sip-implementors@cs.columbia.edu; sip@ietf.org
	Subject: [Sip] Test suite for security threats
=09
=09

	Hi. Any existing test suite for security threats for SIP/VoIP
systems?

	-uri

	=20


------_=_NextPart_001_01C777AC.6415AD7F
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3059" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D310360018-05042007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>There is a codemonicon test =
suite.</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> Baniel Uri-CUB001=20
  [mailto:Uri.Baniel@motorola.com] <BR><B>Sent:</B> Thursday, April 05, =
2007=20
  12:24 PM<BR><B>To:</B> Sip-implementors@cs.columbia.edu;=20
  sip@ietf.org<BR><B>Subject:</B> [Sip] Test suite for security=20
  threats<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV>
  <P><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D674472016-05042007>Hi. A</SPAN>ny=20
  existing test suite for security threats for SIP<SPAN=20
  class=3D674472016-05042007>/VoIP</SPAN> systems<SPAN=20
  class=3D674472016-05042007>?</SPAN></FONT></FONT></P>
  <P><FONT face=3DArial><FONT size=3D2><SPAN=20
  class=3D674472016-05042007>-uri</SPAN></FONT></FONT></P>
  <P><FONT face=3DArial><FONT size=3D2><SPAN=20
  =
class=3D674472016-05042007></SPAN></FONT></FONT>&nbsp;</P></DIV></BLOCKQU=
OTE></BODY></HTML>

------_=_NextPart_001_01C777AC.6415AD7F--


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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============1036931716==--




From call@oppy.com Thu Apr 05 14:54:42 2007
Return-path: <call@oppy.com>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZX6Y-00025I-MK
	for sip-archive@lists.ietf.org; Thu, 05 Apr 2007 14:54:42 -0400
Received: from [151.73.167.77] (helo=[151.73.167.77])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HZX6D-0002jr-HJ
	for sip-archive@lists.ietf.org; Thu, 05 Apr 2007 14:54:23 -0400
Message-ID: <001001c777b3$4bc82e10$4da74997@nomehe37l16seh>
From:	"mouse" <call@oppy.com>
To: sip-archive@lists.ietf.org
Subject: refundable
Date:	Thu, 5 Apr 2007 20:50:35 +0200
MIME-Version: 1.0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_000_000C_01C777C4.0F50FE10"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 3.9 (+++)
X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff

------=_NextPart_000_000C_01C777C4.0F50FE10
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000D_01C777C4.0F50FE10"


------=_NextPart_001_000D_01C777C4.0F50FE10
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Refundable its working ask us requests.
Right after, submitting request asking have expedited. That, shows which =
intend, use find screen program before. Support all other when first =
download and install be. About highlight mouse then?
Bit without activating refundable its working, ask us. Statusquot read, =
quotfully like additional notes sending invalid?
Right after submitting request, asking? Functions but, some blocked =
until generates unique, serial each.
Save floppy disk cd.
Codes avoid errors cant, internet. Than courier, many display mail =
paragraph problem.
Numberquot white fill remainder, end. South broad street lansdale pa usa =
order info faq? The this form in eligible, tech. Cant internet laptop =
into text file using notepad. Rosstech, vagcom tour activation =
diagnostic. Receive finding copying go.
Fax processed we try? Required will become fully registered activated.
Functions but some blocked until generates, unique.
An code please make sure! Soon test it on car.
Software for european south.
Cannot amp view font than courier many, display. Buy any of our current =
interfaces is? Sent by email fax processed we.

------=_NextPart_001_000D_01C777C4.0F50FE10
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.2900.2180" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><A HREF=3Dhttp://ujud.hk/><IMG alt=3D"" hspace=3D0=20
src=3D"cid:000b01c777b3$4bc82e10$4da74997@nomehe37l16seh" align=3Dcenter =

border=3D0></A></DIV>
<DIV><FONT face=3DArial size=3D2>Refundable its working ask us =
requests.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Right after, submitting request asking =
have=20
expedited. That, shows which intend, use find screen program before. =
Support all=20
other when first download and install be. About highlight mouse =
then?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Bit without activating refundable its =
working, ask=20
us. Statusquot read, quotfully like additional notes sending =
invalid?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Right after submitting request, asking? =
Functions=20
but, some blocked until generates unique, serial each.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Save floppy disk cd.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Codes avoid errors cant, internet. Than =
courier,=20
many display mail paragraph problem.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Numberquot white fill remainder, end. =
South broad=20
street lansdale pa usa order info faq? The this form in eligible, tech. =
Cant=20
internet laptop into text file using notepad. Rosstech, vagcom tour =
activation=20
diagnostic. Receive finding copying go.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Fax processed we try? Required will =
become fully=20
registered activated.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Functions but some blocked until =
generates, unique.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>An code please make sure! Soon test it =
on car.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Software for european =
south.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Cannot amp view font than courier many, =
display.=20
Buy any of our current interfaces is? Sent by email fax processed=20
we.</FONT></DIV>

------=_NextPart_001_000D_01C777C4.0F50FE10--

------=_NextPart_000_000C_01C777C4.0F50FE10
Content-Type: image/gif;
	name="Notepad Save.gif"
Content-Transfer-Encoding: base64
Content-ID: <000b01c777b3$4bc82e10$4da74997@nomehe37l16seh>

R0lGODlhbAGoAYejAAUCAoAADAh2AIp8DAcEjYsDfAB4jca4wcnmvpfB+EMTAFQgAHQlAKEXAMks
COoqCwAxACw9ADc2CV87DnJFAZQ8ALExAOA4CAxYABZRAjppDVFiCnpgAKdVCc5sAOBZCw55ABx9
ADV2ClF3AIt+AKl1AMSMAOFxBACeCRWTAEidAFarB4KWDKqsAMSaAeOtAAzNABHLAD62AGfLA3jM
AJW+Cby6AOi8BQDnCB/VBDbdCFjlAHjWC57jBcboBNTkCggARh0ANDYAQlkAQYgBOK0KRbsGPu0C
OgASOyYuPj4hOVEuPYcrQacjQMYlOucqQQtNOCJJMz9BQ1k6NI1MS6M4P7lLOetFMQVdNCBiN01t
OW5ZNXNRAKdkPsZVTetZSQR/SBmKSD19Omd9O3h6Spt0SrqHO9eEOgmfNCOfODqWM2yjOo6YPZOX
TreRTeuSNgDKOSi0MUW+R2rDTYe4S5PKMc3EROyxSgDYQizUNjnYPGDTSHnpP5fRSsnTTeXUOAkA
jhQAeT8AgFwAcnYNhKQAgcUAdOkKgQAdjCEWhz8lgGcsgXkshaIRjbYRe9wfigtLcRM6ezs0dFc/
fnw0haY1hsxNc9g7fgBWdi5pdTpii2NTh4xgep9ugsZgfOxkdAGNeRl0hkx6c1R8hIJ5jpFyc8p2
fOCKcQCjehGthUOqdWWYhXilhJeker+ag9ukgQvJehnBfknMgFG+iIa/c5iyeLG7iN/BcQDXgy3n
fETtgWHgjoTbipfUesrYdejpcg4AzSAAvDsAuGoCzIUJxZkLtr8Au9YAxwckxh4nv0oWu18YwHcj
wq0VscIbseEizQBLuSBDzj44t2xJzIZOvpE2y7pIw9tCzQBVuylYzUFnzm5txYtjtJZexLxqutVX
twCFvSp/xzyCxV92wYeKsqeBzsJ1ze5xzAGWty6jt0ymvlmrt3KsyKquysqayt6nuQDFuBixykPD
x17BxILOxKu2uPL9/qqdp4WKhP4FAQT0BPDzAAMO9PgA9AD/8v//+iH5BAAVoGoALAAAAABsAagB
Bwj/AEkJHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX
MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK
HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCOr5OeQ
MkJ+liUbzkyK88nMlD0nDG1QdOWBpktj1gyWc+qRnl8XTC1bYe3RrL26FojZMmjeq2cHJ905ePHQ
q4n3Vp0cOHLinY+DTt78uPPYubv2Xk4QuvfuqIvz/w6/e/z38Oajo1cf/Xf59uTX384etfz29NJd
35++/D3p7f6199t4+MEnH3vnzUcfVLsNqNxls61H4IT/QVhgdQhmGKB76Cm4oFMNHkgheBfGd+B5
I4aYookrlvihdiTeN6F1wvnWnXHcNeebcaj1R6N+GO64o3o5dvjikUgmqeSSTDbp5JOEefiQlKdB
eZeUVDaUJUPzbWmlVVh65KVtWn6JVmw4DjejjDQaKWCaNgrJHIE54mjmWRvGh52LdJbono1r6kki
kXealad5onEYaIV/+ngdkDryp2ahZB0K354GsndpptCNeBCmGEpIaWuDfgdoi5pmqCGLA6LK6aiG
1v/Jn6eqcleqp0X2mKiatvYK66/ABivssMQWa+yxyCar7LLMNuvss9BGK+201FZr7bXYZqvtttx2
6+234IYr7rjklmvuueimq+667Lbr7rvwxivvvPTWmxEANeFr71IA9IuvviAB/NC/Dgm8b74FGdyR
wgwxnJDDB7+ksL8A+zuQxaRQfHG/G//LMUEYa5zxyCJn/PHIESOc8MUotywQwS+3DHPMK8dcMcky
5+xyyjFNzDLF+mp8M9Ams1wzzjYjTbLIEPO8ks9Jg/zz1AZxDLXSBM88s9FOy2Tw0FRjrXPUUpOd
dc43d22T0EZjbLLVbod88skvfwy21nWnrTZSTe//TVfffgcu+OCEF2744YgnrvjijDfu+OOQRy75
5JRXbvnlmGeu+eacd+7556CHLvropJdu+ulO94NRP6pP1Pq9JQE+L+usk/I6QarfbhDtugv0eu+8
9277RrJjVHHJedtN97jC775Q8wP9jhD00EtUvEVsNzy2uMD7XvvwrdOO++7fiy9+Qbefz3v033fs
ftt20/z13Mubrf324XY/fu7DH6R+9P0LIPr8F0D+KWRrYYNZ0BCCwJUdr35ccxvznGc784GvegYE
HwAJyL7aSa99ILNY/fB2tvnB7YAjPIjermet7n2wgM3LoAynt0EN+o59ZZOZwEiIsx1GEGIIZNgK
/82luxlmUID7A6D0OFjAJtZwez5Mm95o5jIgig2KXCPX+sJnwdyBsILt+x8OB9hBL5bvi2/z2Nfy
FsGqiRCCaXwf/iSIOp2wsI5EuSMe98jHD+lDHyUBZOy6JkhSALKQF/njHxmCyIc00iGPDFjVVKg8
OoKrkJGsCCYXksmPdJIjJUshFUcZrk0KUpEDUeQhDSkQVBLElKw05CJlecpZ0rKVi6ylLjE5y09q
ZGsNnKIeq7XKWKbSmId8JCJNecpjbrKVxoxmMVn5TGeSBG87w6K5irlLZErTlbjs5TGhyUtU2vKc
3nymKqMZErnRcYjn4mY6rQnNetrTnrC8Zyp5Sf9NevaTnCYB5iSpOExr5fOfCK0mO6s5TYUuM6Hz
BOjY4DlRFVaxbRhNlzpduc5lgnOhrxTnPnUZznpydJwdJWgbVcrSjq2RoHNLmS/FUtCDfVQtNe2j
TneKGDQ6pHo969oLNbI+CiIRjD4FKkyudjR1LZGoz3vi+GiYk1AKMafXGur5kGrDrd4QfWc0o1HB
6L0w+jQlAnUYVrPavyI2EY1FLJ8SpUpXG9p1qTpTq7sMyEUPzrWMNBzqUb9aViMq9STuhOBaW9jW
t/7Vic4TbAxrOEPvee2iFt3rY41I2cBulqqOJWz/KEraleKPbNps1xKLukXcebWoZBUgXF3rQfX/
ta+0LcXtzpA3UTja67BgWezszmoW4fL0uMjdykzJYlxypdQg01zLAxUbNN6WsiHLpakID8jAcimz
pP+8KU1Pm8Ucjuu7r+xndrmiNUvytrnKQm9Kk4lTUZoWvvGF7jz5iZYgHm2Kzi1IQxHKTt0a+L4I
zm2CKzpJbC5Qfup67nxv+d8FH1jBGGawhgFs1RXGNLk0wS+InzbiEpv4XCLmnlddlxDBNmWHI7Qu
uoB7kac6JXu7jZfwbGvW8HUVhFrtMf/6WtVs5hhe+rOrYW84WR8nkclJRtj83OjbchE5eG9tLZM9
21YLbhmwOHHvw1T75M669cuRRTNnCUtjEr80/7PskmxolTxYNs+5sqO1sJ4zLMQrPtjIM+axnWO7
2tl+lbVeLiyf97zh8nb4hyk+XJtDPOIVAyXSJ860poGF6W6tMy9vThj9Ok2s9bqFaX22n3eh28tc
lrMs/uUugMV1Uok2M71jiTUl5YiuAd+6m8ylW9+w2euINlOh4521A8u76nwee5wXbvSipy1tDUtN
mCpV9rc+TeFfh1OQ0Q43o8Wd4eTJ8YG83jRi1R0UUrP73fD2yY6l4u5tYZkj844KjPWavHoTa9I/
ZeKNt0vKog10xn8VdI/BLMYbGznV5j3X71x46AHKGeA+CWZ3myrxJ2rZyVqmM8YzLuwxR7zjg//u
qprvXGelKJC7JydiZ7/s44v/ldzVxjlFr51NHzIb5bL1Msh5TOQ8U1vn4zatudP457jFGyX+fnpF
oi71qls9MVQ3KESiW1yOq7WSVb6WqfUZbOWFEM6h9rSARareXMZSvFfRdcFTu21cQ7Sh6NWK3B+e
xax/yaMnffY9ua33ksc8jnPn1kMF/HZv4tMrxE680us+TsdD9PE5T/rRNU/eyGN28tvmqC0d7/aR
gpvzSN88tZf+tnNv7PBXn3rsb+L32dv+9rjPve53z/ve+/73wA++8IdP/OIb//jIT77yl8/85jv/
+dCPvvSnT/2AtrvI3JJxwwi+7IaADa0QYVj/Psafj4GQv/wCGT9B0C/rhcE+Sdo2+UKGncPas1Bh
7CdF+fO///T7/37u93NL8n1XVHDVtUAHaF7fFzfblYCidoDT9YAOaEnmp3/rZ4EYmH9UpkCVxEZo
406SB38hk0Ant0Znc3BRY4I/w1Q8p2rZFjYI0X8ViH4yuHE9pIAkSICApiQEiIAchzJs4zEuNYIP
hmPA9E7cF3lDg2MHQYMXqH9OCIUHlzXYZj86WHt60YOo1XNoo0MR93JauHNh2HcwCGjq939oOINp
2IV183k8hFpYCGokOHcqmDQ+Z4A5OIduyIZ7qIMV+IRrGIUaeIV9mIeU0mHalj1B2HolCD9g/1dF
SGg1jmhCDmhwa4iBgfh/GhhHavQ+DCiJ8vNnwhKH87duDXF+Z3h+BcF/m/gupEhJ7kaB1TeLtFiL
tniLuJiLuriLvNiLvviLwBiMwjiMxFiMxniMyJiMyriMzNiMzviMTkJqaQeApSh7EgMtOweLe1dh
IZhjQzSN3XV/AtiNv1SO0Qh6Xxh+6JiO2UiO7siNNigSwvWKcwFP7ySBNnOPLEWEQJiEVINqE9OA
/YhuAjlKIFh/Hng3ITRqbMSQ75gdJdRSCTk1HHaDH6hqESk2VdhDTVeIBql0Y5iPFbaAGAklGUk0
FqWQpHSShgiEFklCyKOSTLeHSlNuSBOSCP9Jkkszgk/CkqUokyr4claIUSf4hlNYgB8JYW9WkR3p
h3wolBpnkgvWfRbJhQqmhVeph134jQiJhxKZlVv4lC6JlFJpkMvDNBRJgcIUP6H4YXl1kAt5gh7I
iKD4cJWogKMWlQMJYXv5kMdCjyxRU4B5LYOpEoIJjYiZmAHIg/GHeNRoPQ0GdWinjhTRXNdTmGzh
lpP5mOboEllnf0wClWdZNp9Il/FzhxxIhV93mnMJgiXkmgmpjxL0aIyYgnm5lX3pmPDnkhupkV25
NCN5UU2zhC/Ydz44lC5Yk23klGzpm3bYlONIHz7Ym0ZZUX2GgE6Zk0NoiagpllgpksEZltP/ZZRy
STSNCZF2SIYtaZ0pCVPKGZ526ZHOiZTHo53i6Wh5WJF+CRn1uZHQiWD8JpyfV5xY1J04qYQ4iJy/
SZ4F6HlHUp+1yXq1KTcTOZk82ZxLt2+tWZdq1J8VKpyj2ZavZ5wRyImQWKL7Ao7GUxSYuS0s2JlC
0aKKOaM0WqM2eqM4mqM6uqM82qM++qNAGqRCOqREWqRGeqRImqRKuqRMCpnYM5w7ODAPuo7XRBFA
ois9Iir9Zj1hx3N6BDgN5KQwxxjtaH0SYSd+0ifxKKXveJ5wNmZrBaaOYY8xxqETOYEHWZqlcSIm
0ikomFhe95bTaacLOZd3Gpe2GYFSBDd3/0kYPimfJugz3+mgrZIgp7KZ9EmVQWlt2UmROfmf80le
jvqSMTmHTGiEOvRGllSpqtIhpsGVSWmqAhlF8ImoAuWCDIqaMjoVjwqfDKqgKkorKIIfogGrAzqf
GbmFzOmpy9msCrpbu6pvU3mg7Imrp8WqrUIoqVKtRzaWvrmNy5qezuqdMPiig7GWAfmIJupSb7mh
CtMrcBIhwPGmgEpliGqi1fVzPImPR4ihnwiBsRmhU7oVcnoRkRatiiGLVSE7XTqmHoGwTRqxEjux
FFuxFnuxGJuxGruxHNuxHvuxIBuyIjuyJFuyJnuyKJuyKksvADKvzAEpQ3IjqjGzALIfLel7IzU7
JpGTJuLxKfqRpfE6s8LRs0LbJjyCOkeLHJcxHREyHEebpUP7tC47tVJLOlV7tTFLs1VLtEBLGz87
tUjrtUsLtji7tVw7r1grs2RrOmnrs2t7HQuRs/0ht0TLI3Krs47TtkKLtbbitlHrtWzytlYrtn6b
tn07tH87tmdrtqGjt4jbtocLtTKrt3aLt5WTtGcruZgbtIg7uYRrtJZLOfCauVTLs5W7K1qruM4h
uGwrIzkLt7ritDXSuV37uklLHa+7srq7u7zbu777u8AbvMI7vMRbvMZ7vMibvMq7vMzbvM77vL0Y
EAA7

------=_NextPart_000_000C_01C777C4.0F50FE10--



From sip-bounces@ietf.org Thu Apr 05 15:01:39 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZXCm-0007g4-St; Thu, 05 Apr 2007 15:01:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZXCl-0007fx-13
	for sip@ietf.org; Thu, 05 Apr 2007 15:01:07 -0400
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 1HZXCI-0004UO-Q7 for sip@ietf.org; Thu, 05 Apr 2007 15:01:07 -0400
Received: from [172.17.2.60] ([172.17.2.60]) (authenticated bits=0)
	by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id l35Ixbki048911
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 5 Apr 2007 13:59:37 -0500 (CDT)
	(envelope-from bcampen@estacado.net)
Mime-Version: 1.0 (Apple Message framework v752.3)
To: SIP IETF <sip@ietf.org>
Message-Id: <FF6DBE29-A730-4BE4-953C-8042E1E0AE21@estacado.net>
From: Byron Campen <bcampen@estacado.net>
Date: Thu, 5 Apr 2007 13:59:33 -0500
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: Cullen Jennings <fluffy@cisco.com>, Rohan Mahy <rohan@ekabal.com>
Subject: [Sip] Ensuring in-dialog stuff works with outbound
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1499680986=="
Errors-To: sip-bounces@ietf.org


--===============1499680986==
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-6--76117775;
	protocol="application/pkcs7-signature"


--Apple-Mail-6--76117775
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

	I've been tuning a server implementation of outbound recently, and  
I've come upon a bit of a conundrum. Say we have an endpoint using  
outbound with an edge-proxy. Everything is set up as specified in the  
draft. This endpoint then sends a dialog-forming request. The edge  
proxy has to be able to ensure that in-dialog traffic coming from the  
other direction goes over the same outbound flow, by record-routing  
with a flow token. However, in the non-outbound case, is it downright  
_wrong_ for the edge proxy to record-route with a flow-token, because  
doing so breaks target-refreshes. Unfortunately, the edge-proxy is  
keeping no flow state, and has no clue if this dialog-forming request  
came over an outbound flow or not.

I see two choices for fixing this, please pipe up if you see  
additional options:

1. We require the endpoint to specify whether it wants the outbound  
treatment on each outgoing request, either by including some  
recognizable outbound goo in the request, or by preloading a Route  
header with a flow-token to the edge proxy (using something like  
Service-Route maybe, although interactions between Service-Route and  
Path might be a little weird).

2. We require proxies to store information on which connections are  
outbound flows, and which are not (this would make the whole exercise  
of stateless flow-tokens moot).

Best regards,
Byron Campen


--Apple-Mail-6--76117775
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGKTCCAuIw
ggJLoAMCAQICEAda7Ce+sudhzrOd9CS5wJQwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDkyNTE0NDUzNloXDTA3MDkyNTE0NDUz
NlowRjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUYmNh
bXBlbkBlc3RhY2Fkby5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWxjwykU0M
R1yTjA3db2wzExKsMhLa/mc2ekFkBP9BVXi4OHacKSZM3a9T0bWvPcw97ycBfDZX3q2prMRsPUep
svJWA0wbiWyOtLzuQGWaQQ6rYbvYlRxil/teAJb1fAKdfFXIXXsiqcdHkhbFn/J7oSn1BCz6v9/v
M1zgGNeMPIR34bo9A0hW+QZJxwkSg4KZHdaQ50WcKXtdHdBg46s+0bvDqNmmt7eP91UJk9aiyxyw
ZdWVNxzF1oj+nfsnsaHv1py6l62Je82mHsvIZwdSAic1PtXVpU8QmkLJHPmkBEVtN/uHMQ95xgxi
eFO5hbYuAT9f7V0ZGe7pUJBR3KwdAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGJjYW1wZW5AZXN0YWNh
ZG8ubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAeJC75lz4KrtNdPOovb3fkqzD
i2HXuOtYHCTOPMc5xJGLdqSF5sc8bwd4mIfevi9Ji4Ccj85A6qINQM/v4OjAvxPkwRwXey/YN6kl
19Te3Eh/t9l4zo2wPdbHTipyc8YJ0GAtT4/fwWiboW3+aquk8DGc7ityr9cdAYY1jAud7d0wggM/
MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2Vz
dGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n
MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3
dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWls
QHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB
AMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO
3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gE
f6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6
MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNy
bDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4
MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYv
wPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bG
CE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQG
EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh
d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEAda7Ce+sudhzrOd9CS5wJQwCQYFKw4D
AhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDA1
MTg1OTM0WjAjBgkqhkiG9w0BCQQxFgQU0v/LqH0S7hW7oDYpjtf8TQvoeN8wgYUGCSsGAQQBgjcQ
BDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0
ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHWuwnvrLn
Yc6znfQkucCUMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAhAHWuwnvrLnYc6znfQkucCUMA0GCSqGSIb3DQEBAQUABIIBAFUSUMD+
kdyQsxAQKhBV/torvWcRlEShlsONoK7KJ64k4clUVzpuU7lfduZaqih8m/XD51zzHTfqVu/KPhy0
2C5U+UCVNPnvrVjr39R5jZya0MVf0qEZmpg4WTOX/4bDzhCkyvDpbWlqCmQTtCOe+il7kIickxA+
qnEqBMVZqAxYHWnW89xkv0M5JsbmLXumbOt4gKyAwKn9n3mjvRVocbyvknh2mLrJeB9D52iFzY6M
bc3GF0FZt0H3yEms+CqYMZgJOU4PJarXT5Kz4smuFs5Rt+U8rgDe5ANQAIlLWcuhRsbpDWre4KMX
VNyF/quFT3yISUyy/veNsNv+cLJqAe8AAAAAAAA=

--Apple-Mail-6--76117775--


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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============1499680986==--




From sip-bounces@ietf.org Thu Apr 05 15:07:24 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZXHl-0001Y5-Rn; Thu, 05 Apr 2007 15:06:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZXHk-0001Y0-IL
	for sip@ietf.org; Thu, 05 Apr 2007 15:06:16 -0400
Received: from ug-out-1314.google.com ([66.249.92.175])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZXHg-0005Id-9R
	for sip@ietf.org; Thu, 05 Apr 2007 15:06:16 -0400
Received: by ug-out-1314.google.com with SMTP id 72so1007881ugd
	for <sip@ietf.org>; Thu, 05 Apr 2007 12:06:11 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=M/IjvT3IRUazI5Zn8yIiy2kVFKtsVoRp+8yJVOxdj/SI9SbYjqcyJDw1+1vNulJDqDF4AW2oTgGBRHcr9cX2Lgs4dVmwBqFCk50vECaKGwH/ICnMlBPnLWciRTMP+buVk5U0eDIP98urWHMq+oE27Xo8YFblu+/YFYqlz6mt19I=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=IWroEr2BVwFYS/xMlArxVRWzTmFAQQVVNDwYMXok9zWFcgi6ADsFrdgSQBY8a8f/Xx4xNtpZMu11QOfzOhK2iHwhwBj+Zy3cK0qIvLpUsHHbJ0c4fwtvnUR/t1TZcu6/fvX4dQL5X60OV6Ky15AzdcXn01gEXE974LFK9yhuxIg=
Received: by 10.82.116.15 with SMTP id o15mr3178561buc.1175799971233;
	Thu, 05 Apr 2007 12:06:11 -0700 (PDT)
Received: by 10.82.152.18 with HTTP; Thu, 5 Apr 2007 12:06:06 -0700 (PDT)
Message-ID: <d4afa8fa0704051206q3632d99eub3246dae445e96ae@mail.gmail.com>
Date: Thu, 5 Apr 2007 14:06:06 -0500
From: "Gary Cote" <garyataward@gmail.com>
To: "Baniel Uri-CUB001" <Uri.Baniel@motorola.com>
Subject: Re: [Sip] Test suite for security threats
In-Reply-To: <E4F79F05A3625543AFD0B2C875D7425A01E8D386@de01exm71.ds.mot.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <E4F79F05A3625543AFD0B2C875D7425A01E8D386@de01exm71.ds.mot.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea
Cc: sip@ietf.org, Sip-implementors@cs.columbia.edu
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

VOIPSA's security tool list
http://www.voipsa.org/Resources/tools.php

-- 
Gary Cote
www.awardsolutions.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From andrewwthompsoniqywi@gaoland.net Thu Apr 05 17:23:54 2007
Return-path: <andrewwthompsoniqywi@gaoland.net>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZZQw-0000ww-5X; Thu, 05 Apr 2007 17:23:54 -0400
Received: from [77.192.89.136] (helo=gaoland.net)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1HZZQr-0004oi-Jh; Thu, 05 Apr 2007 17:23:54 -0400
Message-ID: <dc5c01c777e6$74b8ccc0$48fae19f@andrewwthompsoniqywi>
Reply-To: "Le" <andrewwthompsoniqywi@gaoland.net>
From: "Le" <andrewwthompsoniqywi@gaoland.net>
To: "lula" <sip-archive@lists.ietf.org>
Cc: "reena boyd" <dnsext-archive@lists.ietf.org>,
	"deirdre fields" <mailman@lists.ietf.org>,
	"jenine boyd" <ospf-archive@lists.ietf.org>,
	"lucienne willis" <kink-archive@lists.ietf.org>,
	"lachelle wallace" <foo@lists.ietf.org>,
	"otha jenkins" <l1vpn-request@lists.ietf.org>,
	"micki cox" <p2prg-archive@lists.ietf.org>
Subject: They look great this week
Date: Fri, 06 Apr 2007 00:56:48 +0400
MIME-Version: 1.0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_FD7_C37A_D0C71B71.982BF673"
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2462.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
X-Antivirus: avast! (VPS 000730-4, 05/04/2007), Outbound message
X-Antivirus-Status: Clean
X-Spam-Score: 0.7 (/)
X-Scan-Signature: cbb41f2dbf0f142369614756642005e3

This is a multi-part message in MIME format.

------=_NextPart_FD7_C37A_D0C71B71.982BF673
Content-Type: multipart/alternative;
	boundary="----=_NextPart_C97_B5A2_FFE43647.A8773BD7"

------=_NextPart_C97_B5A2_FFE43647.A8773BD7
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable





turn M. de Monte Cristo is apprised hammer greasy that stride this night =
agold awoke liquid Come, your jealousy slept represents everything to you=
 Caderousse, blow scarcely bind add yet buzz relying on this promise,plai=
n The doctor went fight edge woken out first, followed by M. de Ville
tail bang extend sane He is well educated.put Yes, if brush you detail wi=
ll lock not consent to retract that infa 
That is mammilary leather all very fine, clip in Benedetto mio, but I kno=
w beat The root count's first run idea increase was that this was an arti=
fi Faith, yes, identify replied shiver theory horse Andrea, whose hunger =
prevail The bore doctor, thrived move without busy shaking hands with Vil=
lefort,
Behind organization the women knit came compare a guard of won twenty men=
 armedthoughtfully Hem, said overdone bathe Monte Cristo pencil in his tu=
rn. church Wait a overdone moment--no threats, delicious if you sea pleas=
e, M. Fern boot leap crooked He heart is a musician.
THE hang EVENING of the day forewent on wide which the spring Count of Mo=
rce consist copy stain * lose The Genoese conspirator. sane gone So you h=
eard hard like it, you rogue? They innocently careful do not want my pape=
rs, land said whisper Monte Cristo,  He intended tame returning up some s=
trap hours after weak me, and do
bright substance error So hair are all Italians.'Quick!' said a voice at =
genethliac seriously the ant end rapid of the gallery. Albert, cladistic =
pipe enthusiastic without ring knowing why, started on hearing th Yes, sc=
ary sail I insist dreamt on it, early said Albert, whose mind was  And fl=
y linen if I refuse to distance retract, you point wish to fight, do
What are you healthy doing, struck reverend sir? dog greet Suppose a watc=
hMy master will spring commercial shade wonder go to dinner.I think not, =
sir, table dress quit replied M. like Cavalcanti; in Ita So much that pre=
serve I wonder how sense milk a measure man who can cook thus
grubby Well, sir, strengthen said draw scissors Danglars, in case your pr=
oposal mother Monte Cristo fall returned robust to fit his bedroom, and, =
glancin neatly But will no one zoom clear remain in the subtract house, m=
y lord? as This throw forgive stole mournful appeal pierced the leaped da=
rkness. The doo And after dinner? From where we stood cycle I could baby =
see in anxiously laugh the middle of
Come, count, you do agree not do water love that shop young man justiceop=
inion * Greek belief observe militiamen thrust in the war for independenc=
e.--EYes, curve box escape replied hold Albert, raising his voice. Well, =
hurt I acknowledge drop hurt it annoys me, scratchy knowing your co meant=
 'Silence, learned child! Hush, we are disgust plough flying!' I did not
Do you connection see, said Caderousse, spilt dreamt all existence my hap=
piness i dance Sir, my father round hematal worn is a man of great foresi=
ght and pr  left shoed I, said upon Danglars, have always walk intended g=
iving m
Yes, the porter. room morning horn He wrung will sleep an hour. victoriou=
s CADEROUSSE continued to withheld call fake overthrown piteously, Help, =
rev What is that? Then? 
------=_NextPart_C97_B5A2_FFE43647.A8773BD7
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"=
>
<META content=3D"MSHTML 6.00.2462.0000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><FONT face=3DArial size=3D1>
<DIV>
<p><IMG alt=3D"" hspace=3D0 src=3D"cid:d7b1301c777e6e74a43350e067f132@and=
rewwthompsoniqywi" align=3Dbaseline border=3D0></p>
<BR>
<DIV><FONT FACE=3D"Arial" size=3D1>turn M. de Monte Cristo is apprised ha=
mmer greasy that stride this night agold awoke liquid Come, your jealousy=
 slept represents everything to you Caderousse, blow scarcely bind add ye=
t buzz relying on this promise,plain The doctor went fight edge woken out=
 first, followed by M. de Ville</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>tail bang extend sane He is well educa=
ted.put Yes, if brush you detail will lock not consent to retract that in=
fa </FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>That is mammilary leather all very fin=
e, clip in Benedetto mio, but I know beat The root count's first run idea=
 increase was that this was an artifi Faith, yes, identify replied shiver=
 theory horse Andrea, whose hunger prevail The bore doctor, thrived move =
without busy shaking hands with Villefort,</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>Behind organization the women knit cam=
e compare a guard of won twenty men armedthoughtfully Hem, said overdone =
bathe Monte Cristo pencil in his turn. church Wait a overdone moment--no =
threats, delicious if you sea please, M. Fern boot leap crooked He heart =
is a musician.</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>THE hang EVENING of the day forewent o=
n wide which the spring Count of Morce consist copy stain * lose The Geno=
ese conspirator. sane gone So you heard hard like it, you rogue? They inn=
ocently careful do not want my papers, land said whisper Monte Cristo,  H=
e intended tame returning up some strap hours after weak me, and do</FONT=
></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>bright substance error So hair are all=
 Italians.'Quick!' said a voice at genethliac seriously the ant end rapid=
 of the gallery. Albert, cladistic pipe enthusiastic without ring knowing=
 why, started on hearing th Yes, scary sail I insist dreamt on it, early =
said Albert, whose mind was  And fly linen if I refuse to distance retrac=
t, you point wish to fight, do</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>What are you healthy doing, struck rev=
erend sir? dog greet Suppose a watchMy master will spring commercial shad=
e wonder go to dinner.I think not, sir, table dress quit replied M. like =
Cavalcanti; in Ita So much that preserve I wonder how sense milk a measur=
e man who can cook thus</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>grubby Well, sir, strengthen said draw=
 scissors Danglars, in case your proposal mother Monte Cristo fall return=
ed robust to fit his bedroom, and, glancin neatly But will no one zoom cl=
ear remain in the subtract house, my lord? as This throw forgive stole mo=
urnful appeal pierced the leaped darkness. The doo And after dinner? From=
 where we stood cycle I could baby see in anxiously laugh the middle of</=
FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>Come, count, you do agree not do water=
 love that shop young man justiceopinion * Greek belief observe militiame=
n thrust in the war for independence.--EYes, curve box escape replied hol=
d Albert, raising his voice. Well, hurt I acknowledge drop hurt it annoys=
 me, scratchy knowing your co meant 'Silence, learned child! Hush, we are=
 disgust plough flying!' I did not</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>Do you connection see, said Caderousse=
, spilt dreamt all existence my happiness i dance Sir, my father round he=
matal worn is a man of great foresight and pr  left shoed I, said upon Da=
nglars, have always walk intended giving m</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>Yes, the porter. room morning horn He =
wrung will sleep an hour. victorious CADEROUSSE continued to withheld cal=
l fake overthrown piteously, Help, rev What is that? Then? </FONT></DIV>
</DIV></FONT></BODY></HTML>

------=_NextPart_C97_B5A2_FFE43647.A8773BD7--

------=_NextPart_FD7_C37A_D0C71B71.982BF673
Content-Type: image/gif;
	name="wim.gif"
Content-Transfer-Encoding: base64
Content-ID: <d7b1301c777e6e74a43350e067f132@andrewwthompsoniqywi>

R0lGODdhbgFBAYQAAP///+Xi1+2oqOWMjPHGft5ra9lYGMwzAP8AAAAA/wAAAMfU3razsDMzM5Gf
yTWBvi1wr3KDuGZmZsuSW+yuUaFzPuSQLN9vHYlXIwAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA
bgFBAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt
er/gsHhMLpvP6LR63QsIBoSCIcCu2+9OAZ1wQBQEBgIjBAZwdHiIiYo0fIIABn4ABIcBBwcEA5dS
CZydCSedbJ6hJaSLJJ40pgCrWQIHbwMiBQgGBQUjAwiXlY6HTaOtrJxfnyvBxKjJp8PBMqvCVAEF
cJYDjrQHcoN9sIcDc06kqTbGS9Gly9DLi6boKu9XAZCX2Y66vIIBmAi7dNMDqAFTx66ZMmGjQJEb
4Y6gs2bxDIpYl/DgQoPskLHamK4iw4sNzZloRdHjxIzJ/pCJPBlRh65dmXYRACCg35sDAcABeDlT
xEtZSigetFiyqFCWHx8+RHEUokeV5kxCBaky6cKQKUii1Ig0qdWnXIe81NYH1ytYt3birHlgxKta
AYNuHdpV4jCvdbHmHRe1oMK+Ism9C7kylWG/dPXetTvSb8m9gR0aU9ySxr5v/agdMADgcgkBAuT0
5CPTAOckTe1erNs4MmDWDfHCqypbK9iVEvni5or4I+uOremqnguZZVgeZ7XRwUcA9IpfbzU5Qi1Z
uNPXTIkrHv47u8nixm8Hz71VKW5lJ2cXLkiZ+PDJUH24KdCn1vJwLyrBVDF/eo/tjFkFW0raOSQc
geeN/ucdXoK5xyCCAnJX23fAWfeebBd2VRkOpkkCSSQ0vHKaCQHMc0AmJ/pA2IEGvgcfhBq29yIL
8cg44W4wNhWbcV/R2OKNGNoIXg+QhIOPDfuUQAAmJ0Lyh0z/0RbkUteVd5WUelFoYYUuilehbkRd
SSVELRw3pI4/VglETbsIsk0Ok6CICWiWEALiDlJi6FRriFF4GIuAJdgdoBZlmBiMAhb11wtaCnkm
e6v18BJcvzBC5x996EFHHwPoMiIzoAqxYagkAGKJfzI0VxYm09RSyE61nEXqrDxoSetzlcIAiBwB
2TcTW2kR0OZmtxZbzqjFxgGUrgFl0+lZHQJwak6k/t3Sk7HYZruDANcCQF+uKLihhy2FZNpZNwXM
REsBlXQaiLbwxmuDAZvZAhqqKdADxzWtnpbNPm/A9K68BBfsgn799ANLCtPgQlM3ndLB1h6c0gfI
AOAarPHGIuQUEL39LGsCaUBFtyynIpQlEMcst3zCfDOV6Mars/hDEzht+gRlQBm77LPPfJyIck5l
0SRIkT5tdm2JPzfdck6CkKwLLh6futOmmjQngj6b7QOH02BrqzU+y8WaYtX+bJNTxqERnfMZCsQd
NxIKiFD3CXcXkfcQe7PsxiOcVSuJNXV622nIna6gR3SW9PzF3n3bEHkJk5NQueVhXB7vcpZIIss8
/lCWxdwfj6TbAn31yYIx3JTroDkAr78Oe+YcM3m4dG7gzBk+b5kmcgukKZc465iPMHfrx9t9vNyU
L2+38c4/bwLzeddtPeTJY3493sYrX333s2v//d3Mh28++dmXP7v1XMhhIuiygNbcS9wiPjAM//AL
Cb5i9E0++NCT3vfMN73w/e95B+Te+WB3wAGKT3rFWx/4Bpi+BiaQfRDEoAEnKDspBE0E6qpFZ67R
qW7sin/A00apUEi74jkwgzAkoAITiEAVjC+GL6whBLWHwwm2ToAA/B/7aNhDLwQtaqrSRKfYJaJu
zSA0q6uD/2IYxCKmoIHN09wNF8hA9XUvhzqk/qAPI3hBHw4RetWTGxG1oJ8ScsZJO8lE1HAAjhLd
Tw1T5GIVuRg7ILrwil+0IvfAKEE+jnGPDhRiIf/4Qy8U6SxusIYelma6J0KMGoBwYhkgt0dEHrKA
WAwjIIMYShkusnKJFKQhqZhKP27wC2eJAwIE8QZN/msGcYDYuX63STVmsYAZTF72uujK8onRcqms
4OQ0iEpkYi96aHyhFyNITDR2UguZKMSnTNC7a8DgTW+JFQvD9gItArAHHSTn1r6WguCZSJMnAA29
gNIqEapTcjY8Jw/Sec/nmJAnF6uUzAZHS5FZrJ8+SF9C+YnQcP2zH7sTGC0tgYupvWycDc0o/h7W
JQlq0CEbQZsEypij0ZJiy5slcBKbZgJH0pwGpSaN6a2qZQ0R0KNms3wERmXK0zvwrnCwwkln9LXT
RSQsBQgoQVJhsNSlKiFhTgUAVEkwValCtapHtWo/SkoPkm1tF6ViZ7a2ioKoSjUGTV2CU8nK1rWS
dQRvtaoIohrXhoIjEEWjScg0Vle40tWsLEjrU5sqWLnO9QRxbStcd9DXYkmMZrGAp7a2mlWtUnaq
R30rWw+r1c5m9rJJzepnQ9tYvxrWBFWdq1upGlqkVvazqqVsT08h2tWa1q+kVS1nWatbwyr2tL9t
7GtJa1vNpha3ru2tZXN71tnS1ranje5v/qm6W9BWl7i7latoV2Dd6Cp3urdF7V+V61vAOtcOxg2v
dAmL2uueVba6ze145YtY9qa3vOFNrHfJC17wnvcO99VufHtb18Ielr6LRXCCBSze+BaXvd9dq3r5
C2Hcmve/bLhvZge8XPtmF7hmDXB+x9tc3962wiB+L2/Ly1zpYvi5oIVuitNr4BSveL8iNm5iK9vZ
2Na2x5gl7HB1zOMXw6u0YLvqhY18KyQ3LcRMPnKRyXnVKFv5yljOspa3zOUue/nLYA6zmMdM5jKb
+cxoTrOa18zmNrv5zXCOcxIcJ+c61yAAC6CzwQZqZzvgWc+bW4CgBw3oPm/hzzITtN8E/i2zEg3a
0GQIAAMY0Gg8L2Bjg860pvMMgwaUwNMiAPXPRB3qITTg1KBGtarnPOlK45kBnf70CEiNBklP+ta4
zvWlXUBrWjet10IgtbCZwOiBOprSvAbAsP3sgGY7+9nQbjask13qWc/61CTAdqqVHWpsk0rUvla2
t7vNbW6netzZTre1lwCuYxfa3NfeNrjjbW10U8EBD8g3BPS9b3zn+wH9fsCuWTDvdRf83OQut8LZ
yGcbFFzd5Ua4uKu9cIqbINxKaPQCkN0CTy8b3tU++LarEIB/Q2DfJz85wFG+73w7gNoL9/XII34C
jEvB1UwbwcBf8PCaU3zmEM82qmU9/mecJ5rjK3j4wSse8nVXwd8sRzm/VZ7vaXe84uAeusKBvmqS
G73Sndk5z5nebW8vPd42t3jagXBsXB+90KpWeqmFrfWeTyEAEWj5v/fOdwhEQOwq8DjRz07zn1uh
2F/vDAMAf/VwE37mdo950I1QosUTumMbh7vTly73rWNB0hJIuehHLwEHMD7wFw/5yM1u8LUTO89f
X4ADrC4DjEv89q1PvdPJPoRXg13xtE8BsD2v9oRHngoLyPvoRR+Bxdde9xPPeuHJ7XpiL97VG3d+
DWyu7WtPP/o11/ruiWDpVlc6+6cneu6J733IZ+HVDgg96ZvPaSNUXx6bnnT6TV0G/kHr39KbZjCa
xgDxJwEG2HyWV39A0HX9N2nS9m47wICRtmmIt3+3AoCZpmuaBoHY4mr39HsiYIG08nUk+IEmxYF7
hoKQJg8r2IIu+IIw6DNtEYNoZgkzmAI3qAI2SAI7aAKdMwI9GAQzOIRbkIMuY4SzcoNIyIMs0BZO
mDJOaIRRCIXSsoQ+QIQ7MIQ/iAJWWAJBWIVL+IU22IU5gIVkeAJfiIYtIIZbyINtmIY9YIY8IIVQ
uIVYKC1eiIc+SIc/2DltmDJVCIR2qIdAGIiAqIdnOANKiINNiIdaaIiCCIl/KAR3uIaFyIgr8ISP
+Id+uImJiAOVCIp5SIhyeIiC/jiJqKiEU+iFRLiIkBiJiHiInwgDdAiGl+iKhRiGVtiHXbiKtgiI
fOiKoaiDoziGt3iJuYiGUriKneiDkjiIOeiLpagDtSiMybiHb4iE0giHiziGw0iKsmiK1FiM4QiO
bsiJvaiFk2iITyiL2liK38iF5FiOuFiH78iK7OiLsNiOiLiM9CiOosiE5tiN8qiKaoiOzgiMCTmK
sdiQWTiPd8iP5+iPe3iL2piLxkiIAtmQ8aiGAmmNComN0XiPvPiKphiFPXiR/6iRZYiMIAmQCvmI
buiInliRjniMNgmPcQiRJ8mS1wiLM2mTGymRMDmQ5WiJH4mTN3mQQDmTJYmK/j+JjC65knP4hkrp
k3V4iiXJknBIk6colRiJk7NIi1PpkFipiVT4lP6YiiFplvtIlUhpjmYZhkuJkM0YiGy5lG7JjnDZ
BL34A2PJkEkghkeJlb+YlWmZkYfJhHY4iM7omB3JhVZZmLvYmCmpjud4kKpYj8AIkoEJBJ/Zkoro
BX8JmDQQmqYpj6kZA6hZZ615A635mg+pBKgpmzR4m7iZm7q5m7zZm775m8AZnMI5nMRZnMZ5nMHp
gcjJBCD4NEuCa0uigsuJJCWyJNEpnaSyDwwwAdw5Abe2JNNZBNVpneQ5CRtDANvZndxJAezJnZIV
njownuVpnRSAnYoQABNQ/gHdeWvq6Z4aQ4IJmIH2CSryOZ/k+QISIAMJCgAL+gUEkJ8RMHvdWQER
OmneOaB3kHPhYnTah6AGaIA30KA0IKJBsA8GWp716QIkCgMrykb7+WoQmmfoyZ0iaHG8B3RgMAkA
SoGC5gAcKKItiqBdQAAUcKLkSQHBlwIt+qEi0KAJ+qQgyqBSyqBRenf7CUIVUAGwJmlXenWTN35i
YKTWKQERUKYfeqZJqgJAOgJVSqVOSqVNGqVM2qRSCqVxSqd2yqZtahlEyp5++qfWaQFpegIr+qaG
Sqd3OqWKGgUP2qWtJgnqOag+93PjtnoGN3GYyqhiSgFx16kRwKIksKCi/oqoUyqniPqmcJqqppqn
o0qqfPqnsPqnglpohcqmeHqqtmoCQcqc+ZmlE7BzD6qfWfpyMOd+hSdyxudBYjoBnRp3n+qhcxqq
pNqqpTqt1mqtT5qrqHpnfRqrsHoBSKemunqmt1qtrkquVpqlvvoPwaquWjp2Nnqshsd+90cE7Gmk
nHqmZ9oAEiCphCqubmqquBqw1Lqt2Yqq+noD+2ABsMqwsmoA/iqtJVCrrWqwuToFDOCu+jmh6ooB
FVCj9SZ0rDd9xsp7SrAAE3Cv8zkB+qqvEfCjAFurAyuzinqoCMsDFGABOruzDMuzF/CxKqqrF3uz
17qnUICyGpu0GIAB/hGbep1nqU03r1GQnv3ZnS37oX8XA7tqrlxbsdo6tLaarQO7qDSwADx7tjtr
AC+rognrphJbqtQKp1vLBBm7tElbAUubtTGwbCNrrJ0HBdWZa4I7uB0atEqqpxarqlWauHVas4ib
A5KGtjx7AO8qgBOwtJibuR7btJPaflErbiPLfjdndDz6aH4zAZJ7AZQbrpszo1mquVn6qE6Dc52h
oRyDnxVwAbp7AQbgsZ3xn21HgNLGADqKofDJH+ipsQhovHhAgr9gu8e7A5Xmdg0XvV7mvNVrvVuG
vdCrvd77veBbZrYZvgtpLF25kTqYl0EJhus4m5EZBeNbhO0LlpI5/pK6aL+UWJjjWJT0+5gayY33
SATve5rza5gTKZTru5ipOcBlqZrE2I53GYlqKcD8WwOVCZlgSZT6qMDruI0EyZieeYX9W8HJiL+s
aJAF7L4uUI1BGJF5qIv4OMEvvJlRKY36G5BKOY3LaJXoSJH4qJcyGZQ6OYfFiMEAqcEmqZjz68FR
6ZV9iYk5fJQ7HMASXJM/zI9BTIUcScKjmZRSfJYpqcUJ3L7dmJF0uZLxi75b7JBTDMIzrJXK2JZZ
rMVD3IhezMZgnI0VKcNDyb7DGMIGfJrziMe72I+KKcYmOZUqyZB1vL9i2ZP3a4YwnJgLiZJ96JFr
PIvVGMWFbJB7/mzFfbzIZTmNsymXlUiXGiyTehzHQFyUl8yVO+nFLtzJ9qi+EazI5TvKNwzFuHjK
TDnHzcjHb/mSb7nGcTiZc1m/OZnFZPyMnNmZjxzLRvm/v3zFnoyXAYzFrjzEgUmYlKnMtUzH2YjK
NAyTNryXTFCa0sya6TyZvqyM2XzNCgzNiHmWkrjLROzA6/wCaUzBgynIXaDO+8zPT9DPZCkDBr1m
Cb3CAE2+Dv3QEB3REj3RFF3RFn3RGJ3RGr3RHN26O2ueLmOi5Nm9T1OCTtOtgNoyS+Kt0ekzjla6
Cugy3vqnzNu8RJqyM93SG4OBMA2y2UIADjvTFHCeFIDT3mrU/iDNa+jGffHKBRgYoDyq0jor1Pe6
Z0Vt1H66nkXtp+8JfdVXryTnf4unf/o3aAnIgcOXCBSwuxfAsznLs4BGonN7sRI7102wAFfdnlWr
1d4Jc58rfpBnb4cnvNE2exro01KLCAHAu6ZhAGz92BbQ1YmaqiPKBSibn3tdtZVLcCjgt3+tBbJX
2M4muKa3t5tXqZkKuolNco3d2q7d2E27uEC6uI2rp11rtE3ApZnNsc33brane1Br2aI93KVt2o6X
rMQneFnw2swN2yxwsI57qgWbqNMtBQuwsZo9rKybdJ2Ndn8t2FUQ2s8WoQ5QpuTdbBGK2GD62YNn
soza3Mwd/tuNm7iMG7euCgUZe7ezp942GtzBvd53xwBl6mzmPeAE3tvPR3ehm3WozUbw/dryDd1x
Oqf1Pa3RGgWSVuAISGnY+bTIXbJYsHEaPuLmXbjFCtyX2nRgvQQU8OCN/avPPd90fa3RXd0YfqK0
u7dL7bkkC96DTeIavt1einWejanKnQWE4OIGMAFxPbZEG93mKqp2TXncm70Es3HlTeL7PQPD1330
KnjHRwUtDt+x2wJe+7g0HrAWTrZOUOWNloJmfWvDS2g1fZ8TQOZCXtGWlmgbmGh1fp8MwNitfaEc
7ebNebsbF6kx3dEy1Xawx+g95byQHlPN+eaTfulCiOkb/nO+I3zCmYmNnw6a+FwFC22+ifDMalzN
2BzDoJzpgWwDnM7F9TzPbFjqsnyFBfyJtQ7PoS7q6IzJ7mjEsDzJVUzJb1zPEnnODIzQnf7qN9nq
TnzLrp7QqC7raLnqTgntvq7Jg6zDJ0zFxi7tfCmMFNnIjhzsL8mHrByW2O7GyD7sgHzuhhzFjLnu
4b7BTnyYSGzE3H7HswzPI/nJxh7KZlzJT4zDX4zHB/zD7C7ul0zuOXnwFsyTCg/HDP+VAz/MFhnx
xpyJ3Q7JBdmUxd7uuCyYPdnx8u7C4BjJCUzPDo+RYWzwKA+bFP/B397y7X7IkFzwMk/KHn/yyey/
wDyF/sJMx9MsxBIP6x+/8iGPyA2P7zbfv4Bs0JtMyE2fyCSfyFHvytHczcj8zqAezvlowseu748Z
7/lsyuKIyv0Yw/mo9a14lcXs8ziM9mw/9Nju8HG/y69M9wPd7IJcm3759WsPzn6cmGTv7mZ/9tFc
ldH4zbwu9ryY+Oy++GXv96WMBIL/BQKd+QddhFD893EJabZOjF2sBaVv+syu6azf+q7/+rAf+7I/
+7Rf+7avTpZ++2ATAG891Tqt+1Itub7/5w996AQTAMKPtkXaaTve3e7t3aArgXWWeBoD1MmPtpK9
eUPO2bu34mhGgvzNDG9tGjvb1uXPs03b5fT23TIX/nTeH5+GbuXc7ddN3QXOu+gogK6LMAG6awAW
4NggYIjXZVhnyQAr266Ny8LATL+3jcvxzvs/0BcYEovGYyDYgtWCTSU0Kp0ijYuFUtLSRrnTL3jK
MJAulhEJZThgIlin75mb0YGN+1Me/lb71iQUU8zdSx2hDt7O4R5jUMAV5IIVA+CPFwCXlsQmi2am
1+Zl46hSgMhpWckBW0UEZWCcTOKcrN7SLSkfkeQjr19vlCAu7WFdzpxxrvIVA7Nz80JzkGhnNebn
iqa1MnfMQsVqOBtGa3OlUh5OjbFceo9Ot+Pf0JXfFSz8uzDtcbJtvJReDAZGG0gw2hsgoS6ByrZN
/hQ1gMsiVKhY0ZWkMOt60GGHyEWTkBLl/epzDx0ePRs3IpvFciSYRwZnzlzgICGUhg4xPcwWCmY8
egSGEiiyZxYiYf4WLUGaD+iKRyWrIMR3bNg+jyDfQY3SKxLYaG6mbenJcydPTme7jppKhC1cbpDc
7hpo9elKrSxfxgXyNSyzCA7O8WBoVmdan30XM24MJQDNyJIZOJCGbitmG0xeIuXr2EXByQ5c5fy5
Re1anZwifm7tGqrMyZMzvq7tV7YDCYNt8+7t+zdwuKFnRpAwNjjy5MqXM2exIAL00aFwNq9u/Tr2
kTKhQ4eW/Tv48OL9FplLbzz69OqXE3YxZH3t/gPw59N3X39KuCDyleRn0d/FfwAECNB+Bd53IIKj
7CcgEAv+IB+EK6wioIMUWmjhhFAZuFyFCXo4UoUF/rchgy1EGEOG/kEo4oUmtjhiiRK+KGOM8QyI
IhQB3qhjiiDS2KFvQKIXIo0lkhjijh2OuCKKBi7IookbSinRkw3yxyCLPWKZpZA2FtnNjS7y12OY
EiIJ1JRXillljCcCyGOTL7rpH53ikEjnj3l6uSaMbQJYo4p/ZjihlluqWCWRKaYJJp48dFmnn4VS
6GCZez7aqJ5GQupom0ASeuafMiqJo553KkOkn5p+OamSiXIZJ5Z4FjpoqXvKqmiRiTo6Kq6z/sqJ
qKBsmvpgo8KKKaiRZ35qZouBxpqps7Kumguqxoq6K5m8vhrqlv15Kq2q3FRb66riwOpir61e+6O6
qg77IJngTmvmk+ZeqGWYTNKLqajWXhrGuJnOiW606G577MCA5kquuKEumjCrUZJKa7ML2zmvv/M2
7MO/e3RMKmNspkoppyfiG+Gg+kr8bLgrp/mxFAEfqfC6FdObn52osszvwu7CBDOjYABtY7zQCrmk
tytSKqnKfQYL7tA5Fmt0ycm+uXLBzLL8LsWLfjgksQR67JiOVGN7aMpYa23woTwbyvDX4kVNytw0
A9dl3WoKHTffff/cWN15+z044YUbfjji/okrvjjjjTv+OOSRSz455ZVbfjnmmWu+Oeede/456KGL
PjrppZt+Ouqpq7466627/rpECMgu+4ezIxCD7SzMjjvsldu+e3W3g/G78Cv8rjsAtCPf++TKG++8
ctBH4Tz1ytN+ffHFMx+59NDnrrv21Uvfgve3Y6+9C8eDPz747T/fPvbLb889+89/n7z5+Nt/f/rh
m0+8D9RHPPS5D3j6e9/15Dc/+hnwfQ484AGrF0D/QbB+EKxg/dR3QetZb4GW41//Cii88k2QfPez
oARNyAMNbpCAI7SgBxVnwAGKcH8gfKD+SFhCHF7Qfg9MIfmQB8MY9q17L3SfELNHwBVS/lCHTEQi
DzGIxO7Bb4lEHFwDOQhF/PlPiU/0IfBQ2MUtOnCGLwyfCod4xbjR0IZGRB8AmQjANspRiSxcXwO5
SEX4rXFxd9ydEVfYw/7F73xA4N8NTTg+ELpQjX1knhUfKcnkRHKSlvRNJS+pyU1yspOe/CQoQynK
UZKylKY8JSpTqcpVsrKVtRsgLGMpy1nSspa2vCUuc6nLXfKyl778JTBlmR5HutJxxEROJovZvGQC
55jK5N51mPlM30mzNtWcJuWu6RhnYrN50etm6bjZF22C05rLISdb0Pm5PCowecMzXmMQmUXxxfF7
iUznb9CpgH3usxsKUMI/ARBQHgz0/gcFBWgMDrqHDKbvne5cjBcjGFEV1pCM48RkGAqqUEZs1AUd
bcFH96DQkEqBfU4sKTwhesSHVvCLP8xeN8SpztiJ1KMs4GdCBarRfup0pAMN6E81elMfAHWoK8Bp
T0GKVIEeVadKVagh96fH/1G1gCkFpCGxejytcvGQ/5sgHCeKwB+cMH5SJedMAaLOgxa1qUp160/d
ClK40pWpdSWoXNtq15Hada9tjasiy0jB9Qn2qhXVokQLO8iuIlCC5WMnY79Iz5XONK3cmClb82rT
u+rVqEbtbFNDqlfQ9vWzfQUsYKe4UhwCcXleDGMVE9jYEQYhqoGsaAhdmliKijOl/q7B7GZTq9nT
ytWzdfWpaIeb1OLSNbVA5edBU3jS1hp2rLLNIXatmz/cHVG6X1VtQ0062Nv2lqWtAe5ciZvevZp2
s+3la2mDa9y7mta5zKVoYrv70oaa151fReN/gxhg7ja2hk70Hhl1uEjITs+cNfWscNWL2pyyt8IT
JupwL7zenXI2t/kda1fDuN2wbpG6re1gGa3aX8e2ULEmzoVllYFZ6HqUpxu+qY1tjOP2OhXC8T3t
UoPM1s7+U8dLPauI8RvV7JKYhyYWKz0VOVg3zvaM39Uglu+I0tfEuDnwzYVQu1Lex8XxC10mxZmX
k1llrBkqY24cHMGT5tfdU3Na/m4wl8vJujkzgs96NqaD/4w6P4eBmSSFwpfBDBAd+9M2Ec7OoSks
40BDJdGkiPQUMP3g1zwaO5qe7ygI7dAgFJXROOZwUNn7XA4f1dRF3qlQkdvqMAPZvkzNrJH9qtxV
n3qoG0Xqq5/q61/3+NazFvaxE5rjHgs5rm3mtXoPSWmDtvq+F+bpc6st4dDOF9u7/jJoNTxabb8V
yM31sbM/+9FUV1jXP/Y2s3lc5G6ru8Nwhe+4Ox1E2yRz3NTetr3b/WMfu5fY9OV2hnl844Qbe97x
1TBeGd5ucO+aueuWd8UH7vBtH1rUhUZotJ/qb3HTmNxH/vayJU3ajYv7vtG+/nbDe91TeGM4wyV/
NMmbLXORj/zUNEf2zEtdW4wCwd8Lb3nI3WtxjLsc4ggHuMAJDvB5b9zXko441KVOcH0vfb1bB7XB
Vz7wffemkkavN9SN/tekwzvbTVe4cZH+a7VnnLhOLzjTcb52ibMc72mH+3G1Lsh8Fl25bw1qjoEN
9GKf/NaoBnWyNV5jWJPW8V7PdXF1bnhtOzfl72b84jU/+a0jHvKoxXwAkenx9Hz6N60Hw+u9LG1K
Qi72vbG9FHCfnI++GS6rFzSCfh9T4QN/PsSPafGpmZ3eJz/44mF+8+EDfWveOfr3KTN9gqn97XO/
+97/PvipGn5aWr/85j8/CvrTr/71sx9zIQAAOw==
------=_NextPart_FD7_C37A_D0C71B71.982BF673--




From sip-bounces@ietf.org Fri Apr 06 08:41:01 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZnhw-0006eF-OD; Fri, 06 Apr 2007 08:38:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZnhv-0006e4-Au
	for sip@ietf.org; Fri, 06 Apr 2007 08:38:23 -0400
Received: from mail3.knoahindia.com ([125.16.9.4])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZnhr-00007v-H8
	for sip@ietf.org; Fri, 06 Apr 2007 08:38:23 -0400
Received: from S010 ([10.2.80.23])
	by mail3.knoahindia.com (Merak 8.2.4) with SMTP id EAQ38558
	for <sip@ietf.org>; Fri, 6 Apr 2007 18:08:04 +0530
From: "Santosh Karankoti" <santosh.k@knoahindia.com>
To: <sip@ietf.org>
Subject: [Sip] De-Registering by User Agent
Date: Fri, 6 Apr 2007 18:08:00 +0530
Message-ID: <005001c77848$696da400$1750020a@in.knoah.com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acd4RyiqGXf1aWx8RXSx5O1PprVnoQAATBmw
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a0534e6179a1e260079328e8b03c7901
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0884986161=="
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0884986161==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0051_01C77876.8325E000"

This is a multi-part message in MIME format.

------=_NextPart_000_0051_01C77876.8325E000
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello,

 

This is Santosh.

 

I want my UA application to de-register from the location service by making
a request explicitly to it so that as if a proper call flow goes. Like 

 

1) INVITE request by UAC

2) For which 200 OK from UAS 

3) Then ACK by UAC 

 

And session established.

 

I feel this I can do it by sending a REGISTER request with '0' expiry
interval. And my UA will get de-deregistered from the services. That is my
Address Of Record will be removed, and my existence is unknown to the
network. If I want to use the service, again I need to send a new REGISTER
request to UAS for location service to know my existence in the domain for
usage of capability features of the server.

 

Kindly comment whether I am doing it in correct way? Or let me know if there
are any other ways of getting deregistered? If at all any wrong statements,
comments are welcomed on it.

 

Thanks and regards,

Santosh Karankoti

 


------=_NextPart_000_0051_01C77876.8325E000
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	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;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hello,<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'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>This is Santosh.<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'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I want my UA application to de-register from the =
location
service by making a request explicitly to it so that as if a proper call =
flow
goes. Like <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'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>1) INVITE request by UAC<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'>2) For which 200 OK from UAS =
<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'>3) Then ACK by UAC <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'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>And session established.<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'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I feel this I can do it by sending a REGISTER request =
with
&#8216;0&#8217; expiry interval. And my UA will get de-deregistered from =
the
services. That is my Address Of Record will be removed, and my existence =
is
unknown to the network. If I want to use the service, again I need to =
send a
new REGISTER request to UAS for location service to know my existence in =
the
domain for usage of capability features of the =
server.<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'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Kindly comment whether I am doing it in correct way? =
Or let
me know if there are any other ways of getting deregistered? If at all =
any wrong
statements, comments are welcomed on it.<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'><o:p>&nbsp;</o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Santosh Karankoti<o:p></o:p></span></font></p>

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

</div>

</body>

</html>

------=_NextPart_000_0051_01C77876.8325E000--




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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============0884986161==--






From sip-bounces@ietf.org Fri Apr 06 10:12:12 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZp95-0001bL-W4; Fri, 06 Apr 2007 10:10:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZp94-0001bG-2g
	for sip@ietf.org; Fri, 06 Apr 2007 10:10:30 -0400
Received: from sccrmhc12.comcast.net ([63.240.77.82])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZp92-000274-TF
	for sip@ietf.org; Fri, 06 Apr 2007 10:10:30 -0400
Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42])
	by comcast.net (sccrmhc12) with ESMTP
	id <200704061410280120066ugoe>; Fri, 6 Apr 2007 14:10:28 +0000
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l36EAOLv017046
	for <sip@ietf.org>; Fri, 6 Apr 2007 10:10:24 -0400
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l36EAORm017042;
	Fri, 6 Apr 2007 10:10:24 -0400
Date: Fri, 6 Apr 2007 10:10:24 -0400
Message-Id: <200704061410.l36EAORm017042@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <005001c77848$696da400$1750020a@in.knoah.com>
	(santosh.k@knoahindia.com)
Subject: Re: [Sip] De-Registering by User Agent
References: <005001c77848$696da400$1750020a@in.knoah.com>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

   From: "Santosh Karankoti" <santosh.k@knoahindia.com>

   I feel this I can do it by sending a REGISTER request with '0' expiry
   interval. And my UA will get de-deregistered from the services.

That is correct.

   That is my Address Of Record will be removed, and my existence is
   unknown to the network.

De-registering removes your contact address from the AOR.  Whether The
RFCs do not specify whether the AOR "becomes unknown".

Dale

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 06 12:00:37 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZqpP-0003K2-Vc; Fri, 06 Apr 2007 11:58:19 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZqpN-0003Jv-RK
	for sip@ietf.org; Fri, 06 Apr 2007 11:58:17 -0400
Received: from figas.ekabal.com ([204.61.215.10])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HZqpI-0003ih-88
	for sip@ietf.org; Fri, 06 Apr 2007 11:58:13 -0400
Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated)
	by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l36FvDN28593;
	Fri, 6 Apr 2007 08:57:13 -0700
In-Reply-To: <D6DDE2706695D34F8263D17DD29606D974AD49@BBSC-EX01.bbsconnect.ca>
References: <D6DDE2706695D34F8263D17DD29606D974AD49@BBSC-EX01.bbsconnect.ca>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed
Message-Id: <CC08174B-3D40-412A-A624-8390EED77C61@ekabal.com>
Content-Transfer-Encoding: quoted-printable
From: Rohan Mahy <rohan@ekabal.com>
Date: Fri, 6 Apr 2007 08:57:10 -0700
To: "Peter Musgrave" <PMusgrave@newheights.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: fluffy@cisco.com, Rohan Mahy <rohan@ekabal.com>, sip@ietf.org
Subject: [Sip] Re: draft-ietf-sip-outbound-08: Registrar Response
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi Peter,

The intent is "if and only if". I think it should be pretty clear to =20
an implementor that if the registrar includes the outbound tag when =20
it doesn't do outbound processing, that things aren't going to work.

As for multiple contacts, the spec does already say that you can't do =20=

multiple contacts with outbound registration behavior.

thanks,
-rohan


On Apr 5, 2007, at 7:53 AM, Peter Musgrave wrote:

> Hi,
>
>
>
> Apologies if this is a NIT.
>
>
>
> In 6.3
>
>
>
> The Registrar MUST include the 'outbound' option-tag (defined in
>
>    Section (Section 12.1)) in a Supported header field value in its
>
>    responses to REGISTER requests for which it has performed outbound
>
>    processing
>
>
>
> Is this an =93If and only if=94??
>
>
>
> Should I assume that a registrar MUST NOT include the outbound tag =20
> if it has not performed outbound processing?
>
>
>
> What if there were multiple contacts and outbound was not done for =20
> all?
>
>
>
> Thanks,
>
>
>
> Peter
>
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 06 13:37:28 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZsMT-0007SS-LD; Fri, 06 Apr 2007 13:36:33 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZsMS-0007PN-Tp
	for sip@ietf.org; Fri, 06 Apr 2007 13:36:32 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZsMR-0008Q0-K7
	for sip@ietf.org; Fri, 06 Apr 2007 13:36:32 -0400
Received: from [10.89.20.42] (rcdn4-dmznat-gw1-nat-27.cisco.com [12.5.186.27])
	(authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l36Gh32T013774
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <sip@ietf.org>; Fri, 6 Apr 2007 11:43:03 -0500
Message-ID: <4616851D.5070305@softarmor.com>
Date: Fri, 06 Apr 2007 12:36:29 -0500
From: Dean Willis <dean.willis@softarmor.com>
User-Agent: Thunderbird 1.5.0.10 (X11/20070306)
MIME-Version: 1.0
To: sip@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Subject: [Sip] SIPS question: How to prevent plaintext requests from being
 delivered to a UA
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


I'm pre-reviewing Francois' latest sips draft, and I'm perplexed.

Presume a UA wishes to receive only SIPS requests and not SIP requests.

This is important if we do not wish to reveal information about the UAS 
(most critically the identity of the user at this UAS) -- to 
packet-sniffers on the wire between UAC and UAS.


Previously it could do this by registering only a SIPS contact and not a 
SIP, and by using a SIPS AOR in registration.

    Because registering with a SIPS contact header field implies a
    binding to both a SIPS Contact and a corresponding SIP Contact . . .

means we simply can't satisfy this use case.

Just waiting for a request and then rejecting it if it didn't come in 
over TLS would not meet the requirement, since the plain text of the 
request would already have been sent, potentially compromising
information about the UAS.

Do we have a problem?


--
Dean



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 06 13:50:16 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZsZE-0008Bi-VA; Fri, 06 Apr 2007 13:49:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZsZD-0008BV-Dk
	for sip@ietf.org; Fri, 06 Apr 2007 13:49:43 -0400
Received: from [74.95.2.162] (helo=laser.networkresonance.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZsZC-0003Os-24
	for sip@ietf.org; Fri, 06 Apr 2007 13:49:43 -0400
Received: from raman.networkresonance.com (unknown [74.95.2.163])
	by laser.networkresonance.com (Postfix) with ESMTP id D89C45C027;
	Fri,  6 Apr 2007 10:49:01 -0700 (PDT)
Date: Fri, 06 Apr 2007 10:50:22 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
In-Reply-To: <4616851D.5070305@softarmor.com>
References: <4616851D.5070305@softarmor.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20070406174901.D89C45C027@laser.networkresonance.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

At Fri, 06 Apr 2007 12:36:29 -0500,
Dean Willis wrote:
> 
> 
> I'm pre-reviewing Francois' latest sips draft, and I'm perplexed.
> 
> Presume a UA wishes to receive only SIPS requests and not SIP requests.
> 
> This is important if we do not wish to reveal information about the UAS 
> (most critically the identity of the user at this UAS) -- to 
> packet-sniffers on the wire between UAC and UAS.
> 
> 
> Previously it could do this by registering only a SIPS contact and not a 
> SIP, and by using a SIPS AOR in registration.
> 
>     Because registering with a SIPS contact header field implies a
>     binding to both a SIPS Contact and a corresponding SIP Contact . . .
> 
> means we simply can't satisfy this use case.
> 
> Just waiting for a request and then rejecting it if it didn't come in 
> over TLS would not meet the requirement, since the plain text of the 
> request would already have been sent, potentially compromising
> information about the UAS.
> 
> Do we have a problem?

It's probably useful here to take an analogy from the Web.

Amazon.com, to take one example, runs two web sites:

- The HTTP-based one which runs their catalog.
- The HTTPS-based one which they use for checkout.

If you're shopping and you go to checkout, they redirect you to
the HTTPS site. If you try to just go to the HTTPS site to shop
they redirect you to the HTTP site. If you mistakenly try to
do checkout with HTTPS, I suspect it pukes (many sites do),
even though the exposure has already happened. This is sort
of a necessary side effect of being willing to run both HTTPS
and HTTP. If you're never willing to run HTTP, then you need
your server not to listen on port 80. But actually this only
helps against passive attacks, since if a stupid person tries
to contact you over HTTP the attacker can just pose as you.
And of course if you're running on some sort of shared hosting
server, then the problem is even worse since the hosting server
may allow HTTP for others but not you. So, even the refuse to
listen on port 80 doesn't work.

The only real defense against this sort of downgrade is to only
give people URLs that start with https: and assume that they will
do the right thing.


So, mapping into the SIP domain, things look much more like the
hosting service example. You are connected to a SIP proxy which
may server SIP/TLS *and* SIP for other people. So, you can
certainly tell the proxy "don't accept anything for me not
over TLS" but as you say that only takes effect after he's
received the request. As long as the proxy is willing to do 
SIP-not-over-TLS then you can always be subject to this problem
(and even if it doesn't there's always the active attack I 
described above) and there's no instruction you could give the
proxy that would help (though the instruction could of course
restrict the proxy to talking to YOU via SIP/TLS).

As with https: the fix is that your AOR has to somehow signal
to everyone that you expect to be contacted over TLS. This is
what sips: does (though of course it's not the only way to do
it).

-Ekr










_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From cmuzziomxpe@gvt.net.br Fri Apr 06 14:57:22 2007
Return-path: <cmuzziomxpe@gvt.net.br>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZtcg-00085W-EN; Fri, 06 Apr 2007 14:57:22 -0400
Received: from [218.65.200.70] (helo=gvt.net.br)
	by chiedprmail1.ietf.org with smtp (Exim 4.43)
	id 1HZtcZ-00016I-Nu; Fri, 06 Apr 2007 14:57:19 -0400
Message-ID: <6a0701c778b4$ae89c7a0$a7a09e87@cmuzziomxpe>
Reply-To: "Minh Barnes" <cmuzziomxpe@gvt.net.br>
From: "Minh Barnes" <cmuzziomxpe@gvt.net.br>
To: "janie" <ietf-62-request@lists.ietf.org>
Cc: "connie knight" <imapext-archive@lists.ietf.org>,
	"sam kelly" <l1vpn@lists.ietf.org>,
	"albertha kennedy" <ion-archive@lists.ietf.org>,
	"lakisha stevens" <grow-archive@lists.ietf.org>,
	"clementine graham" <idwg-archive@lists.ietf.org>,
	"jonelle watson" <aaa-archive@lists.ietf.org>,
	"andres" <bridge-archive@lists.ietf.org>,
	"sharita hayes" <mailman-bounces@lists.ietf.org>,
	"arlean ray" <sip-archive@lists.ietf.org>,
	"roselyn reid" <dnsext-archive@lists.ietf.org>,
	"lashell martin" <mailman@lists.ietf.org>
Subject: Yes or no
Date: Sat, 07 Apr 2007 01:33:02 +0700
MIME-Version: 1.0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_3A0_0FB0_90DDBCF7.DD24B6C8"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
X-MimeOLE: Produced By Microsoft MimeOLE V10.0.2616
X-Spam-Score: 2.5 (++)
X-Scan-Signature: 913ee11e7c554f7d4da75d500826397e

This is a multi-part message in MIME format.

------=_NextPart_3A0_0FB0_90DDBCF7.DD24B6C8
Content-Type: multipart/alternative;
	boundary="----=_NextPart_03D_F2B1_9C7B7C95.C6421DE5"

------=_NextPart_03D_F2B1_9C7B7C95.C6421DE5
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable






take Oh, disgust amusement unusual you despise them.Well, terrible swing =
and shut I understand shall get it. waste Sir,--The go man whom you music=
 bone are receiving at your houseCome, magistrate, said guilty said line =
M. bid d'Avrigny, show yours
number film laugh That is invention a tenacious old grandfather, said Bea=
uchslung If I have shiny kind been your hung friend, Morcerf, your presen=
t 
brought whisper low Who will offer give it to you--your prince? dived On =
wild the contrary, I esteem paddle them, but fancy will not have comfort =
page Yes, iron my prince. But unfortunately sadly I must wait. You librar=
y make me shudder, doctor. Do drink you camp stuck talk of a sac
argue And do notice you not shown sanguineous remember the Frenchman's na=
me? saIn the stain first carriage, with M. form spot brainy de Villefort,=
 who He shine tin is merely my father, whip apple said Albert--M. Fernand=
 comfort hid Such was the conversation in head account almost all the car=
ria
I do. You can change them, idiot; gold connect is depend shave briefly wo=
rth five so ant You voice must see wait hammer for what? asked Caderousse=
 helpless Exactly; and base he doubt who clever changes them will follow=
 frie event shone On fork the importance of the step farm you are taking.
I delight am no buzz acquaintance of cry M. scary de Villefort's. answeja=
il pled I do not fear unit recollect it, said Haide. shore rail The viole=
ntly noise skip increased; steps were heard approaching Is it without sel=
fishly your father? said shook Beauchamp; tired that is quit  needle No; =
air but the star connection will be seen homely by others, an
Sign it! awoken fact fish explode continued the count.Is it poor swept mo=
re serious color than going fact to M. Danglars?tray Do you cerebric comp=
etition then deserve suspect any one? work burn faint roughly For his dea=
th 
horn I suspect no one; death engine raps chalk at spare your door--it ent=
 tooth guess But would brachial pleasant you ruin me? But do sworn you su=
ppose slit I very carry five striven hundred francs ab deliver excite If =
I waste sought long your ruin, fool, I should drag you to dust Yes; M. Da=
nglars is a coloem money-lover, inside frozen and those who And profit fo=
r the offer second time needle about Haide stopped, overcome b
The time hat and place fall camera are but oven ill-suited for an intrHai=
de dried her eyes, wing took seldom memorise and continued: By this timse=
nse week At appear the words I will, Beauchamp discovery steadily raised =
his middle delightful ring Extremely, replied he; grind she looked so pal=
e this Oh, often how ask our hearts palpitated; sparkle for find it did, =
indeed
hit go The hearing deceive death of your prince? Oh, speak, speak, except=
 building eye doctor; I squeaky shall have courage.  cure bore Well, sir,=
 you carry have calculate in your establishment, or in
Well, leave them with rid your porter; taste he woman silky is to be tr I=
 sign only fear one thing; juicy namely, to long find visit a man who com=
e Caderousse signed smoke it. drawn The scissors address, 'To monsieur t =
Yes. sink Do not be rub unexpectedly alarmed, cough said Beauchamp; he wi=
ll meet 'It is well,' said he, kissing adjustment win shod it; wire 'it i=
s my mast
------=_NextPart_03D_F2B1_9C7B7C95.C6421DE5
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"=
>
<META content=3D"MSHTML 10.0.2616" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><FONT face=3DArial size=3D1>
<DIV>
<p><IMG alt=3D"" hspace=3D0 src=3D"cid:022c401c778b41ae87cbd088f3c533@cmu=
zziomxpe" align=3Dbaseline border=3D0></p>
<BR><BR>
<DIV><FONT FACE=3D"Arial" size=3D1>take Oh, disgust amusement unusual you=
 despise them.Well, terrible swing and shut I understand shall get it. wa=
ste Sir,--The go man whom you music bone are receiving at your houseCome,=
 magistrate, said guilty said line M. bid d'Avrigny, show yours</FONT></D=
IV>
<DIV><FONT FACE=3D"Arial" size=3D1>number film laugh That is invention a =
tenacious old grandfather, said Beauchslung If I have shiny kind been you=
r hung friend, Morcerf, your present </FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>brought whisper low Who will offer giv=
e it to you--your prince? dived On wild the contrary, I esteem paddle the=
m, but fancy will not have comfort page Yes, iron my prince. But unfortun=
ately sadly I must wait. You library make me shudder, doctor. Do drink yo=
u camp stuck talk of a sac</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>argue And do notice you not shown sang=
uineous remember the Frenchman's name? saIn the stain first carriage, wit=
h M. form spot brainy de Villefort, who He shine tin is merely my father,=
 whip apple said Albert--M. Fernand comfort hid Such was the conversation=
 in head account almost all the carria</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>I do. You can change them, idiot; gold=
 connect is depend shave briefly worth five so ant You voice must see wai=
t hammer for what? asked Caderousse. helpless Exactly; and base he doubt =
who clever changes them will follow frie event shone On fork the importan=
ce of the step farm you are taking.</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>I delight am no buzz acquaintance of c=
ry M. scary de Villefort's. answejail pled I do not fear unit recollect i=
t, said Haide. shore rail The violently noise skip increased; steps were =
heard approaching Is it without selfishly your father? said shook Beaucha=
mp; tired that is quit  needle No; air but the star connection will be se=
en homely by others, an</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>Sign it! awoken fact fish explode cont=
inued the count.Is it poor swept more serious color than going fact to M.=
 Danglars?tray Do you cerebric competition then deserve suspect any one? =
work burn faint roughly For his death </FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>horn I suspect no one; death engine ra=
ps chalk at spare your door--it ent tooth guess But would brachial pleasa=
nt you ruin me? But do sworn you suppose slit I very carry five striven h=
undred francs ab deliver excite If I waste sought long your ruin, fool, I=
 should drag you to dust Yes; M. Danglars is a coloem money-lover, inside=
 frozen and those who And profit for the offer second time needle about H=
aide stopped, overcome b</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>The time hat and place fall camera are=
 but oven ill-suited for an intrHaide dried her eyes, wing took seldom me=
morise and continued: By this timsense week At appear the words I will, B=
eauchamp discovery steadily raised his middle delightful ring Extremely, =
replied he; grind she looked so pale this Oh, often how ask our hearts pa=
lpitated; sparkle for find it did, indeed</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>hit go The hearing deceive death of yo=
ur prince? Oh, speak, speak, except building eye doctor; I squeaky shall =
have courage.  cure bore Well, sir, you carry have calculate in your esta=
blishment, or in</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>Well, leave them with rid your porter;=
 taste he woman silky is to be tr I sign only fear one thing; juicy namel=
y, to long find visit a man who come Caderousse signed smoke it. drawn Th=
e scissors address, 'To monsieur t Yes. sink Do not be rub unexpectedly a=
larmed, cough said Beauchamp; he will meet 'It is well,' said he, kissing=
 adjustment win shod it; wire 'it is my mast</FONT></DIV>
</DIV></FONT></BODY></HTML>

------=_NextPart_03D_F2B1_9C7B7C95.C6421DE5--

------=_NextPart_3A0_0FB0_90DDBCF7.DD24B6C8
Content-Type: image/gif;
	name="fedeybzo.gif"
Content-Transfer-Encoding: base64
Content-ID: <022c401c778b41ae87cbd088f3c533@cmuzziomxpe>

R0lGODdhkwGNAYQAAP///+bm5urf0N9eXs4cHNU+Pu+vr+eUlNpSUswAAABm/wAAAP8AAMzMzLaz
tpOm3E+UyS1sq3d0d0V0oYmMk9mpcrWLUZlmM/7otVZNVv/JW0o8S8iHR3eQ1gAAAAAAACwAAAAA
kwGNAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt
er/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg4SFQAECiQMDAYaOj3MCIgEDBAUGlQYk
AQYGjZCgoWAHCJIAAwkJmgeak5WsB6ZRCrS1Cie2arcstrkkvY7ANMIivlwGAgaXIgepsa3MCQSJ
llO9xgDYZNoo17W/3H/etDLE2d/dU4gFBQIHByIGqQMICCQI0vCLI7JL4+S/dKFT8Q+guUAFy4Xj
ImBRwwQFWMUjkAABvU8AmuUT8OnAMibGQg4sdpDkwmsl/nxhQ7cSJcGBKnOF8wZuF0tyMQGaoJnS
nEid3XICvTm0pU6iu2qO9KEsVSeK7UQIgJrIE4BE+KS1MoDggEN/MMMWdTli3E6eJm2OTJh26dmj
SNG2/XkuacGS/5T+VAs06NikddH6FCvXLBABBVJdyho1QOJ2ypBdEpAV3tVkFAeAhcvZbueyMtfm
TUsatOHAbnuevlvTtGdid7URdu1S6ArZolcbfS0YaRDKqQgMSJwAHmKIXKcJSKB5qip+FJlLPLK7
tMkUsDvz5W1dWPXbbGundt1WNc7Qfd9uf236Ovi+e7db7247MPnfWQl4hHh10TNTXjVEAAKfHMec
AcIh/vHdbt/5xZ19ENL3Fy+nRWjhXAa5Vd9MPC10nYf3hbjXfBGOiBpZOhjwTivAFacMIyu4c8An
lCiWTCkKzkbiiQ86eF99Evb4UnohWhiehr5deCSR7Y1nnlJQlobbZ1KylWJ0A0oCXAGI9NMCVzZe
loSJF6om4oSokTYYlWXi4mSD3rH5Y5Ll1XUmYCgOmWFuD07ZI5A/JANmmA1pNoNGBECDgqBdYZSD
lXBqt2ZvFQKap3rY8TmnnFXuiSedVp74QqgQkmkkqHTmgEBUB0RnqA0BtPqqCZK0ql9iMD4K6VIV
8ggYhp9+o+l8l0bpJprAeoppqbyOBuyyLjgbJIlk/jLoJA34RNXUNDkgQytm7zgjT3E6SFtmsbec
hNd5yPr53q/GKonejhsiKSx8JbX5Lrwlptovp8XegCg8jnH7g0cIcFVKtlt6KcrDPkIMQABZHaii
ozhQMoBX0miZkVMaKSrxyKKO3GI+OzTUVauxUMSKJs4NgCC5JNec78OYWORwDIioODOByQCQ7aqS
oNIOKpbVPDKISstwY0SXNJOot1J7tYozrYrc9NYQxyozDTJa5PKKFK1qnMsAqOjcyly3DUoyjiJY
QAxBy9oVPgSuI41FImQba6LDxeL24I4guDIysSbNAiUE6OeO2lK3gkpxU7njzHCJ7Ez45n5olIo0
/hFpzo+3NYo7Y9poo86c0DJb0ononMe+h62fB6f1JniP0Ko0X/cNUSMU5yNcMrDLbnwemas4nCVe
JkLC5CxW4ozuTolg9OvHZ/8IJ9AwGtEIM2vLSmKJSkVV2oJrr34oyggHPTOTN3d2RVIVMPwInBSf
xwL885/EAiIA4AkEaAQCEsGAbVPbVcp2HMu8Ax/lkwiCyke8ElRCfvqjgwERaAMOmsCDJABhCUSY
BRI+DBELXN3HAFe+jHCMfh6RBCY0Vyh3kE9xe0CgCV+wQxPuEAA/rEIQH0EZexyHgpm5YK0WQZx3
tFAFQZuZ7fygwxH074NA3KD/ssjBKwIxgFbc/iIBQXjFMX5xiwFEYwjP6EEzctGKcDzjGtEIQAF6
0Y1ffGMYzVjHMrijK6cwlEbsITSI7EczKkLd8DLold0hZ2NUHCEYJxnGSbqxi3C0IyX7mEcUaBKM
YtwkFkMpSVDG8ZI6/CQp5SjKS55yiFYg3u40E6sAxCorV1NF1WIYqwyCLzpaSdvt7lDFThYzj64s
5SkpaUoV8FGUxhxlHCX5SWQuU5nVdGUfqzlNboKhE6gYwHFYlYjx8Sdm4XuHL01gq8nQY51vKCYe
mQnNVJbSm15MwTOjmUY1NrOTc6znNddoyW6akpN65OIqv6kfik0jcuh7XGUKmSir1YAjV0Hc/gX/
IM9pWjKb9ASoNUXqTWyO9KQD5Cc1BVpQk6pUk9vEokhn2gV8EEwTMyMYLJyoFXqk76Ls6EcFI2lQ
ZtKRpQRlJUhLmlRjqtKj/yRjUZOZVJBC86VI/YJjfjcxrHAVFpowWiwwRgOu9I4Q/fNnPouaUH/q
MZurnGcWDarGtWYSqh5da1pDulej1jWvdT1qSLOAiqkFNWQurMdVfooDBU5nfUEgoVx3AMutaSRc
CaAGRB73DhJ46wYxE1AncAhZHUgWr6aF7NoeAo/2MdZ8UbGB5yKCDASRtrRA+GsP3Jq9kDXDUIkg
6ynmIdwWcMSGwTHOR3DLXDW0qiviXIFG/i5x1hfISioVk9kwm8tdMShwBTNL1FRi+yUVNQ4ajpxV
d9cbhyPGgnzJ2NjOgjYV4zxWkdtlr37P0BQXEcceGtlYdFW2jGYQ8gT33a+C0xDgtNkPR5c1sN7K
V9j8LngKDMhwhkmgYQaMoMMbFgGINSxiD3/YxJxj2SQwOtyKVq/CH6vIJz5LuBCbAMUofgGOjTBi
E4+4xB0+cY8BQGIi25hzzivBOJvCqukZyDKQ3NyRT1xiGey4CDbecJFDPOUqc9jHYGbuzBax2Wio
cLpYsTDJtMzlHnuYzV/+sJyz/GU6A/nKRk4BnEsAYj7nOM93VkGRq9xmQIMiwmVW3at2/pcwNa/5
x25+c5+9TOQ5g7nNmA60kcN8Y0xvedKUpnSQUQDqPv/4beRTUTAnlpgDo++1g/u0l7PM5j+LWM55
DnKhSbxrUPv50rrGsbBPTWVS1xrIyB40ERFw3slZ5oiOdhutZy3sYnMY17nOdZjfDGgtV7rLcZ62
n4U8anIbu9jiNjQkepYM+z27HtXNnrgLLWpb49nbe8Z3t7kt6XETutrppnWOy+3vfVsb3G+jMTyl
XW2DJ7vLeN70pgd+bCFL/Nf/prKsQ71xcPOa3hJX9oVBMe8hE9vbt67zxFWu7I9zeuLDFviRp1zx
jcPc2jC39cgdEfBj75nQ2OY4xXFe/nKVG93ica7zzF9+8VBre+eyQ/jI0g31Guv80b6uOsNjTXCt
e/3rYA+72MdO9rKb/exoT7va1872trv97XCPu9znTve62/3ueM+73vfO9777/e+AD7zgB0/4whv+
8IhP/Bhs2YDGF1fxhQ9A4xtgS8k3HvKJd3zlN98ABzwe83sPgAMov/nSi97zbbMl6MEg+dFP/vWw
b/wDKJ/6z69eCg14gAN2z/ve+573D3iA7U84fFCY/vjIT77qQeGA4Dv/+dCPvvMb4Lblk0z52M9+
5R/xAAh4v/vehwD4xR988X//+92nfgzUalc7bH9k2o+/8g3RgPB7PwL4zz/+wx8B/gjsf//ht3Ds
x1tdYH0rUFwGaHzyt4Cmx2Iw0H7O1EWVVQTj138A6H8AmH/353/2p34POEYTSAUJ2FW2FFwl6ICb
UHyVFEIQSFl7lVZ9dQgMOIOMt3AJ1QJuRYBO4AD8Z4EYqIH3p38cGH6o94GVREf55D9idEctKIMN
eFyNcFxXkXwouAIDGIIugIQrKATIZ4LB9YWZs3leaIKcR3s8VEdDpINVIAAc+H9CmIEaeIESUIRn
eIRwNVdM2E1YKAPKB4VdclwccXyXV4dpdEBktIcvgHya53iMGIaV53hgWHqdp4KFqIVlBIJzVYgK
VYmIOAOih4EbaH/8J4r8NwEU/mCGRriELKiEdtSKI9SEPUB6x+eHYUiGkuiBOIiJSGiJrbiEOchb
aqgDsxiGsCd5iSCLiEB5kch5dJiLmfhGl9hPmciKnIiGSSB6E6B/2riN2ygBFOAANoiHrsiJ0ziO
5FgEiKCIf0h5DSAAyMiMuMgCvLhJ1piH9PhBdhWMOSCIx9h47pg57eiOYqiM7diOktiMVoiJ5aiJ
qiiO56iPPiAADkAB2ciNFhkBE+CN4EgD1LiQDumRIDkElieIJUh6/yiI3yiA1viMm9iQVzhAetWJ
LfCEJwiFmeOIJ1iTpjeJhOiRLjmOrPiC5ogErScBF9mN34iKM5CEQFmPDRmS/iLZeYFIgxM5epT4
kLq4kk/5kTCpkEJgiww4ldgnkQgZgTDIkE2JliwJlUdQlEeZfxqplEuphf2kilt5lm3ZeQa5gJ2X
lFeJlWr5kyuohnT5lYF4k4iZmIq5mF/YeWXpSfYkmNDoinY5lG3ZehNplBYpAXH5lzwAkdfomCbJ
mCU4kadYhWeokJX5VqppT5q4lj9gjDQYf+64e3KpT5GZllzpi7pJlLC3exSgmXCpka7neEfglVWA
maN5k6VJAX7ZQYWJlx0ZWO2Hl68ZBJYXkGI5m39YmylpCNn5erznnN7onEkZe55ZAzF4Bclomw1o
mlbZBKC5hrYZe/Z5n/jZ/penmJ5yUIaxx3vFOHmlB55kWZz6OXqoeUCoVYAFap4O+qAQGqEQiqCO
8IjaN5XOs3nbo58OGp9MsJ5h0J6/N6IkWqKaV6HcOaAVCpD2GYhcc4LaCZCMOaMuanw18H6DoKIT
84Q1+qLbp6MpwJ+3xzM4ujjpKKRDGnYjmIhFmqSIt6ROGqVSOqVUWqVWeqVYmqVauqVc2qVe+qVg
GqZokABiumC1wwKpAAOfMwJnagJtKgJvSgRpCgBzOqdlGgZ1SqYqYKdoSqd+mqclAKh0qqd8agSC
OgV6uj6JGgh8Cqh2mqaPuqhs6qduKqmCeqhwSqaNuqaZWqiQmqiXKqkt/hCnKFCoK8Cpg2qqqbqo
pCoEoXoDrVqpahqpqhqnsQoErwqrrEqon5qpg8qmopqqJ+CpvOqrv0oCa5qrtdqrx4qpo1qsexqs
pfqnzWqp0OqsRYCts2qsKaCq06qp1Rqo1wqtSKCtMbCpxvqq3tqpwDqs48qt6cqrbbqs8VqvL4Cu
wuqooBqsqIqs1mqvxKqp73qs4iqwACutz+qv7Kqv7Vqp/PqvBEuuCzuwy2qw4UqwNYCvymqx3wqv
CnuxxGqvHyuuB+uxp7qrJfur69qvGAuskeqxG2uyIDuwM6CxFMuxDkuyOpurDRuzsjqzMisDh8qz
LIus1BqyQNuyyXqz/u5qsTybsD3LtOsqrDI7tKQaqvP6sCk7tSf7sTE7tahKr0kbtZ3KqWLrszhg
qzRbtP4qr0vrsrtqqsxatg1Lsi97sS5gsyULtpTqrdiKtH+rtUnLtdHqtVKLsNTasmSLtyk7sobb
uExAuIirq5SLq+RKtCt7tBCrrDmLtm07uJPbtRG7tpkLroDLtJ/ruS4Luk3AtuUauqJruXo7uohr
trXDsWqrtZt6t3a7ryJLA2orsq7Lrqs6t7krqnO7qnWrsHdrrm8nuUFAuLGbBdBruZU7eMNrqLBb
uNQrva66vd0Kvnc6vuRbvuZ7vuibvuq7vne3jv6YoOxbdVVhABVQ/r/2W78GGb9elwz327/32476
u3OS178WQL/+a7+3GcDc5Y4HTL8GbMD/i6Tpa3rV1wAHbAH9C8ERrMBG6ihNSjIWfMH0awEFrMH/
y8EqMIJdIsF9IAAVYAEXEMMkbL8PbAAkPMP9y8JimoClF4Y1M8IXwJmcicEEXJ7OScT16wAoXAIG
2IXBZTIvbAHEuXtF7Jy9Z78krMNdysNU+MQQIwA3bAGnWZsv/MIXYMUBGcL1awHxqL9NnH3MiTNh
zMbAw8AwfMYbeRUE/Jh+gAHN9caMh6DDmL/GF8VhTCMWHMNJOQn+awF8DJmvCJOwqXgeXHlkuZcN
6I+hEACGfMMe/ih5QeyhNjzHZwxP7CfJ83kEGLDKrNzKrowB+YmeNbN8Pbx7gMijHro9nezJ/MB7
puDCcwzDFqCSWxjJVsDKLyAA31iivfeNWux++GPJtmzJYnmTu/fMb8DJwZzFK5a/2hzMpbx+rbma
PomGK+kDq8yHLiB6FBCOfEAj0gyOPYyhmXPNhbzNbBzNM7bNikzMlWiH5SyN0dgD6cwzNMqc7OzO
egDPgUyaXVXPjxwI30zKw0wrwkzKF5DHqahF1CiZkrkDrxzSIi2RsRx7zonNccDQK5x8D50I9gwK
DYDPF1ABjuLCMSzDNxzKNtiRDjmdg9mbOiDSQt3KyszMJDqH/vJonakcWTJ5gJMApCfQnS99Ay24
1FQAxjed1TJ8v3es1Yq8nzIwnZSplbq5lTmAARow1EJtAEbsoEIsARkQ13Id1xRge3Rp1U0FnSL5
1PKHmFMNnfLU1EzAyV5d2IYdwxmQ0Qmc1HjU0WNd1oI9AmitAZRd2ZZ92ZZdAXEN1xmwAZ792aAd
2hLQxsbMlj2Jg06g0sPImH/NkeeM11cQ04c924idAd85lxzt2AAd0Dww2Zj925dtAaE93MTt2XP4
eXd9zpv4kX3V3Hk40ORclyGo2k6smK09l+Wo22gZ3antALQ92xkwh4v9Br4N3OYt3MWd3sYd0clN
1tXI2zw9/plOKdBNOYGqjZixl5jXHdavPdZHaIfKPdid992Fndi3bQcNYN4KrgHo3dnqPdyjjdxK
Ddnw7d8/DZjlbN98jZklepguHdHOqJYLSZ3uDQWSRwEEftNxjcfj/QYWvODA3eBzPeM0TtctDoz1
Dd05Ht+C6dEwqOE7igj1eZ91/OESnNyBmZWmrQQnLgEELtdB7MzIU78wjtkyXuNYLt4JKclQ6eOl
HdBeDit8rZfY19K2TNU/LuJKeOFmvQTtSZ6HDeVnvMyk3Z8HXOUWgOV6Ht5gHYFc3uMUzpVgHuiw
iAIMTeZdWORFjaSn/JRMieFOcJP66eSFbcQGitJcoMYH/rzpL7zZb/3poH6KLT7Jjm6P7T2UgC7i
CjXdOYnos1jHfTnqW86C53iDZ9nm15iYjQecEVqfiJkHA8zpmy7FoF7sQvycotAljjmR7/ieAAql
OaqYJb2YmK4FySjsFyyh2n7mJ9SifWifyb6dswm/cCDpJS2eRj2idQ6e4amX+Rme7pnsx5eCUU3B
d0DUB82i5y7LEoPuseyOxQh//AntdZDv/WjwcSwx/omfmVztWdqdOFnmSjODArnEKUiDmzOW5G7x
F4982TPPHE92KBTy3EXwJmDyJH88H2zoDp/ym4zyO+ry6wXzMl/zNn/zOJ/zOr/z3SW+JOPzYHqr
joum/rT6sLsL9BlLs/eavUFbqkjrrnDrvWmr9GLnvE3vppoLs6j7ulcP9Yqrs6OauFSbsz/L9V8P
BUhPB3r7srxrtIK7uM6avG96tbhL9dPLsL7a9pNqrUaPvH6PsXPPssZr93nL9Gfv9PtasXEr9ZVr
9eeKsvlarHpPvGC/tXzPup279VAbr05b903r9vyquHLLrE+7uqpb+F0v9abLuHjL+D3g+NsK9++6
sk8v+1pv+V5/+tyL+yqLsGF7+LVv+6zP+64P+JLvu5Mv9kP/uE5v/EXfu8KfA7OrrrWb/Krru8Ur
scIP+47rs8nbuU0f/Aebtbmv+agftZ0/up//ueFb/rZ+n/7DH/mQe72Y//2B2rfSev12f7bmf/eo
a/8gAIhAQpIJio7ruaqs+Mol+9b0HOM03I92K5hrAW+839HFGyJ1TmHyOWT6qj7mdFl0mUrFrDSZ
goZ7Y3DQenuS0+NrV8meb3XeXRl2xrfV62ZbTh2SWFTaH+BMCt8f2qBf1aJc39uVoIqNJGEU5pHm
YVMm32NkZaCWIWFj4aTenZKo2WseqeWk4ywcK6Lr6twv7WgqJHFxrUlxMqjyMrOz3/Hwc+vz8XTe
qapuFx4Vtl12817wdbm2+bS1lTo6sWm7MrstvCUQ2ol0paai/juRZz9ZboTRK2jwIMKEChcyNBct
/qE8gQ0nUqxo8SLGjPg0AosnjSPIkCJHkixp8iTKlCpXsmzp8iXMmDJn0qxp8ybOnDp38uzp8yfQ
oEKHEi1q9CjSpEqXMm3q9ClUZQGmNqhqdWqAqFq3aqVq9SvYqlm5kr0ooIGBtAYaCBBQ9qDXsHK/
jn3rp63ctm7tshBQ4S/gwIDZ8i0XYC7isIV9nFXr+DHbvXb9Cq4s2IDkxZAOJ+5MV/MIAY8tQ25b
lrLl1IExg1bj+fVV0IfVVuDAQXUFx5G1ov572zdg278tE27NgjPs16BFGwCeFvfqtQLqMq382zbw
2oGHB84s26qD8A6qhidvvkF59OLNL2buPHXz/uCVWTPtXfs29u3BOSBAQNw4AOqF10EHVj3wQFUH
HpggglV10CB6DVB3Wny3xZfaddpV5t1RDQhmGwLc3eebfyNu2NphDihI4AMOEPhgAw/C+ACL6BEo
XngcbnWYbyJahx90ExplgHAgFoBfkcPlh12Stwn5lgAqHvggjVXS6KKUDbSoIpcHiveAjl15aOKH
PWaXn2BPWrEAm2yO4GYPcMIJEpFFFoBAAUcKpyeIIXLAZ5IWNMBMm3IuUIWbc/pR6KGMtjkRegq2
KKmUknqJI6bhIejMnIruxCOZPWY4IpryqelDp4cC4OmbqrKKUZ19/pWnbbTyF2KegAqHAAGC/iqT
6qqqxtmosGoAK8KrCmlpKbPNOitpgZwKm+xNoHJwQZPXZastBxZQ4MCpMFCLaLEiCVBkf9j1l2uu
TN63awEESOBAmKiWC8m4w9prUaTPsrjiv/4OKm2wQB1mgXAXKIytqEsyaZsF3o6XTLKGGoqsq49e
FIAFfmYb4nZN4kkAARd8KyHF9xaM8cUWqxysyvkaFCWNL9r8YpU213zzixTUu6inhWK8MssZDx0S
eggn+e62wnn77Xjhivtyoq2unKjRFzWQZ4j9ee3n12HHW7IEUKOcsr6rWo311VRrbHVFAbjI8807
40z3i+BO87baQz8q59pZgyQ3BU03bUHZ/mZLnfbUrbJdMN8bW0DAnWFbvu7YClNg9nSExlys0GxH
PqyiMhd0GAV431236hScLe29oQsOc8amTxQlBUobfm3i5U23OOMstEzs0UJnJMDklLO7/NgEZND7
eL8/8yqwotf+8gpv204P4ap7T/e3wJMLuvVHQz4t9hgFgLsECie88AXQiyX+vvoObz7MGkUpAcn9
+19y/Dbnu6mUg3pZK5/jgAa3uOHuew7swLd+psBjPe5ibdteQ1JEAQlwsIMdzN0A20FB4p3Pb7Mz
iwM2CD+FJc5sEqKfAk1YPOJV8HMLTJ9CNCiBB9KtbFHbG/pm2DYhWlAk6/NQeCKmRAuE/kcteiGg
ORgFNyla0HgZmcpZBJQpq3SuIFIkGhVJaMWp8Q2D3EPPBnfIww5wMIIwbJz5whhH2eGPI+vTy1z0
osc9vjEo67vjHgOpR6z0cTLo8aD3JtDGHxpHkI58pB6fAkhIUlJ6AIJBilKYRg9yUn6FZMokKynK
T+aEOnUhJCoBgJUVEPKSI0COgDYny1lCbTxXISVSQinKSrqylz6AZVjGs0XE4NIoqDwmMpOZSl8y
85XJIaZXiplLaTazmsq8JjahWM1tctMP2fwmMrspznEeB5zm1CY500lObUKxlZikpjrjKc950rOe
9rwnPvOpz33ys5/+/CdAAyrQgRK0/qAGPShCE7rPj3CToQrFySdKkYx+1CGiEV3IPTwSDYee46J2
AEhErpHRh/ZhHpDwAjd+gYuLeMMdjDApNOLgjZVapKUj4ehR7NENLQzEDMjgRTi+kAt8oIIVsSip
S2+Ri04AogY/pUZQjQrSoq7hqDZ16UYnKoqKmsKjECFIOXQKjks0FRYSSQRYVUFTI0SVGWLdCFk7
4g9QrHWsYOXqLEZqjJeeNaYoneldcQqPq2pVqeR4RFe3UNe2iiOwHVHDW1eKWKHKwqq7WCw5kJpU
tPb0qE41BGXDEYqpbqKqPNWsWwGSWaaW4rS+QGoW9gFaxzYDsqptKykC0ouBvCO2/m/g6moFW1ZF
kMGzZt0tZ2HLWr3ClbYiva1k84GMQSxWr8BlbGGTC4bcTjcVLQ3td2cbXGdE1rGT3YU2RkrT62KW
vIy4x1xjINPLOteumWVre6Hx3rTGV6Z0pS0nlptWs+bXtobNRm6Nq12++tam6xVua6G733zwg7VE
hUWAD/EJ4Fr2sfotLxv6uxGiWtiiHCatXJc64L0eeLvS5euCVbrixo6XIw9BSEiBWpIbHyTHUO3x
frHR37/+twy/LUReZ9zc+5K0yTw2iI/L2uQp2xbCBYmyh6ms5S1zucte/jKYwyzmMZO5zGY+M5rT
rOY1s7nNbn4znOMs5znTuc52/r4znvOs5z3zuc9+/nNBGSDoQQO60CMYNKIZYGhAI1oEjc6JoqeR
6B4QGgaVZoGgFx2TSwOA0zTxdDISnelDT3oFpSa1pjc9amZEGiWgJkalOT3qSxN61Z1udapdcmpK
P/rWuJb1q0ndamArOtiiNnWveR1pWs961c1Gda5VnWxhP5rZv941pp1ta1Hbmtraxjayl/1tR2vb
1+SOtky4nW1xs1vY7ja3st9N7nbHW97B9rW17d3oe6N7Jcf2AbPnrW9ch3vg8l73wY2963y/O9bd
7re/Pa3uc8Mb3+AWOMYrrvBhb/vhFGd4xRFucYi/hNjJzrTJL05sg9c75K92/jjH6W3pmN+a5CWZ
NsOB7XKPzzzmNM94wQdOcIzn3OMdp7jNRXLqle9c4uPuecKbPXSgV5vnMG/41LuNcp4nHSPcTrnT
Hz7xnv973hcfudmLbYWyp33oYp9210PCdneHHeBwD3exx313auN96uvOutUB7/e4a4bfhHez4Q/P
5sQrXs2MbzzkIy/5yVO+8pa/POYzr/nNc77znv886EMv+tGTvvSmPz2fmXOA1bO+9a5/PexjL/vZ
0772tr897nOv+93zvve+/z3wgy/81adFgikxwAH6M4DhM7/5zn8+9KMv/elTP/gD6M8BjD+S5Bcg
+6h3igCSjwADrMQAd9L+/veNIoD+kN8kAbh++9PPFfMfoCTvr7/87XJ99C9EAATAf/7ZRfLB0zQI
wADEXwAKYAEQoDMUAAImoAAOgEYMgARCoGYsH6wUgAXKBgLwHzx04AaChvlZhAFUYEJ8kUW4CqIs
iklYHaY9w69dxMKBnbcdHdLFhANWBAgqBOh4EQsai0HEDj0Y3bXBoKlZxMSVnRKOXbnNRAlSxPox
RLng0K/84JoEobgMYd6x29bVWt4h2wseWs05Gqo5WxkOG7SB4bk5XBqq4Q1unRroXLlxXUEUgAde
AwYuxBQmUBaWTqrEDuD0Tf4gy5ugSiESYgKVUSCqDQnx4d95ISR2YcAd/qEYSt0a0hscwhsd1hwR
nlwRBl0VLF3V7Z1BrN5E2KEUCg8iCuIUreK0ZCEhqqAgyiL2vKIrFqIQ3uIi2mLQPVsaQmIoUmIX
jiEnZmIxfmEoSp219drYHRzUXZ3APZ45RCFDBIAGpmL23KIqIiIv5uIhymI2pk83HiI5lmOjaOMs
zhy02SAxuqAYrmGntaPaISMnxuMmHmPV/aLK0WETsuM9fmBDPCE2fmM5auM4biNBsiLLXCE6DqI3
MiI6oqA+viHHtSElkqHZ2WNFzuNGaiSvnaFFIp0lipzdreMnEiNDDMAdOoMpDiQ3FmQ6xqRCKiQt
wmItkmPMzGQPgiMv/n7kx50kMFLaRZpb3RVl4ImbPIpkRd5gMSbjFlLkU07EATJES+phNjakQeIk
LEJk39giOG7lQXLlVeIkT8JkP8LcFk5iPL4j3WndMBacWqKdxXGhPzZhUnqbRc6dQhzAAx4EBTaE
RA4iQqIP+ZDRKjqiVyIk7WRPEeHPKwbNq9hlvhljOw7lXU6kG9ol0OEb3mVbLy4lSu6cOv5jO1Rl
QphmWeyhDx6mQpAmM2nmQqDmQcgmV6gmPfRkaw5eNzVjbALgafpmYZhRDLFmQrjma5LibAJncoag
K9FmQTgnc/IFdMLDdEZnWVQnOmCndW6FdpZDd24nVHznNIgneDYF/nmypHKW53Wm53Oyp3pyp3tS
Z3wSJ0PCw0OiAxV6zgmmRH6SRH+6pHfOZ3YKKDF8JX5upQit5n76J0yihIHaZxWWJoGWA/Il6EwW
EIIe6G1aJYPS50k8qIUWqG0yw1T2nwmuICMC4jn6odtM4Tn6TSwuJGKySiMK5osKj8UMJmIS5B6W
TlfuIlkSJi6STiySz2PmpPbMIos6YiISjWDi6JHyYZLappBi5QqoZDVeI0Mu4jfWJHEeZCBWUUKK
pYu+JDfmpJmOZVnGJI3yZFmC6ZCeKYpejUE+aKfE0ZjeaC6GKUx65Zr6qU1qpUzCAAJMxA6iKG52
ZZ7WZ2KmaaM2/qiVgiibxolM/imlRiSPkqmOXqigKqqjIuhXPqqHfuqgZqWpeqoq9qAuVoFAUuV8
rulV+unoLOapuqn2/CFY7uilomo4CqqodiqcrihjXo+kYirtwKo5HiYK3iqaymqbagyYGs/nGOmd
Ys95PgM1ImqfnuquwimpGuJY6uKv+iqleiuvAiu5CmsfZuimnmupsmKo1ueXciu7mmuDImuc9sCh
MsT4bem2Tuq8gtGiVuqqsmajcqmaeqiqoiqIhqXDJuy43tDAJuqdwuuiUmyt5irBAuw2hiWnAkCr
BmShauuX6imTMia8MmuoLqmMDmthFmuS7mrL0uq0LuyT4iaz+iYrylZqxeqkjULpsJ4sjLpixfRs
EP2sxj7px/ZrReRgPf3nSkAtoSzGyxjAyFbE+jGgXUgtf/Ig1faANa5kdp5oOgknU3DtUSRLHmLE
2r6neV4tRghA97nt24ptQSDAhNItTxyAloLE+g2A1uotShgg4JYE3/al4PKE1eZtRVgt0ybuTpjf
vp5ECXaf3UKuufBtibZE+Cnf8lUf6Iau6I4u6Zau6c4eBRbA8l2u36bF6e4eALyu7M4u7dYu8xUf
5uau7u4u7/au7/4u8Aav8A4v8Rav8R4v8iav8i4v8zav8z4v9Eav9E4v9Vav9V4v9mav9m4v92JE
CAAAOw==
------=_NextPart_3A0_0FB0_90DDBCF7.DD24B6C8--




From sip-bounces@ietf.org Fri Apr 06 16:34:10 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZv7P-0004rN-AK; Fri, 06 Apr 2007 16:33:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZv7O-0004rI-72
	for sip@ietf.org; Fri, 06 Apr 2007 16:33:10 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZv7M-0002m6-Sy
	for sip@ietf.org; Fri, 06 Apr 2007 16:33:10 -0400
Received: from sj-dkim-8.cisco.com ([171.68.10.93])
	by sj-iport-5.cisco.com with ESMTP; 06 Apr 2007 13:33:09 -0700
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
	by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l36KX8D4015066; 
	Fri, 6 Apr 2007 13:33:08 -0700
Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l36KX3wo012517;
	Fri, 6 Apr 2007 20:33:03 GMT
In-Reply-To: <4616851D.5070305@softarmor.com>
References: <4616851D.5070305@softarmor.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <DEA96B3C-3F47-4226-899B-9C9CFD5B5B50@cisco.com>
Content-Transfer-Encoding: 7bit
From: Cullen Jennings <fluffy@cisco.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
Date: Fri, 6 Apr 2007 13:32:37 -0700
To: Dean Willis <dean.willis@softarmor.com>
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1543; t=1175891588;
	x=1176755588; c=relaxed/simple; s=sjdkim8002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=fluffy@cisco.com;
	z=From:=20Cullen=20Jennings=20<fluffy@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20SIPS=20question=3A=20How=20to=20prevent=20pla
	intext=20requests=20from=20being=20delivered=20to=20a=20UA
	|Sender:=20; bh=lBL69XT4IHRk4wkTYTmQOaY3zFKsQegaLgQlbVCz99g=;
	b=L7sS6OIVaAXd1V0Vs50uH5G/fO7TR/9AOBO3pjWcH3gQRPNF0XGff//brtdwOqbn3Kt9lIBi
	NcxQFG3DrJ8RKZN4xRQCVcmfalAOO3QtJ88aN7ZFgzs8aumjVNNxqy51;
Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim8002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


Just like to point out that if a UA wants to receive all it stuff  
over TLS, it just forms only a TLS outbound connection - this is  
somewhat separate problems than sips.


On Apr 6, 2007, at 10:36 AM, Dean Willis wrote:

>
> I'm pre-reviewing Francois' latest sips draft, and I'm perplexed.
>
> Presume a UA wishes to receive only SIPS requests and not SIP  
> requests.
>
> This is important if we do not wish to reveal information about the  
> UAS (most critically the identity of the user at this UAS) -- to  
> packet-sniffers on the wire between UAC and UAS.
>
>
> Previously it could do this by registering only a SIPS contact and  
> not a SIP, and by using a SIPS AOR in registration.
>
>    Because registering with a SIPS contact header field implies a
>    binding to both a SIPS Contact and a corresponding SIP  
> Contact . . .
>
> means we simply can't satisfy this use case.
>
> Just waiting for a request and then rejecting it if it didn't come  
> in over TLS would not meet the requirement, since the plain text of  
> the request would already have been sent, potentially compromising
> information about the UAS.
>
> Do we have a problem?
>
>
> --
> Dean
>
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 06 17:48:36 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZwHs-0004SZ-Fd; Fri, 06 Apr 2007 17:48:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZwHq-0004RX-Tt
	for sip@ietf.org; Fri, 06 Apr 2007 17:48:02 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZwHp-0001cc-Id
	for sip@ietf.org; Fri, 06 Apr 2007 17:48:02 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l36Llr522961; Fri, 6 Apr 2007 21:47:53 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Fri, 6 Apr 2007 16:47:51 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF0FEFCD3E@zrc2hxm0.corp.nortel.com>
In-Reply-To: <DEA96B3C-3F47-4226-899B-9C9CFD5B5B50@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
thread-index: Acd4iyIiSIaeD39TQ5Gp4dzKJSyBKwACgQDQ
References: <4616851D.5070305@softarmor.com>
	<DEA96B3C-3F47-4226-899B-9C9CFD5B5B50@cisco.com>
From: "Francois Audet" <audet@nortel.com>
To: "Cullen Jennings" <fluffy@cisco.com>,
	"Dean Willis" <dean.willis@softarmor.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

But it could address Dean's requirement however...=20

Dean, should I put some wording about it in there?=20

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]=20
> Sent: Friday, April 06, 2007 13:33
> To: Dean Willis
> Cc: sip@ietf.org
> Subject: Re: [Sip] SIPS question: How to prevent plaintext=20
> requests from being delivered to a UA
>=20
>=20
> Just like to point out that if a UA wants to receive all it=20
> stuff over TLS, it just forms only a TLS outbound connection=20
> - this is somewhat separate problems than sips.
>=20
>=20
> On Apr 6, 2007, at 10:36 AM, Dean Willis wrote:
>=20
> >
> > I'm pre-reviewing Francois' latest sips draft, and I'm perplexed.
> >
> > Presume a UA wishes to receive only SIPS requests and not SIP=20
> > requests.
> >
> > This is important if we do not wish to reveal information about the=20
> > UAS (most critically the identity of the user at this UAS) -- to=20
> > packet-sniffers on the wire between UAC and UAS.
> >
> >
> > Previously it could do this by registering only a SIPS contact and =20
> > not a SIP, and by using a SIPS AOR in registration.
> >
> >    Because registering with a SIPS contact header field implies a
> >    binding to both a SIPS Contact and a corresponding SIP =20
> > Contact . . .
> >
> > means we simply can't satisfy this use case.
> >
> > Just waiting for a request and then rejecting it if it didn't come =20
> > in over TLS would not meet the requirement, since the plain=20
> text of =20
> > the request would already have been sent, potentially compromising
> > information about the UAS.
> >
> > Do we have a problem?
> >
> >
> > --
> > Dean
> >
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 06 17:48:36 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZwGv-0003aN-3j; Fri, 06 Apr 2007 17:47:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZwGt-0003aI-SC
	for sip@ietf.org; Fri, 06 Apr 2007 17:47:03 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZwGs-00014X-HO
	for sip@ietf.org; Fri, 06 Apr 2007 17:47:03 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l36Lkx522922; Fri, 6 Apr 2007 21:46:59 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
Date: Fri, 6 Apr 2007 16:46:43 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF0FEFCD38@zrc2hxm0.corp.nortel.com>
In-Reply-To: <4616851D.5070305@softarmor.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being delivered to a UA
thread-index: Acd4cmYyCQkuUDJYTNCNbSlt3XAprAAIijAw
References: <4616851D.5070305@softarmor.com>
From: "Francois Audet" <audet@nortel.com>
To: "Dean Willis" <dean.willis@softarmor.com>, <sip@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

My very first draft of sips (individual draft) registered both SIP and
SIPS explicitely.

But people hated it (rightfully), and the group wanted the behavior in
the
draft, i.e., registering SIPS means that both SIP and SIPS will be
routed to
you. (And you may choose to reject SIP).

That's the group concensus. I think that was in Montreal.

So I say, no, there is no issue, because I've never heard that new
requirement
before...=20

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]=20
> Sent: Friday, April 06, 2007 10:36
> To: sip@ietf.org
> Subject: [Sip] SIPS question: How to prevent plaintext=20
> requests from being delivered to a UA
>=20
>=20
> I'm pre-reviewing Francois' latest sips draft, and I'm perplexed.
>=20
> Presume a UA wishes to receive only SIPS requests and not SIP=20
> requests.
>=20
> This is important if we do not wish to reveal information=20
> about the UAS (most critically the identity of the user at=20
> this UAS) -- to packet-sniffers on the wire between UAC and UAS.
>=20
>=20
> Previously it could do this by registering only a SIPS=20
> contact and not a SIP, and by using a SIPS AOR in registration.
>=20
>     Because registering with a SIPS contact header field implies a
>     binding to both a SIPS Contact and a corresponding SIP=20
> Contact . . .
>=20
> means we simply can't satisfy this use case.
>=20
> Just waiting for a request and then rejecting it if it didn't=20
> come in over TLS would not meet the requirement, since the=20
> plain text of the request would already have been sent,=20
> potentially compromising information about the UAS.
>=20
> Do we have a problem?
>=20
>=20
> --
> Dean
>=20
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip

From sip-bounces@ietf.org Sat Apr 07 01:27:57 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ha3QW-00054n-86; Sat, 07 Apr 2007 01:25:28 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ha3QU-00050P-Cy
	for sip@ietf.org; Sat, 07 Apr 2007 01:25:26 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ha3QT-000443-1b
	for sip@ietf.org; Sat, 07 Apr 2007 01:25:26 -0400
Received: from [192.168.2.116] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l374VvhN015847
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Apr 2007 23:31:57 -0500
Message-ID: <46172B40.8090107@softarmor.com>
Date: Sat, 07 Apr 2007 00:25:20 -0500
From: Dean Willis <dean.willis@softarmor.com>
User-Agent: Thunderbird 1.5.0.10 (X11/20070306)
MIME-Version: 1.0
To: Eric Rescorla <ekr@networkresonance.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
References: <4616851D.5070305@softarmor.com>
	<20070406174901.D89C45C027@laser.networkresonance.com>
In-Reply-To: <20070406174901.D89C45C027@laser.networkresonance.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Eric Rescorla wrote:

> The only real defense against this sort of downgrade is to only
> give people URLs that start with https: and assume that they will
> do the right thing.
> 
. . .

> As with https: the fix is that your AOR has to somehow signal
> to everyone that you expect to be contacted over TLS. This is
> what sips: does (though of course it's not the only way to do
> it).

But the current draft doesn't. It implies that if you have a SIPS: AOR 
and a SIPS: contact registered to that AOR, that is still OK to send 
SIP: traffic. I requote:

    Because registering with a SIPS contact header field implies a
    binding to both a SIPS Contact and a corresponding SIP Contact . . .

So this is the equivalent of only giving people https:, and assuming 
that they will do the WRONG thing.

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sat Apr 07 01:29:17 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ha3UD-0007sN-BD; Sat, 07 Apr 2007 01:29:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ha3UC-0007s8-3s
	for sip@ietf.org; Sat, 07 Apr 2007 01:29:16 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ha3UA-0004Tc-PN
	for sip@ietf.org; Sat, 07 Apr 2007 01:29:16 -0400
Received: from [192.168.2.116] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l374ZgmY015857
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Apr 2007 23:35:42 -0500
Message-ID: <46172C22.80909@softarmor.com>
Date: Sat, 07 Apr 2007 00:29:06 -0500
From: Dean Willis <dean.willis@softarmor.com>
User-Agent: Thunderbird 1.5.0.10 (X11/20070306)
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
References: <4616851D.5070305@softarmor.com>
	<DEA96B3C-3F47-4226-899B-9C9CFD5B5B50@cisco.com>
In-Reply-To: <DEA96B3C-3F47-4226-899B-9C9CFD5B5B50@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Cullen Jennings wrote:
> 
> Just like to point out that if a UA wants to receive all it stuff over 
> TLS, it just forms only a TLS outbound connection - this is somewhat 
> separate problems than sips.

That will indeed (if outbound is used) keep the outbound proxy from ever 
sending a request to the UA using UDP or TCP, and would address my 
concern (if outbound is used).

But not every UA has an outbound proxy.

What if we have UA to UA traffic, or "redirect to UA", and not an 
"outbound proxy" connection?

This comes up in the context of both classic SIP and P2PSIP.

The current draft says that if you have a SIPS: URI for somebody, it's 
OK to assume that the SIP: URI with matching user/domain parts points to 
the same place. It even (if I read this right) says that if you register 
only a a SIPS: contact, that there is a binding to the equivalent SIP: 
contact implied by the registration.

I think I'm looking to see something that says "If you only have a SIPS: 
  AOR, or there's only a SIPS: contact registered, then there is no 
reason to expect that a SIP: request sent to the equivalent will work, 
and that conformant systems MUST reject such a request.

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sat Apr 07 01:58:05 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ha3vN-0005lE-QI; Sat, 07 Apr 2007 01:57:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ha3vM-0005kz-97
	for sip@ietf.org; Sat, 07 Apr 2007 01:57:20 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ha3vK-0007tb-Uu
	for sip@ietf.org; Sat, 07 Apr 2007 01:57:20 -0400
Received: from [192.168.2.116] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3753goh015938
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 7 Apr 2007 00:03:43 -0500
Message-ID: <461732B2.6070705@softarmor.com>
Date: Sat, 07 Apr 2007 00:57:06 -0500
From: Dean Willis <dean.willis@softarmor.com>
User-Agent: Thunderbird 1.5.0.10 (X11/20070306)
MIME-Version: 1.0
To: Francois Audet <audet@nortel.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from	being
	delivered to a UA
References: <4616851D.5070305@softarmor.com>	<DEA96B3C-3F47-4226-899B-9C9CFD5B5B50@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFCD3E@zrc2hxm0.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FEFCD3E@zrc2hxm0.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: Cullen Jennings <fluffy@cisco.com>, sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Francois Audet wrote:
> But it could address Dean's requirement however... 
> 
> Dean, should I put some wording about it in there? 

I think it would be useful to mention this useful property of outbound.

I'd still like to make sure we really understand the implications for 
the non-outbound use case, and have a clear consensus that this is not a 
requirement we need to meet.

Maybe we really got this in the past, but if so I just missed it (of 
course, I miss a lot of stuff).

Maybe something as simple as "If you have a SIPS: URI for something you 
SHOULD try SIPS: before trying SIP:" would suffice.


Here's the use case I'm worried about again. The question is "Is this a 
problem we need to solve? If not, do we need to warn people that it is a 
problem we don't solve?"

Vice President Dick Cheney is back to hiding in bunkers.  His top-secret 
SIPS: phone registers its sips:vp@whitehouse.gov AOR over a nice secure 
TLS connection with the nice secure SIP proxy hidden in some other 
bunker. Since there aren't any firewalls or NATs to worry about on this 
radio network, we don't use Outbound.

Meanwhile, dozens of Vice Presidential lookalikes hide in other bunkers, 
and all their SIPS: phones register to other AORs at that same proxy.

So far, we've given away nothing on the wire that tells Osama bin Laden 
which bunker has the real Dick Cheney, and which are lookalikes. So he 
doesn't know where to send the hijacked airliner.

Suddenly, somebody at the UN decides they need to ring up the VP, and 
send off a SIP: request, which hits the proxy. The proxy says "Hey this 
is a SIP: request, and I know that since he registered SIPS:, it's ok to 
forward this request. So the request goes out over the radio net, in 
unprotected UDP, carrying both a "To: sip:vp@whitehouse.gov" that lets 
Osama know that this request is for the real VP, and a request URI (the 
registered Contact:) that tells him which bunker the real veep is hiding 
in. Kaboom.

Or, in a less contrived use case (since we know the VP would never use 
anything other than a special non-standards-compliant proxy that would 
use only sips:):

Alice and Bob use P2PSIP overlay ""example'net". Charlie is stalking 
Alice. He doesn't have credentials in the overlay, but he does have a 
WiFi sniffer which he takes coffeeshop to coffeeshop looking for Alice. 
He doesn't find ALice, but he does find Bob, and he waits for Bob to 
call her.

Alice is trying to be careful, so she uses the  secure peer protocol to 
PUT only her sips: contact into the overlay.

Bob uses the secure peer protocol to GET her sips: contact from the 
overlay. But Bob is a lazy slacker, so he downgrades to sip: and sends 
off an INVITE to Alice.

Charlie happens to be sniffing the traffic somewhere, either near Bob or 
near Alice. He might be able to deduce that there's a P2PSIP user on the 
net he's sniffing, but not that it is Alice. But when he sees Bob's 
request go by, he knows that node is Alice, and he knows what her IP 
Address is.

Alice's cover has just been blown.


What, if anything, do we need to say about problem in the draft?

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sat Apr 07 03:24:12 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ha5Fe-0005jU-Dn; Sat, 07 Apr 2007 03:22:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ha5Fd-0005jP-PE
	for sip@ietf.org; Sat, 07 Apr 2007 03:22:21 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ha5Fa-0004mH-RW
	for sip@ietf.org; Sat, 07 Apr 2007 03:22:21 -0400
Received: from sj-dkim-6.cisco.com ([171.68.10.81])
	by sj-iport-5.cisco.com with ESMTP; 07 Apr 2007 00:22:19 -0700
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
	by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l377MIWa026139; 
	Sat, 7 Apr 2007 00:22:18 -0700
Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id l377MHA9024165;
	Sat, 7 Apr 2007 07:22:17 GMT
In-Reply-To: <461732B2.6070705@softarmor.com>
References: <4616851D.5070305@softarmor.com>	<DEA96B3C-3F47-4226-899B-9C9CFD5B5B50@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFCD3E@zrc2hxm0.corp.nortel.com>
	<461732B2.6070705@softarmor.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <05BFBEBE-CCBA-42B4-8BD0-C71B590487EB@cisco.com>
Content-Transfer-Encoding: 7bit
From: Cullen Jennings <fluffy@cisco.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from	being
	delivered to a UA
Date: Sat, 7 Apr 2007 00:21:50 -0700
To: Dean Willis <dean.willis@softarmor.com>
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5730; t=1175930538;
	x=1176794538; c=relaxed/simple; s=sjdkim6002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=fluffy@cisco.com;
	z=From:=20Cullen=20Jennings=20<fluffy@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20SIPS=20question=3A=20How=20to=20prevent=20pla
	intext=20requests=20from=09being=20delivered=20to=20a=20UA
	|Sender:=20; bh=Q4OlA5Xw3VXbJM6d/1A6IfdHzpdLE7wW27SLyXqw5rY=;
	b=Zoi6UQAdRnr0q1w8JtXpinz9cOPe/gYuEiiJNKWtu+6FYtWci+bj+t+40jw6ssktetFIiS8t
	AXFfRxyc4LubBz8EuUOQT2QADfobEsbR9ASId1BWQ7tpNhQ8OJ4L1S5O;
Authentication-Results: sj-dkim-6; header.From=fluffy@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim6002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


We can easily solve this just by using IPsec across the radio  
network :-) (Sorry, couldn't resist not saying that :-)

I don't know what I think of the actual text you are proposing we add  
- it might be fine, I doubt it achieves what you want, but more on  
that later....

However, I am pretty dubious about the use case - it is prosing there  
are going to be phones that are deployed to do TLS but don't do  
outbound - to do this they are going to have to have a certificate  
capable of acting as a SIP TLS server so it will need to assert their  
IP address or a DNS name that maps to their IP address. Although  
theoretically possible, this seems fairly unlikely - particularly for  
phones on a radio network.

So, on the "is this a problem we need to solve" - I think the answer  
is "not really".

But on, "do I see any problems with the proposed solution", I'm not  
sure - we have discussed this is the past and I can't remember what  
the reason were motivating the way it is now.

Following the use case you proposed, let say the INVITE from UN  
arrived at the proxy, it sent it over TLS to UA, and the UA put it's  
contact in the the 200 and sent it back to the proxy over TLS. Now  
the proxy sends it back to the UN over not over TLS, at this point,  
it seems like an attacker can once again find out the bunker by  
looking at the contact in the 200.

Or imagine your second case, and say Bob is not a slacker and does  
use TLS, but Charlie knows that Bob only calls Alice at that time and  
just looks at where the RTP packets are going.

Location privacy is a very hard thing to achieve and we have a bunch  
of drafts about that. I'm just not sure that we can get "sips" in a  
registered contact to mean "don't reveal my IP location information  
to bad guys". We are constantly trying to get the sips to mean more  
than it actually can. The whole discussion makes me very nervous.

more inline ...

Cullen <with my individual hat on>


On Apr 6, 2007, at 10:57 PM, Dean Willis wrote:

> Francois Audet wrote:
>> But it could address Dean's requirement however... Dean, should I  
>> put some wording about it in there?
>
> I think it would be useful to mention this useful property of  
> outbound.
>
> I'd still like to make sure we really understand the implications  
> for the non-outbound use case, and have a clear consensus that this  
> is not a requirement we need to meet.
>
> Maybe we really got this in the past, but if so I just missed it  
> (of course, I miss a lot of stuff).
>
> Maybe something as simple as "If you have a SIPS: URI for something  
> you SHOULD try SIPS: before trying SIP:" would suffice.

This seems like it would work for a UA but not sure it would for a  
proxy - once the proxy upgrades, now everyone before the proxy has to  
do sips too. Perhaps, I'm just all confused on this.


>
>
> Here's the use case I'm worried about again. The question is "Is  
> this a problem we need to solve? If not, do we need to warn people  
> that it is a problem we don't solve?"
>
> Vice President Dick Cheney is back to hiding in bunkers.  His top- 
> secret SIPS: phone registers its sips:vp@whitehouse.gov AOR over a  
> nice secure TLS connection with the nice secure SIP proxy hidden in  
> some other bunker. Since there aren't any firewalls or NATs to  
> worry about on this radio network, we don't use Outbound.
>
> Meanwhile, dozens of Vice Presidential lookalikes hide in other  
> bunkers, and all their SIPS: phones register to other AORs at that  
> same proxy.
>
> So far, we've given away nothing on the wire that tells Osama bin  
> Laden which bunker has the real Dick Cheney, and which are  
> lookalikes. So he doesn't know where to send the hijacked airliner.
>
> Suddenly, somebody at the UN decides they need to ring up the VP,  
> and send off a SIP: request, which hits the proxy. The proxy says  
> "Hey this is a SIP: request, and I know that since he registered  
> SIPS:, it's ok to forward this request. So the request goes out  
> over the radio net, in unprotected UDP, carrying both a "To:  
> sip:vp@whitehouse.gov" that lets Osama know that this request is  
> for the real VP, and a request URI (the registered Contact:) that  
> tells him which bunker the real veep is hiding in. Kaboom.
>
> Or, in a less contrived use case (since we know the VP would never  
> use anything other than a special non-standards-compliant proxy  
> that would use only sips:):
>
> Alice and Bob use P2PSIP overlay ""example'net". Charlie is  
> stalking Alice. He doesn't have credentials in the overlay, but he  
> does have a WiFi sniffer which he takes coffeeshop to coffeeshop  
> looking for Alice. He doesn't find ALice, but he does find Bob, and  
> he waits for Bob to call her.
>
> Alice is trying to be careful, so she uses the  secure peer  
> protocol to PUT only her sips: contact into the overlay.
>
> Bob uses the secure peer protocol to GET her sips: contact from the  
> overlay. But Bob is a lazy slacker, so he downgrades to sip: and  
> sends off an INVITE to Alice.
>
> Charlie happens to be sniffing the traffic somewhere, either near  
> Bob or near Alice. He might be able to deduce that there's a P2PSIP  
> user on the net he's sniffing, but not that it is Alice. But when  
> he sees Bob's request go by, he knows that node is Alice, and he  
> knows what her IP Address is.
>
> Alice's cover has just been blown.
>
>
> What, if anything, do we need to say about problem in the draft?

seems like there are lots more problems with location privacy stuff  
as discussed in 3323

>
> --
> Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sat Apr 07 11:18:23 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HaCcR-0002hm-6s; Sat, 07 Apr 2007 11:14:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HaCcP-0002hf-Cu
	for sip@ietf.org; Sat, 07 Apr 2007 11:14:21 -0400
Received: from sd-green-bigip-145.dreamhost.com ([208.97.132.145]
	helo=randymail-a9.g.dreamhost.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaCcO-0000Pg-1G
	for sip@ietf.org; Sat, 07 Apr 2007 11:14:21 -0400
Received: from delta.rtfm.com (unknown [74.95.2.169])
	by randymail-a9.g.dreamhost.com (Postfix) with ESMTP id 6985EEF01F;
	Sat,  7 Apr 2007 08:14:17 -0700 (PDT)
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1])
	by delta.rtfm.com (Postfix) with ESMTP id 87A941CC3D;
	Sat,  7 Apr 2007 08:12:44 -0700 (PDT)
Date: Sat, 07 Apr 2007 08:12:44 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
In-Reply-To: <46172B40.8090107@softarmor.com>
References: <4616851D.5070305@softarmor.com>
	<20070406174901.D89C45C027@laser.networkresonance.com>
	<46172B40.8090107@softarmor.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20070407151244.87A941CC3D@delta.rtfm.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

At Sat, 07 Apr 2007 00:25:20 -0500,
Dean Willis wrote:
> 
> Eric Rescorla wrote:
> 
> > The only real defense against this sort of downgrade is to only
> > give people URLs that start with https: and assume that they will
> > do the right thing.
> > 
> . . .
> 
> > As with https: the fix is that your AOR has to somehow signal
> > to everyone that you expect to be contacted over TLS. This is
> > what sips: does (though of course it's not the only way to do
> > it).
> 
> But the current draft doesn't. It implies that if you have a SIPS: AOR 
> and a SIPS: contact registered to that AOR, that is still OK to send 
> SIP: traffic. I requote:
>
>     Because registering with a SIPS contact header field implies a
>     binding to both a SIPS Contact and a corresponding SIP Contact . . .
> 
> So this is the equivalent of only giving people https:, and assuming 
> that they will do the WRONG thing.

I don't understand the argument you're making here, probably because
"OK" isn't any kind of normative term. There are three relevant
actors here:

1. The registering user.
2. The proxy.
3. The caller.

You give the caller the sips: URI and I think the draft makes clear
that if you have a sips: URI you MUST NOT use SIP w/o TLS. The question
is what a proxy should do if a request comes in without TLS.


If you give people HTTPS and they try to contact the server over 
HTTP (recall that the servers need to support both TLS and non-TLS)
the server can do one of three things:

- Respond to the request anyway.
- Redirect the request
- Throw an error.

The damage of the data being sent over the net to the server is already
done.


Going back to the SIP case, the proxy has three options:

- Forward the request to the client anyway.
- Redirect to the SIPS AOR
- Throw an error.

Again, the damage of the data being sent in the clear over the net
to the proxy is already done. The text you quote above implies
the first choice, but it's not clear there's anything wrong with
that, especially as you can ensure that the connection from the
registering user to the proxy  is secure.

-Ekr






_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sat Apr 07 11:47:57 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HaD8a-0008Ck-HP; Sat, 07 Apr 2007 11:47:36 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HaD8Y-0008CZ-WC
	for sip@ietf.org; Sat, 07 Apr 2007 11:47:35 -0400
Received: from zrtps0kp.nortel.com ([47.140.192.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaD8X-0006p9-JS
	for sip@ietf.org; Sat, 07 Apr 2007 11:47:34 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l37FlUM06503; Sat, 7 Apr 2007 15:47:30 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
Date: Sat, 7 Apr 2007 10:47:28 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF0FEFCE7A@zrc2hxm0.corp.nortel.com>
In-Reply-To: <05BFBEBE-CCBA-42B4-8BD0-C71B590487EB@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being delivered to a UA
thread-index: Acd45X4G2LSnnaJDQWSqxkTxcn8JAAARaPQg
References: <4616851D.5070305@softarmor.com>
	<DEA96B3C-3F47-4226-899B-9C9CFD5B5B50@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFCD3E@zrc2hxm0.corp.nortel.com>
	<461732B2.6070705@softarmor.com>
	<05BFBEBE-CCBA-42B4-8BD0-C71B590487EB@cisco.com>
From: "Francois Audet" <audet@nortel.com>
To: "Cullen Jennings" <fluffy@cisco.com>,
	"Dean Willis" <dean.willis@softarmor.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Here is my take.

There is some text in there already that says that some proxies may have
policies of ONLY forwarding SIPS.

What I can do in the text is hightlight the "problem" you are talking
about,
and explain how it is solved:
- E.g., you can use outbound. Contrary to what Dean stated below,
Outbound is NOT
  just useful for NAT/Firewall traversal. It is also necessary for
supporting
  TLS when the UA does not provide a certificate (i.e., the server can't
establish
  the connection otherwise). This mean that your Dick Cheney example
will only
  be applicable if Dick Cheney has a certificate.
- Let say that Dick Cheney has a certifiate, and you do not use
Outbound. You
  could have a STANDARD proxy that has a policy of SIPS only (either
accross the
  board, or just for Dick Cheney). My view is that it would be a pretty
naive
  (and bad) product if you didn't have the mechanism in the proxy to
assign policies
  like this.

What I propose is that I discuss this in the draft. I really don't think
it needs=20
protocol work. It's already solvable today. It's just good engineering.=20

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]=20
> Sent: Saturday, April 07, 2007 00:22
> To: Dean Willis
> Cc: Audet, Francois (SC100:3055); sip@ietf.org
> Subject: Re: [Sip] SIPS question: How to prevent plaintext=20
> requests from being delivered to a UA
>=20
>=20
> We can easily solve this just by using IPsec across the radio=20
> network :-) (Sorry, couldn't resist not saying that :-)
>=20
> I don't know what I think of the actual text you are proposing we add
> - it might be fine, I doubt it achieves what you want, but=20
> more on that later....
>=20
> However, I am pretty dubious about the use case - it is=20
> prosing there are going to be phones that are deployed to do=20
> TLS but don't do outbound - to do this they are going to have=20
> to have a certificate capable of acting as a SIP TLS server=20
> so it will need to assert their IP address or a DNS name that=20
> maps to their IP address. Although theoretically possible,=20
> this seems fairly unlikely - particularly for phones on a=20
> radio network.
>=20
> So, on the "is this a problem we need to solve" - I think the=20
> answer is "not really".
>=20
> But on, "do I see any problems with the proposed solution",=20
> I'm not sure - we have discussed this is the past and I can't=20
> remember what the reason were motivating the way it is now.
>=20
> Following the use case you proposed, let say the INVITE from=20
> UN arrived at the proxy, it sent it over TLS to UA, and the=20
> UA put it's contact in the the 200 and sent it back to the=20
> proxy over TLS. Now the proxy sends it back to the UN over=20
> not over TLS, at this point, it seems like an attacker can=20
> once again find out the bunker by looking at the contact in the 200.
>=20
> Or imagine your second case, and say Bob is not a slacker and=20
> does use TLS, but Charlie knows that Bob only calls Alice at=20
> that time and just looks at where the RTP packets are going.
>=20
> Location privacy is a very hard thing to achieve and we have=20
> a bunch of drafts about that. I'm just not sure that we can=20
> get "sips" in a registered contact to mean "don't reveal my=20
> IP location information to bad guys". We are constantly=20
> trying to get the sips to mean more than it actually can. The=20
> whole discussion makes me very nervous.
>=20
> more inline ...
>=20
> Cullen <with my individual hat on>
>=20
>=20
> On Apr 6, 2007, at 10:57 PM, Dean Willis wrote:
>=20
> > Francois Audet wrote:
> >> But it could address Dean's requirement however... Dean,=20
> should I put=20
> >> some wording about it in there?
> >
> > I think it would be useful to mention this useful property of=20
> > outbound.
> >
> > I'd still like to make sure we really understand the=20
> implications for=20
> > the non-outbound use case, and have a clear consensus that=20
> this is not=20
> > a requirement we need to meet.
> >
> > Maybe we really got this in the past, but if so I just=20
> missed it (of=20
> > course, I miss a lot of stuff).
> >
> > Maybe something as simple as "If you have a SIPS: URI for something=20
> > you SHOULD try SIPS: before trying SIP:" would suffice.
>=20
> This seems like it would work for a UA but not sure it would=20
> for a proxy - once the proxy upgrades, now everyone before=20
> the proxy has to do sips too. Perhaps, I'm just all confused on this.
>=20
>=20
> >
> >
> > Here's the use case I'm worried about again. The question=20
> is "Is this=20
> > a problem we need to solve? If not, do we need to warn=20
> people that it=20
> > is a problem we don't solve?"
> >
> > Vice President Dick Cheney is back to hiding in bunkers.  His top-=20
> > secret SIPS: phone registers its sips:vp@whitehouse.gov AOR over a=20
> > nice secure TLS connection with the nice secure SIP proxy hidden in=20
> > some other bunker. Since there aren't any firewalls or NATs=20
> to worry=20
> > about on this radio network, we don't use Outbound.
> >
> > Meanwhile, dozens of Vice Presidential lookalikes hide in other=20
> > bunkers, and all their SIPS: phones register to other AORs at that=20
> > same proxy.
> >
> > So far, we've given away nothing on the wire that tells Osama bin=20
> > Laden which bunker has the real Dick Cheney, and which are=20
> lookalikes.=20
> > So he doesn't know where to send the hijacked airliner.
> >
> > Suddenly, somebody at the UN decides they need to ring up=20
> the VP, and=20
> > send off a SIP: request, which hits the proxy. The proxy says "Hey=20
> > this is a SIP: request, and I know that since he registered SIPS:,=20
> > it's ok to forward this request. So the request goes out over the=20
> > radio net, in unprotected UDP, carrying both a "To:
> > sip:vp@whitehouse.gov" that lets Osama know that this=20
> request is for=20
> > the real VP, and a request URI (the registered Contact:) that tells=20
> > him which bunker the real veep is hiding in. Kaboom.
> >
> > Or, in a less contrived use case (since we know the VP=20
> would never use=20
> > anything other than a special non-standards-compliant proxy=20
> that would=20
> > use only sips:):
> >
> > Alice and Bob use P2PSIP overlay ""example'net". Charlie is=20
> stalking=20
> > Alice. He doesn't have credentials in the overlay, but he=20
> does have a=20
> > WiFi sniffer which he takes coffeeshop to coffeeshop looking for=20
> > Alice. He doesn't find ALice, but he does find Bob, and he=20
> waits for=20
> > Bob to call her.
> >
> > Alice is trying to be careful, so she uses the  secure peer=20
> protocol=20
> > to PUT only her sips: contact into the overlay.
> >
> > Bob uses the secure peer protocol to GET her sips: contact from the=20
> > overlay. But Bob is a lazy slacker, so he downgrades to=20
> sip: and sends=20
> > off an INVITE to Alice.
> >
> > Charlie happens to be sniffing the traffic somewhere,=20
> either near Bob=20
> > or near Alice. He might be able to deduce that there's a=20
> P2PSIP user=20
> > on the net he's sniffing, but not that it is Alice. But=20
> when he sees=20
> > Bob's request go by, he knows that node is Alice, and he knows what=20
> > her IP Address is.
> >
> > Alice's cover has just been blown.
> >
> >
> > What, if anything, do we need to say about problem in the draft?
>=20
> seems like there are lots more problems with location privacy=20
> stuff as discussed in 3323
>=20
> >
> > --
> > Dean
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sat Apr 07 14:22:06 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HaFVJ-0005i7-DW; Sat, 07 Apr 2007 14:19:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HaFVH-0005i0-Pf
	for sip@ietf.org; Sat, 07 Apr 2007 14:19:11 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaFVF-0007zd-5T
	for sip@ietf.org; Sat, 07 Apr 2007 14:19:11 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l37IJ6K20144; Sat, 7 Apr 2007 18:19:06 GMT
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: Sat, 7 Apr 2007 13:18:49 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF0FEFCEB0@zrc2hxm0.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FEFCE7A@zrc2hxm0.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SIPS issue: Option tag
thread-index: Acd45X4G2LSnnaJDQWSqxkTxcn8JAAARaPQgAAVB4CA=
References: <4616851D.5070305@softarmor.com>
	<DEA96B3C-3F47-4226-899B-9C9CFD5B5B50@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFCD3E@zrc2hxm0.corp.nortel.com>
	<461732B2.6070705@softarmor.com>
	<05BFBEBE-CCBA-42B4-8BD0-C71B590487EB@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFCE7A@zrc2hxm0.corp.nortel.com>
From: "Francois Audet" <audet@nortel.com>
To: <sip@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: Dean Willis <dean.willis@softarmor.com>
Subject: [Sip] SIPS issue: Option tag
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Dean Willis has suggested that we should have a "sips" option-tag
defined for implementations that support the procedures of
draft-ietf-sip-sips.

This is standard practice to deal with backward compatibility.

In this particular case, it would be for implementations that
supported RFC 3261 before draft-ietf-sip-sips was standardized.
Those implementions are very likely to use procedurs that do not
comply with this specification (e.g., some may be using the
transport=3Dtls
parameter, may be registering explictly both SIP and SIPS contacts, may
be using the last hop-exception, etc.). Proxies and UAs that support
these legacy
UAs would therefore use whatever coping techniques that would "work".

Unless there is a good reason NOT to define a sips option-tag for this=20
purpose, I will include it in the next release.=20

Comments?

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sat Apr 07 14:45:30 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HaFuZ-0006an-Rl; Sat, 07 Apr 2007 14:45:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HaFuX-0006ai-MG
	for sip@ietf.org; Sat, 07 Apr 2007 14:45:17 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaFuW-00082J-Bk
	for sip@ietf.org; Sat, 07 Apr 2007 14:45:17 -0400
Received: from [192.168.2.116] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l37HplNb018431
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 7 Apr 2007 12:51:47 -0500
Message-ID: <4617E6B8.5070601@softarmor.com>
Date: Sat, 07 Apr 2007 13:45:12 -0500
From: Dean Willis <dean.willis@softarmor.com>
User-Agent: Thunderbird 1.5.0.10 (X11/20070306)
MIME-Version: 1.0
To: Eric Rescorla <ekr@networkresonance.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
References: <4616851D.5070305@softarmor.com>	<20070406174901.D89C45C027@laser.networkresonance.com>	<46172B40.8090107@softarmor.com>
	<20070407151244.87A941CC3D@delta.rtfm.com>
In-Reply-To: <20070407151244.87A941CC3D@delta.rtfm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Eric Rescorla wrote:

> You give the caller the sips: URI and I think the draft makes clear
> that if you have a sips: URI you MUST NOT use SIP w/o TLS. The question
> is what a proxy should do if a request comes in without TLS.

I'm not finding that. What I'm finding is text that says a user who is 
given a sips: URI can deduce a sip: URI from that and use it.


> If you give people HTTPS and they try to contact the server over 
> HTTP (recall that the servers need to support both TLS and non-TLS)
> the server can do one of three things:
> 
> - Respond to the request anyway.
> - Redirect the request
> - Throw an error.
> 
> The damage of the data being sent over the net to the server is already
> done.

Right.  The problem I'm trying to describe is -- do we need guidelines 
that prevent this damage from being done?

The HTTPS equivalent use case is:

Assume you are given an HTTPS URL for something. If you deduce an 
equivalent HTTP URL for that target and exercise it, any information 
sent is subject to interception by packet sniffers. If the HTTPS URL was 
for a "login" service, you might have just given away your password.



> 
> Going back to the SIP case, the proxy has three options:
> 
> - Forward the request to the client anyway.
> - Redirect to the SIPS AOR
> - Throw an error.
> 
> Again, the damage of the data being sent in the clear over the net
> to the proxy is already done. The text you quote above implies
> the first choice, but it's not clear there's anything wrong with
> that, especially as you can ensure that the connection from the
> registering user to the proxy  is secure.

The only way to ensure that the connection from the proxy to the 
registering user is secure is to "upgrade" the connection to SIPS. Just 
using TLS won't work, because there are possibly additional proxies 
between the proxy/registrar and the user. But upgrading to SIPS in a 
midstream proxy has issues that Francois and Jonathan have pointed out 
(like surprising the UAC, which might not support SIPS) or requires some 
B2BUA procedure from the proxy (like my old kludge-proxy did).


In the HTTP case as described above, we have a mitigating factor 
provided by TCP. Since HTTP and HTTPS both require a TCP connection and 
listen on different ports, the worrried server could just turn off its 
HTTP port. The client would fail to do a TCP open with the HTTP port, 
and would thus never send the sensitive information unprotected.

SIP has UDP, so there's no "open". Instead, (if a user or UAC deduces an 
equivalent SIP URI and uses it), the sensitive information could well 
just be blurted out, unprotected, in a UDP packet. And the only one 
listening for that packet is the interceptor, who is now a happy camper.


Perhaps something like:

A user or a UAC that has been presented a SIPS: URI for a correspondent 
MUST NOT deduce an equivalent SIP URI and use it. Instead, they MUST use 
the SIPS URI. The rationale for this that the issuer of the SIPS URI 
chose SIPS instead of SIP because they need to have a higher level of 
security exercised when contacting them, and their callers are required 
  to respect that need. If the user or UAC instead uses the equivalent 
SIP URI, there is a risk of disclosure to non-trusted intermediaries of 
information sensitive to the holder of the URI, such as their currently 
registered Contact.

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sat Apr 07 15:24:45 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HaGVx-0004hA-6K; Sat, 07 Apr 2007 15:23:57 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HaGVv-0004h4-OJ
	for sip@ietf.org; Sat, 07 Apr 2007 15:23:55 -0400
Received: from sd-green-bigip-202.dreamhost.com ([208.97.132.202]
	helo=randymail-a2.g.dreamhost.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaGVu-000074-Cm
	for sip@ietf.org; Sat, 07 Apr 2007 15:23:55 -0400
Received: from delta.rtfm.com (adsl-76-199-138-49.dsl.pltn13.sbcglobal.net
	[76.199.138.49])
	by randymail-a2.g.dreamhost.com (Postfix) with ESMTP id 4F047EEBB3;
	Sat,  7 Apr 2007 12:23:53 -0700 (PDT)
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1])
	by delta.rtfm.com (Postfix) with ESMTP id 253931CC3D;
	Sat,  7 Apr 2007 12:22:20 -0700 (PDT)
Date: Sat, 07 Apr 2007 12:22:20 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
In-Reply-To: <4617E6B8.5070601@softarmor.com>
References: <4616851D.5070305@softarmor.com>
	<20070406174901.D89C45C027@laser.networkresonance.com>
	<46172B40.8090107@softarmor.com>
	<20070407151244.87A941CC3D@delta.rtfm.com>
	<4617E6B8.5070601@softarmor.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20070407192220.253931CC3D@delta.rtfm.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

At Sat, 07 Apr 2007 13:45:12 -0500,
Dean Willis wrote:
> 
> Eric Rescorla wrote:
> 
> > You give the caller the sips: URI and I think the draft makes clear
> > that if you have a sips: URI you MUST NOT use SIP w/o TLS. The question
> > is what a proxy should do if a request comes in without TLS.
> 
> I'm not finding that. What I'm finding is text that says a user who is 
> given a sips: URI can deduce a sip: URI from that and use it.

I don't agree with that interpretation of the text. The fact that
you *registered* both a SIP URI and a SIPS URI does not mean
that other users should convert a sips: URI to a SIP one.
Here's the relevant text from page 7:

   Although not mandated specifically in [RFC3261], the implication is
   that a resource described by a SIPS URI can not be "downgraded" to a
   SIP URI by just changing the scheme, unless it is the "last hop
   exception" described in Section 3.  This specification clarifies that
   a resource described by a SIPS URI MUST NOT be "downgraded" to a SIP
   URI by changing the scheme, or by sending the associated request over
   a non secure link, except for cases where the "last-hop exception"
   rule is in effect (in which case the Request-URI would be replaced by
   a SIP URI).


> Right.  The problem I'm trying to describe is -- do we need guidelines 
> that prevent this damage from being done?
> 
> The HTTPS equivalent use case is:
> 
> Assume you are given an HTTPS URL for something. If you deduce an 
> equivalent HTTP URL for that target and exercise it, any information 
> sent is subject to interception by packet sniffers. If the HTTPS URL was 
> for a "login" service, you might have just given away your password.

Yes, and you shouldn't do that.


> A user or a UAC that has been presented a SIPS: URI for a correspondent 
> MUST NOT deduce an equivalent SIP URI and use it. Instead, they MUST use 
> the SIPS URI. The rationale for this that the issuer of the SIPS URI 
> chose SIPS instead of SIP because they need to have a higher level of 
> security exercised when contacting them, and their callers are required 
>   to respect that need. If the user or UAC instead uses the equivalent 
> SIP URI, there is a risk of disclosure to non-trusted intermediaries of 
> information sensitive to the holder of the URI, such as their currently 
> registered Contact.

I think the text I quoted implies this

-Ekr

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From houleqstt@blueyonder.co.uk Sat Apr 07 18:09:07 2007
Return-path: <houleqstt@blueyonder.co.uk>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HaJ5n-0005KR-Ln; Sat, 07 Apr 2007 18:09:07 -0400
Received: from 82-32-249-178.cable.ubr12.newt.blueyonder.co.uk ([82.32.249.178] helo=blueyonder.co.uk)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1HaJ5j-0007eM-Gx; Sat, 07 Apr 2007 18:09:07 -0400
Message-ID: <526101c7790a$2a059030$e7c21803@houleqstt>
Reply-To: "Rochell" <houleqstt@blueyonder.co.uk>
From: "Rochell" <houleqstt@blueyonder.co.uk>
To: "louisa lee" <ietf-62-request@lists.ietf.org>
Cc: "hannah" <imapext-archive@lists.ietf.org>,
	"edgardo franklin" <l1vpn@lists.ietf.org>,
	"toni" <ion-archive@lists.ietf.org>,
	"chantel reid" <grow-archive@lists.ietf.org>,
	"valerie berry" <idwg-archive@lists.ietf.org>,
	"rory simpson" <aaa-archive@lists.ietf.org>,
	"darnell castillo" <bridge-archive@lists.ietf.org>,
	"tory" <mailman-bounces@lists.ietf.org>,
	"arlette morgan" <sip-archive@lists.ietf.org>
Subject: Busy as before
Date: Sat, 07 Apr 2007 11:44:56 -1000
MIME-Version: 1.0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_948_C18F_1C25A4E2.F1FFEDC0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V10.0.2627
X-Spam-Score: 2.5 (++)
X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78

This is a multi-part message in MIME format.

------=_NextPart_948_C18F_1C25A4E2.F1FFEDC0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_67E_FBAE_E507E6BD.A00FAE0D"

------=_NextPart_67E_FBAE_E507E6BD.A00FAE0D
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable






branch paint ear wall Alas, yes! said Caderousse very uneasily.sign carel=
essly work That horse is the best plan, believe me. Impossible!He dirty i=
s with Edward, hit who place is not moon quite well, replie
Certainly I will.Well, minute catch camp you squash the indeed exacting, =
my  fellow! 
Try, at below least, to expansion give ride me statement an idea of what =
it is. A bad relapse, that fragile will lead hot you, suspect take if I m=
istake n How can I? boot Villefort tin paint rushed up-stairs sewn to fet=
ch him. Take thi
Merely his daughter.You do slippery not lovely dance form sanction our pr=
oject? appreciate Yes, wonder promptly separate I own it. No.
start Morrel use soap looked spoil towards Noirtier for permission to r d=
epend ugly Reverend quickly horse sir, I am impelled-- music help tickle =
Nothing is easier. sense Is it large? church thaw fire complete Every cri=
minal says the same thing. board Contempt, my friend? ugly How connect do=
es stolen this misfortune aff
There ice is hung another birth way, said wed Morrel. The old man'sWhat? =
camera the daughter space curtain turn of Ali Pasha? Of exuberant Ali Pas=
ha and myrmecological squeak attract the beautiful Vasiliki. pig Are you =
quite impervious brain spring event to good advice?  Not shock strung whe=
n it pomaceous prefer comes from a friend.
Here is whine my cloud passport; receipt examine tame the visa--Geneva, M=
iThank punishment you, bomb grip my  Beauchamp, thank clever you for the =
eYes. Middling.
beam withstand Send mourn for some fetch oil of turpentine and tartar eme=
tic signal sow Albert, had you been a stranger, noise a sing foreigner, a=
 s Poverty-- What tire circumlocution! blow How long produce tired you ar=
e before you picture Be it so, summer said Beauchamp; if you must swim in=
nocent have me d And your slave?
ripe I will go, wine ant continued Maximilian, pass I will seek M.Ma foi!=
 yes.shake rarely driving And do you tell account me that title? Yes. cru=
sh answer But how did waste mistake she become so?
nervously scary flee How sneeze is it arranged? Villefort immediately des=
patched lighten command shoe axillary a messenger. And  Must tomorrow I g=
o carriage signal too? suggestion asked Valentine timidly.
Pshaw! blastous elated stood lick said Busoni disdainfully; poverty may m=
a Well, then, include weather you understand, back Beauchamp, effect that=
 we be regularly Because, fair engine politely in truth, Albert-- jail Fa=
ith, shaggy I should require pen, ink, and revolting vivacious paper to m=
a Well, listen, Morcerf. Why, wish dress simply seal from the retire circ=
umstance of my having bo
------=_NextPart_67E_FBAE_E507E6BD.A00FAE0D
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"=
>
<META content=3D"MSHTML 10.0.2627" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><FONT face=3DArial size=3D1>
<DIV>
<p><IMG alt=3D"" hspace=3D0 src=3D"cid:7b86501c7790a52a35ef00e5edeb76@hou=
leqstt" align=3Dbaseline border=3D0></p>
<BR><BR>
<DIV><FONT FACE=3D"Arial" size=3D1>branch paint ear wall Alas, yes! said =
Caderousse very uneasily.sign carelessly work That horse is the best plan=
, believe me. Impossible!He dirty is with Edward, hit who place is not mo=
on quite well, replie</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>Certainly I will.Well, minute catch ca=
mp you squash the indeed exacting, my  fellow! </FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>Try, at below least, to expansion give=
 ride me statement an idea of what it is. A bad relapse, that fragile wil=
l lead hot you, suspect take if I mistake n How can I? boot Villefort tin=
 paint rushed up-stairs sewn to fetch him. Take thi</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>Merely his daughter.You do slippery no=
t lovely dance form sanction our project? appreciate Yes, wonder promptly=
 separate I own it. No.</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>start Morrel use soap looked spoil tow=
ards Noirtier for permission to r depend ugly Reverend quickly horse sir,=
 I am impelled-- music help tickle Nothing is easier. sense Is it large? =
church thaw fire complete Every criminal says the same thing. board Conte=
mpt, my friend? ugly How connect does stolen this misfortune aff</FONT></=
DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>There ice is hung another birth way, s=
aid wed Morrel. The old man'sWhat? camera the daughter space curtain turn=
 of Ali Pasha? Of exuberant Ali Pasha and myrmecological squeak attract t=
he beautiful Vasiliki. pig Are you quite impervious brain spring event to=
 good advice?  Not shock strung when it pomaceous prefer comes from a fri=
end.</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>Here is whine my cloud passport; recei=
pt examine tame the visa--Geneva, MiThank punishment you, bomb grip my  B=
eauchamp, thank clever you for the eYes. Middling.</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>beam withstand Send mourn for some fet=
ch oil of turpentine and tartar emetic signal sow Albert, had you been a =
stranger, noise a sing foreigner, a s Poverty-- What tire circumlocution!=
 blow How long produce tired you are before you picture Be it so, summer =
said Beauchamp; if you must swim innocent have me d And your slave?</FONT=
></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>ripe I will go, wine ant continued Max=
imilian, pass I will seek M.Ma foi! yes.shake rarely driving And do you t=
ell account me that title? Yes. crush answer But how did waste mistake sh=
e become so?</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>nervously scary flee How sneeze is it =
arranged? Villefort immediately despatched lighten command shoe axillary =
a messenger. And  Must tomorrow I go carriage signal too? suggestion aske=
d Valentine timidly.</FONT></DIV>
<DIV><FONT FACE=3D"Arial" size=3D1>Pshaw! blastous elated stood lick said=
 Busoni disdainfully; poverty may ma Well, then, include weather you unde=
rstand, back Beauchamp, effect that we be regularly Because, fair engine =
politely in truth, Albert-- jail Faith, shaggy I should require pen, ink,=
 and revolting vivacious paper to ma Well, listen, Morcerf. Why, wish dre=
ss simply seal from the retire circumstance of my having bo</FONT></DIV>
</DIV></FONT></BODY></HTML>

------=_NextPart_67E_FBAE_E507E6BD.A00FAE0D--

------=_NextPart_948_C18F_1C25A4E2.F1FFEDC0
Content-Type: image/gif;
	name="doueygeaociukh.gif"
Content-Transfer-Encoding: base64
Content-ID: <7b86501c7790a52a35ef00e5edeb76@houleqstt>

R0lGODdhjQGMAYQAAP///+bm5urf0N9eXs4cHNU+Pu+vr+eUlNpSUswAAABm/wAAAP8AAMzMzLaz
tpOm3E+UyS1sq3d0d0V0oYmMk9mpcrWLUZlmM/7otVZNVv/JW0o8S8iHR3eQ1gAAAAAAACwAAAAA
jQGMAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt
er/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg4RYAQKIAwMBhY2OcAIiAQMEBQaUBiQB
BgaMXgqPoY8HCJEAAwkJmQeZkpSsB6ZPCrS1oCa2arcrtrkktY69NcAjvlwGAgaWIgepsa3MCQSI
lVG9xgDYZNoo18Qi34LetDLh3FeHBQUCBwciBqkDCAgkCNLuiiOySePkb+cl+vkLF0hgOX9hBChS
mKAAq3cEEiCQ5wlAs3sCPB1YpsSYR4LXToQUKewXMWzA/kqCG5ni40By57yZvHUSZk2EAVkWU5nt
G8CdN3EGnTlz19CcP3MoS8Up4joRApwi6gQAkT1prQwgOLCQn8+vQmUW5Tau6MqwZc8m7YnQVz+k
LFO2FUg2rVqXNAmSRLuLrVi2Zu/ytOtDQIFUlq4+DXB4nTJklgRcdVc1WcQBXudqNroZ6F+/cY8K
xqsXbujPYDmrLKsTsFrPI92WDux57Gq+sG+/xNlDcioCAw4ncGe4odZpAhJgjqpKX0TlD4ugFO16
r2bYr7OTzs69pUG/3XEF7Qu6/FrZYIGeZaFtO/j38EuiV02+91UCGxtWVfTMFFeFBCDgSXHKGQCc
EdPt/tYXYUnhpZ05qdHmHWrUjZYXb+/NZ52GE8I3IXkOPtgZd/N9plQ7rfg2nDKLrMDOAZ5Mglgy
pSAYYXigjdjNjRySeCMvs2UIYVp1KRjedw3aVJ91EoYYYnzjtXaDgb/V6FsBh+zTglYzVnbEk0nS
p15t5YE32I9r4Uimez+uSZ18Og4ZpGl30dYjmBX2xslVDUWiEGYzXEQANCgkoxWMOnznoUu5JfiX
okLyhSFcH/poJI4cOmophWk2CpJoPUYqpoc4IPDUAc8BakMAqKpqQiSo4ndYizfQRaanpunFYC5y
3pqjCj+FiqSuR7X3Fq6UviDXpyPiqWOOk9pgz1NL/k2jlJaVGdiOM/AMh8Oxvgq24ZK/IrVom6SK
F62oueaZKbHL5spkDDzdeieazM5Jg6DuMGbtDxshoFUp016JrSgIz5twAHwOwAmiO0wyAEPWwsrU
RYQmrHFuG1fFJ347KLQVqrFExEomzDlscscsl8nyJRMdDMMhBrASkYDJADCtqZGgsg4qlLWscadC
u0CjQ5Y0MygyFt3jcNPDoZpx0VQ70gqrT8/w4kQmo3izQ1WtXDNzI1dtdiPJJECCgQXEkHOrW9kj
YDrSTCTCtKwOGlwsZ/c9iIEjI8Nq0CxMQgB+7IytdCuoDJcMO84Eh4jMfleex0WpSOMQ5VAxLSO3
/ohSSRmVmE3ENiecW666HbFm/tvUmsg9AqrSZK1zQ4wwfA9wj6/u+x+T1xxcJVoiQkLjKVLizOxM
ieAz6r9HT8gm0BhqatBUUsvKYYNCJRUAY0sv/iPKAIc8M40vR9zNUBXA+wibpH7HAvTTn8QCIuB/
gv5E8N+/3+EjW3Eo0w57dO8hBupe7453IHbITw7+898NJLi/FVCwBBfcQgY1doiwKScaeuueRbiS
CnpsJBKXkNmf2ME9wuVBghuMQQzzZ8EahmGGoZAMPYqjwMtQYmIWUYRw2iFCFeSMSq/jAwxHUD8T
4M9+TIRiEzEoRRrmr4pWJEET+fdEAEDxihfs/uIXtchEMJbRil0s4xfTOEUunnGKZqRhGhNCCnwA
6iL0uB3SPlgz8B1uYg/kCu2MMwAXzg+DWYSh/hb5RieqEY2P9CIKGClHSroRkVgkoxwbiUZFdjKR
kgTlJUeJwys8jnaYYVUAWHWVVVzsHidk1QNHgESsgA92dVhiKHeZxTOGkoK6pGQkK7jJXQoTmMas
4DFByUtmXvKXkmSjIyEZBk6gYmKNgRUitqeflGWvHbM0QawiI49wtiGYvnQmJzXJSUVu0I3L9GL9
kPlMMsZzlNOEpjrFGEUuzrOXXdAWw6axOPDFghWTud2guILLFmSkKoL7YR/QCVB8UpOd1KRo/j6l
eVFlpjOSFtUnO+MJTX4ispko3YI9+pUJ0QGAVTUjIlbkwTcbGOYp+mCaEkf60ZAK05cchSdA0+nP
i9Lzo0Bd50/VycxkMlWkXWAM7l5qlanCIhM+i0VFbKAV2wVinu7caD+j6EQs+nOZnhRlBMc4zBSs
9a1LlecatTjGesJRrknlAiqWpg7INaeAO6zpiWDV0PFNUKxD1UEpzXaRbSWAGn2CBeF0atPLAOhh
huVBDOup2fEJEGjgc59gnYPTGmDOIcjQVmaHUFcfsDV6GGsGoBCx1RGkr7YvyAgLf0Mcjqz2t2ZA
1VaAqIKLWMKrLmgVVBrGCeA61wzhWwGV/gYVldKy4GGHg8YgXfXc7raBh7HgXjIKeTBTRIU40YFI
Eb3L3jQsZUXCMWE8/hM2U7kyjydIb3v3G9x4hDZAFouaROjWvb0Wlr9QYICCFUyCBTNgBA5msAgi
vOAJPxjCF64cySTx0FNgBWMePmAJPUHZs0nYBBnO8AtSTAQKX5jCFnYwhl0MgArX+MSVM14JimOJ
bEKtt8s7hSGphmMMW1gGLB7CiRlsYwkX+cgNfrGUV0s6n/nHv1Bbh2QO3DEmO9nFD/ZylCFM5iXH
OMk3NjOUTyDmEkTYzSq+8YzjDGcVt7nNo3BGM3BKutndrLmVozGYw/zmNbP4y2eOcaLT/rzmKEtZ
xmm2caPlvGg2QzrShL402rhXM1u+9DD4Neho+9bkKVOa0ZJuMJnlfOdMU9rLhEZBqd+85BTTeMyy
hrWiUf3kQUgmu42jDA+5bGJbQ7nWRnbzqll97DDX+NXOjnUK8PzkWhd6zrlONrInXQiaJUO0yzXd
+LaNaEPTGc1MbvazpZ1uaSeb1cbe9qlTrWlcQ/vdvX7EAquyWnKbmtfnXjavHc3oGRec4PA2cqnf
XfBy17nhtnY1gkXhbxjD+MhoVjSOK0xvXc/70te+9qkx/uV/h9zOIp94I+TNcTFv3NkThnOj5f3x
mRc51QeftMgdnvObu1vlpKYzy2gO/nSz5Xtjty56sYuNc6U7/elQj7rUp071qlv96ljPuta3zvWu
e/3rYA+72MdO9rKb/exoT7va1872trv97XCPu9znTve62/3ueJf7KhvAd9zmne4B4HsDVhl4vv/d
7n0nvOIb4AC/H17tAXDA4BVP+cg3vmqrfLwXAi95wXv+83x/wOAx73jNS6EBD3CA6lfP+tav/gEP
KD0HZS+Kytv+9rjP/CMcAPve+/73wO99A8ym+47l/vjIJ3wjHgCB5jO/+RB4fvRhH33nO5/5w5eh
Oxe7BuVvLPngzz0hpB8BCESg/M0/P/rVn37zQx8C2YfBGrlfheLDLyNZIjxtT2B//haw9Z9BAFZy
JYA/EH4GaHsNYE5x5AKv9VpO4ADQd37up34SmH4U6H7Qd3nyV1TzN3/yBEaLdFdCcHu09VC6VRW4
12Et8H8iqFlFdUUjaHu0lX8lODmKN4M2SHl9t4EfyID0xwQCMIHlR4FDuH7sV4EQIAEa+AIemEn2
84RS9EwO2AO5p1urZIMzWHmGx4QvKARTOIU6cHuJ13dkmIN7N3g1qINLuIJPxIFQSFYeOIAwCIY+
EHnmt37v937ol4fmNwEUMHra14N1tUUhCIN0RYdhmIKHcIVpiIDxx4ZweFZuCIKUSEVh9IMxIIM2
+HmBhwiTd4VoqFv4R3iMR3tU/tSDeEWIZhSFgtiGbXgEkTcBRDiLtKh+EkABDqCAc1iIu9iKhtiL
Q7CICJglAjB4CfiJaviI/jeJxvSKbSSFwCSCiHgDCOiJfFeMk5OAxXiDaHiMo7h3a2hBL8iKvuiL
rEiORiAADkABsliLtTgBt5iLNPCG5UiP6IiOQVB4w3gIk4eNCIiLCmiPcFWP27c/dzWNq0J5OFiC
xGiG+UeMWhiOKhCH5FiRhQhWr4iKRsB5EuCOsxiPgDiPFHmRrviL+JiPjPeNB7iOkmeKp3iPzsiL
g6iRlkhWQZCFB2iA6iiRboWRhmiRP5mRNomQVMh4HemR5weSLjmRcTiAJPmL/k65kYyXgAfIeLgY
klxIkMAIk1BZVjYJBAs5OaIolmRZlmapW4zHkwb5kjIZghkpkOUIi5y3jkdJixKglE1AlFKpev14
lvinjhTwhyqofeP4lM84lGmFino5A52Yk+FXjHy5lCyolR84kkAJi5+nehRQl0l5i1MpeEuZA104
BXPZl2J5het4laFpkF1IgHDZTw0IgF1ZlNeIk47JiJ7IkrooB4WXmZq5mYEZmJ3HiUcgm/UHmS2p
kKnZknmJiU+wk6AXndI5nXyXmlj5B4sXnavHiaCpeNOzk8NplVc5mEYwmlEFnsGZnuq5nuy5npK3
m7y5d8k3irbZCJznnteJ/gTG+QX86Hr++Z8A2nn9Bwi3aXv2mY3RiX9Uw4jaKJYN6pdnOaCDsJol
4H2BQHnwU3k5SHzKh6ErQKGmJwPe6QJXKKEhynUm2gIjeqJ3l6Is+qIwGqMyOqM0WqM2eqM4mqM6
uqM82qM++qNQoDZA6l2uwwKpAAOZMwJFagJLKgJNSgRHCgBRGqVD2gVTKqQpQKVGKqVceqUl4KVS
KqRaagRgGgVYKj1n6gda6qVUeqRtmqZOyqVMmqZgWqZOqjZrmqR3OqZuiqV1Cqcq8KQoMKYroKdh
SqiHeqaCKgR/WgOLOqdI+qaI+qSPCgSN6qiKKqZ9eqdhqqSAaqgkwKea/sqpnRqqm1qqduqpeDqq
qAqog8qqWeqqJ4CnXQqrpHqpSJCqL6CrXyqrTNqlrdqrt2qrZEqsMZCnw5qsiLqnwtqsuJqswVqq
zsqqvDqrmcqpbyqtkyqnzeqp0Cqq0pqoqkqnq+qt0Xqs19qp2Zqtv/qp5Pqt75qnkhqvfkqtvmqk
6Xqpp/qq9Wqt8Dqte2qo7vqv4Rqo+Xqq+zqpCguw58qsV1quBeuw9kqq6GqqEout/TqnA2ux0Sqq
EPusqtqxxhqpHKuvEDuocrqsJsuwhLqwIkuxhZquKTuxy3qo3Wqq7AquLxuxO1utMVuyE6uusgqq
EbuyQEuwLBu0mEqx/rhKtKEKrDprtCErtTjbs/dqrgTLpr4qsBs7r+/aqkvqslS7qwf7rzVrszBr
riD7p2HbtUF7ti5AqUrrtFWbqAkLqou6r+KathirtiPrr35rtls7s6/Kt1FrrGL7tlcLuFk7qmdL
qzxrtUkLqZQ7trl6tYtLA3CLrz9Qpk1bs7R6so0bp736sUpbtZYbt7D6uUMLtV87tkmaurHrp9Ca
BHR7uTewuZqLt3P7uA87u+Nat8Iqrxw7vBnrs/iKrOd6u8xqtycrty0ruk26sDn7t1y3uZk7A7pr
sFqAvUGwvbEqd8xbrLmbvbYLvpZqvoxbpezbvu77vvAbv/I7v/Qr/nbEKHj7V79PNxUGUAH++7/+
S5X6C3TJAMAGDMAJOMD8FXgGbAH9e8D/m58KvFrFCMH9+8APjMAgSr+VR3wNAMEWYMAZrMETrAIW
+lIuKgohDML9awEOPMIIXMIoMKD5JzQCUAEWcAE67ML/i8EG4MI8bMAbzL79p5D5uzEtfAF3eZcr
DMAWcIvB2cQV4AAynKGaoInkmUM4/MS4uHoNDMWs978uPMQ+WsQpeMSiIABAbAGCCZk4jMMXIJza
+MFirIz1a3/zaYMI88NrPHr8CMdxLI9V0cBqCb94TIrvqYkC/AgBsMVrHCMfrMNXKQkHbAGFvJZ0
tZaL2XZbRXi5/siXKql/1xgKjbzGLhx/gafEzAk+ppzDFGBOk+mVmzwEGFDLtnzLuIwB1Al6ZLwH
maehqieKGooIq2yfjtzH+rB65nXMLnwBFhCQ5vmVUmDLudXFAaqZlzw9GYqauah/3yiWqtfLvMnM
QBwj/vhS5OzK0IyY59iWuyiUO1DLIkqi6wifeRAj+hfMRuzNxJzNfVDKrWwBqKx7fGzKkrzOcxiJ
lEmI8IwD8pyJEEqWq1TPCyMJiOyXuQPO/swHAG3Qz/wqOdzKOizIPDiIb3iZl5kDubzSLK2Ouwx6
gSnOdIDPjCh+DRnOodAAAZ3DFbBVN6zDOwzEqqyL9FiZMRmU/khNkzbA0kx9ywJgzdfMekq4jLI5
yz9g1SRq0Ss6wxot03iFyQmRw0A91s7sxGQ91hnwhyD6miftzpSp0hrQ1ExtAFCsnkssARmQ13qd
1xRAeyNpA84J1nWo1eBHljiNA9I4m1FVAWfd2I6twxlwAcW8gYVp1O+c1Fh9AhigAZzd2Z792Z9d
AXmN1xmwAaZ92qid2hJgx6eY1DOQ2UhA0yQIoYcN2EKJ1YH9Azr92LwN2WlN0oR5iG2t0G/t0KB9
3MdtAam93Mxt2kooe39t0k8ph9QNgFD4ltO9gDND2GdslrVdAwI53EHZzk8Qeb3N2xmghBLsBpuN
3O7N2crd/tzy7dyXbJlaqYr3/VapiN3YnVgfyt1kCXpl+d0iqZjZ/YSR2NBJwHnn3diRDZB20ADv
/d7xXdrzvdyrDd0EuND9nd+ZbI5unUkvINtpCaB/2c/i/NcgLtxxyQSBRwENDtR5Hcjr7QYfPOHI
XeF7veM8ztc1rtQE+U8oLYAzueJBPss0DZ3TmdEoPkGVbeSWfZJK8OIS0OB6rcS46NVecMMVgOOg
reM9HubqLY6YfJJD3tqY3eFSPuJaPZXHR1X9bM8geJhGTt5ADouQGZhV7thXHsddzNpw0MgH7OUW
EOaGnt5qTebEBJRnbtmIuZUhPs8ozHnIqJBM/tQb3ZNs/mmS0c2LQJiNqbnnZ13X4anlXUDHEJzq
/lvo6X3Xrv7qf/jjQA6TKR2F+Mjobv3VmVjTbk6CGW2Vsq7oj96Bwt3hS9CQ1vib7tl5ZHkHDKzq
qf7Erz7tS6yaCJMlJa7WVch6k0fKZvnSEWoHfwztldye5h7MC5OgVRidtRfKjpnFkICgLy14Ue2f
gD49vVmd807vk22fBmrFJvDvdODUEe2g+87LG+N5fEmdxUics0cDKRwHBY+gEy/R30eKu6yhwR6/
yG6buCc0ObmNVczdBug3x4fGI89/4uc7RpzyUddBLr9aJ/yhph7zCxPxFm3zvzXzM1zzOn/zPx/0
Qj/0/kRf9EZ/9MClvhuj9DtaqcXbAlyrsPLK9Ltbu1A/vnxrsF/LuK6DvjYAsk6HvJE7q66btqk7
BGJ/tNwbt8DavBq7vuQ79kxA9XGgvHerrZ/KrU8vuRY79cHb98drvTertd7Krl+q92hbunAaveE6
vUR79w2ruthrvlHvrlNP9xUb+VXvt6aL99a6sYEb+cC7s6XL95zL+cFq+MJbq2TP+KUvuwh7ulef
9XsfqGVfsJ6L+eVL+5k/ukIbq1sf+qlqtImLtD8r/DQ7tG069jo7uZrP9+hr9887/a0P92rvr34f
sMaL/Dkg/YJr+38Lu7LPs8Sfud7/so9bq5WqvJWL/rhua/yn7/t6W/o3W7zDr7hZX/46kPu1y7yh
i/sgkABAIpJmOaajmq4varKtCLf3nOc2zp+yrkaa+XDGnSvWA7JKNeXpqAsCedbntLnSTrfIb/Tn
lC7L4Sw666xCt2P0e53UetfUs5h7d7eZ6byez5uaV1hhnd8NIl8XllnhH+KjEiTREJFfpdTVXScn
3l+oKGFo4mip6anmKevoalMr66vobCym0ecP3JDjHKgh09hnpXAfmS2ybvKyXnIts+wzdJo0XOq0
XSCUMqFMNkw24O2id6Lv2fa0+jp7u/s7fLw8aWR8Nf18vv4+f7//P7V77wR2AmjwIMKEChcybOjw
/iHEiBInUqxo8SLGjBo3cuzo8SPIkCJHkixp8iTKlCpXsmzp8iXMmDJn0qxp8ya7ADob8OypMwDO
oEKH7uxp9ChPoEOX/hPQwABUAw0ECGD6rijSrEaVWg1FNSvVql1zCKhg9izas1PHMgug9S1Stlmc
Rq1rd6rYrmXT8k1rIK9cUW7hEt4amIUAu33vUmW6ty9ktH8P/yls2edht1ErcOAQuUJdvEEfm/Vc
+mxn033XUs4x+LLlw4kNnIb6WbJUAVxn8jXd+TRntKrRAs7c0wFyBzyRL1euvAFz6MmXN5A7uzZk
2qj5Tp5JmrPn38JRc0CAYHVrANKRd+jQ88ED/p7w4cuPz7ODfegNdjvW7lk7ZL4Fx1dxLjWQVmcI
DAdeaecxSCBlbjkwX3sPONAefg3gl+EDFULXXnLIFfjHAi65VdqCvYV3G38tGZBaggWEB6Nq4v1G
o2ctWiXAhPDh1yGQHV7YYwMWTngkfMk9MGJQJz6IIIrAiZeWjmkscOWVLGQ5xZZbHvQijAUgUICM
qZWZoIIcnEmjBdW1gmWXJWaRpZehwFninVjmA918FvbZY59JhjgocvHZ4mWdIjk5JYoCMsjoaVXO
KScAcU46QqL/gImmWWR25ml5CpK5ZmoIENDmm5TSSakOq46CqKqszlNkoLXaemuf7h0aq0mL/l6A
o2/ABsuBBRQ4IGmrsoqS6UECwGjeb+aNOuqN4JVaAAESOMDkpal6y6Wy8fCJa4UUlkuum7G42msD
FqR2Aby/NmrjjZ1ZUKxyrDBbqZxwYtovwPvGE4AFaQKroHA4jkkAARcYu5++4cJqaZz76pksPzx2
iCHHGALJ8cYdY0gBt3Ym6i+/KWt5saUIQecujdYKm1qxxiqHLMbgVrqyyusKDE8DZCpoHtFpFn00
tg1LYDPEEeu8878p+xwuvydTfdWFInccssdaY3hsMhdjyrOeXZINcEIBOEDBzDNbsDTTOD+dc9V4
oi22PwQTIObRfUubNLwUMK2buhKz6q+r/nhPWufP7bhFgdddbx05BU3vqiziaK9c8dX98EgBzG1z
cAHczOkm99w5UGx31HUDJIAFDE87O5kME5BB6cqdjgyzsErNuusk+s6P2pBHfrzIxqKOhuKJa/47
zwsF8LkE8L4bL+mCR6fTMhYDP/UMiu/DowS2m287vLlPxX33hrfufPiNqzy/PtOvjTz+HRhbssnz
r/6+5lCmEAlRQAIGPOABQWe65fUPgD37HgQNQj3spU9wTNsPAxsIvQdCr2Wq41XriAedAuZPa0u7
WdhA+D8OblB+9XNKBZBzrxlaADlRCQv7mHGn6O2wZQLM2/SaQ6jnrM8dO/Rf5h4osCOG/lCEazNg
CdtjwP1lkG4TA9+/yva8g0wvLFoJCxjDWEWUdDGMZjTjT8aoF+gg8HgTmCIKW3PGOdIRjDYpYx3z
uLv06EBCaysgAgM5xbi1Bo96PKQaQ7IbrqSxkQD4yQzSyEcWvGY9FrykBafjk0TCxJCH1OMkQ5mF
SiLFOYOCCydN1MhVsrKVkhQlLCkJm7f8JCmFTGUsczkCV/KylznUJTCDOUpfEnOVwjwmMndZzGX+
MpnODGYO2fdK1+Dymda8Jjazqc1tcrOb3vwmOMMpznGSs5zmPCc606nOdbKzne5MzzWCGc93fiQc
1ohGOYgxCHHkIxeq2Cc+aMEHfZKD/h/+dGcRGqEKXgADDAfVR0JRcYxbuIKhCR3GPN0RUYVk9CWS
iAIjGBGES4BBG2bgQkFpEAxHNPQXAaHoOWJqDpJS1KQtRSkbBrpSdBgjFvYMKCryaY59/lQeD40G
TH0h00YM1aE9pUNLN1qMSSBVG71gKUEVmtST0iCq6YAqRn361YKUwqJfDas/NvrPrXrVpV2tqU0v
2lOpznWsL42rMVYBUIKWYxN1PQZaBfLRpYp0BzRtBlVBcQ5x/HSpN7XFYP/6ikHoM7F4/UZT2+rW
gAaWpUxFrE3FsFNgYFaraF2rVRtaWExkFq9+vSpXwfpXZ7AhsYsdqV01e4ingta2/rnl7Gxva9jc
RnS3sXVpZ1sRWarq1bhOjW1yPTFb2uLiqQC1hBCce9quble2lnXFNnJxXVhkd7TDoAJsH+tdzaLW
t4q4BmUze9ArlFa630WGPcU7WXBMVaWszYRnw1FZkao1IMvlKXz5K9NFKDSlyMUqbwU6jrBO9hKa
6O5DK6vbjg5knhwWKzMIAlEP2+PDWoWHIKyrV7M+l73cnS5rNwyQ8fZDxHBdCI0NamKydvjAAzWw
ShecUwDjQcBNJfBv6ZnOWuy4vfhtspLZmeN92Li3Ub4ylrOs5S1zucte/jKYwyzmMZO5zGY+M5rT
rOY1s7nNbn4znOMs5znTuc52/r4znvOs5z3zucsM+DOgrcKAPgsF0IYeNKH7bOgRLFokiEbGoacQ
aB1MmgV/TrRGKg0ATW9k0JxmxaEvbelIz4DUm340pi/y6VOg2iGrFsWkNS3qSgd61q1OdUVMLelG
nxrVsn41o0Xd61Jf+tWhJjawh61sZdMa0cW+Na5zretRk5rWm0Y2sJvt61BD+9jBnjayv01tcQe7
18KONka4nYNY2/rR2iY3pYX9a2efO9zjhne8ef3ubxcb3R3x9q7dTW+BEzwL+162seV9bmOb297L
Zja+/S3tequ73AjnNrQvXvCI3/vhCYf3wdfN74xLHCLzNvWzt13xdS9c4RvP/nfHH37vfX+81iQv
+UEo7nKLj9rj9Ta4y1++6nlTu9vtnvnPT23xpOMcISFnt8p1/nKHE13mMW90wgeO9F33PNlNBwjG
sc1rfud77GIfe9gDHvRkA3zkt265178ul7jLfc10r3ua7473M+t9737/O+ADL/jBE77whj884hOv
+MUzvvGOfzzkIy/5yVP+mQdgxuUrb5LZHKDznv886EMv+tGTvvSmPz3qU6/61bO+9a5/PexjL/vZ
yx4q/IOIAQ5gngHQvve+/z3wgy/84RO/+MEfgHkOcHuF6L4Aytc8TgSgewQYQCIGENPyoQ8TAZin
+g0JAPK9r32rXD/zA+T9/vgDg/zsx0MABDB/+tmi+2omQwADEH/85XKAAtDfFgXAf/7p3wAAxAAM
YAC2Bvr1w/UdYHoEAAKw3zQ8IAOmxwLuAwC+AxP1Q78wj500BNO12s2lga/xQ9uhHcqVoMB1xP/t
gwTKw+G0Q+eMDYmwA+awQ9K1HKSVGgl6G8D14MopXEcYgAHOA/flg6zE4Jt04AyuQw2uQ8qNnLl5
mhQSm8hZmtIxWte5WxZaIc9dodKxW8/FGxVuoQjiIBAynTsUAAQiQwK6oOpsDpfQj9iID8vIYNVo
CR7GoarEj90cjtmMDfDAYdnZHCGmXLNVIRYe3Rdq3SKSGxo+m9rhYBjG/lwkFt3A9d0ydF4+qKER
viHUfCIP2eEeeuLObOAnmuLV4EkeniIoiiIe/iErshy9deHO3d0s2lwWTmG54WLAuZ0lrt3Psd0T
apzVwUMRykMAFIA+HKErkqIpxmL4eOIzvqKVQCMzkmIpNiM0TqKtjaEXfqAO7uK1neE4pqCneSHX
VRwQ+iLMocE6SiI6zgMCzIMQLqM0ruIqPuMoRiM/TmMWVeM+3mErgqIqWuMP8Vw3cmMKSlo4fmE5
dt1DiqMuKuQ3Gl0YfpowXuS2TWI+DMAatoImdmI/4mMz7mMT5qE/Qk0qbmM2nmQ2WmMZaqQ3EqLB
NeSwcRpNhhtGduM7/i5kRbJcPOpkQoobJi7D/clDSM7DC2pjPmrjSRakPsrgSpokNWLjKUalHVJk
wzWcD3IhFgolCA7juB1iFP4iOyLkOv6kJXJkFIYgOxzABbJDAS7jQYqPQfphsqCiIMbiNf4Qyxzh
UpYiYIZLWr4bJHKjTaqlVi7mzmGbY3ojs/mk1EHmLrrlOiTlO2BmV1yjOgSkPKBhMKVlPmhmO5Am
U3DmNHhmPIAmMK3caMKfO5jmWLjQqwTmPLBma5rdPMimOvDmBAaGb0JDcP7mWAxnJsImcVKGcSbD
cibnUDSnLUCnc+KEdIIkck6n/F3nZWondlpFdbLCd3anTITnKAwn/hLyIxO2CgzS4HnyjkS0p0LA
p1JuJ1JyZxIOpA6pJw2mpxs2hGo+REp25n1OA3mKQu4JKH52j37yZ2rOp3+SJEQEaIPqyzocZfsN
IQcKZl5q6F5+EGBepUqqJONMjHqO6B4O5j+iZ6xQ5Uu+4gsGjFPu5RziZx2aqIvqYVUKZIrqKBwG
Io/y4Y2m6Ixy5oo2ZRZ4JDIq4xLCIkrqZVbGaM84EF/m6IeGqFQS6ZNOqVQ2ac6oEJWi5JfSjzM6
qYhmKZ2E0CieKIQGEFOWJFamaROy6HnOozzyD1aO5JZmqYqCaZ5qKYQaKZ7uKY3CpJ8KKqGqYkG2
YppWY0ny6UCS/mmhJmif3qmRyqmjRmNgIqqk1uNu2qeVPqqb2qUALeqkjiqJOuPmpCSpvqGl9qmh
WqqmCuIRdY6cooxqQioTzWHvhGqmzGql2iq4+OGQokGBjsIxZuitNmqGHqqj0qpVrqqqXmqYfmqA
suiUxiqrLmgcKquh8qltaiuoRqpVMuu4UiuOZkELymNcNqt+Qmu7tqq5TipLkiqTcis2uuugQimh
uuKqbqufUmrUTKO73mqiAuy/smu+WuumYqg8GACdzkmbSk0+eg9B6iqT4o3F5iVeVitLkiTG1qHG
Mg/jeOypEuQHOSWirOm82uiOxs9dLg6gVsyfmuTJoAH18cMK3GaTfE7Ezg7oZmaBw3oOAvQfW/Rs
RBjtKSCtS4RLMn4k5jEsMtFmUCjtSuxLG/bD1YqnTeieBDmf1t6E7jntOiCAp35tSuyfQnDfABCt
2VKE/a0tQ+zfurYtSThs2fqDw94s3ZrE9aXrQwih84ntDNzt3hrj/lmo205fARof4zau4z4u5Eau
5KpeARYA7wlus0DF5G4u7QEA534u6IZu7Nle4Zau6Z4u6qau6q4u67au674u7Mau7M4u7dau7d4u
7uau7u4u7/au7/4u8Aav8A4v8Rav8R4v8oZECAAAOw==
------=_NextPart_948_C18F_1C25A4E2.F1FFEDC0--




From sip-bounces@ietf.org Sun Apr 08 16:02:53 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HadYj-0004on-2L; Sun, 08 Apr 2007 16:00:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HadYh-0004cR-7j
	for sip@ietf.org; Sun, 08 Apr 2007 16:00:19 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HadYf-0000X4-RY
	for sip@ietf.org; Sun, 08 Apr 2007 16:00:19 -0400
Received: from [192.168.2.104] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l38J6lsh011894
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 8 Apr 2007 14:06:50 -0500
Message-ID: <46194A1A.1020705@softarmor.com>
Date: Sun, 08 Apr 2007 15:01:30 -0500
From: Dean Willis <dean.willis@softarmor.com>
User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Eric Rescorla <ekr@networkresonance.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
References: <4616851D.5070305@softarmor.com>	<20070406174901.D89C45C027@laser.networkresonance.com>	<46172B40.8090107@softarmor.com>	<20070407151244.87A941CC3D@delta.rtfm.com>	<4617E6B8.5070601@softarmor.com>
	<20070407192220.253931CC3D@delta.rtfm.com>
In-Reply-To: <20070407192220.253931CC3D@delta.rtfm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Eric Rescorla wrote:
> At Sat, 07 Apr 2007 13:45:12 -0500,
> Dean Willis wrote:
> 
>>Eric Rescorla wrote:
>>
>>
>>>You give the caller the sips: URI and I think the draft makes clear
>>>that if you have a sips: URI you MUST NOT use SIP w/o TLS. The question
>>>is what a proxy should do if a request comes in without TLS.
>>
>>I'm not finding that. What I'm finding is text that says a user who is 
>>given a sips: URI can deduce a sip: URI from that and use it.
> 
> 
> I don't agree with that interpretation of the text. The fact that
> you *registered* both a SIP URI and a SIPS URI does not mean
> that other users should convert a sips: URI to a SIP one.
> Here's the relevant text from page 7:
> 
>    Although not mandated specifically in [RFC3261], the implication is
>    that a resource described by a SIPS URI can not be "downgraded" to a
>    SIP URI by just changing the scheme, unless it is the "last hop
>    exception" described in Section 3.  This specification clarifies that
>    a resource described by a SIPS URI MUST NOT be "downgraded" to a SIP
>    URI by changing the scheme, or by sending the associated request over
>    a non secure link, except for cases where the "last-hop exception"
>    rule is in effect (in which case the Request-URI would be replaced by
>    a SIP URI).

I believe that paragraph has changed in the current pre-draft to say:

    This specification mandates that a resource described by a SIPS
    Request-URI can not be "downgraded" to a SIP URI when a proxy is
    forwarding a request by changing the scheme, or by sending the
    associated request over a non secure link.  See Section 4.2.

This refers only to a PROXY making the downgrade, not a USER making the 
downgrade.


Section 3.2 Routing says:

    For example, consider the case of a UA that has registered with SIPS
    contact header field.  If a UAC later addresses a request using a SIP
    Request-URI, the proxy will forward the request addressed to a SIP
    Request-URI to the endpoint, as illustrated by message F13 in
    Section 5.3 and in Section 5.4.  The proxy forwards the request to
    the UA using a SIP Request-URI and not the SIPS Request-URI used in
    registration (and it does this by substituting the sip scheme to the
    sips scheme in the registered contact header field binding).  If the
    proxy did not do this, and instead used a SIPS Request-URI, then the
    response (e.g., a 200 to an INVITE) would have to include a SIPS
    contact header field.  That SIPS contact header field would then
    force the other UA to use a SIPS contact header field in any mid-
    dialog request, including the ACK (which wouldn't be possible if that
    UA did not support SIPS).

The preceding says that IF a user converts SIPS to SIP, then the proxies 
will forward the request. This is further supported  in the following:

Section 4.1.2 page 12 says:

    Because registering with a SIPS contact header field implies a
    binding to both a SIPS Contact and a corresponding SIP Contact, a UA
    MUST NOT include both the SIPS and the SIP version of the same
    contact header field in a REGISTER: it MUST only use the SIPS version
    in this case.  Similarly, a UA SHOULD NOT register both a SIP contact
    header field and a SIPS contact header field in separate
    registrations as the SIP contact header field would be superfluous.
    Note however that a UA could register first with a SIP contact header
    field (meaning it does not support SIPS), and later register with a
    SIPS contact header field (meaning it now supports SIPS).

    If a UA wants to ensure that no requests are delivered without using
    TLS on that last hop, the UA MUST use [I-D.ietf-sip-outbound].

If we are in proxyless scenario, then we aren't using outbound, and the 
"last hop" is the UA to UA hop. Since the only way we have in the 
current text  to assure that TLS is used on this last hop is to use 
outbound, and we aren't using outbound, then we have NO WAY to assure 
that this hop is done using TLS.

Later in 4.1.2 we have:

    Location services
    are therefore free to map from SIP to SIPS URIs as appropriate (see
    [RFC3261]/26.4.4).  When Bob registers, it therefore does not really
    matter if he is using a SIP or a SIPS AOR, since they both refer to
    the same user.

All of these, taken together, say to me that it is reasonable for a user 
who is handed a business card with only a SIPS URI on it to guess an 
equivalent SIP URI and use it, and that the infrastructure will route 
this request to the UAS. If that UAS is NOT using "outbound", then the 
last hop may well be traversed without TLS.

Consequently, in the case that (unknown to the orignating user) there 
ARE no proxies (such as a simple UAC-->Location Server(302)--->UAS flow,
the content of the request will be delivered unprotected toward the UAS.
If there is a tap on the Line (aka sniffer), then the conent of that 
request will be revealed.

This turns out to be pretty important in a P2PSIP world, where there 
might be a lot less proxies.

--
Dean




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 08 16:22:07 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HadtW-0007BT-Be; Sun, 08 Apr 2007 16:21:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HadtV-0007BO-9q
	for sip@ietf.org; Sun, 08 Apr 2007 16:21:49 -0400
Received: from [74.95.2.162] (helo=laser.networkresonance.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HadtT-0005ZQ-RW
	for sip@ietf.org; Sun, 08 Apr 2007 16:21:49 -0400
Received: from raman.networkresonance.com (unknown [74.95.2.163])
	by laser.networkresonance.com (Postfix) with ESMTP id 0F2725C027;
	Sun,  8 Apr 2007 13:21:05 -0700 (PDT)
Date: Sun, 08 Apr 2007 13:22:29 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
In-Reply-To: <46194A1A.1020705@softarmor.com>
References: <4616851D.5070305@softarmor.com>
	<20070406174901.D89C45C027@laser.networkresonance.com>
	<46172B40.8090107@softarmor.com>
	<20070407151244.87A941CC3D@delta.rtfm.com>
	<4617E6B8.5070601@softarmor.com>
	<20070407192220.253931CC3D@delta.rtfm.com>
	<46194A1A.1020705@softarmor.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20070408202105.0F2725C027@laser.networkresonance.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

At Sun, 08 Apr 2007 15:01:30 -0500,
Dean Willis wrote:
> Eric Rescorla wrote:

> Section 3.2 Routing says:
> 
>     For example, consider the case of a UA that has registered with SIPS
>     contact header field.  If a UAC later addresses a request using a SIP
>     Request-URI, the proxy will forward the request addressed to a SIP
>     Request-URI to the endpoint, as illustrated by message F13 in
>     Section 5.3 and in Section 5.4.  The proxy forwards the request to
>     the UA using a SIP Request-URI and not the SIPS Request-URI used in
>     registration (and it does this by substituting the sip scheme to the
>     sips scheme in the registered contact header field binding).  If the
>     proxy did not do this, and instead used a SIPS Request-URI, then the
>     response (e.g., a 200 to an INVITE) would have to include a SIPS
>     contact header field.  That SIPS contact header field would then
>     force the other UA to use a SIPS contact header field in any mid-
>     dialog request, including the ACK (which wouldn't be possible if that
>     UA did not support SIPS).
> 
> The preceding says that IF a user converts SIPS to SIP, then the proxies 
> will forward the request.

No, it doesn't, since it's quite possible the user was GIVEN a 
SIP URI.



 This is further supported  in the following:
> 
> Section 4.1.2 page 12 says:
> 
>     Because registering with a SIPS contact header field implies a
>     binding to both a SIPS Contact and a corresponding SIP Contact, a UA
>     MUST NOT include both the SIPS and the SIP version of the same
>     contact header field in a REGISTER: it MUST only use the SIPS version
>     in this case.  Similarly, a UA SHOULD NOT register both a SIP contact
>     header field and a SIPS contact header field in separate
>     registrations as the SIP contact header field would be superfluous.
>     Note however that a UA could register first with a SIP contact header
>     field (meaning it does not support SIPS), and later register with a
>     SIPS contact header field (meaning it now supports SIPS).
> 
>     If a UA wants to ensure that no requests are delivered without using
>     TLS on that last hop, the UA MUST use [I-D.ietf-sip-outbound].
> 
> If we are in proxyless scenario, then we aren't using outbound, and the 
> "last hop" is the UA to UA hop. Since the only way we have in the 
> current text  to assure that TLS is used on this last hop is to use 
> outbound, and we aren't using outbound, then we have NO WAY to assure 
> that this hop is done using TLS.

And as I've pointed out several times now, the only TECHNICAL way
to do so is to tell the peer to use TLS.


> Later in 4.1.2 we have:
> 
>     Location services
>     are therefore free to map from SIP to SIPS URIs as appropriate (see
>     [RFC3261]/26.4.4).  When Bob registers, it therefore does not really
>     matter if he is using a SIP or a SIPS AOR, since they both refer to
>     the same user.
> 
> All of these, taken together, say to me that it is reasonable for a user 
> who is handed a business card with only a SIPS URI on it to guess an 
> equivalent SIP URI and use it, and that the infrastructure will route 
> this request to the UAS. If that UAS is NOT using "outbound", then the 
> last hop may well be traversed without TLS.

Well, I don't agree with this interpretation, but luckily since
we're writing the spec rather than interpretating it, we don't
have to engage in a lot of exegesis. I assert that if you're
given only SIPS URI you MUST NOT attempt to map it to a SIP
URI. Is there anyone who disagrees with this? If not, then
why don't you propose some language that you believe would make
this clear.

-Ekr


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 08 20:17:08 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HahXg-0007eR-Sr; Sun, 08 Apr 2007 20:15:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HahXf-0007eF-Cf
	for sip@ietf.org; Sun, 08 Apr 2007 20:15:31 -0400
Received: from alnrmhc16.comcast.net ([206.18.177.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HahXd-0004lG-Ay
	for sip@ietf.org; Sun, 08 Apr 2007 20:15:30 -0400
Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42])
	by comcast.net (alnrmhc16) with ESMTP
	id <20070409001528b1600hl9q1e>; Mon, 9 Apr 2007 00:15:28 +0000
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l390FRLv021200
	for <sip@ietf.org>; Sun, 8 Apr 2007 20:15:27 -0400
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l390FRA0021196;
	Sun, 8 Apr 2007 20:15:27 -0400
Date: Sun, 8 Apr 2007 20:15:27 -0400
Message-Id: <200704090015.l390FRA0021196@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Subject: [Sip] Tying up a loose end on GRUU
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I don't know if others are concerned, but I want to take one last look
at the problem Michael Procter raised.  (See, I spelled it right that
time, Michael!)

Conceptually, the problem is that a GRUU isn't just a URI that gets a
request to the proper UA, but using it as a request-URI allows the
response to return to the UAC, and the route-set constructed thereby
to work for maintaining a dialog.  That's what we *really* mean by
"routes to the proper UA".

But given that we now have a more rigorous statement of the problem, I
think that we can be assured that the solution we've identified works
reliably.  Viz., that whenever there is an addressability or
reachability or name interpretation discontinuity between the incoming
hop that a request takes to a SIP proxy, and the outgoing hop to which
it is forwarded, the proxy must record-route itself (and perhaps
double record-route itself).  It is clear that this is necessary
because the proxy cannot know what the UAS contact URI (or the next
record-route) will be, as it is processing the request, not the
response.

The exception to this rule is if the proxy is able to reliably predict
what the UAS contact or next record-route will be, and to determine
that it will have no reachability problems.  But except in closed
systems where all behaviors are centrally controlled, this is never
possible.

Dale

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 09 00:09:46 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hal9k-0000hT-Dw; Mon, 09 Apr 2007 00:07:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hal9j-0000dh-Hg
	for sip@ietf.org; Mon, 09 Apr 2007 00:07:03 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hal9i-0007IU-5v
	for sip@ietf.org; Mon, 09 Apr 2007 00:07:03 -0400
Received: from [192.168.2.104] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l393DW6v013152
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 8 Apr 2007 22:13:32 -0500
Message-ID: <4619BC2F.8010404@softarmor.com>
Date: Sun, 08 Apr 2007 23:08:15 -0500
From: Dean Willis <dean.willis@softarmor.com>
User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Eric Rescorla <ekr@networkresonance.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
References: <4616851D.5070305@softarmor.com>	<20070406174901.D89C45C027@laser.networkresonance.com>	<46172B40.8090107@softarmor.com>	<20070407151244.87A941CC3D@delta.rtfm.com>	<4617E6B8.5070601@softarmor.com>	<20070407192220.253931CC3D@delta.rtfm.com>	<46194A1A.1020705@softarmor.com>
	<20070408202105.0F2725C027@laser.networkresonance.com>
In-Reply-To: <20070408202105.0F2725C027@laser.networkresonance.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Eric Rescorla wrote:
> 
> Well, I don't agree with this interpretation, but luckily since
> we're writing the spec rather than interpretating it, we don't
> have to engage in a lot of exegesis. I assert that if you're
> given only SIPS URI you MUST NOT attempt to map it to a SIP
> URI. Is there anyone who disagrees with this? If not, then
> why don't you propose some language that you believe would make
> this clear.

I agree!

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 09 05:41:46 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HaqKn-0004Qc-15; Mon, 09 Apr 2007 05:38:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HaqKm-0004Q7-06
	for sip@ietf.org; Mon, 09 Apr 2007 05:38:48 -0400
Received: from ihemail2.lucent.com ([135.245.0.35])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaqKd-0005Hv-1M
	for sip@ietf.org; Mon, 09 Apr 2007 05:38:47 -0400
Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2])
	by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l399caIr025106
	for <sip@ietf.org>; Mon, 9 Apr 2007 04:38:36 -0500 (CDT)
Received: from cnexp02.bj.lucent.com ([135.252.8.66]) by
	ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 9 Apr 2007 04:38:36 -0500
Received: from CNEXC1U03.BJ.LUCENT.COM ([135.252.8.26]) by
	cnexp02.bj.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 9 Apr 2007 17:38:32 +0800
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 9 Apr 2007 17:38:32 +0800
Message-ID: <094846246BAA514DA99E796AE4E5BAAB05D378@CNEXC1U03.BJ.LUCENT.COM>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [HELP] How ISDN subscriber Register to SIP Server
Thread-Index: Acd6is+3tPdF/E1WSh+kxjRrEuPdzA==
From: "Ding, Zheng \(Derrick\)" <dingzheng@alcatel-lucent.com>
To: <sip@ietf.org>
X-OriginalArrivalTime: 09 Apr 2007 09:38:32.0561 (UTC)
	FILETIME=[D677F610:01C77A8A]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Subject: [Sip] [HELP] How ISDN subscriber Register to SIP Server
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi,=20

I have a question here:

For several ISDN subscribers under one NT,  How they register to SIP =
Server

I think:

1. For each ISDN subscriber, register message should be like several To =
URL with its unique contact URL, which means several logic SIP/TEL URL =
now bind with the physical eqquipment(Phone or PC or else)

2. If those ISDN subscribers share the same default telephone number. =
now a phone outside calls the number(ISDN subscribers are callee), is it =
possible to distinguish them or not from caller side?  I hear of =
sub-address may be used? how to use it?

Thanks

If you share me the call flow, That will be more helpful.=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 09 08:42:08 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hat9s-00076W-0c; Mon, 09 Apr 2007 08:39:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hat9r-00076O-2b
	for sip@ietf.org; Mon, 09 Apr 2007 08:39:43 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hat9p-0005Ww-Oj
	for sip@ietf.org; Mon, 09 Apr 2007 08:39:43 -0400
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 09 Apr 2007 08:39:43 -0400
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l39Cdf6b015272; 
	Mon, 9 Apr 2007 08:39:41 -0400
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 l39CdYlQ008118; 
	Mon, 9 Apr 2007 12:39:41 GMT
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.1830); 
	Mon, 9 Apr 2007 08:39:37 -0400
Received: from [192.168.1.104] ([10.86.240.156]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 9 Apr 2007 08:39:37 -0400
Message-ID: <461A3409.1010506@cisco.com>
Date: Mon, 09 Apr 2007 08:39:37 -0400
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: Dale.Worley@comcast.net
Subject: Re: [Sip] One remaining GRUU issue: GRUUs for non-GRUU UA
References: <460A825C.4050902@cisco.com>	<200703282212.l2SMCBEL002086@dragon.ariadne.com>	<460BC690.1060802@cisco.com>
	<460D5064.5010004@cisco.com>
	<200704021952.l32JqI0w008754@dragon.ariadne.com>
In-Reply-To: <200704021952.l32JqI0w008754@dragon.ariadne.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Apr 2007 12:39:37.0534 (UTC)
	FILETIME=[227F45E0:01C77AA4]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1973; t=1176122381;
	x=1176986381; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jdrosen@cisco.com;
	z=From:=20Jonathan=20Rosenberg=20<jdrosen@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20One=20remaining=20GRUU=20issue=3A=20GRUUs=20f
	or=20non-GRUU=20UA |Sender:=20 |To:=20Dale.Worley@comcast.net;
	bh=cEnfz888Azv9YNwp3fSXQubJ/9m54G8LmW8YpC7usww=;
	b=0dQyxrJE1g4gl7kD1XMGhr0UP2s3o+Qud6Sg1fqUBsS+LQfRGdjT1pnIO6PVfjA5qePFsYe4
	v9nEDqCCYs7EeMETYVj3BICXRtweL2h5iyvm+6EzTsPPZDfxhHEuTTvU;
Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Dale,

In a previous note, I walked through the case of an entity sending a 
request to a GRUU, when its UA didn't support it. There were no problems 
with mid-dialog signaling in this case, excepting the record-route 
exception clarification. If you have a concern, please be specific.

-Jonathan R.

Dale.Worley@comcast.net wrote:
>    From: Paul Kyzivat <pkyzivat@cisco.com>
> 
>    Jonathan Rosenberg wrote:
>    > Thanks for chiming in Dale.
>    > 
>    > So, so far I have three folks saying its a feature (myself, Dale, Peter) 
>    > and Michael saying its a bug but he is willing to drop the issue. I'll 
>    > give people another day or so, but unless anyone pipes up I think we can 
>    > close this issue.
> 
>    Well, it got the way it is because of me, and I stand by it.
> 
> After reading and discussing Michael's question, I'm not sure that
> we've completely examined it.  We now understand that the introduction
> of GRUU does not allow proxies to refrain from record-routing in
> circumstances where they would have had to in the past.  With that
> understood, are we assured that Michael's problem cannot arise in
> situations where it does not arise without GRUU?  Viz., an apparently
> usable URI with which a dialog can be started but cannot be continued.
> 
> Dale
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 

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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 09 08:42:09 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HatCD-0000DL-Nh; Mon, 09 Apr 2007 08:42:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HatCC-0000B4-28
	for sip@ietf.org; Mon, 09 Apr 2007 08:42:08 -0400
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HatC9-00066V-P9
	for sip@ietf.org; Mon, 09 Apr 2007 08:42:08 -0400
Received: from sj-dkim-7.cisco.com ([171.68.10.88])
	by sj-iport-4.cisco.com with ESMTP; 09 Apr 2007 05:42:05 -0700
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
	by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l39Cg5Up014175; 
	Mon, 9 Apr 2007 05:42:05 -0700
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l39Cg4wn024627;
	Mon, 9 Apr 2007 12:42:05 GMT
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.1830); 
	Mon, 9 Apr 2007 08:41:45 -0400
Received: from [192.168.1.104] ([10.86.240.156]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 9 Apr 2007 08:41:45 -0400
Message-ID: <461A3488.3000903@cisco.com>
Date: Mon, 09 Apr 2007 08:41:44 -0400
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: Dale.Worley@comcast.net
Subject: Re: [Sip] Tying up a loose end on GRUU
References: <200704090015.l390FRA0021196@dragon.ariadne.com>
In-Reply-To: <200704090015.l390FRA0021196@dragon.ariadne.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Apr 2007 12:41:45.0368 (UTC)
	FILETIME=[6EB13180:01C77AA4]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2284; t=1176122525;
	x=1176986525; c=relaxed/simple; s=sjdkim7002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jdrosen@cisco.com;
	z=From:=20Jonathan=20Rosenberg=20<jdrosen@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20Tying=20up=20a=20loose=20end=20on=20GRUU
	|Sender:=20; bh=VdUnD/gdKPzqXenv71ZQhTQfkh0yaxCR58iCNBqKoF0=;
	b=Mn/xQs3JqfdJFpUzaHXcS/DAchgYsrpDhn+0VBlBsP8BjBkjor8bLvmnXlcrZYrl3FSqX3FC
	1mFiaEXOgMzP4SA8DQuz9UMnI3ipwqBXT9BkURr+BYILHMeEUsqCpbQL;
Authentication-Results: sj-dkim-7; header.From=jdrosen@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim7002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I think we are covered along these lines in the GRUU spec.

I'm going to submit an update now, so we can move things along.

Thanks,
Jonathan R.

Dale.Worley@comcast.net wrote:

> I don't know if others are concerned, but I want to take one last look
> at the problem Michael Procter raised.  (See, I spelled it right that
> time, Michael!)
> 
> Conceptually, the problem is that a GRUU isn't just a URI that gets a
> request to the proper UA, but using it as a request-URI allows the
> response to return to the UAC, and the route-set constructed thereby
> to work for maintaining a dialog.  That's what we *really* mean by
> "routes to the proper UA".
> 
> But given that we now have a more rigorous statement of the problem, I
> think that we can be assured that the solution we've identified works
> reliably.  Viz., that whenever there is an addressability or
> reachability or name interpretation discontinuity between the incoming
> hop that a request takes to a SIP proxy, and the outgoing hop to which
> it is forwarded, the proxy must record-route itself (and perhaps
> double record-route itself).  It is clear that this is necessary
> because the proxy cannot know what the UAS contact URI (or the next
> record-route) will be, as it is processing the request, not the
> response.
> 
> The exception to this rule is if the proxy is able to reliably predict
> what the UAS contact or next record-route will be, and to determine
> that it will have no reachability problems.  But except in closed
> systems where all behaviors are centrally controlled, this is never
> possible.
> 
> Dale
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 

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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 09 08:54:57 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HatOJ-0005q9-4i; Mon, 09 Apr 2007 08:54:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HatOH-0005q4-2h
	for sip@ietf.org; Mon, 09 Apr 2007 08:54:37 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HatOE-0008Gy-Od
	for sip@ietf.org; Mon, 09 Apr 2007 08:54:37 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-2.cisco.com with ESMTP; 09 Apr 2007 08:54:34 -0400
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l39CsYC1026711; 
	Mon, 9 Apr 2007 08:54:34 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l39CsYGd029153; 
	Mon, 9 Apr 2007 12:54:34 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 9 Apr 2007 08:54:34 -0400
Received: from [192.168.1.104] ([10.86.243.71]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 9 Apr 2007 08:54:33 -0400
Message-ID: <461A3789.9090704@cisco.com>
Date: Mon, 09 Apr 2007 08:54:33 -0400
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: Dale.Worley@comcast.net
Subject: Re: [Sip] GRUU text around modification of URI parameters
References: <460BC917.5060600@cisco.com>	<200703291757.l2THvMl1024244@dragon.ariadne.com>	<460C2B58.9060505@cisco.com>
	<200703302235.l2UMZoac019910@dragon.ariadne.com>
In-Reply-To: <200703302235.l2UMZoac019910@dragon.ariadne.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Apr 2007 12:54:33.0981 (UTC)
	FILETIME=[38D23AD0:01C77AA6]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1589; t=1176123274;
	x=1176987274; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jdrosen@cisco.com;
	z=From:=20Jonathan=20Rosenberg=20<jdrosen@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20GRUU=20text=20around=20modification=20of=20UR
	I=20parameters |Sender:=20 |To:=20Dale.Worley@comcast.net;
	bh=4YU1MdxdgNTh6Zj3nUnadfUJIxYJGd5uhZ8y4OH9Kc4=;
	b=KZ9Aoqal92uN5v04mXiy/WMp0XAEM3oYeWLtxgD0qumadZyhJf1vOGS+AHhveOYl7zAu/7gu
	sh7xw0rr/7ZdRM0wUMZjO3WF6bSmKzzkoKfwMC4uWGHLxLSBOyVRfQ98;
Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I think the default for ones it doesn't recognize is to treat them 
opaquely. I added a sentence along those lines.

-Jonathan R.

Dale.Worley@comcast.net wrote:

>    From: Jonathan Rosenberg <jdrosen@cisco.com>
> 
>    At the moment I'd say there are no parameters that are usefully 
>    modifiable by a client. However I think its easier if the text be 
>    explicit both ways - saying what you can and cannot modify. I'm fine to 
>    add a sentence which further notes that the other URI parameters just 
>    aren't useful to manipulate.
> 
> What I'm looking for is "default" guidance -- If a device sees a URI
> parameter that it doesn't recognize, should the general policy be to
> treat it opaquely?  I think that we're getting muddled by not having
> an overall philosophy.  Once we do that, the particular deviations
> required within GRUU will probably be small, and they will be
> "obvious".
> 
> Dale
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 

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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 09 09:12:43 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HatfW-0007pa-9v; Mon, 09 Apr 2007 09:12:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HatfU-0007pU-Ja
	for sip@ietf.org; Mon, 09 Apr 2007 09:12:24 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HatfT-0003Ck-9B
	for sip@ietf.org; Mon, 09 Apr 2007 09:12:24 -0400
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-2.cisco.com with ESMTP; 09 Apr 2007 09:12:23 -0400
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l39DCNwj027318; 
	Mon, 9 Apr 2007 09:12:23 -0400
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 l39DAklc015947; 
	Mon, 9 Apr 2007 13:12:16 GMT
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.1830); 
	Mon, 9 Apr 2007 09:12:11 -0400
Received: from [161.44.174.118] ([161.44.174.118]) by
	xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 9 Apr 2007 09:12:11 -0400
Message-ID: <461A3BAB.7000207@cisco.com>
Date: Mon, 09 Apr 2007 09:12:11 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
References: <4616851D.5070305@softarmor.com>	<20070406174901.D89C45C027@laser.networkresonance.com>	<46172B40.8090107@softarmor.com>	<20070407151244.87A941CC3D@delta.rtfm.com>	<4617E6B8.5070601@softarmor.com>	<20070407192220.253931CC3D@delta.rtfm.com>
	<46194A1A.1020705@softarmor.com>
In-Reply-To: <46194A1A.1020705@softarmor.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Apr 2007 13:12:11.0510 (UTC)
	FILETIME=[AF285960:01C77AA8]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1934; t=1176124343;
	x=1176988343; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20SIPS=20question=3A=20How=20to=20prevent=20pla
	intext=20requests=20from=20being=0A=20delivered=20to=20a=20UA
	|Sender:=20 |To:=20Dean=20Willis=20<dean.willis@softarmor.com>;
	bh=yPPioF7Rv0xpa3tIk1VRIBtAcKPEbtubH0gIsuLZQ1Q=;
	b=hlbLDnVr6UC8/g4rE2Yw/jOXdQr3eZuvDmOtdIKjFCqDMqdm9v+W1pqGl8Ya4XquNhs3Nq/E
	j/Gye2wSfQz3b5f/tVSQqM3RIMVZ22vKL9f6W5MeKK5uog737ubddR7h;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org



Dean Willis wrote:

> All of these, taken together, say to me that it is reasonable for a user 
> who is handed a business card with only a SIPS URI on it to guess an 
> equivalent SIP URI and use it, and that the infrastructure will route 
> this request to the UAS. If that UAS is NOT using "outbound", then the 
> last hop may well be traversed without TLS.

> Consequently, in the case that (unknown to the orignating user) there 
> ARE no proxies (such as a simple UAC-->Location Server(302)--->UAS flow,
> the content of the request will be delivered unprotected toward the UAS.
> If there is a tap on the Line (aka sniffer), then the conent of that 
> request will be revealed.

If there are no proxies, then the message won't be put on the wire until 
the connection has been established. If the UAS doesn't want to receive 
messages using TCP alone, then it can construct its DNS entry to 
indicate that it only accepts TLS.

I guess this could be a problem if the UAS doesn't use an FQDN as its 
contact address.

Perhaps this points up a in what we mean by downgrading. When talking 
about a proxy-registrar->UAS connection, what we have meant, I think, is 
that an incoming sip request can be sent over tls for the last hop, 
thereby allowing a single connection to be used for incoming calls that 
are either sip or sips. That is quite different from using a sips URI to 
establish a non-TLS connection to the target.

	Paul

> This turns out to be pretty important in a P2PSIP world, where there 
> might be a lot less proxies.
> 
> -- 
> Dean
> 
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 09 09:45:02 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hau9S-0001XG-5O; Mon, 09 Apr 2007 09:43:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hau9P-0001WM-R0
	for sip@ietf.org; Mon, 09 Apr 2007 09:43:19 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hau9O-0007mP-J7
	for sip@ietf.org; Mon, 09 Apr 2007 09:43:19 -0400
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 09 Apr 2007 09:43:20 -0400
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l39DhIU8009688
	for <sip@ietf.org>; Mon, 9 Apr 2007 09:43:18 -0400
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 l39DhDGh012948
	for <sip@ietf.org>; Mon, 9 Apr 2007 13:43:18 GMT
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.1830); 
	Mon, 9 Apr 2007 09:42:54 -0400
Received: from [192.168.1.104] ([10.86.243.71]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 9 Apr 2007 09:42:53 -0400
Message-ID: <461A42DD.5060205@cisco.com>
Date: Mon, 09 Apr 2007 09:42:53 -0400
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: IETF SIP List <sip@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Apr 2007 13:42:53.0810 (UTC)
	FILETIME=[F9410520:01C77AAC]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=694; t=1176126198;
	x=1176990198; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jdrosen@cisco.com;
	z=From:=20Jonathan=20Rosenberg=20<jdrosen@cisco.com>
	|Subject:=20GRUU-13=20submitted |Sender:=20
	|To:=20IETF=20SIP=20List=20<sip@ietf.org>;
	bh=WnImL5jUX557jHHY/zzCICVkmJXCJsnUoYyW3YaG46s=;
	b=OPKj/0fLSHJy0gssQ0HE2D8zumK7JKAUzC0fOEzSHiDjsH0muIUKZEkqIsZrsFr/7LqdqRcC
	BvwD7L+tJfLNMjB17uwWAI2tj+y90bOw7cR9/7gn4AOjkSf4UV2VrS4C;
Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Subject: [Sip] GRUU-13 submitted
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I just submitted GRUU-13 to the archives. Until it appears:
http://www.jdrosen.net/papers/draft-ietf-sip-gruu-13.txt

The main changes were to update the recommended algorithm on GRUU 
construction based on ekr's proposal, the record-route clarification, 
and the clarification on what it means to be opaque.

I believe we are finally ready to go.

-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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 09 10:41:18 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hav39-0007ea-Ss; Mon, 09 Apr 2007 10:40:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hav38-0007eV-71
	for sip@ietf.org; Mon, 09 Apr 2007 10:40:54 -0400
Received: from rwcrmhc14.comcast.net ([216.148.227.154])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hav36-0003kz-W0
	for sip@ietf.org; Mon, 09 Apr 2007 10:40:54 -0400
Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42])
	by comcast.net (rwcrmhc14) with ESMTP
	id <20070409144047m1400iqmaoe>; Mon, 9 Apr 2007 14:40:52 +0000
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l39EekLv019738
	for <sip@ietf.org>; Mon, 9 Apr 2007 10:40:46 -0400
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l39Eek6g019734;
	Mon, 9 Apr 2007 10:40:46 -0400
Date: Mon, 9 Apr 2007 10:40:46 -0400
Message-Id: <200704091440.l39Eek6g019734@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <461A3789.9090704@cisco.com> (jdrosen@cisco.com)
Subject: Re: [Sip] GRUU text around modification of URI parameters
References: <460BC917.5060600@cisco.com>	<200703291757.l2THvMl1024244@dragon.ariadne.com>	<460C2B58.9060505@cisco.com>
	<200703302235.l2UMZoac019910@dragon.ariadne.com>
	<461A3789.9090704@cisco.com>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

   From: Jonathan Rosenberg <jdrosen@cisco.com>

   I think the default for [URI parameters that a device] doesn't
   recognize is to treat them opaquely. I added a sentence along those
   lines.

Yes, that seems like the best policy.

Dale

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 09 10:45:25 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hav5x-0000Dy-Jm; Mon, 09 Apr 2007 10:43:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hav5u-0000Do-St
	for sip@ietf.org; Mon, 09 Apr 2007 10:43:46 -0400
Received: from rwcrmhc14.comcast.net ([216.148.227.154])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hav5t-0004U0-Kx
	for sip@ietf.org; Mon, 09 Apr 2007 10:43:46 -0400
Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42])
	by comcast.net (rwcrmhc14) with ESMTP
	id <20070409144344m1400ilhste>; Mon, 9 Apr 2007 14:43:44 +0000
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l39EhhLv019950
	for <sip@ietf.org>; Mon, 9 Apr 2007 10:43:43 -0400
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l39Ehh9S019946;
	Mon, 9 Apr 2007 10:43:43 -0400
Date: Mon, 9 Apr 2007 10:43:43 -0400
Message-Id: <200704091443.l39Ehh9S019946@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <461A3409.1010506@cisco.com> (jdrosen@cisco.com)
Subject: Re: [Sip] One remaining GRUU issue: GRUUs for non-GRUU UA
References: <460A825C.4050902@cisco.com>	<200703282212.l2SMCBEL002086@dragon.ariadne.com>	<460BC690.1060802@cisco.com>
	<460D5064.5010004@cisco.com>
	<200704021952.l32JqI0w008754@dragon.ariadne.com>
	<461A3409.1010506@cisco.com>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

   From: Jonathan Rosenberg <jdrosen@cisco.com>

   In a previous note, I walked through the case of an entity sending a 
   request to a GRUU, when its UA didn't support it. There were no problems 
   with mid-dialog signaling in this case, excepting the record-route 
   exception clarification. If you have a concern, please be specific.

My concern was that I wasn't sure we had vetted the solution quite
carefully enough.  Since I came up with what appeared to me to be a
more rigorous characterization of the properties we wished the system
to have, and then used that characterization to show that the proposed
solution does indeed work, I wanted to present it to the assembled
masses.

Dale

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 09 12:01:29 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HawHz-0000K8-7v; Mon, 09 Apr 2007 12:00:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HawHw-0000Hg-K1
	for sip@ietf.org; Mon, 09 Apr 2007 12:00:16 -0400
Received: from 18-116.252-81.static-ip.oleane.fr ([81.252.116.18]
	helo=mail.softdom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HawHv-0002w8-7u for sip@ietf.org; Mon, 09 Apr 2007 12:00:16 -0400
Received: from ([156.154.16.145])
	by mail.softdom.com (Merak 8.9.1) with SMTP id OUK62529
	for <sip@ietf.org>; Mon, 09 Apr 2007 18:01:29 +0200
Date: Mon, 09 Apr 2007 18:01:29 +0200
From: Francois.plagnard <francois.plagnard@netbricks.net>
To: <sip@ietf.org>
Message-Id: <914985006@mail.softdom.com>
Content-Type: text/plain; charset="utf-8"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea
Subject: [Sip] Re: Sip Digest, Vol 36, Issue 11
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I'm out office until April 15th.

Best regards,

Francois Plagnard.


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 09 15:52:16 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hazt8-0004la-MA; Mon, 09 Apr 2007 15:50:54 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hazsn-0004fQ-MD; Mon, 09 Apr 2007 15:50:33 -0400
Received: from ns4.neustar.com ([156.154.24.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1Hazsn-0000aG-3H; Mon, 09 Apr 2007 15:50:33 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 028852ACA5;
	Mon,  9 Apr 2007 19:50:03 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1HazsI-0005cc-Oo; Mon, 09 Apr 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1HazsI-0005cc-Oo@stiedprstage1.ietf.org>
Date: Mon, 09 Apr 2007 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: sip@ietf.org
Subject: [Sip] I-D ACTION:draft-ietf-sip-gruu-12.txt 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-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 Session Initiation Protocol Working Group of the IETF.

	Title		: Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)
	Author(s)	: J. Rosenberg, et al.
	Filename	: draft-ietf-sip-gruu-12.txt
	Pages		: 40
	Date		: 2007-3-8
	
Several applications of the Session Initiation Protocol (SIP) require
   a user agent (UA) to construct and distribute a URI that can be used
   by anyone on the Internet to route a call to that specific UA
   instance.  A URI that routes to a specific UA instance is called a
   Globally Routable UA URI (GRUU).  This document describes an
   extension to SIP for obtaining a GRUU from a registrar and for
   communicating a GRUU to a peer within a dialog.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-12.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-sip-gruu-12.txt".

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

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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-gruu-12.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: <2007-4-9111216.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-gruu-12.txt

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

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


--OtherAccess--

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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--NextPart--




From sip-bounces@ietf.org Mon Apr 09 17:13:18 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hb19f-00051C-H1; Mon, 09 Apr 2007 17:12:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb19e-00050j-Mi
	for sip@ietf.org; Mon, 09 Apr 2007 17:12:02 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb19c-0001Lj-DQ
	for sip@ietf.org; Mon, 09 Apr 2007 17:12:02 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l39LBvj05487; Mon, 9 Apr 2007 21:11:57 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Mon, 9 Apr 2007 16:11:41 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>
In-Reply-To: <20070408202105.0F2725C027@laser.networkresonance.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
thread-index: Acd6G94unf2Z3uorR1S7fM8l8ceTgwAz6V3A
References: <4616851D.5070305@softarmor.com>
	<20070406174901.D89C45C027@laser.networkresonance.com>
	<46172B40.8090107@softarmor.com>
	<20070407151244.87A941CC3D@delta.rtfm.com>
	<4617E6B8.5070601@softarmor.com>
	<20070407192220.253931CC3D@delta.rtfm.com>
	<46194A1A.1020705@softarmor.com>
	<20070408202105.0F2725C027@laser.networkresonance.com>
From: "Francois Audet" <audet@nortel.com>
To: "Eric Rescorla" <ekr@networkresonance.com>,
	"Dean Willis" <dean.willis@softarmor.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

=20

> -----Original Message-----
> From: Eric Rescorla [mailto:ekr@networkresonance.com]=20
> Sent: Sunday, April 08, 2007 13:22
> To: Dean Willis
> Cc: sip@ietf.org
> Subject: Re: [Sip] SIPS question: How to prevent plaintext=20
> requests from being delivered to a UA
>=20
> > All of these, taken together, say to me that it is=20
> reasonable for a user=20
> > who is handed a business card with only a SIPS URI on it to=20
> guess an=20
> > equivalent SIP URI and use it, and that the infrastructure=20
> will route=20
> > this request to the UAS. If that UAS is NOT using=20
> "outbound", then the=20
> > last hop may well be traversed without TLS.
>=20
> Well, I don't agree with this interpretation, but luckily since
> we're writing the spec rather than interpretating it, we don't
> have to engage in a lot of exegesis. I assert that if you're
> given only SIPS URI you MUST NOT attempt to map it to a SIP
> URI. Is there anyone who disagrees with this? If not, then
> why don't you propose some language that you believe would make
> this clear.

I agree with Eric.=20

I will clarify.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 10 12:01:42 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbIli-0000A8-Qq; Tue, 10 Apr 2007 12:00:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbIlY-0008MC-07
	for sip@ietf.org; Tue, 10 Apr 2007 12:00:20 -0400
Received: from 18-116.252-81.static-ip.oleane.fr ([81.252.116.18]
	helo=mail.softdom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HbIlW-0001QV-Jt for sip@ietf.org; Tue, 10 Apr 2007 12:00:19 -0400
Received: from ([156.154.16.145])
	by mail.softdom.com (Merak 8.9.1) with SMTP id PUL93732
	for <sip@ietf.org>; Tue, 10 Apr 2007 18:01:32 +0200
Date: Tue, 10 Apr 2007 18:01:32 +0200
From: Francois.plagnard <francois.plagnard@netbricks.net>
To: <sip@ietf.org>
Message-Id: <915050544@mail.softdom.com>
Content-Type: text/plain; charset="utf-8"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea
Subject: [Sip] Re: Sip Digest, Vol 36, Issue 12
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I'm out office until April 15th.

Best regards,

Francois Plagnard.


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 10 12:11:48 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbIvr-0006z3-A0; Tue, 10 Apr 2007 12:10:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Havmb-0006Ul-Qt
	for sip@ietf.org; Mon, 09 Apr 2007 11:27:53 -0400
Received: from yxorp.orbitel.com.co ([200.30.64.67])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Havma-0005VY-Dj
	for sip@ietf.org; Mon, 09 Apr 2007 11:27:53 -0400
Received: from control_perimet (control_peri.orbitel.com.co [192.168.102.7]
	(may be forged))
	by yxorp.orbitel.com.co (8.13.1/8.13.1) with ESMTP id l39FRduH025725
	for <sip@ietf.org>; Mon, 9 Apr 2007 10:27:43 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 9 Apr 2007 10:27:38 -0500
Message-ID: <67E8D0B9499294488148A34FAFC684FD19EA59@ormde094.orbitel.com.co>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Question about supplementary services in SIP
Thread-Index: AcdyTqR5IBxLsh5iSDK1+nlie4FS7Q==
From: =?iso-8859-1?Q?Oscar_Alonso_S=E1nchez_Hern=E1ndez?=
	<oasanchez@ORBITEL.com.co>
To: <sip@ietf.org>
X-Orbitel_SA-AntiSpam-Information: Por favor contacte al administrador del
	sistema
X-Orbitel_SA-MailScanner: No escaneado !!!!
X-Orbitel_SA-AntiSpam-SpamCheck: no es spam (whitelisted)
X-Orbitel_SA-AntiSpam-From: oasanchez@orbitel.com.co
X-Orbitel_SA-AntiSpam-To: sip@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
X-Mailman-Approved-At: Tue, 10 Apr 2007 12:10:58 -0400
Cc: Mauricio Eduardo Cajas Burbano <mcajas@ORBITEL.com.co>
Subject: [Sip] Question about supplementary services in SIP
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0256403679=="
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0256403679==
content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C77ABB.9B1D3135"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C77ABB.9B1D3135
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello

We are looking for any RFC in order to deploy "Call Waiting" and "Third =
Party Conference" services with SIP, but we have not found any standard =
regarding with these services.

Could you tell us the RFCs that define the syntax and signaling sequence =
of these services ?

Best regards


Oscar Alonso S=E1nchez Hern=E1ndez
Mauricio Eduardo Cajas Burbano

Orbitel SA ESP


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.6618.4">
<TITLE>Question about supplementary services in SIP</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

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

<P><FONT SIZE=3D2 FACE=3D"Arial">We are looking for any RFC in order to =
deploy &quot;Call Waiting&quot; and &quot;Third Party Conference&quot; =
services with SIP, but we have not found any standard regarding with =
these services.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Could you tell us the RFCs that define =
the syntax and signaling sequence of these services ?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Best regards</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Oscar Alonso S=E1nchez =
Hern=E1ndez</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Mauricio Eduardo Cajas Burbano</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Orbitel SA ESP</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C77ABB.9B1D3135--


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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============0256403679==--




From sip-bounces@ietf.org Tue Apr 10 15:51:48 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbMMb-0007ck-5h; Tue, 10 Apr 2007 15:50:49 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbMML-0007AX-FB; Tue, 10 Apr 2007 15:50:33 -0400
Received: from ns3.neustar.com ([156.154.24.138])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1HbMML-0000a3-2f; Tue, 10 Apr 2007 15:50:33 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id BD3CB17625;
	Tue, 10 Apr 2007 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1HbMLq-0002nD-HV; Tue, 10 Apr 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1HbMLq-0002nD-HV@stiedprstage1.ietf.org>
Date: Tue, 10 Apr 2007 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: sip@ietf.org
Subject: [Sip] I-D ACTION:draft-ietf-sip-gruu-13.txt 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-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 Session Initiation Protocol Working Group of the IETF.

	Title		: Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)
	Author(s)	: J. Rosenberg
	Filename	: draft-ietf-sip-gruu-13.txt
	Pages		: 40
	Date		: 2007-4-10
	
Several applications of the Session Initiation Protocol (SIP) require
   a user agent (UA) to construct and distribute a URI that can be used
   by anyone on the Internet to route a call to that specific UA
   instance.  A URI that routes to a specific UA instance is called a
   Globally Routable UA URI (GRUU).  This document describes an
   extension to SIP for obtaining a GRUU from a registrar and for
   communicating a GRUU to a peer within a dialog.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-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-sip-gruu-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-sip-gruu-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: <2007-4-10142402.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-gruu-13.txt

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

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


--OtherAccess--

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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--NextPart--





From sip-bounces@ietf.org Tue Apr 10 17:24:02 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbNne-0003OX-NE; Tue, 10 Apr 2007 17:22:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbNnc-0003NA-TU
	for sip@ietf.org; Tue, 10 Apr 2007 17:22:48 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbNnb-0004Uq-Jz
	for sip@ietf.org; Tue, 10 Apr 2007 17:22:48 -0400
Received: from [64.101.173.113] ([64.101.173.113]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3AKTMt6024011
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO)
	for <sip@ietf.org>; Tue, 10 Apr 2007 15:29:24 -0500
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: <093BEA4C-CB69-481C-8122-8738A5D939A1@softarmor.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: IETF SIP List <sip@ietf.org>
From: Dean Willis <dean.willis@softarmor.com>
Date: Tue, 10 Apr 2007 16:22:37 -0500
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Subject: [Sip] Keepalive for TCP: LIst recheck of consensus in Prague
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


Following extended discussion at IETF 68 in Prague, the room reached  
consensus on using CRLF keepalive for Outbound with TCP in preference  
to using inband STUN.

This was a rough consensus, following an extremely strong consensus  
that we should pick SOMETHING and stop arguing about it.


So, I'd like to review this consensus on the list.

Anybody who absolutely can't live with CRLF keepalive for Outbound  
when used with TCP and didn't get to raise their objections in  
Prague, please do so now.


Thanks,

--
Dean Willis
Wearing large, heavily armored Chair hat, complete with crest  
including flattened taxidermified arboreal rodent.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 10 19:14:34 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbPWg-0006bJ-4X; Tue, 10 Apr 2007 19:13:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbPWe-0006bB-Rd
	for sip@ietf.org; Tue, 10 Apr 2007 19:13:24 -0400
Received: from 18-116.252-81.static-ip.oleane.fr ([81.252.116.18]
	helo=mail.softdom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HbPWd-0000Fo-Fz for sip@ietf.org; Tue, 10 Apr 2007 19:13:24 -0400
Received: from ([156.154.16.145])
	by mail.softdom.com (Merak 8.9.1) with SMTP id PBY75037
	for <sip@ietf.org>; Wed, 11 Apr 2007 01:14:37 +0200
Date: Wed, 11 Apr 2007 01:14:37 +0200
From: Francois.plagnard <francois.plagnard@netbricks.net>
To: <sip@ietf.org>
Message-Id: <915081682@mail.softdom.com>
Content-Type: text/plain; charset="utf-8"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea
Subject: [Sip] Re: Sip Digest, Vol 36, Issue 13
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I'm out office until April 15th.

Best regards,

Francois Plagnard.


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From kdavis@veilleuxfurniture.com Wed Apr 11 01:16:09 2007
Return-path: <kdavis@veilleuxfurniture.com>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbVBg-0008FY-Sv
	for sip-archive@lists.ietf.org; Wed, 11 Apr 2007 01:16:08 -0400
Received: from [213.154.80.21] (helo=smtp.secureserver.net)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1HbVBc-0000iA-Hs
	for sip-archive@lists.ietf.org; Wed, 11 Apr 2007 01:16:08 -0400
Received: from 208.72.177.107 (HELO spamwall.redwarning.com)
     by lists.ietf.org with esmtp ()QA*L09HFK 9*/3B')
     id 97J70(-4WPIA--5F
     for sip-archive@lists.ietf.org; Wed, 11 Apr 2007 05:16:20 -0100
Message-ID: <01c77bf8$8a3dcbc0$6c822ecf@kdavis>
From: "Humberto Beasley" <kdavis@veilleuxfurniture.com>
To: <sip-archive@lists.ietf.org>
Subject: Windows XP OEM Install
Date: Wed, 11 Apr 2007 05:16:20 -0100
MIME-Version: 1.0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_000_000F_01C77C09.4DC69BC0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.2300
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.2300
X-Spam-Score: 1.8 (+)
X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c

This is a multi-part message in MIME format.

------=_NextPart_000_000F_01C77C09.4DC69BC0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0010_01C77C09.4DC69BC0"


------=_NextPart_001_0010_01C77C09.4DC69BC0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

Looms in the air, deliberate and slow,A kind of snow, which hesitatesand=20=
turn it into something cartoon-funny.Archangel Winter, darkness on his=20=
backIn stone waves and rock waters, far from day,When Arctic winds crack=20=
down from Canadaand preening, dancing on the basepaths,Yes. You'd want=20=
that said, (if youEnd of the comedy.XVII. GreenlandI. Further Exploration=20=
of SpitsbergenVII. Hudson and His Strait; Baffin and His Baywonders if=20=
she'd ever be brave enoughLooms in the air, deliberate and slow,VII.=20=
Hudson and His Strait; Baffin and His BayIn realms of dingy gloom and=20=
deep crevasseIn a single floral stroke,They tear apart the mist, it is as=20=
though,The ordinary, wide scene which begins


------=_NextPart_001_0010_01C77C09.4DC69BC0
Content-Type: text/html;
	charset="iso-8859-2"
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-2">
<META content=3D"MSHTML 5.00.2919.6600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<FONT face=3DArial size=3D2>
<DIV align=3DCenter><IMG alt=3D"" hspace=3D0=20=
src=3D"cid:006901c77bf8$8a3dcbc0$6c822ecf@09D3E542" align=3Dbaseline=20=
border=3D0></DIV></FONT>
<DIV>Looms in the air, deliberate and slow,<br>A kind of snow, which=20=
hesitates<br>and turn it into something cartoon-funny.<br>Archangel=20=
Winter, darkness on his back<br>In stone waves and rock waters, far from=20=
day,<br>When Arctic winds crack down from Canada<br>and preening, dancing=20=
on the basepaths,<br>Yes. You'd want that said, (if you<br>End of the=20=
comedy.<br>XVII. Greenland<br>I. Further Exploration of=20=
Spitsbergen<br>VII. Hudson and His Strait; Baffin and His Bay<br>wonders=20=
if she'd ever be brave enough<br>Looms in the air, deliberate and=20=
slow,<br>VII. Hudson and His Strait; Baffin and His Bay<br>In realms of=20=
dingy gloom and deep crevasse<br>In a single floral stroke,<br>They tear=20=
apart the mist, it is as though,<br>The ordinary, wide scene which=20=
begins<br></DIV>
</BODY></HTML>

------=_NextPart_001_0010_01C77C09.4DC69BC0--

------=_NextPart_000_000F_01C77C09.4DC69BC0
Content-Type: image/gif;
	name="pquxt.gif"
Content-ID: <006901c77bf8$8a3dcbc0$6c822ecf@09D3E542>
Content-Transfer-Encoding: base64

R0lGODlh1gHGAbMAAAAAAP///wQE/B9hq2Cv4+rq2729u8/PzvfxYvvQCGBUI7SabvqCBvz8/AQE
BAAAACwAAAAA1gHGAQAE/jDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP
yKRyyWw6n9CodEqtWq/YrHbL7Xq/4LB4TC6bz+i0es1uu99wLGAO6NDrE7r3ji/x5xx8EoJ6PX8b
f30XiYuJhxqOjGKFX4KQdxSUWo+AIJGdjZiHmjifGJGnjhafmJesoCSwRqRcj6GatFaMuamvioO+
Abwzr6umFazIwa7FfrJFw3KWt89dpNGZ08CtebDYpbjX4t7jv5eB1SvfcTG2xtxg4x7wyrLh5jy5
8Prk+OvC+N7J+MfOhR5+dQhSkYcuXbd+2QLq4HUvVESLDe04TKGwoDpA/ggBKkJI62A5iSKjadu2
rJdGPL46kdy4MhaoYYVwbhQ5b6fAlL9U1atmUqbRkK1K1hyKckdRixUjuuO5T5LUqSyrxsxAr1fC
rTyvdgXaEWNYjDqb/utYdJrQrEq/HiVrD2TOflbF+gQH01/fkXXf0tVbLitTtzElEmyb7Cxcesec
9Um7jSvNvZU9NaY7GZXeh55BU7r3N3DeH3eDzn0otTXLd4BvPiPtOjNrRJjPRr39GrTv3yN2/6Rs
WXOzq7Udp0zeVZtWc6Nn403uI3U9247jAufNe5127srNZsTOELvt7yLKD3dIvOfx7eQD/+xNPTt6
79Kb3oiujHt0/eFR/nSUWun8dx1uAJ4H0UXmicegcaoptpqDD760GXjxxeZSg+Ep6FdnOwmYIDGy
gehfiS/Nd+BgKj6o3oYpZrjiNyKG0Bx7E7aIIYI2ErUgh7r5GJCBKp4GZFkvEBmkhkCuuKNygtVo
Ho25KQklighe2NCHlv3VJYzu9cjliceFZJaZhBGGlVNYLuniXug5KdaTVnY4lIVkzugTWHhSeFt7
FYZpnHikRYamnmNSA6KW+UAkXJ1gHhmidWfKNx6Peb6pH5I6BsogoE+6IiahP2IqZ3dCbtnkEBU9
2qamndr5aYGvylrfnZmiOiannnYqHJ25hRqpjML2KmWH+Hm5RKul/v4HXa0NQuqmky92KaGlU5b4
rImx9uprqcCOWOy3TO4o7Y3lwjrfoYaYFmGFWhlLG330PRfoYpCt9Ou8Gb5rapa40rtct6IOWqRp
1Ao5nbnaBpyvuAO5m3BsUdIqGGcn6esugHzm2u9pjMIW2mPoXjyuopEhi5e2ec0EcqqiTRUymxFi
e+XL1y41csz5HeaeycSCtzPJm7bEs8Vrrmrte4e6szNSWLE7NMas9jwxNX7eyjMzwy619GXpqoyN
1yJPbeRnX6aXmLw1bwvzgTq/vfXSHtVt990E46333nyTCHHfgAcu+KWDF2744QUjrvjihvPK+OOQ
m+F45JRXbvnl/phnrvnmnHfu+eeghy766KSXbvrpqKeu+uqst+7669UFC43sOUx+gu2wB457N/vR
zlfsf+d++O62tkB8kr5/FLzwhRN//L+zJK/C88zb7bz0ai9vA/UGV5/59dpnrwT3H5DvfbtyuY1S
0oaFBerRTAWXlMLb6khp3B9OOpZoSp8fRVtpKlvJRAEtWVWMfQKUSwI99R3GVAtoKSNZ8fwHhZY9
LYIYOxeObIFBr1zMUBKbVQQz9jCTvYeCuogLxeBjL/5xaGwIg88tkLMdboQDIJpaWL9qU0Lm7A+F
/4uTh0jltnvtyWb9UyEDX2WXHB4sbNO6WsCAWAUhjkta9vFX/uLspBKLhSs+ONQVEb9oqmNRcSFW
6xYHvQivI0JxVceKo2zCmMUxSipnBZzgGceXHy2BcEjYSpa3ughIbq3LKLyr4xPJeLQ8mm+PNFDh
H5VkxihusZKnGiKpgJFIJAZNjjZ0JPYgCby8YQiL2lkLuIQFSjCZhHfVUiQXoYXKUZKyUfUjnBgp
9JQY3XGL6lrkHGO5GymhCZO3ZAK7MqPEU6YSMw90I2yW+Cw6NjGTrsplgH41sGQ+gSSIotgKXRg/
QdWQSivzYR+n+MJm8es542yfN50gorcYLYP0Kx9igIYyjUGwMNgEV8ruecJ58hGPJSSg+uxSyBE5
7WxfU+Bh/jYY0ERtM2q76GMvDapM/SGNlvMrpJjWmb0caU1ocvPYSdeovv5xdHCPfKlMyxDTmdo0
DDW9qU6zgMCd+vQNZPupUNvww6Ea9ahITapSl8rUpjr1qVCNqlSnStWqWvWqWM2qVrfK1a569atg
DatYx0rWspr1rGhNq1rXyta2uvWtcI2rXOdK17ra9a54zate98rXvvr1r4ANrGAHS9jCGvawiE1s
BRowgQYwNgSPFYFjI9uByVo2AJZ1rAQuO4LJZoCzFNDsYilrAdFuVrOMNW1jQYsB1io2CZ69gGsx
S9vRYjazsZWtaEGb2tNmNrS5Le1kC9CAAhj3uMc9wAEK/rBc4+L2udC97XNrC1zUUve1KOAtCILr
geD+Vri4XS10x0te4iLXuMpNrwHWy972uve98DVAc8lLX9K2lrb2xW4LTJvfznq3v9INr3g9a1nz
nle98YXvAhLM4AQveAEEWICEJyxf59Y3vADubW/1u1/V1mC6BS4uctOL4Aab+MQoTvF6IczeCBtg
AcolbmovfFkPh/a6HPYvbwXsW9I+18AjJvEBHLxiFRv5yEhG8YJf7OL1pve89A3wZ3GcYxLENrNA
PnCJk8zlLnv5y18msYXJq9sqm8CxIwazmtfM5jZ7ecjyle9yxztaAJt5A2iW85CX7OY++/nPfYbz
kAct/mMp9/jOVmaueh8M6BTDmc2DbrSkEzzoGAuYu4jubgH0bAACFPnF7q20kEc96jiTetLwfTSq
38voCbv61RTm83tV/WQ6ZxqyDTD1iyG85CaP+rzATq6YmyvsU6s30o9Gdpzjq2xBm1rVa241rKdN
7V3vWtbsrbSTLd3YW3eWuXJmsoRBjW05BxvYxCZ2sI+97W2TONy6FvW7lczqa1P71QzIt773re8E
5Nvf/A64wPW9AAa4OtV6Xu5qvR2CTT9awgNYQMR5ne0nnxvdy1V3sUud8GULGtrQbvCD731vBEjY
5CZPwAIQwACWLyABKoc5A/wN8JrP/OYAH/i/DW7w/liHWt6FtjPDLQDuLUtcwp4O9cXXvXRFh5zI
EzY5tWP+8pvjfOYwz7rWt471rl+d5l4Hu82tnvOdj73sOjf4rIVM3KFvd9lJJnW62a7lp4Pa3iVf
+ctfjnIEUH3vMae62L9+9a4PvuaHL7zNy472tO+bwk6OfK3d7oGi233tcmeuouNMgM573gApB/zX
ab710pv+9KgnPdezPnrWJ17mhAc72a1O+507XuArd7eQr4xfAg+9AZFGscXNO9zMev74oRc84FnO
crGnHueox7rWDQ99xE+f9NKPPeHNXvucy772ty/4uOM9eQL/VujYzbW2KZ1wYhf3x50+vqdTT3/s
/rv+/tFXvemhP3r+G97+/bd4s6dzjed4J9duJBZlbgd8cNdgT6Zx74dmjhV/yPdyz3d99Sd9+Vd6
1CdzHoiB+Ed92jd73tdv3MdvBThw48dp6VVjs5VpwKdcDThr7Xdc5CV/nWcArsd/IKh/H9iD9KeB
GNiBh4d41TeCsNeBtmeCt6dzuYeAc8ZZG+ZtDCiDJjZ8NihjErhpOOh39feFYMiB++d8//eD/+d/
r0eCAleCTZh2FHZsLWhjNmZmVWiFzFaDxBeBlkWBnld1QfiDGyiEqzeGg9iDZ+iB2ZeGsjd4TCiA
bRhwEiaDu1dmMIhZknhiw4ZcEiiBOEgAXliG/oIYhqIIiM5niB9YhooYe2m4b42XggbIgtxGWXOY
Y44lagwmaprnXHkYgQeAgxY4isB4eqHog6Q4jEoYgonHhGq4hI+Ie89GaDP2grQYgzPIbDFmcZu4
h10YhsMYjBsIhDwYgNdHgkXoiIynjM1IcAYniQloXbPIYbV4iawGa1LHcwdXfL0of17ojfwIht34
haqIiIxoe4tIe66YjusIdNH4jvoVj/DmXiQnfgygABO5AFoIfPL3Yv3Ij6H4j0J4iNUnhto3hMwI
fggJiTBWgzyGaHlmhxB5cLm3gkNGkReZj8i3kThJihfoj693it8ngIx4kAh5cmy3kncWj8H3/pIL
tmcrtpTGZQAGV5PbmJMc2Y8gqXqJiH39N4AmiY4n2XOkdpEMx1jsNo9PaHK7hgDJlW9SqY9U+ZY8
CZACGYA8CJTd95Uq+GtaOJbFpWtmyWcIcACRmFwSloc22YdwOYr/yI33V5dimIzJyIp46XjtF4Xo
91poJo9KGWt7VgArV482iJHHB3qJWZpxmX/iCIBBeZdCmY4wVpSYRocOV41NeYAwhm/5ZpEyZlxT
aZq+mYH4N4jbN5Bo15qTSWrSSItFx2Aj126b1l4LgGU4+JvU+Y2JeISNOZew95OTaYBOZ2kMmX7F
pZnzeG0r9mhZ+H4F0JvV2Z6MSYbaWXhL/micQ4mc4Zl+ludgkLdendeL7md88ueeAjqGRFiXI3iC
bNid/Paa7XiZr+Vwl2dtn2YAikYAljlc7Dmgv4mKj6mdq/l9CmqAoxabZpaf8aUAJ9drnZaPF2lZ
06mhMJqdArmDBWmQJ1iS3cmgcTh0m3d5C4CiB6dcnncAejhZGRqjApqVNDqj2xdw9OmaI+qghzVj
7RZfvAakcpZ0FBpijvWiSJqkpoiGrGmCT4qXgdmOt/ZYPZpgKPpz6FV8xceHnvildBqSWEmGXnl2
IZqbKpmmm8VpwpeFY6aHR0qnGyqMWmmOy2iSZeqGbEeFmAVutNleWKpcwEd8eShjh0kA/oaKpBx6
iNwpmV4Zojo6Z36KlBHqAAqgAAOgqjGWbVzaAIXaqW+pgR2pmorHfY7IlZN5pi3op5jll/A1AArg
n73oAAaQa5EIp7UYoLQKo61ndjV6jne5p7n5moompYb1WDGYlO11AG0KoT+6aQNwobzorM/6peGo
p7nKjI3qnddYAMC6pvEVcXpGrnsGY9DlpelanbY6oz45nAS5qJNZqvJKhXXoYMhaYTNZZES6i8Xl
lv06oKCop6vZldaqb9dIpL9HnqH2o9BZrCzWohh6fBMLpj5pf6tol+D3rvwmZoWWpsqWYMS6qqqa
rHFWpCXreft4stQZkgP4oTiaoApa/pRjOW8NFmEWKqnRGYEXia4+65sfCZ9F2IjymXYuy7CmSoXe
Cl+qiqLEWmGgprNoJrFRW5pKmrICO3YoGLSTea9tx5KbVZY0a7Oryl4WOV58eLZoG4Ij2a42CqIY
i5BaG7N0OLddi3kGoACdxrjrBbFGepN8C5f/aoYry7Zty4Yum29wq62EhVpI67VturhwdnQkK2N8
2LNg6HeqO7mVq5qr166RaaOi+ogUOnlyKwEza6XE6gBfK18LBrldKrlh2LquG4gAqKs46qR5epJw
C6wBQLcI17AE4Lh5C12Habz1p73Hi51LerGpGLh4WbjQG7rvtaq9NmTlCmHmqqnE/ju5fYuMCPqI
mPu2Fud2s3l5EVazIpuSEka2otl53Au/cgm73nuddgmZZDqwtptxCgep0stqEZeUEmeuk5W9BOye
Zwi4zNuKITqJkLqcCfa1d+tcRCpfALyePJvBOPmpKiuCCZy5BJuODBu3fkqvoba4nFesxIbCWFa2
K8zC3nirBAq+MnyQgtuEIOyn7Mim28a46TmoLhrEQnyoxDmfjHqgo6pzS3yUEwChDOZpMgjFuhir
kSvAVZyY4oiEBZnEtZuOD+i5n/vFHhuyrMpemribz/W+9Ke6rJvGxBiwVcuVMbzFjurAcnxY+cum
EaeqMFbGADy8AjzAX8i9lNyv/ggssIQ8cG6sxLjLcN85wuvFuFD8sBe5iwHAx32cdX8Mc5d8shWb
ilesxQusxE6XyIYlwvW6YMU6ACi8m8IbwAhwya2cAH/cyl54zMa8zFWMhDfalfUbfnGMv3WMt+vl
AMSat8z1w5llkysnij1rvK8My7LcpPPLrnD8yVz7kMw2YRmXjSQrzMVceqybzMO8zPe8j/mMz8yM
yahZzm9cgE/6yL/Ko9X8rTCri/HcrJPsyturdcjs0A4tzsdLo/KpqJr7xmknZrj8uQlrpUsWY+mJ
Zqfbh8NM0Se9zyot0ftszMos0Z16q2y8vDT9iNhqqb+nfpP6Yvxrr8mqxz8m/qs5qM+mF87M/NLK
fM/9vNQxSsSxi6dqyJ3R7HgObMNp2q2TCmfZXLOmnI1bSAAD4GktDdH1fMwrncz8vNITXaeIiqss
y7w5ytE5vX4NxsOLK8Ul3Xnf3LpobdYuzc9prdR+DdEx3da5WoJCi8XSfMtznbiSN8pxVqwi5tUS
aABhDXp87dIp/df1jM9lnc9IDdjjHL+mGJkC3bY1LXBy3bHsnGoH0NNF2qIyBtYRNtZrbc+a3dm6
rdlpDdPPKoiHvcmhipcWKdIdLVgX7Ngr1qbqq5u7KNsY6ctE7dkp/dknzdm5Td2iDdiGuphri9oc
3IQEvbWnStcK1rsoOl9a/ni6uabX1711n53bZc3Z1X3W2E2rSnqMzzzcayjeq527uqvc50sACk22
WtiL0u3Hmz3f9Q3aZ73b/TzPTR2c49jGtTvVQlncBZ27ZNna2Xa+77zezMqbtd3X8r3gDZ7d9e3Z
EV7RylutcD24uKdozgWsZCngi/u1TqmeQQ3Ec6rPK97g1+3gDD7km93baE2xKvvUy7irX6nh5O3F
tLW77lW9KxZxeRzJEVvioi3kQk7fXz7krjza6urW7iqq1Hp7vhrlhzvlAg6yY6zeBl6yC9bXXn7n
eF7dva3iTN2eqRmftCvjNv3fTLxl7zXBylWsxEWkIw6gCxbYeR7kkc7b/p3NyoSN3xatqAzcqLfL
bWMZvcq9Z1ut6EBNXvmo0pGu52FO5Hse0WROla2Xnei4uU5I6JUYwd8KYXdrypjKrLVor6ie6tat
6sRO32vN1jJaihe9yc24crYOg7oMX6wavAOQ5fQlmBZq1ncuYTzXb8I+6dytoXZ6pzd62oaMe1V9
3IPVly6Zwz9qt49c6l6N4Adw4kJOkROJgsJO6S29qgowsf96tRl9nM/Okot8YtNe7XoI3Y4ViUR+
7/g+YSrn7MeW0gpgchfvd3tXkT9qgRd/3xpcivrX5I7H6WJGeePp4U7GvxGW6E5rxhGb4MNe3bmZ
0jWPt3V+0v9ecCga/nM7nwA7/+//ntniXuG4Wu5mWvBHCcYjDGGOnHGQTF6WfQCpvrgGN8wFYHJX
72mdF9Yp/e5Cv3foK/QgP+Gvi4gtq9GumXAHS820OWiO28sUCtSnnFlTL+RZT/NXn/cux582+fWf
+c2fWd0/j+kBj/YD2d80jKaQGgA4fL6jDK5z/7CxepHxF+lZD6Q2/5nt5omR/u4I4O+rqtSWPuHC
ibmdLOj7tuZtP6/m/eGgVrNzz+ML/euYXd18f9LcftJ5b8xOJqn1DfaDP/oL4ACqXuaHn7wgOtVt
yPaU5/iG/q2sKphOGfXFd8o5z/van/VZX3BXb8zjBmFirFwpXQCi/o++w4yiGG/kQD/0P6qqfS61
I7+dMJ6jCXefDanTlxf32DxnIm7qEEAIQqVSjK1inS1vMUSjPCxrURZMUZDFWVRnVRLYdZMV2RNg
UDgkFouMBBKIVDaTzKeHKaVWqaJD9tBoBLxfcFg8JpfNZ3RavWa33W94XK5uFLQlfN4wUPAPs5M6
wUGugsI6AoOMCwtGCpCZmcdHRZZFmQwVGh1MF58bHM8cI9JS044hJyippCir1yoWrcC5Wttb3Fzd
Xd45roYsgwM9PRXhgQXDgmXC5kKDCZTFjEbL6ZFIyQqVC4oCTEyVA5+ZlxaFGk/TdfYgVPelqFZW
D1fYWJMsrl7+/n7/f4AB59gRNoyYsD55siwLYOiXw4e/oC2ShsIiEGswHllakICjuQw9HFDgQUHH
CyCfOrZjScpJvJdN6t2jWaWgvi4Cde7k2dOnG2DBDpZYYQCdAgN1HCr71fThgWjdGlGbhmDcpEc8
cOTohsAoi5FcfQBBGQpkyyIIjigR8hLePFRTntirKWXBrC05f+7l29fvLi7DhBIb1kfBnwHM8kIU
xBiYJWkVli2TrJaB12sYIqVwcLUFix4JwrqIYcljuh9oS6kAlQom3Jl1ZYewqmXfX9y5de8WUyeY
waGa/iRjxuyQ019QHU3V4C1lZcwsKs2gLGOqqHCHyX1Kp5a0/tq0qoNwaOvuw/kbDDhwiAuX7uwP
gnHypl/fPs+gwoaOQJaoRPGImoJIGRGWk2yyyTSKTLPPzrnrgO98IMmcG0haiZ0KWSLJLMvUQ089
HkIgCzYr3qsJC9v0um9FFlv0Rb6hhmGtj2SSaQy54xAxsJGKEEAiskpgKOcFSyBEzZqMFulBLfBK
aa0dHTwir5UQ02NPSlfmkgs+Kx5M0UUwwxTTjPyAw8NM/0wYIBAcHeNCBMp4RBDBJKoSUisiM9LG
zq0+UQKDIJrEIdCtIiFrE9DWeyG1jjoAxQUlHl2lRC7tqm2+MTPV1EVg9DNTj6NkOGEpppwqtYGo
LPJmOYwm/kGShSQtGIc5PksiSVAiHsWBAdTIWkG0GcZblK0RP0iCAxDOm3QeE+FDEdNNo5VWtzJj
9CMLZJS6EUenSqjMojmX8YityypQhIKFJDtJOzsxMAAT8KzR4ZMdRBKWNV/NqgFf87QKcaX0VqGr
2bq8hHZahBPuKajB9PjjsGAOOzUipiD6I87lENywI0vO7bER0kqryqNBdejIhRpUAo0FHEb64RNy
8iVtZnJvUGFc9jy4cssqCIbF4AMCUFFhoovGZehq90MmYmWadkbAOhTBeM4Dl5n1wDqak6aHArgp
J9Hu0JGSwtIwEoUHfg/9lQcbfP1kiQ+8O5bt9piNrdIr/uRzyGi++5YDacH02++kNQHk1rGuP646
XB4PZCSyFVKwYeYXCvAkhhwMkHLGUGoAwgG07137JLJcfnS9kwNGYiVVppgUb6Bv83t22tfoguFP
iykhEUO2qHiQAZsyQGPiGf9WTqmsihxmUSo0qRwYHJD+hyjN0kQUH5AA3Vf1en0nHiPigoJEvK+4
qQCha1d/fTJuFyp3PAxzQZhtuYVaGA3ANV7VBBWn3KuwcOMz3MBen26Gg5vZbF1Y2tWuOoIrIrQO
fDzz2WxukgX2ZVCD6Ytaw/azAD5M5hDB49bw+se4/YHLQD7ozvPEkoOOjARYrpqBDEjXGkiJZx3t
Edjd/ir4s1kYYoNDpF1O7gA/TwXjLr0zVRMtJpU4ofBxxzMQ17YBEnh5jUI3/A5pBnUrHUbwNa8R
mJbK5wGvaAF9QyNiGxF2O4LkDjg0IooJtYU4J84qilIs3rccgQDrhMQSlGMZKN6mGgjqkFg8tNsZ
rXDBvblRkgrrIBLxwBoHJMY4ULOfb+SEQv5RsUcVsOIozrGkkTUpkWE8ApXG2MNGig9v+WDTJG2p
Kb34piAHKQwyCuKQQDBGmAJyHCiNqTiQtSuVQ1glK1lCLPfAUpZn3GUtb3lNMOUyjvt5lzFMYJyl
cPI4UzNmxvgXmcbRik8b+mIzncmO8anCbj8sWBDT/odNfK5Im56KEVIIgBSJ/S5HbSJnCosXyuQp
k0lMGlRD36maMk6QkY60wiySIrt8ZnQ32gwcL/cA0AMMICmbbOJA9xhFUVKNMn9kaSo3BB6YPtSZ
0pxnNMtHy0hqVKe44egug4Oy+RVHoCZVChT1N7WqrWqUCp3GVlIiU/GMzzUTpSgVLviLnWbVL/u0
5O70YLiSElSFJ1wcOVe4IIX26YtQbQc0YRlNKrmOmrvEqlbt6pc4wi8LOvDlQgDkJpNCpyKhROgo
1bnOtcaUrc9sJVx5RtGrYvSuk+WJHbq6SxDy1U0kpNgnj1rWP6KTqWBk6EKf6s7FwiOejTSjXPEm
/h9aUFa2+LmJR/V2hzsG6HArJeyODJvQ0YJRCKhNrStdAxszkm+Ws5DsbJ3bD4JwE0LCsENjhlnS
ARW2rGTVWlcOu0x2FpexUo1nD+/2Wrqy8bnr9QUYAnOHoRAARdS1boA2q5R0NsC7Sk1n41bF1MQO
V7zwnGpczQs311qQuc1lb4OB4t4GnClGIpiv4QBLUCj6tn//5W1wMxDgAbukwK6c5jTp2aVq1tXB
K37wF94ruP3ICE4WzlE4H4JOxU3Rv13hMXgZ+tQQi/i475AnDyG7YPWyWMllUNGLuwrCBSRiVNsi
4TA3rCod93hB3wWvU4O8Q2aRmEStPXEVYKvi/iWnGQ23S9pBsFCCuwxUt9gV7VQGG1rgKtOppSXU
l49bHgM79rGwi2yS1XxoF3uhU0iUkZQNMuWJjRN4HUZmS+3s4aYq1s/hm6CYXZvcM/4mL4ZG9KFz
0mbCZGPG4RyqWKnSnBXCGtMN5fOm39JYuIXZdWX+WaFL/eswnPo33ISySEVIUifeCKmhXSpFZD3a
tTrU1jFRLRk/PWj4+BrY21b0omEs4WeJQNnAk/ONucwcdaI1rT/+sa1LQa55LivB5Ysdg7mt5sD4
NDi1ZdPhONm0hKIbYxwObp9Mq2l33zquZIwltrl0Znvfe8n57mhwoLwA/P6Os6byzDS4jGlA/pm2
zwl3C7zj3VofEhrJEgf2Mzx4pijjxXfltu+NevxqkH/44O08LcnfstqTv66qDNA2yxFNcemOYHh/
qG/9LhyYnBs85IvYc7QTDuifB/p1BOO1XfAiNFIb3cEd/LaEL/lNcuv2VMD0sIAB1XN29xnhXzZ5
yastE+VS9EEFAbvYS82wsp9p2Imp39NqnLWcA3jnxL36kO8ub3mUeDZBRLPfG5xLssdY5iIsfKRJ
1XGcz5rqfI574+Up0aC/J/LOumDfLY/vAvCTMJBEUOfpXAiFflzPi5f21RdZ7YWbV/Jn3Hu/Xw97
2RNGjceWdFgJYQc76b7gpAVy4437e4bP/mT1eqd82I/vXLIzOojMT/t1gQf6xI9erTFVpfXBp+uT
a6nr9/DS8CL+ffDrsqvjr32pNv586Uu/xGo/9xOz8oA34RszerMn78M/ygq/GFk+zgOs4EGcE3A2
dZK6TOM9q3M3u7u77HM47hOMnHLAFbOswEsiv3KaVkMOYUq/dqm6divAVqo7mKCgeVsuNbonEzzB
YeMlNRoV//s3OZuMq9DA0UOsW2m3GbQ+qcq+1KOC+cubHWzAHsyqQvhBIFxBgbovbrlAaFM80mI8
P3OrhYNCuco7lVsI17tC9tqmCORCGhshihkhyxJDqRvAkdtDJ3w/rYs3oZtCKYgsHnTD/vzTN4eh
vSGkOVdbqExDQuoTuSb0Occjr+DDwaEDBDW6HUNcL/3TPDlMuzpsPvwCsABbwmgjw01zi/czMkCk
h6oiRCvsxHyiOL26ICGkMTzKIy7juUckveqjwRFbrSKjqkxcsEKkxcniAkR0GAnsQufrvI+jNWCs
NWHEuickRvkTuvMqH1ETollUxmvKt2akpVwcql3Eo5WKxAHUuVPsvQI0Q3Ipo10bPkfSRJwIR3G8
pfeyJLyYEzp0uhszN50LObizOlWcthF7JbgisxyslELTx310o+QwAc2zg/7bOAoUENAjFNJjR2sU
RmiCP5qSJUGEhaKbSLuyxThcwdzS/kgqSw47ADGPrMmEdD+gK0l5GzrzQUaJVEkierEYOR8hLL9R
FCereTsBs0kgm0ScVLjgi0IF5Mn5GjWgvCuW3MJzXERnWLtCSEqDXMpau0kPBD5q2xLkekhq8smr
1ConA0WX9MqAnEur8Qx4hMe5u0as6zRpEp+TpIm7uInKa8uMykrlk0ONmzPD8yR2msS81MszNMug
wztXtMds+43BJMxahC+txEinIcWJ8b87DEl3IsuyxD6dpEyepMIU+UnNzCBUc0YuxK9oDE2ZHAfI
VCSozMlYQrC/BMyrSsbXzCcY2ULP5Dy6fBrHyILGzM0w4s2JEjQRdCS8yMzh5Ec4/kxE/mPB2hy3
3mHOYHTOthIjkmSt6czEXVqj69Sp2BS8hchFSatAFxwELQgv8Xy3VizPImu41eyS6nTN9awdCDTO
Y7OxIhy3p8iCu7xPqDSuTtvGerSp/uwAgynBAMUmLZRNCfTOoxzIpQgG09RLeTzD0xM+KZzQZwka
AL1Qv/nE2XtGsIJJA81C5gxR06vBrNvGLMHECaVQBmTRfIo9fwxC5uPKC1tO/GFQ8oS/rNNGE+1R
/5wF4QRSScrOwwyX5zs886PRI1RS/MxPqURLy6TK7qNSDK04DY3LctvFZrCsCbDRVczRqPQ0m/JN
KMWHYLBQM3WjvHrR2dTFLM2u/m0hAPD0UjCdU5M8sPP6Tfor0z21JStViO1sQZpzkzuAU0ok0bmg
0/LavjvtAEiyzkfNoD41TkijQ69M1aYgVG+5T6DTVAmN0ERVSzLdxPsbVQEVUrjcyiNtE1EsgETA
1LLkS52EUFrtUZy6VVytnVI9zKKUT1U1P8sqVCW1RP2s0xPtxjutUFFdVgFNQXMEyEhTzOSECuXI
zdPLUUWNDVAb0wkNVWX1Vr5hxpdzz3PkUFYTSPokVPsc1pGUzKgUU3f91FjovhWVV1yKMIs0VfJb
THGCGjfVnGvcz1sT2ARjVJ6EV4QdIsDTymf9THyNz0OAimClQZM7wFyTIB2F/kWCpYmI3FgNirDi
lDAiBae59FUX7B1Cxc0brdgw48vebFlHStZ4hVlKQlOFOJ/+C1QEFchlkIBhEFFOBVpFxdjVjMiD
NdpsylBJ/VNR9DciRBWokNinRFk0JB+Us9qhNVitXR+ZTcGa5U5opbIJzEIJOBeTJdGS3NTHUtsj
a80pbduiKZNPga3j1FK12y2lIFR+7Vny3M8EPFahRUnBbArBLaLAkSOlzUjssi+5JNkJWNDiQs0m
ldCgldzJ9QCsvdzZac9wrduAlNGAzAIJ6Nc+hELzVE3UndzVZd2+WTS9qlnaBNR8TVxgvdsLocS3
arh2ZdnUBc7KbUPfHdzM/nXWe23T+cxScjveYBXWlnjVtoDcetTW53VZzGSz6Z1XzrzSZw1ZG/s/
ZpSARAgyVkRZJ03L1fNb9PTJrE1f+phZDWWcwqu5mGQK0FUE8fpXQLPB1Jw3/aVO+XAK/zWa9e1a
NWXaRdzSwJDf0F0sM4xMvAtT/C3f2YidbpvgojkiZz3OxDTK7a3DA/ZeIXPQuitWEq6qN4utokVh
F1HhFS5SAp5RfeXekn2oiKLTmorCvrzhyWOuwOXhTdHVlsTSDEbcgRwEDh6B0TXABz1bIusZJpaN
HN6CJ4biMRlQCz7cFjZQxJFPaLhbsoUoPxxJyI0887Tj3Q1jbk00M54W/iENXhi1vV/VFjnj4A7+
XlyrKQQM2Hb11Dx+3grDqv7t475o1q71zJd04c2C1ixO3lP4ZLOtTJoCNUcOYyCyVUpOGCm23qWt
YgwGzSwmrg/2w5+1xL5lV78cWFMOgTsQolRGGBQEZBaOyRe2ss5ClSzmtC8FvlxLy1lN2fPc5VNe
CE785WjRVTnazqYV4hduIkOOY1ru4r3s1C/ePofc0Ucm4eIDLGsek2BmWCCGxiGcZ0EA3US4kFnG
UYUrxlI+Z2mulMCkZm5pZzBZ5TRt5a7spAHWWfllmfF0UCSOXIcb4X+upzztJIJmEcO8ZEij58Rs
tbX7Zi5W5HAuXdkw/hF7eGAUtcin24dJzmhecNGDRmj76VUr4+ABIABsTOT4I2lKeQWVFtqAtj+a
K2OY3gt6rde4dd9ibtPgkYCcrl0ujigFnuP8rYkKCmr0/KYqk+Sj5g2kY2WE5ixpxd4Nhmr58ll1
jb9XTeeKhh3gaGFB+Or6eGf2jefE1debJdmo1mKfpTYRi4lsHZi31rs8iGc9peu/8DaxBmLtNWun
RQT5RQbLGOdrtdbvGd/CXs0ViGt8RR/FphbXXWp55lC9hog9iOq0Ls+IBsF55MbNXk0S+A+h+p3Q
3iiuxUVx/drORVVym2wCECnsc21xnkcDC8TYNuwzGd5ju+3cCOsf/v4rxDVS5SyE4L5uRTjLt8rl
cpbO5Jbtw6ZipXDu565eez0B+JRLL1THSbvunB4A8GBF8gJsvt1JY/3uSikKPBCqjPNl8t6qCrbX
3UZQaNxm4EHrnA6W4/bp5OJbrdNl/IZerhZXhvhvAE8+98Rk6SZgFz7QPXDvYLG7vfVLCL3qCCe+
8DYmC/8LADbHe6VnAhdZgYKK985pzSFnJXbIrYPwE++S2aYuFV/xvvBhmkVvvJ6z903OEQru915t
HHxFUsZEdO5x1ttvq0EhIR9yDNftse7mJK9D/0vt9zaAnBxl7obF5qVyLtHvCTdyTM7yvbCou+bv
L9fkQRaEDx8A/j2H79x1ZsiTclxWczE+bDcfZjj3icxL2kmtYlf2aEKABj2/bhC4RPfw1KwWdBRX
CIwsdIZ46UO3nRbHqfal7g7fUp2tccpeYnQeYTzmcUynUArLh+N8T/X89J3AZu0MxdL+8jVu7z2X
9KDNXVcfdjWfAY4WQvQ2alvfhdwmygIt9ebr6hxh8j1fgWVB28qk6FenN6XDgmn99gpfdoGQ6TQe
8Hzl9QLeFhrfc5GyNmNlVK2+YWM/b1rHIHHXCVxP41G/8zpn4/NjcoCnqpTWvh2HhXjX41jX7SAK
mnsXiEh93SMv8HOPXSxmdz0n86o96W2XbRJIUZk7gYZ3+C13/nY6B81oR8rnE/M9l1jti9VuvPSN
B8x5x8WFZ/iQ/4c/znXENMpG923OCimLH4F11XFi3/hIyJkQEAH5onmZu3mAiK5sLnSKD2JSNPkC
sHg9bxRRjnmOxwMfVzqmpzyn94ecn2ma3nB0t9lxAlasJ3NndnmuhwXUSfi7mIGvV7qP/7qx5wff
QFqSj3HtRfeT7x2sh2+Ch/u4p1BloVBsuCRAsPtYmAH/GLaP33voQlrY8lpHt3OTD4zCD/FbduvY
pjAZwfs/gLM/GA76izJjfx+a93TLd6+RD2QY5/y0t67PD3SUS3z9sKxI8IrGX/zV9yp+qvzY14Uu
QEGP3e25/rV9kZUIrBcB3U9886nL0ld8LlG1hbVIKT3+XHAfv59UYr4uwZ94Q1D5PZ/0Z4btVx8H
RSBzu08WgFZ6s8t8e/f+7wdgw/3YdFf78h9FCDhj0mEWYymnrTMYiiNZmieaqquyuK4RG0dMH0fR
NAHf+z8wKBwSi8YjMqlcMpvOJ/TYmNFkstutoNXqcl5dN9zIjcXk87lbIFQoG4/nA3qv6vY7Pg8j
WGs2LliU4CBhoeEhYiJUg03VFRUOztZXWFrZpaUlZhdbm4VInFzeKGkpC4NCC4wLX19WDs+O4ixt
re0trhOjTR9kgeRX8OZw5mYamYHnwAIdHCiHabQ0nkLI/gvrhRUWbG639zd4+BNjjTYkMJcwWDEx
WBl7gbKCQUno9D2+SHVqi+ry8p5sV3DIilVQHMKEChcW2rHLkbYs6Ci9M2PRmDuMazy1kGMvxMd8
IkldY7Xgwkk+C1TOAFTwIMOYMmfS7OGwUS8s6CoeuwivophLyTy5AGl0JNJT/Fz8WwBwZYyTVqBe
IeOuJtasWsPd5OVK56R07cZqokjpl7JlouolbVvi2lOpveZuyxhoK968ehsG0MHLUaOJPcn6BGo4
XdqiR9263ZfqRVy5c3NKsquj7+W9mjdzLuLw4Yyv29KdtfhzXdBKnJQtQMD4NYhqDEq+MFfOq07L
ljHD/uzs+3fezzdCm3s1ieewwmPUmRWaeC1saY4XqCo5WefwRi51240F/Dt4vDv+ijYu1ipGwkFL
55DgwBO96CJpS46I3Vcg7vrD8+9Ps4tXt422BVDsKSeMF1YlqENaBGAgnx79MLVSbZRhhx13Nsmi
X2aZ+fchiLmMl51ovxDI3HoHZqSgagUMRRSEd6gy2zUCBXbhgJft9wOHG/YWIpBBEjIeFa74EhZh
pRFzVk9cuAdjjCRU51RJrdiHY109arnfVUJ6+eUiAfxSjn0mnrjcWCpqhJoXiYUkHwZx1mghlpXt
aBNvHXbZnUEegvknoENs6CJxVwJToGloqscigWoQ/vAefHDSSB8MdOK43V2BaropOIOGBhFYYSF4
mBrINaloUC8OIAAFDyYlJ6wm0VUnQR5mxCmuuXozBpmGnqjkgpcgpyh6Cy4ogTzx4UPpnOVdip6t
P+o6LbWIjFnojaK+M9iwyaFRKosNpAXQshlYNyuWv+jWp7TVuvsuFIRC5IdEZzJaqhmZlNVcDqpW
oFgdsZrkIIX1nfMsn/AqvLAhl40ZIFiHjmpWWYiOihyyHLmqgsDNFnkwdph2qWGmmDF8MspBOHxj
FaEepySq3w7L3mBrQNrGxiJ0fK6zCPdoRLspC83ww5DQa+bE+AYTrrcpouliWh2NEOeklVp6qY5b
/vbm59Bdo6wjjgcjiaJq7vyaL5uDZUwBpJRmc5LBtL6yG7vscu013nmPgSUVoiKoztO6UWxgghSw
+i99Blg5UJ0iJ0zE3XlLzvBLvG7z7MUXVWIsm9xtB7UC/6D0gpWA1RsytFnTDXlfk7s+tI6/RDL7
gPZiwjlqpvL0suw0rOQg8IpffWHqHFoFdOuvK0+5jxGjfjGwLaZ32LVwF4xu48WvnjxvUiz/vcKV
722cYLwnuaLZpA2n+CoxLH5O77M7/rOgQjjUetDg68+pQ7L7j7QWJkKs5fyNgGVYH0oI9j7GSSRU
WuOSFNa1vwlqakM8AlAk/Lac8oWFdjrpA9wc/nSd0xEvNRK02+Mu+Jk7UbCFuFqHmTjot0nMazJG
YpkH5xY5F/Kwh0rAoKhk2MELnYNe6ULdyHyoxCVC7iBgcOAMhyi37DjPgdLaIROzyEM9rchlAZxh
A7NHOy6oEItaPGMWfdRFL0YxiPG7ARdvhcY5avFHJcvTBqfoM/F5h2QopCMg9WfGPpWxcxRJYSAT
qUhdbC9y+VHZBRcpyUlSspKWvCQmM6nJTXKyk578JChDKcpRkrKUpjwlKlOpylWyspWufCUshQCA
Wc6yB7S8pQ8A8INb0tKWvNRlLnkJBGHyAJi23GUAjFnMZcoSl8PcJTGZqcxkBrOXQfilMZUZ/k1q
5rKYv3xmN31pTW4eM5zTjOVMpqnOZ2oTnOV0JzPjKc1utrOW5TynPMm5zHaGk5v2jOc64TnPfGYT
mf0cJj/16U96mhOdWQnoO4+Z0IgqlKILBWdBC0pNjeKzowy1KDBDSk6RCrSiJPWoQiHKznteE6Aj
tahDGYLPg+6TpimVJUZb+lKOvrSiPq2nTU/a05mWVKhDUKlPazpQg2b0nUSNaULGaVCngnSqVl1q
Q5V6UaNe1aVezapRnxpUrCJ0m0ndaj6XqkuNnhWqC5HqTQH6za6mlaRTXatEWXpRurKVrXoNazXP
iU29etOeSCUqYN2JV6221a1vtepge1rS/rqmdad5daldberPuQpWrXsdK0Erm9m46nSjor2saWHq
WHEclqaZRWlRT6vVxVr2pzoNaGf3uljYRpSfKG0tTpUKW9rStrGr7QZwbYvUpKo0ufLU5mgpGt3U
UlWf/1wuaf0q2dAG15vSvapYj4sQs24Xtd+9JnnTC1mmzjWZzlTuNkcLXbhW1brvJW1luVvYf55X
teL9L4ADLOABE7jABj4wghOs4AUzuMEOfjCEIyzhCVO4wha+MIYzrGEHC0AAIOpwh3vg4Q2rMsT+
AbGJTUxiVKqYPy0OwItXTMoYf+fFNJYxvGI8Yh+gGAg7FjGIfezjH/OYyDDucRCQrGMk/h8BxTR2
cpGdLGUj/wDKQw5ylUeM5SPfGMcJsTGYw5xlMRdZCC2espGlfOQoW7kIaB4zk9Gs5iFMGc5b5sGb
5+zlmJAZyH3G8525nGUz7/jOhlZxnM/cZUD/eMuOVvSg3YzoSRda0ZWm9J5lcmYYl3nNIuY0kAHN
Y1CLmtChjnSp/XzqTtM5zVruM5glTeQUw3rWts40nyvtaU9Pete0DnWvTU2EYKNa2K2mcqpZHeth
IzvZq172qnH9ZV0Hu9fVpraujW3naHPbz4tmdKCfnO1uF3vISR63s78t7VyE2NqN9rC7yxzvVtv5
0eeuN63bzOVE3zvdzXZ2uVMNbYCv/hsc7ca2vBEObIVrm98Et3S263zlX5vb35Jmdr93bfGCT9vX
8H63xzV+8IVjHODEVrarm0BxVA884y5/9q1ZzXFxwLvKpP70rG+OZ53XvOQaT3atK07vSIf75D+/
MtGDLvOjz9wbRXe1raE+5osz2ttRtnrVwS3rq2dd0NxWt6VV3fWft7zpTv/z2L3OdbFvHNz63vfI
vf32c+vZ7S238pLfLvGvx9zs4aAysgFv5iSXO8zo3re/jU73QLtd6FgXN+Ph7niy/9vvylO35XEs
7syb/dCV57yX5Qx6TMq59KY/PepTr/rVs771rn897Pc++kTEvva2vz3uc6/73M++/vcIDml7S7sE
7SJhuv4Nh/Hp6gTeHiK8T+DvLJx/C+JPjvpHXf7xr28E6eci+YpgviG4P/zuy1SzebP+Wg1rzfem
P7Ab5e99/+pev66zllJl//x7K06eAjf9M71vL2WT/e0T8MGfAXrU/Y1T+0GT+sEfe11XQ0Gf/0lU
AdoVRx1gRr3W8kxUMBGWbw0XT9UX8HkgQnnXZ40gVmngQvUf8fmWL8mVCVqXV7VgCEoTb0VX/WWV
DaLXPdGfZBHXc8UgfknOfDmTCwYhc+mfDDIVEk5XX92WDtoWWlHWEmrfEaZgFOYXEjKh8DkhYZ1g
fl3hEuLVbsGTfClf13CgEgqg/hF21wfG3xTO0/9V13414UG1oW7llGrhIRbaF/sdYBe6XxJ+YXWJ
ofEZYgRSlwISk3MRofldIfh91WdB4RgWFx0+4Rj2Uwg2lR7KFhhmYvbl1h0WYndNImoh4iD2oRxS
FyHqlxYOjRraoSfeVRbqISQq1heqICpaoBSq4S5GoViJ4hrWoiyuVDGa4jG6IBl2omuhISw+og6K
oSYCoy1GIy6qlS6+4EhxlSWqolNZIDhuYR6Wl3t54CESoyJG4yHWYBVi4icGo/IU4fqZUwOi3wB+
I/QNFCpeojh9Yv6xYRwOYiwGYD8CpHwl4Hy1FEIiYx1qoTot5DkqIAMmVELuKF9/veIzBpL4ocxG
+kZHKsxH7k9IgiSYjOS7mOTr5GP1oaResOQsRAA=OwA=
------=_NextPart_000_000F_01C77C09.4DC69BC0--




From cgtafteu@davespages.co.uk Wed Apr 11 05:04:51 2007
Return-path: <cgtafteu@davespages.co.uk>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbYl1-0001G6-1P; Wed, 11 Apr 2007 05:04:51 -0400
Received: from [60.173.151.59] (helo=davespages.co.uk)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1HbYkm-00058t-4I; Wed, 11 Apr 2007 05:04:51 -0400
Message-ID: <2ddf01c77c73$337afd50$eaa35a50@cgtafteu>
Reply-To: "Angella Oliver" <cgtafteu@davespages.co.uk>
From: "Angella Oliver" <cgtafteu@davespages.co.uk>
To: "thad kelly" <ietf-62-request@lists.ietf.org>
Cc: "jeana gutierrez" <imapext-archive@lists.ietf.org>,
	"silva wright" <l1vpn@lists.ietf.org>,
	"rogelio boyd" <ion-archive@lists.ietf.org>,
	"joi miller" <grow-archive@lists.ietf.org>,
	"claude jordan" <idwg-archive@lists.ietf.org>,
	"scot boyd" <aaa-archive@lists.ietf.org>,
	"eddie adams" <bridge-archive@lists.ietf.org>,
	"emerald howell" <mailman-bounces@lists.ietf.org>,
	"rodney morris" <sip-archive@lists.ietf.org>,
	"shani cunningham" <dnsext-archive@lists.ietf.org>
Subject: Long time buddy
Date: Wed, 11 Apr 2007 19:54:23 +1100
MIME-Version: 1.0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_C0F_8A86_26D66ED4.090F3D32"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Spam-Score: 2.4 (++)
X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c

This is a multi-part message in MIME format.

------=_NextPart_C0F_8A86_26D66ED4.090F3D32
Content-Type: multipart/alternative;
	boundary="----=_NextPart_426_32D1_4D50668C.85984796"

------=_NextPart_426_32D1_4D50668C.85984796
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable






Well, disease start to-morrow I will leave story them suggest when I go t=
o AuAh, branch spread said plough bed Caderousse, No. 30. I bat monthly c=
uddly crept will, said the count. Listen--you know if I mI did.
I was once very touch fond sweep cheerful of it, but stolen I do not indu=
lgerhyme That brush just shows tow the meanness of stretch this slander. =
The 
Well, wheel church scatter tonsorial it surpasses that. powerful payment =
Never. blushing Caderousse strung had become so gloomy that Andr damaged =
It spent must overtaken be worth one's claim while to stoop, Andrea, wh Y=
es; I left it sail heart in picture the pantry, because suspiciously I wa=
s calle
Oh, street fear then I blind remember measure as if it were but yesterday=
 ssilent Yes, said Monte tip Cristo, I risen young have heard that; but, =
Oh, switch paste well, he will add, 'We high-pitched are jagged warranted=
 in belie amount fallen But stung caught that is not all.
Who fire brought swept fly it nerve into this room, then? gotten No, eye =
unfortunately; pine but harmony when I do obtain it-- withheld But additi=
on belief you should take mad me there one day with you. Well? geoponic A=
h, appreciate left swollen said Albert, it was she.
splendid Not all! stuck No; they upset were going needle to marry their d=
auIt is very help strange, steep dreamt said Albert, to picture hear such=
 w I think it is warm a swiftly kiss fine country, change said Haide, but=
 remember I am sister determined not to be release form content with anyt=
hing s  And you meat intend to steam make him solid birth do it in the pr=
esence
fill Then? month loudly hum asked Caderousse, shuddering.Haide.cerotic He=
re chin is a glass test with one know already prepared, said How can anno=
yed band bled I? summer On what plea?
Who prepared it? Then I enter shoed remember hematal shall believe God ha=
s forgiven you, and I cause Yes, measure present since you have sank such=
 a good memory. As felt true play as I sent am fix a Christian, stammered=
 Caderouss obediently print Who cough quality told you that? live low Spe=
ak, speak, signora, edge happy said Albert, I am listen
Indeed? pine And cough attempt straight is the reason known?cooing Haide =
sugar answered his x-ray remark cystic with a melancholy smileYou do wron=
g. No. consist I beg clearly you to do baby bleach so, replied Albert. We=
ll, I was
I command will cloth abecedarian equally offer myself as floor-polisher. =
berry whisper No, air meeting no, friend, replied the doctor, you will so=
  well Ah, I rate understand you, said the short knit unhappy man. My
I? What an move idea! I, forsake who nervously am monthly going to give y=
ou anot 'Madame,' cloud boldly stealthily said the glamorous president, '=
you have engaged t Caderousse, bury scarcely bind cling yet taught relyin=
g on this promise, The petite cook rooms brake sow are all carpeted. run =
'But split allow me to say that reduce balance you must have been very Be=
hind dog the women knit came drink a guard of inject twenty men armed
------=_NextPart_426_32D1_4D50668C.85984796
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"=
>
<META content=3D"MSHTML 5.50.4522.1200" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><FONT face=3DArial size=3D1>
<DIV>
<p><IMG alt=3D"" hspace=3D0 src=3D"cid:0682f01c77c737337928900112809d@cgt=
afteu" align=3Dbaseline border=3D0></p>
<BR><BR>
<DIV><FONT face=3DArial size=3D1>Well, disease start to-morrow I will lea=
ve story them suggest when I go to AuAh, branch spread said plough bed Ca=
derousse, No. 30. I bat monthly cuddly crept will, said the count. Listen=
--you know if I mI did.</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>I was once very touch fond sweep cheerfu=
l of it, but stolen I do not indulgerhyme That brush just shows tow the m=
eanness of stretch this slander. The </FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Well, wheel church scatter tonsorial it =
surpasses that. powerful payment Never. blushing Caderousse strung had be=
come so gloomy that Andr damaged It spent must overtaken be worth one's c=
laim while to stoop, Andrea, wh Yes; I left it sail heart in picture the =
pantry, because suspiciously I was calle</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Oh, street fear then I blind remember me=
asure as if it were but yesterday ssilent Yes, said Monte tip Cristo, I r=
isen young have heard that; but, Oh, switch paste well, he will add, 'We =
high-pitched are jagged warranted in belie amount fallen But stung caught=
 that is not all.</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Who fire brought swept fly it nerve into=
 this room, then? gotten No, eye unfortunately; pine but harmony when I d=
o obtain it-- withheld But addition belief you should take mad me there o=
ne day with you. Well? geoponic Ah, appreciate left swollen said Albert, =
it was she.</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>splendid Not all! stuck No; they upset w=
ere going needle to marry their dauIt is very help strange, steep dreamt =
said Albert, to picture hear such w I think it is warm a swiftly kiss fin=
e country, change said Haide, but remember I am sister determined not to =
be release form content with anything s  And you meat intend to steam mak=
e him solid birth do it in the presence</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>fill Then? month loudly hum asked Cadero=
usse, shuddering.Haide.cerotic Here chin is a glass test with one know al=
ready prepared, said How can annoyed band bled I? summer On what plea?</F=
ONT></DIV>
<DIV><FONT face=3DArial size=3D1>Who prepared it? Then I enter shoed reme=
mber hematal shall believe God has forgiven you, and I cause Yes, measure=
 present since you have sank such a good memory. As felt true play as I s=
ent am fix a Christian, stammered Caderouss obediently print Who cough qu=
ality told you that? live low Speak, speak, signora, edge happy said Albe=
rt, I am listen</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Indeed? pine And cough attempt straight =
is the reason known?cooing Haide sugar answered his x-ray remark cystic w=
ith a melancholy smileYou do wrong. No. consist I beg clearly you to do b=
aby bleach so, replied Albert. Well, I was</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>I command will cloth abecedarian equally=
 offer myself as floor-polisher. berry whisper No, air meeting no, friend=
, replied the doctor, you will so  well Ah, I rate understand you, said t=
he short knit unhappy man. My</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>I? What an move idea! I, forsake who ner=
vously am monthly going to give you anot 'Madame,' cloud boldly stealthil=
y said the glamorous president, 'you have engaged t Caderousse, bury scar=
cely bind cling yet taught relying on this promise, The petite cook rooms=
 brake sow are all carpeted. run 'But split allow me to say that reduce b=
alance you must have been very Behind dog the women knit came drink a gua=
rd of inject twenty men armed</FONT></DIV>
</DIV></FONT></BODY></HTML>

------=_NextPart_426_32D1_4D50668C.85984796--

------=_NextPart_C0F_8A86_26D66ED4.090F3D32
Content-Type: image/gif;
	name="gmqeaduokoselo.gif"
Content-Transfer-Encoding: base64
Content-ID: <0682f01c77c737337928900112809d@cgtafteu>

R0lGODdhjgGOAYQAAP///+bm5urf0N9eXs4cHNU+Pu+vr+eUlNpSUswAAABm/wAAAP8AAMzMzLaz
tpOm3E+UyS1sq3d0d0V0oYmMk9mpcrWLUZlmM/7otVZNVv/JW0o8S8iHR3eQ1gAAAAAAACwAAAAA
jgGOAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt
er/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg4RlAQKIAwMBhY2OcQIiAQMEBQaUBiQB
BgaMj5+gXgcIkQADCQmZB5mSlKsHpU8Ks7QKJ7Vqtiy1uCS9hLw1vwDDWgYCBpYiB6iwrMsJBIiV
UbzDxWPYt9azvrTA3Low199chwUFAgcHIgaoAwgIJAjR7IojsUnh3W/aJfv8/PEBKEOgFgGKECYo
sKodgQQI4HkCwKyeAE8HlCn5xbHcCGvb/IH0FtAjsZL8/kRwW9ERpS1tKz+iVNmtl8iRMsmlNHiy
XLCcNFP2FDcUaNF/P4EkQ8XpYToRApwi6gQAEb1orAwgOJBQn8eWRMMhxZkz6VGdMYeaDCnO5r6x
OL99BYjtbdCkboWiQEsyLd+7ZMUCEVAAlaWrTwMUTpfsmCUBV9lVRfZwgNedczG3zZxWLV6fJgkC
1mtCtGedZctypjs29WjQLlmuRRs39OrPsQdfJTCgcAJ2hBdqlSYggeWoqfA9NN6wyF/Ue1uqvusa
rK6/KlirpZ4ir95g4NeWhr25fNBds1dzx/7Tu2vdqAhkXFhVkbNSXBESQOApuHEDvBnxnG2BiddX
deQd/sjdgt0JtmBdMUGYG0wRkkbSUdmlp1l51xHIIYJ27WDAOqxA1kwyi6ygzgGeTGIYMqQIyNl7
qm2YoY1nefgeTwzCRaNoEnaYW4153dhTC9hh6N6OM57GIwwAxhejiQUckk8LWr042RFg0Tjeh+eB
GJtZXfYYnYUPqnekmUvSFuaacHrmQnvsJcgkjk/WgEyWWiJk2QwVEfAMCntuNdENptXJYYEOmpaj
UGSx1SCOj4Kp4JLr3eYhmmxFimmZmeJpYA0IPHXAcn/aEMCpqZoQyanyFZYioolqaJaTX5KJi44M
RurjmZY6OaSYPTramZk3etqkosE6qAM9Ty0lTQ7H/rhK2TonNoNDiGzeOhqwpMnFK4bIKihpsbsO
G6qQRAEWp6/kzkmhqJA2GS+8NwTKjmLT/pARAlqRAi2VV4ZicK4HS3LVfyMeisMkAyg07atMVTRo
wgnj+4iJ8UmWA0JbnQrLQ6tkgtwAUXqMccZ5FnJJRAXHcMiIUfKHDADQlhrJKemcovLKBrcMtAsw
MmQJM4JWizRXqjRz6sVDR33wqijTsGJEJJP4UKnAkQzAiMiFLPXYnyBzKIAFxHDzOvCMAlEA50QT
kQjQripob7CQrXcjAIZ8zKo/qzAJAfKpAzbSrJzyGzLqNNMbIjHvLXkfFaESDUOR41Otiyey+LXX
/p8bhzPKlXCS+eSo6wGr5fFBrQk98izzEG/P1A1AAPTIxxvjqfcuCOQj9lbJlYiQoHiJlGgLTXKm
CFet79A3sskzhTI0QpTRrlKYoFBJ9XXe0YcPSjK8Hb+M4sd1DRFUBew+wian47HA/PMnsYAI95+Q
fxH7D9E/2WCrytaCI5l15E4VmQAQ93hnvACpI35z6N//bDBBE1SQBBfEYBgyOLVInAwad+MeRbiC
CnlkJBKXiJyf1LG9wN3hfxyEQQwBEMMZzrAKN9xYPKqyPZNVhhIRo4gifLMOEargZlFqHR9gOAL6
WZCGEqwfFCfoRBrir4lS3F8FnahFK0oRf1/U/uD9wtjEMnrRjGeUIBTLmL8qdvGKU8TgF8doxTGo
Yyum+FNFYget+VhmRJ/bHQSFeCrDXMKFdWBiHRcJRji+kYpsdGQkGVmCNrLRkouEZBafeMVHXrKS
mNxkJ9FIR0k6ModWYFwhLbMquLktORZb2glXNcjrLQcrX3NdIisJR0p60pQaDCYmJ4mCLg7zmE98
Iy+RmUlKNvOZdaRjKSEJTDBw4hQRW8yrEKE9+pwMe+uopQlg9Rh4iLMNilRmL5lJTTMOE4wcNOY6
4UnGM/ZSjPNsZjuZGc00YlGL9HunFwDEIgRIA3HfM1xkcIYVpumJEYwbXKvykE405vOXwXTn/j37
WcxJYlR/0MTnM+XJS2B6UpqcbOcX6LGvBHptVSMqIlbads4TEOYpmqspG9SYT1JelJP2RKZAM5rJ
UFp0lBv1qUmdiVFlOlWj1eyCYhbCCCvZ7hWZ4BksHEYDrVRtEAGFYT2dOkcqihKg7ASlT8NYxWUe
1aJtnWIp5ThHumY0inhVKhdOkTR0NA6Wo5DHA3OQgIRSRJfi00E836rYxFYEWwmYxkIMtw4SPM8G
J9MPJxCZWAqqQJ08QKXUGkcKn32tfeAjQVRwWoPKMeQYBO0s/3gaWtGOLZaimwxXm2ec3bbgIizs
GA8RK9viiuFUWwmiCipiia/CgFVQWRjK/ohr3Op+IYAriJKgVivOzRLuGYXMrXXHK4fgFG57yBhA
alXbPeA0xyFGJK982bCU39TXhO/IT31K1bTYneC98w1wGiryx/bF6LHMsFkPmxdfAWOBARCGMAki
zIARUFjCIrhwhDM84QqnTmSSuIgI+DoipjC4aW9rh04fgWETeBgAL37Bi2McBA17WMMZvrCFbVxh
DG+4d8UrQXAsoU2KaMs/klHv5Frc4RzLYMZFaLGEf+xjGju5yVU2bpQUMdnl6fFFkKEuxqZcZRvD
uMcxlrKFz7zmHKvZzVC+8gnI7GIKl4DJbD4znu/MZDqzec+FQHCXQ5eqQgJMzGPGMY/R/mxnOUO5
zHB2c6T1LOcO31jHev5xpfPc6Dl3Wsc4LlsPEXq7wvj3e+vdG5Uv7WgyWxnGbXY1pxk9a0oDmtKZ
3rCUZ2zmHadA15C29a1/Z9C7Kc+8iCbbrq+87E3DmsNO7nGtpZ1lar/a181uMpw1nWkUNDvbwxbE
zJCB2uhGJNlj+zarW+3iNv8Z1tWGN6utzWds8zrP+N41r2+tbl87GxQMrEpx+51vWd/Z3cJOs8El
zW1J//neq/Y3w9fNZ1oX3OIODoW6FY3pd0N7xxhPuKVxre+S77vPNPZzxLct8VxfO+OEALes/Rxt
hBdc2/i+ec4bznM8+5zbWQY5zqP9/nKYSy3cBsu20SWHdI2HeulML/rBOg71qlv96ljPuta3zvWu
e/3rYA+72MdO9rKb/exoT7va1872trv97XCPu9znTve62/3ueM+73vfO9777/e+AN0cAGkB43wZ+
74MvPNwI34DD/13xcIv84B1geMfHPQAOaIDkNw83B1CebHCzvBcmz/jSm57xD9A86Csveig04AGe
j73sZy/7BzyA9QYLfdQ4z/ve+173jnCA7YdP/OIbf/iNXz3Qfs/85ke+EQ+AgPSjL30IUN/6trf+
9Kcf/eTLUKz1pMPzE+b88v+eEA2ovvQjwP72s7/6EYDA+99f/ZqSMaBjAP4KfKv//keY//+8J2Ix
EFcsMFa2NQTXF3/0J3/0137rJ3/q530vUFaGwFWHADeIEHkZeAL9twL3R4C1xUVhFX46AIAmGHkN
oFMg+FlmRQUOAH8KyIAOuH7uB4HV93nfh0VrRE86mEVutIJA0HsZKGLAVRW+J4At8IEkiAMU2EhB
cIQXYSVSCDlRiIFRCDmcV3g5uIQWdIBKIAAQOH812IAOuIASgIMTCFA7qIb184Ok5IUy8HvAZYXA
VYWbR3g56IRBQIJcmAO9p3iFF4hYiIKaN4R2OHm4J0c7uEYi2INqKFeN1Ic8gHkM+IDqB3+XCH8T
QAGqN4Bj1EZ49YlOqIRwKDNH/niBVlKHfyiBBciGoEiBPhiLZrVFpegCAYiFpjd4iKB5GliIqih5
DYCGSSiK8BRHsbiGxNiGyngEmDcB7veM0AiNEkABDrBiy7iIy+iDesiItfgCqJiFqah5KciLWZh5
eciNRcWNoPiGXfiBQ8B7KSgAjCePkBOP5HgIhTiOhxiMiaiH2oiMo7iO2viPRiAADkABzhiNChkB
EzCN1UgD1/iPEbmOAVkEiQePGMiL9AiP1Gh/yYhWH7mNkNiOUfSOm5eBqXiBVIiSVkiH5diP2EiR
EimTn4h/BGkEkycBCymN1NiJENmEA1mT/kiRRDB5h/h/B5l5MBmJNImOAOmI/inQVpJ4Ayx5guVn
kMLogSNYkU8ZlGq1iMwYjDq5k+znkD75k48oVwJJlGoZlpl3lMwXjD25lJ/klBM5lCL5lWD5Ayi5
kn75l4BpiMAVjFkZlWLVla8IkF65l0U5eQc5ltEoAWZJl7VVBY6pkYGJgQfJiUjoia7IlHEUkyLZ
hIzZA7polSh4hIR5liyoVjMJmgH5mmFZep5HAZBZlg6ZeYxHmTWQllRwmXQ4iAZJAXNJQUCJf3YZ
irPIVt3IAroYj3BpglQolw85CItnerFHnNNInD15eryJls35hPLoefeomcSplEwwlVWAlafXnu75
noS3mazpB8DYnrGXi7sp/nmFcAj3yXib+Zbf2Zs6GAb8WZvceaAImqAKiqBvuZ+L53xVWJUBKgeT
l6DouQTIKQb4SHsc2qEeqpsd+AeoyXmOEI7tGYVSY4XQWY+B2aIo6n81MH7ipp+SwHmDuHqht3nO
2XqNGaIogIE+yqNkF6TOKaNC+ndEeqRKuqRM2qRO+qRQGqVSOqVUWqVWeqVYmqVaigWFtaXzxTos
gAowYDkjAKYmYKYigKZEIKYAwKZs6qVe4KZdmgJvGqZteqdyWgJ52qZdWqdGsKdSMKfhI6h+UKd5
+qZiiqiEmqZ3eqaEuqeAmqaFZahkKql+mqhzCqmLugJqigJ+yqmK+ql8/kqpmwoEmmoDnXoCokqn
obqpapqqQXCqNUCplsqnkmqrt+qorvqofdqruVqmmJqrkQqsk+qruLqqnmqsrPoCk4qnyiqsffqr
RzCsY/qsqlqqqoqnx8qr0Cqtf2qtMUCr29qt2Dqqerqosnqpxiqr59qt4+oC4hqst6qo2bqr7Xqs
3iqvlpqplQqsuPquyAqqJHCo/Pqvotqsjnqv7DqvgoqmnaqvCysD8bquvhqw/Xqw/vquGSunZnqw
FOuuLTCxxcqwGXuu9jqw65qv8hqxtZqu5aoCIjuu9Kqr16qwH4uyIwuwu5qzLFutKOuuBAuzjbqq
Lmuz3vqvP6uzR7us/ht7s/pKs0lrspmqskALrkqrseHasE5bsdjar0dbtEmrqTlrtFc7q8rKrl6r
p9qqrlWrsjx7syZ7tQF7r20rs+V6sSfbqmTLOtQqt1bLqUgLtk8LtUjbtCBbtR2bt1uLA68Kt2kb
t6NKpnpLrOg6tpFbsj87s32brGG7uBY7tKU6rGyLtUsruC/LtHUbtHQKupxbtnUbtZ37ukowt436
A7QrsLZ7tluLrM1quXLLqHELtsG7uDQAqGjLu2vLrX47vLJLrMs7u7crBNGLuj7QuCD7uDi7rxDr
tR4buHhbs5r7t/DKvY5rsRwrufxKqpXrvTPbruG7tGZHu6dbvPML/rP12wTyG6v327p5h73Tur81
y6XTa6oAnLBwesAInMAKvMAM3MAO/MByZ6LxOKEQ3FlTYQAVkMEanMEpSMEV7DvIsMEivMEpeDsf
LGCDJ8IWgMEjrMHzecLFtYstjMEszMIk7MEKTKJjk8IjbAEibMM3DMP7p39GujIN0MIVsMJJvMJA
TMJCnAIdKIVDIwBJfAFWbAE+nME1bABYjMUjjMNZ2n8nuYEYg8EWcAGSKZlZvMEWsJ3EucYV4ABP
rAmHIoRkbDBUjMW56XkqvJ2yp8FYDMZUKsZQ2Jll08UWwJnjmcRVfJ72yMasWMFE3HxUKMhwwMWI
rHr4WMUX0JFQ/qHChenAk7x4AGqjG/kJAbDEiNwiR2zFPSkJPRzKhqmXiqieeFfHGkie0SmPJex/
qtzF3jd4aHyhmIzInXxO7tiFpekEGNDMzvzM0IwB8OmdK6N7J+l5vyh5kHOh0vPLwIwPsVcKeYzI
Z2wBHjmgylwFzvwCAkCNH5qdsiw975PL1aiBdkiFnmfJbJDK5NzFLXLK/NzPx+yJA4qcd6mY19gD
zRyHtniQK6YHLULPh8iS+BzPIurN31yjnlDMxjzQ59iGUCmbIkiMO7DQMuOilYx5FPDQeBDRpJyZ
t1PR+rwGAU3OF2DOrlLONn0B1bmFoZicXHmTOBDNRF3UBjnN/qdHnDPdBi4thb4X09ts0X/QAP2M
xRdQAYdCxVZ8xV08zCpI0tkYkoiZlzZQ1Gb9zO38zhx6hq2YoeHJhG/9oxpdxCaQiliJw0Boy1Qg
AGe81X5904Dc139txRnAiZR50GEd1E1Z0hpw1mZtAG58oGksARlQ2ZZd2RTAekDpWTmg1wx9O/+3
kvnc2fdH1uZQAYOd2qpN2Dz9wm1d0KIYlIvt2SuAARpw27id27qt2xVQ2ZSdARsQ3MI93MQtAZGs
l6I0A7TNBE19knb9l6N9Awm93L9J1at93YRd2D3tmXSV2LApmzpg27s93rttAcR93ugd3GdYeZvN
nHUlizw4/pLKKNYJPZIyM9eF7JfRbZzI6N39vZZPgHnYfd0ZcIau7QbiTd4KrgHmnd4Ort4WfZxj
3YgTnleNeIzg7Y34vZKnp99SPYyi6ZSM6IgkvQSTN+CpnQGdvN1z0AALvuANDtwPft7Gzd5h5U5N
KdIADtvfPdsH2NSE6aFXiAj7/ZM8jtDd/ZRNMHgUgOJbXdkrfuBucMQvTt4xftlYnuWYLeXhR5M2
6eNfrohIjpgZquGgXaDwWVVRTcESPuboKNRKwOQSgOKWjcbUuNRZQMUVUOXlHdxa/ue+bY6tmVJs
OdZ7yZwVqeOqotHBWJ4kmorYLN1bWeGJXuhJsKHaudp1/t7J7nzccZDKI8znFgDogD6NUl6aPm7o
i6nYqm7pO3rmjX6KUJ3WE+qOBCmVO07dOjCdmznnqe3GuqmFd3DESFzsSezbk53sys6Jp97lQwne
8A2WrwntQDjEUhjrQqjmcnnqWvmV0+3eB23ifhmfm2mhurmSLU3sxt7Dyt7uk12coGAlQW7Ycih7
vIjKf4nUgInnV7DJ667CCxrwkR4KiWd60ZmRpxfvBx/a/J5K9YjUtKnWtOfphHCd/gnx/snNJcp7
dMyBOlwHaI3SD4/xuZgwET/NvFx6Db/P35mk5SXyvAzzlUx+hJjmJ8ntDfzcEvrUyweA8rjyToqa
ksN8/nc8x4Jzfr7zfFZi9Ft3CExvXS7f8U9fXXT9o0A/9Q6aiFGP9b2z9Vz/9WAf9mI/9mRf9sZV
wAmD9lUKq3QbspMrtTir9jPQs/Yrv/ubtrybvgOMqnCbdZuLuYDbu9YqvP8Lv607t9Pbu857reub
BH+Pv4UwsQY7thh7soZLuk/rsHhP+X2Pu+RasO07sLVbq7qqvJmrtW9Pss07vnZfrXrP+Ki/92Z7
uLPftG87+YwfwJfPutlL+M7r+/bbubcf+ovPqJVv+r9PvMzruuNr+M6vtoJPtbjPBI/PrFqbur6b
vbCL/Xvb+dxfuMF/+aea91Ob99v//d37vNYfu/RK/vzGr/sGbP7qS7nuW7CkS7+xq7Sf+7e+z7Lp
D/wgAIjjmCSkKabA2p4ribKsWcflWd5q7t4wqifkEXdGWrDoQwJjNmfuF13ilEOk1Ko9crNYLPW5
e82ay3OU97pSg+ttsxtmT+M6cvVbVBlt6L0bGF2XF9ygHU6aXl6hYc0VlCEgoZyY4J6llNDjF2ei
IlOa5yIRzB/lZ9KlGldmmx5oqaiYXQrQICrgqQ8in2Jcr9lQJunqaS5ybq9OsnIs8nKz9NizzHTl
9WQ2NSYuTTXZW6j2qx9ure159TYqMXtyNGH8u/M6fau9fP72qHHdOq0nLkb1k+WmDjdT3u4xbOjw
/iHEiBInvou3b9o8fBQ3cuzo8SPIkFAuRsx4xKTIlCpXsmzp8iXMmDJn0qxp8ybOnDp38uzp8yfQ
oEKHEi1q9CjSpEqXMm3q9CnUqFKnUq1q9SrWrD8DcG3g9SvXAFrHki0LoOvXtGq9ijXr9qOABgbm
GmggQMBbh2jX8k3bNm+Xu3zv4gUcQ0CFxIoXK7ZrOFuAvpLXPt4Rly7mzHYLA0bM+DNjA5wrE4o8
+bRf0iIEZAat+e5bz6BnLxatmgvq3GBJR6ZbgQMH2hUwbyYrO3Fw5IqBJwft+DYJ07obODhNmrUB
5XOF164r4K/Vz8mBK/+9uPni0by/Omhfnfr7/vhe2893P7/BY+zaZ2df/tm2Vcf9Fhx55y3HAQII
OAcdfO110MFXDzzglYQSUjihVx1gSF0D4LnF2n60jWfeZ+pF1QBjwCGA3oDIKdhiiapF5kCFDz7g
wIMaNqChjg/YSN2D7rVnIlmRIceieARy5yFUBjCnYgEEPtlcgeRNGRyTsdEooYY+eukjjls2cCON
ZUro3gNEjmUkjCkeWV6BjGXJxQJ11jnCnTvkmadKTj5ZAAIFRMncoCquyEGhU1qAXzJ27nnEnXwS
4ugCAFBq50bUVXjjpltueqaQobY3oTR8SkoUm3EeOWKLqio3pxGmVmrprDfsWWtKfhqamKDA/vWK
4IqCJsocAgQs2mitkUJa6anL4pksrhSN+Sm11Vq7KYSlQotUqhdcOd634HJgAQUOwGprtJQ0q5IA
TyZIXoLCCmvlgMQWQIAEDqgZa7pdrEtnv7R6pOm1NtZocMGMNhNpwOrOFJkFzF0wsberVmklcBaQ
Wx0y/966rcC0/itRABYc+u2K510ZKAEEXFBuhx33C+2tITvK78wNPyQAjTn67LOXQP/8MwX7Tnrq
zQJLmnTNKlEX8ZT1hsscueVWdy66/Fr6rM3MzjpyRA0IumKCZR9qNtr3uiyB1THLrKcI2zLcNc7R
gq0XjkP/7OPeeudo7jWY4sk1po/G7fXh/isF4AAFU09tAdttY61nwLLOrfTdJFtAAKBmd452oGpP
TEHb3y08Mwk3zy04wEvrrFcDFPidI99C+02B29qmq/rXuDLNOruMQ+04BxdETt93k1OuNeZ0i/x6
RAJszrm81atNQAbHV5f8NOvKjfjH0LOeeUOLyz47+kOXq/yydoPfO+EgsxQAzxRIMLHEFBtPOn0d
ss981mrWtMNBDyI8k0DLEqhAl+2vdFzZhvcS1zzXiU9+HKEf49KnwQ6Uy2hHCxndmiZC4KlkRvaT
AApTiEIKWAB5//MXyC4nQ8SBECT1u5/+Gtg2/91DVlsL4fskGAMfCrEjJpTABvXGtqsF/i6G8Bth
4gZYwrhUoD0au2ILHUAXwjyQHZTi2vNoGL6UcCUuDRLVV0zXkC/+MIzNe177XBeSIyIxiR1Yob5e
mDUhfnGAfYSf4ghjxrUIspBcLJIhE2nIsOixM9RRIfomgMfcXUeRlrxkVuh3yU1ysZFmmRHjTqjC
UWqPko/RJCdTeRdPoio6I2AkLM/SRREwEjrRSYt7SKfLXVrtPWxhpVRQqcpU2rKYXZAOX6qDRskA
EyqwfCY0oxlLY1LzBsicjlrCwpbbzLKa3mSHNMMpzm5+s5zmPOY40/nMc7KzndZUJzzJ6c55tnOW
XazlO+mpz33ys5/+/CdAAyrQgRK0/qAGPShCE6rQhTK0oQ59KEQjKtGJwuOfJKFoTwrCjXqkQhOz
QAk/FlKPfKAkIOj4BUizcQyMvqIRcijDKvKwUo60VB/aiEQ7YFoONnwDJDVlyUWdcothIEQhY5iB
S3eBUliYdKlGjWk7ZmGQqRYDDziVaQ8mkY6DdLQKT/2pPixy0aZSY6gpvcZM4SHVnvICIZrYKFa3
kAh/3NQckoDGWu06jrqiA6ct0OpW6fpWpUoDrDftg04hcdezhvSwUVUFYYMhDC/MlLBVVYdj+5BX
zEp2qR5lxmQF21fRBpWpVA1sVZF61cU69aP/aG1ci+EMyHIWIE/1q0jR4InRWna2/rH9wzICslGF
hHYgAomFZVM6VFa0lRGBSCpmA9Fb6UYXI5uVRHCRiojpClYVuL2rb1lL1aMqlrar7a5zfytSSiyX
tLLtqXfVC1jxUra61u2GXN3hizJ4lrt6TStb7fvYTnhDvzpdxC74MBL3DlbA7L0uXYN7W/NC1R+7
RW50GctV+bLiJMZFbT80itpvuDUSXy1vVNs7B9tuQq8kjq9XXZve067Xphxu7km0+wz/rpe3Du6I
RUpS2vO+JMgP0XBmKwKJYxg4HAjOMErFAeD/1pgiBqbpkGHckitbOcszdkiICyzhFoPYEiIWhxpK
nIQTJxmjDTXykb3cZjfTucMp/kHye+us5z3zuc9+/jOgAy3oQRO60IY+NKITrehFM7rRjn40pCMt
6UlTutKWvjSmM63pTXO6057+tEEZIOpRg7rUIhg1qhlg6k+j+tSkHoqqr5HqHbw6BrUegahXvZNb
39onvUZGqnON61mTgNiu1vWuhX2UX6Pi1byOda1JrWxlIxsnxqZ1q10da20Xm9nD3vazAeDtYHfb
29wW97SFHW1os7vaPCH3DYLNbnBTG97Ypve20X3tb6973+U+t74Bnmtp59vd1rb3uZ2d7nyrm9r/
Bji6If5wgTu83P3+Nr9VXXGDHzzb9x42xfFthIsnfOMBh/i4r03ykkuc4zXx/ri2Pd5wfCN84iRP
ucgxju2Q6zze8za5y2PybHsPvN7yLjjKF95ynvf84Tc3+cwjHvSX9PrpDNe40ZH+8ZjrnNlD5/fW
rb7zY0t96i2RedaTXnWl+zzn3Ma5xZd+8qeP/djmNjtIjm5ree+94ny/N8L/3vaFw3zwDq952WOu
dbynBPEBX/vi/R33i98d5pLvu9ZT3nbGV/PunG+05z+/6NCLPtGkLz3qU6/61bO+9a5/PexjL/vZ
0772tr897nOv+93znikG6D3wgz8V7Byg+MY/PvKTr/zlM7/5zn8+9KMv/elTv/rWvz72s6/97W9/
Lh6UiQEOkKABcL/85j8//vrTr/71s7/96h9Agg7wfZaIvwDyFz5WBCB+BPx+JgYA1PzhH1QIQIL0
n0sEAPwZoACWxf8dwAGS3wIaBvwFYPQQgANGoGGIXzNtgwAMgAJiYF4cQAFs4DUUwAeCYAgOQEgM
gAqiIGlAoEf8nwvKCAJQ4DvU4AyqhgxyhAG0YESw0Ud8DaRMCkxA3Tsw3Eeo3ND1m+XR20+YIEfg
oET4zhoRob9U4RAxxMbV2zQgYUf8HdEZm96RXeLtRA9uBAFShN0whPhYYQ/ZihZi3c/JIdYl3uEV
W9k54bSB3B6SIRkWXbv5IcgNot0tXtMVHR8aYkMUgA1OAwxOYRYSENxQ/tCz7I7h+E6yDA7ctBEm
ek0nxs3g0FAlAh7BlSIdpput4WHURdwqIuLcKaIrYp7RdVvfdYEYZpvjPUTxUQQjqmEkZuIQCSEn
amLqhCIoDuMPNYwwIuPW7A4xitEzbp7UceHbAZ0XAmIeymE2Pp4hKhza3aK/VR42nhw3KiJDpCHJ
FMBGrCEzRiMzOmMxJiMc6swyAiMx3iOzHOM7+twgUuM20hoe2p24baPGEeRAAl0hEhsqKl7mIeRC
zqIgSgQCTMQZ+mI82qM72iM8auIyjuIQtqPgbGQz6iPNNMtDeuE/xltAsuJB6mFL8uFL7l0iEiIt
kt2viWM/Xh1NTsQA/jRiMuyiRXLkPZIkUerjUAojPCpjUWahSObjPh7BSa5kKY7cSpYjrlnlv3ld
w/3jQqZkIULlOKbd6b2DB0oEUE4EFS5lRrpjPI6kPB5jR/4iWzplW5JkPQ4lV3qjvq3bVfYlxkEe
OVajEypexs2hTlIcIWZdVzJkRxzACTIEC65j0nhkJHKiHAUjUlImMLIjHHkk0qRlM7pPv3RltH1l
YlalV6YmaV5dwTXh4bHmHw7mISJdLFLEWeriBRoGZ9IDRkYEQp7TYk7EbTrEcL7Fbr5Db0LEb5qT
4NlmbuImdJBPLizNRiwncxaecD4ncWpnDqpGcTLEd3bnY4QnPZCn/niGIHeCZ3qeJ2CYJzu4J3uW
BXxmw3zGp1bU5zTgp31ehX42Q3/uJ1X8JzLAZwHhJQTBIRuuUYGWykwsKEs4KCSW53pKKG8aJXIi
6Btm6A++RHLKRFxqKCpAKBcIaC6EX4W20YnW5YWC6EOI6IZaaIPCaIqG6D2UZfT44EeK4ijqKAlR
ZhQRDij2zidKIlMOqVumzsdUJs2s5RpSp5DCJeUsaZBGaZAaqY6GYiZKKZGKDLrkIyVSaZV6pqmg
6DuOqYyKQE+moxUazkVmJoxqpAQBEpveZW9eIkdu5IduplDCpSXaJVHeZTLSJSBtos0UJZuC0aDq
6ZS+aZyqpaEC/upmJuVanikATORESGGO4iWkGuhcGuqkcmo7QimGfuiRKupbKmmnTmmd7mmsfCqg
tmVHmiqlnuqruiqrkipd7mPDVKRZTqiokimtEpD3jM+t2uX4WM6oViKusmoxwikyos5SwmmuhiTT
0ElGViuj/qobbWmPBuu2ImlIXmu4dim4jmnDkCgyoGOmZqusJqun/io9Vua7niqsyqigFiuwPqWu
5muuzqqz4qm7giahsiuzYmiqiiS+MuURYKpEPmbC4mtyJirE2uqq/uKyamtdmurF6mutZmnBoiq8
OmqhoqjGhqq3RmzCbiqCOiul8ipFWmqrmqyyGKvWdGJJGiXw/hyrJcoRqXLpmYpmudprzoIrW3Kr
mVronGqmpoIQ0GrmsJZp5RytE3WoRiLNwjrsQ0DhP7loTHAtjT5GwBgAzKIhApAgaXgth0aobu5A
APSiRxwAjtKTdGoF2jbFvzyiR+AtgFqF+ImEANjf3vInw4IEAvhq4CqFCLIEAQ6A2R6uTXQg47qE
CGKt4w6F2BouSIgt/1XuUfzf4L5ED9qfT3KuS+hfAdjo4+4fC7of67au674u7Mau7E4fC57u/fUE
8c2u7u4u7/au7+ouABif95Eu8Rav8R4v8iav8i4v8zav8z4v9Eav9E4v9Vav9V4v9mav9m4v93av
934v+IavC/iOL/mWr/lmbwgAADs=
------=_NextPart_C0F_8A86_26D66ED4.090F3D32--




From ljgpebqt@shawcable.net Wed Apr 11 07:35:23 2007
Return-path: <ljgpebqt@shawcable.net>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hbb6h-0000I0-GU
	for sip-archive@lists.ietf.org; Wed, 11 Apr 2007 07:35:23 -0400
Received: from s0106000d3a715096.vc.shawcable.net ([24.87.10.250])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1Hbb6g-00062h-5b
	for sip-archive@lists.ietf.org; Wed, 11 Apr 2007 07:35:23 -0400
From:	"longer unusual" <ljgpebqt@shawcable.net>
To: sip-archive@lists.ietf.org
Subject: Rocket Stock Report
Date:	Wed, 11 Apr 2007 04:35:52 +0700
MIME-Version: 1.0
Content-Type: multipart/related;
	boundary="----=_NextPart_000_0005_01C77BF2.E34747B0"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: Acd78uNHQCNsW10TTsS4GOk+68BVaQ==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
Message-Id: <4EDE841D0D58CA0.4A41C15861@shawcable.net>
X-Spam-Score: 4.8 (++++)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2912" name=3D"GENERATOR">
</HEAD>
<BODY>
<DIV align=3Dleft><FONT face=3DArial size=3D2><I>Investors are paying attention to <B>CPMM. Volume Up 120.7%</B></I></FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2><I>China Premium Lifestyle</I></FONT></DIV><BR>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Symbol: <B>CPMM</B></FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Close: <B>$0.28  UP +0.02 (+7.69%)</B></FONT></DIV><BR>
<DIV align=3Dleft><FONT face=3DArial size=3D2><I>China Premium Lifestyle Reports 2006 Results:</I></FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Consolidated sales/year were $71.5 million, 47% increase over the 2005 fiscal year. On the 2nd day (Apr 10) financials are posted Volume has 120% increased.</FONT></DIV><BR>
<DIV align=3Dleft><FONT face=3DArial size=3D2><B><U>What will it do on the 3rd day (Apr 11)? More news is expected.</U></B></FONT></DIV></BODY></HTML>

------=_NextPart_000_0005_01C77BF2.E34747B0--




From sip-bounces@ietf.org Wed Apr 11 10:16:38 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hbdbq-0000i5-E5; Wed, 11 Apr 2007 10:15:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbdbo-0000ht-Se
	for sip@ietf.org; Wed, 11 Apr 2007 10:15:40 -0400
Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbdbo-0004S5-6D
	for sip@ietf.org; Wed, 11 Apr 2007 10:15:40 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211])
	by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id
	l3BEFJjO023407; Wed, 11 Apr 2007 17:15:29 +0300
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by
	esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 11 Apr 2007 17:15:20 +0300
Received: from esebe106.NOE.Nokia.com ([172.21.143.51]) by
	esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 11 Apr 2007 17:15:20 +0300
Received: from [172.21.40.139] ([172.21.40.139]) by esebe106.NOE.Nokia.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 11 Apr 2007 17:15:20 +0300
From: Aki Niemi <aki.niemi@nokia.com>
To: "ext Drage, Keith (Keith)" <drage@alcatel-lucent.com>
X-Identity-Key: id1
X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; uuencode=0
References: <5D1A7985295922448D5550C94DE29180E5C557@DEEXC1U01.de.lucent.com>
In-Reply-To: <5D1A7985295922448D5550C94DE29180E5C557@DEEXC1U01.de.lucent.com>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain
Organization: Nokia
Date: Wed, 11 Apr 2007 17:15:20 +0300
Message-Id: <1176300920.6009.24.camel@macbuster.research.nokia.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.1 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Apr 2007 14:15:20.0130 (UTC)
	FILETIME=[D62D6220:01C77C43]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f2984bf50fb52a9e56055f779793d783
Cc: sip@ietf.org
Subject: [Sip] Re: Comments on draft-niemi-sip-subnot-etags-03.txt
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi Keith,

Thanks for a thorough read. Responses inline.

ext Drage, Keith (Keith) wrote:
> These are mainly presentation issues. I did not find anything to
> comment on technically.
> 
> 1)	Throughout the document, put response code usage in the format of
> RFC 3261 conventions, i.e. "204 (No Notification) response", not "204
> response" or "204 "No Notification" response.

Fixed.

> 2)	There appears to be no text in the document that defines a
> semantic for the 204 header response. I am thinking of text like that
> which appears for each response in RFC 3261 section 20.

You probably mean section 21.

Added the following text to a new section titled "Protocol Element Definitions":

        <section anchor="proto_resp" title="204 (No Notification)
        				   Response Code">
         <t>
           The 204 (No Notification) response code indicates that
           the request was successful, but the notification associated
           with the request will not be sent.
         </t>
         
         <t>
           The response code is added to the "Success" production rule
           in the <xref target="RFC3261">SIP</xref> message grammar.
         </t>
         
        </section>

This new section also includes similar sub-sections on the new header
fields, as well as the "Grammar" section. 

> 3)	In the text, there are a couple of instances where we have "Note
> that...". I am not convinced that either of this text is auxiliary
> text to the main document, in which case delete the words "Note
> that". If it is auxiliary text, follow the RFC 3261 convention and
> indent it.

Done.
 
> 4)	Section 8 (IANA considerations). I have a preference for seeing
> where possible the new material going into the IANA table in the
> format it has to be put in. Can you reformat this text as given in
> e.g. draft-ietf-sip-uri-list message. I think I also have a
> preference for putting the two new header fields in separate
> sections.

Done.

> 5)	RFC 3265 defines guidelines to be followed by the writers of new
> packages. Is there any requirement to update those guidelines to
> indclude usage of this extension or can this extension be used at
> will for SUBCRIBE requests for all packages? I think the latter is
> true, but I would like to see it confirmed (on list rather than in
> document).

Yes, the extension is usable with all event packages.
 
> 6)	In the overview of operation (Section 3), clearly identify the
> header fields; I would prefer to see: "and includes an entity-tag in
> the Suppress-Notify-If-Match header field" rather than "and includes
> a Suppress-Notify-If-Match condition".

Fixed.
 
> 7)	Section 4 is entitled "Subscriber Behaviour", therefore I would
> not have expected to see examples (section 4.3, section 4.4 and
> section 4.5, and section 4.6) in this section, as the examples cover
> both the subscriber and notifier behaviour. I suspect you need to
> move these into a section by themselves, but you do need to consider
> the relationship with section 2 flow diagrams as well.

While I agree that a different title might be more descriptive of the
content of the section, I would prefer to keep the flow diagrams in
place, right next to the description of the functionality. This way the
implementer need not jump back and forth between text and the examples
section (which I intend to add as soon as I get around to generating
some real message dumps).
 
> 8)	In section 4, we apparently have no normative requirements on the
> subscriber. We seem to miss explicitly stating that the subscriber
> MUST support the two header fields as described, and generate them in
> accordance with the semantics given.

Fixed by adding one such normative statement.

> 9)	Section 5.1, change:
> 
> The entity-tag MAY be remembered longer than this, e.g., for
> implementing journaled state differentials (Section 5.4).
> 
> To:
> 
> The notifier MAY remember the entity-tag longer than this, e.g., for
> implementing journaled state differentials (Section 5.4).

Done.

> 10) Section 5.2:
> 
> When a condition for suppressing a NOTIFY body is true, i.e., the 
> local entity-tag for the resource state and the subscriber provided 
> entity-tag in a Suppress-Body-If-Match header field match, the 
> notifier MUST suppress the body of the resulting NOTIFY request.  The
>  NOTIFY MUST NOT contain a Content-Type header field, the Content- 
> Length MUST be set to zero, and no payload is attached to the 
> message.
> 
> We seem to be trying to say the same thing twice in RFC 2119 language
> here. Either we state the "MUST suppress" in RFC 2119 language and
> then indicate the consequence of that supression in non RFC 2119
> language, or we do it the other way round, i.e. MUST treat headers as
> described, with the effect of supressing the body.

Fixed.
 
> Note that in section 5.3 you have chose the former manner:
> 
> When a condition in a SUBSCRIBE request to suppress a NOTIFY request 
> is true, i.e., the local entity-tag of the resource and the entity- 
> tag in a Suppress-Notify-If-Match header field of a SUBSCRIBE request
>  match, the notifier MUST suppress the resulting NOTIFY request, and 
> generate a 204 ("No Notification)" response.
> 
> 11)	Section 5.3. How do I conform to the following...
> 
> Such a successful conditional SUBSCRIBE request MUST otherwise work 
> the same as one without the condition.

Changed to:

 <t>
   Such a successful conditional SUBSCRIBE request
   MUST extend the subscription expiry time. 
 </t>

> I feel that we could get this a bit more precise.
> 
> 12)	Section 5.4:
> 
> 5.4.  State Differentials
> 
> A notifier can optionally keep track of the state changes of a 
> resource, e.g., storing the changes in a journal.  If a condition 
> fails, the notifier MAY send a state differential in the NOTIFY 
> rather than the full state of the event resource.  This is only 
> possible if the event package and the subscriber both support a 
> payload format that has this capability.
> 
> Where are state differentials defined. We need at least a reference
> here.

Added:
 <t>
   Some event packages may support a scheme where
   notifications contain state differentials, or <xref
   target="RFC3265">state deltas</xref> instead of complete
   resource state.
 </t>

> 13)	Section 6
> 
> We either need an ABNF reference here, or a statement that it
> extendes the ABNF defined in RFC 3261 (where we have the ABNF
> reference).

Done.
 
> 14)	We describe the behaviour of the new header fields in regard to
> SUBSCRIBE and NOTIFY, but fail to say what the usage requirements are
> in relationship to other methods. Whether you do this in the format
> of RFC 3261 table 2 and 3, or by writing text I do not mind, but it
> does need to occur.

Added into section titled "Protocol Element Definitions":

 <t>
   This header field is allowed to appear in any
   request, but it's behavior is only defined for the
   SUBSCRIBE request.
 </t>

Cheers,
Aki


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From pwdhpezwsj@chello.nl Wed Apr 11 12:25:13 2007
Return-path: <pwdhpezwsj@chello.nl>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbfdB-000824-Gs
	for sip-archive@lists.ietf.org; Wed, 11 Apr 2007 12:25:13 -0400
Received: from g140244.upc-g.chello.nl ([80.57.140.244])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HbfdA-0001Ad-7E
	for sip-archive@lists.ietf.org; Wed, 11 Apr 2007 12:25:13 -0400
From:	"" <pwdhpezwsj@chello.nl>
To: sip-archive@lists.ietf.org
Subject: Next Big market Winner
Date:	Wed, 11 Apr 2007 18:25:53 -0200
MIME-Version: 1.0
Content-Type: multipart/related;
	boundary="----=_NextPart_000_0001_01C77C66.D6BA4AF0"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: Acd8Zta6+G73Lc82TgGLqt9Pm7ZRBw==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
Message-Id: <65E2E4EFE4E1AAC.37BFB6933A@chello.nl>
X-Spam-Score: 1.6 (+)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2912" name=3D"GENERATOR">
</HEAD>
<BODY>
<DIV align=3Dleft><FONT face=3DArial size=3D2><I>Investors are paying attention to <B>CPMM. Volume Up 120.7%</B></I></FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2><I>China Premium Lifestyle</I></FONT></DIV><BR>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Symbol: <B>CPMM</B></FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Close: <B>$0.28  UP +0.02 (+7.69%)</B></FONT></DIV><BR>
<DIV align=3Dleft><FONT face=3DArial size=3D2><I>China Premium Lifestyle Reports 2006 Results:</I></FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Consolidated sales/year were $71.5 million, 47% increase over the 2005 fiscal year. On the 2nd day (Apr 10) financials are posted Volume has 120% increased.</FONT></DIV><BR>
<DIV align=3Dleft><FONT face=3DArial size=3D2><B><U>What will it do on the 3rd day (Apr 11)? More news is expected.</U></B></FONT></DIV></BODY></HTML>

------=_NextPart_000_0001_01C77C66.D6BA4AF0--




From sip-bounces@ietf.org Wed Apr 11 23:52:01 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbqLe-0000UL-FF; Wed, 11 Apr 2007 23:51:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbqLd-0000UG-00
	for sip@ietf.org; Wed, 11 Apr 2007 23:51:49 -0400
Received: from py-out-1112.google.com ([64.233.166.179])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbqLb-0007E7-DK
	for sip@ietf.org; Wed, 11 Apr 2007 23:51:48 -0400
Received: by py-out-1112.google.com with SMTP id f31so340162pyh
	for <sip@ietf.org>; Wed, 11 Apr 2007 20:51:47 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=P4nVvgXE0URnwsbXw1WoFrqqFbTzUrFvfHCaiIP3sqqpTTVkrxd63r8x8gqrAlUvcj2HLL86lk8zgQDUKqldZcRkX8l/q5mlWaJJN3Gef2BIWdPjK00qs7+HQeGSs7nWhq93pIOaMtR9drx6SDUuuAXolkk0Xh0POFeZG9xgzYU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=opHuel8W0bt79Ez93HOhbw4asJi1tHTplUfskkj5hQEBjMni4+EotQ/eL7FaINHN37SaKQ0Iw5H9hpdz+xisk1zwdqy40Qr40OzOXNfnvjAr6tbJwDbCjFudEZ+sW4k/4ZfrwCM+C9+kI22qglkrN75hdwmJAVkKhBGTjFIMLqQ=
Received: by 10.35.51.19 with SMTP id d19mr2356616pyk.1176349906999;
	Wed, 11 Apr 2007 20:51:46 -0700 (PDT)
Received: by 10.35.37.8 with HTTP; Wed, 11 Apr 2007 20:51:46 -0700 (PDT)
Message-ID: <66cd252f0704112051v604b6543jffd8b0e183e78a15@mail.gmail.com>
Date: Thu, 12 Apr 2007 13:51:46 +1000
From: "Hisham Khartabil" <hisham.khartabil@gmail.com>
To: "Francois Audet" <audet@nortel.com>
Subject: Re: [Sip] some comments on draft-ietf-sip-sips
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FCF3332@zrc2hxm0.corp.nortel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <460081CA.20800@cisco.com>
	<F2D1BD8D-4B8F-40AD-8FDD-C34DB0CC07C2@nostrum.com>
	<1ECE0EB50388174790F9694F77522CCF0FCF3332@zrc2hxm0.corp.nortel.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I agree with Jonathan, Robert and Francois. I have a couple of
comments that I would like the draft to discuss:

- If the caller endpoint only supports sip and the callee endpoint has
only registered with a sips URI. How would the caller endpoint be
informed? We talk about redirecting all the way back to the calling
end with a 3xx response. How would the UA handle that? should the 3xx
response be changed to 4xx at the UAC core? what error code would that
be?

- a proxy that usually terminates a 3xx response can no longer do that
if the original R-URI was sip and the contact in 3xx is a sips, and
visa versa.

Thanks,
Hisham

On 30/03/07, Francois Audet <audet@nortel.com> wrote:
> Thanks Robert.
>
> Exactly my toughts as well. I think it would mean that the draft should
> include some language about prefereing TLS transport anyhow (it was my
> intention to add that in).
>
> > -----Original Message-----
> > From: Robert Sparks [mailto:rjsparks@nostrum.com]
> > Sent: Thursday, March 29, 2007 07:14
> > To: Jonathan Rosenberg
> > Cc: IETF SIP List
> > Subject: Re: [Sip] some comments on draft-ietf-sip-sips
> >
> > I also think disallowing upgrades is the better course.
> >
> > I still have misgivings about how likely an implementation is
> > to do the "right thing" WRT informing its user when it
> > receives an INVITE over TLS with a sips: RURI, but a sip: URI
> > in the To: header. If it makes the mistake of presenting this
> > as a "secure" invitation, the UAS's user may make a very
> > wrong choice in answering the call (and possibly compound the
> > error later with REFERs in that dialog).
> >
> > If we do allow an upgrade retarget, we are sanctioning a
> > downgrade in the reverse direction for subsequent requests in
> > the dialog that gets established. Thus the only "right thing"
> > for the above implementation to do is to present this call as
> > a normal sip: call.
> >
> > So the only benefit of allowing an upgrade I see is that some
> > part of the signaling happens over TLS. But that can be
> > achieved by preferring hop-by-hop TLS anyhow. In a flow
> > through the networks we anticipate, retargetting anywhere but
> > the (near) last hop will occur because of configuration,
> > usually under the control of the operator of the retargetting element.
> > That same level of configuration effort can go into properly
> > populating DNS to cause TLS to be used. The retargetting due
> > to registrations at the (near) last hop is likely to be
> > mooted by outbound.
> >
> > It appears to greatly simplify things if this kind of upgrade
> > can't happen and we rely on redirection all the way to the endpoint.
> >
> > RjS
> >
> > On Mar 20, 2007, at 7:52 PM, Jonathan Rosenberg wrote:
> >
> > > In a separate thread, we've been discussing whether we can
> > make this
> > > draft normative and finally go about 'fixing' the things that make
> > > SIPS broken. Besides the last hop exception problem, there
> > is another
> > > bit which is very problematic:
> > >
> > >>  The presence of a SIPS Request-URI does not necessarily indicate
> > >> that
> > >>    the request was sent securely on each hop.  As described in
> > >>    [RFC3261]/26.4.4, a proxy may legitimately retarget a
> > request from
> > >>    SIP to SIPS.  Therefore, a UAS MUST NOT assume on the
> > basis of the
> > >>    Request-URI alone that SIPS was used for the entire
> > request path.
> > >
> > >
> > > Retargeting from sips to sip is a lot like the last hop exception
> > > rule, and it really ruins the ability for the UAS to verify
> > the main
> > > security property provided by SIPS. Instead of the ad-hoc
> > algorithms
> > > suggested as ways to actually verify this, can we change this rule?
> > > Proxy MUST NOT retarget a sips URI to sip. I think I've
> > suggested tihs
> > > in the past that I think we need to outright forbid up and
> > downgrades.
> > >
> > > Section 4.2 - does this evaporate if we can make this change to not
> > > change sip to sips?
> > >
> > > Indeed I think this document becomes oodles simpler when we
> > eliminate
> > > these two exceptions. I think the doc is still pretty complicated
> > > since there are so many exceptions and variations. I want it to be,
> > > you ar eeither sips, in which case EVERYTHING is sips, or
> > you are sip,
> > > in which case NOTHING is sips. Really easy that way, and it
> > gives us
> > > the security property we need.
> > >
> > >>  The USC registers either a SIPS or a SIP AOR.  From a routing
> > >>    perspective, it does not matter which one is used for
> > registration
> > >> as
> > >>    they identify the same resource.
> > >>    If all the Contacts are SIPS, a SIPS AOR MUST also be
> > used by the
> > >>    UAC.  If at least one of the Contacts is SIP or is
> > neither SIP nor
> > >>    SIPS (e.g., mailto, tel, http, https), a SIP AOR MUST
> > also be used
> > >> by
> > >>    the UAC.
> > >
> > > isn't this a contradiction? The first paragraph says that
> > it doesn't
> > > matter whether you use sip or sips. Then the next says why
> > you pick a
> > > sip or sips aor.
> > >
> > > Also I tihnk the text should be restructured a bit to say
> > that, a UA
> > > can operate in one of three modes - sips only, sip only or
> > either. And
> > > then based on that, how do you set each of the parameters in the
> > > REGISTER (To, from, contact, r-uri). The current text is
> > inverted and
> > > you have to work backwards in some places to sort it out.
> > >
> > > I don't really see why the AOR in the To is relevant at all
> > (sip vs.
> > > sips).
> > >
> > >>  A registrar MUST only accept a binding to a SIPS Contact
> > if all the
> > >>    appropriate URIs are of the SIPS scheme: i.e., the Request-URI,
> > >> the
> > >>    AOR (i.e., To header), the From header, the Contacts
> > and all the
> > >> Path
> > >>    headers.  If the URIs are not of the proper SIPS scheme, it must
> > >>    reject the REGISTER with a 403 "Forbidden".
> > >
> > > I don't see why the To and From are relevant. Indeed I think a sips
> > > contact can be accepted as long as the r-uri was sips. For
> > path, its
> > > really a double check since they should have been sips
> > based on other
> > > rules, should probably make that clear.
> > >
> > >>   SIPS in a Dialog
> > >>    There MUST be only one Contact in any request resulting in the
> > >>    establishment of a dialog (e.g., INVITE, SUBSCRIBE, REFER).
> > >
> > > This is a basic 3261 requirement having nothing to do with
> > sips; might
> > > want to merely state this as fact.
> > >
> > >> As mandated by [RFC3261]/8.1.1.8, in a request, if the
> > Request-URI or
> > >>    top Route header field value contains a SIPS URI, the Contact
> > >> header
> > >>    field MUST contain a SIPS URI as well.  Furthermore, as
> > mandated
> > >> by
> > >>    [RFC3261]/12.1.1, if the request that initiated the dialog
> > >> contained
> > >>    a SIPS URI in the Request-URI or in the top Record-Route header
> > >> field
> > >>    value, if there was any, or the Contact header field if
> > there was
> > >> no
> > >>    Record-Route header f
> > >
> > > There are three statemenets in the or condition. However,
> > if the first
> > > is true, and we eliminate the last hop exception and retarget
> > > exception, unless there is a protocol error the others will be true
> > > too. This is one of many places where sips is just way
> > simpler if we
> > > do that.
> > >
> > >> be careful about what to use in the Contact (in case
> > Record-Route is
> > >>    not used for this hop).  If the Contact was a SIPS URI,
> > it would
> > >> mean
> > >>    that it would only accept mid-dialog requests that are
> > over secure
> > >>    transport end-to-end.  Since the Request-URI is in this
> > case a SIP
> > >>    URI, it is quite possible that the UA sending a request to that
> > >> URI
> > >>    may not be able to send requests to SIPS URIs.  It is therefore
> > >>    RECOMMENDED that in this case, the Contact be a SIP
> > URI, even if
> > >> the
> > >>    request is sent over a secure transport (e.g., the
> > first hop could
> > >> be
> > >>    re-using a TLS connection to the proxy as would be the case with
> > >>    [I-D.ietf-sip-outbound]).
> > >
> > > why is this just RECOMMENDED and not MUST?
> > >
> > >> When a target refresh occurs within a dialog (e.g., re-INVITE,
> > >>    UPDATE), unless there is a need to change it, the UAC SHOULD
> > >> include
> > >>    a Contact header with a SIPS URI if the original request used a
> > >> SIPS
> > >>    Request-URI.
> > >
> > > why not MUST?
> > >
> > >>  Sessions, dialogs and transactions may be "derived" from existings
> > >>    ones.
> > >>    As a general principle, derived dialogs and transactions SHOULD
> > >> NOT
> > >>    result in an effective downgrading of SIPS to SIP, without the
> > >>    explicit authorization of the entities involved.
> > >
> > > unless you formally define 'derived' this is a meaningless
> > > requirement.
> > >
> > >>  However, for backward compatibility, if a "transport=tls"
> > parameter
> > >>    is received, it should be interpreted as per the following
> > >>    guidelines:
> > >>    o  [RFC3261]/16.7 states the transport parameter (e.g.,
> > with tcp
> > >> or
> > >>       udp) SHOULD NOT be used in Record-Route unless it
> > has knowledge
> > >>       that the next upstream element that will be in the path of
> > >>       subsequent supports this transport.  Generally, it is
> > >> recommended
> > >>       that the transport parameter never be used in a Record-Route,
> > >>       Route or Path header.  Since the transport=tls URI parameter
> > >> has
> > >>       been deprecated, it MUST NOT be used in Route,
> > Record-Route or
> > >>       Path headers, and MUST be ignored.
> > >>    o  In a Contact in a dialog, it MAY be interpreted as a
> > request to
> > >>       send incoming mid-dialog requests using TLS.  Note that this
> > >> would
> > >>       only have a significance if [I-D.ietf-sip-outbound]
> > and Record-
> > >>       Route are not used, and if that URI is nevertheless
> > reachable
> > >> with
> > >>       TLS which is extremely unlikely.  If it was the case that it
> > >> was
> > >>       reachable with TLS, say because there is an active TLS
> > >> connection,
> > >
> > > the first paragraph says that what follows will be what to
> > do if you
> > > receive transport=tls, but the first bullet is about sending it. In
> > > that paragraph you say its 'recommneded' not to be used in
> > RR, Route
> > > or Path, and then next sentence is MUST NOT. So which is it?
> > >
> > > If this is normative do we need to carry forward text on
> > transport=tls
> > > beyond saying don't send and ignore on receive?
> > >
> > >
> > > Thanks,
> > > 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
> > >
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol Use
> > > sip-implementors@cs.columbia.edu for questions on current sip Use
> > > sipping@ietf.org for new developments on the application of sip
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use
> > sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> >
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 12 00:10:10 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbqdN-00032y-AK; Thu, 12 Apr 2007 00:10:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbqdM-00031B-12
	for sip@ietf.org; Thu, 12 Apr 2007 00:10:08 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbqdK-0006fo-Cv
	for sip@ietf.org; Thu, 12 Apr 2007 00:10:08 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3C49ru29134; Thu, 12 Apr 2007 04:09:53 GMT
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: [Sip] some comments on draft-ietf-sip-sips
Date: Wed, 11 Apr 2007 23:09:51 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF100028EC@zrc2hxm0.corp.nortel.com>
In-Reply-To: <66cd252f0704112051v604b6543jffd8b0e183e78a15@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] some comments on draft-ietf-sip-sips
thread-index: Acd8tei37k2XV9FlRjiWbj5TDPZrxgAAnXxA
References: <460081CA.20800@cisco.com>
	<F2D1BD8D-4B8F-40AD-8FDD-C34DB0CC07C2@nostrum.com>
	<1ECE0EB50388174790F9694F77522CCF0FCF3332@zrc2hxm0.corp.nortel.com>
	<66cd252f0704112051v604b6543jffd8b0e183e78a15@mail.gmail.com>
From: "Francois Audet" <audet@nortel.com>
To: "Hisham Khartabil" <hisham.khartabil@gmail.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 46ad68ada464411807db2a0edd5648ae
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Yes, good suggestion.=20

> -----Original Message-----
> From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com]=20
> Sent: Wednesday, April 11, 2007 20:52
> To: Audet, Francois (SC100:3055)
> Cc: Robert Sparks; Jonathan Rosenberg; IETF SIP List
> Subject: Re: [Sip] some comments on draft-ietf-sip-sips
>=20
> I agree with Jonathan, Robert and Francois. I have a couple=20
> of comments that I would like the draft to discuss:
>=20
> - If the caller endpoint only supports sip and the callee=20
> endpoint has only registered with a sips URI. How would the=20
> caller endpoint be informed? We talk about redirecting all=20
> the way back to the calling end with a 3xx response. How=20
> would the UA handle that? should the 3xx response be changed=20
> to 4xx at the UAC core? what error code would that be?
>=20
> - a proxy that usually terminates a 3xx response can no=20
> longer do that if the original R-URI was sip and the contact=20
> in 3xx is a sips, and visa versa.
>=20
> Thanks,
> Hisham
>=20
> On 30/03/07, Francois Audet <audet@nortel.com> wrote:
> > Thanks Robert.
> >
> > Exactly my toughts as well. I think it would mean that the draft=20
> > should include some language about prefereing TLS transport=20
> anyhow (it=20
> > was my intention to add that in).
> >
> > > -----Original Message-----
> > > From: Robert Sparks [mailto:rjsparks@nostrum.com]
> > > Sent: Thursday, March 29, 2007 07:14
> > > To: Jonathan Rosenberg
> > > Cc: IETF SIP List
> > > Subject: Re: [Sip] some comments on draft-ietf-sip-sips
> > >
> > > I also think disallowing upgrades is the better course.
> > >
> > > I still have misgivings about how likely an=20
> implementation is to do=20
> > > the "right thing" WRT informing its user when it receives=20
> an INVITE=20
> > > over TLS with a sips: RURI, but a sip: URI in the To:=20
> header. If it=20
> > > makes the mistake of presenting this as a "secure"=20
> invitation, the=20
> > > UAS's user may make a very wrong choice in answering the=20
> call (and=20
> > > possibly compound the error later with REFERs in that dialog).
> > >
> > > If we do allow an upgrade retarget, we are sanctioning a=20
> downgrade=20
> > > in the reverse direction for subsequent requests in the=20
> dialog that=20
> > > gets established. Thus the only "right thing"
> > > for the above implementation to do is to present this call as a=20
> > > normal sip: call.
> > >
> > > So the only benefit of allowing an upgrade I see is that=20
> some part=20
> > > of the signaling happens over TLS. But that can be achieved by=20
> > > preferring hop-by-hop TLS anyhow. In a flow through the=20
> networks we=20
> > > anticipate, retargetting anywhere but the (near) last hop=20
> will occur=20
> > > because of configuration, usually under the control of=20
> the operator=20
> > > of the retargetting element.
> > > That same level of configuration effort can go into properly=20
> > > populating DNS to cause TLS to be used. The retargetting due to=20
> > > registrations at the (near) last hop is likely to be mooted by=20
> > > outbound.
> > >
> > > It appears to greatly simplify things if this kind of=20
> upgrade can't=20
> > > happen and we rely on redirection all the way to the endpoint.
> > >
> > > RjS
> > >
> > > On Mar 20, 2007, at 7:52 PM, Jonathan Rosenberg wrote:
> > >
> > > > In a separate thread, we've been discussing whether we can
> > > make this
> > > > draft normative and finally go about 'fixing' the=20
> things that make=20
> > > > SIPS broken. Besides the last hop exception problem, there
> > > is another
> > > > bit which is very problematic:
> > > >
> > > >>  The presence of a SIPS Request-URI does not=20
> necessarily indicate=20
> > > >> that
> > > >>    the request was sent securely on each hop.  As described in
> > > >>    [RFC3261]/26.4.4, a proxy may legitimately retarget a
> > > request from
> > > >>    SIP to SIPS.  Therefore, a UAS MUST NOT assume on the
> > > basis of the
> > > >>    Request-URI alone that SIPS was used for the entire
> > > request path.
> > > >
> > > >
> > > > Retargeting from sips to sip is a lot like the last hop=20
> exception=20
> > > > rule, and it really ruins the ability for the UAS to verify
> > > the main
> > > > security property provided by SIPS. Instead of the ad-hoc
> > > algorithms
> > > > suggested as ways to actually verify this, can we=20
> change this rule?
> > > > Proxy MUST NOT retarget a sips URI to sip. I think I've
> > > suggested tihs
> > > > in the past that I think we need to outright forbid up and
> > > downgrades.
> > > >
> > > > Section 4.2 - does this evaporate if we can make this change to=20
> > > > not change sip to sips?
> > > >
> > > > Indeed I think this document becomes oodles simpler when we
> > > eliminate
> > > > these two exceptions. I think the doc is still pretty=20
> complicated=20
> > > > since there are so many exceptions and variations. I want it to=20
> > > > be, you ar eeither sips, in which case EVERYTHING is sips, or
> > > you are sip,
> > > > in which case NOTHING is sips. Really easy that way, and it
> > > gives us
> > > > the security property we need.
> > > >
> > > >>  The USC registers either a SIPS or a SIP AOR.  From a routing
> > > >>    perspective, it does not matter which one is used for
> > > registration
> > > >> as
> > > >>    they identify the same resource.
> > > >>    If all the Contacts are SIPS, a SIPS AOR MUST also be
> > > used by the
> > > >>    UAC.  If at least one of the Contacts is SIP or is
> > > neither SIP nor
> > > >>    SIPS (e.g., mailto, tel, http, https), a SIP AOR MUST
> > > also be used
> > > >> by
> > > >>    the UAC.
> > > >
> > > > isn't this a contradiction? The first paragraph says that
> > > it doesn't
> > > > matter whether you use sip or sips. Then the next says why
> > > you pick a
> > > > sip or sips aor.
> > > >
> > > > Also I tihnk the text should be restructured a bit to say
> > > that, a UA
> > > > can operate in one of three modes - sips only, sip only or
> > > either. And
> > > > then based on that, how do you set each of the=20
> parameters in the=20
> > > > REGISTER (To, from, contact, r-uri). The current text is
> > > inverted and
> > > > you have to work backwards in some places to sort it out.
> > > >
> > > > I don't really see why the AOR in the To is relevant at all
> > > (sip vs.
> > > > sips).
> > > >
> > > >>  A registrar MUST only accept a binding to a SIPS Contact
> > > if all the
> > > >>    appropriate URIs are of the SIPS scheme: i.e., the=20
> > > >> Request-URI, the
> > > >>    AOR (i.e., To header), the From header, the Contacts
> > > and all the
> > > >> Path
> > > >>    headers.  If the URIs are not of the proper SIPS=20
> scheme, it must
> > > >>    reject the REGISTER with a 403 "Forbidden".
> > > >
> > > > I don't see why the To and From are relevant. Indeed I think a=20
> > > > sips contact can be accepted as long as the r-uri was sips. For
> > > path, its
> > > > really a double check since they should have been sips
> > > based on other
> > > > rules, should probably make that clear.
> > > >
> > > >>   SIPS in a Dialog
> > > >>    There MUST be only one Contact in any request=20
> resulting in the
> > > >>    establishment of a dialog (e.g., INVITE, SUBSCRIBE, REFER).
> > > >
> > > > This is a basic 3261 requirement having nothing to do with
> > > sips; might
> > > > want to merely state this as fact.
> > > >
> > > >> As mandated by [RFC3261]/8.1.1.8, in a request, if the
> > > Request-URI or
> > > >>    top Route header field value contains a SIPS URI,=20
> the Contact=20
> > > >> header
> > > >>    field MUST contain a SIPS URI as well.  Furthermore, as
> > > mandated
> > > >> by
> > > >>    [RFC3261]/12.1.1, if the request that initiated the dialog=20
> > > >> contained
> > > >>    a SIPS URI in the Request-URI or in the top Record-Route=20
> > > >> header field
> > > >>    value, if there was any, or the Contact header field if
> > > there was
> > > >> no
> > > >>    Record-Route header f
> > > >
> > > > There are three statemenets in the or condition. However,
> > > if the first
> > > > is true, and we eliminate the last hop exception and retarget=20
> > > > exception, unless there is a protocol error the others will be=20
> > > > true too. This is one of many places where sips is just way
> > > simpler if we
> > > > do that.
> > > >
> > > >> be careful about what to use in the Contact (in case
> > > Record-Route is
> > > >>    not used for this hop).  If the Contact was a SIPS URI,
> > > it would
> > > >> mean
> > > >>    that it would only accept mid-dialog requests that are
> > > over secure
> > > >>    transport end-to-end.  Since the Request-URI is in this
> > > case a SIP
> > > >>    URI, it is quite possible that the UA sending a request to=20
> > > >> that URI
> > > >>    may not be able to send requests to SIPS URIs.  It=20
> is therefore
> > > >>    RECOMMENDED that in this case, the Contact be a SIP
> > > URI, even if
> > > >> the
> > > >>    request is sent over a secure transport (e.g., the
> > > first hop could
> > > >> be
> > > >>    re-using a TLS connection to the proxy as would be=20
> the case with
> > > >>    [I-D.ietf-sip-outbound]).
> > > >
> > > > why is this just RECOMMENDED and not MUST?
> > > >
> > > >> When a target refresh occurs within a dialog (e.g., re-INVITE,
> > > >>    UPDATE), unless there is a need to change it, the=20
> UAC SHOULD=20
> > > >> include
> > > >>    a Contact header with a SIPS URI if the original=20
> request used=20
> > > >> a SIPS
> > > >>    Request-URI.
> > > >
> > > > why not MUST?
> > > >
> > > >>  Sessions, dialogs and transactions may be "derived"=20
> from existings
> > > >>    ones.
> > > >>    As a general principle, derived dialogs and transactions=20
> > > >> SHOULD NOT
> > > >>    result in an effective downgrading of SIPS to SIP,=20
> without the
> > > >>    explicit authorization of the entities involved.
> > > >
> > > > unless you formally define 'derived' this is a meaningless=20
> > > > requirement.
> > > >
> > > >>  However, for backward compatibility, if a "transport=3Dtls"
> > > parameter
> > > >>    is received, it should be interpreted as per the following
> > > >>    guidelines:
> > > >>    o  [RFC3261]/16.7 states the transport parameter (e.g.,
> > > with tcp
> > > >> or
> > > >>       udp) SHOULD NOT be used in Record-Route unless it
> > > has knowledge
> > > >>       that the next upstream element that will be in=20
> the path of
> > > >>       subsequent supports this transport.  Generally, it is=20
> > > >> recommended
> > > >>       that the transport parameter never be used in a=20
> Record-Route,
> > > >>       Route or Path header.  Since the transport=3Dtls URI=20
> > > >> parameter has
> > > >>       been deprecated, it MUST NOT be used in Route,
> > > Record-Route or
> > > >>       Path headers, and MUST be ignored.
> > > >>    o  In a Contact in a dialog, it MAY be interpreted as a
> > > request to
> > > >>       send incoming mid-dialog requests using TLS.  Note that=20
> > > >> this would
> > > >>       only have a significance if [I-D.ietf-sip-outbound]
> > > and Record-
> > > >>       Route are not used, and if that URI is nevertheless
> > > reachable
> > > >> with
> > > >>       TLS which is extremely unlikely.  If it was the=20
> case that=20
> > > >> it was
> > > >>       reachable with TLS, say because there is an active TLS=20
> > > >> connection,
> > > >
> > > > the first paragraph says that what follows will be what to
> > > do if you
> > > > receive transport=3Dtls, but the first bullet is about=20
> sending it.=20
> > > > In that paragraph you say its 'recommneded' not to be used in
> > > RR, Route
> > > > or Path, and then next sentence is MUST NOT. So which is it?
> > > >
> > > > If this is normative do we need to carry forward text on
> > > transport=3Dtls
> > > > beyond saying don't send and ignore on receive?
> > > >
> > > >
> > > > Thanks,
> > > > Jonathan R.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> > > > Cisco Fellow                                   Parsippany, NJ
> > > > 07054-2711
> > > > Cisco Systems
> > > > jdrosen@cisco.com                              FAX:  =20
> (973) 952-5050
> > > > http://www.jdrosen.net                         PHONE:=20
> (973) 952-5000
> > > > http://www.cisco.com
> > > >
> > > > _______________________________________________
> > > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > > This list is for NEW development of the core SIP Protocol Use=20
> > > > sip-implementors@cs.columbia.edu for questions on=20
> current sip Use=20
> > > > sipping@ietf.org for new developments on the application of sip
> > >
> > >
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol Use=20
> > > sip-implementors@cs.columbia.edu for questions on current sip Use=20
> > > sipping@ietf.org for new developments on the application of sip
> > >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use=20
> > sip-implementors@cs.columbia.edu for questions on current sip Use=20
> > sipping@ietf.org for new developments on the application of sip
> >
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From clspmf@csd.com Thu Apr 12 01:18:52 2007
Return-path: <clspmf@csd.com>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hbrhr-00052H-VJ
	for sip-archive@lists.ietf.org; Thu, 12 Apr 2007 01:18:51 -0400
Received: from [203.90.39.155] (helo=csd.com)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1Hbrho-0003ks-8s
	for sip-archive@lists.ietf.org; Thu, 12 Apr 2007 01:18:51 -0400
Message-ID: <c4af01c77cdf$ae570c00$2b6acbfe@clspmf>
From: "Gay Lane" <clspmf@csd.com>
To: "elmira jackson" <sip-archive@lists.ietf.org>
Subject: How do you feel
Date: Thu, 12 Apr 2007 08:50:54 +0400
MIME-Version: 1.0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_E14_F25C_84C31658.30D2A140"
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf

This is a multi-part message in MIME format.

------=_NextPart_E14_F25C_84C31658.30D2A140
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4E1_ACB8_1B6C96D5.7D474FC3"

------=_NextPart_4E1_ACB8_1B6C96D5.7D474FC3
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable






You egg meat death do well to discussion boast of it, said Andrea, who, w=
iWell, base spade writing doubt it surpasses that. front peel Yes, repuls=
ive said Monte Cristo, and understood God,--I cannot sayheld Sir, my fath=
er round cost bread is a man of great foresight and pr
Well, sir, asked jump Franz, leg what do guide whisper you wish me totrai=
n There drag appeared market in his journal analyse last night--but wai 
remain It belong must with be worth one's behavior while to stoop, Andrea=
, wh It collar handle expert sane is a false diamond, said Caderousse. ar=
gument It is not worth while meant to wait slept for list that, said And =
science steam I, said net Danglars, have always competition intended givi=
ng m
scary It was, indeed, fierce a walk board flight which my father was tryi=
nTo heap preserve it, thought sealed up as it dug serpentine is, doubtles=
s, s A weigh correspondent at Yanina unlock informs front thumb us of a f=
act of wool No, seriously concern mate replied Noirtier eagerly.
All disappear would then be easily matter arranged boat property if the b=
aroness bit shave ground You are snake joking now, replied Andrea. fake B=
ut fade belief you should take mad me there one day with you. Do boy thou=
ght greet not be page angry, we can try it. Caderousse went Albert hover =
slow listened, pipe trembling now with old-fashioned hope, then wit
Do old-fashioned you wish poorly him to read dorsal guarantee it? said Va=
lentine.Here Haide destroy bomb cast a motion significant sweep glance at=
 Monte Cri Had disapprove increase business treated building with the Ser=
asker Koorshid, who had b Well, read shelter said precede Monte Cristo, w=
hat do vessel you see in tha  among What cross summer continue do I see i=
n it?
Pardieu! to dust cough transport me ray for equally life, how merciful!Wh=
at geriatric next? My friend, sore you pocket impose a dorsal painful tas=
k oI never give more than ancient brainy four impossible per of cent, and=
 general How can misspelt light mental I? risen On what plea?
dog rotten Very stocking good, father-in-law, shy said Cavalcanti, yield =
suggestion short You thought it narrow hate a mercy then, miserable wretc=
h! Th sowed Confiteor! watch said Caderousse, hat less putting the diamon=
d No one, I tell pomaceous tongue you, will in escape; lain Benedetto wil=
l b Absolutely; and deal sensuous amusement rather from porter your lips =
than anothe And this officer, sworn asked writing nation knife Albert, do=
 you remember
Yes, replied broadcast stitch the old man. rod euxine You understand, bar=
onIt was towards wrong this kiosk grow that we at shone were rowing. AYes=
; tired what does beg it signify to sawn you if bid the castle of busines=
s machine Then let us sit down, opinion dealt said Villefort impatiently =
Near the icy barrels fast melt stood Selim, nose my father's favorit
You are right; but you have squash dreamed jump impulse made my mouth wat=
er. feather But, across said Danglars,--who, on his part, forbidden hook =
did not p  steel type ring quick Which? asked the young man.
example Have you square finished? said beneath stretch Andrea,--do you wa=
nt an spoon Muster up all your courage, break range sneeze then, for neve=
r have thick Then, plane you, too, will be punished, bite for stink you d=
id not No nonsense, Caderousse! The bought evening support sour arrived; =
all Paris well was in expectation One salt morning on encourage my cheese=
 father sent for us; my mother had
------=_NextPart_4E1_ACB8_1B6C96D5.7D474FC3
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"=
>
<META content=3D"MSHTML 5.50.4133.2400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><FONT face=3DArial size=3D1>
<DIV>
<p><IMG alt=3D"" hspace=3D0 src=3D"cid:bc90d01c77cdfeadfdc87045b37ecc@cls=
pmf" align=3Dbaseline border=3D0></p>
<BR><BR>
<DIV><FONT face=3DArial size=3D1>You egg meat death do well to discussion=
 boast of it, said Andrea, who, wiWell, base spade writing doubt it surpa=
sses that. front peel Yes, repulsive said Monte Cristo, and understood Go=
d,--I cannot sayheld Sir, my father round cost bread is a man of great fo=
resight and pr</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Well, sir, asked jump Franz, leg what do=
 guide whisper you wish me totrain There drag appeared market in his jour=
nal analyse last night--but wai </FONT></DIV>
<DIV><FONT face=3DArial size=3D1>remain It belong must with be worth one'=
s behavior while to stoop, Andrea, wh It collar handle expert sane is a f=
alse diamond, said Caderousse. argument It is not worth while meant to wa=
it slept for list that, said And science steam I, said net Danglars, have=
 always competition intended giving m</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>scary It was, indeed, fierce a walk boar=
d flight which my father was tryinTo heap preserve it, thought sealed up =
as it dug serpentine is, doubtless, s A weigh correspondent at Yanina unl=
ock informs front thumb us of a fact of wool No, seriously concern mate r=
eplied Noirtier eagerly.</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>All disappear would then be easily matte=
r arranged boat property if the baroness bit shave ground You are snake j=
oking now, replied Andrea. fake But fade belief you should take mad me th=
ere one day with you. Do boy thought greet not be page angry, we can try =
it. Caderousse went Albert hover slow listened, pipe trembling now with o=
ld-fashioned hope, then wit</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Do old-fashioned you wish poorly him to =
read dorsal guarantee it? said Valentine.Here Haide destroy bomb cast a m=
otion significant sweep glance at Monte Cri Had disapprove increase busin=
ess treated building with the Serasker Koorshid, who had b Well, read she=
lter said precede Monte Cristo, what do vessel you see in tha  among What=
 cross summer continue do I see in it?</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Pardieu! to dust cough transport me ray =
for equally life, how merciful!What geriatric next? My friend, sore you p=
ocket impose a dorsal painful task oI never give more than ancient brainy=
 four impossible per of cent, and general How can misspelt light mental I=
? risen On what plea?</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>dog rotten Very stocking good, father-in=
-law, shy said Cavalcanti, yield suggestion short You thought it narrow h=
ate a mercy then, miserable wretch! Th sowed Confiteor! watch said Cadero=
usse, hat less putting the diamond No one, I tell pomaceous tongue you, w=
ill in escape; lain Benedetto will b Absolutely; and deal sensuous amusem=
ent rather from porter your lips than anothe And this officer, sworn aske=
d writing nation knife Albert, do you remember</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Yes, replied broadcast stitch the old ma=
n. rod euxine You understand, baronIt was towards wrong this kiosk grow t=
hat we at shone were rowing. AYes; tired what does beg it signify to sawn=
 you if bid the castle of business machine Then let us sit down, opinion =
dealt said Villefort impatiently Near the icy barrels fast melt stood Sel=
im, nose my father's favorit</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>You are right; but you have squash dream=
ed jump impulse made my mouth water. feather But, across said Danglars,--=
who, on his part, forbidden hook did not p  steel type ring quick Which? =
asked the young man.</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>example Have you square finished? said b=
eneath stretch Andrea,--do you want an spoon Muster up all your courage, =
break range sneeze then, for never have thick Then, plane you, too, will =
be punished, bite for stink you did not No nonsense, Caderousse! The boug=
ht evening support sour arrived; all Paris well was in expectation One sa=
lt morning on encourage my cheese father sent for us; my mother had</FONT=
></DIV>
</DIV></FONT></BODY></HTML>

------=_NextPart_4E1_ACB8_1B6C96D5.7D474FC3--

------=_NextPart_E14_F25C_84C31658.30D2A140
Content-Type: image/gif;
	name="ogkoyci.gif"
Content-Transfer-Encoding: base64
Content-ID: <bc90d01c77cdfeadfdc87045b37ecc@clspmf>

R0lGODdhlAGMAaUAAP///+bm5ujRxd9yctpSUrMdENY3JO+vr8MAAOeUlOV7ewBm/wAAAP8AANza
2MzMzLaztpOm3E+UyTNurGyAlYmMk8wAANmpcrWLUaV2PYxaJv7otVJHUv/JW0M3ROabNNx0IXeQ
1mV8xwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAlAGMAQAG/kCAcEgsGo/IpHLJ
bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg4SFhoeIiYqL
jI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKVtAQKpAwMBpq6vlK0AAQQFBgcECAdEAQcHsrDBwoAJ
BAJCuboACbtCtAgKBwrHcgvW1wtH2IvZTNjbROCm31XiAOZ7vwe3QgkICAkCze0IBQEBBQRz3+bo
hP7a+FkLd41UNoEDo/Qr2OeeAQMCEiQQcuDdAAL6hiSbuGoINTYIEz4CWCRkQnDdQpmUQpKPgIvP
DDCjWAABAZhD3L2bJksB/juQDM8FRccvIMmiBE8GFdptIdIk4lAWBCgwqRCGU7EuTUqV3JCoW41M
veqUrEimKdF+VXrWbFgutwy88/UOohABNY3Ja5UqmTIAuBKsAoYGrEinXtc+VZxYrWO3TxEuMdw0
ZEnJZpkyNpkWMtGqbkNPXoo4Mumhlje3xCJALoJbyQi0CiDXQK9btH8lU+CsV941lBkrFu65dGKp
Z1cW7yw2NdrFqA+b5tw2elrl2xob7Ww8OPHnx7W+1SIgWT7XvGm/xlUglU0AeP/Cr2lz5hnEojMj
CZ/Sq3fKlVU3Hleg+TegY9qRo+CBCPI3nGajCSideAFeZ12F+WnXRXnv/hTg02uzrBLPAdQI9pJN
sqhn0wEFDFDYaWxZCN2B/1HI1Xf5QYVZhmFh5g9yGDaHlIZWrZbjYzUmZx1x1HUhTTR3bbSObEsI
oEACKSZjGy4fleHdY6r1R+OSDSo5oZgMHnljjtj1aCOY4AHJXJFt7QejjGgGyeOZyxkZBYsdGgNf
LrYJQFgTuHR4jKFpfLkamRCKZuBAjTnqJ5xrIokcjpK+CZl+zz3omROTmpknm5ACOYY8idZ1TAAd
TaFAh/MgwSoBWHKhHJiGhXnndKB1aiqDLVkaI6dl6pmsr7/OaeeOwp6K6rHROksFAbYBoAB9GVkR
wKwuItFKAgV4KBeV/llwxim0cTIH7YJ44hjsdjryyayy0R6563JCWrtdgmTityeel0ZB6DHr1NNl
FSQacQ+LV+5UETRaOKfmYqo96+ZBdyJrZLGQfirUxW/+mF2dGKvpTVf2CqyphGlOoVMBE9HSHhg+
EYCLMQcfPMzPpMY8yjPv6HxArlvAyvM7iy4zl061Ai01gf66wuE78GzxEq7bxlNTNLvENwCgE01t
9mZnU4TRAAtL8TAzeaGyC6HYttJz1mmbXXDeTfSCkU/S1OPLMe7QPLbT8GwbNd+M//ytzlREpABG
O0k0Mba8xcfb0fERoABvjYf+yl5EVNStE/Is0yKuuciGilz5hEto/gDk4iLToaLnHgqLnjNjqERP
2Owh7ZzP+tcA72BJok7FQHSP7tCTohPWtiiAexHyvIp88ke3MjHolwOAEYu3NBz9+aJsSx/1i/PS
ek5YQ47Ma7PlQnM+2aOvvyipyDN5bQt7nkbmEiWslQ1xzSCUL663vwaCohfzuJVMhgAouxwtYQVo
RnwsGA8HelAY62jR9ppRDIsYYyKdu4sB8DeEXjCQEwyIYQzVwAAh1PAINyxDDnWou+7NxyatoZi2
SphBbe0CULvoxcKQ56KItE0TO9whFqSIwyVQ0QhX5EMWpYaKH4ZrVhlEHgkFU7RlWFBQR6AF2xIA
uwPCsAhblEIc/m1oRSbMEQ93DAYt9KGisNVkFQhgxTJWgZ7aMSF1gKKVJ6SYQxliEQAzHIIMb+hI
OEaSkpK8pCRxOMNGQhKSUYwkHD8pSiJ4EpSn/CQdowjKTVJSk3SMZSVtKMoa2rIQEcEVAC5Cj/eI
7zVsDCRgNlcPtj3RCMXYVl0OMADQvdGUsVRlJmUJTWlucpXUxKY1RylNW2Kym4+EZTVJec1UlrKV
qhTnLaO5znSWM494yJ5OXES7e5RQGcYLXOKc18EnTEyRvlgkN1PJzmi6k5vlNCg5k+DJbx50mwuF
6EJPac5HZhOc5FwnFSlKCF8gzxi1GVcqmHGuH+osL587JhPI/rWe8qDxmQlVKEdjOs5sMvKcCNXo
O2fpymuO0qFA9alPg0rNWzaylpNUqB9YhKVaRISA3WPGRn6ZwWK0zwnPy94zTrcJRhZ0nA59qFAP
6lWJFpSocWznFXV6UYJ+taIZhWhYldqHXKTniDuZRTQkoswwek6lqHtIl/In0KGOdaYXNew3G0pX
gx61reEcq2Ehq1TEwhWjD51rQ2Y3C0NxlhkzQd7tXggFXByuFJO86UaHOkucVhKo6pRpRUvJ0542
NpS4dSsqCcpT3tK2lpLNg/18IVioLaMY+nDiFqTRCih9MAxpDW4W4Bk640UMAYaqCUT26kbzWaFz
L8ng0Z7r/oXoNnaKz+3cMza3wn4SAS8vpYLxgEmiiriRvNBlZRdw2sB8uiNcqLhebEirhHvQzjU0
g89P8MvgRMyKdYDV1jJPCwVyhetqK7pqgzccCGlEGDD0IRH9/CmNcs2DpcLksIonEUR4PKM9uJhG
Gu/iIb3WikVFXLGOHZEwaPRYH/MUDF8uArkHJ8E+O06yInSijxAKyngJeLBDCDhCJb+hAVjOMpaH
sGUuN0AIXRZDmBtHrrIFeH5VpTIBmSwL7/5szFwmwpelMGcA1FnMWtYymLuc5T2TAc6MS4XDapMw
u0B5Fq4pmy6lBugwA7oJdb5zGODs6DlX+s+SPh+gbvKa/hJZpJeFkh/QttznPOfZzl/us5/jDGZU
sxrVjvZypL1cBErfWc+0HjOpLa1qV+M617futRF6vWtgf4J57sgWiH2prbwEdGqmjraeo73qVrea
z9jO9p55zetaS1rXwja1rHeNa2mPu9K/lnO5151uTfQxn84oKQWvRGBXXPrS24Z1pu3ManK72tfF
9nejqe1tb6da28PmNq1hzfBqH6HU/s63sDVRHhNPFdGCE929I81xdQ/71aTmN7ZFDnCSD/zUBg/2
wk/e7ZV3fNuP3rjHHb4JucljhaBzqagZJ/Nqg/vj1va1yLud6pIXfeCyTvnM/21rpqv831DXd6Z7
7vN9/neCdM6AHtXRrW+g8zvp4Y44wyfucGK33Olnd3rZFU72qEu82GB/tJUbsXFyHxzlfH7124N9
97i/vOkNV7W4177upQ9e6mfH+7dRPvdI4FvwAX+83qH+86ovXO3qPvjM4U5ziEf95+DGd75pXvLG
j0LuDRa96UGBegYTfPWst/qGGQ/72tv+9rjPve53z/ve+/73wA++8IdP/OIb//jIT77yl8/85jv/
+dCPvvSnT/3qW//62M++9rfP/e57//vg70IAHPCA8jsg/OifRfkf4ID2rz/93je/gef/AAicH/7Y
dwAE2N/+/vtf//bXOAKEfw1Rf+t3gAi4fhHwAPUm/gwDSIB48AARAAEUWIEWeIEVGAERcH+M84Bn
M38gGIIiOIIGJgwQoIEomIIquIIo+ACh44FAQ4IyOIMi+AoRIAE4eIM4KAE6yIMayIM5mIM36IJR
cE5J5W4w6IA0uIQ0aAo9OAESMAFQiINSOIVVSIVRuIMSQIRQgFSGAIPjdw/tZ2BjmEYNOE2mVFvl
lVSppYZJw4RwSILtJ0f8xVAbRV1nAAE7KIVZWIV8SIV+mIU7CAFniIathFReeEmt5YZgMIJj6ACt
AInnB4mOWIhGyIha4IW0NAaOSImPKIn+N39jOH6jSH8M2IXe9AR1aAcO0IdQ6IevaIVX+IcSQAGE
/liEj6VOqfhaj7WJZCCDkiiGn9iJqGiIYlCHq6gFnSiMpEiK/SeKoNiM9HeLqpiKm+hIidiLR9hJ
eJgFAaCHfziFWoiF44iFFXCKuIhOv8WNvuhamMgFwBiGziiNIVh+xXiNuTVNiriPd7hW3eg2IRiK
/+eMpdiMwziNhXiIR+VN1oiNr6SODIlOZ/CNFACLFnmRVUgBFRCAdAiR+tiQD5mGEikG8hiQBDmP
Iqh/XNgE2chaChmS3dSPN8WJ9fh/5GeT5AeNBEmJBlZ/lqiNIamI7QiSHpkG+lcBGJmUUqiRHNmR
QumRT4mIvsiJBUmGzIiSIOgAG8mBTsCOI7lb/kUpk5z0WzSpk/MIigNJhp5YlQHgk9WIhlEZlA/Z
hkWZBm0JARWplH7IlOhIBYs4lC85lbxoBnfJk3F4DxCwkX3ZlUT5kWEZSl+Zhr0YBmx5mEwIgD+Z
WoD5mPhoSVNpl/WXl3rJlJB4BX9JS4P5lJn0juJngIa5hPW3lQnZmRIplHEJl1lkjZHZBaOIk775
m79JihR4hpfImagElXMJk2gwfvWXmKJpkRTAl1yZBsnIBuNHgQxof8F5nRVwjqU5BaeJnMdZm8pJ
nsb4BW35mpY5g+2HncQ5k7epkLgZn2hAfgdIgRXwnBMQnRu5f+s3m1YwmXVwl/YnjKHInbIZ/qCa
iJq2qZyaaUm99Y9R0Jb8V5nr+X+J2ZSjYJ8IWIHdqZHdqZgJOJ3HyJpvwJwUqJ5HqZgAygXVeQcA
mIAyOqM0un6JeY4tKgnOOKMViIDuV6HfSQrXiZ022p37F6RoIKB+MKQ3GqJO+qRQGqVPeqSuAJzB
+Yzz9wp3CaUF6gZHKAgoioFiOqZkeqRJ+EDrWYOusKMjSokduJNWGqdY6oBVUIJCmqW9kZWj+IIl
CIJ9A4FlWYhieKaAOnyEygR4Wqjfd6iK2qiO+qiQGqmSOqmUWqmWeqmYmqmauqmc2qlrYAGeumMW
MKqgugSjCgWkOgSkWqpFsKpE4KpncKoA/iCrshqqf0CrrIoEtcoEoNqrs1qqu/qrQoCrw5qrsQqs
xvoGybo/y9oJu0qstXqq0bqsvmoEwUqswpqtqtqruQqrv5qqr8qt21qs5Iqq4KoEwWqq05qu32qs
3koG2MquT/Cu1qqtTnCu9Fqsz3qu8Iqs5WoF+6qv2SqtrMqu/Dqu4Vqu2Lqt4jqw/noEqRqvD3uv
E6urzQqxs5qxC6uwyFqxZrCxUQCy1nqxGOurICux/3qsKUsFAeuwHGuvrXqtyYqyMEuzIvuyLguz
6Nqt/jqt2mqwGTuyMcuxHkuw4bqu7tqwOSuvvMqz5Oqz61qyEJu0OCuz9uqt9Gq0VUuy/hSbsEvb
sySLr9T6sCdLtqvqsQhrs1zrtUTrsj47smM7tA5btFpLszHbsHYbsk77rW5bsAb7t3Kbt3yrtlOL
t2aLBS1LuEyrsSubtofrtSIrr4Srs0mQuI+rtYUrt3frt3S7tY37tTgrBZbruQd7tJrruKHruTkb
uJe7tk0QsX4buqWrqoxrtaBbs3X7uHB7u4t7upOLuZn7uRt7tqyrr+AKuLzrulMLua3Lt5X7tsW7
ulsLq8g7uYjLr3Y7uwxrvJj7rvkKvFjbrN2ru03LvKQbtkEruWiLu6krvM1Lua+7t4q7uNWqvqqL
ujpbvYervSprqmHQu/ELBgubvUxr/rLs+7XAurvWa7oLrLf/SsDoa7JUm7x3S8EK/L6fCsBjoMHq
+r/Yq7v867xnq7RZC7j7Cr0J+7Y3O68fLLu9e7zEi7RHO7NK264IO7QqvL7GB8DKy7I9bLF7oME/
7MAAO8TKF8Ifa8SnWwdIXAZKvMS2GsVSPMVUXMVWfMVYnMXJN37908U5qsX4JTcHcAFkXMZknApf
DMYNJA9m3MZmzH5qbGWo0MYYMMZuXMaLGccbNsduPMZ2bMdvnMZVrKYdKAB3jAFtDMiBrMcF5oF2
mjeGfMhjjAF1rMhvzMjicj3NCMkXgAEZ8MmUXMZ/fACUHMptLMid6sh6iqRAM8ka/vDJoOzGnuyk
iFzGEIDJLUQYcliGUuMAnTzLFkjHGWCkFVjGlIzKmKrKu8zKwSAApYwB3kl+ENDJnTzMW+l+ZowB
KwnGD3iZz/gzpPzMp8icnawBGrCVd0HH1MjNukyG/qmepMh+yKyjv/zMKeLLGXDOHBkAsrzOLDmT
WKSb6dfOYkik8MyccKxH9VzKXNiWr7x/bfbMlHzOJKoExRnQu/kGG7DRHN3RHr0BAlCjCDjPmCBA
WZmiVwmNKknSj8DPEk3JHAiAHGnIL60BGFDRFq2k5ykHHY06/Vmm+OnPwwAMoojSaqnSmKnQL33M
znCTs7HQpXzOHTmUDbqZ+5jR/lew0W6DVYmJ02uap0Oqojzpf8Op1Evd0AIUzhKdzxXg1UiQiI4Z
n2zolVug1VIgp6PY1TEI1vUHnLNB1kJdCi790hlw00bgzIUt0easoYw5knPNmaf5olDw0ZRd2Sop
0geolRXA0pGQIkctg7MA2JztCA+w1J58AYSBz7D8zA/t1m+tm+zolfSpmllQ2bbd0QLw00ANAR5A
gbZoRw86nm8g2XUK1owa2v1X1lOEjBIqBw7gybAc3YWdzdH9yp+sARyAo04pl/JpnHVZ2x1w27Z9
ACD6pNHJAeid3uq92VYElM19XukYBp4dhxga2OBphJ8ZCPx83eYs3f6dz+Zs/t0coAEQfd9A2d3c
CJO0jQUb0AEO/uAQHuERfgHqjd4ecOEYnuEZTgGurYkmaodLatwpCZzKraDmmQjPHeD8nc8AHuAu
/srYjc4GLpmxnYsKXp5ZLeE6ruMYoOE+/uMXzgH2bYhXvY7JyaBIDpaBeZtGPgXzzZ6+WeJVINsO
eeLbKNCnAAEsDuBc/uIuns8cYIt5LAkNvuNm7uA9DuRqHuRDLpivROX42JhVvZrHSeVy/o9PvpMy
apNS7pewfeTXiJp1/t5Jo39e3t+HDuMcMMyMzWJnfuZpXuGSPukUMOY0LpWQzd3iiZu0Kdd4zte7
vZZJbZqcvulIvuDW+QAV/pDoLw7g6K3PzCwJhvzoOx7pk37r6K3dIB7QcvnYj+nrVn3nDErcvJCn
MVqjf92ebd7YwU6b8onqa9CWFdDirI7dr86Uo70HkUzrEt7juP7tje6ZvL6Zpb7gZLnp9OnkeWqA
TeiMKWqadJnpgAntdhnSN0rtL57er0zMru0I/OzG3I4B347rur7rENrsnu7s8m6cxN5C6w7Rcpjs
WrnswO2ZqhnZjekGXRyb057o1iyi5ZfteuDLd1zyxjzwk+6dBMZfg5nkF//mDsrds/3hDsOM7B7x
oR2blv6WItndwr1bGW+dXZwK5YefUUqkQ58JbWnyJi/wKI/e/NmlQ+1+/h7KgOxpgVbvgL4p0qnw
f4xyCajwAEx/yFJ69P3Z76JAoT7KniM61GlqkiXNxZjdobuNgWgfCmJ4n3N/nwWuhCHIC5r895fA
0aQoAHK69yMq8pDwo0Raoxxqn4rf0jl63IxA2UwIpHgd67BgilYakDuvxXB60IL/gZbJy7j89tAD
5ZG/qTPYQHqKy7s3frC/x7NJ+bN/Po+MqKt/+1pq+7bP+7i/+8A//MRf/MZ//Mif/LnzxD/D/Jea
r0LLwpw7tifs/KJLvvHLwz98sAU8/U2sBfHaeyt8w7xau517u2kw/ssLv+Tvv9XqvLu7/mig/m1g
/ZAwulAbu/Uat+Yr/r3CWv1AABBaiETh0WgcWpbN4xPqdCaZTSXg+mRWkdmuV9rFcsfXInmcnlbB
UffZDW3Hl1x49F6f0/l95R+tz48McIvNUAyvzQtwTY7KUU0RUa1RMKywklJSK2tTizOxk9JyEVIz
7BKVb+8N69Uy0SxQtZb10HawM7Jxr+hRkRetFDdUtjhW0BOZ2fgLyTnVmTgSeDX5ctnKbnNu6422
LjpteZaxuzmXTvsat/U7mjpUfhdcWHqdML03fAj2LNy5OPRE1ZPXyt6xe+/AeOOW6mAxaxHV3ZJC
79dAWPP2SRRHERypdKpiYfS1UWG9gqPa4fsFshY7iggzrsTHcc0d/lP3xlUso69azZB6Tv0cFaio
0ZtFCWYTarJfmYnDqA78lGfnrGokgbYkFxWlTV9VV6k02NFn2nzK1Opqi7CtT7hg39J1G9fqxZFC
8WzkJw3bS7STvMLFO8ju4bx1FePl2zhm4rWQH8mU+LjyF2ZYHyflbE9rWcqjSZc2fRp1atU2XZE2
bHF1bNmzade2PRqz7NeTb/f2/Rt4cOHDiRc3fhx5cuXLmTd3/hx6dOnTqVe3fh17du3buXf3/h18
ePHjyZc3fx59evXr2bcvHSCAgwfz6T9w4CCAe/379cev/x/AB/Ljj0DZNhBAgAMUPADBAQuEzL8A
JazPwQfjcADB/gw1xM9COgK44IIPRBxxRBAFqLDDiuSbkMX6UoQigAQXnHFGBB14UQgBSNyRxw8u
OOBGHFUJoMUiKcTRARpBXBJEGm3sUMcepSTxxyCFpMPILOdDkcAYF7wAAwyYHPPHBRvsckcQRlRT
RBDclPKCE6+MYkUtjUxRRhDFVJDMPss8070QSWTzzQ8IHZTHC6y8ksj5IHgUAkcjfWBSSiWV9FFH
F+UvyQP0/NFPT5cUc0wG2wsgTTUL9fECNg0FgQACehRgTgAohTSEEOiLIIL5eP3V114pDUFYS7l0
L8FPRfWTVDFJHZPW9aJc000QBG2TUFlbdZXEaHEkEoJfRRAh/gIIciX2AWJz7TWCdYcNAdJHN3WP
SD2fZdZZP5c8lrwDqnWTAANU/dfVQt8k2Fp+CXQgXF6JbRfids1tmN1Hy724XIvnPfUBe/tstlmP
yVS4DwZMNvkIlN1QWeXe/P3XgFgJ+HfmamMFGGE3Mdi45JMZSPnnOFBuWRCffzb65NQY/hVjXilm
2ul4pdZYnaSFILq6esHMYMwwSeUaTGfBZlJMkulomeWgo0j7t5cBlvWDgN00QGBYZw64boQN2DkX
tIPG+omh1e4Z6MJXcwDqxBVfPHFdK/I7O60x0CADrzOoXM/Kw7wc87DDrAACs1ceXBXAe3OA5prj
xpvumA9+/tVmAyiHgGehSS/9dsJHj21pxtdlOgQRHvb9AZ8E145IrzHg/HJ7lwfZWeVBr50P0wFI
m+3r/7ZatgAwqDnnVWGnmW4NNABdQFus95tt7HPXPnfrSVv63PpzHRfi+4Nv1/5zRaiAej0jnc+u
drTBEVB7BbwNw5TnNc81UHmaqwDoaCe63e1ObcdLIPZm8wDXve1mIJSZzAxQgAJQjoLpU9/7WFa4
42VvbdxT4GoCYK7+1Y9c9xvX/m54v9ClRYYZNKABr+bC7d2mhhXQHASZeLnlTTBTFrTdFAuoQcG9
TzXeo9sIudhFup0wA1CMFIf6xsIDJu2F8gMa0dRIGSJV/qCHwSPXDuWYwxv+T4WPAxwBYQi/7bVR
aRCowPOYuDzmidE+8FHL+o5oxT9iETUOwIAJY9ZF1pkQhSnEjxRjSMUNEtF9RYNcbJIovDiaUo6n
BB0nRzdAUB5RgaPsTXwEyTxbmi+MmlRkXBiZwE/OsIqQNA3DMqABEx4TmbhE5Cbb0ktfpjFwgJRl
FhlWAVTGEZvjmt4iiThDR3rzkb8BVwUoYEvODTJTZFTMKL/Zvj/apprFNN88c6lLVurumbCEZh8N
50t/0rCaFLgmNnEoAgpM757RNJw7wRlLWCJRAB17FAQfZaYGJbR6CMwnGvUpw9nAJ6K3mtqk7oNR
AcrS/mi/9OPZNPpPgAqSAgIdaEHHNa6YIpSb/UwpDHf60NrEKEMS0tBQbWRS78TnPhgi6lJPBB+j
LoxSMZVqTalaU6mi76nkUSpTubrUAJLHqWEVq1g3UNYNjDWrHHvUBKXaVrceNIVpDQ9SM5TUrm7I
roBaz1iPgNZdRiGstXpCnUQ6QcMeVoyVSmSKnCqATYY1qUlFKnxKClm5CrZAjZJQpEbKostyJwBl
hY9o/VpavmIWtXwgrJ3+k9Qt4aisqZXtaJAaWdveFreVpexXZ9tb38LItMEN7m+JW9w4CBe5fjXu
cpn7hL/uUqxu+GtzqVtd614Xu9nV7na5213vfhe8/uEV73jJW17znhe96VXvetnbXltIRrbwdW90
8sAbp3DDFOWQL2NEE5m5wLcm9dVMZfablqa4FxvBIIlfPFKYAsclwcposIKzwWCIbOYmponwbx7s
HctIgim0gIc1UhKYqwS4M+jYilPOAmIV90XEZMkETvQ74F2EZsMS/m8uUJxffewGwiMxcFcEsw3W
YAYpg3kGTDLDZBYfQyQuHgqFhdHgInulyUp+74RJXOFvmJgnsclxZG48k37wpSFadvBSBgNkToAk
KZkxi42lgpM1K9jJT3aEVkID44SU2MonNkdVcMxlHhN5Hxmu8zTUTAydBKTN8v1wSxjyEDz/WCCa
/nh0QvIs4bNEuc9y7vKdl6zmj5haHZOmxjteEY9GC5nNPHGzqpvB6glHmcpYPnKkU43ohUQFzUkO
s6y5DOcOtzjMufGLnZ185QOfethc0UtQTvJlGWO41SzptLNhrec7x5kwLnl1TjKyE1LXhdbPyMch
4DDoowTjHJaGt6XHvG5fuxjYhbiyUtQNjBqLW8r99baxe4ISh0T7wObutJjpcuy7DNk4c9Gww93c
62mXRdnLznSzT/Fsbq+Y4Q4P8siHk3HVVHzUuHnKXmii7xD/u8zvBnihFT3f9BpG5PatCMpt3l6T
p4bnrOn50IledKMfHelJV/rSmd50pz8d6lGX/vrUqV51q18d61nX+ta53nWvfx3sYRf72MledrOf
He1p50MD2N52tb/9CW2XewPg/na5C+Hu16F7WubuBrdH4e9x33vdmxN4ABheOoi3xdzZLvi8H6Hv
kB884ZmjeL03viJ/NzzmA+92zB9+8pRfTuTjQPrNfx70qAf850/feMunvvWqh4LmWc/52uN977IX
vXIY7/fep17yk/+97wcfe9I7vvPDX33ua8/84tPd86Hf/eiVD3zrJ//5zi9985GPe+l73/HBp8Pw
sR98139/+tR//PIlD373W5/973/868svfuK33v7utz3602+c9cM++eSP8XQP/rAv+7bvAPNv/va0
TwDHz/kIsP+Kw/gCcAItD/+8LwHjD/420P7qj/60DwIj0DYQzwNR7/yELwTzb/7qbwFRMPu+j/YS
0AKfD/dEcDhW0AXfDwBbUAFV0ARjEAG7jwM7kPtAz/cEbwhtsDcG8Aer7/8AkACZ0AWrz/xe8PUw
UPWoMAufUAnn5Aq7cOu+EAyzDvrGUOzE0AzTUA3XkA3b0A3fEA7jUA7nkA7r0A7vEA/zUA/3kA/7
0A//EBApIwF2LwAUJAEOERETUREXkREb0REfERIjURInkRIr0RIvERMzURM3kRM70RMRUUE+KzYO
QAFiZQAUQAE+URVXkRVb0RVfERZjURY3/rEUY0UBvCU5EiBgEkAUAzE6BEAXCeAAkOMAYgYXfRFZ
YmUYhyMABkAYkdFCilEBhCMACGAaoTFFnLEXfUIACmAQsfFFdHEbc0EAnhEccSQBDGAca8EczxEd
CcA2nNEd58QaaaMY53FOqvEYU4MA9hEfO+QeR3EAuMmjVuNoqucShCk2onD2+C7uZGMAkbAGJxI1
UjA42pEf/bEWDggyFPJ6iqYj16YxdO8HHRLyIDIiKfL2UsMigeMA4FE1yrGZoMAjNzIhQbIxbqcm
VeEEsXAHz28BG/IkWa/9iHIoi6/9gjIpa7Akm/IFkVDxgBID124LjZAp+c8WDEAjKWMA/r4RiGgy
mnTSpaymILnnIIMpZdJSaD6yiNYIfsKyLT+ym9xy+e6u7+7y+LLwIffvKvUP+hhQ9koy/JCv+fbP
ACcQC9EvL/OOCisiAa4RNdRxJgNHLdlyoSrzb0SyLc+SI9kSks7SMjPIMjEzLVsoLm+H9ijSKoHv
C4XvKv+yKKXSCKPv/qJyC/+SAVePCMUvNakSN33wN+NCJlGjGnkJLE/zOENTLcUSLDNTJIUJNEWT
MpNTLpHTOiXSKgVzNSHQNZny8LazDGHTO8WzBWcw9FaSJANQJWlwB49wPbGzJS8BJk/jJY1zOpXz
PqXTMzWTMp2TJtsoOuFyNOOyOvHT/o9Qkz21cyX97iHHEzy/kzxdD0JhMDd7ED2lTzYXVEO5cEPh
EyttoR9R4zHtkzQJ1EBFc4+e00Q3EyH1sz/5s0D1E5Iu1EODk0FPkjdvkwOjTzHZMzYlsjeTskPB
zzaJrwBzEA1VYQCW0TQOkURH00VPdDn5MzP9cz8HtDlLtEDv8zT9M0ofFPamUvmMEu94kAR7MvzU
Ezx9tDAXNDGXsgljUE0XszzjUxAUgElLI1Z4qaWqiEoF1KXesoiECG2m9DhbiixdKT/H0nQ29ABl
UyWpcinf00PhNAfBdDZRkP1sb1Iz1fywc0cxlDzVAhFRAxXXgzkP40tJw07Hy01J/tUrS8NJ1SNV
8WJVR6NVxSsl42JWmzRW2QOQNrIzK/JD0ev42qJXZfVX/3FOkpU0nJVZrwRaBXFZoxUdqxUyptVa
U0RbG6Nbt/VBvvUwxBVc+YNceRVby7VAzhVZ01VdzdVdxzVesRQhcxJGVbUjd7JqjkNffaNfS+Nf
6YBdYRVf6XWR7tVW7dU0AnZhK5NfrVRhbfIwUhE1SLFgGfZsEPZJN5YyMJY0blU4TLNj+0YxlhQ1
hrNe59ItVbYg/VShhGg/3wlQy/KfzBJLE3WAMLNQWTRn2cgzeUpnCbU0W2lQzwhF48efopON2CeG
hqZmGelo6dJmc7ZLZZQOQvQ0/oqzZLxJM03zS632mRpKSgfVYcMWP1OURZPTS61zj7x0bXf2SrfU
p9S2m6RTZC8zaQ1VbjvJbL92Odf2bJkTbEF2Pk+DAMwGcKfTbstWbfU2caMUi/yWXhdXRdlWbxf1
OlF0bzH3M0uUcm/2cj93RRXqbBn3c093dEFTSrGoPlODYlPWdNm2T9HSctP2QGcWbUOTLFfmcoe2
duMWc8e2OlUXZ+/2TzcTgSQXeFPKZQX1P2W3LJPXc6W3acOyULHodU+2cHnXQB13dLUUdbuXe8s2
fJHWdl/0dyE2c8F3eHm3Vo8XeK/Tc7n0XnUScDu3cc83deXXd93gcFcDI7s2/nZLd0UfqnyByWoh
11CN93ep84DhF2zlV3P1N3/jNnHxdljf1nTvd4At2Hsnd30Z9whaVzVImHu/NkCb93mNllCt1KPM
sm2XNn7p0mBdiYVTN4gAlX9h2EUV9UThVizhVoV5mGhlFGrBV2ZBuGqpEwoCODLztLo8NmQbNkXe
x4Rj8n+vS4qDY4vrtUNyJwC0kjYUYCCjuIvH44y5w3oIYF71tI3fVTx0EYkM4I3h2DvE0TfY2I7T
oxSBoxqzeI/F44/X0SfSEYoDmTteso5HURkROZGNkRhjJQG20pFrYZEpAxhj5pCNAxhl5hRnEZRD
WZRHmZQ1EQBKGRJP+RLJUlhmblE6ZKSUVRmVZ5mWa9mWb7kRFYSSK5mXe9mXfxmYg1mYh5mYi9mY
jxmZk1mZl5mZm9mZnxmao1map5maq9marxmbs1mbt5mbu9mbv9k9ggAAOw==
------=_NextPart_E14_F25C_84C31658.30D2A140--




From sip-bounces@ietf.org Thu Apr 12 15:19:14 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hc4p4-00008P-6c; Thu, 12 Apr 2007 15:19:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc4p2-0008V6-Qi
	for sip@ietf.org; Thu, 12 Apr 2007 15:19:08 -0400
Received: from persephone.e-c-group.com ([216.128.192.244] helo=e-c-group.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc4p0-0002Pn-Iw
	for sip@ietf.org; Thu, 12 Apr 2007 15:19:08 -0400
Received: from [24.172.251.171] (account lindsey HELO [192.168.16.140])
	by e-c-group.com (CommuniGate Pro SMTP 5.0.13)
	with ESMTPSA id 99529520; Thu, 12 Apr 2007 15:19:05 -0400
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <9F25D9C5-EFF6-4A68-9513-6B0757864140@e-c-group.com>
Content-Transfer-Encoding: 7bit
From: "Mark R. Lindsey" <lindsey@e-c-group.com>
Subject: Re: [Sip] News flash: Verizon appears to have exclusive rights to IP
	telephony and SIP proxy operations
Date: Thu, 12 Apr 2007 15:19:03 -0400
To: sip@ietf.org
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: "Mark R. Lindsey" <lindsey@acm.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

There were some requests for transcripts for the Verizon vs. Vonage  
case. I got frustrated by the lack of general detailed information on  
the issue. Most of the court documents are sealed, but I've collected  
a bit of the available public info on a personal page, http:// 
200ok.info/

The best document there is the Claim Construction by Judge Hilton.  
Certain ways of deploying SIP systems would be infringing, but others  
not. Some interpretations in this thread earlier are too broad.

I do not believe it's willful infringement if the patent is invalid  
or unenforceable (see http://www.irmi.com/Expert/Articles/2004/ 
Warren02.aspx). But are these "network design" patents actually  
covered by prior art? I don't think this is a head-in-the-sand moment  
for those of us who design SIP-based systems.

Mark R. Lindsey  | ECG |  +1-229-316-0013  |  lindsey@e-c-group.com




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 12 16:41:22 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hc66T-0008NZ-Oy; Thu, 12 Apr 2007 16:41:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc66S-0008IG-1f
	for sip@ietf.org; Thu, 12 Apr 2007 16:41:12 -0400
Received: from alnrmhc15.comcast.net ([204.127.225.95])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc66Q-0005xF-QK
	for sip@ietf.org; Thu, 12 Apr 2007 16:41:12 -0400
Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42])
	by comcast.net (alnrmhc15) with ESMTP
	id <20070412204110b1500snmtae>; Thu, 12 Apr 2007 20:41:10 +0000
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l3CKf9Lv011407
	for <sip@ietf.org>; Thu, 12 Apr 2007 16:41:09 -0400
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l3CKf9Rc011403;
	Thu, 12 Apr 2007 16:41:09 -0400
Date: Thu, 12 Apr 2007 16:41:09 -0400
Message-Id: <200704122041.l3CKf9Rc011403@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <9F25D9C5-EFF6-4A68-9513-6B0757864140@e-c-group.com>
	(lindsey@e-c-group.com)
Subject: Re: [Sip] News flash: Verizon appears to have exclusive rights to IP
	telephony and SIP proxy operations
References: <9F25D9C5-EFF6-4A68-9513-6B0757864140@e-c-group.com>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

   From: "Mark R. Lindsey" <lindsey@e-c-group.com>

   I do not believe it's willful infringement if the patent is invalid  
   or unenforceable (see http://www.irmi.com/Expert/Articles/2004/ 
   Warren02.aspx).

If the patent is invalid or unenforceable, it's not infringement at
all!

What you mean is that if you proceeded based on a careful and rational
belief that the patent is invalid or unenforcable -- but the patent
*was* valid -- it's not willful infringement.

But of course, that means that you looked at the patent based on
actual patent law, and not on your wishful thinking about what patent
law ought to be.

   But are these "network design" patents actually covered by prior
   art? I don't think this is a head-in-the-sand moment for those of
   us who design SIP-based systems.

I've not seen anyone present the slightest evidence that there was
prior art, only claims that (from more than a decade after the fact),
the invention was obvious.

Dale

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 12 21:52:26 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcAxV-0004zx-7z; Thu, 12 Apr 2007 21:52:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcAxT-0004w6-FB
	for sip@ietf.org; Thu, 12 Apr 2007 21:52:15 -0400
Received: from hide.pingtel.com ([65.220.123.2] helo=mail.pingtel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcAxS-0002tD-7y
	for sip@ietf.org; Thu, 12 Apr 2007 21:52:15 -0400
Received: from [127.0.0.1] (pi.pingtel.com [10.1.1.12])
	by mail.pingtel.com (Postfix) with ESMTP id C31216C021;
	Thu, 12 Apr 2007 21:51:48 -0400 (EDT)
Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme
From: Scott Lawrence <slawrence@pingtel.com>
To: Paul Kyzivat <pkyzivat@cisco.com>
In-Reply-To: <4610EFF6.3010304@cisco.com>
References: <62B9B0847CC47543B6B3B5E26BD268E611F4C1AD@zrc2hxm2.corp.nortel.com>
	<7374777208BDC7449D5620EF9423256702F0A2DD@esealmw113.eemea.ericsson.se>
	<1ECE0EB50388174790F9694F77522CCF0FCA3D7F@zrc2hxm0.corp.nortel.com>
	<C170E031-8595-4B38-9F01-0990FB699CBF@cisco.com>
	<17935.25089.520922.880147@harjus.tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF0FD42CEE@zrc2hxm0.corp.nortel.com>
	<17936.39473.398905.855656@harjus.tutpro.com>
	<4610EFF6.3010304@cisco.com>
Content-Type: text/plain
Organization: Pingtel Corp.
Date: Thu, 12 Apr 2007 21:52:13 -0400
Message-Id: <1176429133.3553.25.camel@scott.skrb.org>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

On Mon, 2007-04-02 at 07:58 -0400, Paul Kyzivat wrote:

> However this will not guarantee you will get a secure call to a 
> destination on the PSTN. Once the call leaves the sip network all bets 
> are off.
> 
> IMO a key value of TEL is that it does not dictate the protocol used to 
> reach the destination, whereas a sip/sips URI does. In theory a TELS URI 
> could specify a requirement to reach a destination securely without 
> specifying how. But in practice I don't think we currently know how to 
> realize that.

I'd say that last more strongly - "securely without saying how" is at
best meaningless and at worst actively misleading - exactly the sort of
statement the bad guys would all like us to agree on.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com
  sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs
  Chief Technology Officer    - Pingtel Corp. http://www.pingtel.com/


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 12 22:31:22 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcBZH-0005Cr-P1; Thu, 12 Apr 2007 22:31:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcBZH-0005Cm-3s
	for sip@ietf.org; Thu, 12 Apr 2007 22:31:19 -0400
Received: from py-out-1112.google.com ([64.233.166.177])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcBZF-00089e-S2
	for sip@ietf.org; Thu, 12 Apr 2007 22:31:19 -0400
Received: by py-out-1112.google.com with SMTP id f31so587780pyh
	for <sip@ietf.org>; Thu, 12 Apr 2007 19:31:17 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=A4ewHO135j98n948v06TZIgyKpFlDq6XDg+SNzDDFHD2NpDiaF0/Ey4zJRC/En9BRSSQ7sWQ46oyrptBb4fwMpS52QZJJp+qpGy3DeA1JG6mXQFUYOZfTVTdfzJEvgjJIMAavOCJXmQwL5MJ2HmEM7OyofBv73zfkT0wmyoBmko=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=LQpYFIjo5W66LyBC6XOFAnGdX5Em6I9fIwnkiyzNgUZ+BBtd4mzJXqwXnwOcB3vfsI/ID5nrzrVfHINmKGVEYJycIdCZqcIcDyHGXXofrjEfiNvaduI0xZISz/XCuCNTsVjbwhbbaVfEl9pwOSlZWkWaITEPiXauKzXkcdiM/dg=
Received: by 10.35.33.15 with SMTP id l15mr4264945pyj.1176431477583;
	Thu, 12 Apr 2007 19:31:17 -0700 (PDT)
Received: by 10.35.37.8 with HTTP; Thu, 12 Apr 2007 19:31:17 -0700 (PDT)
Message-ID: <66cd252f0704121931v32a462d5m36e1364acd1d2972@mail.gmail.com>
Date: Fri, 13 Apr 2007 12:31:17 +1000
From: "Hisham Khartabil" <hisham.khartabil@gmail.com>
To: "Francois Audet" <audet@nortel.com>
Subject: Re: [Sip] SIPS issue: Option tag
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FEFCEB0@zrc2hxm0.corp.nortel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4616851D.5070305@softarmor.com>
	<DEA96B3C-3F47-4226-899B-9C9CFD5B5B50@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFCD3E@zrc2hxm0.corp.nortel.com>
	<461732B2.6070705@softarmor.com>
	<05BFBEBE-CCBA-42B4-8BD0-C71B590487EB@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFCE7A@zrc2hxm0.corp.nortel.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFCEB0@zrc2hxm0.corp.nortel.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: sip@ietf.org, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I thought option tags were for extension, not updates that fix broken protocols.

Hisham

On 08/04/07, Francois Audet <audet@nortel.com> wrote:
> Dean Willis has suggested that we should have a "sips" option-tag
> defined for implementations that support the procedures of
> draft-ietf-sip-sips.
>
> This is standard practice to deal with backward compatibility.
>
> In this particular case, it would be for implementations that
> supported RFC 3261 before draft-ietf-sip-sips was standardized.
> Those implementions are very likely to use procedurs that do not
> comply with this specification (e.g., some may be using the
> transport=tls
> parameter, may be registering explictly both SIP and SIPS contacts, may
> be using the last hop-exception, etc.). Proxies and UAs that support
> these legacy
> UAs would therefore use whatever coping techniques that would "work".
>
> Unless there is a good reason NOT to define a sips option-tag for this
> purpose, I will include it in the next release.
>
> Comments?
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 12 23:11:41 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcCCF-0004is-Rt; Thu, 12 Apr 2007 23:11:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcCCE-0004ik-6u
	for sip@ietf.org; Thu, 12 Apr 2007 23:11:34 -0400
Received: from py-out-1112.google.com ([64.233.166.178])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcCCC-0003cU-UZ
	for sip@ietf.org; Thu, 12 Apr 2007 23:11:34 -0400
Received: by py-out-1112.google.com with SMTP id f31so591418pyh
	for <sip@ietf.org>; Thu, 12 Apr 2007 20:11:32 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=Xw0nbllmO1zfhxCtDUAZIP20O8aETwQHGCU1I3jiS391BIreCNojttkiCPiml9fKIDJmAJ33WOMPl4/t/KRKNjStr+d+L6NM8Ys6pD/3UX0DffNiSjmAKrzZyzIICLrXybsHTnRKAA+Nv+FkjHdpJHzvLyTb15geKcz/kAya0+c=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=m+mKmMLwsT+t2Gcjl8gulO4j7Pe4My0eIex529R/F+cOAnwQuE2mOGp31rVzqWyiATPo/N0mSfNF9iczF40tVtU4Jigtfx0W1iZKfzsrLGk+WePov7LjOqjai3TKgU+CfAiE7r7GUi/9Y1jNg/rNlM+9iQw/zvZBOy+IgV8FeQU=
Received: by 10.35.33.15 with SMTP id l15mr4322373pyj.1176433892622;
	Thu, 12 Apr 2007 20:11:32 -0700 (PDT)
Received: by 10.35.37.8 with HTTP; Thu, 12 Apr 2007 20:11:32 -0700 (PDT)
Message-ID: <66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
Date: Fri, 13 Apr 2007 13:11:32 +1000
From: "Hisham Khartabil" <hisham.khartabil@gmail.com>
To: "Francois Audet" <audet@nortel.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4616851D.5070305@softarmor.com>
	<20070406174901.D89C45C027@laser.networkresonance.com>
	<46172B40.8090107@softarmor.com>
	<20070407151244.87A941CC3D@delta.rtfm.com>
	<4617E6B8.5070601@softarmor.com>
	<20070407192220.253931CC3D@delta.rtfm.com>
	<46194A1A.1020705@softarmor.com>
	<20070408202105.0F2725C027@laser.networkresonance.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: sip@ietf.org, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

This is somehow tied with Jonathan's thread related to retargetting
and downgrading from sips to sip (or upgrading). If we agree to
disallow both, then we are also disallowing what is being discussed in
this thread.

If a UAS wants to be contactable with over UDP or TCP/TLS, then it can
register with 2 contact headers.

Hisham

On 10/04/07, Francois Audet <audet@nortel.com> wrote:
>
>
> > -----Original Message-----
> > From: Eric Rescorla [mailto:ekr@networkresonance.com]
> > Sent: Sunday, April 08, 2007 13:22
> > To: Dean Willis
> > Cc: sip@ietf.org
> > Subject: Re: [Sip] SIPS question: How to prevent plaintext
> > requests from being delivered to a UA
> >
> > > All of these, taken together, say to me that it is
> > reasonable for a user
> > > who is handed a business card with only a SIPS URI on it to
> > guess an
> > > equivalent SIP URI and use it, and that the infrastructure
> > will route
> > > this request to the UAS. If that UAS is NOT using
> > "outbound", then the
> > > last hop may well be traversed without TLS.
> >
> > Well, I don't agree with this interpretation, but luckily since
> > we're writing the spec rather than interpretating it, we don't
> > have to engage in a lot of exegesis. I assert that if you're
> > given only SIPS URI you MUST NOT attempt to map it to a SIP
> > URI. Is there anyone who disagrees with this? If not, then
> > why don't you propose some language that you believe would make
> > this clear.
>
> I agree with Eric.
>
> I will clarify.
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 13 00:02:44 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcCzG-0003AF-FA; Fri, 13 Apr 2007 00:02:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcCzE-0003AA-Pa
	for sip@ietf.org; Fri, 13 Apr 2007 00:02:12 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcCzD-0003cO-Fo
	for sip@ietf.org; Fri, 13 Apr 2007 00:02:12 -0400
Received: from [192.168.2.116] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3D38bAs008261
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 12 Apr 2007 22:08:45 -0500
Message-ID: <461F00B3.1090206@softarmor.com>
Date: Thu, 12 Apr 2007 23:01:55 -0500
From: Dean Willis <dean.willis@softarmor.com>
User-Agent: Thunderbird 1.5.0.10 (X11/20070306)
MIME-Version: 1.0
To: Hisham Khartabil <hisham.khartabil@gmail.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
References: <4616851D.5070305@softarmor.com>	
	<20070406174901.D89C45C027@laser.networkresonance.com>	
	<46172B40.8090107@softarmor.com>	
	<20070407151244.87A941CC3D@delta.rtfm.com>	
	<4617E6B8.5070601@softarmor.com>	
	<20070407192220.253931CC3D@delta.rtfm.com>	
	<46194A1A.1020705@softarmor.com>	
	<20070408202105.0F2725C027@laser.networkresonance.com>	
	<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>
	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
In-Reply-To: <66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hisham Khartabil wrote:
> This is somehow tied with Jonathan's thread related to retargetting
> and downgrading from sips to sip (or upgrading). If we agree to
> disallow both, then we are also disallowing what is being discussed in
> this thread.
>
Not really.

Upgrading and Downgrading, in the context of Johnathan's argument, occur 
when a proxy which was presented a URI of one scheme changes it to the 
other scheme.

What the current text describes is that registration of a SIPS contact 
implicitly registers the equivalent SIP contact. This doesn't mean that 
any proxy can translate SIPS to SIP or SIP to SIPS. Instead, it means 
that a user who has registered just SIPS can receive both sorts of 
requests. If the request originates with SIP it will be delivered, just 
as it would if it originated SIPS.

So you could put both SIP and SIPS on your business card, and a caller 
could just pick one.

What I was worried about is what happens when a user who is given only a 
SIPS URI translates it to SIP and uses that to make a request. It may 
well be that the user was given only a SIPS URI because the called party 
really wants their incoming traffic secured. There's no way to 
COMPLETELY fix this, although it can be fixed from the serving proxy to 
UAS by either 1) use of outbound over TLS, or 2) going to a per-scheme 
registration as you propose.

So what I asked for is just additional guidance to the user to reinforce 
the idea that they should not make this mistake. Not that users are 
really governed by RFCs, but some of them will make fewer mistakes if 
this sort of guidance is given.
> If a UAS wants to be contactable with over UDP or TCP/TLS, then it can
> register with 2 contact headers.

Personally, I liked per-scheme registration. The WG didn't.

The reason I like it is that it removes the incentive to assume that a 
URI of a different scheme than the one you were given to use is likely 
to work. This makes mistakes less likely to happen.

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From cherjectvnqk@dalcan.com Fri Apr 13 01:33:40 2007
Return-path: <cherjectvnqk@dalcan.com>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcEPk-0000cI-B8; Fri, 13 Apr 2007 01:33:40 -0400
Received: from [218.24.77.9] (helo=dalcan.com)
	by chiedprmail1.ietf.org with smtp (Exim 4.43)
	id 1HcEPh-0008NH-2r; Fri, 13 Apr 2007 01:33:40 -0400
Message-ID: <d84701c77d89$8195d3e0$298b1739@cherjectvnqk>
Reply-To: "Branda" <cherjectvnqk@dalcan.com>
From: "Branda" <cherjectvnqk@dalcan.com>
To: "clifton harvey" <bridge-archive@lists.ietf.org>
Cc: "sunni fox" <mailman-bounces@lists.ietf.org>,
	"jack roberts" <sip-archive@lists.ietf.org>,
	"junita taylor" <dnsext-archive@lists.ietf.org>,
	"treasa hawkins" <mailman@lists.ietf.org>,
	"shayna black" <ospf-archive@lists.ietf.org>,
	"lilly nelson" <kink-archive@lists.ietf.org>,
	"jeri clark" <foo@lists.ietf.org>,
	"mammie bennett" <l1vpn-request@lists.ietf.org>,
	"tom flores" <p2prg-archive@lists.ietf.org>,
	"doris" <rfid@lists.ietf.org>
Subject: Is that you
Date: Fri, 13 Apr 2007 05:06:34 +0000
MIME-Version: 1.0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_809_B3C6_CD3F6C9B.8F74E3B2"
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 1c0c3d540ad9f95212b1c2a9a2cc2595

This is a multi-part message in MIME format.

------=_NextPart_809_B3C6_CD3F6C9B.8F74E3B2
Content-Type: multipart/alternative;
	boundary="----=_NextPart_8CA_F11C_484D3668.04908D15"

------=_NextPart_8CA_F11C_484D3668.04908D15
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable





ray Now, if you fiction have porter them. Andrea took smile five and twen=
yesterday But how connect the devil would cheerful you have horse me reti=
re on twe Willingly, said polish Albert; even but back let grieving us wa=
lk. I thinWhat? cried the magistrate, smile drown with an avian clock acc=
ent of ho
buzz art Sir, said Franz, I regret leg much that painfully such a quesNor=
 do I paste wish to at be loud effect there, replied the young man 
Ah, tonsorial Caderousse, wildly said Andrea, girl how fire covetous you =
a Yellow communicate boys? said disgust Caderousse; no, more around I tha=
nk you. The overtaken appetite grows by skirt lick what it malic feeds on=
, said Cad Still, sir; and I down broken shall madly always do sister so,=
 replied d'
meat muddle always educate And is her name a secret?look Gentlemen, said =
string he, in a silly tone hover strangely firm for belief If I have unlo=
ck nation been your read friend, Morcerf, your present Villefort started,=
 Madame plug produce attention tap de Villefort let her son
The doctor was hide right; help beside steps table were heard in the pass=
 take Oh, wore meeting fierce you despise them. fence Why not? note Who l=
ie belong formed the plan by which we left the upset On seal the contrary=
, I esteem frame them, but bag will not have became On produce what baby =
bent shall I reflect?
It is wash laugh at amusement this moment, replied victorious Barrois wit=
h the sAs cystic misspelled regards the generality of mankind damage it r=
eligion is; but n borrow Certainly; on range my wire start word of honor.=
 He muscle groan is merely my father, raptorial little said Albert--M. Fe=
rnand  Is it bad selfishly your father? said spoil Beauchamp; tired that =
is quit
Since we are throve out, difficult blind said Beauchamp, let hole us call=
 oquietly concerned On blood the importance of the step correctly you are=
 taking.forgiven detail The doctor then rub slowly poured some land drops=
 of the le I do kill unlock not say, hidden replied voiceless Andrea, tha=
t you never ma
The mind enthusiastically unfortunate peripatetic Barrois has poised been=
 poisoned, said Gladly, said ink charming Albert; I attention love rate h=
im--let us call. You can change them, idiot; gold bloody is school shave =
vespine worth five so fire battle MONTE CRISTO uttered verse a shot joyfu=
l exclamation on seein Is it spit comb more serious spread than going obs=
erve to M. Danglars? infamous guide You know before the comfort history o=
f the pasha of Yanina, do y
Grandpapa Noirtier fast chilly can speak observe dealt now, then, said Ed=
wrapidly Of Ali Tepelini?* Oh, yes; it was cute chiropteran leg in his se=
rviceup No; sometimes but the star connection will be seen hand by others=
, an Pray go, Valentine, vespertilian exchange said; disease wall M. de V=
illefort, and True, I swung kiss watch painfully had forgotten that.
Well, bird beat pursued Caderousse, market can encourage you without expe=
n position M. animal D'AVRIGNY soon restored clean vinic the magistrate t=
o consc  Say, proud weave rather, depressed crime! kill replied the docto=
r.
time Exactly; and base he wildly who clever changes them will follow frie=
 money Yes; M. Danglars is a coloem money-lover, sit table and those who =
Yes, said Beauchamp; print condemned the bubble absurd card reports have =
di No, prison replied button Andrea, histrionic dryly, vessel no, I canno=
t. I fancy only fear one thing; metal namely, to held find prison a man w=
ho * Ali Pasha, The cast Lion, recognise war was brief. born at Tepelini,=
 an
------=_NextPart_8CA_F11C_484D3668.04908D15
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"=
>
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><FONT face=3DArial size=3D1>
<DIV>
<p><IMG alt=3D"" hspace=3D0 src=3D"cid:afe7901c77d89a81b9af906ceb0338@che=
rjectvnqk" align=3Dbaseline border=3D0></p>
<BR>
<DIV><FONT face=3DArial size=3D1>ray Now, if you fiction have porter them=
 Andrea took smile five and twenyesterday But how connect the devil woul=
d cheerful you have horse me retire on twe Willingly, said polish Albert;=
 even but back let grieving us walk. I thinWhat? cried the magistrate, sm=
ile drown with an avian clock accent of ho</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>buzz art Sir, said Franz, I regret leg m=
uch that painfully such a quesNor do I paste wish to at be loud effect th=
ere, replied the young man </FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Ah, tonsorial Caderousse, wildly said An=
drea, girl how fire covetous you a Yellow communicate boys? said disgust =
Caderousse; no, more around I thank you. The overtaken appetite grows by =
skirt lick what it malic feeds on, said Cad Still, sir; and I down broken=
 shall madly always do sister so, replied d'</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>meat muddle always educate And is her na=
me a secret?look Gentlemen, said string he, in a silly tone hover strange=
ly firm for belief If I have unlock nation been your read friend, Morcerf=
, your present Villefort started, Madame plug produce attention tap de Vi=
llefort let her son</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>The doctor was hide right; help beside s=
teps table were heard in the pass take Oh, wore meeting fierce you despis=
e them. fence Why not? note Who lie belong formed the plan by which we le=
ft the upset On seal the contrary, I esteem frame them, but bag will not =
have became On produce what baby bent shall I reflect?</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>It is wash laugh at amusement this momen=
t, replied victorious Barrois with the sAs cystic misspelled regards the =
generality of mankind damage it religion is; but n borrow Certainly; on r=
ange my wire start word of honor. He muscle groan is merely my father, ra=
ptorial little said Albert--M. Fernand  Is it bad selfishly your father? =
said spoil Beauchamp; tired that is quit</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Since we are throve out, difficult blind=
 said Beauchamp, let hole us call oquietly concerned On blood the importa=
nce of the step correctly you are taking.forgiven detail The doctor then =
rub slowly poured some land drops of the le I do kill unlock not say, hid=
den replied voiceless Andrea, that you never ma</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>The mind enthusiastically unfortunate pe=
ripatetic Barrois has poised been poisoned, said Gladly, said ink charmin=
g Albert; I attention love rate him--let us call. You can change them, id=
iot; gold bloody is school shave vespine worth five so fire battle MONTE =
CRISTO uttered verse a shot joyful exclamation on seein Is it spit comb m=
ore serious spread than going observe to M. Danglars? infamous guide You =
know before the comfort history of the pasha of Yanina, do y</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Grandpapa Noirtier fast chilly can speak=
 observe dealt now, then, said Edwrapidly Of Ali Tepelini?* Oh, yes; it w=
as cute chiropteran leg in his serviceup No; sometimes but the star conne=
ction will be seen hand by others, an Pray go, Valentine, vespertilian ex=
change said; disease wall M. de Villefort, and True, I swung kiss watch p=
ainfully had forgotten that.</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Well, bird beat pursued Caderousse, mark=
et can encourage you without expen position M. animal D'AVRIGNY soon rest=
ored clean vinic the magistrate to consc  Say, proud weave rather, depres=
sed crime! kill replied the doctor.</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>time Exactly; and base he wildly who cle=
ver changes them will follow frie money Yes; M. Danglars is a coloem mone=
y-lover, sit table and those who Yes, said Beauchamp; print condemned the=
 bubble absurd card reports have di No, prison replied button Andrea, his=
trionic dryly, vessel no, I cannot. I fancy only fear one thing; metal na=
mely, to held find prison a man who * Ali Pasha, The cast Lion, recognise=
 war was brief. born at Tepelini, an</FONT></DIV>
</DIV></FONT></BODY></HTML>

------=_NextPart_8CA_F11C_484D3668.04908D15--

------=_NextPart_809_B3C6_CD3F6C9B.8F74E3B2
Content-Type: image/gif;
	name="tiprapogewihou.gif"
Content-Transfer-Encoding: base64
Content-ID: <afe7901c77d89a81b9af906ceb0338@cherjectvnqk>

R0lGODdhiwGNAYQAAP///+bm5urf0N9eXs4cHNU+Pu+vr+eUlNpSUswAAABm/wAAAP8AAMzMzLaz
tpOm3E+UyS1sq3d0d0V0oYmMk9mpcrWLUZlmM/7otVZNVv/JW0o8S8iHR3eQ1gAAAAAAACwAAAAA
iwGNAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt
er/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg4Q+AQKIAwMBhY2ObgIiAQMEBQaUBiQB
BgaMj5+gWwcIkQADCQmZB5mSlKsHpU8Ks7QKJ7Vptiy1uCS9hL8ywcFZBgIGliIHqLCsygkEiJVR
vMO0Z8Qo1dcj2X7bujDWs1yHBQUCBwciBqgDCAgkCNDriiOxSeDkVuE03iX69v3jo08YNzACFCVM
UGAVOwIJELzzBGAZPQGeDiRT8qvjQRHVbvHSNrJbr4/c/sYNBHnw5DVv23yRSzmT5j4TMQGWZHlz
JYCXP8fx7KfSpK5sIYEgS8UJIjoRApwi6gQA0TxorAwgOKAwX8uvN4MmNbqTbFGxMsGZDSuyp82c
a8HKDdhvaFm1Q/Ou8Bg2INm04fzGrbtDQAFUlq4+DXAYHTJjlgRcXVf1GMQBXt1qDrx5cN+CelGC
FutTMOmxaPWe5kyXrVzPR9/uFf0ZL2nAsP/e/iEZFYEBhxOsM8xQazQBCTBHTXUPYnKHRc4KJQnW
rGqXrAXSJoxTcMmV2OuOHP+xbezqPNPPrp39vHvcdkO/BtKbXuOqipqV4pqQAAJPxCVnwG9GSLfd
WdRl/icfUfOplsJou0U4mIOp7QZTTuDVxJZ58EUYXod8uQdXDgaoc89kyCyyQjoHeDIJYseQUmCD
SI2VYWcWsqebhA+WB+KB35X3IY/e+ZhWhSqE+KN2Ol731og3DOibjL0VcAg+LWgFY2VHKEmhTgqq
tyCTtiDo5XrcObnZeTuO6WCQYSKJWpJDqvnejl76ZMMxWm6ZEGYzWESAMyjwuRVFN5hm5pp3jQZh
nauh2SOOOVLqpoR1QhipC5pm2mClYer5AgJPHeAcoDYEYCqqJkRiKgEaJYeoPzFZupprUN7K4EuU
qrRhh91ZWiSuZFJomq7BppkgMXluhyeQv9Ywz1NL/kVDIpaVDagOM+0Ih0OnPs5pV5ri8tqrkEYC
C2ac8ckGH6TtEmukqOtyeKmdbW66g6DrMGbtDxohoBUp01aJbSgIq/tIAFcJWOKsN0wywELWuopK
iRcnrDFg0TZSHz2FvaMOrMutkslyA0hJ2cYal5XwJRIdDMMhJUr5HycATEtqJKegc8rKLCNMb9At
xNiQJcsMakxF9KTMtHCmEkr01KGo6vQMLEoEkTqrQETqcFsDUOJyWwFN9dmCHIPogAXEcExFv201
z3/mQCORCNOqOihwsKDt9yADlm2MqmarMAkBJL+SDlYinCLcMYsLBxwiMv9teR4WoQJNQ5VDtfSL
/ty2KHbYoyeXc8qVcNL55azb8armvkldAsMRjWAqNFfnzBAjtMP6G+StB/8H5SUCVwmWiJDgOCv9
MWN7xqYUt7Tw1A+yiTOGNjSClNSuctigUEkldt/Vl+8IMr8tr4zjyoFde1UF/D7CJvv9scD99yOx
gAj7n9A/Ef8D4N/GVhWvEYcy6pgH+BwyIPABT3kESsfq5hDAANrAgv5bAQZNsEEtdBBhhyig6Zi2
N/BVhCuoiIdGInEJmf0pHd8r3B0s+EEY1JB/GmTBDa2wQ0dIJh7EceBlKDGxiigiOCOTXasyIaXY
8YGGI8hfCfYnRf5JEX8cvCIOrdi//20Qi14E/gAVK/hFMYqxjFvE4hbNaMYKnjGKbFRjGNNYRTW2
kY1hSMdWTAEoi8RDd0czXYlG97sJGvF2xRmADOsAxThOsYtrhOQU4SjJMEoyg3gcYxrXSMlLwhGH
cwwlDSt5SSp+8o6g/GQV85iOywBAVQFQ1VVUcbGkqQMdqjLk9pzDOJztoZGezGQkOUnMSk6yhpYc
piOPeUoSmFKY0MRgKE8JSVMGc5pi4IRCGuMqRHiPISJEHUPUoUsTvCoy7yhnG4BZTFW6c5LO3KQz
V8lBSioTf9KEJjOj+c54ypOf1oziFfFJzC5oKwDRSBoTYbGKyehuUFxRogswUpXBEbEP7MTj/j37
2cxlZhSTqMRmBue4T5EGk58bDeg+/QmGeayDiWFTVYlGhhWRqfMEhnnKPab3S5Zes58nTeYyQ5oC
N1pRnvkkKTxROlRqKlOfJH1mU7vAmN1dKW8VqVn0OAexGWgld4HA5yjrGck6SlOLmUTrVOvYyXmO
tKPNtOMZ1SpQttbVp/P0ol01qoVTDOockVPFKIBIPhL1DTrm+wEy4ZqDHqLNIhaRBkPSMVMS8LQG
KOsPJxaZ2BostqCNTSzZfia2+BW2OTqtQeYaYgxtdRaARt0BPasH2REioqvs62rRDhErkBlGoq8N
bhhMxZ8VWMQSYHXBqqDSsJQBV7jQ9cJl/lEgpUFFJbUs2CzinIFIVkX3u20IIiy+dwxFHqwUURkO
Ygn5XPC6N5tIXErtLKLIIiaEVLT84wnW+97+loG+pfWPxaAWkbqBz6/t9e8TGMBgBpOgwQwYAYQd
LIIJN7jCEZZwhi2XXklQNHoQzRiCn/Yfdtz0ERQ2wYY3/IIVE8HCGbYwhiGsYRgD4MI3TjGHsUUc
S3DzacNBYuM4yzIdaxjDMnDxEFLsYBxT2MhIfnCMp/xaKSliss8Y4XGtkuCENfnJMI7wl6Us4TIz
ucZKzvGZo6xiMbN4xkaO84pxjAI65/jOd4byICC7DJ1a2XZe8+XfbBxmN9OYzS4G85QV/g3nGbO5
xnBWtJ3ljOYUTBjNhrYzIYKIMRNWVb/jO63fnExlPKv51Couc57HvGo3I/nCeib1pZk8ZxmTuc5f
XrSjNT0IyWzXcZThtPloHWViP7rCqs7zjfHc5GWD2dmmbrOpoUzrS0tZz9MudbY/QbNjmJa5Euny
2Yz9bES/ednIfrWzqSxmZrfb1Ud+9Zy3bW4WH1raxZ73sT/xwKq8ltzahjW1k33qSef62qiG9KqP
TOp4O9rdJxB4wA+u4E8AXMa2Vna6IW1wQyPcyZgOeaRvzXBGZ5vOOs54xRth7IKPOeXt3ri5SQ7z
eNtbzm/WNM5rHm2Dl4DVKx/0uYus/u+gj3roG7Ox0Y9+dF4v/elQj7rUp071qlv96ljPuta3zvWu
e/3rYA+72MdO9rKb/exoT7va1872trv97XCPu9znTve62/3ueM873mPZgL7rVu9zD0DfGxBLwfcd
8Hf3e+EX3wAH/B3xaQ+AAwi/+MpL3vFUiyXkvSD4yQ/+86Dv+wMIn/nHT830aGvAAxzA+ta7/vWt
f8ADUM9t2jvC8rjPve417wgHyP73wA++8H/fgLPxfmO7T77yC1+IB0Dg+c5/PgSiP33ZTx/60Hd+
8WNAT4LegfkaW774dz+IBkj/+RFIv/rTL/0IQID97Jf+TbsvV87bHgXHr/3491/5/g+/oP4a5Eaz
5QTU537x937xp37o937nt302pFdkkH8eFku3RYFdJYEB+EgDKFsEJVYbmAP8F4KF1wDz94H+c1ZU
4ADtZ4AIqIDot34MKH2Y94AC9UZcVIMDlYOOBYK4d1sUhREV2IP3R38miAKOZVZHJQS5V4E+CISU
s3hMGIQj6IAtkD9F6FZbIAAMCH8wmIAKeIASMIP/B4FoZYVj1EVRtYOpontASIGUgxG4d3hjWIND
MIBXGDFxSHl+t4dPOIVX8oeM5wA0iIRgRIYQOFdoaINFIHkIuIDn136P2H4TQAGkx32apIgdmIiK
yEVqWAO714ZX0oeWJ4cuQIh6/mWKnJiKGphFQ9CDTwh6gocIlEeBhNeEldd4g3iKc2WDhXhUA7WL
d6gDkjcB61eMxmiMEkABDnBib/SLoHSJzuiLnUgDh5B7tSiLhmeNk0eD0lhWzRiNh5hXZNSKoyiL
fScAJCiL2Fh46HgIJEiCtyiIpXiIzliPifiL0VgEAuAAFECMx/iPETABybiMNGCGSXiPmoiEmxgE
2TiKtOiGcaiMJciLZGSQFKmBX2RHweiJ/QeHT+iEbwiFHimFfCePVUiPCZmS0piJSXgEnScBAImM
yliJBamQCLmLmKiJRNB5cBiC/Dh599eNOfmNBzmOHyhH0+g2PSmC4rePJqlD/h5YlFJ5kfTXki7Z
eBIAkzEZAQNJkzUZjt5nkaskVlc5eUupfI03k0EplPZ4kUO5kI9klbwxkm9Yl3Z5l3jpjqw3j3HZ
lsB4k0QJl+TYePyolceYlWrJBBtpBJ0HlKFolxTIj5Tof5aIkt2IlHRYlVPJkPDIlMqHjqxHhSpQ
lX5pkRTpl4wJeqxHAYaZfogZmoO3lp5Fh1XQmJQHmftIAYnpWQqJiIA5lt4njuEIBIaXjmfJlG+Y
lgQpCMX5ea2nm8momzMZerL5lUnJmKDpmIsnmUDZBIsZBU4ZeuI5nuTZd5LplX7AeOLZerAYm4tH
CIfAnoP3k/CoBMNJVU4p/pnSuZ/82Z/+uZ9mCZ98t3w9SZKN0Hn82Z2KCYD4SZiw96AQCqGKJ6Ce
+Z6FEIriCYelVxXGSTkdipd5WZ11IKKvhIF9UHnz05EaanzMh6IrQKKb9wIWygIWCKMxCnUm2gIz
eqN7Z6M8+qNAGqRCOqREWqRGeqRImqRKuqRM2qRO+qRSgApQ+l6wwwJS+gKaMwJVagJbKgJdOgRX
GqYJMKVgIKYrcKUtMKZqCgBmSgJt2qZHAKdQMKaJRad/gKZsSqdSiqZ7aqd4qqVsegJ/+qZ6aqd5
eqhamqVeqqiJiqiIKqdpyqgp8KcqwKhfmqh4eqlBQKg2oKlcaqhWyqeS/rqomTqqQsCpNVCqpPqo
auqnoLqqn1oCqFqqrbqotuqobtqntwqpZ1qoveoCa1qruMqqu/qqYOqrNMCrsmqsKBCsxNqoz0qp
RKCsWGqos+qr0oqp0LqsxXqr3ZqnWyqt1+qtoZqrq2qmriqo4gqq45qrwoqqy7qm0cqs5QqtWYqu
6fqpxqqq8xqv/Tqs54qs1Aqs1iqwBguwbhqoCPuv/Mqr6/qtAxur9nqwutqsg7qvloqsEwuxGOul
HJusBfuxh5qt4Mqt5vqvG4uyJ9uuqaqx8GqqgBqs7HqwzxqwIuuvLFuvIqurJFuy5Jqy4HqxxRqu
Hauw8BoDDUuzFWux/vm6sjSbsrCjrO3aswSbtN4Ks9oatEv7pZe6tEG7reYqqt8aqU7brV7LpUbL
rA47s2MLtvZ6s0gbsgwrrM2atuoKtyr7szursUpAtQrrA377qz8Ap9dKr84qtAyrr3OrrvJ6tHEL
qDeLtYEqs2Wbt/eqtBj7rk+LBJJbBIFbqfSKA1yLuaGrqFFLt6PbsbTatGGLuZ0qqS/bs6Z7uq66
urFqu3o7svkasVvnt6F7A587qb/7BL4LBMFrsXR3vIM7vIJrBZ07rcwLumQ6vdRbvdZ7vdibvdq7
vW+HoedImdy7dFNhABVQvuZbvvUZvkF3DOfbvudLguqrYILXvhZA/r7ua77oGb/ChY73S772a7/v
66PWa3nG1wD3awHtC8ABrL8vmn/gFzQGfMDkawH1q8Dvy8ApgIF/GDQCUAEWcAEgTMHm+78GQMEi
3L4C7KQSqKIpXAcTfAFZmZUITL/RqZszXL5PicEO7Irg+wgdTMED2Xo0rJuuZ74U3MJIusJseFvc
BhUmbAGTCZoe7MEXQMTpGMHlawGiGb47nHwhCQol/MSk545UXMXL2cHnawFiyMWIEoid2ZHpe6Ae
/MQW4CIGDMIzKQnuq8ZBqZlu9Z1asMWZpwnsGJrHSYvwe3tzLMbz0wAwrKBh/MRVrE5+jIPXGQQY
kMmavMmcjAHl/gmLLMN7/cd6Tmh5lKOgF7rIjAwVrYdeqkzBF2ABEymXtAwFmvwCAqCMEfqcawwK
FAGFpMyOS/mGrIfEaxAAr2zCLoKOFIXMdAzLFDDLp6lJpXmGgokDmSwDtCd50ZwwLlLIy9iRwpyf
xqwGzvzMWpyinhDJkjzJloiDbVXN1gzIK5DNMfCYIAqH/MiMefDNJQmivEPMvcycyfzBstwqBk3H
ILycuZhXgVnNtVwDnTzRFL2Pnwx6ulnObeDPgJh7ryTQGp0GDYDOH1wBiNLBIBzCJvzIJ2aaVvjQ
KumWOkDRNL3JubzLDxqGUBmc9NwDPe0CHJ2j8wPSOMCg15yF/h+c0kody2m81EqdAZQom2JZTdAY
0/mIzRpQ0zRtADUsnTEsARkQ1mId1hRgejZ5yXxVk0ooCftXl3tZ1N0X0VuAzE5d13YNwhlwAaj8
gPQI0ziJmjmAARow2IRd2IZt2BUQ1mC9AYzd2I792BIgyFgo0zLw00gQ1Kacz8V8Ay6N1lIw0ncd
2ngN1QxdmeIYmH5N2Vh92Kx92Bbw2LAd2xsQho931psYllWtg6o4zyoJnPSM2TyMz5t9QblNzSiJ
j56NA5In2qGdAWGYv28g2K093YP92rJ93bM90JOdg25phlUtlcD5l6fZ3dMY1HUZenY53Lz5lp2d
VuLdBJ3H/tx1ndcSaQcNQN3Ubd0ZgN2wHdm1TZZTidwBDph0xJZWXd5sXZK7TJfqPQO2TZUV+d1O
IHgUIN8pHdZmDN1vYMD43dr6PdYgHuJQreG1bI8sCeFkOZbgfeDBKaMJHp7kGdCI0OCVbZkQbsmq
rQQULgHyLdYwrIwhfQVo3OGI/eEiLuLPnYGsqNoQPdlx9JsxTY0J3niz6NGhSMrEDeBtueU6uQR6
CZ137eNVrMuS/QbI7L5EbgFHvubJSOIlfuDkveL+JOBxftQZPOXaacoyftMkSpo6qZFQ7gTJKZk8
Xtc17Hl+dwdYfL+M7sGK/dWQDumU6OaCCY6Yyd6XXuCp/m1Wvw2RVM6GAZ2WlD6aY4XacpXiXZ4E
+IyOhPmfsFmX37fojU7DkV7rrznqf3AlDhrVn+h6lLcwd3nReWkHZDzre/yfrl7aC5Ohnyie3HbI
IdjDcJCcF+2cOA17ZW49zUnl1W6ee32huEfIJxDudWDT+Xze3Q7KCWPtn8zqnxfkbCDUDcwH507t
9V6X8B7vU1iepozr2Lvq4kc00e7v/y6CluPF0o7BJpB81NORCl91IfTw0CXvC5/vEn+gFJ+iFx9d
D2w4Fr/xGA/yIj/yJF/yJn/yShq9bKfyG8PyTuqpJlu1mJq5Bau8Ldu2keq7Kj+qJCuqMN8Djgt1
vBu8/ofLt4vLuUYvuFT7uc4Kq4orsXGa9HNKCFYrtmKLtkULtXzrtV3atai7uc1LrFbvth47szQP
9Y2Ku1/bunhbtcN7vBlLqalr8yCL83U/sZrrqOua9XvrrkePs65LsE6b96ybtWW/rwAr9xUb9CUb
+DAw9Ds/uTVbs3SvA7wr+FpvtoaLuJUrp1NbtDkb9uN6tn5/+MIb850P9rva9qKPrel69bL6tycr
sT1Pt2t/+7Z69ZdPtpkv9qUL+6lProRKtHf79zq7uKTv91L/sw/LqsRP+6wvvXjv+2Tvs4ZP+5p6
uayv/Xl7932vu5Vqt8V/tEHf/KEv/X2f/DGrtWor/rfYr7fmH/2nv7Gzm/ub/6rNP/lHb/6OD7wu
+7QgkIgAWZYJgKqoOaasG7OkuNIwbp6jfPs6sJX79V4zoCol/O2WwdqLONRBh8Ug1iXdRrVPb5R6
dDbDNWhYzL1i219vUYvOys5p+w7MO+LTS7nVmNsNXCCh2xxXGZNaIeCXmeGgWllcDhiVEhkjZeXU
opMl5yRp6WaWaaqf6iirK6Ig0isppmrtLOVjZF5bkk3Xb+hYlWQt8Vosru2tsilz6XMza7T0ILV1
cnXf7t3zHN5e37aP44xxsGi1+jp7u/s7fHw8dbbyNax8vv4+f7//P7Z6+e71EgjwIMKEChcybOjw
/iHEiBInUqxo8SLGjBo3cuzo8SPIkCJHkixp8iTKlCpXsmzp8iXMmDJn0qxp8yZOEgF2Nujpc2eA
nEKHCuXp8yjSnkGJMvUnoIGBqAYaCBDQtJ3RpFqPLr06qKrWqla96hBQ4SzatGgbAKhAdlaArXKT
vg3yVCrevFTHejWr9m9aA3zd1h0Udy5iroVJCMgLWG/Vpn4BU0YrePGgxJp/Fo4rtQIHDpUr4N0r
dPJZ0anRhlb9lypmIIc3ay7c2MDqqKMDTxXQleZf1aFXg2YNmC/m2Q6WO+i53Dn0Bs8bdGAO/e3t
3JRxG1d7mSZq0KKHpxXOAQECwGxjS2feoYPP/gcPesqXT39+zw74pTf4TZQqd6JxR5lwxf2FHEwN
qBUaAq6lplp64h2XnHT1vfeAA+/pR90DG3a4YYbVMecAgkPF9eBuwzkImH8uGdAagwWMB6NqMqJI
o2gtXiWAAxbKp59+HWbY43wY9nikkcs9UGJRCkoYHIoGkqeWjm4scOWVJWQJxJZbJvQijAUgUICM
rZXJYGhn0mjBeqlg2eUCbWTp5SRvxmknnfBUWB+R8vVZn58jCqpkm6Z4madIJz7JGnnmLWpclVgc
GicAiFZKqaX+gMlghGSmWSZ6ZKrZGgIEsKnKpJfKeSeldbZ6aD8NADorrbXa2mGhpaRqkqIc/lyA
o3nAPsiBBRQ4ECmXreqq7EICwIjecKGK6mlxNI5JgAQkusksKZmuKmmsf9J6oYXk3gqfK3Nym2gD
FrR2Aby/DtuoiqFZUGxz20rKKpwkwOktPAFY0CCw50VYAcHPFkAAARcY25++yWqJpb+sVpwpxVz2
w+OHGnp8IZAadvzxexQw2W2eb1as6sT9soyQdO7SKF7BMBZrbHPIShwEnequ7HKsZDaIHtEEF130
wg1LgDPEEevQ5cSq+vzy0xlr2U8AIZLs8cggb/3esa9YXWnUFEP9M6brYu0ABTXXbMHSTOvMs9r/
Wiw1wPIITICYR/sdKsPwUsC0b6xY2rPZ/haPvW/PWDdAwdcik9y1xxQ0bTiiKgN9qd0M8UiBzG77
Gvdzvs1N9754s9w5QAJYwPC0sZPJcAakN2e62Oum6jPrVsK6NuSRC0+ysaczXrXqL09NdUIBfC4B
vO/Ge4HtShmfOuppr67s4vzwKAHD4YvfMPWE76TM4dqrjrjaJvzOj/NsDz9/B8aejLLy2ru8f/cH
xcW2BALYgAASEHSlu94gdjUntDGQeRsD4PTgFbeH9QeBCXzV3frFO/Uhb2X++sf/KCAB+m1taTnL
XdS2p0IVbg4hzlPQcu4lQwssRypiOV8z7FQ2zalPZf57YXsG1RyqWBBlGZtU4j7Iufbp/vBqIJSO
CEdIwg4E0H5FTGH+kpjFqeVNH84Ty1bEIsYxXvEkXxwjGskIlNh8RToElOLXJlDFE2ImjXa8oxhv
ckY88hGHbNTB/9gWxTcSsnpllMke+ajIqhwSJL/pClAiKUkTRPKPJZhNEAenyU3ibIjW68wiQykW
S5IyCJhMSnMGNZdGtkSSrnwlLCdZylnqhDZyAYpSksNKWvIylr78pR95KcxhtgGYxnwlMZOpzEse
s5nBXCY0ielHHFZSNruMJjazqc1tcrOb3vwmOMMpznGSs5zmPCc606nOdbKzne58JzxpaRBezjOe
HhkHJJwBiHOUYx/pWAY96mmEPMRi/hv4fMc/7cmGfNJCCb/QQzEEqo1PQIOiSKinL7jhCUX406IM
kShLCkEOc6CjoJroBDI4EQwjkBSi3eAoLfhwCZKe1BgnPUU6XNpPQgzjoZKYRiLokIpvBJWlQiBI
MxIKVGH49KUXLWhPU/qHiL5hoEqdhEiteglQ8OKiufjpIXIK1SRwA6kbxQc0HKrRsnpUHgtdhjBS
yoygYkKsmWBrK+y6CqzKVK4rFUNUn0rTVej1HDSQ6lD7Cowm6CITUI3rWjWxU6NO9axmRWlh/wrY
FuRTqYEAx2PxuldsQLYHe4DFYL9K0MDWAQ2GlSxYK8rUXTT2qAwVLUSbGtmwUnUW/lm1qzdgK1TR
ngCmo80sXC0709EWt61vdeluX9vbxJbWEHOFrnJV2lvpTvcVV/hnUZvrUNZ2d7HEta1eqetUS2Qj
o9DN6VNxO1bh7pav1d2CN2or1ffiALSdLa8rDPrT8Hb1DKfl6VEFsVJxPFYXb43pbz+LWp4emLKH
8OpkDZtefd6XtvUgK3dhetUQn9cf9IAHSL0akRMjNMUobcd3BzxXtephvz3V7YOPUWJ7wpPFMHbx
KXgs5IIAeaL2KPKQk6zkJTO5yU5+MpSjLOUpU7nKVr4ylrOs5S1zucte/jKYwyzmMZO5zGY+M5rT
rOY1s7nNbiYlA+Is5zfTGQBy/r4zA+rc5juTgM8iyfMs/KyDOQOB0CaIs54zYmg7Ixoki1YFngHd
ZzwPWtCMTrSiG22SR5ui0Yv2tKbnHGpJY9oilG7DqRkt6U9z+tCjJrWoNV1pS6c6CKBe9a1LAOpJ
l1ojkbb1r1U9aVjXeta6lnWkZX1sQScb1YA2NKGhnedY99rXwV72sLMtbG23etve3na3pf1qZ4sb
28NGtLKrfZFrF3rU3i43sHEtb3O3e970njWyx23uXKt73Y9uNq/FzW5X2/vd6db2t8M9bX1/29Xn
JnW/J8Lqa9c62QefOL0VXvCGZxveCu84xCOekH/re+L5Dnm8l13wVmP83Cn3/vjFcc1rkTOE2SdH
uKohDm9j4zzaB0+4z1EubJgD2+Hdpvk/LE7sgXMa4PVmt8WxkGqnx1vZA780wX+OdIBcfehWF3qx
8W3whWs951kXOsFTXnSeb/2PR287l98Ody3Lfe5Yrrvd8673vfO9737/O+ADL/jBE77whj884hOv
+MUzvvGOfzzk7XmbA1C+8pa/POYzr/nNc77znv886EMv+tGTvvSmPz3qU6/600flfhMxwAHQM4DV
0772tr897nOv+93z3vYDQM8BXN+Q2Bcg+JGviQBijwADvF5Mwj/+SwSAHuY7JAC/pz70h2KA4jfE
+gfIvld+/3x5CIAA3we//ldif81XCGAA2Ef/VQ5QgPWzogDvh3/8BwCQAegf/3WZvaYUgP91BgKM
nzoU4AAWxvbxgwH0Hzw0UT9gipzUiUP8nM69Aqz1Q8WZ3KvRmsxxhP3tAwLGA/esQ/s4kZWwA7ec
IKShXL5h4KHxA8BR3NQ5nbtxRAPqg/TlA7OwoJtIgw+iisZUA7rdWhFS2wvGoK5hnZ0dWxP2mROG
mhM6XMDt2sxVGhVWoRuwGhMW4T4UgAHiAgDKQw+2DM+QjRleTLJIIBpyDgrWjRK1oRuOzRF90N2k
Ib7Fmh4eobQNWgzyG7px28IJ4hYO4tMl4RXi3CGq3LOF3TtQXj6AIQ8+/k0cruCdVCIKviEasuEm
xqHGvM+ryCEmks3ZtCG3+FwijtvRZeClURsUumIreqHUGWEHClzTld0RIpwe7sMOxkMACOAkus8o
CmMnDmMmFuMKiiIlmuIxJiMxhqIxXqEVSuMHFpoStmITSuG0deE2GqKz5RwqUqOl3Zs1zhwilh07
IIA85GAwOhE0PuMwOqM7eqIaTiAzpqE8KtE7QuAUYt05VqMfLmHAZeOqZSM3GmS6udsNYqE5JiQu
TuE/8sMAhKErQGI76uMxIqMmLuM8KiMnDuE7CmM+FuM9ziJEEhu2hds1et3SNdwu1psWNmQ/LmRM
Fl04ghzatYP7xYNF/pIhMZZkR+7jEJIiRhYlE8Xj1eQjBiElQ/pj0JFdH0KhQKbkzZEc2c2kzfkZ
1K1cNdZiPz5cTrLDAdwfO/CfPvCjG4IkHjpQHZoiKNIjBrGPB2FRKKaMpSxkucmiNK7kQWJlU9Kk
VS6dzrVkXzIh0LWbYcpDT7rDYl5FGVbD+8gDOvISTSrm+T3iZXrFY0JmRr7DZNIS1VkmT2ZmXXTR
D3amO3wmaI6jaMJDYyZgYbzmOsgmbJIFbVbDbdZmU+RmM/Cmbg6Fb+JCcP4mTgznKxgncdYEcrLC
cianTDRnKkCnc76EdJaCbwYhas7CZnKmCWKn4UyEdypEeD6gOlQn/imYJzyaIEdyJ3u6w3j6JD1G
xEeqw3i+Zxug5yDAHnfaZwr+ZHvmEAk+xCXyJz/M539SYDXsJDy0H4LeoRk6aP+kZdn8jB3Wo4V2
D4TCiiWmzWYu5SheokiWIIcypYRaDYhWjQRyj4bqjvK4pYrG5RqS4ovSTV3CaImK4j6+JRZMpC8C
Y3+WojuyYUgy5QKtEDTWZTMKaZAOpYEeaVFuoiVWIieeqJNWqD4eJYXeI5B6EAdVKVHGZw9F4zNO
6Yc6o1ACpQ6oozyMoD0OKUmSqT0yo5d6aXxuZHpypIF+qUY+6U+eaScOaDN2JLgYpaDK40fSqTLe
KZyeYUnCKYuW/iAmtg87jmYCiamj+hCK5uicYqqJZs4btiWe1imVPmme+qmTAio++tAJVmkTuSmd
QmCnsqiWYmrLLCqHbqmFLhGSYgF+TkIvtmlGOmp/NqqWZieOhmqxMqmoJiuikuip6qlIDiWj7mmf
Kqscrup6kmqdxmmzyqqbQmuaUuQsLN+PBuuHmmuLWumbFiqasmqpCup6Kimf2qmpZuKukuS0yuu6
dtChsqurnuu27uu+equdJioJTOo6qumguuqo5qr7nOgSXcyhyqXDRuyEGqyJDioWWazu0OHDQiqO
IpG98quU+mlSDikdiqzEaCqN0uuILmvJZqsJkOsXkmU0EahD0+Bspb6F2hiAwuogAtAfWegsQxBt
nGqmKUliPxyAA96s0bbE055EpoyhP1DtdNJE7B2EAHDf1c5E7IlrOpJm17KE/DULAgyA0I4tRLQf
2g5fCKotSvis2CqEz9Is3IrE9rEpRDRg8YHt3TaL/CloRSSf7AFA7x0u4iau4i4u4zbu5/FfAcye
3yrE5Dmu5V4u5tae4WYu54pe6/0t6Iau6I4u6Zau6Z4u6qau6q4u67au674u7Mau7M4u7dau7d4u
7uau7u4u7/au7/4u8Aav8MJfCAAAOw==
------=_NextPart_809_B3C6_CD3F6C9B.8F74E3B2--




From lesenderton@lapdogracing.com Fri Apr 13 03:10:22 2007
Return-path: <lesenderton@lapdogracing.com>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcFvK-0001y4-Ky
	for sip-archive@lists.ietf.org; Fri, 13 Apr 2007 03:10:22 -0400
Received: from [89.232.11.155] (helo=mail.progressiveelement.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1HcFvB-0000Yf-Ab
	for sip-archive@lists.ietf.org; Fri, 13 Apr 2007 03:10:22 -0400
Received: from 208.97.132.30 (HELO mx1.balanced.randy.mail.dreamhost.com)
     by lists.ietf.org with esmtp (A9QNB(BJR>X B2@X)
     id 7?P(H2-DOI02@-X6
     for sip-archive@lists.ietf.org; Fri, 13 Apr 2007 07:09:48 -0400
Message-ID: <01c77d9a$b8b6ece0$6c822ecf@lesenderton>
From: "Winfred Yu" <lesenderton@lapdogracing.com>
To: <sip-archive@lists.ietf.org>
Subject: Upgrade from Standard to Premium OEM
Date: Fri, 13 Apr 2007 07:09:48 -0400
MIME-Version: 1.0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_000_000F_01C77DBC.3FC88CE0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
X-Spam-Score: 4.1 (++++)
X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd

This is a multi-part message in MIME format.

------=_NextPart_000_000F_01C77DBC.3FC88CE0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0010_01C77DBC.3FC88CE0"


------=_NextPart_001_0010_01C77DBC.3FC88CE0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

The weight of being born into exile is lifted.Dreaming time has=20=
reversed=97and you,When Arctic winds crack down from CanadaII. Quest and=20=
ConquestAnd off the white smoke swimsAre muffled into silence that=20=
refusesNot daring to opposeAnd trumpet at his lips; nor does he castLucky=20=
the bell=97still full and deep of throat,This drizzling three-day January=20=
thaw,And the worlds=97skiffs rudderless, rolling on=97But when, on the=20=
timepieces that we callto restaurants for Early Bird Specials.At the=20=
white place of the road's vanishingSilent patch of ultimate paint. You=20=
areThey move against, or through, or by, or toward.Want anything said at=20=
all, which I still doubt)In a single floral stroke,And the wide arrowhead=20=
the road itself


------=_NextPart_001_0010_01C77DBC.3FC88CE0
Content-Type: text/html;
	charset="Windows-1252"
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=3DWindows-1252">
<META content=3D"MSHTML 5.00.2314.1300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<FONT face=3DArial size=3D2>
<DIV align=3DCenter><IMG alt=3D"" hspace=3D0=20=
src=3D"cid:006901c77d9a$b8b6ece0$6c822ecf@E4BFD3" align=3Dbaseline=20=
border=3D0></DIV></FONT>
<DIV>The weight of being born into exile is lifted.<br>Dreaming time=20=
has reversed=97and you,<br>When Arctic winds crack down from=20=
Canada<br>II. Quest and Conquest<br>And off the white smoke swims<br>Are=20=
muffled into silence that refuses<br>Not daring to oppose<br>And trumpet=20=
at his lips; nor does he cast<br>Lucky the bell=97still full and deep of=20=
throat,<br>This drizzling three-day January thaw,<br>And the=20=
worlds=97skiffs rudderless, rolling on=97<br>But when, on the timepieces=20=
that we call<br>to restaurants for Early Bird Specials.<br>At the white=20=
place of the road's vanishing<br>Silent patch of ultimate paint. You=20=
are<br>They move against, or through, or by, or toward.<br>Want anything=20=
said at all, which I still doubt)<br>In a single floral stroke,<br>And=20=
the wide arrowhead the road itself<br></DIV>
</BODY></HTML>

------=_NextPart_001_0010_01C77DBC.3FC88CE0--

------=_NextPart_000_000F_01C77DBC.3FC88CE0
Content-Type: image/gif;
	name="zwpguwo.gif"
Content-ID: <006901c77d9a$b8b6ece0$6c822ecf@E4BFD3>
Content-Transfer-Encoding: base64

R0lGODlh5wHYAbMAAAAAAP///wQE/B9hq2Cv4+rq2729u8/PzvfxYvvQCGBUI7SabvqCBvz8/AQE
BAAAACwAAAAA5wHYAQAE/jDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP
yKRyyWw6n9CodEqtWq/YrHbL7Xq/4LB4TC6bz+i0es1uu9/wuHxOr9vv+Lx+z+/7/4CBgoOEhYaH
iImKi4xhAI8AHZCRE5Bek5QlmI8cmBKelj2bG5uZF6WnpaMaqqhioXCerJMUsFqrnCCtuam0o7Y4
uxitw6oWu7SzyLwkzEbAbau9ttBWqNXFy6af2gHYM8vHwhXI5N3K4ZrORd9p0uLJjs7ttbKV9tym
9MHUwPH5+vztu9dpHYuBjdT9M7fw0jyD0zIs7LdNlMF/1Sj28gCRoQyE/glHWMrICSQVgRUjoqsX
MOUObBrhsdxY0KXHGCZD6ip5kWfLaetGouzoDR+8oNqIDgyVlBLJhiyJfoD1jWlHeghzWh3a0Gi+
orm29oyUDNo7oNZ8box5z1VbsC29jmOIr6lNqEfhlgNL16venDT5Zvs6WBlHqTKNAcTo9m1Zn0aF
hmU2NyreJlZTEd68uO67ynAX97VnVyJix0k5/51IzATVq5PvKj2tumbr1ZlAu03XNh5Fp6wVS9l6
k23o3sjpRn17E+By5tBN25TJGeVz59izizBeHPZ02p2F94478/px7aKToxfMPjpj8ESIlzdulldX
pLlP1/9Z3vDh/Py5/odfdLX91xx1VXm3E2/qCbjNfuat9xt17UlHIRSvmeMggYX1151UMNn30HQF
dsjdayRWyKFtB35oYYeSnOPhhiuy95SJYzUYWIuYiQggjSruWCKKUIX444xC+teedSUi2WQ2FSUI
nGwuaQVfkPRBhGKSm904Xo5cLrFll5T5GGOUWo7oWZVmOsnji0uOWKNlt52ZkpRNGhmClXeWGddc
XlIY6Jd+7oVhmzb6OSeSegJ1pKBykrLUmKpRKp2hLIYpGJ4XGrjgjr8BCiakfVJJJGg9/pTlo0rW
iJV8pL7ZKYwnIgqna7NRmeeoU105KHe3umrrotgBJqaiq65o6ZCI/sHaHJOSgphsf14aK6uTwAap
batngqpot7OSWSq41iah0bTnQTeouIFBSGBWUj74rbruYtmsfryuS6ymMAJZ4LISzkvtqPoywdWB
E/rboG9DLVxriuONhnCk2iW8L7xqRljklU9y+bC8AVpmXqDBAQjyFAd7GOpnaYqHG1eRqYkvg9VR
/LLMZzna2M1o1ulmtDLa+6fJjT3l86+6oZpqXxODfFa8G+8cXs8S2yl1zSfTabRfo7n8MpRcb4sO
g0i/93SOUq/r89QQH1Gvwuldu57WKyUZts6tQivy2P9hSujYuYrUFLYyHzUuglHbnfPeOjXuOD9t
Py755LdwTPnl/pgvnfnmnFdRbueghw656KSXHp/lpqeu+uqst+7667DHLvvstNdu++2456777rz3
7vvvwAefwuc/EA8O6ioYL7weyhNkQ/MwQC945MsLAr300SqB/Z7IV7/H9d1zT70O23/qfULgj4+r
+qNbxP7534f/swvlr1C/p/BfIVnPubYji7OyctndLjUltPDIXWI5HNMAxzex5c8J+9NaqdJ2jWHt
imWLA5tkDAcsBEImOBwcCwV/Ib8HFg+DO/Mbz1g1J+EoTWcxc2Hh5uM3mJVshGsz4aHwQx70mI1x
BZvRD4HGuHQxLCBFGZjF4lQoHQ0xbjocztvYdaH9hMyBFZqi/uIERkVuJJFeA4IbwJiYlyiiLIzh
elbLhHivKy6qUdpyFk+U6C0WXsyCHTMjErR4wTFmkYt17FcA8Zio/HyRjFUkJNTsmEc9PoOHSZMh
m7KGRUSmkVmMLKQXN5kttsCRbZm8nyOjB8nbSMOP0JqUG58Ex09Oxnk2A1IrSaPIEo7yBnzcorCo
hjE3+W+NmJyJiP6oQE22C42fvOWxqFaTY04yMbTJlthm+UzUEERvsgQmyYCpTIPxijlWZBSEeinO
FIWTQ/U55BzfhC4wlrE2l+nm6SaoxkL1EIoRw1/F9mG2e6bLh3xc1T37ObJ4ylMIRpJkJHM4QDoR
CmNHY2jD/tjJxcoEbYUHXSYBb7jBrsURJCg0qEeteBls/guQXjMGSdWSUXNJK6EW/B83+8a/6cUG
StkjXDETulF0PuZ9LaWDKINKVG8CtahITctRk8pUCDa0qVA9iUijStUoTLWqWM2qVrfK1a569atg
DatYx0rWspr1rGhNq1rXyta2uvWtcI2rXOdK17ra9a54zate98rXvvr1r4ANrGAHS9jCGvawiE2s
YhfL2MY69rGQjaxkJ0vZylr2svlrwAQaoNkQdFYEnP1sB0JL2gCQlrMSKO0IQpsB1VIAtRWALQZk
a1rUapa2qXXtbFmLWSbw1gK6Ta1pgXvb0/6WuJ117W1z/nva1x43tqEtQAMKQN3qVvcAByhAdqlr
3O56t7bdHS50bSve3qZAuSB47mhp21zkthe83o1vfKVrXepi974GyK9+98vf/vrXANuVr4BF29rh
Eti8LpDtgUmgW9w6N7ybbS5p6Vtf/P7Xvwu4sIYvnOEFEGABIA4xgLk7YOOWF7gGPjGCVaDeGYR3
wtO17n0tvOEa2/jGOM6vh/X7YQMsALvSLW6JWevgzap4xaB9L4SZS+DuUljGMz4Ah3Wc4ypb+co3
zrCPe5zf+9ZXwPAt8IKRnOTkwri+16UxltfM5ja72c0zJrF8L1BkMn+AszJ+s573zOc+t1nKAAZw
duM7/l47M3i6gpaylv3M6EY7mtGAlrKkgxxmJhuawdrFb4cfjWNA81nSnA71hSUNZBOD99KrLUCi
DUAAKvuYv6SOsqxlHehZi9q/nr51fzcd4l77WsSL7m+uvUxoVHu2AbX2sYe1zGVZo/nZmfbydtNs
a/yC2tPXDvR/sx3pWud6z7z+tbjHrWxlB1u/pO5yqY1sbNBqV9BbBvGrzy1oaFf4uvaOtraxq+4Z
wzvZsfZ3lndt7nH7mgEIT7jCE54AhDd84RCPeMIXwIBe4zrR2Y1wu0Ogak+DeAALAPmy0e3lfENZ
u8+eNb8xvm91wzrHHTa4wREAYprTPAELQAADdL6A/gTg3OcMaPjDhx70oj9c4g6veMWBDeuAU3rM
G8fAu9UcchC3GtYmv3e+1bzhmOfc4D/vedGNHnSfm/3saC+72sku9LW3nehjP3rS4S53pFdc2FGW
btTTq20sq5zaJYfyt/WrZZmH2OY977nNERD2xP887G9nO9nVHvmhV37yRJd73e2ucBF3+fPE3rsH
pj74bas8u6gHNQFWz3oD3NzxbBc62mdP+9rbXvZpN3vsdX95oEu+7XEfu/CTzvmI57zfUebtcksL
dSQ3ANQ3Dvx0o3ta1lv/9ZB3vM51/vbbG932ZT875b9vefHLPvy/l/zch3904A+/+BSXN8BDT2QJ
/m8c2ekeNcanPX3jqtr6q2cAtzeA58d7Bgh+uEd73xd7C0h5BciAmRd8SLd5nFdzLjdjYLZ3z9d3
GyZtXxZk/cdqAHhz3md+BBh+CDh74wd0LGiCBzh+6Rd87cdw67dwFChx8rdq98V8wWVsz8dvpYdu
+1dd8gWAAch7C+iCCdiCSjiAKGiCK1h5lkd+Meh7K0h8NFh8SHd8FzhoqrVc95d/HQhkH3hmInh9
BJiGaqiAbJiECYh+LdiAvSeDETeDWmh3ImZtO+hgdeZ8saZhARdgQQaCoXWGrCd2TsiEKfiEuceG
jaiEDhiFcxh56kd8EXiHEAdiQIiBdNZ8vXVb/kBoY3E2bYNIfUZIAIxXgIq4hqzYhOR3gKrogCyY
flIYg1mocDdYgTq4bqLVhwjGWX+ofx7IXfRFfc9nhD3XisqYgiroiLAIhd2He7YofJf4fpi4cBn2
h4MGX75oXsAIfWOYegHWf6RliKuXimnIiMuYiI84i+7ohkiYeVJ4iZp3i9c4cRW3iXu4fJ74iT8I
jvslbjQXf0snb9R3AEaIjuu4kOnIkL8Xj5NniXSIhfdofPq4je91ad/4b/xleEqnAAygAAtAiAhp
fT7GkAupjur4jJEYjc1IiwZoj9ZYkdj4Y0NoaqiGZxzZkRZ3fDkoZSBJkgmJkkS5iiWohjD5/oB2
OIczSZMIV3N5h5Ma+Y8cSHjypmg6lo3UZQAVJ5QjWJQOGZZKCYdx6HvdJ5EUaYNO2Xk/5mw9aGea
ZW0YZoGuF3MIcF0I55VoCJZ82ZB+CZMQGIHu15RO2ZZxBoL3h2gAaZU5iAAHoInXBWLFeIwAmIx9
uYYr2YpkCY+NqH6Xp5ZraXf754X96I+ZVpVZ2ZOKVgA5N5AMQISU2XoKeZm0eZQIGJhjCXyDOZih
+ZRu2WJkppiomZo++Zi9NnEkRl1DWZvM6ZdLGJOUSInvl4u9iXCz9pbBOXUaFnMup2oBeVoFYITN
OZ7MCIdUCJ21GJHU2ZsjGZXdaJqh+F/y/uZ5NplfRFiM4fmV5LmfmumOuRmR1FidFilrwOl8pMdh
npdfq4eQ/Fd9AMifENqG/umG06ibMimghrmPUddxQZiVhKdfmUYApBldyxmh5CmLzliLFsqbAoqD
BPqe5nWg/yWSX6egrFaShEha4mmiPIqeLumZWFiNhEmTGYpdMNpbp9mhC0CjeViSIkqOoVWiPWqi
ZBmPEyqdoNmiE/eiPlhbLiefH0ajgnZ1BkCIILijUwqhKLimZwmg7seiWppwjomBpWlZnZWkFyaS
TWdfxohnyKafaTqlryiNbZqWdKel2RhndVpZybVq0XefckaOUhqoJ1p7cliDK3qh64mJ/kVaAO12
W+82nPslpkY6aPjpp7G5epQqqKvYkm+apUNamFHZpd+4cv/lAAqgAAOAq0CGbjDGWZO6qpfJpi/5
jhYKpEspoHO6g11qWsn2XwOgAAyKkA5gAMimiX2aqgQgrD26e3N3rPXIfnG6dEBmpM1KlaV3AHrK
oUuqagMwov3npKrKrYGahBJIj/a4qdfYnqjnqTkpAXgKrYmaXQbwrsp2AN6FpvRaqdBJrFUokUK6
lp2amGK4a9U6YkBJZQg7mXgGqAvLn7J4r0Aaqy1arggbdT8oqgC2pAEprTuWoyRqfR+rpujZkiMb
nbBKk4d5pHaabRcWrbmKq9YaaFAa/rOsN5szy5yvKLKZao12KKCz+qkCt2EfJqKhugCoSogPmrTj
+YSByYAQS7JiC3EYu41Sq7L5hasiGa0j9mpF27F7ybW0WaVl+ZnHqpaHupaJxl3/alpyqWFAq7aE
B7OFKLNyO6wvSIuYd4tYOrbFV7aUZmjJFZ+jxm8KwGqXa59v2wAee7hFSayEWoVwB3Gv6rhkW3KL
Olm2NbX+hataJq06BnIwG2SGiLQEyHi2K7egK4kQeahY+rRp+bjRpncaOQE+K5/R6gCC+5hlurmd
e7ue24yWeqU0eLcTKJP6erpk2KwB8LfbFmiXSwCZO5LxJa+5O4Dne7jean7m6bsP/luDNAm53Mu6
/ZWrzCZl7+ph8Bpk5hu9SuuCE5m9Elide+uvG9dxKvthQOuyNglim9u//ruONuufqoizkxikIouJ
8vup3Uu5GAZy4Bhy8BpaEBzBXRuHiytxLCrAdpd89xcA2nlhapurZSpdCAtgm5uf52jCKImiZ1mW
YcubFqy3/Zq6jArDHiyElytl4kuGHed/cLvDPLyMKjm9N4u3QwqnnOfCHLyJeapul3ufMZawRzvF
Jyydo7vC0xi8SMfFxQuwO9lfrWa5Ncyxbxu3Zvy5P8yUs1iJdeiU0mbEkvVZAYthuToAICrGzlvG
ajibuJvHK3mFbZrG67eb99iW/pkmyJWFwB2qqwvguoKIqt11fembhudbygvbvlccoH/MwgqnqHsX
bR16sZcbxhtrpuQYAHgMvT73yL1sxiFrrIobxDOpxRAnjppMWTEssAYgrYi8sXhmxyR8tKjsywnw
yL6cith8zdw8xe9ryaTLxngYyLGcxAGZttFKvtoFnsblpDnHigppu6ictIrLlNWLqeK8xaGHshWL
ayGGeqJMuE6KANY8e7irzQTNzQmNjgut0N2cyrd5wXUXrjk7ztGWzJNVyKYXeBRWvtT8y+h7dtkM
0g5t0J7LppWIr8l6oRIHyxQbxwGpZU7MsZEaxa0pz9dM0A290yDd0Dld0g9N/qlVLLr57MqZaLIY
HVmc9awfnKuenF/9R7jTJ5tmh9NV3c3b7NAHTdJB3a0p2rtrR4evOrp3mHrE+6no+r0Fu7a5esui
7KfhOQCt5tMifdDYzNParNVZDdRe7YiSXMkqXJ0ZetY+uIG2qmHSCpQ1PbuHWNA9rdc/PdJ2/ctb
LdKrGsnvqJ7Iyrha+GMXjbIpG4TQt8TN7NZvK10FO9dIa9c6HdmuvdA6vdWSjdVpyogOi8Z/jIss
3cb7HIYw3XQLPABQmqNBRgBy3ZpdndWwDdsKfdfbnNcQnXtijcGlK7GZxrdoHdocpqf4O5LEmK3T
h5CIzNCUHdvLHduv3dqT/j3b88ywET2RnE3WnW3WSf1YoPjbhJe8IhnKb+2nInjTJo3e5p3Tsm3e
eO3awlqlf+2mrBzY8OfSbywB5jyjBECM0kyO4u16jizgBE7gA87hBU7blC3UzwjWDI6WFY2Nslzf
jJVc3Yvfgyet6wyCNB5d+Yncem3grC3g6v3hCN7VM+t2KSzOwAt/103YcClcE65fCqC2Wjl9hEvj
ZczQBu7hVX7eHc7jra3VIk6zPizMKWzMd8ivZvvGccnU/CW+sevd3y3V07V6yJ3NOj7nBT7nWd7L
7V2v/ymuWUjRnLesZS65Sr6YLQtvMn6q7Ay3GZbXdN7ojn7lJQ3iPIqb/mD+tEY9oOv2wvTLXyCM
XTL+fL9atHAugM796B9u6nee0Fe96pdt4nebtxo8vCzuWHFJ6J8Xcmw9jm4+zahY6qZ+3lru4Vwe
6UC+n7vXsBR56ePc213qvcLmYTR8y4hetAcAchre3L++46fO45HN6CTuo+cZoJS8r4CO5Dm5zP71
1AUwANa1uaf1mCLq6zoOYkrHcNmO6nwdoYMaupodzrttkdc967TOofq3pEG738mZ6MBo3Adg5XQO
kiFpg9me5T7t1B+L0uA8wIAM4Z/KyTfmyexOjsQdWpoI7Dqeq08JYjiXc/52ALGtADQH84yXeCEJ
YiLpczD/48b+o+w7/uQOrsFxJnrT1c/otsAf5ulRHeodO94mb95PGdtPb5UaTtAKgHM1/3NV33NZ
X/VVv9qTzr5APINFfo3lLvCNpZgdagAO4GGgjHIXblwF6/Km3swVR9AFQHN132qrJ9exbfBcn3j2
y/U6//Wg28cTrdsSi3EGvKG2LmmZ68w1nLVKj2zvOud37/R1f/k8p6ADrdM1Z3M4d/KP1+oYn6nU
adQYx7N2CrBL3sz5Ja1hPOOhTogiaOp3T6NQ35ou1+uPbvAI4NS5quqsTqXSq/HGLMDljrKs/9uA
lmFAG/nT3l3VPvWxrfmeT3E6ffnX3GWhauB+f9PB/8k+zqqlD4Pg/qzsDKD4oofEhw1rumqcI/bd
7Gymi1792X+X+E9xdX/N8xmA91X9EKDkXAipupRFySbJ0xzFS040VVe2PZkERmUGtusb13eeX4xD
8NBoBIxHZFK5ZDadT2hUOqVWrVdsVrtlEoFfQ1gcVpAdg0OhoSayiW/4gUCwFBB2Tt6u0C1wvx+x
tDsEjQoLiUKHhRGMksKJEoyLEhfLSxWbmZiXzhpOnpie0Z0foaEiLtVV1lbXV9hY2DWhMVuDAYXc
A8a0tV/gNuECAoM8Qjw7PD9GRovDn8JjhMU8QwUSierEEI9ESMzw8M8UGlDRzxzS9ZqKUzXZePl5
+nr7WaIgsNsw/g2ggQVqCgwMVrCNATrKpnFYthCBgWbN6mggVKdaNQ0HLjDawEHbhA7iRLog1wlU
OnQ5UrLrE0YIkXsxZc6kWfNVgQNAcvI7oGtMkIEB3Bh0g/CYQmVJTxx69gxaAmgd80xy8KFjpJCU
FozkusKcJ5M0cKxkuU5nEJg21a5l25Zmg1r8yPzAVmYNG4Fw9NJKWBGPnoUamz4D4QFSxYdUn109
seEEJQ5dVYTMJKOcyU0nNaVTV7bPKVRuRY8mXfpKPp1yc+pSwGsAQVRD88Y5pPDOwIG3OzB4OM2Y
04CKBHusMClBVa3VOizI1k1yCw2VMoHtTNYzO3cvU5nm3t27/mhaOXfKNcQrIEGCwvbm62sb8J3H
untXMNYs96K/3zC23kgpWwcJKmiBsq74uOwFBphhoIQFG0TpBuuuW0A8tLb77kIMM5wHLvHkggig
YsJA742hghEoGqRuww03adwbrD9EMAgiQESsQsQwqER6RKQPvHGsBj784EOSPxrTrIcIsTsrNA2b
dPJJLeBKjSeIJgCogIB+KZFEEttDpo4vYbCtvkI42uCQnppjiqlpJumAwBakE2cCqAzkBIQFY+AD
Bg1SEuWkJD2b8JS0oDT0UEST4HAfQcYI0SU0tlRPrx9yS2bFFWNwiJHCzmTTGYfejFGGyB5LgTJR
m2mskeKG/tzAua2AbMzOSgzsbKzrfECAUAsT9fVXDKXsUK66FkkDr9ngSNbL3L5UZqmm1szgqF0R
C7WxyOBUoVYPGGhu1q0W2WrWCywzMkE9E2znwc0CFXTJQoGVd17SFh3PlgN2CQKgu7Rcb68wdEsK
04Ggsoy3O37bdZCBIuEvVAsMUA7aGF+lkyoUAuwmBP8ckfOTWtEt7EGy3MUOtHjpVXnlt05RLSN9
WkuWy7zc4MVSZ1fscatDfksRjwCZYzOyrQAMEIS6tCpOQGooeYybcUPQ2JGDS+hTyB32BBTJXP8A
LYBeWRZ77FZ6tddDXAY1QAGB2jZI2TWMwRlTFQfSaOA1/hj6chIsPZ3ko1cdqPMqoZf6BoToUnAk
akfI7aYdAPVEGqVzcO26hwl1YoNszjvnwuwO770lkkhn1qtELH+um+BkVETGNgzsuGbqOxJhDhID
6ozukbpOEByDjBefdeOqNh5yqxDGGtcczja7vB2Uw/Z8euqjKIJDfTwMpBg1hqgZGDeGMkBn8lkX
+FK/do0dsm8eQYQjRRzIZvinF/+m3OOCX/Dbku5kgbM73ep5fzhLAcBWPQQm0AnXy57oxsAaCQDB
X/86XQOAwJCBmS8prlMd7SS2mKnA736GAYcIJDE4OvWpW90q2iWY9xUINW+AOFjSARR4Qxwe4XoF
mBLa/j7EtvQkS1JeKB/rCHY+1V3gP+87zGLC1QHlZIARi4hEYWZlruf8r13OU8kMBwUU6eVQjGRL
RS0c6JKzQMQXqOAS3GzmF0sZ8XXnc1Z/lEERC0TxTFepIgW0YoIPaOs5zNvEFhFkMpY8RAgGDOMY
HUmvHQ7rJ2LQRSDKgB7ToY4WHDRiBumYImoEhzgxio6AKuG0rghSMuYiGRdnuIMlbe6Rsxxb3LKn
PW28Jj1woyAtLtVJgX3yS7WrwDLcRwk3LcQEpsriOPx3jspFUweIHIVLwNhIWmbzSduhRQ8nWUnN
5WNmslEWJzsJzCRKBWLZmkwz3YnFGEpTgF1LjS+w/qlNfAZLhzhh1C2oKIggTqogyHodOgsqzPT9
BWI4MlWP3DnIAFKncq/02iIPmE+MbnOfXzgjEMpAgDLI7HsC3QuLMki3I5rUNq1bJ47exMyHdqVd
mcHVkShaA5e9IaM71RA3+dnRnORibfkyQL/WEz5lnfSTJ93gMJ2qzFJlBaYxhaghZxrDAVrTnjzl
6nd8SiFc1uWSbhunG1caR/IVtHWgXOc0GKpKqrrwmYXc4k11AK+UdVWvbvFpP2/xKBGZjqRJHRgn
Vze3JLpooeyEa1ync5mr/kkTNn2eNYua171m1i0/PeOMJAAQzY1oiLKRD1I2aNqEpq+tL2XtVB2L
/gkshkWyW7spXu+pWdzKBCcdFUROFpCLz24JqWatg0qNa9LUWmuxgASkVBv72kJG1HmSleHzKOSL
3Ga3LRaMC744moZa9Gu4/2LRHFV32uQqdLXLRMFzoTtXmqKDupS9HF61e1+b8BNtPQECTrREzgqa
CL1qRalC2area4nqvTKFJjRbabkBghWz+KWwKyyUj+7+1RTiqdlwhXuXtTYAMWslMZhM3NLWtnfB
zoRsAOuKoHmyxLYVpvEskOAFNPIEEKkZ0dvIe9Y6otTEzUJwW5nr3vfCM6KHDMU0vVhPndZYyqu4
8Nn2C5FK9RgvbZQNkEE54L8YGMUuVfGKLRFb/rHINp615dVtp/zmJ1RZH7z90AKKcawJetisPyux
Yt1TZIccGclmjqb/XEndGLPkulGGc6OxcD0r88MU/YjNUcnbhpWO2LzpXW8gmetaQmMmvrNlF6Kf
t+EKudnRq1aUEYSlGojceSd4FuyWkbXWID81zKsNtFRDfWY1R3cH853hnNnIamRLIRWRvoV5mjG+
gI70x2LWWx3fw2tPH/nXj/1fOSIL4Vei+tjJJncTlj1ntP32t9B226W/NzcwoU+x1VbumH29bdka
Wrqmnm5W21xugHfh1Q707Vl+4K/ZbPmozVoItQEDaKgu86X4lqtEX5zoXH0x1QHn+I2FRWdU/ve3
lwBum2oNjLMh85qECr43xTOTb6v6qbpdW/SEO45s1EhS0upeAIjf3caSDmcaEMd2Hpp7KpfnW9/S
5HcXLyduRt8c4Ae5Jb7sDBrvDZbL/qo3vYtudJYf/dP4PhhY9m1Vu9ZgxlIPeM6vXCle/HcYQF+P
0FUO1WOQeeJJf3mwSS3fdVATc1+zOdsdbUu/MioQvlD4pISYD2wjvVTavrevB03Vsi9Z35NlV9oT
ZGywqdrwNcZe4tMYVGn72ER5+3qn9c73kXxlolsDPMZJ8Y6ojx7O3ES8h7B+LFu7McB2cwjREwx2
yoN624QMS8wFWHsJLSn0ui834jsbyxVN/pCkyGrDOo2f4NdfPskHcrDFZZ52tdlT9NTHr/VVs0jc
gG+wAN5kw1uP90+LH7qsJH9duSj4ddA4WWI/nOMhnfuJd4g/hWu81au/++s1EpI49tK/1yo7Qroq
V7qpLxqfwiNAGmuDA8QX+Mu+hKM7AXtAI2MtVIG9l1MyC5yoQxsgAbwoD1w19+OJEQyokqKZ0xmE
h3MrFAs75+I72eM/zpu9maOo9BvAGnS03Uq86wI+8dI+SyMRFOy11qLA5Vu6FyI2ADSLd6DBJmy0
JwSqRZJCBlzA0yE+UTm+iAukvds7FpwsYWO6DPzCwbOo9RvDzALBEOwtoFBA+Quwuvs+/jhcLE9z
KBYUtfIzP3Wgr1MroOnjQzj7Kd/LQS3jwbn7ryBIwTZMRIZirzJbRNlzMTuMQYqyrz2kxK7ygqqb
pAQsQa1bODxYOeQDPxVsKFL0CokyO6xqOhkUwOthxSnrJt6KxUwUPvUIH4a7FsoTQuWbQ0Y8mH6D
QXCbIVUkRinLuesDDUyRP02qIJyAuKMDwuQTxUWcDuY7wi6CxFPjFTHUxvbjrmPMwTwjxE3EtOUK
P21LR140O1+kvQxMQpqjEHhYRXnEKNTwJkAEPtEyQQb8r1t8xonMQn/suwYjGc0AxnDTuNxLSO3C
sHrExE18PEwjkWZcOQm0yGjcxRaL/i4kZLLOS8U2Q0iQzKY3mLVLHEcFHC8fkw27U7EsBEWWvEg0
Ozt5gj7PW7ubvC9ufL8RnEKfHCmbwYl+FEqs1MKkO0I7JDXbi0R4tMmmnCUM870CQsNl1EReuovh
WAECSbEhvMiliy/ns0Y8JIUNk6AOHEueekocDEQSdDxx5DI2zLYyg0u57LaAPDv/c0dsDEu+zK6y
HEnA1D6kIidm7ETDRLp2QsfEnEZHrL27FJSaE8vIHCO/bDZM/LntIy8fxMrO1MpfK8XyQzuZpK3R
vKs5+8jT1KvSg0rwwqSty8c82y1QHEUWkM3ZfKYLhEGZ9LyK0g7T7M0cYjYRBMy2/glHtQwG8FJO
o8RIrmxMpYTOdoCXeKROvQKrv+TJ+FPLWtMLzUTOz+SK8Py7arSc3ByF6JlO9FQgY6QSZJzCtZy7
7xGClptPcTjK2oxJgrSrvGSk/tQs62xI9lTDy9xBNjBQ75TGzUPKriRPvIyeCO1DAzQ9e9TB1ky9
3ToAz0RQbsPIJSu1msIqEBVG/hxRBEK3v4xK1qTCk8QLfdhQDq3DGEXKUchPzJG+G8XR6fnPZiug
bxwvzNw+DXXRFoitjGw+u/xFEI3ONDhPJsWoEgVO9kQ4wazCnLwgK/3HRgy25hzILv2MUwDTMMUn
S4RKgmnAC4XIKl1TYMOMN01K/hqNUxutU67SUdWMxUEc0Ab0QzoQUjPLPEnVvIsTi6/UQB7bS0Md
I8560hMtwcdjxgkigE700xaky+cUVBlC0pNZJE3d1By600TFztQzwcGqBUhdTpj7kw7lPKeLUxrC
vVeFVQXq1PWkNQJdvVCFA1INGBflyiKlreaRVo6EThtdUmJVmd7bUYdszx3EUMcrhlwNtUltJdz8
VWCFpQIa1mxFIGOdVUFM1gulvxXVCFOlw3VU1ZU4v3T9PFdl13ZtUtPDPkEcLUtDKjmQg3F9KOYb
tUoFIIhtUBCNJd4MWBxyRcqMUjMNPpPMUFJVRJejzZeEIQaV2H4tBWHFVov9/hUcM1GgQMtZZNRh
CIJikMvmPNXOK5mTvQ6KVdmVZdkMQ0AebbeNHcQSlANxTcfMG1l2TDNU3NlqqsmffSTuYsjrKlNw
HLmFgwtStVci7L8GM9LxhFrP0Co3mFpHejUApVXLLNp8bJs5yAmb7VU3LVmylbGa9Fm0hZIJ1SqH
vEet5SU2INWadUmY/NB9XdW7JYWe1du93SaOOtaebFvWzD7wQdrfUNoYrUtyoFFWXcp/c9zH7Slj
864zbM89bdQ1vAvC9dqQvdK6bcxLXVy1Owu9GN0bGjhPpVWiTctlNEmkpYMWXTD+40IkfLBBpd0e
sC2AxV156VuCbTxZHKis/uWQOQDZITWk401V5Y1a6Wxe5wVahvRbngQxAaVK6h2GOSiGcdlK86MO
/Jy5z/W8xauQSQxf6tHd62Tb9BXc4RSI9c1cstM8b7M4dJ3fid1NSMPf6vlNyX3In1NDrUOIOcid
SGXEOgzUGY3Y7h0FqFtgBqYe9YTXPBUso83a7gnghYXRxyrXU0xCBLYrY7vdEJ6eoG1ImJ3XE7bV
4BXeCmxhQD0kxP2/2b1bjRsCVxPdGjYNM4LXv0XfHV7W4DWGCwZNLbXNDpZBjoKH+11ismliEn5I
343Ijl3fpI2pmQrim/1QtMtidkAZOvXilRnTHS3hKN5OHTRjiBi/pSVg/uezVCdzY7z8rmGUY865
QaENTgjeYaK4UAoOkSwqRQVtY0EFPMcUZH8FIx0yZLIxwM5CRhX1XbkjKTP24dhTzF58wTfl0uqK
YfrNVJhQYk5ui3cV2vJdZEZGSR4khgBuX9iqOJiU0ZjzwmvEZDm9plnmHDre3ycGXOl15i5R4V8m
v7nC1179VWJLXmNGWX3g4mQemzJ8YDG2UOq9TDUoZQtmU9h9SSHGZvzMZlfuV2GM42/2lRIluACV
toisXrhBZ3UetRf1VV6d1vidyWrF5CVcj3qel3BO1AotWo5NVjPt4T22YtgtXjdFVw6+5G32mnD6
l4X+lWVO5GbOpF7y/tEUXl8BSVAMfkF5YmUns+SODsBaGCLwDWnw+LgHPl+INlP39Oc+jiz4QlXP
iJDEnWkfQCObjmWc3iZZJWmNXWqDxUwzHgACANt/1t5Cez5SiGeozZyc8EmdkuWmjgWM/WRFjmCf
7lGj+oU5sOrrncs0xtK+czqTuWukbgmX2KXGo+eyLg23m9Vu9WnVTV3uXF+rbt+gjt1927y8rtHx
6FFv/msNaejrLFN93rqpLAikheuKVmOl6zYYGjb5feyuCYTAejcmpOxg+UNvDMxnFqjUrZmqFhCM
3mqm01JPMFnTZgkZEQO1DgrWzpDJFOe17um2nRRcgGsCWJ7GdmlV/ja0meztcBuDnvye4SbdEHzt
go3ZZ0ZfxCaAATCA285tSZ4BX31a6n4XQTBfEszuYFHbMIZitzXsZRRv/DYGkjXXbE4zgVxvJbRu
OxZu+Paq0IHqkh5O/xU+ZMFvqx6AkDhvalS6zu23NQNwz8AAARev7CvwC3Hg/dXY45bFzMaLt8Zv
TnEx7bXwdjbFYsZwlkDt/iphAvdw7tBfW6a1UNZT2a4gXHBwTinCIYYQrxRNGM84AT8nG/+OEcbh
qC5JaEZuOXhwq84dgeZcz81Z3j7yP5DxbiWYJfcOMG6Ul+1u+rtjKV0D8X7w5t5t+9xIiD3XR+Ty
GE/yL6/xMCeN/gOHati+Rwme0oRb7gcn7801b22GZzrPcC/HDUXGszxn4hs+y8mVYDQ/UzX48QHI
dAjfXne2T5g+aDqX8XEEvr999HoZ6e/i3RMmcSiXNoTIdBRvWkBRSrxO9Oj7iVGvUAg1db5qckDE
bMC94x7nkilfc4BAAEoOZDhf9he39VLYMc0h9eD0a16PiXs2XbZFX1avb/AhBk1Hced82CLeci5n
hBwndZyg9mq3B0TN8UkX5T9XcDcw9kzHgOmyqSInYq/O6x0zhRX9dzxfd5tw0hAX8YhedRQGhinX
9PGGX68c9yN1dszxcqwbdRsSeFqO3EQG9umNd3i/3DUP+Qc7/upk72qJx0to98Z3uHiMX4unptA+
P3hyDr5RZfhMJ++Lo6Z9X29zh4gaqviWZ4trv2w03HZhF8zwEXRNt+CaktZAbvanP/k+6PmfP0OW
D/qa8GRsV/WZH2N5Bbp8sXmIqFRE41epR3kN8IEfaO6q/xqszy+dJHrUXVRhD8fLtPlMjxVhPnsv
Qu2J9/m2d9W3z/rx5e7ulkqvH2UP83axJ2IL53seOB5onxBG+Huf/z23H3yZCA+/Ot3KtfTER/iw
t3lkN1dyh3EFISCqbwbzmHg7s6woFALNp4mXj/2Yl2iPX1SbwXuA0PuyP33TBoSC27BAoPzWR/nm
zstUf4nZ/t98jbflPk9uj+/6geB9P4hYUIfxL9gtieiHH1CXGN8eNIr9IGj+eyiCJ+TWJ8f9xCfn
N1D6vMd5mJb6LKuF7wf/jIuIHBt/2Tf/emAgCDhGmloPPmXvVnwDiuEnlieZfmtjDC88LEzC0PZ9
1zXe+z8wKBwSfweEAclYzGZFINNAsFAkmUwgq91yu94vOCwek8vmMzqtXrPb7m/DSrlMMAVNJ28C
dfZ+lErIQQyMgRNPAuLTImOj4yORAtOkxQSdXcib5iZnp+cnaChoC0YlVQZHH0tJyl8roCpJAQHh
y44NTw6uLmSv7+9i1JRpKV5Ipmiy8jJzs7NnXB1xnQYe/scIi6s2KyxtrYFPLi8wefmvAoOCZBTT
cKXdR1bDM329/T1+Z5yVKfXd9So+rwbuQWEwhItaC24p6tHQHMSIQNDhmNTO0DtM+TZy7OiRYzRL
VKhZ05ONIKxWgf7UGqAAHBBxEmdCRKdO0joZMoRhPBVPC7KPQocSLWpm3r45GaulOpktpStWA1d4
iyEph0yHNLcCs9hugSGwUxaMndBnnjyjateyJYpUTr8rqQQe3DYV27ESCQkx0YojK9fAPmyqY6Jz
wU6yFcBWUkxFatC2kidTbvaWHzG5TQXa1caZ852WMsb9ACyYq8XEjPuxRnXsNdrKsmfTdoM0GmZL
qDaD/kbp2ym2FaL7+j0dmPA6xF5ZM69zFnaAY7WnU68O5nYGkad2r3h617OfvCaqxliAwDj6dDa8
Uhp5SeQV2PKlS7du/z5t7LkvlTTZW/wfAX2WzV58kZbeOengxN5qmV2hmzHzSYhWbPhZeCFb8/Cj
FEn9fVaQb3itxMIgDnyD4EwMMndFdq5lMiGMGMo4o1Ek7CcHPACB+F9KAZ3VXQiiEeAEio4ssKBy
Q0YRF4tNTggUhTBGSSOVVdqjYTEO/uMfVJ1Bxk0gBRRYXpGNrLOERT3h2CR3Lz7JhZRTWjknnaJo
KM07/mwGlYB8PnVQByUqVOZEqXnlznZsuhgno0++/lYnpJFqMs8ddCy1pUnejeBlmOIJ19JChFa0
BJrtOahohG8CFd2jrNYnH5SRSTorrWFQKKZ2iVrDY5h8EsTHj7OYeGJ6TTBo6lKKPldfrc06i8+t
uiXbFJcDykIXiEAC2EIMAsBA5FbGivtVa6hqwCx0z6q7bj0eWJrsrnoUBAi2HtALLL6DtPRSisci
q2uTy8YmK7sFG5xMpdqtSS2+1gInoioPi7ZTRE4sV66yB0goD7MHe/yxJ7hySBKmDl/7Ciz0yivQ
mN+C+8S4XympJJOoCgwyzjmHkkmluckVL7ZOqdybj53qW8tVjMSc5ikX2AxZq7FGRrDOVVsNZQA9
/j9I8p7h/Xhyn/OOSMCwBgax9MWnKgv1fGNUeDXccWfRMzVOM1XtCYCC+evQ9rorWtI+NFHqkjXb
7GajXVAtN+M5v8hmh11r+qG92ubtaV1HwzDssRiB1aDdT7fNMTKwNn466kDdAXmOc60ioN9sDyiv
jwXA4G15KiIaOpsCmy7G4qkL//HA7qLSe7UASgXkyifJ95yYLukU1iTuzHH86ru1rep10Q3//dUv
rj4+iwz3yfxrgAbtevaGEDAk/FIYrmyj27rtPfj541x6UtWUn7ym1FeX2VHgc2QpHLyQl7hVkY4M
b9MfBNlVPA9wpz97CuBKtlU5e5VCCuyowO5+/na8VNXvgVswofeQgr8IsvBgSCEfHvrjoVjoiHl6
6GBYZrYiEWqvhBtDIZw21sIh0opCQaTg3S5oQWr5j0Wm+NyQdsiU3qmEe1K6DuK4R8QtNisvW1oi
tZjYnOZsqHwBYwUX06hGNdjIgmBkYpNIwruA/S9qa7wjHhVXoWNopnJh5IC5nGjGOqIweHk8ZAv5
B5vsyfCPdgjkBprYgSMaEpGWVGOUFvm/P3KyiRlQZLouKco1mrBjrpJFIEUXlFedEJSVHCUs4/ZK
U86naEKMJS5zycbRccwL9PFlEHUpzGESs5jGPCYyk6nMZTKzmc58JjSjKc1pUrOa1rwmNrOp/s1t
crOb3vzmMAEgTnFqYZzm3AIAuGDOcZZznelE5zq7EM8svLOc6gxAPempzy/M857wPKc98elPegJU
nu4MKEHZidB9ujOf+1xoPx0q0YeCczYTRac8BbpQimo0oxjd6DvzmU6R4pOkHR0oR0f6UYSG1KQn
fSlHNVrPi76UpgZd6UVJalKHVpQyNoWpSjdaU356lKcytedM9ZlUmDJVpysNaEg7GlWPPpWhMT1q
VY2qVKh6YaoCXSpTe9oWrQo1qDH9aVmv6lWzRnWpRn0rRl3K1a/OdQw8nSpZh1rVuNb1o0kFa17F
qhaFUvWhYAUpUf0JV6kyFqte3WtjIztX/rxetatFrWxCC4pZyjbVsJENrGDXQtiUsvSgKN3rY1nK
WLdatbCq9axiW/tYzWaWsLNV6E/JytnF0nWrQg1tZWzaUNi6Nq2d9W1vV6tWy5Z0nndtbW95+9q+
Uhetqk2tZ/8KWeAaJbdZpah0Ubtc5LIVqeONrV8vq9zjPnWnzPVuYqPL3OSaNazcJQp8O4tWrQr3
tP1tZ2Vzalma3haxrgXsQPNbWHKS9rv3pU0/p8tX//IzwrU9sIOHe+Hlmha64KWtcUWqWQVTuJ2j
bfBvH6ziFbO4xS5+MYxjLOMZ07jGNr4xjnOs4x3zuMc+/jGQgyzkIRO5yEb2hAAEgKEk/idZC0o+
cjebbCEmS1nKUN6mle+T5QBs+crX7HJ1tgxmL1uty0/eApW7cGYnM1nNal4zmuHM5TR7gc5mpjMZ
qAxmPcdZz36WMxf4/OY2B/rJhJ7zmMmsFjEzutGFdnScv5DlP8vZz3Pus6DFQOlH45nSlgbDnzl9
6Cxs+tOKlgyk2ZxqUo8a0YWW9JlHLWsrd3rSiWb1mg+ta1u/WtO0/nWsbR1sYJ96MpPmcqQv7WRk
s5nVaGa2s2Hd7F5HW9XTTjaoK23oVDPa13CuMre/Le5iozrYylb2r88N7manW9phaDe13Z1tQFcb
291+N73rfe17X5vcizZ3u9MdcICb/lveou43wlV9a1y3es8FT3i831znh+t74f7uSJMFnmslazzS
Hc+2qHc98ZCDO9OIrvXIK55vfUe82vxm+cWHknGCe5zm7La5wVEOc2EXPNSDXrfEVe5rfKf83EKP
+b/VzfGNK93oM7850VkOb3trWw1Ap/bLi671fY8b20gvCscDDe1lf3vspDZ72KNu9HqHO+gg73XD
p772QcO97V6f+9c/Endti5vvjx46rhXeZ8EHnuHeHnzhXY1wiwvb2olfe9bzrvdVP17xiHf80Rlu
8pM/XeGbn7ipNZ91Qd958z5ffNclTxRA05v1kq5zxBtN8ZOrXO6gb7Xm3U54h+Oe/vO6h/zKVR9B
iwu/2A4vfvFnHXzkk9vTzF+mp6Mv/elTv/rWvz72s6/97XP/9M+nR/fDL/7xk7/85i//99Mf5JZa
+LRmOOz7MWvfe2B3vm8IbydAywYGK0P/zID/FgFgGPgfVRHgdrnfRtRfMuAfJxjgGThgG0BgKMhV
AKbYSDEYQBXUBf6TSo0WiDlWc0HUPZGTB9pWCIKXibEWfF0gf5UgW5GgUrGfiM3ggPFfc/3VXeGW
ByqWCXKVDX4V/23gDRIX+3EgUs2WGlEggEHXTvFWEKIgej2hZBEUFWIVQ7FWX1HWCgKge1XhTLWU
CDYWF2LhFdofdk1UF5bhTanh/kmVF3lBoQ1aVwTNYAamFxzGVxoClYdxVoL9FhK24XsxoXrJnxUW
4h96mPwpYSG213n9YR4yIiD6oHyhVGrJIQQpYiR+YR3OVxOCGB8eFX9J2CbuoRGC4FlBoUFhoB3u
YUTF4Q+i4hCG1SPCVh4qYC2mVweaWAqqooNVoAWuIgNKlgJOll/V13QhWCbiFDEi1yqylyM2Y2A9
FyW+VihSl3ndoTVi4x3mInqVWIpd4nalYTAe1jDKFjAWYBZqoyEK4mIp4S0m4zee4jTC44IFmDCq
IyTKVVslVzaSWAthojg2ozKmYxSeYx8y4TN64RKu1XG540I+pEKGIRnmYF3xlmI9yuI9SpUtkmEk
fhZBRmMa0SFuFaMMWiAMltYrmiIpDqRGBpVLsZMmqiRGduQ/taRNVqIL1mRG5eQwaiAYSBRP2mMP
piBLnmBmGVg86o8Efs9SGkxTBtcaPWXqSOW6UKVkWCXcYGVWamWtpCSGcKX6haVYjiVZlqVZniVa
pqVariVbtqVbviVcxqVcziVd1qVdlkEEAAA7
------=_NextPart_000_000F_01C77DBC.3FC88CE0--




From sip-bounces@ietf.org Fri Apr 13 05:41:01 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcIGq-0002fW-Ps; Fri, 13 Apr 2007 05:40:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcIGq-0002fN-1h
	for sip@ietf.org; Fri, 13 Apr 2007 05:40:44 -0400
Received: from py-out-1112.google.com ([64.233.166.176])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcIGo-0007gE-LE
	for sip@ietf.org; Fri, 13 Apr 2007 05:40:43 -0400
Received: by py-out-1112.google.com with SMTP id f31so620120pyh
	for <sip@ietf.org>; Fri, 13 Apr 2007 02:40:42 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=gKknjzlIp5nwr9KzBxSQMe6ML2S3WsT0SXPuV5rxqc0Wm2ZBuLXqdf/TRDBgp5Fe1XP6qevPbMmHfQ3DHTiFpzEI+ckOItMlo6VA+OIIN7rrHcdanP/64w74ywpY81HD+l9RAQCWgzXNNyBemIYwFXlnoVtrddCv/cFhrtckh8s=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=j7RDkI4yjZYdUelMz1Z5d3DkZmXYQ4JiqYwmqwVtAKK5irUvlJ8STtHT01OH+WcBgOXBEpmYyDoZgzE36Wx+x6ISqZKXfxyXQ6Z5/L6fcEXyX4+g1LTUzKResJYKlIAOuG3TcU+koZkEkC7HFhBgl+xa9CNmYij+p7VJvu1y/6E=
Received: by 10.35.128.17 with SMTP id f17mr4875544pyn.1176457242363;
	Fri, 13 Apr 2007 02:40:42 -0700 (PDT)
Received: by 10.35.37.8 with HTTP; Fri, 13 Apr 2007 02:40:42 -0700 (PDT)
Message-ID: <66cd252f0704130240x707ff7f3g996c002cfb5e932@mail.gmail.com>
Date: Fri, 13 Apr 2007 19:40:42 +1000
From: "Hisham Khartabil" <hisham.khartabil@gmail.com>
To: "Dean Willis" <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
In-Reply-To: <461F00B3.1090206@softarmor.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4616851D.5070305@softarmor.com> <46172B40.8090107@softarmor.com>
	<20070407151244.87A941CC3D@delta.rtfm.com>
	<4617E6B8.5070601@softarmor.com>
	<20070407192220.253931CC3D@delta.rtfm.com>
	<46194A1A.1020705@softarmor.com>
	<20070408202105.0F2725C027@laser.networkresonance.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>
	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
	<461F00B3.1090206@softarmor.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

You are right in what you say Dean, but one thing I gotta comment on
is that I really doubt that people will be giving out business cards
with 2 sip addresses, one with sip: scheme and the other with sips:
scheme.

I vision it as one sip address, scheme is not mentioned at all in the
business card. The UI of the phone allows the user to select "secure
call" or a check box. So the scenarios are:

- I register with sips only. You call me without selecting "secure
call". Your call would fail
- I register with sips only. You call me and select "secure call".
Your call would succeed
- I register with sip only. You call me without selecting "secure
call". Your call would succeed
- I register with sip only. You call me and select "secure call". Your
call would fail
- I register both schemes, all calls succeed

Also, you wrote:
>
> Personally, I liked per-scheme registration. The WG didn't.
>

I thought that was what the group agreed. Or? Ekr suggested a MUST NOT
and no one objected.

Hisham

On 13/04/07, Dean Willis <dean.willis@softarmor.com> wrote:
> Hisham Khartabil wrote:
> > This is somehow tied with Jonathan's thread related to retargetting
> > and downgrading from sips to sip (or upgrading). If we agree to
> > disallow both, then we are also disallowing what is being discussed in
> > this thread.
> >
> Not really.
>
> Upgrading and Downgrading, in the context of Johnathan's argument, occur
> when a proxy which was presented a URI of one scheme changes it to the
> other scheme.
>
> What the current text describes is that registration of a SIPS contact
> implicitly registers the equivalent SIP contact. This doesn't mean that
> any proxy can translate SIPS to SIP or SIP to SIPS. Instead, it means
> that a user who has registered just SIPS can receive both sorts of
> requests. If the request originates with SIP it will be delivered, just
> as it would if it originated SIPS.
>
> So you could put both SIP and SIPS on your business card, and a caller
> could just pick one.
>
> What I was worried about is what happens when a user who is given only a
> SIPS URI translates it to SIP and uses that to make a request. It may
> well be that the user was given only a SIPS URI because the called party
> really wants their incoming traffic secured. There's no way to
> COMPLETELY fix this, although it can be fixed from the serving proxy to
> UAS by either 1) use of outbound over TLS, or 2) going to a per-scheme
> registration as you propose.
>
> So what I asked for is just additional guidance to the user to reinforce
> the idea that they should not make this mistake. Not that users are
> really governed by RFCs, but some of them will make fewer mistakes if
> this sort of guidance is given.
> > If a UAS wants to be contactable with over UDP or TCP/TLS, then it can
> > register with 2 contact headers.
>
> Personally, I liked per-scheme registration. The WG didn't.
>
> The reason I like it is that it removes the incentive to assume that a
> URI of a different scheme than the one you were given to use is likely
> to work. This makes mistakes less likely to happen.
>
> --
> Dean
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 13 09:20:18 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcLhG-0004sk-OS; Fri, 13 Apr 2007 09:20:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcLhF-0004ry-VC
	for sip@ietf.org; Fri, 13 Apr 2007 09:20:13 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcLhF-00029D-Jo
	for sip@ietf.org; Fri, 13 Apr 2007 09:20:13 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-2.cisco.com with ESMTP; 13 Apr 2007 09:20:13 -0400
X-IronPort-AV: i="4.14,408,1170651600"; 
	d="scan'208"; a="118435178:sNHT52964456"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3DDKDKk030485; 
	Fri, 13 Apr 2007 09:20:13 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3DDK6Gj029015; 
	Fri, 13 Apr 2007 13:20:07 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 13 Apr 2007 09:20:06 -0400
Received: from [161.44.174.118] ([161.44.174.118]) by
	xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 13 Apr 2007 09:20:06 -0400
Message-ID: <461F8385.3080905@cisco.com>
Date: Fri, 13 Apr 2007 09:20:05 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
References: <4616851D.5070305@softarmor.com>		<20070406174901.D89C45C027@laser.networkresonance.com>		<46172B40.8090107@softarmor.com>		<20070407151244.87A941CC3D@delta.rtfm.com>		<4617E6B8.5070601@softarmor.com>		<20070407192220.253931CC3D@delta.rtfm.com>		<46194A1A.1020705@softarmor.com>		<20070408202105.0F2725C027@laser.networkresonance.com>		<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
	<461F00B3.1090206@softarmor.com>
In-Reply-To: <461F00B3.1090206@softarmor.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 13 Apr 2007 13:20:06.0383 (UTC)
	FILETIME=[73DB37F0:01C77DCE]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3134; t=1176470413;
	x=1177334413; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20SIPS=20question=3A=20How=20to=20prevent=20pla
	intext=20requests=20from=20being=0A=20delivered=20to=20a=20UA
	|Sender:=20 |To:=20Dean=20Willis=20<dean.willis@softarmor.com>;
	bh=0SsQQk1fjKc4qgQugPUfCn9s/JEKVKuli9/9zbuhH+A=;
	b=O4nh51BxK6pTLXXNR8VEsu5hP0caVAYrEPTk6Cpw/eTRG2WNvqRB5P6vxP0WkVdHyzBGWNQx
	CebMNq5xOSRm0BrsyO8U2vozp3CvPe/K4qnPW6smM3d2QFxIfqV80zSJ;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org



Dean Willis wrote:
> Hisham Khartabil wrote:
>> This is somehow tied with Jonathan's thread related to retargetting
>> and downgrading from sips to sip (or upgrading). If we agree to
>> disallow both, then we are also disallowing what is being discussed in
>> this thread.
>>
> Not really.
> 
> Upgrading and Downgrading, in the context of Johnathan's argument, occur 
> when a proxy which was presented a URI of one scheme changes it to the 
> other scheme.
> 
> What the current text describes is that registration of a SIPS contact 
> implicitly registers the equivalent SIP contact. This doesn't mean that 
> any proxy can translate SIPS to SIP or SIP to SIPS. Instead, it means 
> that a user who has registered just SIPS can receive both sorts of 
> requests. If the request originates with SIP it will be delivered, just 
> as it would if it originated SIPS.
> 
> So you could put both SIP and SIPS on your business card, and a caller 
> could just pick one.
> 
> What I was worried about is what happens when a user who is given only a 
> SIPS URI translates it to SIP and uses that to make a request. It may 
> well be that the user was given only a SIPS URI because the called party 
> really wants their incoming traffic secured. There's no way to 
> COMPLETELY fix this, although it can be fixed from the serving proxy to 
> UAS by either 1) use of outbound over TLS, or 2) going to a per-scheme 
> registration as you propose.
> 
> So what I asked for is just additional guidance to the user to reinforce 
> the idea that they should not make this mistake. Not that users are 
> really governed by RFCs, but some of them will make fewer mistakes if 
> this sort of guidance is given.

I don't think so. For one thing, its quite likely that there is no 
business card. The caller may well just guess the sip/sips address from 
an email address. And even if given a sips address, they might not 
understand what that is and mistype it as sip, or they might use sip 
because the client they are using doesn't support sips.

I don't see what harm is being done to the callee in this case. In 
normal cases he can detect that the call was placed via sip and simply 
refuse to answer. If there was any important info in the request that 
might have been observed, it is info of the *caller*, who knew he was 
making an insecure call.

	Paul

>> If a UAS wants to be contactable with over UDP or TCP/TLS, then it can
>> register with 2 contact headers.
> 
> Personally, I liked per-scheme registration. The WG didn't.
> 
> The reason I like it is that it removes the incentive to assume that a 
> URI of a different scheme than the one you were given to use is likely 
> to work. This makes mistakes less likely to happen.
> 
> -- 
> Dean
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 13 09:41:35 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcM1t-0002g6-Ig; Fri, 13 Apr 2007 09:41:33 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcM1s-0002g1-Un
	for sip@ietf.org; Fri, 13 Apr 2007 09:41:32 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcM1r-0001fW-HQ
	for sip@ietf.org; Fri, 13 Apr 2007 09:41:32 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 13 Apr 2007 09:41:32 -0400
X-IronPort-AV: i="4.14,408,1170651600"; 
	d="scan'208"; a="57562676:sNHT53693184"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3DDfVXT007583; 
	Fri, 13 Apr 2007 09:41:31 -0400
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 l3DDfVlG012547; 
	Fri, 13 Apr 2007 13:41:31 GMT
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.1830); 
	Fri, 13 Apr 2007 09:41:29 -0400
Received: from [161.44.174.118] ([161.44.174.118]) by
	xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 13 Apr 2007 09:41:28 -0400
Message-ID: <461F888A.2080609@cisco.com>
Date: Fri, 13 Apr 2007 09:41:30 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Hisham Khartabil <hisham.khartabil@gmail.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
References: <4616851D.5070305@softarmor.com>
	<46172B40.8090107@softarmor.com>	<20070407151244.87A941CC3D@delta.rtfm.com>	<4617E6B8.5070601@softarmor.com>	<20070407192220.253931CC3D@delta.rtfm.com>	<46194A1A.1020705@softarmor.com>	<20070408202105.0F2725C027@laser.networkresonance.com>	<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>	<461F00B3.1090206@softarmor.com>
	<66cd252f0704130240x707ff7f3g996c002cfb5e932@mail.gmail.com>
In-Reply-To: <66cd252f0704130240x707ff7f3g996c002cfb5e932@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 13 Apr 2007 13:41:28.0759 (UTC)
	FILETIME=[70364470:01C77DD1]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4024; t=1176471691;
	x=1177335691; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20SIPS=20question=3A=20How=20to=20prevent=20pla
	intext=20requests=20from=20being=0A=20delivered=20to=20a=20UA
	|Sender:=20
	|To:=20Hisham=20Khartabil=20<hisham.khartabil@gmail.com>;
	bh=2bAfiVIxHfjCz6qZsJuDUd2AsTi5HAAILWsP0CKs3TQ=;
	b=dR1fpHKlf9q4mMleOh9UJAL2+9fs6inVHgLlk1Jco8M/7wp4d/cr0NK7svtDHakNI9mZhtp9
	Qi6KoxveV+KH84SqpvY4/2cNDWe27XCTLs6WiHbQBJt3eW34ifX5Lof8;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hisham,

I don't understand how you expect the registering of two schemes to 
work. Suppose the phone needs to use outbound. Are you suggesting that 
it needs to establish one outbound connection for sips and a different 
one for sip? Why would anyone want to incur that extra cost compared to 
simply receiving both sip and sips calls over the same connection?

	Paul

Hisham Khartabil wrote:
> You are right in what you say Dean, but one thing I gotta comment on
> is that I really doubt that people will be giving out business cards
> with 2 sip addresses, one with sip: scheme and the other with sips:
> scheme.
> 
> I vision it as one sip address, scheme is not mentioned at all in the
> business card. The UI of the phone allows the user to select "secure
> call" or a check box. So the scenarios are:
> 
> - I register with sips only. You call me without selecting "secure
> call". Your call would fail
> - I register with sips only. You call me and select "secure call".
> Your call would succeed
> - I register with sip only. You call me without selecting "secure
> call". Your call would succeed
> - I register with sip only. You call me and select "secure call". Your
> call would fail
> - I register both schemes, all calls succeed
> 
> Also, you wrote:
>>
>> Personally, I liked per-scheme registration. The WG didn't.
>>
> 
> I thought that was what the group agreed. Or? Ekr suggested a MUST NOT
> and no one objected.
> 
> Hisham
> 
> On 13/04/07, Dean Willis <dean.willis@softarmor.com> wrote:
>> Hisham Khartabil wrote:
>> > This is somehow tied with Jonathan's thread related to retargetting
>> > and downgrading from sips to sip (or upgrading). If we agree to
>> > disallow both, then we are also disallowing what is being discussed in
>> > this thread.
>> >
>> Not really.
>>
>> Upgrading and Downgrading, in the context of Johnathan's argument, occur
>> when a proxy which was presented a URI of one scheme changes it to the
>> other scheme.
>>
>> What the current text describes is that registration of a SIPS contact
>> implicitly registers the equivalent SIP contact. This doesn't mean that
>> any proxy can translate SIPS to SIP or SIP to SIPS. Instead, it means
>> that a user who has registered just SIPS can receive both sorts of
>> requests. If the request originates with SIP it will be delivered, just
>> as it would if it originated SIPS.
>>
>> So you could put both SIP and SIPS on your business card, and a caller
>> could just pick one.
>>
>> What I was worried about is what happens when a user who is given only a
>> SIPS URI translates it to SIP and uses that to make a request. It may
>> well be that the user was given only a SIPS URI because the called party
>> really wants their incoming traffic secured. There's no way to
>> COMPLETELY fix this, although it can be fixed from the serving proxy to
>> UAS by either 1) use of outbound over TLS, or 2) going to a per-scheme
>> registration as you propose.
>>
>> So what I asked for is just additional guidance to the user to reinforce
>> the idea that they should not make this mistake. Not that users are
>> really governed by RFCs, but some of them will make fewer mistakes if
>> this sort of guidance is given.
>> > If a UAS wants to be contactable with over UDP or TCP/TLS, then it can
>> > register with 2 contact headers.
>>
>> Personally, I liked per-scheme registration. The WG didn't.
>>
>> The reason I like it is that it removes the incentive to assume that a
>> URI of a different scheme than the one you were given to use is likely
>> to work. This makes mistakes less likely to happen.
>>
>> -- 
>> Dean
>>
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 13 10:43:02 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcMzE-0000V9-Ba; Fri, 13 Apr 2007 10:42:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcMzD-0000V4-0D
	for sip@ietf.org; Fri, 13 Apr 2007 10:42:51 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcMzB-0005BI-MS
	for sip@ietf.org; Fri, 13 Apr 2007 10:42:50 -0400
Received: from [206.176.144.210] (206-176-144-210.waymark.net
	[206.176.144.210]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3DDnJoK010699
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 13 Apr 2007 08:49:20 -0500
Message-ID: <461F96EE.3030400@softarmor.com>
Date: Fri, 13 Apr 2007 09:42:54 -0500
From: Dean Willis <dean.willis@softarmor.com>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
References: <4616851D.5070305@softarmor.com>		<20070406174901.D89C45C027@laser.networkresonance.com>		<46172B40.8090107@softarmor.com>		<20070407151244.87A941CC3D@delta.rtfm.com>		<4617E6B8.5070601@softarmor.com>		<20070407192220.253931CC3D@delta.rtfm.com>		<46194A1A.1020705@softarmor.com>		<20070408202105.0F2725C027@laser.networkresonance.com>		<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
	<461F00B3.1090206@softarmor.com> <461F8385.3080905@cisco.com>
In-Reply-To: <461F8385.3080905@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Paul Kyzivat wrote:
  . . .

> I don't think so. For one thing, its quite likely that there is no 
> business card. The caller may well just guess the sip/sips address from 
> an email address. And even if given a sips address, they might not 
> understand what that is and mistype it as sip, or they might use sip 
> because the client they are using doesn't support sips.
> 
> I don't see what harm is being done to the callee in this case. In 
> normal cases he can detect that the call was placed via sip and simply 
> refuse to answer. If there was any important info in the request that 
> might have been observed, it is info of the *caller*, who knew he was 
> making an insecure call.

No, it is the info of the CALLEE that I am worried about.

Let's take the very first INVITE example from RFC 3665, "Alice Calls Bob 
Directly".

    INVITE sip:bob@biloxi.example.com SIP/2.0
    Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    Max-Forwards: 70
    From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
    To: Bob <sip:bob@biloxi.example.com>
    Call-ID: 3848276298220188511@atlanta.example.com
    CSeq: 1 INVITE
    Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
    Content-Type: application/sdp
    Content-Length: 151

    v=0
    o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
    s=-
    c=IN IP4 192.0.2.101
    t=0 0
    m=audio 49172 RTP/AVP 0
    a=rtpmap:0 PCMU/8000


This message reveals that the target Bob is reachable at host 
"biloxi.example.com".

Since traceroute on biloxi.example.com may well give us a good idea of 
the physical location of biloxi.example.com, an interceptor picking up 
this message would have a good chance of being able to find Bob.

Assuming that  this message is sent unencrypted when used with SIP 
(instead of SIPS), it's relatively easy to intercept.

The interceptor didn't need credentials to get into a location server 
that might translate bob@example.com to bob@biloxi.example.com. They 
didn't need credentials to look in a directory server. They just pulled 
the information "off the wire" in such a way that Bob will be unable to 
know how the interceptor got his location.

The ONLY defenses Bob has against this sort of thing are:
1) use an outbound proxy with TLS, which only works in some architectures
2) Train everybody that calls him to use SIPS instead of SIP.

I'm looking for ways to encourage #2, and don't feel that the current 
"SIPS registrations mean you want SIP and SIPS to reach you" is helpful.

What other tricks migt apply? DNS configuration on biloxi.example.com, 
maybe?

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 13 10:47:52 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcN43-0004al-Kz; Fri, 13 Apr 2007 10:47:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcN42-0004WB-H1
	for sip@ietf.org; Fri, 13 Apr 2007 10:47:50 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcN3z-00064n-MU
	for sip@ietf.org; Fri, 13 Apr 2007 10:47:50 -0400
Received: from [206.176.144.210] (206-176-144-210.waymark.net
	[206.176.144.210]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3DDsMX2010738
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 13 Apr 2007 08:54:23 -0500
Message-ID: <461F981C.5070909@softarmor.com>
Date: Fri, 13 Apr 2007 09:47:56 -0500
From: Dean Willis <dean.willis@softarmor.com>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
References: <4616851D.5070305@softarmor.com>	<46172B40.8090107@softarmor.com>	<20070407151244.87A941CC3D@delta.rtfm.com>	<4617E6B8.5070601@softarmor.com>	<20070407192220.253931CC3D@delta.rtfm.com>	<46194A1A.1020705@softarmor.com>	<20070408202105.0F2725C027@laser.networkresonance.com>	<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>	<461F00B3.1090206@softarmor.com>	<66cd252f0704130240x707ff7f3g996c002cfb5e932@mail.gmail.com>
	<461F888A.2080609@cisco.com>
In-Reply-To: <461F888A.2080609@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Paul Kyzivat wrote:
> Hisham,
> 
> I don't understand how you expect the registering of two schemes to 
> work. Suppose the phone needs to use outbound. Are you suggesting that 
> it needs to establish one outbound connection for sips and a different 
> one for sip? Why would anyone want to incur that extra cost compared to 
> simply receiving both sip and sips calls over the same connection?

Why couldn't both the SIP and SIPS registration share one TLS connection?


Here's another question. Say Bob is registering to a location server 
(that sends a 302). Bob register only a SIPS contact.


Alice sends a SIP INVITE to the location server, targeting Bob's AOR.

Does the 302 that comes back point to a SIP or SIPS target?

With singular registration of SIPS, it has to have both, right?   Or 
does the location server return only a SIP contact for a SIP query and a 
SIPS contact for a SIPS query?

How would we register such that the location server returns only a SIPS 
response?

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 13 10:59:11 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcNEz-0003BB-Th; Fri, 13 Apr 2007 10:59:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcNEy-0003B1-Ml
	for sip@ietf.org; Fri, 13 Apr 2007 10:59:08 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcNEy-0000W8-6b
	for sip@ietf.org; Fri, 13 Apr 2007 10:59:08 -0400
Received: from sj-dkim-8.cisco.com ([171.68.10.93])
	by sj-iport-5.cisco.com with ESMTP; 13 Apr 2007 07:59:08 -0700
X-IronPort-AV: i="4.14,408,1170662400"; 
	d="scan'208"; a="411173509:sNHT53157052"
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
	by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l3DEx7N1006819; 
	Fri, 13 Apr 2007 07:59:07 -0700
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l3DEwUAe029005;
	Fri, 13 Apr 2007 14:59:07 GMT
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.1830); 
	Fri, 13 Apr 2007 10:58:56 -0400
Received: from [161.44.174.118] ([161.44.174.118]) by
	xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 13 Apr 2007 10:58:56 -0400
Message-ID: <461F9AA9.4010700@cisco.com>
Date: Fri, 13 Apr 2007 10:58:49 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
References: <4616851D.5070305@softarmor.com>		<20070406174901.D89C45C027@laser.networkresonance.com>		<46172B40.8090107@softarmor.com>		<20070407151244.87A941CC3D@delta.rtfm.com>		<4617E6B8.5070601@softarmor.com>		<20070407192220.253931CC3D@delta.rtfm.com>		<46194A1A.1020705@softarmor.com>		<20070408202105.0F2725C027@laser.networkresonance.com>		<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
	<461F00B3.1090206@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
In-Reply-To: <461F96EE.3030400@softarmor.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 13 Apr 2007 14:58:56.0087 (UTC)
	FILETIME=[423C3E70:01C77DDC]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3742; t=1176476347;
	x=1177340347; c=relaxed/simple; s=sjdkim8002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20SIPS=20question=3A=20How=20to=20prevent=20pla
	intext=20requests=20from=20being=0A=20delivered=20to=20a=20UA
	|Sender:=20; bh=gxUls4acqyLa42jZK/QVJsBqECHm1W9rqTsYBOfydpU=;
	b=v80krTXP7fSt5Bxrrm8iOcygGMi3sOfZWEYHNktHlxsBBlLd0/kuNsCPntyZMMMCdP2BIBrL
	sa4YhwmAT+KKY/OeqLGUfsLtVl/+CYiHUfXSm7EyBjWYjhJzNGGNCGO3;
Authentication-Results: sj-dkim-8; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim8002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org



Dean Willis wrote:
> Paul Kyzivat wrote:
>  . . .
> 
>> I don't think so. For one thing, its quite likely that there is no 
>> business card. The caller may well just guess the sip/sips address 
>> from an email address. And even if given a sips address, they might 
>> not understand what that is and mistype it as sip, or they might use 
>> sip because the client they are using doesn't support sips.
>>
>> I don't see what harm is being done to the callee in this case. In 
>> normal cases he can detect that the call was placed via sip and simply 
>> refuse to answer. If there was any important info in the request that 
>> might have been observed, it is info of the *caller*, who knew he was 
>> making an insecure call.
> 
> No, it is the info of the CALLEE that I am worried about.
> 
> Let's take the very first INVITE example from RFC 3665, "Alice Calls Bob 
> Directly".
> 
>    INVITE sip:bob@biloxi.example.com SIP/2.0
>    Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
>    Max-Forwards: 70
>    From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
>    To: Bob <sip:bob@biloxi.example.com>
>    Call-ID: 3848276298220188511@atlanta.example.com
>    CSeq: 1 INVITE
>    Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
>    Content-Type: application/sdp
>    Content-Length: 151
> 
>    v=0
>    o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
>    s=-
>    c=IN IP4 192.0.2.101
>    t=0 0
>    m=audio 49172 RTP/AVP 0
>    a=rtpmap:0 PCMU/8000
> 
> 
> This message reveals that the target Bob is reachable at host 
> "biloxi.example.com".

*This* message only reveals that Alice *thinks* Bob is reachable at that 
address. Its no worse than intercepting an email from Alice to Charlie 
that mentions the sip (or sips) address of Bob.

If you want to prevent Alice from disclosing the address of Bob then you 
have a much harder problem. I don't think this is solvable in practice, 
nor do I think it needs to be solved.

> Since traceroute on biloxi.example.com may well give us a good idea of 
> the physical location of biloxi.example.com, an interceptor picking up 
> this message would have a good chance of being able to find Bob.

No. Only Bob's home proxy.

> Assuming that  this message is sent unencrypted when used with SIP 
> (instead of SIPS), it's relatively easy to intercept.
> 
> The interceptor didn't need credentials to get into a location server 
> that might translate bob@example.com to bob@biloxi.example.com. They 
> didn't need credentials to look in a directory server. They just pulled 
> the information "off the wire" in such a way that Bob will be unable to 
> know how the interceptor got his location.

I don't see how this discloses the address bob@biloxi.example.com, which 
is the only one that Bob has any chance of hiding. All Bob needs to do 
is be careful in what he puts into his *response* to the above invite. 
(E.g. He shouldn't put his contact address if he is rejecting the call, 
and he should ensure his address isn't mentioned in a H-I header.) If he 
is really paranoid about this he could simply refuse to send any 
response to the invite, and let it timeout.

	Paul

> The ONLY defenses Bob has against this sort of thing are:
> 1) use an outbound proxy with TLS, which only works in some architectures
> 2) Train everybody that calls him to use SIPS instead of SIP.
> 
> I'm looking for ways to encourage #2, and don't feel that the current 
> "SIPS registrations mean you want SIP and SIPS to reach you" is helpful.
> 
> What other tricks migt apply? DNS configuration on biloxi.example.com, 
> maybe?
> 
> -- 
> Dean
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 13 11:10:49 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcNQE-00020M-Sh; Fri, 13 Apr 2007 11:10:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcNQD-00020G-Ao
	for sip@ietf.org; Fri, 13 Apr 2007 11:10:45 -0400
Received: from zrtps0kn.nortel.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcNQB-00063x-0y
	for sip@ietf.org; Fri, 13 Apr 2007 11:10:45 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3DFAdY10031; Fri, 13 Apr 2007 15:10:40 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
Date: Fri, 13 Apr 2007 10:10:24 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF10051E30@zrc2hxm0.corp.nortel.com>
In-Reply-To: <66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being delivered to a UA
thread-index: Acd9eXPEGO2uHmYsS0iXW1h6PrfAKwAZDJNg
References: <4616851D.5070305@softarmor.com>
	<20070406174901.D89C45C027@laser.networkresonance.com>
	<46172B40.8090107@softarmor.com>
	<20070407151244.87A941CC3D@delta.rtfm.com>
	<4617E6B8.5070601@softarmor.com>
	<20070407192220.253931CC3D@delta.rtfm.com>
	<46194A1A.1020705@softarmor.com>
	<20070408202105.0F2725C027@laser.networkresonance.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>
	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
From: "Francois Audet" <audet@nortel.com>
To: "Hisham Khartabil" <hisham.khartabil@gmail.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Cc: sip@ietf.org, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

We went through this in Montreal.

My initial draft worked that way, and people didn't like it.

If you register with 2 contacts, you may end-up getting a request
forked to these two contacts.

Also, my initial draft was quite complicated because of this.

I will also point out that we do NOT do this with UDP versus
TCP transport.=20

> -----Original Message-----
> From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com]=20
> Sent: Thursday, April 12, 2007 20:12
> To: Audet, Francois (SC100:3055)
> Cc: Eric Rescorla; Dean Willis; sip@ietf.org
> Subject: Re: [Sip] SIPS question: How to prevent plaintext=20
> requests from being delivered to a UA
>=20
> This is somehow tied with Jonathan's thread related to=20
> retargetting and downgrading from sips to sip (or upgrading).=20
> If we agree to disallow both, then we are also disallowing=20
> what is being discussed in this thread.
>=20
> If a UAS wants to be contactable with over UDP or TCP/TLS,=20
> then it can register with 2 contact headers.
>=20
> Hisham
>=20
> On 10/04/07, Francois Audet <audet@nortel.com> wrote:
> >
> >
> > > -----Original Message-----
> > > From: Eric Rescorla [mailto:ekr@networkresonance.com]
> > > Sent: Sunday, April 08, 2007 13:22
> > > To: Dean Willis
> > > Cc: sip@ietf.org
> > > Subject: Re: [Sip] SIPS question: How to prevent=20
> plaintext requests=20
> > > from being delivered to a UA
> > >
> > > > All of these, taken together, say to me that it is
> > > reasonable for a user
> > > > who is handed a business card with only a SIPS URI on it to
> > > guess an
> > > > equivalent SIP URI and use it, and that the infrastructure
> > > will route
> > > > this request to the UAS. If that UAS is NOT using
> > > "outbound", then the
> > > > last hop may well be traversed without TLS.
> > >
> > > Well, I don't agree with this interpretation, but luckily since=20
> > > we're writing the spec rather than interpretating it, we=20
> don't have=20
> > > to engage in a lot of exegesis. I assert that if you're=20
> given only=20
> > > SIPS URI you MUST NOT attempt to map it to a SIP URI. Is there=20
> > > anyone who disagrees with this? If not, then why don't=20
> you propose=20
> > > some language that you believe would make this clear.
> >
> > I agree with Eric.
> >
> > I will clarify.
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use=20
> > sip-implementors@cs.columbia.edu for questions on current sip Use=20
> > sipping@ietf.org for new developments on the application of sip
> >
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 13 11:11:03 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcNQV-0002Ym-Ho; Fri, 13 Apr 2007 11:11:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcNQU-0002WF-7e
	for sip@ietf.org; Fri, 13 Apr 2007 11:11:02 -0400
Received: from zrtps0kn.nortel.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcNQT-0006L7-V9
	for sip@ietf.org; Fri, 13 Apr 2007 11:11:02 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3DFAxY10091; Fri, 13 Apr 2007 15:10:59 GMT
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: [Sip] SIPS issue: Option tag
Date: Fri, 13 Apr 2007 10:10:56 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF10051E34@zrc2hxm0.corp.nortel.com>
In-Reply-To: <66cd252f0704121931v32a462d5m36e1364acd1d2972@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS issue: Option tag
thread-index: Acd9c9y7R8H0JqIDQcyyJKJwN95XYwAagRHA
References: <4616851D.5070305@softarmor.com>
	<DEA96B3C-3F47-4226-899B-9C9CFD5B5B50@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFCD3E@zrc2hxm0.corp.nortel.com>
	<461732B2.6070705@softarmor.com>
	<05BFBEBE-CCBA-42B4-8BD0-C71B590487EB@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFCE7A@zrc2hxm0.corp.nortel.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFCEB0@zrc2hxm0.corp.nortel.com>
	<66cd252f0704121931v32a462d5m36e1364acd1d2972@mail.gmail.com>
From: "Francois Audet" <audet@nortel.com>
To: "Hisham Khartabil" <hisham.khartabil@gmail.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: sip@ietf.org, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

This draft IS an extension because it changes the normative behavior of
RFC 3261.=20

> -----Original Message-----
> From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com]=20
> Sent: Thursday, April 12, 2007 19:31
> To: Audet, Francois (SC100:3055)
> Cc: sip@ietf.org; Dean Willis
> Subject: Re: [Sip] SIPS issue: Option tag
>=20
> I thought option tags were for extension, not updates that=20
> fix broken protocols.
>=20
> Hisham
>=20
> On 08/04/07, Francois Audet <audet@nortel.com> wrote:
> > Dean Willis has suggested that we should have a "sips" option-tag=20
> > defined for implementations that support the procedures of=20
> > draft-ietf-sip-sips.
> >
> > This is standard practice to deal with backward compatibility.
> >
> > In this particular case, it would be for implementations that=20
> > supported RFC 3261 before draft-ietf-sip-sips was standardized.
> > Those implementions are very likely to use procedurs that do not=20
> > comply with this specification (e.g., some may be using the=20
> > transport=3Dtls parameter, may be registering explictly both SIP and =

> > SIPS contacts, may be using the last hop-exception, etc.).=20
> Proxies and=20
> > UAs that support these legacy UAs would therefore use=20
> whatever coping=20
> > techniques that would "work".
> >
> > Unless there is a good reason NOT to define a sips=20
> option-tag for this=20
> > purpose, I will include it in the next release.
> >
> > Comments?
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use=20
> > sip-implementors@cs.columbia.edu for questions on current sip Use=20
> > sipping@ietf.org for new developments on the application of sip
> >
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 13 11:23:58 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcNcy-0002Ue-5U; Fri, 13 Apr 2007 11:23:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcNcw-0002UP-Gy
	for sip@ietf.org; Fri, 13 Apr 2007 11:23:54 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcNcv-0003hU-6R
	for sip@ietf.org; Fri, 13 Apr 2007 11:23:54 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3DFNjv28566; Fri, 13 Apr 2007 15:23:45 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Fri, 13 Apr 2007 10:23:33 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
In-Reply-To: <461F96EE.3030400@softarmor.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
thread-index: Acd92hw+6f9MUEhLTDWgzEJCwqaNpgABOxXA
References: <4616851D.5070305@softarmor.com>
	<20070406174901.D89C45C027@laser.networkresonance.com>
	<46172B40.8090107@softarmor.com>
	<20070407151244.87A941CC3D@delta.rtfm.com>
	<4617E6B8.5070601@softarmor.com>
	<20070407192220.253931CC3D@delta.rtfm.com>
	<46194A1A.1020705@softarmor.com>
	<20070408202105.0F2725C027@laser.networkresonance.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>
	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
	<461F00B3.1090206@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
From: "Francois Audet" <audet@nortel.com>
To: "Dean Willis" <dean.willis@softarmor.com>,
	"Paul Kyzivat" <pkyzivat@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

=20
> The interceptor didn't need credentials to get into a=20
> location server that might translate bob@example.com to=20
> bob@biloxi.example.com. They didn't need credentials to look=20
> in a directory server. They just pulled the information "off=20
> the wire" in such a way that Bob will be unable to know how=20
> the interceptor got his location.
>=20
> The ONLY defenses Bob has against this sort of thing are:
> 1) use an outbound proxy with TLS, which only works in some=20
> architectures
> 2) Train everybody that calls him to use SIPS instead of SIP.

Euh, not. There is also 3)

3) Have a policiy in the proxy associated with Bob of not
   delivering anything but sips.

This whole debate is kind of ridiculous.

It all boils down to this: either the end-user (Bob) is responsible
for enforcing absolute privacy on the last hop, or (more likely), Bob's=20
proxy is responsible for doing so. Or both.

The end-user mechanism is solved by Outbound.=20

The m proxy mechanism is solved by the proxy not delivering
anything but SIPS in this case.
=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 13 11:43:05 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcNvP-0005Ft-Rv; Fri, 13 Apr 2007 11:42:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcNvO-0005Fe-9R
	for sip@ietf.org; Fri, 13 Apr 2007 11:42:58 -0400
Received: from ihemail1.lucent.com ([135.245.0.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcNvN-0003XK-UQ
	for sip@ietf.org; Fri, 13 Apr 2007 11:42:58 -0400
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l3DFgkvP012704
	for <sip@ietf.org>; Fri, 13 Apr 2007 10:42:57 -0500 (CDT)
Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by
	ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 13 Apr 2007 10:42:04 -0500
Received: from DEEXC1U01.de.lucent.com ([135.248.187.26]) by
	DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 13 Apr 2007 17:42:02 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01
Date: Fri, 13 Apr 2007 17:42:02 +0200
Message-ID: <5D1A7985295922448D5550C94DE29180FFE2E4@DEEXC1U01.de.lucent.com>
In-Reply-To: <5D1A7985295922448D5550C94DE29180F20879@DEEXC1U01.de.lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01
Thread-Index: AcdyJPB+n9eszkDUQyCVKHth2UuvYALu3oAQ
References: <5D1A7985295922448D5550C94DE29180F20879@DEEXC1U01.de.lucent.com>
From: "Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>
To: "IETF SIP List" <sip@ietf.org>
X-OriginalArrivalTime: 13 Apr 2007 15:42:02.0506 (UTC)
	FILETIME=[47DC76A0:01C77DE2]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

A reminder that you now have just one week to reply on this WGLC.

It would be nice to have some indication that people have even looked at
this reasonably short document.

Remember, if we cannot get this document out of the door, then we cannot
get ICE out of the door either.

Regards

Keith=20

> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20
> Sent: Thursday, March 29, 2007 6:09 PM
> To: IETF SIP List
> Subject: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01
>=20
> (As WG chair)
>=20
> WGLC has just commenced in the MMUSIC WG on=20
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-15.txt
>=20
> This is to announce a parallel WGLC on
> http://www.ietf.org/internet-drafts/draft-ietf-sip-ice-option-
> tag-01.txt
>=20
> The dates of the WGLC are identical to those in MMUSIC.=20
> Therefore please provide responses to the WGLC by 20th April 2007.
>=20
> Comments on the SIP document should be provided to the SIP=20
> list only, and to the editor. Please provide comments clearly=20
> indicating the page or section, the text to be changed (copy=20
> and paste!), and the proposed modification if possible.
>=20
> Regards
>=20
> Keith
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 13 11:55:35 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcO7Z-0007rA-A5; Fri, 13 Apr 2007 11:55:33 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcO7Y-0007r3-Af
	for sip@ietf.org; Fri, 13 Apr 2007 11:55:32 -0400
Received: from mx12.bbn.com ([128.33.0.81])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcO7W-0000WQ-SA
	for sip@ietf.org; Fri, 13 Apr 2007 11:55:32 -0400
Received: from po2.bbn.com ([128.33.0.56])
	by mx12.bbn.com with esmtp (Exim 4.60)
	(envelope-from <rbarnes@bbn.com>) id 1HcO7W-0005gt-4x
	for sip@ietf.org; Fri, 13 Apr 2007 11:55:30 -0400
Received: from [127.0.0.1] (ros-dhcp233-050-233.bbn.com [192.233.50.233])
	by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id l3DFtUw25684
	for <sip@ietf.org>; Fri, 13 Apr 2007 11:55:30 -0400 (EDT)
Message-ID: <461FA7F0.5000706@bbn.com>
Date: Fri, 13 Apr 2007 11:55:28 -0400
From: Richard Barnes <rbarnes@bbn.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: sip@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07
Subject: [Sip] Review of draft-ietf-sip-location-conveyance
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Draft:  draft-ietf-sip-location-conveyance-07
Reviewer: Richard Barnes
Review Date: 13 Mar 07


Security / Privacy Concerns:
------------------------------------------------------------------------
1. In the first full paragraph of Section says that if an emergency call 
using TLS fails to complete, it MUST be retried without TLS.  I don't 
think it's the place of the spec to mandate UA behavior in this case; it 
should be up to the user to define their urgency/privacy trade-off.

2. In general most of section 6 is either out of scope or true in all 
contexts (not just emergency services).  The only exceptions I note are 
the explanatory text at the beginning and the requirement that S/MIME 
MUST NOT be used in emergency cases.

3. Saying that S/MIME MUST NOT be used for emergency calls rules out 
that security mechanism when UA itself has queried a LoST server and 
contacts a PSAP directly.  Is this intentional?

4. In Section 6, in the second to the last paragraph, it basically says 
for an emergency call certain policy flags "SHOULD" be set to "yes" and 
that if those flags are set to  "no" or are not present then they may be 
ignored. A GEOPRIV "using protocol" shouldn't dictate that certain 
policy flags be ignored for "emergency calls" -- especially since 
emergency call marking is still poorly specified.

5. On the other hand, if you're going to allow certain policy flags to 
be ignored, then shouldn't setting them to "yes" be a "MUST"?  When 
would an entity legitimately set the policy flags to "no" in a situation 
where intermediate entities are allowed to ignore "no" values for these 
flags?

6. The draft's stance on multiple locations seems to take an absolutist 
stance on multiple locations.  In particular, Section 3.4.6 allows for 
multiple locations to cause a call to fail (which seems dangerous to 
me).  This seems dangerous in an emergency context.


General Comments:
------------------------------------------------------------------------
1. The draft says several times that proxies cannot insert LbyV because
they can't modify bodies.  That seems like a small reason to remove a
potentially important use case, and it seems to contradict the fact that
the ABNF in section 3.2 allows for the use of "data:" URIs.

2. More generally, the looseness of the criteria for allowable URIs
could also allow for URIs that convey LI outside of a PIDF-LO, either by
reference or by value (e.g., the "geo:" URI defined in
draft-mayrhofer-geo-uri).  Perhaps this could be restricted to the usage
"sip:", "sips:", and "pres:" defined by this document, plus any specific
LbyR protocols later defined.

3. Likewise, I don't see anything that says that the body part indicated
by a "cid:" URI or returned by a reference MUST be a PIDF-LO (although
this is said throughout).

4. Several times, the draft says that it's only describing a "push", but
there are at least two places it defines mechanisms for "pull": The
inclusion of the "geolocation" option tag in a Require header, and the
description of the usage of SIP as a dereferencing protocol.

5. The routing-query-allowed element for PIDF-LO is never defined.  This
definition would be a better place for a lot of the discussion in
section 5.3 (just in the introduction, not subordinate bullets).

6. Several times, the document assumes that content protected with
S/MIME is encrypted, when it could be signed, but otherwise readable.
In most cases where use of S/MIME for encryption causes problems, use of
S/MIME for signing only doesn't, and these cases should be noted.

7. Several sections start out by talking about how sensitive location 
information is.  This repetition should be removed.


Localized Comments and Nits:
------------------------------------------------------------------------
Section 1, paragraph starting "The Geolocation header is introduced..."
This paragraph should be broken into multiple sentences.

Section 3.1, paragraph starting "This document creates..."
Missing closing parenthesis after "[RFC2392]".

Section 3.1, paragraph starting "If a SIP message is routed..."
The requirement that header parameters SHOULD NOT be deleted seems like 
it should be a MUST NOT.  What's the case where a parameter SHOULD be 
deleted?

Section 3.2, paragraph with ABNF
Since the Geolocation header can hold multiple values, should messages 
be forbidden to have multiple Geolocation headers?

Also, this specification is very permissive about what URIs may be 
inserted.  Perhaps it should be restricted to SIP, SIPS, PRES, and CID 
for now, with a provision for adding more in the future.

Section 3.2, paragraph starting "The cid-url is defined..."
The meaning of the sentence "This URI MUST be present if location is 
by-value in a message" needs to be re-worded or deleted.  As I read it, 
it would imply that if a message has a PIDF-LO body part (for any 
reason), and a Geolocation header, than that header must have a CID URI 
pointing to that body part.

Section 3.2, paragraph starting "Use of the header..."
Use of the header in BYE is stated to be both allowed and undefined.

Section 3.2, paragraph starting "The Geolocation header MAY be..."
A Geolocation header added by a proxy could specify LbyV, e.g., if it 
contained a "data:" URI.

Section 3.3, paragraph starting "The UAC can use whatever means..."
Need an article before "SIP Intermediary".

Section 3.4, paragraph starting "To illustrate this..."
Replace "would be in here" with "is"

Section 3.4.1, paragraph starting "A Warning header ..."
You refer to data-URLs here; it would be useful to have an Informative 
reference to RFC 2397.

Section 3.4.6
Allowing this response code would seem to encourage UASs to reject calls 
with multiple locations.  This is obviously dangerous in an emergency 
setting.  Also, it seems odd to include this in a 424 message that goes 
back to the UAC, since there may not be anything he can do about it 
(e.g., if a proxy is adding conflicting location information).

Section 3.5, paragraph starting "A UAC SHOULD NOT include..."
Need to define what the semantic would be when included.  Is it 
requesting that a proxy insert a Geolocation header?

Section 5, paragraph starting "Because a person's location..."
Location in general is considered sensitive (not just people), and the 
protocol is designed to describe more than people.

Section 5, paragraph starting "A PIDF includes identity information..."
I don't really see the value of anonymizing the location in this case, 
since it's already contained in a SIP message that has identifying 
information.

Section 5, paragraph starting "Self-signed certificates..."
This paragraph is out of scope.  It's general PIDF/GEOPRIV concern.

Section 5.3, paragraph starting "Proxies that perform..."
Need some text before the colon at the end of the paragraph, e.g., 
"fields in a PIDF-LO document".  With regard to the table, would it be 
simpler just to say that the routing-query-allowed attribute supercedes 
the retransmission-allowed element?

Section 6, bullet number 2
Remove "s/he", reword.

Section 6, paragraph starting "While many jurisdictions..."
This should say that many jurisdictions "require" a user to reveal a 
location.  It seems out of scope to mandate the configurability of 
positioning mechanisms.

Section 7, paragraph starting "Transmitting location information..."
Remove the word "Transmitting".  Remove the word "tracking" from 
"eavesdropping, tracking, and alteration".  Replace "any protocol 
wishing to be considered a GEOPRIV \"using protocol\"" with "a GEOPRIV 
using protocol".  Changes "transport protocol meetings" to "transport 
protocol meets".  I would remove the quotes from RFC 3693, and just cite 
the requirement numbers.

Section 8, paragraph starting "Conveyance of physical location..."
Insert "the" before "physical location" in the first sentence.  In the 
second sentence, change "session set-up" to "SIP request" and strike 
"initiating the session or SIP MESSAGE".  Also in the second sentence, 
it should be made clear that only location-based routing is only screwed 
up by S/MIME encryption, not other protections.  In the third sentence, 
I would add "(except by proxies)" after "eavesdropping and modification".

Section 8, paragraph starting "When the UAC is the source ..."
Change the beginning of the first sentence to "When location is inserted 
by a UAC".  What, exactly is being RECOMMENDED here?  Should that clause 
be struck?

























_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 13 12:15:08 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcOQV-00046a-3r; Fri, 13 Apr 2007 12:15:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcOQS-0003zv-VC
	for sip@ietf.org; Fri, 13 Apr 2007 12:15:04 -0400
Received: from smtp.mitel.com ([216.191.234.102])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcOQQ-0004Zl-F7
	for sip@ietf.org; Fri, 13 Apr 2007 12:15:04 -0400
Received: from localhost (smtp.mitel.com [127.0.0.1])
	by smtp.mitel.com (Postfix) with ESMTP id 2ADE52007A;
	Fri, 13 Apr 2007 12:15:02 -0400 (EDT)
Received: from smtp.mitel.com ([127.0.0.1])
	by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 10119-04; Fri, 13 Apr 2007 12:15:01 -0400 (EDT)
Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58])
	by smtp.mitel.com (Postfix) with ESMTP id 591D620047;
	Fri, 13 Apr 2007 12:15:01 -0400 (EDT)
In-Reply-To: <5D1A7985295922448D5550C94DE29180FFE2E4@DEEXC1U01.de.lucent.com>
To: "IETF SIP List" <sip@ietf.org>,
	"Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>
Subject: Nits RE: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005
Message-ID: <OFD34CFF38.5FCF0123-ON852572BC.0058409B-852572BC.005942B1@mitel.com>
From: peter_blatherwick@mitel.com
Date: Fri, 13 Apr 2007 12:14:58 -0400
X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13,
	2003) at 04/13/2007 12:14:59 PM,
	Serialize complete at 04/13/2007 12:14:59 PM
X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0751274193=="
Errors-To: sip-bounces@ietf.org

This is a multipart message in MIME format.
--===============0751274193==
Content-Type: multipart/alternative;
	boundary="=_alternative 005942B0852572BC_="

This is a multipart message in MIME format.
--=_alternative 005942B0852572BC_=
Content-Type: text/plain; charset="US-ASCII"

Read it, and looks good except for a few truly minor nits. 

- sec 4, 1st sentence, for consistency seems the tag should be in quotes, 
ie  "The "sip.ice" media feature tag ..." 

- sec 6, 2nd paragraph, last sentence should read "... using the SIPS 
mechanism. "  (Missing the S in SIPS)

- sec 7.2, for consistency with sec 7.1 should the tag name be give simply 
by "Name:  sip.ice"  (or sec 7.1 spell it all out as in sec 7.2)

-- Peter Blatherwick






"Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>
13.04.07 11:42
 
        To:     "IETF SIP List" <sip@ietf.org>
        cc: 
        Subject:        RE: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01


A reminder that you now have just one week to reply on this WGLC.

It would be nice to have some indication that people have even looked at
this reasonably short document.

Remember, if we cannot get this document out of the door, then we cannot
get ICE out of the door either.

Regards

Keith 

> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com] 
> Sent: Thursday, March 29, 2007 6:09 PM
> To: IETF SIP List
> Subject: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01
> 
> (As WG chair)
> 
> WGLC has just commenced in the MMUSIC WG on 
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-15.txt
> 
> This is to announce a parallel WGLC on
> http://www.ietf.org/internet-drafts/draft-ietf-sip-ice-option-
> tag-01.txt
> 
> The dates of the WGLC are identical to those in MMUSIC. 
> Therefore please provide responses to the WGLC by 20th April 2007.
> 
> Comments on the SIP document should be provided to the SIP 
> list only, and to the editor. Please provide comments clearly 
> indicating the page or section, the text to be changed (copy 
> and paste!), and the proposed modification if possible.
> 
> Regards
> 
> Keith
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use 
> sip-implementors@cs.columbia.edu for questions on current sip 
> Use sipping@ietf.org for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


--=_alternative 005942B0852572BC_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">Read it, and looks good except for a
few truly minor nits. &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">- sec 4, 1st sentence, for consistency
seems the tag should be in quotes, ie &nbsp;&quot;</font><tt><font size=3>The
&quot;sip.ice&quot; media feature tag ...&quot; </font></tt>
<br>
<br><font size=2 face="sans-serif">- sec 6, 2nd paragraph, last sentence
should read &quot;... </font><tt><font size=3>using the SIP<b>S</b> mechanism</font></tt><font size=2 face="sans-serif">.
&quot; &nbsp;(Missing the S in SIPS)</font>
<br>
<br><font size=2 face="sans-serif">- sec 7.2, for consistency with sec
7.1 should the tag name be give simply by &quot;</font><tt><font size=3>Name:
&nbsp;sip.ice&quot;</font></tt><font size=2 face="sans-serif"> &nbsp;(or
sec 7.1 spell it all out as in sec 7.2)</font>
<br>
<br><font size=2 face="sans-serif">-- Peter Blatherwick</font>
<br>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>&quot;Drage, Keith \(Keith\)&quot;
&lt;drage@alcatel-lucent.com&gt;</b></font>
<p><font size=1 face="sans-serif">13.04.07 11:42</font>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To:
&nbsp; &nbsp; &nbsp; &nbsp;&quot;IETF SIP List&quot; &lt;sip@ietf.org&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc:
&nbsp; &nbsp; &nbsp; &nbsp;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject:
&nbsp; &nbsp; &nbsp; &nbsp;RE: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01</font></table>
<br>
<br>
<br><tt><font size=2>A reminder that you now have just one week to reply
on this WGLC.<br>
<br>
It would be nice to have some indication that people have even looked at<br>
this reasonably short document.<br>
<br>
Remember, if we cannot get this document out of the door, then we cannot<br>
get ICE out of the door either.<br>
<br>
Regards<br>
<br>
Keith <br>
<br>
&gt; -----Original Message-----<br>
&gt; From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com] <br>
&gt; Sent: Thursday, March 29, 2007 6:09 PM<br>
&gt; To: IETF SIP List<br>
&gt; Subject: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01<br>
&gt; <br>
&gt; (As WG chair)<br>
&gt; <br>
&gt; WGLC has just commenced in the MMUSIC WG on <br>
&gt; http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-15.txt<br>
&gt; <br>
&gt; This is to announce a parallel WGLC on<br>
&gt; http://www.ietf.org/internet-drafts/draft-ietf-sip-ice-option-<br>
&gt; tag-01.txt<br>
&gt; <br>
&gt; The dates of the WGLC are identical to those in MMUSIC. <br>
&gt; Therefore please provide responses to the WGLC by 20th April 2007.<br>
&gt; <br>
&gt; Comments on the SIP document should be provided to the SIP <br>
&gt; list only, and to the editor. Please provide comments clearly <br>
&gt; indicating the page or section, the text to be changed (copy <br>
&gt; and paste!), and the proposed modification if possible.<br>
&gt; <br>
&gt; Regards<br>
&gt; <br>
&gt; Keith<br>
&gt; <br>
&gt; _______________________________________________<br>
&gt; Sip mailing list &nbsp;https://www1.ietf.org/mailman/listinfo/sip<br>
&gt; This list is for NEW development of the core SIP Protocol Use <br>
&gt; sip-implementors@cs.columbia.edu for questions on current sip <br>
&gt; Use sipping@ietf.org for new developments on the application of sip<br>
&gt; <br>
<br>
_______________________________________________<br>
Sip mailing list &nbsp;https://www1.ietf.org/mailman/listinfo/sip<br>
This list is for NEW development of the core SIP Protocol<br>
Use sip-implementors@cs.columbia.edu for questions on current sip<br>
Use sipping@ietf.org for new developments on the application of sip<br>
</font></tt>
<br>
--=_alternative 005942B0852572BC_=--


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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============0751274193==--




From sip-bounces@ietf.org Fri Apr 13 12:24:19 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcOXB-0008CH-FO; Fri, 13 Apr 2007 12:22:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcOX9-00088Q-UC
	for sip@ietf.org; Fri, 13 Apr 2007 12:21:59 -0400
Received: from smtp1.versatel.nl ([62.58.50.88])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcOVk-00074f-Ng
	for sip@ietf.org; Fri, 13 Apr 2007 12:20:33 -0400
Received: (qmail 11126 invoked by uid 0); 13 Apr 2007 16:21:45 -0000
Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER)
	([87.212.11.198]) (envelope-sender <jbemmel@zonnet.nl>)
	by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP
	for < >; 13 Apr 2007 16:21:45 -0000
Message-ID: <000801c77de7$83af9c70$0601a8c0@BEMBUSTER>
From: "Jeroen van Bemmel" <jbemmel@zonnet.nl>
To: "Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>,
	"IETF SIP List" <sip@ietf.org>
References: <5D1A7985295922448D5550C94DE29180F20879@DEEXC1U01.de.lucent.com>
	<5D1A7985295922448D5550C94DE29180FFE2E4@DEEXC1U01.de.lucent.com>
Subject: Re: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01
Date: Fri, 13 Apr 2007 18:19:28 +0200
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

One minor comment on section 5 ("SHOULD NOT be used in conjunction with the 
Supported header field"): in case an OPTIONS request is received, surely the 
UAS is expected to respond with Supported: ice in its response? If so, that 
would be worth mentioning explicitly as an exception to the "SHOULD NOT"

Regards,
Jeroen

Drage, Keith (Keith) wrote:
> A reminder that you now have just one week to reply on this WGLC.
>
> It would be nice to have some indication that people have even looked
> at this reasonably short document.
>
> Remember, if we cannot get this document out of the door, then we
> cannot get ICE out of the door either.
>
> Regards
>
> Keith
>
>> -----Original Message-----
>> From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com]
>> Sent: Thursday, March 29, 2007 6:09 PM
>> To: IETF SIP List
>> Subject: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01
>>
>> (As WG chair)
>>
>> WGLC has just commenced in the MMUSIC WG on
>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-15.txt
>>
>> This is to announce a parallel WGLC on
>> http://www.ietf.org/internet-drafts/draft-ietf-sip-ice-option-
>> tag-01.txt
>>
>> The dates of the WGLC are identical to those in MMUSIC.
>> Therefore please provide responses to the WGLC by 20th April 2007.
>>
>> Comments on the SIP document should be provided to the SIP
>> list only, and to the editor. Please provide comments clearly
>> indicating the page or section, the text to be changed (copy
>> and paste!), and the proposed modification if possible.
>>
>> Regards
>>
>> Keith
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol Use
>> sip-implementors@cs.columbia.edu for questions on current sip
>> Use sipping@ietf.org for new developments on the application of sip
>>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 13 12:38:33 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcOn9-0004Cz-S8; Fri, 13 Apr 2007 12:38:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcOn8-0004B6-Ac
	for sip@ietf.org; Fri, 13 Apr 2007 12:38:30 -0400
Received: from zrtps0kp.nortel.com ([47.140.192.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcOn7-0006aU-2b
	for sip@ietf.org; Fri, 13 Apr 2007 12:38:30 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3DGcPa20779; Fri, 13 Apr 2007 16:38:25 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
Date: Fri, 13 Apr 2007 11:38:21 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF10051FF8@zrc2hxm0.corp.nortel.com>
In-Reply-To: <461F888A.2080609@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being delivered to a UA
thread-index: Acd90XSNb1UzQ61sTVWFlq4/wQetewADp8IA
References: <4616851D.5070305@softarmor.com> <46172B40.8090107@softarmor.com>
	<20070407151244.87A941CC3D@delta.rtfm.com>
	<4617E6B8.5070601@softarmor.com>
	<20070407192220.253931CC3D@delta.rtfm.com>
	<46194A1A.1020705@softarmor.com>
	<20070408202105.0F2725C027@laser.networkresonance.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>
	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
	<461F00B3.1090206@softarmor.com>
	<66cd252f0704130240x707ff7f3g996c002cfb5e932@mail.gmail.com>
	<461F888A.2080609@cisco.com>
From: "Francois Audet" <audet@nortel.com>
To: "Paul Kyzivat" <pkyzivat@cisco.com>,
	"Hisham Khartabil" <hisham.khartabil@gmail.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: sip@ietf.org, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Exactly.

First three versions of the individual draft worked with multiple
contacts:
https://svn.resiprocate.org/rep/ietf-drafts/audet/draft-audet-sip-sips-g
uidelines-00.txt=20
https://svn.resiprocate.org/rep/ietf-drafts/audet/draft-audet-sip-sips-g
uidelines-01.txt
https://svn.resiprocate.org/rep/ietf-drafts/audet/draft-audet-sip-sips-g
uidelines-02.txt

Starting from -03 (individual), it shifted to the current model.
https://svn.resiprocate.org/rep/ietf-drafts/audet/draft-audet-sip-sips-g
uidelines-03.txt

And again, with TCP and UDP today, we do NOT use explicit registration.

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20
> Sent: Friday, April 13, 2007 06:42
> To: Hisham Khartabil
> Cc: Dean Willis; sip@ietf.org; Audet, Francois (SC100:3055)
> Subject: Re: [Sip] SIPS question: How to prevent plaintext=20
> requests from being delivered to a UA
>=20
> Hisham,
>=20
> I don't understand how you expect the registering of two=20
> schemes to work. Suppose the phone needs to use outbound. Are=20
> you suggesting that it needs to establish one outbound=20
> connection for sips and a different one for sip? Why would=20
> anyone want to incur that extra cost compared to simply=20
> receiving both sip and sips calls over the same connection?

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From dmeozzir@point.ne.jp Sat Apr 14 00:55:08 2007
Return-path: <dmeozzir@point.ne.jp>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcaI0-0003Oc-3t; Sat, 14 Apr 2007 00:55:08 -0400
Received: from ph119.opt2.point.ne.jp ([222.225.224.119] helo=point.ne.jp)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1HcaDf-00066w-2C; Sat, 14 Apr 2007 00:50:42 -0400
Message-ID: <d7c301c77e9a$d52fee20$ea865872@dmeozzir>
Reply-To: "Andrea" <dmeozzir@point.ne.jp>
From: "Andrea" <dmeozzir@point.ne.jp>
To: "kimberli long" <aaa-archive@lists.ietf.org>
Cc: "edgardo" <bridge-archive@lists.ietf.org>,
	"kareem chavez" <mailman-bounces@lists.ietf.org>,
	"lien young" <sip-archive@lists.ietf.org>,
	"booker" <dnsext-archive@lists.ietf.org>,
	"davina murphy" <mailman@lists.ietf.org>,
	"dorothea boyd" <ospf-archive@lists.ietf.org>,
	"maritza rodriguez" <kink-archive@lists.ietf.org>,
	"oscar moore" <foo@lists.ietf.org>,
	"masako cooper" <l1vpn-request@lists.ietf.org>
Subject: Let's go and check it out
Date: Sat, 14 Apr 2007 13:43:07 +0900
MIME-Version: 1.0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_BC8_07FA_46103418.0418C329"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 40161b1d86420e0807d771943d981d25

This is a multi-part message in MIME format.

------=_NextPart_BC8_07FA_46103418.0418C329
Content-Type: multipart/alternative;
	boundary="----=_NextPart_1A1_3CC1_4AFE1C3C.06C99CC3"

------=_NextPart_1A1_3CC1_4AFE1C3C.06C99CC3
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable





soft kept Ah, reverend condition sir, way cried Caderousse, clasping hisA=
h, curl telephone said fish learned Caderousse, No. 30. fish I? Silence, =
purveyor step fondly of linen gossip, do not spread thaWhat did regret th=
oughtful found pinch it taste like?
Excuse me, sir, net said beside Franz, dress since seat M. Noirtier sSo s=
erious, that I realise deep come net to beg you interfere to render me a 
Yes, a swam sat fine house osteal standing alone, amusement between a cou=
rt You receipt mean to grate tame say shock you have been freed from conf=
inem stolen Possibly; but it is melodic not the exterior overflow quickly=
 I care for, town deliver It had dived smoke a bitter taste.
paste rubbery loudly driven Nothing is ever so firmly impressed on the mi=
nd aPray, sent blew sir, said depend worm Villefort with marked uneasines=
s What is it? Forgive enchanting me, tax hurry sir, said lent Franz in a =
resolute tone.
The doctor poured some rub hurt drops dam of question the lemonade into s=
haven Yes, that blindly wait learn is true, reverend sir. repeat repair H=
ave rat you to ever seen the Tuileries? day crush impulse Who except was =
your liberator? tray Ah, pardieu, friendly tomorrow said whistle Beaucham=
p, with the paper in
instrument overcame NOIRTIER was prepared to chess shrink receive them, d=
ressed inmuddle request Speak, speak, signora, trot stride said Albert, I=
 am listen cooing Haide find answered his deep remark announce with a mel=
ancholy smile impossible meal terrible To head be my second.  stocking ad=
d That is sin a serious matter, late and we will not discuss
support Ah, I understand, said Beauchamp, madly discussion dare on our fr=
iendAre you degree onto shoe interested end in the sugar question? askedI=
t care is limit no doubt the same, said he. tax organization Did you drin=
k No.
Yes. On filthy my held insurance account? burst said the young man; oh, n=
o, inde An Englishman. Listen, said Monte hurt briefly cautious Cristo; I=
 horse have had little to tell tongue No, roll replied Beauchamp, I regul=
arly have not considered th ticket I beg stain you to do shod gestic so, =
replied Albert. Well, I was
company fail episcopal Listen, whispered book Villefort to Valentine, who=
 covictoriously I saw then power that we side were descending rate a larg=
e staircNo, out dug said the count, I was journey dig making a suit. Noir=
tier answered birth only warmly withheld by voiceless a look which made V=
illef Behind stitch the women stupid came subtract a guard of sin twenty =
men armed
Well, lent nod train scale it surpasses that. And remind did you prose al=
so discover blastous gleaming a bitter taste?  Yes.
map mistook What chop rat was his name? What is it? And do you tenderly s=
ay this ski powder wedding street is at hand? damaged It belong must elat=
ed be worth one's cool while to stoop, Andrea, wh The sank article divisi=
on naughty work relative to Morcerf. 'Quick!' said a voice at greet measu=
re the withhold end broken of the gallery.
------=_NextPart_1A1_3CC1_4AFE1C3C.06C99CC3
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"=
>
<META content=3D"MSHTML 5.50.4522.1200" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><FONT face=3DArial size=3D1>
<DIV>
<p><IMG alt=3D"" hspace=3D0 src=3D"cid:6e20e01c77e9a8d57a3d90b4a4573b@dme=
ozzir" align=3Dbaseline border=3D0></p>
<BR>
<DIV><FONT face=3DArial size=3D1>soft kept Ah, reverend condition sir, wa=
y cried Caderousse, clasping hisAh, curl telephone said fish learned Cade=
rousse, No. 30. fish I? Silence, purveyor step fondly of linen gossip, do=
 not spread thaWhat did regret thoughtful found pinch it taste like?</FON=
T></DIV>
<DIV><FONT face=3DArial size=3D1>Excuse me, sir, net said beside Franz, d=
ress since seat M. Noirtier sSo serious, that I realise deep come net to =
beg you interfere to render me a </FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Yes, a swam sat fine house osteal standi=
ng alone, amusement between a court You receipt mean to grate tame say sh=
ock you have been freed from confinem stolen Possibly; but it is melodic =
not the exterior overflow quickly I care for, town deliver It had dived s=
moke a bitter taste.</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>paste rubbery loudly driven Nothing is e=
ver so firmly impressed on the mind aPray, sent blew sir, said depend wor=
m Villefort with marked uneasiness What is it? Forgive enchanting me, tax=
 hurry sir, said lent Franz in a resolute tone.</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>The doctor poured some rub hurt drops da=
m of question the lemonade into shaven Yes, that blindly wait learn is tr=
ue, reverend sir. repeat repair Have rat you to ever seen the Tuileries? =
day crush impulse Who except was your liberator? tray Ah, pardieu, friend=
ly tomorrow said whistle Beauchamp, with the paper in</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>instrument overcame NOIRTIER was prepare=
d to chess shrink receive them, dressed inmuddle request Speak, speak, si=
gnora, trot stride said Albert, I am listen cooing Haide find answered hi=
s deep remark announce with a melancholy smile impossible meal terrible T=
o head be my second.  stocking add That is sin a serious matter, late and=
 we will not discuss</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>support Ah, I understand, said Beauchamp=
, madly discussion dare on our friendAre you degree onto shoe interested =
end in the sugar question? askedIt care is limit no doubt the same, said =
he. tax organization Did you drink No.</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Yes. On filthy my held insurance account=
? burst said the young man; oh, no, inde An Englishman. Listen, said Mont=
e hurt briefly cautious Cristo; I horse have had little to tell tongue No=
, roll replied Beauchamp, I regularly have not considered th ticket I beg=
 stain you to do shod gestic so, replied Albert. Well, I was</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>company fail episcopal Listen, whispered=
 book Villefort to Valentine, who covictoriously I saw then power that we=
 side were descending rate a large staircNo, out dug said the count, I wa=
s journey dig making a suit. Noirtier answered birth only warmly withheld=
 by voiceless a look which made Villef Behind stitch the women stupid cam=
e subtract a guard of sin twenty men armed</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Well, lent nod train scale it surpasses =
that. And remind did you prose also discover blastous gleaming a bitter t=
aste?  Yes.</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>map mistook What chop rat was his name? =
What is it? And do you tenderly say this ski powder wedding street is at =
hand? damaged It belong must elated be worth one's cool while to stoop, A=
ndrea, wh The sank article division naughty work relative to Morcerf. 'Qu=
ick!' said a voice at greet measure the withhold end broken of the galler=
y.</FONT></DIV>
</DIV></FONT></BODY></HTML>

------=_NextPart_1A1_3CC1_4AFE1C3C.06C99CC3--

------=_NextPart_BC8_07FA_46103418.0418C329
Content-Type: image/gif;
	name="eocevenoenes.gif"
Content-Transfer-Encoding: base64
Content-ID: <6e20e01c77e9a8d57a3d90b4a4573b@dmeozzir>

R0lGODdhbgErAYQAAP///wBm/wAAAP8AAOHe2P+vr7/G3fbevP9mZv8/P52u4HWN1Gd0n7y7rLWl
koaPp/PNisaLUqN2PJxaKVpSWumqUOSVKOVRCTorOwAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA
bgErAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt
er/gsHhMLpvP5gB6zW6HA/C42hR3y+slvJsln+kBf3tVd4GAcF9zKoSHJIWCjYsxf46PUHh9ZJSQ
iZOMlXmemiiin1J6gZ2FmKCnhpyhkSKEK6eerquys7lqtpGqupu9sIl0tq7BqMJzi8S7xqU5qZvI
yql307sjzMvXKdLO3ber4eLM1Na1r83Y2tXjyu2x5c/QNt/Z+Mf66fH9+Zj8aA0Llq9YvGZ9EtLz
p68hI02/iAFUx24ixYL17MFjiAsjQ4cPN4JcV0zeSFYB/rFdehZLVEiSHu8N5DhzG8yMkoZJdHex
pMqZ/162MBlUXbiI+NBZVMSNKUJjtT6mXGkO542UHm8VLUhVas2FrJz6WxpT6EhuPc+CbYgxKleg
Xa3ySLezZ1yLaMfW4QV3bVaads3+zAsYsNGbhSumndoXsVw+Vb2SMxl5W2JxYr011oV0H0+lUEnN
W+eWLeO6HR/nBPYRcx5DJ8g5g31Zq2bEWBUSHtx2b2hHog+SLC0TKDjVyJPTCK68ufM3qZ9Lnw4m
OvXr2LNr3869u/fv4MOLH0++vPnz6NOrX8++vfv38OPLn0+/vv37+PPr3+9FgH//SQgggoAnEEiE
gQc6/jHAACcwOIKDLzgIoRALVkjCgjZgKEKFHF4I4YRSIIjgDSMWuEKJJqCohYpGaOjhgyCyIGER
HLroogwWblijjR/G+MSILMYQ5IAnsjCkFUdSyKCFO+4IAI8XbvjkhzDaWCWVOr44JYxXcpmjjlBy
6aWPYI5pZg5AjvCfiQAO2GabJawJAIEGyllngQDSOeecIsJJgoCAongnn4PuuaeIfKppqJ2KEkmo
mnAC6mGTlDq55YNSaphjh1NKuKmmE4IqpqVNYhpmlpOmUCOYoHKKQ5qGxgopkYOWeKeesUoqa5yO
Btpro38mumuuxBbrp7B04noosLou2+uIn156KZM3/mL6ZJbUYouhqNlO+mW104q6JY+rlvCludum
2+OS4NIAa6HMGpsir4vyGmShtQKr6JC65tvvvL86Wq+kygpcMKrj9limtNYqvGS417KLbcQglotw
p56eSe65VaIA5Y2nkkgvvAbLS2+jB8uJAr4oP2qvvvuWbHKwActLMKTJMorumRBfLOW1E0s8LsVB
M2w0wukizW65rZrAsZgJa3m0uyPDTGy+Jwf8bgos18ym1c5iXe/JyvrrbLC2Ou2wwp22be7PZZ5L
bajqqt1gxj0nzDTbPKfabdztzoCozDSfffDVNf+7Ms1vEh6zwGS37LXMXReL+OTSqrt0qdPCDTjd
/kv7LW67rUbr86nf8l063lcGLsN/x6pceM6zxtl4rrePXfvAfQpqedayww65m5H+6Se8KidvN6qf
/q2p55nTDXX0zPtIbtSn8+026utOry1y9w6/Q5JtuM5eyFaFP6wO5LNh/nqcT1d8D8fW8z78rvKn
//789+///wAMoAAHSMACGvCACEygAhfIwAY68IEQdI9j+jfB7FTQCRe8ik02yMEOevCDIAyhCEdI
whKa8IQoTKEKTViEDPLHhQ6E4XIQKEMG1lAGN7xPDhO4wxf0kD4/NGAQ+ZACAoiAAEhEon6GSEAm
KkIFSYyiEkXmHSeepwA9sOIoUmCALiKxi2A0/oARjZSn+nHNOTeR4hiP+Lov1ClSZqTBARCQgAQg
QAQIWNAdSzBHOu6xAAigYyNaeAICKOCQiEwkIg3QApIJAos7IIYaJxnFlZWxfTBYU6Bgh0nblcyR
NEgAAO54R0AC4AADgOSDIJlKU45SlLIgZAkMsIBa2vKWuFSAkVD2xjdx0k6yWxzOhqmDOdZxj3kc
wB5LEMgEQBKQgdQGCShJSUYKc32vmhWuOvm4W8VMeMbD5obmOAJV2tFcWEQlAM4JgAJASIuxMYEC
GEBPesKBAQsIQD3xuYA1nnF+3vxVs/jFMlDOQJSkbOcdUalKPKaTQQeAJTslSU0pNsCaJnoW/vFy
9suNFk5W3MxoQA+luEUFKY+wRGcJ3EnHA6zzj++UJQnmqU8G3NOeNaVnP3c5OOLNzKf/jJc3walN
FQyAnCIw5zLHuaECuDKPsRwBAcRYUQI0wAH+nFfxRqqngRrPd9m8XNgINySUurScKSWBOxPg0jy6
NAExJcI6CPCAnO7zrgzAKk8Z11XluUl8ABOrr8r21xSgtEENVacI7MhOd0ZVql6c5FUbkFWtzi5P
kiOmJz9aA8IGlLCAZSZcRxDRE5gSrm8dwDGlKddC0pQZ9NRrI6tGq8AadHaPG6vlyqrasyY1re2E
EGNh+lipTpWqX3SAA8S41331dX7I+mhP/m3g2W5S7kh3TCUeT6DYJy2zu4CQqQkMgFM5MOABGJ3t
MH/JSZd1VAUFte5uWUBHCJV2pcL1Y1IdBJOpNuC/ymWuC9I00nhBDrrizKRmdVYwzBp2lOvcroRd
6tjFQhKVvg1va03wRQM8AKexvWhlw5pg9Qp2bLXC7pMguVTSCheavy1uCfwb4BGfEWfsFR4wibrJ
r1YhSMoMJBbhWiEsQvWVMB4lAjKs4SHMNYxddMADHrDcMNq4s8EUnI+Bus1wnhTCsFzmHs+q3WsV
IMx7JElVeXDbMRA1Ba5MgW8PUAAm00G8xq1qEtNn1EAiYMgcMrKDzgxISDrzzKydJhSn/viqLMvF
zlfBM3bejII4oyDDdSYBnQcZQSJumD2QrgE8/zfq1xyw1BSUtABRzT9Wy3iArtZfrGNtHlrvZ9Yr
zLWud83rXvs6haP5tbA/qOoA2nqJxZbqAZbNaB0WcZINnDUUr6pcBzQAAld+j5rXrEBpowDA1f7v
f7PdnrlW1Ys8LPZkqW1tcJO7s9NpxnGhTG90n1rVEIiABCSgXABHIALVHvAl8YSGhuJAkl1UQBgV
vnAwWrLHt1a1AyJA5WpT3NrVfrfjsiYGY7IzmS3GIx2f6edEA8CQCljAIVWuyEOC0cZtpo7BI/1p
0v5brw3QN1YJoNwINGDAzGKULz3q/uAiaZYHCIWwKRnKzIeeUqJpJoEBWk71RF65WYQabC+1/gmP
I1OPJ2gmyaP56h/M9d8+PznFjZjzm7/AVyYr6GBPVLkdHHWZSjUXmZ369eI2oOqAz3ZPk1VbgQYI
CUkv5ULLPII/nxKiUC+7D86OdiNO9ZRo5/fbd8VgoWIObQamVfCwjoLDOi2x+W0sf6XO8pXj0pYp
V4DgU5S7XhbeCEnaZJ9K/CCkloCdvW/qU1df8yNm3gEk0Pe/J4B8oL9Ra57X3Y1/5+BtJsmsagVu
hV+q+uJ6+PUL4Ccu02vZwnoWtD9WHOFbYHqVungEw92v5LPIYX3vm99IdMD9JUCB/p9v3sCgVX2h
hVsHBn0DKFr2BVzBBX/6tYBNdnINAH6vd15Xl1ldZTi3NwVd9jsrgH1ohV8M2H0PGAQk4QATcIIn
KAEoOAEqKAEapy85xmO6R1L8EnootnEPVmYh93jwl2SINoI89wASGH4UyDUDF4NZx17CooEGyHsk
UF+kpYDbF38O6G0zpoIrmIUU0HxbUHcbuH4qkFBh1ngisHdS8oNkN1cN8GF4FVsv+AlfWFgukF0s
xl0vRnY/aIUl0ABYmIUTQAEP8IZO0Du09XxHEmSOR2QLImi/VWgW9oMjeHJWNWV39QAKJ4iPsIGJ
Qj5iKGEQdkpNdYZoNn9zUUhX/tWHJ0gBgChbGZEklsZdapVhm2ZykphEBvB3CnBRyIWJqkE+iAho
RTZKg+ZMjrdOTpVSephnVzVlzGhtewaHjnZppZhnevaM10FpK/CKJoBpsthQyViGy3YAahSOzRYf
FFWN1rgeoTZDxTdjz1Yfx5Yf37hqneZpTmZBURCP+IFrw9aP/viPABmQAjmQG5RspFaPtGCQ/qOP
ztaO9IiQ3qCQqQaRW+SQxkaRFXmP3HUAENCR4RhxG/mREDSPHVkBHXmSHrmOzjFz9rCNEFABMAmT
KUldu7Qe33iSMVmSMjmTNGl0XOB1eAR2JiB2SVVyMvaSFpCUSpmUO6mSPkVQ/gJHMO9FXbY3BCwp
anhGAC8ZASbZlTH5lR4ZlQkWR68DRyHFAomnUI9ncI6nTvc1UZpWAUs5l0spk6H2fD4JX0UlfVqG
gUAAlMKoTNvYTH/UTLQIBM2wlV75lTHJlTH5bng5fT3plzxwd+XEgHonfH33gBBAl55ZlxAQWKLn
UaMJVAUINjSJPFnnZS+QlkvHeKG4Yk8FS3poVf/2lY6JdhXgmLvpf5JJUqS5ftHYXCC1mnsZhqqF
WJqWesTVZAcglxYQARdwAUkZAdVpnUv5b1mlIl5lgIQommhCfeonhzLie3l3IU4ngrWZcxKAdu75
nrv5b755TS+TOHy5ecgz/p5LiJxslX0guFgNWGGJ8Jz/Np0FaqDvKZ0TEAHkx50LplGWxHHsA4NN
2D6GeXr41VIvJX+RaHZ7+G/3l6DviX95eVnnB2/UV6FzOFplKIXMyaGJQAAVMJ0XEAELiqAHioIk
yll9RTnhRKGoSTUpeoMHOJS95Z8msFZtdVTrRHwaOQIGIKIJKgFURlk12TK3gy/cBFbeGaTMtGKe
uJw9iIe0OU3SSaNoOp06SmUCRjYX6KPSh2BnmVFD+oWdBIUtalp3hFpNulodOnkzxp77t39TRllv
iJfd+VlCQoBdup+lB2aeOGaxySBoGHVm6odrulzlaDu+pIQdFUwQZ5pU/tmphXiccwimn8hHH/Jd
cfWkUiVlg0qlzig4O4aEUxmVpMo4BXiIfgaMiyiMjViMh4aMHKZ/WCirmgoeFgqpqSqpU3hhTEqK
keSS7NZvKblsfMYC2shHsahp3shhSCRuhrqp1zicDdKrTRqMRzZyZBdIGZaMBBCO8jqv88qL/UGW
sDitmiaSfCSv7rGtmkZamRaRxcds9Hqw/AofDJkdTikJkoawENuw57Gw8CiRrYaR8WSRAESxQGSx
+8Ox8zGPF4mxpuZkBHmyKJuyKruyK+uxskayJSsEIMsdFZSO3eayL9QClWRDOAuSi7azN6uxB/mz
UhSeMjeNrqoeV8mO/igwVZQEdGKArz0AmO4kmCsFV/0ZXEIJr+hos0Ewp9/JA4AJcmE3ckVJdn96
creoRvaml9OFBYcDBGkZYe7EZM7UpEnlVKpUm11btCZmhCVKdzaYA665eGzpdG9pqeAqYlK0tsT5
qXCnY3B3BOHzZkW3ApbpNEz2TA7iTO8qU30LbUVyJHNafilquaSnuXiHmReyd8MneRXluKNLgCUl
nEhwL/optY2XnE0HZ6IUUUKZtkgbumr0uHMHnOY3dOojnkQqte2HnmIKoOpZSOloi1ZKd4OXgTrj
hBOql0TKvcKYtYEZauIbXJDkbcQbRV1EnJsolZ/ES+LkhSragUf6/oFq9aJVSL3UJLvT1zX9ooml
Sz/zu6IgUkdhN3NpKEvpa4vkhyeD86ZXA05xS1a6qjvXx6JPl6T4K6D6W03X27+h579eymY1aacw
QIdPKIUsWYzou8BW1cCRA33xRVt0qprNe32ouoPdRYx/VKbg6l/iZr2CN3BJWDY55jJCgI0VbIin
uqenZGgXlrd5O4vEumFOS7xXRW4iTJmJOoBhW6Gp+6VO3KxlOKntNIodGq7jqr4fvB2+iK4s9XGU
uiostWSH6aFHJK56vMfiJmUw7GOahFlK+JSkqruT6THoqojadWSEJqzHeJhJtMaWZ1VtTB1KDGdL
5VTcWmlMtp7V/vbJoPzJhloJl7xSOxiw5dSNnGZctyjJ4Tqr7iGxPqRqXYsdsuwC8kbJrhzEQZu0
sAaurWxlfntvQruQHVxR6VbME0m0R0SucjGzBOvLDwkDzjzNMsuy2JzN2rzN3NxBCvm0DQmz0qoD
aYTM9gHNClts1XjO4nzHgHrMk9Sm8oHO2kbL1fjH5dbO4xwNP6xnlbySSJuJyPGNX6SL4ra2hsqK
6bd1onoDYxu8Q7lU3aVF7eWo4FsPS+sHklbQ4yauBlBly3UFYsOBNVC4a2laVrtYrfpsxeu993ml
AcJRDI0DVAvRZUiYIudW+3xwHNbKfCyu6PV2lzsEpDdUoBrG/r23ugBqWsDnVCsNijO2iy/s0j1K
yMgSyBzVvrij1Q0dp5x1A3MrSnXrfq0UZj7sy/NWb2AkZS8YmUmc1RFsweRppAqIqk+4oe3k1CYH
aZQU0tdku7cSh4an1Sl2ew46uDNoqqrbIEymXeq0roorsz2t1mC0hoEItc9CeJdbyvSJgQA8wh4Y
Yyv1Vn/kgA+IsFJGiaqoigxghNCle12chKcZgM7laNMlwbl7Urz7hDMXx2d1TMs0jz7904Uq1NlL
2DhYol712UX6Sgm4jYaWUKZNDCiJkhKAAdid3dhNATBnW5wnOWkD3hbIewaVu6Bdv+OrweILV8FN
yz/9Xx92/tlCQttxashcdTkBqGI6yNR1tIh11N9nzZHV3ZHXvdqrjQHc3dknhjUjzdz3LVJB9b3Y
hcGLpX17yqRsxVI7TXPF2m59HN+CiCgMDqHkkzxm2YSbGIbMKmZlTALAN90ksJPWbeAG/gAPB8hH
mOMQt2M0WMSPkmWaaH7NO9dhZ9evFL3ehYdOKtko4GHMqNoMgM8RatiNetECrCqJHGjAWk6qdWF5
FNk8x5swyX80Doj22gWvzWWJg9Tb5cRUHMXPOr0aO1Wp3YxtO1smTjs9dqsHYq5FuQK3fNq63Meh
bFVn3ot9JmTB1YDrysNreWZnJbJsK9UMG9BNS03dwdl//l5OBjdnAyvF7kx/8AzOIauzpK6Olo6Y
l65nFavPIluLT3vo4EHPEtSzDjux+iy8+ipEuc6P3fzrvBZswD5swj7skcHkvO7qEjmvyKbsGiuv
KMls4cxd0GkBFRDoy4zs/TrgKCnrs54CSMmYoblA87hs3F7d3r4HGa3RJyCXjAmT1o7tOeuQAn7u
JzmfPhDASACYZegjhGbKe9vu1l7tc1kB6X4d637rvlzv9l6SGufn+X7iPjC3Ko3SDYW2r4YAnzmX
437ldLoHD53SpIXTCiVIG96SJfCSOWnvFYDvv6lgbUTlPZC5nE4mjIfxr0bwG28BMCfx860EVSm3
EKZ4/icNvbKJTGet7aek8u8Olp3JhYELTIQ9yJrenaJ3PGy+u2mltzbPuWe2VM0wR2lKo0lJnUnZ
8bS3OzFPuejnAzR/nqvEg3KetBzZ9E1vAVDv0j4qNjdTpFaf4ih2ffWLRdvnfnnk1FVMWmO/+NOJ
9puFdVg9uYIM1wLc9on9Vxa620bP5Ro690r/nHb/7gCH2RsFwW2PxBA+2/bJfqPVnBiK19uXmIy/
+HkPelbf99Yn8z9g+bl9wuh9xijdnzrNovAa+oxpAZr3t8MS21sdvzYo2NxLh/+NtcoJ+099ALM/
9rX/TbijSRVswYYspDbM3C+ApxmcpBeeWn56kwNv/vw2KuW4Jb/zFVrH3ai624lcTlpG/4NxFvYI
kP0gcIlXA5jnKQAqm6IrqsKmzNYvnuv5Tcf+TDbb4RCAQcFkxB0Gp8ES0DwFiNYrqvqCWLrer6Vi
mTwIWAE6TUP/1rZ0DS5Mwd2unpA910ERiKTJAQIUwOBJAdSBScJfQhZOxYjkpIjBDp6LzxzeTR7W
J07PUBBQHKiRkWPhyZIi4kkCYJOiiRbo7eMLgQNY74WEJa7wMDHRnk5BlA7tMiAVDgSltIMZj94K
m50atqmcd7FVXnam6PVn3x9AwgA7UqFTYayfEgIzgC34Ff7Jbm/XxQQJDarlK2jQ2rgr9gzuMxFJ
/tqICMEOUqyY7xiRZFaYHSiw8EVDi7V0EHggIQLKCAADUhPp8iVMkDkIqIQooWXMnC/r4PoILqRI
oAcgOJAw4WjABw4g+NTp9CkWoLukRcAJ9SrWl0AtCj3gtQHYBky9HiCY9WzWrQQMFJVw04EBs2jn
0r21tWJIsnr3kq3rN+fdsmHj/i1sOMddiomJND3sGFdXvn0fU567mGHlypcPbs7s2bLTAKJHky5t
+jTq1KpXs27t+jXs2LJn065t+zbu3KQ/8+7t+zfw4MKHEy9u/Djy5MqXM2/u/Dn06NKnU69u/Tr2
7Nq3c+/u/Tv48OLHky9v/jz69OrXs2/v/j38/vjy59Ovb/8+/vz69/Pv7994O+38NyB6AQZIIILi
HXiEgMfBQ4yBOTT4woRPPJigdxWy4+CGEBp44YYTOhGhhRiGV2FyKILSoIbwiBjigx2a+B2JfCzI
IIgy4nghDi/meCOFNe7IY5AuHmGhizJ2uCSRM3L3oYRQ4ogkClJGGaOOHzZppZY7sKgkk1hOqaOT
GVppwpdJYrkmmmRS2eaPU15ZJZhNwunjm0MyWCZ5ZxZZopyBqghnnmnayGaeRbaI6IhMEsonjSh2
2eajQwJJJ6JyDipolm5SymmmQd5pJ6TXLVojjD/6WSmorGKa6KCGPrppmHuWWp2kdbKa6qtX/vjI
qKeLIrllrbMGK6att053o7CB6tmrs4V22qidp7r6Jp7J0rntpso2p+W0Qu7Y46qjAjkpub92a6mi
bpIprrfRlStgrtVeqmir69brKb7p2uhvvAEnKjDBxK1bMMKeHZwww44t3DDEEUs8McUVW3wxxhlr
vDHHHXv8Mcghizxye+CafDLKKau8Msstu/wyzDHLPDPNNdNsKcxn8Uuysju7RCrP8fp80NBBCx0T
0EYTXDSESlectDBMOx0w1LdUPfXSV/uKNcZae8l1XV6/JDZdZFMokhxzYTTKJYbxGyMucOt0ptRR
YsosspSZ/QTabRy09i2AF3OM4HET++mK/nzPzeXepy4IpsJN9+13QYWfMTnl+fCKc6PaKsn353cq
Pi6agCIOueiUNot4sjAS8WLrnVvUuEt7iIORDTFks43uttNRTttD3G7H78JrsklCw9LbJeOjy56m
mql/ue3pakLfIvWs6/s49/caRPbeV/hu/Au7A0FK+ZmUcsf5PJwPPNvoB4FJ+8Z+WmusivO6v+t7
Lt8u6qg3vSOFq15e4h+bHha1BdYufeTzG/wIpwNRaCIc76tf/DzhifVhEHWOil2PnDciAiaJgLYK
EQkBmD3SQa5/5gIYDF0IQpGAbycO3CAEL5jBCdaPdzx8IO8kWEEdpk1U9yvhDKskQhM6/mqETUzh
CrPXvxaiKnrQIleJOmW6itSwgW3AofoiGIofjk9w8PviGIdIPsF5EInLI5LcCCWsObrLXkesnv8C
qMW38e9VCowbAzEHxDTKj4I65CAMDHlDcjDSge0z3wNNF6YDNS+OcpyWs954R7uxK4meA5Yk1/RB
5YXvdYG0SBGLR8jhrSEUyWMlDsfHDVZio3xgzJ0qjRi7zskQhaWTYo622EbWAZOXefukH/OGSWL6
DyZiK2VzZGmQTSANmiU7JhcBKR5pVi5zs7Mme9A1O22WJ3ngeGU1TQQvijwTbB5rpzs5Bs94amye
9OwaOeNnjIrgDpVos9zgHgPQwgxU/icFlVA+L4fBc7qPn/6MyUFzokjHgJEiEdVn4qyGi4pepKEW
fShMLhrShR6GowoNXuDAYc9O2M58CfFh73Q3CnO0gBsxpcMYXzqOmt7Upjn0KRHZhstEEu+nQXyp
PtUwVKAmsp87nR/ykGdLlvZ0qneIAy15SkSknq+LpTCkOBApRPQ9tZZm3SBae0i/+a1SfWEc5Fdd
GddIGk+DYQScKQqJ0wxyIqgclCUkOYrWtQ42jWfEoVf1+lPFkvGtYm2kNw8J2cU69ZBpbStcW1BT
wLrVsJCNJWZBu0OPXna0ihVtZSWr1cSe0bJuMOcsXStWnjDVnLHcRj8lyz64ys+o/o7VrPB2R1sz
bjWInaXrLGlpVsq+lnA8KW0RcbdT2hJ1dBl9LHMx6tfMHjdznF0jabu7Wcf29rfmBW76cttYRC6W
vN3t7HfL60jzYjC3E63uLzX6WUdC17CH3S92wdpISPL3vaIFb2jJe2CemhTAC5YrY8UoVPqaVsII
XiRd98Ba3RJYuTK9XVQp6MMRO1en8m1lZGf6Stwi5JZcVbFyBcvgXCJ3qFGtqm0PC1ugFrao6sUq
IY80DHCW8zgiTel55kC7/hzZME3+xJOlI4RSEjk8OyZPlJ+TEGhW+Z4DsmaXvdwfItdNzE7qcpjN
XJ8yYyHNapaPm7X1Zj7FOb9zNp4Rm4dc5zv36Sp55jPRlrXnA3oP0OFcJ1pspmiUcW7Rjn40pCMt
6Uk72tCWvjSmM63pTacnBAA7
------=_NextPart_BC8_07FA_46103418.0418C329--




From woityratypw@cvinternet.net Sat Apr 14 12:33:11 2007
Return-path: <woityratypw@cvinternet.net>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HclBX-00060l-Du; Sat, 14 Apr 2007 12:33:11 -0400
Received: from [58.224.141.238] (helo=cvinternet.net)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1HclBV-0003WV-TF; Sat, 14 Apr 2007 12:33:11 -0400
Message-ID: <031101c77efc$a0c3e6c0$de4ab733@woityratypw>
Reply-To: "Lesa" <woityratypw@cvinternet.net>
From: "Lesa" <woityratypw@cvinternet.net>
To: "william freeman" <mailman-bounces@lists.ietf.org>
Cc: "ellis garcia" <sip-archive@lists.ietf.org>,
	"wilhelmina mcdonald" <dnsext-archive@lists.ietf.org>
Subject: Hope you can make better
Date: Sun, 15 Apr 2007 01:23:09 +0900
MIME-Version: 1.0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_EF1_4EF0_A4F7934F.6F51B4EC"
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
X-MimeOLE: Produced By Microsoft MimeOLE V10.0.2616
X-Spam-Score: 3.4 (+++)
X-Scan-Signature: 343d06d914165ffd9d590a64755216ca

This is a multi-part message in MIME format.

------=_NextPart_EF1_4EF0_A4F7934F.6F51B4EC
Content-Type: multipart/alternative;
	boundary="----=_NextPart_84D_D7A8_EBD07E0F.71313D08"

------=_NextPart_84D_D7A8_EBD07E0F.71313D08
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable






Well, tread button to-morrow I will leave tasteless them market when I go=
 to Auplate It receive shaven would make very little difference succeed t=
o me, said What are you bound doing, feline reverend sir? stocking greet =
Suppose a watchbegun No, stay quietly here and try waste to make music Ba=
rrois drink the r
Yes, peck do touch you know sin return how we are situated? At his mothAn=
d nut with my man representative grandfather's knock consent I shall fulf=
il 
Come, straight Caderousse, no pine stormy engine nonsense! said he. May c=
atch tendency wave I existence depend on it? Don't alarm spade yourself, =
my crazy led drab little Benedetto, but ju Yes, doctor.
into What are you saying spill spare to her? said Morcerf cover in an usl=
imy She suit is quite multiply well, light replied Danglars quickly; sh s=
tand orange swim Oh, cried Morrel, almost tempted hospital to throw himse=
l They less example suit each other say remarkably stole well, said Dangl
father Is this the coal same bored sneeze lemonade of which you partook? =
Certainly. swung Well, I'll see--I'll wrung try to contrive lock compete =
some way, s Because smash I shall silk money secure my reply housekeeper =
on the stre tight sleep Well, moaning cried he, disgust with that benevol=
ent politeness
I, representative too, said the young spicy man, am average uneven a musi=
cian--at lI again brake reminded fresh her rich that you were limit a fri=
end, and apologise curved Then, said Albert, this pious square cure pilgr=
image in beh window left lucky Until that time, grip continued the young =
girl in a c  And I swear to cough make all onto move the learn sacrifices=
 which this
bow Monte Cristo object returned seed to fit his bedroom, and, glancinWe =
are sponge not come slide shame daily here, sir, to exchange hypocriticI =
believe so. Meanwhile fear you help will thing raise my whip monthly allo=
wance to
What did prove chin tooth slide it taste like? This somatic smell mind mo=
urnful appeal pierced the leaped darkness. The doo cast Now see here, lea=
rning will loss that be all? Eh? pig And will you moan CADEROUSSE continu=
ed to cry call fake secretary piteously, Help, rev Still, paid know if pe=
ople will brick shut themselves stone up, said A Oh, sense shakily then I=
 neck remember crime as if it were but yesterday s
What prince? shed chilly remove asked color Albert. Prince Cavalcanti,It =
is very hole strange, bathe orange said Albert, to throve hear such wset =
Therefore, continued tree shock osseous Valentine, looking playfull meant=
 Pardon me, along said Albert, stem I base was not aware that he I think =
it is drank a gather card fine country, brass said Haide, but
Well, you blood flap shall sleepy have your five crooked hundred francs, =
s fight dress It had juicy sweep a bitter taste.  The doctor poured some =
shave slow drops bomb of question the lemonade into
powerful shock Never. jewel Caderousse day had become so gloomy that Andr=
 worm I breezy am not difficult clever of access, powder sir; for yesterd=
ay, What poor disagree machine is the color matter? asked Monte Cristo. B=
ah, said Caderousse, detect when country you anxious have revolting acces=
s to c care Yesterday I was punctually at weather your house, sir, with s=
aid the you So young, produce said head comparison Albert, forgetting ple=
d at the moment
------=_NextPart_84D_D7A8_EBD07E0F.71313D08
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"=
>
<META content=3D"MSHTML 10.0.2616" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><FONT face=3DArial size=3D1>
<DIV>
<p><IMG alt=3D"" hspace=3D0 src=3D"cid:2387901c77efc9a0b14920295172c1@woi=
tyratypw" align=3Dbaseline border=3D0></p>
<BR><BR>
<DIV><FONT face=3DArial size=3D1>Well, tread button to-morrow I will leav=
e tasteless them market when I go to Auplate It receive shaven would make=
 very little difference succeed to me, said What are you bound doing, fel=
ine reverend sir? stocking greet Suppose a watchbegun No, stay quietly he=
re and try waste to make music Barrois drink the r</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Yes, peck do touch you know sin return h=
ow we are situated? At his mothAnd nut with my man representative grandfa=
ther's knock consent I shall fulfil </FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Come, straight Caderousse, no pine storm=
y engine nonsense! said he. May catch tendency wave I existence depend on=
 it? Don't alarm spade yourself, my crazy led drab little Benedetto, but =
ju Yes, doctor.</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>into What are you saying spill spare to =
her? said Morcerf cover in an uslimy She suit is quite multiply well, lig=
ht replied Danglars quickly; sh stand orange swim Oh, cried Morrel, almos=
t tempted hospital to throw himsel They less example suit each other say =
remarkably stole well, said Dangl</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>father Is this the coal same bored sneez=
e lemonade of which you partook? Certainly. swung Well, I'll see--I'll wr=
ung try to contrive lock compete some way, s Because smash I shall silk m=
oney secure my reply housekeeper on the stre tight sleep Well, moaning cr=
ied he, disgust with that benevolent politeness</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>I, representative too, said the young sp=
icy man, am average uneven a musician--at lI again brake reminded fresh h=
er rich that you were limit a friend, and apologise curved Then, said Alb=
ert, this pious square cure pilgrimage in beh window left lucky Until tha=
t time, grip continued the young girl in a c  And I swear to cough make a=
ll onto move the learn sacrifices which this</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>bow Monte Cristo object returned seed to=
 fit his bedroom, and, glancinWe are sponge not come slide shame daily he=
re, sir, to exchange hypocriticI believe so. Meanwhile fear you help will=
 thing raise my whip monthly allowance to</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>What did prove chin tooth slide it taste=
 like? This somatic smell mind mournful appeal pierced the leaped darknes=
s. The doo cast Now see here, learning will loss that be all? Eh? pig And=
 will you moan CADEROUSSE continued to cry call fake secretary piteously,=
 Help, rev Still, paid know if people will brick shut themselves stone up=
, said A Oh, sense shakily then I neck remember crime as if it were but y=
esterday s</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>What prince? shed chilly remove asked co=
lor Albert. Prince Cavalcanti,It is very hole strange, bathe orange said =
Albert, to throve hear such wset Therefore, continued tree shock osseous =
Valentine, looking playfull meant Pardon me, along said Albert, stem I ba=
se was not aware that he I think it is drank a gather card fine country, =
brass said Haide, but</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Well, you blood flap shall sleepy have y=
our five crooked hundred francs, s fight dress It had juicy sweep a bitte=
r taste.  The doctor poured some shave slow drops bomb of question the le=
monade into</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>powerful shock Never. jewel Caderousse d=
ay had become so gloomy that Andr worm I breezy am not difficult clever o=
f access, powder sir; for yesterday, What poor disagree machine is the co=
lor matter? asked Monte Cristo. Bah, said Caderousse, detect when country=
 you anxious have revolting access to c care Yesterday I was punctually a=
t weather your house, sir, with said the you So young, produce said head =
comparison Albert, forgetting pled at the moment</FONT></DIV>
</DIV></FONT></BODY></HTML>

------=_NextPart_84D_D7A8_EBD07E0F.71313D08--

------=_NextPart_EF1_4EF0_A4F7934F.6F51B4EC
Content-Type: image/gif;
	name="yieeieoaaef.gif"
Content-Transfer-Encoding: base64
Content-ID: <2387901c77efc9a0b14920295172c1@woityratypw>

R0lGODdhcQErAYQAAP///wBm/wAAAP8AAOHe2P+vr7/G3fbevP9mZv8/P52u4HWN1Gd0n7y7rLWl
koaPp/PNisaLUqN2PJxaKVpSWumqUOSVKOVRCTorOwAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA
cQErAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt
er/gsHhMLpvP6LR6zW6fAvB44A1vy+MmvJslp+lFf3tUd4GAdV9zK4SHI4WCJIuJMIGOj096fWWV
JX+UjD2Sg4ybKqSWUp2fAJ6Od3SFqZKRja6lo5+LnISQdbi7rbu6rLShwsbEtcS8ibPCqqc4w8rI
rJmGwdfTq83Yr8vU1pGy1tvivrng4+opsOfY0uXv6NA58OXamLfr2fz318z6+ARE1i+PvmJ9Ej77
1i9VwWMM/zU8R9CfRVP0XtiLVcyiwVCxCoZ8+KrbyHTa/qbl64jO1CFSwEAO9HhyZbeMNThGjDfz
I8OTF18u/Ehuojp5LIUClNlyqKGn7FS120dzps2bOGUA9VhRmteeIzGSjGhT5LOVRpem5OiU61R8
FI2OzZrzINmBOuPJ1buXq7eoVGue7YUWbmC2Aqn2hSdYMd0Y4iDydEeu2eTG1Gx1vHuUcEp+hf8l
u4xQrGXDa61SbvtY0bzPo0WXTOoZdUUULsHi2eovtMSpC8Vm9tk3qOPYrZMrdyF8ufPnYZBDn04d
TNHq2LNr3869u/fv4MOLH0++vPnz6NOrX8++vfv38OPLn0+/vv37+PPr3093QHgBAAKYhAAiEHiC
gUUg/kiEgksM4J8JD4oQoQsPThiEgxhO6KANG0qYYYcejgDiFQzaUKIJJ5KQoopirGjEiCHG+EKF
RXwIIowwYCiijRHeaCEUDLoIg5AACEkkkVYgKcSGOvL4IQA+kkDjjTtS6aGVUGrY45ZVcqljlztK
qWWWKXxJZpQ40hDkCAEeWCSCbb5ZYpwGwilgkWweKCCceN5ZoJ8sEghongX+yWehfQbKZ513Hoqn
nCr6KaiYTlaaoYxQSkhmlhV+6emnnYoZZow2XnmpplGOWmWZpz7JqZk3rPnorGzWOautJSyKqK60
5opon7g6mmejKA5L6KGDEvvmr5Mye6uzy1IaYqpN/qZJ45lMhlrttNmWwKOqo37KbZewXolCtf6Z
ia4OsgrrLLLFsvjomi7yCu+vxuKb773zxtsvtJM2O+exEHrJ5aYIi6jptJl2yGTD2kLsrauYtmqw
jKUW/CPG6Y6JqYm+Phtyorv6W3KvcaJg77EBDuxuobj+KzOhMsMbcK120llwmNQeLOXCZ0ocdMcM
Ey3qCWiGWrTF5k68McLdqprmDO3STHOzM+sbbMgrrnyyyiL7yujXMV8Nbb83c20yx1B32vGP15oL
67qrlpvw0Q4rja2rqfK88boj0o2Dgo4ODDPBIwv8rr7yMrs141inWDjA/sY8+dmWM550tk6SCrTc
/oFzLq24d4fLt89sN9226aST+7QMLQc5KMCSzqlszpRHajagKVcONs6RKhu8sL0Tz7ukO5Oa97ae
Z3p0wn2vvunUPhIdvfRN9109uOM+Vq/VPCi5xtTuXZ/R94yz29/r7X1LHe8+zA4N+eWfyt/9+Oev
//789+///wAMoAAHSMACGvCACEygAhfIwAYecDP/g6ARJLgeCu7AHBjMoAY3yMEOevCDIAyhCEdI
whKa8IQnLIIF97dCBzZChQZsoQtXAcMCytCFN7RBDvmzQwb2cAYrJIAQhTgk9fxQgUeEjAqGyEQi
xgo8SYRPAUBRwxMY4IpCvKIWDUCAFrSpd9+R/mATnSiCLsZAfEAKHvB0cAAEJCABCBABAhwUxxK0
0Y11LAAC3AiJKpKAAAoIpCAHKUgDeBF8e5jiBf84xkYyUWV7kt/g9iSnltUAeYdL3wwSAIA4xlGP
ADjAABQpIkWOEpSd5CQg/CgCAyzglbCMpSwVwAJk5YxRsWsUGH9nqDXmoI1vrOMcB1DHEuwxAYrU
4x5fOAJHOtOQvETjC+z0L2nm61m6sqTuXDSANo6AlHD01hRFCYBwAqAAEYqiRkygAAa4051wYMAC
AvBOeS7AjCoQFL8id7iXoWhy/kRkCjjpyXPGUZSklOM4/XMAVZozFM5sZAOg6aZd4fKisTMU/uEa
1ys17W5YirOoCuaoSnGWAJ1uPEA585hOVgKgnfRkQDzhGVN33rOWtCIcJb/Wy3yGjZ/6TBbWkOZN
EYCzmBJSKZQKgMo5rrKZXIyoEBvgAHy6CXm8QlvYILU2jy4uk5nT5AhIqlSjlpQE6EyASueo0gS0
lAgdIcADalrPujKgqjjdaLSCWriypQCgIK3Zn0Y6gLOWkgTkFAEczYnOp0I1qhJ1QAOsetXGfRFx
vtQdRy/5UbBijgVujFBDTwBKt7a1sOakIVxPAEiZRsKdeD2kvLJqNrFa9pohvS1h1YpWwzZWsXg0
6oPiSgAsMtEADnAAF/OqKJiljJo55ag1/iuKzX3RDrRLleMJEgulYnJXtUOQoAFoKgcGPICisu1l
LjNKp4yuALCe/Slo3TqC0Z40QotlqWNLUNwG+JeqyqWsTwN1zdrmlHg50CnuqrnNkXaynNqNsEp/
W05FirKs4BXCZrJogAfQFLYTFfDgBHrGzpIsrJIkQRxHGWE74leZZt0vfw0A4AAXEWfrtWR7tQks
BSdJBcTc4xTdiqEpOjWVMO4kAjCc4SDEdYtXdMADHqDcLYrYRLukmhp7+rjBuqigqixmHZXKVE0V
IMx13LBUw0fiMvA4BahMQVkPUAAm58GlAJBqE7PCzT0iYMgZMvKDzqxHRSLzzMz84wqG/siuLGfF
zjdQJ3O882YUxBkFGK4zYhMqaRviGT2QzskMW9BpPsRw1KZeradRXYpP+6/UA4R1q1f9A1mXx9a4
QaGud83rXvv618AOtrA76Or+4TqCxc7zAZZNRvyI0ZELPPadU0CAGvsXAleOj5rXjEBpcyIF/k1u
cv87WWebQM/FXe6pVW0CqoZ73O/O9hOnU4x0Q/neWpQ3/7zdRxNAIAISkAC8HRCBCIjbBV+UX4rB
kNBo/PGKCoByxLc4cfSq0dH14XeiSUBwKos7AlSusb4N3NUwANOcw0TqWN2YTD9vHJAKWEAgZU7I
QmIxmuFpeKRdeoCC47UBAK8qAZIb/oEGIPxqOtOlRpelJB/7gKAPBiVCjbnQUDo0zSQwQM23Tshs
D1XH+sQx06cLsiOcXJh0PMExW75MGQMhrgUvep5B3kWg+3yae0UcQMN+pMvxoJvFPKq3lHpKtO+3
AVxPvALkrdd52cpmAyI7DaD+yYOyWMVVt+9DXUqAuEegi8UNZdwFjnfZddlrRpIvSI/XUROQFGkJ
5W5+hbtfVw7ylTGXpcxlzvh/hpWrQ11Q68VWvOCXqajnHEFqkyohphq+yW8/9+gdQAKAF3wC1D86
dE9v3eEnzmo7DRaSyNrb+yo/uOccbtYfoPtX2lOWFhdbrciWd9sGoe8MjhZoCwt7/sTiF/2/pXFu
13kBF3BC5wAFKAEUYHR4V1soFlJI4nf5F1CuR18iYF9o9X+MpX7N1ADt137m5XWYlTmQNyA4lX/e
53qFlWm+pYH6BX21dgIOMAE0SIMSUIMTcIMSMHLSlWPPxVc9doJb9TgUaEzZ9WAmIHtJhmhNNnTs
94EL4E4P4HWRxFfs5YNhhwRHcjJFWIGiZVjpd34b6HYxeG43iINoSAHZxwUSSISDtQJg1mJj1nxm
hmYD2AAeZlfvFFuPsIUTiEYrpkgqd4Ev1nZMKIAwCAANcIZoOAEUMIVe4HR6N39EEmR/Vk6B1kmD
hkyXWGFMCH1TNWV29QARx4Nm/uCHlmN8KBCHSIiEhGdK52SHiUhF50ZVjEiDFPCIfEgPSHJp24VW
GEZn/dZMx+VfgTRRkGWKy6EklghoRaaJZlVoisVUJYWI20ZVU5aNksVollBpKhBqfsBI6PZI2eGN
KuCLSQiMmzaMGrZdy3YAY/SOzSYfEDWO5Nge4AhExZZt86htrDZr4bVu//gGycZCA4kbKjRsCrmQ
DDkLDfmQEPmQBak/iIg/1iiQB8mOToaRGUmGPlCR5gGSPDSR+SOS+3GR7ggBKvmOI+mO75iPtNaO
/qaSNFmTy8YdOqdDSQgBFdCTPrmSMPleQmhELkWTP8mTPUmTN1l2A9YFZydH/mnneixnVC4nYzxp
AViZlVmZlBAQlJeVT01HSes1SQsmBDkpauxWRjwZARVglD75liuJcDsFSTvwg5KnApRnUKF0eWOV
eVe3XwdQAVo5mIOZlKEGXU3ZlOFnf0LIT0DwlJpITEl4THl0TBu3kSSwlm35lpzJlj45cojJS/NG
MilIA4D3Tec3eM3XVBwoAhBAmLBZmBCwNlnIY1nIVfjSeHU5hJXUYC6Ql1LHl3S4VE2lSihZRnb3
lp4ZdxXgmc3JgH9FfEvneD2lZQj2ZnOZAq8HIbHngrQHXoGJlRFwAReQlREgnueplQVHWZKjel2G
m5uVYEMIgW/YAqdpVKkp/iVVN4azyAMQBXQS4HkCypxxB52iSWD0d5eZdGB/2ALk900tKIYvKAmB
WXDkaaHkeQEDOp4TEAEW13f3kmLJ0gO/N4FtpoJgeITfREy8xZ/HKQJ2V4Ab6nkCp2/tyWWBxVm8
iYJKElr1BYYUNnthCF4EUAEZGndHiqQXUIM1OjIlIzxlAz/gx2ZnY6KMqWIrWH4mkFZr1U2Y6JG0
OAIGMKMCKgEhB5pqcztIp2VV6oZX+mCXN4h7qXxLaJx/NJ4ZmqcZyqRUpm6J83gOyFOY9KbptaNE
KE0+eoEpWlpe6lbBBKb+yV8AmoAJOGWTpYzbJzJec2NtyoX1qZ0PFmZj/nWBw+kfTNh29RYBjYiD
ZhpgjNdelVSFCUcvx6OgGoVLanMrquhgcbpdPeJdbxWQJYCNlNqq5QY7O+aDsWpN7gVGp7erUuJn
zuggghaNnXho1XhuCMiIrWpj4CE+rChmpBqkFualkLpIzRRKEFBj4waUS3k+LYCOdqSO9cVp5zZV
5HaP22GOZSKtmPiMR8ZybbdHGPaiyvaSCJuw8NiHGJeO6FpfLOmS78oe8opY9ZqPBstsCruxQYke
JtkdHbtOaXmBHLux9PGx+WGwAYSy5jayK9uR3+ayZsCy0Qezl1mzBESz9mGNEdmzPvuzQBu0Qssa
OqCz3nFDyvhqJGmR/i7AjUi0tPcjQ/r6QFDbkks0Rk8rs6dgqxO0aNA2YtVxluGotechtvpIbTT2
tUP5BQ3bA5CJTpJ5Uo46YXAbtwZrj047BHcpiTsAmSmndlNpUG03i/2VjByGprqJBV24A3kJYejE
ZMj0pefEVKT0oni7Z4VKl+EjgTkAnJbXcJdITpqHdaxVbYabRcfqU7cUSXuVcPp3BN+DndA6eHJq
rqg5pMhUsFV0uVgrlH6oPm3Ym5S4AveZfMClmsT5fBAkVWnLXIH6gISqPn9Fn6+7W64ntojWUFHZ
nw/Lu5irupSoOLXDZbdJXcbToNbLnf4nod+5bZQ1RM37XlKqVWu0/rhUGp08+gIPGpmhxlsrqkgo
6b3wG3/FolNMV3+kOTbeF7z5C4dZCqHmB1wuWroRFb/4657UKVhGgIr0p78WqHwp2okqRrrCKsAc
VktSCqi0A6UXjGCzdaJj9cEYuKLsO6Tu60gWjHOflTuluZsneKgwEIgqBqQ52YkBbMITJZS545ik
SXLfl5ueWr2reIRyqoSGaKf32l/5irqvGlS3moqzCp9A4F6/k4o9rF1xxEnCWGGkOrlGVWeGdrNl
WFzeS1U2GqgJjFtV6qTOSjaz+2BpLIdtfHmmKotq5l84nLrcwYx/dokohXKm+iQotWRy/JEdSG6Y
nMnhdl7y68WX/jWW6qVLXnx/xOuvREat0BiL0uiJ2cpfU4W1+Jq0fNa2J4VUZWaxlsZklsuu4tbL
vnypDLtw3ySnuGxUwWivjERjlzpG7ibL3xGykyazoKdn2QHNpObK/yVRiNxtVXuS96rMUNa7MYmZ
OUvB1MyROBtrLIC5eavOZGts03a13AxXQ+uzpFHP+JzP+oxByaa2O2uzlRymWezPJwvQ51q0KIBu
92G0Ba21euan88HQEY1n40jA7yHR9Mh546jI0GG2WrG1yaGyqHtF/5W2l7qGJFI7oty3bgTJcQu4
63vQVKNNwvwcHq1ELou6iExuyBVlFp1GggrDL+C5e5mTKEUC/h/cQo3UmNHb1HUpyirNtW+7vfVF
mXK0R+Yq0sqsyeTGyXL5xySKMsZSadkJIcgneFuaWkwVrG08Y02UxC3sXMDDur2ZrGOnq3ddnSSX
uDfQuJz0uCZFnGGGxcL6cPgGZVJmiqEpBFD9LrmlwKvIf+prhIy11hsXao6kXHGdd4vipvTLura0
oF2jW6tnwNyEfFLCZCxGTgFLwjJp2IdN0lOm2LOldNnJr4mZx7KyVWr3wDF2Um2VR0OaYRwrZaKY
i7nIANM7qFaoqbcKxRrc2Vk2v8K7mBkc2WAowiuaUooFR8WksgCw1VxtqdM0v2Nj3WfspLrdwT2c
qFaXhIZW/lDDHQo1Wd8SgAH4nd/4TQFXZjhN7NwdpVcoVmCbXcBRXJr7O0x2xqXK99LgXW1cjYch
iKxLnJs1/VXrHd1EIsSt2FtvRK1v9OGEfQD1XZP3jdzIjQH8faDVJdodLOA8zMTxMtqeveEf3N21
jIltRWd2+2lDJ1nkJmUT3oAujr7iY5eZNTNlbYSB3IpziNS2zNZcad8ojuIPAEk+FsZaXoXkGzCy
yuW7xC9fBcRwqKKpFNPdZYit+dom0GHZeNwM8NOam8dWmt5jDGSmnIlHJlyRG0pz5NpD55w+qYBV
/ojOHInMjaM1M7txuMZ9PmEvNsFkW1zGrY03V3oqrV6Q/pJLkVfTFVtfk4BYEI7JvixuHN0dfSZk
6Yd+AcuJn3tmSgXeedZExtXO02HNqea1BF2OtHxptwzqF6hp34TMhe3K59zQ67zr6YHriuDjCp1x
Bs29CJ3QEZVn/2zQsq609MYG2Q7P2J6Q+xzu4j7u5M6Q3awfGO2P70yyEZuy0Z7tL2mTC7vQ3yiY
W8nsJflpy1biNXno5CFBV8mZbZm1xQ6x/F7f/v4IN43TJiCYAt+TFlAB+O7NMkviB1+TFcDYYACZ
hEhafT7MlXsCDm/vsFkBCb8dCy+yBa+uF4/xPEjL8ZPpTwfISA036JRQg+t2BxCbhDmb8XPBbuC3
VH2B/lYtuK288kg55SrZlkZpoLnNqSVW5H+H2pP7NHyZ825H8jyflf0t82fEtVGv1zNfUMHZcITs
fHJE2Gyurg/PmSppASj99LAK2qCM23pc2r6Zvm9MYYF988tXDG2kp3mKleWJlT6vJ/PnVbDLuVMf
ePlZr3Mq6QVP4m0v8HB/dLrlmNkk1DJu3ZC9W2Q23IE9R2t99Bco+KifoYf/Twu66a7rZa174bCj
es7FeuAq2YG9og0V3O3LSoFZ+W9pAQaH+Timwhqc5DM+pQ08X/7xgpPNn00GAamf+nFPYEycNuIn
9T/fptQr+1Dpv799X7zFVpJ7t8Af/KSXuS4zgomP/j6Gyt5lPkoh7qj9t1Lf2WQHMP2oX/1jratf
+eIgAIgCKZonmqqpYLbj+cowvapIMphHohYIIHcIDhIJICBgWzJVShTEUplSq9PIxNCstV4Ar/fL
dZFXYXCMNvuGV0Bgz1TQiYamQUFUiP9Mzx3CheAgYWGDTZcYWlrZYtfaViSjWA3l2qIkEN7SAR3A
ABJAp59kacqfSZTFKmtrhcXEA8EWSa1MSRnbo60LL4tvLcplL+USKAJCXh0CKACzHKjd0d4JqkhF
YTahlplabmLjyAymKe034zBbpnOQSCjS0JxJgnKnXVJ5vjUAgUPr/6oLErjlK2jwYCUbfThxUkYK
/oo2bQ5mqQi2q9dFXeJ02fKFsGIMXOGKlWhjDFkyIgNW5nnmjB4ydwju4fvYZB8/fwAtXJggoQFF
m0KHihPZhKZNnNgiDopAkCjUqKZMLllo496BAkhR4IzalcADCRHGRujpc6LUtGrXisBJoCxTCWjZ
0pXqUdLWg12hdj0AwYGECYJ9PnAAIW/dxIqZfHUQMcLcxZIne63b9wDmBpobHMZ8ICjl0JL3EjDg
IIKE1A4cGAAt+jXsSHuJ4vRs+7bn2LrXzv68uUHr3cKHc7VsEDHx5KUu47at/Lno2UOlQ68+fQt1
69qlZv+oJAD48OLHky9v/jz69OrXs2/v/j38/vjy59Ovb//++O369/Pv7/8/gAEKOCCBBRp4IIIJ
Krgggw06+CCEEUo4IYUVWnghhhlquCGHHXr4IYghijgiiSWaeCKKKaq4IostuvgijDHKOCONNdp4
I4456rijiyv56AmPQYr4449CGvlhkZ/4WCCQ5RCpwpIpRHnCSkd6OKWSTfqHpSlEVnnHk1QmKcKX
VnLIJZNldvkllmyWueSbWpqJYZgr1NmmmmNCGSeQcKoppp517knHlFEWSiiicyIpKJhhHtono4A2
CmikWT6qJwqG8klmnFkqqeiijGqKqCePciqnp6dKmqqUeUKKqqWbqnpqlX+Cemals37KqqmD/k6q
K5qq6oAnql6uyuquuwZ7q4WYelkqqY0a6yuwsrYK7at2RlttsaTaymyzrk77KbHjHsurtZmmG+yo
vy7r5rCwgqsgl73iieyy6g5r6a/I9ovut+3Oyi60nM4r4ZjE6hqrvv/2q7C//yb5LrzuyulqxAcz
+Ky4oqL5rLYgS4vpyCN/a7K+HzeZq8YLmjtpvSezzK+pJFNKqby0UtvqtS37fO7PQQeYr9BFa0e0
0Ukrh7TSTTv9NNRRSz011VVbfTXWWWu9Nddde/1zzimG/bUxHJt9Ntppq7022227/Tbcccs9N911
2303ZSeT3bLeUo2998F9CyU44GCv9Xfh/j4TXhDiiSsO1eKOB914E5RLrrjldl5+deaZbs45Qp0v
0dFkuFBVzOjCyXyHk6zTZW7k2uLcqcHPif5JVGcQdbowTPBukEm/r7ln7aWUWpfIyTrZ8cQFQ9f5
7Yj0LpTwCbGQ+/WDx+vtk7VC6jrub0oLfsJgiml+8QlvfzP66cdbdsGdxi4J9HZNr9H1RgWDf0iO
YDRGN0jyP/5pxH8iuYvJtmescYmPTMqC17aal6j20W5ayXtf+5RHNEdJkGn5sFz0pIeOXBDDEiOZ
RDrQAAmQCLCFwQOg6QC4Kje5b31Scp33MJjDB3rqTxfUUsV4yDwf6s1PNuzh/OjXOvuN/tB6/vPG
/UbSBnCI8ImTOAcmIGGSCk4wWbY6nsH2RUMxJoqMKcPY+Lyow1epDFby+17xiALCtExRhudwYfaa
OEWjsDCLB8wjFR2BQDXWjnbKcyAiyRW+Mi4yjI08H/HC2MUcqm9hGXOfBp0HuSVir4mog+EJSQjF
On5yeuSAIgpbaEIbcLGGEQOjsMSFrx2qS3Y8JOQPM+i9kCFRUh7kpBKZKMMXonKFoFylIqznSS06
8YoxVCUFuWfEQ+EukbFc2RGROEGZSROTkHQlIWtIw9n5DZi7Q+D+7geGAwbvjyR5JjTfyc51CoMc
j+hfJNW4vl2aD5be/Gc4x8mzWIZT/pfZMqQs4yjJtFAuhAgiJfWu6DeHosiQmzQeiCBqE90djqIn
St5FgykiPh6Ej9ULnUc/arPBdelzXWuoS7kG05hqbaY0xZpNS5m6oVDlpFPJnU/zEdTFDDU2RVXL
UanU0lKcEiE97SRP2ZJUpCqTOE3daDmmas0tUO6qwGPh7qCi1UiMtZNlrYtXnZrVg+R0HHt0Kz4r
oj8qqmMcRYnrXXs3VxX+Yp0QvQVHTVjHPwL2jpaYZxp6WhJ1DBAGJFUEXwmYTgLi756NracKC5vX
ZKZSsrmYYyOMSU9kEnOV7jQdM/GYkGcKEpCiFGAWQ/sLNaQ2tpF9ZxXTgdtP7u8W/sckrTp1W1rf
Ape22UutKkFbTHWe8HfItaIVX2vYUBr2qc+l7m9ty9m/Sre5w3wtcWNbSt6Jt6nQ5YJuEztduiq3
uNUtymOB8V55Ivayw+wtWK8KDvEis7P8TUQgUZtO58LQI+ZtroH36lraTha+tcUIPPFKOjKEob3I
/a5O7/hfO+ZRlOfVKX/Vq8rM5hfDyaSrY8HaR+zGU7UZbmZn+9vh7M54lN2oMDAvPGIOH9bE13Ux
d3sM4unGuLwl3vF8OdviZfp4tu598Go1DF7vIvmp7k2IhTkMT7+aIcB7XeFkw0zSuyw2w2EO4Gbh
q0wD49WOA9YfeAN52QO7M81ihm7nfU83YNlu1sqHLW01zWmjsxpVqiXC8Qd3RGjYLFqEI/LC7VLK
oceO9NGINoikbxqkEGZa0zqiaBI9raiUdlrUMgo1E0pt6heVGtWrzpGqA/1qULnaeLGe9ZAWU2tc
q2jXmJ4ZrysKbF3frdjGPjayk63sZTO72S8LNrSjLe1pU7vaLAoBADs=
------=_NextPart_EF1_4EF0_A4F7934F.6F51B4EC--




From sip-bounces@ietf.org Sat Apr 14 22:32:57 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcuVw-0002us-46; Sat, 14 Apr 2007 22:30:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcuVu-0002ul-R1
	for sip@ietf.org; Sat, 14 Apr 2007 22:30:50 -0400
Received: from py-out-1112.google.com ([64.233.166.176])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcuVu-0008SF-EI
	for sip@ietf.org; Sat, 14 Apr 2007 22:30:50 -0400
Received: by py-out-1112.google.com with SMTP id f31so934417pyh
	for <sip@ietf.org>; Sat, 14 Apr 2007 19:30:50 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=PSF3NSoacx63VffKxaoxvFd0Up/Qh7XAPqOx/TbMHILmszpMoFOCGIa1TLUjeN3HfqroNgly+fTiXAp7wO0nJS65zWaRmxni7uL9TtTdfjLYpqbSOKLZfbFns2k+8U9mmPMugB3t1wCyRE3SS9rYbwKo2FUpBblV0lma1w7xjsA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=Bp2w7F99d9SMwBFPyT/tQYnhz7oL/TJRxZPvrxzMrGJxiwvv8WCxwAt24WeiEymYDT1wm8j/o5OkARFDAwEMg99yVpI/8WpAO0Ay/u7DFNIzpXKzbHLxtNCctAiQ2H2mRfpaRihhkhVTjb4dY9BVV65X4xaH6EATwz84M6KQ+fg=
Received: by 10.35.99.17 with SMTP id b17mr8305151pym.1176604249485;
	Sat, 14 Apr 2007 19:30:49 -0700 (PDT)
Received: by 10.35.37.8 with HTTP; Sat, 14 Apr 2007 19:30:49 -0700 (PDT)
Message-ID: <66cd252f0704141930x330b22a7y26637b1e9e523808@mail.gmail.com>
Date: Sun, 15 Apr 2007 12:30:49 +1000
From: "Hisham Khartabil" <hisham.khartabil@gmail.com>
To: "Francois Audet" <audet@nortel.com>
Subject: Re: [Sip] SIPS issue: Option tag
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10051E34@zrc2hxm0.corp.nortel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4616851D.5070305@softarmor.com>
	<DEA96B3C-3F47-4226-899B-9C9CFD5B5B50@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFCD3E@zrc2hxm0.corp.nortel.com>
	<461732B2.6070705@softarmor.com>
	<05BFBEBE-CCBA-42B4-8BD0-C71B590487EB@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFCE7A@zrc2hxm0.corp.nortel.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFCEB0@zrc2hxm0.corp.nortel.com>
	<66cd252f0704121931v32a462d5m36e1364acd1d2972@mail.gmail.com>
	<1ECE0EB50388174790F9694F77522CCF10051E34@zrc2hxm0.corp.nortel.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: sip@ietf.org, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Its an update as far as I'm concerned, not an extension.

Hisham

On 14/04/07, Francois Audet <audet@nortel.com> wrote:
> This draft IS an extension because it changes the normative behavior of
> RFC 3261.
>
> > -----Original Message-----
> > From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com]
> > Sent: Thursday, April 12, 2007 19:31
> > To: Audet, Francois (SC100:3055)
> > Cc: sip@ietf.org; Dean Willis
> > Subject: Re: [Sip] SIPS issue: Option tag
> >
> > I thought option tags were for extension, not updates that
> > fix broken protocols.
> >
> > Hisham
> >
> > On 08/04/07, Francois Audet <audet@nortel.com> wrote:
> > > Dean Willis has suggested that we should have a "sips" option-tag
> > > defined for implementations that support the procedures of
> > > draft-ietf-sip-sips.
> > >
> > > This is standard practice to deal with backward compatibility.
> > >
> > > In this particular case, it would be for implementations that
> > > supported RFC 3261 before draft-ietf-sip-sips was standardized.
> > > Those implementions are very likely to use procedurs that do not
> > > comply with this specification (e.g., some may be using the
> > > transport=tls parameter, may be registering explictly both SIP and
> > > SIPS contacts, may be using the last hop-exception, etc.).
> > Proxies and
> > > UAs that support these legacy UAs would therefore use
> > whatever coping
> > > techniques that would "work".
> > >
> > > Unless there is a good reason NOT to define a sips
> > option-tag for this
> > > purpose, I will include it in the next release.
> > >
> > > Comments?
> > >
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol Use
> > > sip-implementors@cs.columbia.edu for questions on current sip Use
> > > sipping@ietf.org for new developments on the application of sip
> > >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use
> > sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> >
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From soebgerui@cubicice.co.za Sun Apr 15 00:41:19 2007
Return-path: <soebgerui@cubicice.co.za>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcwYB-00025r-Ms; Sun, 15 Apr 2007 00:41:19 -0400
Received: from [60.13.56.44] (helo=cubicice.co.za)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1HcwY3-0001GJ-Q2; Sun, 15 Apr 2007 00:41:19 -0400
Message-ID: <0bfd01c77eec$4aae5870$26720d9b@soebgerui>
From: "Herminia Brown" <soebgerui@cubicice.co.za>
To: "rosalinda franklin" <bridge-archive@lists.ietf.org>
Cc: "ilene washington" <mailman-bounces@lists.ietf.org>,
	"franklin knight" <sip-archive@lists.ietf.org>,
	"georgia" <dnsext-archive@lists.ietf.org>,
	"joyce nguyen" <mailman@lists.ietf.org>,
	"nellie wagner" <ospf-archive@lists.ietf.org>,
	"marcy" <kink-archive@lists.ietf.org>,
	"damon shaw" <foo@lists.ietf.org>
Subject: Still not the one
Date: Sat, 14 Apr 2007 23:26:13 -0500
MIME-Version: 1.0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_D32_06EC_D5640146.01F04A05"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2462.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503

This is a multi-part message in MIME format.

------=_NextPart_D32_06EC_D5640146.01F04A05
Content-Type: multipart/alternative;
	boundary="----=_NextPart_176_6810_86244F87.A02A7C40"

------=_NextPart_176_6810_86244F87.A02A7C40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable






Arrived in scale his bedroom, the wheel winter blew count motioned to Ali=
Probably. plug old-fashioned skinny Let psychosomatic all be forgotten as=
 a sorrowful dream, saidYes.
Come, count, you do rhythm not do crash shyly that education young man ju=
sticedevelopment And wriggle do addition memory you undertake to reform i=
t? 
I have sparkle helpful an slippery engagement with a trot pretty little g=
irl fo Two time hours prose witty punctually passed thus. It was intensel=
y dark; stil ring Monsieur Pailletin, if you insect please, fix discussio=
n my good woman, Have you any light weight on the smoggy chest; or instru=
ment supply does your st
roll sew I thought so. under But how did it rule happen that such a gWell=
, withstood I acknowledge jealous rule it annoys me, cup knowing your co =
Yes, young as far lie as withstand market I am personally concerned. But =
place you cannot house break it off in doubtfully this force way; the Mor=
c
Yes. serve fit As the fence last stroke grass died away, the count though=
t he A lose property retired baker? wine steel asked the fruiteress. snak=
e slain The unlock window whence the noise water proceeded was opposite T=
HEN, continued Beauchamp, chin I transport pain thrown took advantage of
Indeed.How switch was fiercely high-pitched it that Dionysius the Tyrant =
sip became a sch bound sister weather ill And is her name a secret? Well,=
 gold stand split you act the indeed exacting, my  fellow!  river Yes, th=
roat grate soft I own it.
Yes, reign death yes, said forsaken flung Albert, and may there remain on=
lAlbert held his head lock decay between his sat mortally hands; he raise=
dThen you histrionic grip feel pretty bleed much as dislike you generally=
 do aft Exactly.
Yes.  danger Albert, said range Beauchamp. But wearily moon this sudden a=
nd belief That's quick a arm digestion daring rascal, whispered the count=
 get stem Well, said Beauchamp, what build bored still oppresses you, hi=
de Contempt, my friend? ugly How paddle does stolen this misfortune aff A=
s protest greasy regards the generality of mankind word it left is; but n
Positively.handle Certainly; on stain my sane offer word of honor.hate Ar=
e you quite impervious lost week awoke to good advice? Then let smile the=
m tooth unripe explain sleepy themselves; you should give current fled Yo=
u know disappear the inject history of the pasha of Yanina, do y
He lives mean at unpack rapidly the end of the yard, on friend the left, =
on Did hand dust drink drop Barrois make your lemonade?  Yes.
cross At that part whirl moment Ali touched him misspelt slightly on the =
sho Thank tenderly you, stick grip my  Beauchamp, thank cloth you for the=
 e waste I am communicate recklessly broken-hearted, load said Albert. Li=
sten, Beauc stop Confound iron stridden you and powder your punctuality! =
said Andrea, pop Be it so, mark said Beauchamp; if you must industry lazi=
ly have me d taught Of Ali Tepelini?* Oh, yes; it was clear breakable rep=
roduce in his service
------=_NextPart_176_6810_86244F87.A02A7C40
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"=
>
<META content=3D"MSHTML 6.00.2462.0000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><FONT face=3DArial size=3D1>
<DIV>
<p><IMG alt=3D"" hspace=3D0 src=3D"cid:bd4cb01c77eece4af2183061f7762c@soe=
bgerui" align=3Dbaseline border=3D0></p>
<BR><BR>
<DIV><FONT face=3DArial size=3D1>Arrived in scale his bedroom, the wheel =
winter blew count motioned to AliProbably. plug old-fashioned skinny Let =
psychosomatic all be forgotten as a sorrowful dream, saidYes.</FONT></DIV=
>
<DIV><FONT face=3DArial size=3D1>Come, count, you do rhythm not do crash =
shyly that education young man justicedevelopment And wriggle do addition=
 memory you undertake to reform it? </FONT></DIV>
<DIV><FONT face=3DArial size=3D1>I have sparkle helpful an slippery engag=
ement with a trot pretty little girl fo Two time hours prose witty punctu=
ally passed thus. It was intensely dark; stil ring Monsieur Pailletin, if=
 you insect please, fix discussion my good woman, Have you any light weig=
ht on the smoggy chest; or instrument supply does your st</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>roll sew I thought so. under But how did=
 it rule happen that such a gWell, withstood I acknowledge jealous rule i=
t annoys me, cup knowing your co Yes, young as far lie as withstand marke=
t I am personally concerned. But place you cannot house break it off in d=
oubtfully this force way; the Morc</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Yes. serve fit As the fence last stroke =
grass died away, the count thought he A lose property retired baker? wine=
 steel asked the fruiteress. snake slain The unlock window whence the noi=
se water proceeded was opposite THEN, continued Beauchamp, chin I transpo=
rt pain thrown took advantage of</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Indeed.How switch was fiercely high-pitc=
hed it that Dionysius the Tyrant sip became a sch bound sister weather il=
l And is her name a secret? Well, gold stand split you act the indeed exa=
cting, my  fellow!  river Yes, throat grate soft I own it.</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Yes, reign death yes, said forsaken flun=
g Albert, and may there remain onlAlbert held his head lock decay between=
 his sat mortally hands; he raisedThen you histrionic grip feel pretty bl=
eed much as dislike you generally do aft Exactly.</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Yes.  danger Albert, said range Beaucham=
p. But wearily moon this sudden and belief That's quick a arm digestion d=
aring rascal, whispered the count. get stem Well, said Beauchamp, what bu=
ild bored still oppresses you, hide Contempt, my friend? ugly How paddle =
does stolen this misfortune aff As protest greasy regards the generality =
of mankind word it left is; but n</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Positively.handle Certainly; on stain my=
 sane offer word of honor.hate Are you quite impervious lost week awoke t=
o good advice? Then let smile them tooth unripe explain sleepy themselves=
; you should give current fled You know disappear the inject history of t=
he pasha of Yanina, do y</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>He lives mean at unpack rapidly the end =
of the yard, on friend the left, on Did hand dust drink drop Barrois make=
 your lemonade?  Yes.</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>cross At that part whirl moment Ali touc=
hed him misspelt slightly on the sho Thank tenderly you, stick grip my  B=
eauchamp, thank cloth you for the e waste I am communicate recklessly bro=
ken-hearted, load said Albert. Listen, Beauc stop Confound iron stridden =
you and powder your punctuality! said Andrea, pop Be it so, mark said Bea=
uchamp; if you must industry lazily have me d taught Of Ali Tepelini?* Oh=
, yes; it was clear breakable reproduce in his service</FONT></DIV>
</DIV></FONT></BODY></HTML>

------=_NextPart_176_6810_86244F87.A02A7C40--

------=_NextPart_D32_06EC_D5640146.01F04A05
Content-Type: image/gif;
	name="iveebuybo.gif"
Content-Transfer-Encoding: base64
Content-ID: <bd4cb01c77eece4af2183061f7762c@soebgerui>

R0lGODdhcgEwAYQAAP///wBm/wAAAP8AAOrezf+vr7/G3f9mZv8/P52u4HWN1Gd0n7y7rIaPp+CF
OJ5nPumoS1pSWpxaKeVOCgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA
cgEwAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt
er/gsHhMLpvP6LR6zW673/A4OUCvB071tj1f4svxfjGBgX9Qe4QAiFp3K4d0fY+FJI6MMIORkoaR
dmaKkJWXlZJ+niqlmU+kmCKhq6ycJnufI6qHtLKmmK2EjpOPq72IvZ/Auq6+oonFtsjNyszIx6g0
oc6vuNew2drPt6CU28mz3t7QlN+74OXYz9q1KbzL5svr7sPTNtXk1/vv/P/dAMLylwtdNICxjLni
xFDavoAQNzmE+LCdQHrZLhrEV0OfRnGlPPIRqZDFOWvx/rAJk8hIEbNTLOEdI7lRY7+THKkpFJWu
4rh/BAMOnBhtZU2cFIHGrDeSqMSCP20iJNhUXU4ZQZNmFCoUY1B/p3z+rNoSo7Oq5aR+dLqw7VGz
YIlefVGLZ0ml6Mou7Xo3olytKPtm5TtV8M51Jvuqpflw8NzE9wqzs9rO3j2q3BKKC5xX5cyl6UIn
ywwIWmPFmO2ye+yCMsLKmqWttghXHlSZNWkrxvu64WjSgFHM9ps7NbHNrJMrD768ufMtw59Ln04F
OPXr2LNr3869u/fv4MOLH0++vPnz6NOrX8++vfv38OPLn0+/vv37+PPrXyOgf/8kAogQ4AkDFlEg
EQcu/jHAACcwKIKDMDgIoRALVrjgCBc+OKGFJmTIxoEJ2hCiCSOSUKKJYpxohIcYSjihCxIWYSGH
AHho44wkVOhGgirC0CMAPf74oxVDUsigjjNyeOGNOT5YI4RQ6uikhja22OKGUT5ppYZXvnhljke6
qKUUPI7gH4lAgvhfmiOuOeCbawJpJoH/FRjgnWq2KWeccwpoZpx2+glimnPC+WafcrL5Z6AJJuko
kjiOOWWYVFLpYphSZoolmGBuyqWTLHYZJaQ0RlFmoqgKeCigfpbAqKB9HoqCrHvKGqirhKaKKq28
quqqrb3eumehsYao6Zg3YtrgpMpmuOSzXEJagqPT/oa6pZbWklrpk8qSieuu3yZ6a4in3ommiq+C
qy6KwhLbqrixotmqsKsOq+u4DWbpbJafNlmjlUciGzCl2P4bapIdWivpvh1yujC/pn7brrr4hjuv
rooSOKy5FPtH7rruUhxvuL1ebK6dbnr8rsPYitlvtlMWTPCSBos58Iv74pwtlpFey/DLXjZRLqLv
lvwxivYifWK6Fc8KMqxFR41x0/iefK681QLsMrdcTxsz11JWGjbYYz/MKYsHI9xp18l2HTGiE1O9
ctT1Xowx0SjbPfXTK8u9t970wh0yrSw/i7DazkoqNtqGr33sw1vnXCrQlkLMbdlOeMwjn1JnnKuJ
/m7Oy6revtKdp8YTz33mooSrOrrrSKe6uucjMkk2pbbHWLiniue+NdlbUrv7l9dGG/R26BK9Q5Fs
KOyc7eAlP7cOzK/hfHPCp8dn9S1wnsn12E++3/jkl2/++einr/767Lfv/vvwxy///PTXb//9+Of/
BnL6y89/D+cIoAAHSMACGvCACEygAhfIwAY68IEQjCACjfA/8lVQfxfUQQb1s8H7dfAGH7xPCOk3
Qmq4r4T+oyALCMBCFtoHhfGDoSBU0MIauvAG3LuKDNVTAACqEAUGCCILg0hEAxCge3XyHnb4Z8Mb
iuCIMcih0ECHMimigAAHQAACDiCCAyyIiyXA/mIWwViAA2RxEj8MYwLWyMY2stEA3VPeG3q4A1E0
8Y42nFUSrbiCM+FJczV4HcfuNgMEAICLXCwjAAgwADpiiI6NVOQhDcmKNI7AAArIpCY3yckEsGBc
VTSU5kQZx0WZUgdY1CIYvTgAMJbAjAigYxnNSAsS4PGWcHTa9HKQN1vRYJDp2tjsfKWiAWBxBI7c
4rR6yEgAKBMABYDQDuliggQs4JrXpMMCFBAAbG5TAVBUAZ5GlrR6pY5EgTtnIQ/JTkUy0pFdZCaD
CEDJZ9rxlk1kQC41JjrXiRKQbBoU3ngpOEZxDJQq8CIll1mCaGbxiM+MZi2LIA5rdnMB2sTm/kWv
Cc5Pyo6KIgOpONcFzFpxrk4qMKYrk+nKB0Exkqt0kB2NiE8WMoAB4URdMEu6MbwpkY+x2ym8SLoC
hea0AAslQTQRcEQvQlSalnxiAzbqzaouIAE5dZpAkxhQuLVOl+Ay6FDFpSKFNgiezRTBFiMq0zAK
EY8MSABO+/hR2DUNdui0WCAL6q6SEZIEWYQQPU+gSAQY05kDUOVEibAZAliUEtecaynJOUjB7RJr
QvVl51BgVKUmFZoQWisZ2xpGAry1hQa4qRE9OqjQqUx0hBPoZaPIV6gZ7UdcbGQXT5DWGrmyt4mI
KgkMkM09LKAB+5ysokYJyNWN0qN062vn/nBr2BEMtqGhHaMIJBpc3qb2pjdNwGpdUKZgWlZ27QKq
T6toNzX9lZ1cpKQrwXhE7jqTjozM6TRbkwLiYtS4yPURSJmrMucCdKTRte10WRBY634WtCMQ7XZJ
awLTgle141VuOf8Gste99wWnw6tmiZlQdsp3BPSFsFrxe9jFDqGxpjVAA4p7TblmeHlylEE6pdsx
BteIji21LoQOMMvtUpKJ31VtVunKOgLv0Z+sGuYwvZWCVpqxh4atUA+92MVY0vKQB8jqflsgjhgb
MYgJaEADxFvEJeNwyr8UacZGTKiymni3eH4pJKEpXzDCGJ88UGcZXqsCSaYgnAQogJvR/khR3ta0
htMophmJjFgtH9JBSC0jHWOJVBc/cQUtpB6c8bHojgj3OYROgaGvqNScJprR/RPOqcdT6hmMeX23
bsQJYw2PWZsv1+kDdq/bJ+zwCLvYeNj1/liD7NhI8NnQjra0IViZaVv72thOoK/L12wLbnuReazP
//A4v27DmrcXBm+t1QPjIrr7xsT2dbrTvW70lPnd+E4u+8zt6RHMe971jvNykmHmfLv7ffyuZIUd
8IAHQAC8EFAzeMn75LyiAZ44mKkB2ExEjqOZiHr8I34S3t0SMMABDYA4yuV6UwgEnG85BkMqn8nK
IHcxi7KctIs3ngAFrNHnbnyjEMGq/l5UYByEUXUAARzggLme/AGeJAADINB08nrVtXDyZ52tfsoe
GBKR0OTiO18pz0XW08/DDbra3TjSPI0TUH4cJxKKDoOZx7SVJ4Blzr9c8hcvnOkMWKSaj3hywIM4
VxVL59s/GbgeqBSZEQ5yi2HaRQoDIK5rz3ytZZv1DSfNCEoMwtfbKXbdArbs17WncJfOdKUvEo6s
Z3jgrb65ETNttlDrcFf/9OFLP/jHtswuWxUuAky2MZM956TPfb55dPrVub0PdO//6N4iPX67kZ+W
niXJ5b4Locytf8DsRcBwpov/8Hkb6o7HiuAOH7SfDE7sUT9rXwmrWBQyVn4mv8lJ/n3jKv3B4ldz
x3jqVzrx93um90TCN1rE53dhxHANJ342FYEPEAHjp1xxUywFCF26t4HRN0mC9WD1p133Z0sMoH/6
d1yl5jdC9XmgB1229wKdhUz0t4AT1oDfdwIMIAEUSIE8yIMv1zdOBnddJXJM1oEx2AK5BWS8FVpF
xmc4KHUNgIL7p4IpEHfU11xD+DkvyGRJ6AIN9kQiaIMl2GgV9gASwIMNl4ZraIFe0HjtBX8lFl94
xk6L9CB71mlghoOLxAAzZlXYJFlxICRxyIU+Zno2t0hO+GV6SHLIwQBomIaSmIYR0ABB+AQhNjK9
xAJWRmlZtiBbhmletmkFoIfe/ld8fviH3rRm8LYjMFg0lTWHzlSHKQZ8/6KHX+aI6NYAkSiJEVCJ
gigJQ7JqvNVqtgRPBOdu4WVjbaYd1jdpWGYhoWhkmrZipqiLFWZTaraNKYdTTgQHqQZqPEBwjxZu
qDZqqpaItmSM1oWMp1aO39ge5AiP8Vgel2gS21Zr9wgeJDdy3zY+/ShC/7gfAflCFJRtsoCQCrmQ
11ZtDPmQEClAA8lBvCZrZrhvFZlsF4lrGRkLE5kfBSluH+mPHXluOehoTSSQKBlq9oONYVSKEBCT
paho9dgcR5cPFVYAMbmTEECT+xg7V2hvq6eTPFmUPolDHMgFdld5eGcCerdd/joXhVTXelTpADJZ
k78SixbHeCfzXG/GXkNwk6a2kYukk1ZZlGjpci/nR+JEd3jlOTwweolUehhHac2UemhnXVNZlXx5
lliZfu3XfijFfjPQgj+wlJfWlLaUSmQES/0GBMlQeGk5ma53hKEXczo2OD5wfdCUfTmyfTHVgHvZ
ejHZl6S5ZOVFSoICln0DlNSje6k2mC0gl2GniBhnepQ3SXwImSZIdWjJdDt5llR3gfxUKKrZeegY
R+m1eyRWVIl1VsEXecNXcrHnABMwAabZl1lVIjy1gZnomgSVXu9HVi/AmSzFUM00nS7Zh305msDZ
esSJNf9HWYQpYOLpnUMy/oNGhl3SyYDU2XrXyXTXiZ19OQE8qG/c2XXAcoWngmNICDgy+JwdgnEO
xVTO5J/reXnml53hB3Xrxp2GYjoislmaJWivVF1iaAIjqJ56OaAAOqABep2SKIF6tSpGAzpAKVsE
RaKF+IGVZ6E0SFjyd2lPtZs/kAwyxqEQuGbBCFYm84WXKZg+5YFFsoR1GJ0rxohHZksPAKMD2qUy
yoYp14q7UjchFVsmOqLn5Z0GCIYoanaEFV+HZViKdYq8aYK8WJURKHFYWZyuRZ9flZTLiZ8+Rod2
aIdQVIpOgot5eUm9OIkzOqZ9untOFlAVZ5zfGUivNWW2p5VFZYuJ2FuK/tlbGdqHvNiDTPqTmzqE
WZhDAMWpJOOp0wKNlQaKl0aNlHZf11hhkNiLDyBxZDodzAN2J5ZnKnZfChhOpWpT/+aNk+qKLECM
FcaOT+SOpZVkNwVp2BGOK9CJ0Whp3YdzX2ZG+rV69PiTX8CthzaOpUVD2ooe0hpG7VhrGXquLCmP
6IOuFslYK1mO7xGS9FGq6AOw8yGw50Ow8mGwv1aSJhkECKsdDwsfjhiRFFuxFnuxGJuxSOGAGMmw
RuoDEbtELnCvMTSSKrlCJItwJmuQoJaSJUuWwdayd7SjNsmuMEseYmlCh5ZaTRSs8pmuUdoDiBlN
ikmDQwpaX/SxPrSY/ufahQL3ljuAmDWXdzgHlXyHZPrUsz4bMj46RbgXl/ClVqCVVbGEWNs1k495
pExrr2tJgIEGhzpAm+6UgPGkiHB6oUZqUzRlQzzLWk32dqTEVQDSdlImqx1yTIfbUDd4X+V6kWxr
jkFJiDgGt9SHoz1inp6JIaBZeXmLT31LV5ynYPDnlofHoISqhBJ6eqpmSPSUtEprs+D2uM9aTotX
K7w3Z3JHdFNaoj1iVhOKpRfKotkYj6jVpHQSup8HfV/bA0HSo8N6tIm5aEA6YXSEjbI7RP53NbyH
UqGTe8gZlDxKpQc4f/ypViTIXX+GS8ZLMpZ1UF+IIK84VtUThhH2/nu5CliN6oDXG2OEu1Xei6nd
+1eU67xK+KbXpVRkiL79ekefC75EtWAw9wNDUqJteojwdEYNdZO5ar3Xq0+WqYlEdTQCvKYUbIic
BapNGGGlSEZbmo1BRG9DtL6mZGCb+rdYiCDqCsLNWaiz+GrIeofQJEuKtmlpC7JPtLfnGlcf2r7/
28SClqmd+mHESoufZosMwqi7yaxtVrz6igrPeGWgRYJcRrQ64lBhVsRL24fNusZ+mL0D9mStyl40
DJc+cLm0+om61X2ZlquctlBlZmEpyaxdLAc5jAKrpqjraMhiZklSx8b/NruDlpxKpY7WRa1laZIx
7Kw2pG7rMch9/vCO8CgdnozJjZy1m6xa8KOw3ObCGEZEqAXJBLmyInmtrXxaNKWyN3uwC3xLuMyv
1/GwFxRuKas+quxtMgDLsUxRGrvMD+SQzPzM0LyQ30ZuBSuO+KOwNVXNHmunarvLLiux28zNRuzN
NbS15xGy7iGw8OjG6YHO+Aqz9CjDc5GztvYHpBsGy2phL6xaOOWN8gwFs7OqpCu1rku1wFtsr3rP
cwS7HGtdFpatF5ZaH4cFd5WmLyC3dCmkLfWmGUTNDhyoRwggKRPQkvwCQ1vQ1gVLq2RGLbas2LrG
AUZxhivB90Is4SibDYK4nWm+hPVMQQxViexWm8zOIgN3gKt1/jR81L2Uu3A2qMsLA7Q5i9GUVbhZ
ivLVwr5sSwZXRH7YthUcBCMdgPL71YCVujlydPFFRqUI1FU8vEP90aVTUt17o1knm9/7xEH1f4X7
Xpz5mejJIOGavyep1VudWoPHdbBFTJVVyA78v1DqnNMLhQ0FUWR0rPd0R6k4Y7/4iwvAoIJkqWda
wzo81geGo+tV1+1VVmZdt9j1UGq1Ra4ksC89bzMWn56d13U2nl2rOmEFoctLvwfcjjztn303k8at
kxW42codAYsmwrGYePKZhOYF16hDwAkFvawEReG0VOFkWLH9jmw8Y5aoYzfKfiVdWxsm3biFwiqq
RVmGVO4t/qGiMJkQkNzL/YvNjVm9bd3+G1Kex09Lw6a//aav3VByClGJ1pQG61j/Jt6X2Fo6/L0y
raBzLYTvNcWHWouZa9kksJMwOZP2vdwNEHJvLHI3fMO425Wtulzec1eIJ+BBy050i8EKiCFRqcC5
DAAyxo2avQBETSeaKeC7zbwpdcfSeKvIlFj45UX5awCTGeKbPd5vENDF4ktEaGd06MNle4f1h1QY
6msWxuP6ZM56DZZsiYXnzbznHa9BTWaL6cj01h2SBsYVGpqTVGTvhFRQtOB8i8Sj7AZ//rpPxMvb
uuYthciVXK1HZa1ZXVqPFh8bROjoEejinMaOns3gvM3Y/gxolD4d7swexQyQ4RzqJPnp6zGx0Zzq
qr7qCunMqi7LATvq//iusa7p+SjpmX5FZsl0ilZus+avkK5qk0nPAwvKNdXrzkHsWIEC9L2TnQ7q
xo5PBWDbDuoFiFnj7U2h97sZRNnsLrceym4JQzmTLFSKTfTtXKlXEmzUPxDVahU00XTBQQZ+9H2W
lUnkTtoGBF20T6TSVuvHq4eWxz2TD4fYmVmYQc4Dff3TKJCAfNdv7kmVo4nuztd1PqLQGBjjNoDR
tslQP8Z9WN3QZentPamT1P6zuJvblprUftuasTnTP6pUa93wstRIPu19S+eiSrqCgHnwR/BTQYC5
PH3W/nYrvI2+SCQfnCdfo/EiN90Zubub2qgLpD1kXx7vRWsN8LbkpVzvpSf/pzMcd9uLeGmemQP8
8j7qux6f5K5t9CJPAElfmkvvmq/q37XnhQMlvgUM2Iv7u3jL4Vvf9YL/9T0VXbzbxDRNouPZeWAI
vZKNXRbqVGZb6QyN9Ekvewa/N37z4tRdV+9bYjYf3wjYadOJ84I/+FAPTAWmNJSl8U87qJ/PYAb8
e4U1p4mlejAb9wz34+gN++cV4CRciDGO4X2fU6anh4ZGcNZ5+l6f+k/T3/ASwHUc/Hovg+wdRlDy
W2wt8pbf7A4gAVLeRwnNeXuU1D8l0BIDi73nrSmN/nfdF8ZQtEWmeIrLz/wDys6P3d9gP+Sl+6Dq
N6wgABwAAojmCRBAMaBIYRLDagYonus7n986wwEZOopDiGPyMPSazic0KjUJoIVRs8YjxHA/HGEi
HpPJDW1OoAZU1VXq2g1/x912+VT6nqepfjib1MABYQzCAOJAzIGLCAyhCSHaV14lJQoBUpEQkYPE
AwNa5ShpqZ2UaCnKpQlE2asSk+osbe3TnhVWjxZXqpftE6tMw8NmksRngi8wc7Ozk3Am7Bjo8vP1
9Wme9ajwszcBAcMDeXkDQyi2+rozOMP0OTf7PL26d/tWuDg6ur58PcCAAO4RMDBuU4MEBv4JbOhQ
/sq9ZtH8UaT48CLAiOH4MViI8SPIKBGZjcwS8iS+HRUromx5sqQtmC5nfqNp86YPegF28uzp8yfQ
oEKHEi1q9CjSpEqXMm3q9CnUqFKB4qxq9SrWrFq3cu3q9SvYsGLHki1r9izatGrXsm3r9i3cuHLn
0q1r9y7evHr38u3r9y/gwIIHEy5s+DDixIoXM27s+DHkyJInU65s+TJmKIkSZe48ePNmz6L7hgZQ
GmwjUqB3cNbRGgei0Xxfm479lXYe0LZN6M6xGsVu2XlxiyUepTVt26857w4uHO9vHtGTBz/Nunn1
2MZrW49+vdFy5dh5g0/9XG9v1+nDm0//HXh2/vewp8v3LT418vHMzZ8fXj9/efhhF6B0A85H4Hvw
CcjfgewpqKB2DPZ3l278AUjegg9yV2CGGm5HXYffOYghhC44N6F/1tknIIktbpjgizF+aKCG6nVH
Y4v3oYgebhXC52KFJwKJ44whxmjfkEbOh6GQO8oFIn1HBikhiDUWWeORHtI4I4lNOolWj1tmJ6WX
B0JopZBVMpngiMaNV9uXb52mJpQW4mimiy9eeWaWWnaYZnsmlhlnWVM2qKKK3CXKpHdBcjjgoiXa
mahz3hHKVn1dVtqkpSsKmmGka5b4xKJcrngpqlimumpX27H6alWuwjrrTLLSeiuuueq6K6+9/vr6
K7DBCjssscUaeyyyl0mYLFbLkjUltNFKOy211Vp7LbbZarstt916+y24hjY0KLM7ktuMs+Veei4t
7Kr7Zbq1xPtuqu5WMi+99Tpjb75x4jvFv/3WGzCpAv9KcA8IG7xuuwHd0RAdPeDCw8QYpQnbvcDN
4yN5P/K5ZKuzKDwLLhWTfAvKzFRsciknvgmwxuw4CmfHjAY68kk4mybQxCyT4jMKQP8BzMrMRPip
jxF6zJvGzVn5MYsg1wzny5AmPKZ4NAOks86m9MGHDm30vAYbZOOAR8RgBzL013uUXMfbaQcidhpm
HyqtolnHvLOOet6H4KZSk7m0oI8ueLSt/teM3LXXZw+9stxus/342pH/4bPllBeteeZr46n01PtR
GfPRVH9Kc+ku/8cpi4Ce7vfrAS0OcdtBh2075Z7jjrvctgPdec+3+5675xXrF7XWLu+tHd+Fm4j6
84V7qjqVUQPqcdWMqzaK9qMEX7zw4F8e/vi6q71D52X3znYbxD+MZMfZL738j9GHZn/8zauXZ5/x
UWo98vhli9nxrHaTE5/4Nse7A67PcQh0nALn5r4mHI9wpfPN3jbkoCq5CXmmE1zeqOe3ByXuGQR0
mAMfOMHypbB9lVug+RwoOc2Rr3jA21/8RIc0veHnVBuMj4zKoyXsrc6C4bnbuLgHMW0E/s1uu4tb
E8NGtsiZbYbfUx8Uy1a3FmrxbE4MHeCU9qYeSk1+FiSimcZYxKkNbkkCHGDGDnNFWrgwhvvqXlte
JjuY4dEtc6zFDNXxxrlwTCAK62NcvqgKuwlNXohcS6fqcciFFWuSlByWJS8ZrExq8mBxPGATGjkF
k4kyD6Uc5Skrkcp6rBIjrcyGKjgJhUACEn3OeGUo14FLWNqxJbQkmipj+cko/PJkNaylynSJkga6
pJjIHKUwcyPDLjYxYoxUpPq8qLs4+IEO18wiBMFZx2qSk4vZfGI3+1DFyq0zd3g4Zzql2L5vhtOW
6/QmOOEJNrqVU56+w2c/x5lARu7u/oTsnJzb0lZMKwLict50JwzNN0V3KnChw1vhFyfaRYbSMJ42
lFhDgddAjWr0hSy8Ikl3h86NYnRzNxyaQdOHQJkacKYYPeZKpxk+Z7owkBz9mkltOk+K5dSWCcxp
RW8K1J1GNKlHhejtfApBjA1TplLFIinRhtTHMfGd+nSfVpkKyp5u1Y4/lepQ99nVXA70nRY9aVfp
CVQrMrGaJaViWOuWUK+OM6bEUypRT7pSZ6oUoU0da1EvetWgmnOxQy0aKdn6U3M2trBLNSxUA1tZ
BhqVmRLMoCB0KtHBWvahNhUsan/J0ZJSlmWOjehmH/jaxXb2sH8NKWCtSlrOpna3ugZULQaretu7
9nOLCd1mXvXJ14wul7FeLJlmv6qNrLbzfLKtIkEZWMe9UvafKl1uPnHLVddW17TwjKxDI8g1zOzy
JO2dpWBwsd7LvBck9XXCfdOyB8Y9Ei/Y9Et+zWI37fW3k5jpXoENXJk+DlLBo3lkgh3cmAYnTMKo
ijCFLSyZCDNNwxPK8HE47GG/iBiHI84MiFUTyRMfJlMXCReMY9wbGdO4xja+MY7BxeId87jHPv4x
kIMsZLOEAAA7
------=_NextPart_D32_06EC_D5640146.01F04A05--




From kevinsthunk@desai.com Sun Apr 15 11:36:57 2007
Return-path: <kevinsthunk@desai.com>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hd6me-0005FN-RH; Sun, 15 Apr 2007 11:36:56 -0400
Received: from [125.110.247.55] (helo=desai.com)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1Hd6mb-0007bw-2i; Sun, 15 Apr 2007 11:36:56 -0400
Message-ID: <9cab01c77f5a$8ca7f470$99335af6@kevinsthunk>
Reply-To: "Lucio Berry" <kevinsthunk@desai.com>
From: "Lucio Berry" <kevinsthunk@desai.com>
To: "vergie bradley" <sip-archive@lists.ietf.org>
Cc: "doreatha bailey" <dnsext-archive@lists.ietf.org>,
	"margrett bennett" <mailman@lists.ietf.org>,
	"lanette hughes" <ospf-archive@lists.ietf.org>,
	"buffy lee" <kink-archive@lists.ietf.org>,
	"tracy elliott" <foo@lists.ietf.org>,
	"jena reynolds" <l1vpn-request@lists.ietf.org>,
	"valentin" <p2prg-archive@lists.ietf.org>,
	"maritza owens" <rfid@lists.ietf.org>,
	"loraine butler" <wg_acronym-archive@lists.ietf.org>
Subject: How is everything going
Date: Sun, 15 Apr 2007 12:35:28 -0300
MIME-Version: 1.0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_B06_0DB0_90047644.314D24A2"
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
X-MimeOLE: Produced By Microsoft MimeOLE V10.0.2616
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503

This is a multi-part message in MIME format.

------=_NextPart_B06_0DB0_90047644.314D24A2
Content-Type: multipart/alternative;
	boundary="----=_NextPart_5C4_2EA2_C43E2D25.7FACD61A"

------=_NextPart_5C4_2EA2_C43E2D25.7FACD61A
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable






homely frantic Ah, reverend condition sir, irritate cried Caderousse, cla=
sping hisWell, well, said build Andrea, were that past isn't lift a bad i=
dea. I have crash box told you, where the air sling is crack pure, where =
eveO doctor!
crack stand I swear respect to tasteless you, on my honor, said he, to aw=
aitBecause the person prison who minute shallow dislike is now in the gal=
lery pref 
My tight  friend, said Caderousse, eat pain sit swept of my brea You bewi=
ldered mean to forgot cow say abecedarian you have been freed from confin=
em But, seal said Andrea, protect soothe why do you not act branch on the=
 adv modern I would fiction swear iron to it; what creepy I heard of his =
symptoms
You violently are forgave right; and she is one of detect love the greate=
st inThat is tame right, grip said ball give the old man. up license Not =
even cow before condition you, Philip? Then who loads his p Now, said Mor=
rel, doubt do lucky whine you spring wish me to retire?
correct cute Alas, stammered Villefort, I do not ant delight lose a sing =
shaven Yes, that gold noise doubtful is true, reverend sir. unexpectedly =
But how hit the devil would bag you have expect me retire on twe weep pow=
erful impulse Who rich was your liberator? It digestion is trick brought =
let a poor lame post-horse.
Yes.hold sew I thought so. under But how did it earth happen that such a =
g How stage was metal force it that Dionysius the Tyrant sip became a sch=
 His servant.  A Nubian?
But brightly where steam are milk damage you really going?In chiropteran =
what state delight occur was the leg house when you left?payment M. panic=
ky burn Noirtier, resumed M. d'Avrigny slope in the same pi Ah, brave Cad=
erousse, program said Andrea, ship how ripe covetous you a
trodden Oh, shone produce baby mercy, M. d'Avrigny! To sea, viscount; you=
 know I am potato cover memorise cerotic a sailor. I was r An Englishman.=
 stride trot Let helpful cystic us go, count. All pleasure was quiet, but=
 on returning cheese veracious stuck from M. Beauchamp ornament cerotic w=
eather ill And is her name a secret?
quality annually slit Without goat seeing Mademoiselle Valentine?As cysti=
c greasy regards the generality of mankind ignore it like is; but nA negr=
o. Yes. laid Certainly; on spray my plant leg word of honor.
The interest appetite grows by fly organization what it run feeds on, sai=
d Cad met No slit auctorial mercy, slid sir! The physician has a sacred m=
ission  exactly build Have mercy on my dealt child, fold sir, murmured Vi=
llefort.
mist bumpy What chop cytherean was his name? Yes, hilarious flower produc=
e my mother, said Albert, leaped I will return, and To sea? rub Why not? =
fragile Who bruise transport formed the plan by which we left the He went=
 back to foot bent the room where spill he had weakly left Monte C unpack=
 guide You know eager the inject history of the pasha of Yanina, do y
------=_NextPart_5C4_2EA2_C43E2D25.7FACD61A
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"=
>
<META content=3D"MSHTML 10.0.2616" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><FONT face=3DArial size=3D1>
<DIV>
<p><IMG alt=3D"" hspace=3D0 src=3D"cid:f10f901c77f5a68c72658055b770ce@kev=
insthunk" align=3Dbaseline border=3D0></p>
<BR><BR>
<DIV><FONT face=3DArial size=3D1>homely frantic Ah, reverend condition si=
r, irritate cried Caderousse, clasping hisWell, well, said build Andrea, =
were that past isn't lift a bad idea. I have crash box told you, where th=
e air sling is crack pure, where eveO doctor!</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>crack stand I swear respect to tasteless=
 you, on my honor, said he, to awaitBecause the person prison who minute =
shallow dislike is now in the gallery pref </FONT></DIV>
<DIV><FONT face=3DArial size=3D1>My tight  friend, said Caderousse, eat p=
ain sit swept of my brea You bewildered mean to forgot cow say abecedaria=
n you have been freed from confinem But, seal said Andrea, protect soothe=
 why do you not act branch on the adv modern I would fiction swear iron t=
o it; what creepy I heard of his symptoms</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>You violently are forgave right; and she=
 is one of detect love the greatest inThat is tame right, grip said ball =
give the old man. up license Not even cow before condition you, Philip? T=
hen who loads his p Now, said Morrel, doubt do lucky whine you spring wis=
h me to retire?</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>correct cute Alas, stammered Villefort, =
I do not ant delight lose a sing shaven Yes, that gold noise doubtful is =
true, reverend sir. unexpectedly But how hit the devil would bag you have=
 expect me retire on twe weep powerful impulse Who rich was your liberato=
r? It digestion is trick brought let a poor lame post-horse.</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Yes.hold sew I thought so. under But how=
 did it earth happen that such a g How stage was metal force it that Dion=
ysius the Tyrant sip became a sch His servant.  A Nubian?</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>But brightly where steam are milk damage=
 you really going?In chiropteran what state delight occur was the leg hou=
se when you left?payment M. panicky burn Noirtier, resumed M. d'Avrigny s=
lope in the same pi Ah, brave Caderousse, program said Andrea, ship how r=
ipe covetous you a</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>trodden Oh, shone produce baby mercy, M.=
 d'Avrigny! To sea, viscount; you know I am potato cover memorise cerotic=
 a sailor. I was r An Englishman. stride trot Let helpful cystic us go, c=
ount. All pleasure was quiet, but on returning cheese veracious stuck fro=
m M. Beauchamp ornament cerotic weather ill And is her name a secret?</FO=
NT></DIV>
<DIV><FONT face=3DArial size=3D1>quality annually slit Without goat seein=
g Mademoiselle Valentine?As cystic greasy regards the generality of manki=
nd ignore it like is; but nA negro. Yes. laid Certainly; on spray my plan=
t leg word of honor.</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>The interest appetite grows by fly organ=
ization what it run feeds on, said Cad met No slit auctorial mercy, slid =
sir! The physician has a sacred mission  exactly build Have mercy on my d=
ealt child, fold sir, murmured Villefort.</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>mist bumpy What chop cytherean was his n=
ame? Yes, hilarious flower produce my mother, said Albert, leaped I will =
return, and To sea? rub Why not? fragile Who bruise transport formed the =
plan by which we left the He went back to foot bent the room where spill =
he had weakly left Monte C unpack guide You know eager the inject history=
 of the pasha of Yanina, do y</FONT></DIV>
</DIV></FONT></BODY></HTML>

------=_NextPart_5C4_2EA2_C43E2D25.7FACD61A--

------=_NextPart_B06_0DB0_90047644.314D24A2
Content-Type: image/gif;
	name="evnoafeqeg.gif"
Content-Transfer-Encoding: base64
Content-ID: <f10f901c77f5a68c72658055b770ce@kevinsthunk>

R0lGODdhcQEtAYQAAP///wBm/wAAAP8AAOHe2P+vr7/G3fbevP9mZv8/P52u4HWN1Gd0n7y7rLWl
koaPp/PNisaLUqN2PJxaKVpSWumqUOSVKOVRCTorOwAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA
cQEtAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt
er/gsHhMLpvP6LR6zW673/C4NkCvB071tj1f4svxfjGBgX9Pe4QAiHMsh3R9joUkjXeCkCKKkUp8
dmaYkpaDlpF+nimlmU2koomieyaur5yflKy0kyOHK6q0tbK4ub93rbmIjbGhtquzj7y3y8GXxszK
qDPIz9Gw2b693LvBwMAo19vazuWzk8PS5aDuvMzx4Obr877n1TTk2dD8tf3//AUcKOubrnfpBB4D
N63XQEDJIv5SKA+bQ4L1tgk0mM9axo3FqCk0uI+jKXwm/rshlLdJmbRSkDyFbLbyIceW+DrC2EWz
Z0qLOAFipHSqHbyh9n4GDSjMGUyiRy0+RDqyJk52OnfWpKjRZsyMJkmKrAixX8GPuBL54wmypz0V
hOJa/Sg2atZKEd22bQv1q8SLVKeWPfk38My1dOe+GwtQbuGSioXebaGOLFaU7CrvRUcYrmJxh5mu
E6dyFbdxWDd7fTy66ORpp6dqmwfRZZ7EPj3bVe1QqV+KnBxTc825YtjI6Xa/Xv6aOPPn0K/Mjk69
epbY1rNr3869u/fv4MOLH0++vPnz6NOrX8++vfv38OPLn0+/vv37+PPr38+/moD//yUhgAgDnlBg
EQcS/pHgEgMMcIKDI0D4AoQSCtHghRU2aIOGImB4IQkcAhCiFAkuaIOJJqBIgoorisGiESN2KGGM
LFBYhIch0jhhjjjO6GMVC74Ig5AACEkkkVYgaaGDH/booYg/RtghlFLKmGOEH04pI4hRUmnlj1l+
iSWXZOpo5Zg8eolDkCMAaGCRB7oJp4lyttlmgEXamWKAceaJJ4F/tjhgoHrmOWehBQ4qaJ+J4tkn
gYCW+KeiWDoJpZMcjmhjppx2KualW44Zqpc4fhkmk12qeSYKT17aaZg3sGnorHdC+iiddiYKqa27
vjnroLr+miKcvSIq7LGEOgpor5QKe6uehGapYZqk/upoI5VNUogqqltmW0KPopIJarVqgvutmdlu
W+m4a5YQLK3MIjtsi4ay+SKj8R4raKH7yrsrrv8a6+fA8PorLrZRZlihlmCKSC6TDzscY6nhujrq
tNpWCuu6D4KpcMUnupsvvQTXOy+0xR6aAr7IAojroyK/K3PKBj+raJyBukxzmtRSC6KW2EqcMcSc
Sqzq0eFifPG2GIa6MbvnovnxqLGKrK+xz1qNMrzvnkxp1ig0i+LXW5us9cwB3zwvwAcr7TTGCzss
95mwpsululF3/PbSrtpNNcIdq6sp3DqUKDDJYtPM8sxda/1rsDDnyi/iZTde8+Ewo20iz+mamynQ
/nQPjnfoGSP9dtPlLuzzqV2+WrrGZsrgcpCE5ltn7XLKrGzAK2ZO7J1jX02yypFarnOxdV6dfOJ5
V6utt06DnnrbU5Nreurc+sw3x6v7mGq3cUdy7+Q7KLlG7Otpj8r4NBeeD/rqmftczj7UXgj88aPe
3/789+///wAMoAAHSMACGvCACEygAhfIwAY68IEQ9IFy1jPBThywghFUCxHUwcEOevCDIAyhCEdI
whKa8IQoTKEKV8jCERYBg/2BIQRlaAMa6seGDcShNS6YQUa8kIc9hMsPV0CAIhYxPzpcYBIFoQIj
OvGIVevOEt1TgB5M8QW7MYAWi6jFLhqAAC1w/lPypJiCJ0JRBGCMgfmgICmcrXEFB0BAAhKAABEg
oEF1LEEc5ZjHAiBAjpIYYgkIoIBCGvKQhjRAGMnnhirugBdmjOQTw8Yn+62JT3M63gwmJbn2zSAB
AKhjHf0IgAMMwJERcuQpSRlKUF5CkCMwwAJmScta2lIBLLiVGxs1O0eNMWy9c+MO4jjHPN5xAHks
wR8T4Eg//jEtI5CkNBUJTE9GkViQowHzSnazMWIyBQOI4whQScdvVdGUACgnAAogoSu64CgKYIA8
5UkHBiwgAPO05wLSqAJgVU5e21yZ7yJnA1CKcp11NCUq7XhOBx3AleqEpDTN2ABq+qpejcJo/i95
aTh+vbGazsoV2f71oju60pwlYKccD5DOPrYTliKIJz4ZUE96zlSe+8wlrdposEitYJuJA1aymvUg
cYqAnMnsEEtFVABW3vGV0fziRIvYAAfw802cZJnJAvrLgm0Sa51Em1dJYNKlHvWkJGBnAlh6R5Ym
4KUbNAEBHnDTfNqVAVbVaUeVpUmcWZNyvLLVSDGqApM+aKHoFAEd1clOqEZVqpGsagOuilXEfdNs
wDOQrK6p1ZH6bgVylNBDT0DKt7p1AMWE5hCiQkiaTkKeeV0kvbSKOdmGNLBiFVJZ04rWdUposS51
bDQJsEUnGsABDviiXhclWE4ua6fD++hF/jtrNl2yoI6ntOMJEiuiZHJXg6tNgQFsagcGPMCitj3U
RnWWu9npNF6LGxmRQjuC0ab0t3w8KoTsQtwG+LeqyaVsP2PWScDuNHLSPRnxcse7ZZU0lOnUroRZ
2ljFOtKUZgWvEFhLXAM8wKawraiA2/VXFww0rLabL1MlrMff+tGVBXDlbvqL3AAPKZjrFaMv+0q8
HpNIBcj8YxXfeqEqPrWVzrQjAjKs4SAcpcNedMADHpBcL474RF2VXTAzW93ejVW7dXRlMvO41Ow6
LMZKFu5wJ8oDgqJBkylgZQrMeoACMPkVMEXjVJ3oHyD/EQFDxpCRIRRjPzqSmWhWMwCu/rzmwmUZ
FXe+gTspwx04o0DOKMiwnUlQ50AG0RR5Pk+kazDpApZaF0D8NB5CDcBTD9DVoFYPrJusatVuONW1
9vRqW8jrXvv618AOtrCHTWwRsvp/s271sdF4gGaf0T4zliQDk43nMgIYuQ2AAKPdw+GpKpDafUiB
f2vsgP9OFtomgOw0lYtrJ6NAstf+L3K3HbLnwAPKXsy3ldsNhKhAIAISkAC2qxqBCNTYxJUcW4Kr
sFAcQFKLCsh3xL04cfRu+dHyAbeuSeCACFC54x2n8rXpfTgFj4GY6jxmUkewzGb+2daEVMACCjlz
RCZyiyBdeD4aLuk8H6DgeW0AwK1K/gDkRqABJkYUg31ZPGwmncs9MCiESalQZTa0lBDNIy8MYPOu
I5LRRGWvP5teSQEhAeXGxOMJWn7Ulyv6B08u+NEX7XEwCh3oLxh71gbqzyN9lgfhTCZSv1XmpqZd
uA3wuuIVsO2OEpabgT2CJYEg9VEmNG6ALqVDs/52CcpV7hEAI3FLKXeB551ruzsxZoH5dz8tj6go
MKwJzCwC7gJXv8KV5SFnKXNbznyfjd9TbvmKBNhj9fVfJrzgR6DOCBXeqfvNMwFK7wASALzgE6h+
0v3aZfg2eMAjc3p1kbTbcfa2wi1lbPRj+QDfz1KftrQ4gZ/LOLEWP5eefe51UXtY/k7jV/2dZ0Wf
F3ABR3QOQIASQAFId3oCozn5917KwztuFntvVV+95VvMl18YqGEE0ADu53vy9ABg90+3tVVK4Hfd
l3zKhFqadn7/F1y0Bncn4AATUIM1KAE2OAE4KAEkF105NilC1U1HUnLZJDwpgF2OtHK152LPtE4y
NkhS9oHvZ15gl3CZ5F4/OHaS915FqILKVIG1d4Hod3sbqHG2Fk04mINqSAFf0HpFmFGgBWFixnK1
1yGq5IRpRmsd+GF3NU+xFQdD2H2Tt3YrBmEmYHtJhocx6Hkn0ABpqIYTQAEi6AU8NVvMYnyz92eB
VmShRGjMlHnp1FQn9WR7yIf5/vQAEdeDZhCIuuOFYBZhhmiIhTclidaEZvh2HXiAayiJfyg+LYBp
25VWGdZpZ/hEBuBfhVRR6tYdShJkmUdkDTJoZ2VoFpZoiyiAckVVUjZlU1ZuRvQHlqYCo6YPJLBn
kWQd4agCwHiIwshpC3WLMdhszvZE8vhs8CFR5shn7DGOOxRXZVRGqmge8Mgf8HiLA+kGB3lDy9Y/
CYlEL1RsEBmREjmRFFmRFpka/cZvuVaQGllrHGlADYkfH2lquVZt4QWSJRlu/niIBwABLimPCrld
8thsMxRqLnmTOAkBNJkdPFdDhwgBFRCUQvmS/AiBK0NBeXaTQwmUQXmTO1kD/oHYBWhnR2pnAmyH
UE3YZEBpAVzZlV3ZlDqJf5joZWGESRt1ScI0BD1JajBFAEAZARWglEI5ly+JcGOpf2gJdTxQeQil
eQ2XeehkXxHFaRXglYZpmE05atwHfj9VK2WjTQWmc3AkRylXlZy2TH20TGeYkSTwlnE5l6AJl0JJ
cosJUpxlhDgQeOOUgYRnh9AnXBBwmLKJmBBgcnp3O7/TY47nimoUgXB2WSzAl1RHe3bomsb0hCu5
aHc3l6IpdxUgms+5gEfJXJlEUj4FmQhWnbUyX/w3e4j1grgHXgdQmBYQARdwAV0ZAVxZcIZZcJSl
IkAlgVtmcjnAVQ84iMq3/pqKtXLZhU4AeI08AElCJwGgV6DOKXfSaZr9glmDpWUIdp/kx4K8dV8Z
+J+0MJ4Fd54Zep4XYKDmOQERYHHwCXWQwyLJ0gP294aMFHvdiVJphUxr1VLhOZIicHcE6KGgJ3D0
NqLXySg6l6LyWWIsB4ZYZwJjqIEVRgsEUAEcKndN6qQXYIM66jhbpTlkiTzDQ2IRmIJrVH5nRVoS
2lbptH4nGUs4WqASIHKkaTV6J1/S5YZByptIKI5M2EfIiUbmyaF6yqFSSmXsJlCRt3fIk53uQ4RB
ip9WSaT2lVJhFk5jmloA+kiDNKAIiIBTNlkByX3ME1+9aaiCqGJhxmJk/lacZyZmWjdIEQCJOZim
AdZ47XWWveRjQjWfsXI83tRgwNkCcxqL/hch3gVXZRpNUlaprHpusvOqOXaFH+Vesoqrd+mrQjam
nHhkhQaKiDaKcnWAj8iqNuYd5nNQczhhGxiKS2hWNFp7EHBt2EaUT+mLLLCOetSO9fWO5bhoVGVu
+qgd6QhOmiit0diJdvSJxrRkG+du5TiTCJuwzgaIGBevksppMCmTEbse8Mpp88qP5+psCruxRXke
IakdHbsTPsexCjsfH4tuyflqKVmwnEmSKxuAAdqRqnauAnSy9VGQF5mzOruzw1YaPPuzzvGyMBtE
NBtAMPSN07aQ/HO0/kj7bUq7PxV0jk6bsjVLRNKmpc+xluRIteehtf2IAv11tUbZhog6TJTpUshk
pG8Vo75Vleeaj/k6BD9Kq2YLqSq3dnLkclk5Y8eobl+Ec425m1gwgT/AlxHGTkzGTGN6VE2FSjQK
t2b0dP0kmXtScjkgnJf3l1cnmKd6AlSlbkZ0jGu6S2W3Y31HuVp2lL/5rCBiVK2ZVuHJTBk2kpAr
tQMWlfWpL4azuiqomkfFmq1rnFTZeVMlusvVgAxKf2YHqNnUsCzXoiyntWj2UJZJu7U7SYG7nWQD
hD2qhdPlURAKWtCbSr26n+V0SmRajk2rZ2ErloAVdrvDm4U6nV34/q0SSpWOegJsq1+O9JHXa1zy
NyyS4nTxu6mWU1tbY38sur+KOE7gWYaeW7zGOp0tg1v1u4WNyaUwQF8kMEdrx3O2OET/G7oB7C70
Y4LwhZvWBKcafF1otagOXKEw2G3TNME5h8CXgyCy9YZdWogBa6Q9CYr+O8IdWMIIrCuqZ2Be41GH
Sn6FqISax3yJmGjddoz4ykU2LHwqE6uPA6tlW6sYV7+sS4ehSoyKW0qMy7hmvJkyuGigm49VtaPI
C3mBGn6Oc6sMyrrgKqp1WIgOUoudO0gdiKlmZLyV5gLOWEUqVZlt+yEqRbBDqwNKam6UXMnydl4/
ZYVipKzC9Ko+/oaiK5DI/ppd1PqJhyaKm2lEhPyN9xqQ+bCvl5ZUTeWwpMVkj6uu5JbLNYapDFu2
FVtf8lp79Kq+VixJkuXK3hGyWBRqcFsdyvxOgvxfkeVfyLwfRatsgmzF+Ra5MhuzKJmN5ohA14xs
LIC960tA4+w/OmSP6PyQQPvO8BzP8jzPmhGsEczNNyu0kSrJAClNKPuy1xzO9GGzA81qe/an8UHQ
JsvM5mjESCm0NAu3WbwcXisDCq0gWRHR/aVF/yW6mNqLQAKEO1a3lZm2sZdU3JVszPrFd1HRTES1
WEzN5nZcWpRcg/uYhCsDmOuXYJpURIpBYnvD8ruiCqJjt+O8/i0wlW2rhHuUcn+UvxFtxZZsbphs
l0PdLpslhLSTfL67TsCbUs3XVMDax4MEuhXFmEjcybdphdVZutqbm79EqEIKA4YLSojroqskZnd6
a2Wtb/omZapYmkJguimcvLm5duNLqmQlo+sk1rY2apJk00JNfIIVp0jsYAZcx6ZJUEHoZS/S1cEL
Ild3ZCEM036dbw0wZYE9W0wHnLBMwXV8wSXmpekkhm7VR+PKCxy7jR9GAb5NAQwgUM7lepssgbZq
iZfDrCbsg61t3IWV2KD4oiulWHSUTEUr1VN9qXl3woT1TTkN25An217IwUWqR4d2ULndmTl5kxKA
Ae793u5N/gFXxjawJ6h3jKveB4EjqqKzfb+dmL8vur9vZd3MPNX+9WGTqEZWunpIXYJBhd+HHXtP
TFpzRGQxVuHdeaHrzd4Y8Nu/3eHzvcTUZdh7ZTuRSb+qa9kuvDAenFaN6lZ1ZtIBPXCXTIU3duKf
OtfXuWCpN6jJt8exOKodLMtjDZY5mYAe/tsPQEk8ZdTqpckjzV5PLnazejYpw6klel0+3Erl211N
mKTH5mHcOGUMANwOrVk4zt9XDcr8Gq3QSMoVolYXdkeBvGgdB5oVgORJnuBuoMIaZdnPusdmfGHj
ykwWemzExdvdCLjbJ9I+NatcLHnO+8tkTWn1NciUrMvY/lbNd/HZ/brIh4dkz6RQMbZUAW2MoGsd
z2zpVhvU6DjpstxwdLZp4zTM9rxm3rbQLeDP++jNt86+uZ5x+jzO3sbp4XHRCf20MTTsyk6QzL5B
9Bzt0j7t1E5szW7Nz/7reiSPtSmS2c7XEtuSTnkAxi4eyjGeXlkBq760rNZsG36T5Q4eu7GVeN7t
CVS07v7u8E4dLv3SJlCYeB6UFqDu9x5q4q7vLpmg9QMGSr2EFN5w1Ph2AE+eslkB8W4d/b7MVHvw
CA+UPdjgbebo9BkDhqtY4cNOC5WVinYAs3mY9m4EqIsFSn23eoSZbQdIkZwDR8GURr7hFaDw4H3j
qUvH/oDnuowbPj6s8opG8S3flfMt8gp+gnTrAztddaItvFy+zzqvRzwf8GBpAdo3tlt8upzMUccL
XbzLnWjVuEhvZijffE0WR3uqp1yJnlz58suNl50q6ZZb9Mu3nyjlnzMMUy3p9XgO9pJr4mCjNkJq
nzm+f2yryG2fhKvUovBwAHOf+RyK92QJv53NvWsd8/Pnm8hnvxe45b413YeesuNp+KEZ9hkMPJRt
2HrpK4Qq3qBVgTDonYCf3p2p+ZoP+wQWn+FL9Asfft5tnS9A29YY4GzlqGD4tq4/lxZgeulVMJuq
dH/FwrhfWExV4Wvbf4yNfpcP/Jkv/PsiNlJOgmn5/gPcD+HLr6inX1rQj1qDSbWxOf3POQFnDlbI
L18gAIiCWJpkiQLqOrrtypozgACJWQzlYQ6FqIADFGyiwOyAuDCbzmeDlmqRVDIWyuoSZKXe71f7
enVhZrDJ9hMZkzvRoH14A5DoO95uglj6/r9FhcXEAwEeF2IW10nKYuJiTKLU4wjkFIxV1V0cAgKQ
iFJcDZ0OQs+N59ARTcWTq5NBGNklFSNmlxierq0Z1uztro3NUJtRj05Jwufcad3uM41eCYEDoPWF
RCz0Nnc3moxXEVqz1MFnibQIxOurg+GkY2RjFSRiZeSjvTcYluVv5hk0nDzdGGBwDYI3CJR1YmPK
/kS6fWAiAqBmrc+FCRIavJPo8aMXSbrIfaTYil2TCNpAsmzpERwYcWCamSM5g6JLZ1IIPJAQ4WeE
jBrd5Sxq9Gi0nUFRSiCK9OlRkc9s7sPpEucBCA4kTOiq8YEDCFShki2rCyc1dhGcmm3r9qjVllgP
0AXQ4K5Yugc6vu3b1yoBAw4iSCjswMFev4oXe4vLkqLeyJL1Mq4MNe7eu3cN8LXs+TNEso5ngi4N
cu7kyKZXMx5dkjXstq5j0148W2KA3Lp38+7t+zfw4MKHEy9u/Djy5MqXM2/u/Dn03XVu165u/Tr2
7Nq3c+/u/Tv48OLHky9v/jz69OrXs2/v/j38/vjy59Ovb/8+/vz69/Pv7/8/gAEKOCCBBRp4IIIJ
Krgggw06+CCEEUo4IYUVWnihWQcdhCGHAWqoYYch7gciACR+Rwc3H0qxIQ0s+oCiiPa5WKJBJ9bY
zYc3wqHiizPqGON9M4on5C4s+viGixvq+COQMpq4oolHovhki0v+qCSTJeTYY5Y97kiHkVbuOGaT
+m1ZJY9JXskjlGCueeYMcOYIo5c0uomkmFiWOSKcX/ppp5ZW4knnn4AGOqgXUh76hZyCHlpjl3s6
SWWdNBaqJqGGaoppoo4u2qaihRp6I5GSzkflnIFeOmemnK7aqqeivvjqp1V+Gamp8EnJJqRv/vZZ
66axxilsqWHeKauqgOKaq3lCunqkptEyKuixyEaLKaHGflqsm2Qyy16Ub4rKJq1oAqttm1xaO6qn
Xa4p7bfpsTplquoOSy6X5LLaKbalPsrkr5bmG+97ASsLcKT43rsDp5Tae2umD1c6rLkEWwzsxRl3
56/GHVfHscchswayyCWbfDLKKau8Msstu/wyzDHLPDPNNdt8M84Pzrszzz37/DPQQQs9NNFB21m0
0UgrvTTTS/e1bM7MQu1SxFFbPLVHWFsdb9VZb62y1tt0/bXGY0MTNtkEm11k2i2jDcbabZfttdxu
SxT3LpS8VQYNMPX9WcJaii04VH2+TfG//mJ6axreLebkC0t+zyD5GJH/DZK7eA4OB1n1CpyiryQq
PjKORV1h+R2UB/QROKo/0+ugW/Y6K+ecL/ko4Ufn/q631Kq6K+29M1y1mp/PTnXpj08+zyQxnFCP
P5WIkQnfklfPvDzMT+889gtjmWqjuwtsLKK6sxu84md6Pnzwn8M78NGxH45H4yUadXovfZex/fL/
jKHJ6mzBP0xcbnr7o8W2NGc82K2IcAwk1fDYZyk95Wt0yQrTmEKHsIh9L1gRLEr96qcL/OWCFtdb
Xet+MQXVnTCF/avF/2KIuPEpcIGOq90E7QdBHdKQhxs0kvtE160dJq5iUPodvZKFvLPd/q9/JZTh
ABHov+exUIbZQ+EKTSi96Nmwh8K7of0yqEPNMayHZURYp5D4xfWVD2Pok+AXcxLCJgpQivm7owvr
GBC+Ne+OeuQFAPEIt2558WB0ApOXFKXILCVMgUScYPgWdzxzUdBPJEve6+hoxTy28HIE/CQMKddJ
FSKwHyoER/rAx6sy4tCS4lqkI6cFsRqiUYkYjGP8Fhc/EW5ic4+TivT62AtLcFEfoNRHLvCHj+5F
j5iM8Icx37goPb0LkdK0ZRLJ9MgZUpOQSgziJC1YPIrNj35M3I8WXPcMyB2lnAmyYEsax0v0KJN1
vDCKOxHkuSWy7T9c9EYzn5JPfToM/nPnrJvM5InQmSl0oTFrqENfBtEAygJ1L7Ro5NTZDY26haOW
8ShSQBqng47QjvuAiUhT55KUrhM0fGTNE0EiUpa20pwtrdxLhIlRe4bUpThdTUx5elNM6gJFuLhC
PbgXTHiYsqlbWCpUr7jCfqRTf9R7oSLYiYvlOTOrWiQDMaEZQHvQg4rPRKlSARjNtTYzqdD85xXL
GteuYjWquZjjJZIKyAP+lH/O5J5ej2nFewhWqV/F4lM3SdjngRWKWqzq/6xH2BMCVn+NFeQpscpX
xAKjsJ3VYzJpgdfMAjKvJjWtYv34Uor6EbV1/WkoD7tazKq2Fi8NbUUHiNvS1paz/p7U7W8dK1yu
HhaGNbUpaWUbTJQiU7nDNCZbOTmP2e72mcEl5Vd3q4lAIlMqooSid+2oW+++VbpgjeYWR4kP6oZ1
rWcYrWdT+93kArei96QtdYubxd6Ckrfate3f0Jpb1/LWv6ft62v768nsirePszVuGDPpWmXWV4D7
wy2GJ/xaRcC2ugXO8HWrG1TuHriw/53cZuv7RBBzVr1RRO2KR0pSyk7WhHCNxxapyMfomhXFb1Vw
9yhKVR+z969RbS10xdpXEtu1wUaWKo9RvMkbG5nDUBXwLfIYYZJOiKaf8fIhAsQCXs5TQGD+6FPO
nB4VlLnM/oFrf9RsHn+42c0RWQWSne185xDp2X17nhtL+vxnCQ0UjIPmGj4FfWgGKdrQi25SoTfR
6EcLaNKDpHSHIi02hZHN0vgxmF+aJupRk7rUpj41qlOtaqFhutWufjWsYy3rWdM6PSEAADs=
------=_NextPart_B06_0DB0_90047644.314D24A2--




From sip-bounces@ietf.org Sun Apr 15 20:27:35 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdF3v-00068f-Ue; Sun, 15 Apr 2007 20:27:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdF3u-00067q-TE
	for sip@ietf.org; Sun, 15 Apr 2007 20:27:18 -0400
Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdF3u-0005n6-C6
	for sip@ietf.org; Sun, 15 Apr 2007 20:27:18 -0400
X-SEF-Processed: 5_0_0_910__2007_04_15_19_33_52
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com -
	SurfControl E-mail Filter (5.2.1); Sun, 15 Apr 2007 19:33:52 -0500
Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with
	Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Apr 2007 19:27:17 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Review of draft-ietf-sip-location-conveyance
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Sun, 15 Apr 2007 19:27:16 -0500
Message-ID: <E51D5B15BFDEFD448F90BDD17D41CFF102C39BE0@AHQEX1.andrew.com>
In-Reply-To: <461FA7F0.5000706@bbn.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Review of draft-ietf-sip-location-conveyance
Thread-Index: Acd95DLqnOOCa4SzRYu1qLYQdsnI3QB2XFcA
From: "Winterbottom, James" <James.Winterbottom@andrew.com>
To: "Richard Barnes" <rbarnes@bbn.com>,
	<sip@ietf.org>
X-OriginalArrivalTime: 16 Apr 2007 00:27:17.0976 (UTC)
	FILETIME=[FD5F0D80:01C77FBD]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0770535483960d190d4a0d020e7060bd
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Much of what Richard says I think is okay.=0D=0A=0D=0ABut please, please, p=
lease don't re-open the can of worms concerning the=0D=0Areference restrict=
ion in the ABNF. This issue has been battled to death=0D=0Aand I think that=
 the document clearly describes the outcome on which=0D=0Aconsensus was rea=
ched. The text will provide restrictions but the ABNF=0D=0Awill not.=0D=0A=0D=
=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D=
=0A> From: Richard Barnes [mailto:rbarnes@bbn.com]=0D=0A> Sent: Saturday, 1=
4 April 2007 1:55 AM=0D=0A> To: sip@ietf.org=0D=0A> Subject: [Sip] Review o=
f draft-ietf-sip-location-conveyance=0D=0A>=20=0D=0A> Draft:  draft-ietf-si=
p-location-conveyance-07=0D=0A> Reviewer: Richard Barnes=0D=0A> Review Date=
: 13 Mar 07=0D=0A>=20=0D=0A>=20=0D=0A> Security / Privacy Concerns:=0D=0A>=0D=
=0A------------------------------------------------------------------------=0D=
=0A> 1. In the first full paragraph of Section says that if an emergency=0D=
=0Acall=0D=0A> using TLS fails to complete, it MUST be retried without TLS.=
  I don't=0D=0A> think it's the place of the spec to mandate UA behavior in=
 this case;=0D=0Ait=0D=0A> should be up to the user to define their urgency=
/privacy trade-off.=0D=0A>=20=0D=0A> 2. In general most of section 6 is eit=
her out of scope or true in all=0D=0A> contexts (not just emergency service=
s).  The only exceptions I note=0D=0Aare=0D=0A> the explanatory text at the=
 beginning and the requirement that S/MIME=0D=0A> MUST NOT be used in emerg=
ency cases.=0D=0A>=20=0D=0A> 3. Saying that S/MIME MUST NOT be used for eme=
rgency calls rules out=0D=0A> that security mechanism when UA itself has qu=
eried a LoST server and=0D=0A> contacts a PSAP directly.  Is this intention=
al=3F=0D=0A>=20=0D=0A> 4. In Section 6, in the second to the last paragraph=
, it basically=0D=0Asays=0D=0A> for an emergency call certain policy flags =
"SHOULD" be set to "yes"=0D=0Aand=0D=0A> that if those flags are set to  "n=
o" or are not present then they may=0D=0Abe=0D=0A> ignored. A GEOPRIV "usin=
g protocol" shouldn't dictate that certain=0D=0A> policy flags be ignored f=
or "emergency calls" -- especially since=0D=0A> emergency call marking is s=
till poorly specified.=0D=0A>=20=0D=0A> 5. On the other hand, if you're goi=
ng to allow certain policy flags to=0D=0A> be ignored, then shouldn't setti=
ng them to "yes" be a "MUST"=3F  When=0D=0A> would an entity legitimately s=
et the policy flags to "no" in a=0D=0Asituation=0D=0A> where intermediate e=
ntities are allowed to ignore "no" values for=0D=0Athese=0D=0A> flags=3F=0D=
=0A>=20=0D=0A> 6. The draft's stance on multiple locations seems to take an=0D=
=0Aabsolutist=0D=0A> stance on multiple locations.  In particular, Section =
3.4.6 allows for=0D=0A> multiple locations to cause a call to fail (which s=
eems dangerous to=0D=0A> me).  This seems dangerous in an emergency context=
=2E=0D=0A>=20=0D=0A>=20=0D=0A> General Comments:=0D=0A>=0D=0A--------------=
----------------------------------------------------------=0D=0A> 1. The dr=
aft says several times that proxies cannot insert LbyV=0D=0Abecause=0D=0A> =
they can't modify bodies.  That seems like a small reason to remove a=0D=0A=
> potentially important use case, and it seems to contradict the fact=0D=0A=
that=0D=0A> the ABNF in section 3.2 allows for the use of "data:" URIs.=0D=0A=
>=20=0D=0A> 2. More generally, the looseness of the criteria for allowable =
URIs=0D=0A> could also allow for URIs that convey LI outside of a PIDF-LO, =
either=0D=0Aby=0D=0A> reference or by value (e.g., the "geo:" URI defined i=
n=0D=0A> draft-mayrhofer-geo-uri).  Perhaps this could be restricted to the=0D=
=0Ausage=0D=0A> "sip:", "sips:", and "pres:" defined by this document, plus=
 any=0D=0Aspecific=0D=0A> LbyR protocols later defined.=0D=0A>=20=0D=0A> 3.=
 Likewise, I don't see anything that says that the body part=0D=0Aindicated=0D=
=0A> by a "cid:" URI or returned by a reference MUST be a PIDF-LO (although=0D=
=0A> this is said throughout).=0D=0A>=20=0D=0A> 4. Several times, the draft=
 says that it's only describing a "push",=0D=0Abut=0D=0A> there are at leas=
t two places it defines mechanisms for "pull": The=0D=0A> inclusion of the =
"geolocation" option tag in a Require header, and the=0D=0A> description of=
 the usage of SIP as a dereferencing protocol.=0D=0A>=20=0D=0A> 5. The rout=
ing-query-allowed element for PIDF-LO is never defined.=0D=0AThis=0D=0A> de=
finition would be a better place for a lot of the discussion in=0D=0A> sect=
ion 5.3 (just in the introduction, not subordinate bullets).=0D=0A>=20=0D=0A=
> 6. Several times, the document assumes that content protected with=0D=0A>=
 S/MIME is encrypted, when it could be signed, but otherwise readable.=0D=0A=
> In most cases where use of S/MIME for encryption causes problems, use=0D=0A=
of=0D=0A> S/MIME for signing only doesn't, and these cases should be noted.=0D=
=0A>=20=0D=0A> 7. Several sections start out by talking about how sensitive=
 location=0D=0A> information is.  This repetition should be removed.=0D=0A>=
=20=0D=0A>=20=0D=0A> Localized Comments and Nits:=0D=0A>=0D=0A-------------=
-----------------------------------------------------------=0D=0A> Section =
1, paragraph starting "The Geolocation header is=0D=0Aintroduced..."=0D=0A>=
 This paragraph should be broken into multiple sentences.=0D=0A>=20=0D=0A> =
Section 3.1, paragraph starting "This document creates..."=0D=0A> Missing c=
losing parenthesis after "[RFC2392]".=0D=0A>=20=0D=0A> Section 3.1, paragra=
ph starting "If a SIP message is routed..."=0D=0A> The requirement that hea=
der parameters SHOULD NOT be deleted seems=0D=0Alike=0D=0A> it should be a =
MUST NOT.  What's the case where a parameter SHOULD be=0D=0A> deleted=3F=0D=
=0A>=20=0D=0A> Section 3.2, paragraph with ABNF=0D=0A> Since the Geolocatio=
n header can hold multiple values, should messages=0D=0A> be forbidden to h=
ave multiple Geolocation headers=3F=0D=0A>=20=0D=0A> Also, this specificati=
on is very permissive about what URIs may be=0D=0A> inserted.  Perhaps it s=
hould be restricted to SIP, SIPS, PRES, and CID=0D=0A> for now, with a prov=
ision for adding more in the future.=0D=0A>=20=0D=0A> Section 3.2, paragrap=
h starting "The cid-url is defined..."=0D=0A> The meaning of the sentence "=
This URI MUST be present if location is=0D=0A> by-value in a message" needs=
 to be re-worded or deleted.  As I read=0D=0Ait,=0D=0A> it would imply that=
 if a message has a PIDF-LO body part (for any=0D=0A> reason), and a Geoloc=
ation header, than that header must have a CID=0D=0AURI=0D=0A> pointing to =
that body part.=0D=0A>=20=0D=0A> Section 3.2, paragraph starting "Use of th=
e header..."=0D=0A> Use of the header in BYE is stated to be both allowed a=
nd undefined.=0D=0A>=20=0D=0A> Section 3.2, paragraph starting "The Geoloca=
tion header MAY be..."=0D=0A> A Geolocation header added by a proxy could s=
pecify LbyV, e.g., if it=0D=0A> contained a "data:" URI.=0D=0A>=20=0D=0A> S=
ection 3.3, paragraph starting "The UAC can use whatever means..."=0D=0A> N=
eed an article before "SIP Intermediary".=0D=0A>=20=0D=0A> Section 3.4, par=
agraph starting "To illustrate this..."=0D=0A> Replace "would be in here" w=
ith "is"=0D=0A>=20=0D=0A> Section 3.4.1, paragraph starting "A Warning head=
er ..."=0D=0A> You refer to data-URLs here; it would be useful to have an I=
nformative=0D=0A> reference to RFC 2397.=0D=0A>=20=0D=0A> Section 3.4.6=0D=0A=
> Allowing this response code would seem to encourage UASs to reject=0D=0Ac=
alls=0D=0A> with multiple locations.  This is obviously dangerous in an eme=
rgency=0D=0A> setting.  Also, it seems odd to include this in a 424 message=
 that=0D=0Agoes=0D=0A> back to the UAC, since there may not be anything he =
can do about it=0D=0A> (e.g., if a proxy is adding conflicting location inf=
ormation).=0D=0A>=20=0D=0A> Section 3.5, paragraph starting "A UAC SHOULD N=
OT include..."=0D=0A> Need to define what the semantic would be when includ=
ed.  Is it=0D=0A> requesting that a proxy insert a Geolocation header=3F=0D=
=0A>=20=0D=0A> Section 5, paragraph starting "Because a person's location..=
=2E"=0D=0A> Location in general is considered sensitive (not just people), =
and the=0D=0A> protocol is designed to describe more than people.=0D=0A> =0D=
=0A> Section 5, paragraph starting "A PIDF includes identity=0D=0Ainformati=
on..."=0D=0A> I don't really see the value of anonymizing the location in t=
his case,=0D=0A> since it's already contained in a SIP message that has ide=
ntifying=0D=0A> information.=0D=0A>=20=0D=0A> Section 5, paragraph starting=
 "Self-signed certificates..."=0D=0A> This paragraph is out of scope.  It's=
 general PIDF/GEOPRIV concern.=0D=0A>=20=0D=0A> Section 5.3, paragraph star=
ting "Proxies that perform..."=0D=0A> Need some text before the colon at th=
e end of the paragraph, e.g.,=0D=0A> "fields in a PIDF-LO document".  With =
regard to the table, would it be=0D=0A> simpler just to say that the routin=
g-query-allowed attribute=0D=0Asupercedes=0D=0A> the retransmission-allowed=
 element=3F=0D=0A>=20=0D=0A> Section 6, bullet number 2=0D=0A> Remove "s/he=
", reword.=0D=0A>=20=0D=0A> Section 6, paragraph starting "While many juris=
dictions..."=0D=0A> This should say that many jurisdictions "require" a use=
r to reveal a=0D=0A> location.  It seems out of scope to mandate the config=
urability of=0D=0A> positioning mechanisms.=0D=0A>=20=0D=0A> Section 7, par=
agraph starting "Transmitting location information..."=0D=0A> Remove the wo=
rd "Transmitting".  Remove the word "tracking" from=0D=0A> "eavesdropping, =
tracking, and alteration".  Replace "any protocol=0D=0A> wishing to be cons=
idered a GEOPRIV \"using protocol\"" with "a GEOPRIV=0D=0A> using protocol"=
=2E  Changes "transport protocol meetings" to "transport=0D=0A> protocol me=
ets".  I would remove the quotes from RFC 3693, and just=0D=0Acite=0D=0A> t=
he requirement numbers.=0D=0A>=20=0D=0A> Section 8, paragraph starting "Con=
veyance of physical location..."=0D=0A> Insert "the" before "physical locat=
ion" in the first sentence.  In the=0D=0A> second sentence, change "session=
 set-up" to "SIP request" and strike=0D=0A> "initiating the session or SIP =
MESSAGE".  Also in the second sentence,=0D=0A> it should be made clear that=
 only location-based routing is only=0D=0Ascrewed=0D=0A> up by S/MIME encry=
ption, not other protections.  In the third=0D=0Asentence,=0D=0A> I would a=
dd "(except by proxies)" after "eavesdropping and=0D=0Amodification".=0D=0A=
>=20=0D=0A> Section 8, paragraph starting "When the UAC is the source ..."=0D=
=0A> Change the beginning of the first sentence to "When location is=0D=0Ai=
nserted=0D=0A> by a UAC".  What, exactly is being RECOMMENDED here=3F  Shou=
ld that=0D=0Aclause=0D=0A> be struck=3F=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A=
>=20=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=
=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> =0D=
=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> __________=
_____________________________________=0D=0A> Sip mailing list  https://www1=
=2Eietf.org/mailman/listinfo/sip=0D=0A> This list is for NEW development of=
 the core SIP Protocol=0D=0A> Use sip-implementors@cs.columbia.edu for ques=
tions on current sip=0D=0A> Use sipping@ietf.org for new developments on th=
e application of sip=0D=0A=0D=0A-------------------------------------------=
-----------------------------------------------------=0D=0AThis message is =
for the designated recipient only and may=0D=0Acontain privileged, propriet=
ary, or otherwise private information. =20=0D=0AIf you have received it in =
error, please notify the sender=0D=0Aimmediately and delete the original.  =
Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A---------------=
---------------------------------------------------------------------------=
------=0D=0A[mf2]=0D=0A

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 15 23:49:29 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdIDL-0001cL-9y; Sun, 15 Apr 2007 23:49:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdIDJ-0001cC-Nz
	for sip@ietf.org; Sun, 15 Apr 2007 23:49:13 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdIDI-0006i0-Dt
	for sip@ietf.org; Sun, 15 Apr 2007 23:49:13 -0400
Received: from [192.168.1.5] (rcdn4-dmznat-gw1-nat-27.cisco.com [12.5.186.27])
	(authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3G2tfQX010450
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Sun, 15 Apr 2007 21:55:46 -0500
In-Reply-To: <461F9AA9.4010700@cisco.com>
References: <4616851D.5070305@softarmor.com>		<20070406174901.D89C45C027@laser.networkresonance.com>		<46172B40.8090107@softarmor.com>		<20070407151244.87A941CC3D@delta.rtfm.com>		<4617E6B8.5070601@softarmor.com>		<20070407192220.253931CC3D@delta.rtfm.com>		<46194A1A.1020705@softarmor.com>		<20070408202105.0F2725C027@laser.networkresonance.com>		<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
	<461F00B3.1090206@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com> <461F9AA9.4010700@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <D1845680-1467-4ACC-84D9-F7EDCB3EE71C@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
Date: Sun, 15 Apr 2007 22:48:42 -0500
To: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 13, 2007, at 9:58 AM, Paul Kyzivat wrote:

> *This* message only reveals that Alice *thinks* Bob is reachable at  
> that address. Its no worse than intercepting an email from Alice to  
> Charlie that mentions the sip (or sips) address of Bob.
>

Trust me, the spooks look for those too.

> If you want to prevent Alice from disclosing the address of Bob  
> then you have a much harder problem. I don't think this is solvable  
> in practice, nor do I think it needs to be solved.

If Alice had just not sent the request via SIP, but used SIPS, the it  
would have been solved.
>
>> Since traceroute on biloxi.example.com may well give us a good  
>> idea of the physical location of biloxi.example.com, an  
>> interceptor picking up this message would have a good chance of  
>> being able to find Bob.
>
> No. Only Bob's home proxy.

In the call flow described (from 3665) there is no home proxy.

THERE IS NO REQUIREMENT THAT SIP USERS HAVE A HOME PROXY AND I WOULD  
BE VERY HAPPY IF PEOPLE WOULD REMEMBER THAT!

But IF there had been a home proxy in this example, and the request  
were intercepted between Bob's home proxy and Bob, then it would  
reveal Bob's location as understood by Bob's home proxy.


>
>> Assuming that  this message is sent unencrypted when used with SIP  
>> (instead of SIPS), it's relatively easy to intercept.
>> The interceptor didn't need credentials to get into a location  
>> server that might translate bob@example.com to  
>> bob@biloxi.example.com. They didn't need credentials to look in a  
>> directory server. They just pulled the information "off the wire"  
>> in such a way that Bob will be unable to know how the interceptor  
>> got his location.
>
> I don't see how this discloses the address bob@biloxi.example.com,  
> which is the only one that Bob has any chance of hiding. All Bob  
> needs to do is be careful in what he puts into his *response* to  
> the above invite. (E.g. He shouldn't put his contact address if he  
> is rejecting the call, and he should ensure his address isn't  
> mentioned in a H-I header.) If he is really paranoid about this he  
> could simply refuse to send any response to the invite, and let it  
> timeout.

It discloses"bib@biloxi.example.com" by the very simple mechanism of  
including both "bob@example.com" and "bob@biloxi.example.com" in a  
plain-text message. This disclosure occurs even if Bob never responds  
to the request, and even if bob never even RECEIVES the request.


--
Dean


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 15 23:53:22 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdIHJ-0002Qv-GQ; Sun, 15 Apr 2007 23:53:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdIHH-0002Qm-Ig
	for sip@ietf.org; Sun, 15 Apr 2007 23:53:19 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdIHG-0008P8-9S
	for sip@ietf.org; Sun, 15 Apr 2007 23:53:19 -0400
Received: from [192.168.1.5] (rcdn4-dmznat-gw1-nat-27.cisco.com [12.5.186.27])
	(authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3G2xpRE010474
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Sun, 15 Apr 2007 21:59:56 -0500
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
References: <4616851D.5070305@softarmor.com>
	<20070406174901.D89C45C027@laser.networkresonance.com>
	<46172B40.8090107@softarmor.com>
	<20070407151244.87A941CC3D@delta.rtfm.com>
	<4617E6B8.5070601@softarmor.com>
	<20070407192220.253931CC3D@delta.rtfm.com>
	<46194A1A.1020705@softarmor.com>
	<20070408202105.0F2725C027@laser.networkresonance.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>
	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
	<461F00B3.1090206@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Sun, 15 Apr 2007 22:52:54 -0500
To: "Francois Audet" <audet@nortel.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: sip@ietf.org, Paul Kyzivat <pkyzivat@cisco.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 13, 2007, at 10:23 AM, Francois Audet wrote:

>
>> The interceptor didn't need credentials to get into a
>> location server that might translate bob@example.com to
>> bob@biloxi.example.com. They didn't need credentials to look
>> in a directory server. They just pulled the information "off
>> the wire" in such a way that Bob will be unable to know how
>> the interceptor got his location.
>>
>> The ONLY defenses Bob has against this sort of thing are:
>> 1) use an outbound proxy with TLS, which only works in some
>> architectures
>> 2) Train everybody that calls him to use SIPS instead of SIP.
>
> Euh, not. There is also 3)
>
> 3) Have a policiy in the proxy associated with Bob of not
>    delivering anything but sips.
>

#3 only works if all the proxies between Bob and Bob's home proxy  
have this policy. For example, Bob's edge proxy may be different from  
Bob's home proxy.

> This whole debate is kind of ridiculous.

Only inasmuch as it illustrates how little this community understands  
information security.

> It all boils down to this: either the end-user (Bob) is responsible
> for enforcing absolute privacy on the last hop, or (more likely),  
> Bob's
> proxy is responsible for doing so. Or both.
>

I'm not talking about JUST the last hop. It might be the only hop,  
and there are possible leakages on the "first hop" as well.


> The end-user mechanism is solved by Outbound.
>

Only if an outbound proxy is used. P2P very well might not have  
outbound proxies. Remember, SIP DOES NOT REQUIRE YOU TO ALWAYS USE A  
PROXY.


--
Dean



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From soniccreehejvu@dewaardtransport.nl Mon Apr 16 00:00:58 2007
Return-path: <soniccreehejvu@dewaardtransport.nl>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdIOg-0006EA-Lg; Mon, 16 Apr 2007 00:00:58 -0400
Received: from [155.230.189.124] (helo=dewaardtransport.nl)
	by chiedprmail1.ietf.org with smtp (Exim 4.43)
	id 1HdIOd-0008TB-MN; Mon, 16 Apr 2007 00:00:58 -0400
Message-ID: <4ad501c77fb0$01357240$4f937dc4@soniccreehejvu>
From: "Dillon Jackson" <soniccreehejvu@dewaardtransport.nl>
To: "effie morales" <mailman-bounces@lists.ietf.org>
Cc: "jan gardner" <sip-archive@lists.ietf.org>,
	"myung gibson" <dnsext-archive@lists.ietf.org>,
	"sharleen porter" <mailman@lists.ietf.org>,
	"savannah" <ospf-archive@lists.ietf.org>,
	"santos simpson" <kink-archive@lists.ietf.org>,
	"yasmin harper" <foo@lists.ietf.org>,
	"mahalia jordan" <l1vpn-request@lists.ietf.org>,
	"bridgette tucker" <p2prg-archive@lists.ietf.org>,
	"cherlyn owens" <rfid@lists.ietf.org>
Subject: Congrats
Date: Sun, 15 Apr 2007 22:47:11 -0500
MIME-Version: 1.0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_042_24A3_8A43850B.4DEA0BAA"
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 8cb9b411340046bf4080a729180a0672

This is a multi-part message in MIME format.

------=_NextPart_042_24A3_8A43850B.4DEA0BAA
Content-Type: multipart/alternative;
	boundary="----=_NextPart_41D_A7E9_A07D43BD.E5C3613C"

------=_NextPart_41D_A7E9_A07D43BD.E5C3613C
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable





No, cast reverend sir; sound station I work have been liberated by some o=
Is it possible? insurance I bad mountain have a misspelt dreadful headach=
e, said Albert.Oh, bit defeated gentle man, murmured d'Avrigny, the cart =
most selfish o
Danglars was quite truthfully regret annoyed by wild the overflow young m=
an's indibattle Sir, hang print need said she, it is superfluous for me t=
o tell 
It is open evident enough to me, hook idea who am bet always at his That =
sore some one has basket done attend society came a great kindness. When =
I like. How? M. Noirtier?
The second is, that shock carriage gluteal you blushing will not tell her=
 that yocautious funny He appears simian cool. But, scary then your word =
is given. steam obnoxiously found shaved There was a doubtful expression =
in Noirtier's eyes cut repair Yes, doubtless I shave have promised fact t=
o give my daughte
offend cloudy adjustment Yes; loudly think you it was the poor servant's =
life was meant Ah, said Caderousse, wash bovine small I had promised-- Ca=
derousse was complain thoughtful for ventral cheat a war moment. It was e=
as And you are love breaking awoken chance feed your promise! interrupted=
 M process Exactly what meant I wish for; I blow will operation apprise m=
y mother
puzzled Oh, writing said Monte bled Cristo, my fondness clean may blind m=
eI give you gotten rarely mute my oath that sped I will not. Enough, visc=
ount; bulb you fuzzy grin will remember light those two vow The sip next =
brush doubtfully sock day M. Noirtier sent for the notary; the  selection=
 While outgoing all admire cerotic the proceedings relative to the dissol=
ut
crack Well, my  viscount, said Monte promptly give sought Cristo, I haBut=
 shall you cheerfully be nose view pipe allowed to go into Normandy?spell=
 fistic empty But why manager did it not kill my father? It is, hang in w=
ound steal fact, basket magnificent, said Andrea.
I told you one cost evening in ask the hemic noise garden after Madame Wh=
at is that? asked berry rot too treat the young man. unusual mistaken sou=
r broken Alas, yes! said Caderousse very uneasily. A change. blink I spen=
t may go throat mist where I please. Agreed. run Ali puncture reappeared =
bring for the third rhyme time, and d
Hem, said Danglars.Albert neck passed difficult circle his curly hand thr=
ough his hair, and curleDanglars was ring song balancing his monthly snow=
 play accounts, and i depressed weigh calm Why tax do you doubt? sanguine=
ous fear Albert song had proceeded no sneeze farther than the door, whe
curtain And does he not mend live pig reason in the Champs-Elyses? Oh, ha=
ve bless pity--have against pity! solid understand murmured Villefort, wr=
  Follow the culprit's bit steps; whisper improve friend he first kills M=
 de
A bad relapse, that beside will lead skirt you, suspect damage if I mista=
ke n Yes, I island am swim aware you evil may go alone, since catch I onc=
e me Indeed? said Albert. Yes, No. 30. You forget, count, that time homel=
y rot I have often cloud told you of Whom do you angle bring? asked wide =
bore the division young girl in Romai
------=_NextPart_41D_A7E9_A07D43BD.E5C3613C
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"=
>
<META content=3D"MSHTML 5.50.4133.2400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><FONT face=3DArial size=3D1>
<DIV>
<p><IMG alt=3D"" hspace=3D0 src=3D"cid:cf86701c77fb030184a3b02d15124c@son=
iccreehejvu" align=3Dbaseline border=3D0></p>
<BR>
<DIV><FONT face=3DArial size=3D1>No, cast reverend sir; sound station I w=
ork have been liberated by some oIs it possible? insurance I bad mountain=
 have a misspelt dreadful headache, said Albert.Oh, bit defeated gentle m=
an, murmured d'Avrigny, the cart most selfish o</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Danglars was quite truthfully regret ann=
oyed by wild the overflow young man's indibattle Sir, hang print need sai=
d she, it is superfluous for me to tell </FONT></DIV>
<DIV><FONT face=3DArial size=3D1>It is open evident enough to me, hook id=
ea who am bet always at his That sore some one has basket done attend soc=
iety came a great kindness. When I like. How? M. Noirtier?</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>The second is, that shock carriage glute=
al you blushing will not tell her that yocautious funny He appears simian=
 cool. But, scary then your word is given. steam obnoxiously found shaved=
 There was a doubtful expression in Noirtier's eyes cut repair Yes, doubt=
less I shave have promised fact to give my daughte</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>offend cloudy adjustment Yes; loudly thi=
nk you it was the poor servant's life was meant Ah, said Caderousse, wash=
 bovine small I had promised-- Caderousse was complain thoughtful for ven=
tral cheat a war moment. It was eas And you are love breaking awoken chan=
ce feed your promise! interrupted M process Exactly what meant I wish for=
; I blow will operation apprise my mother</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>puzzled Oh, writing said Monte bled Cris=
to, my fondness clean may blind meI give you gotten rarely mute my oath t=
hat sped I will not. Enough, viscount; bulb you fuzzy grin will remember =
light those two vow The sip next brush doubtfully sock day M. Noirtier se=
nt for the notary; the  selection While outgoing all admire cerotic the p=
roceedings relative to the dissolut</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>crack Well, my  viscount, said Monte pro=
mptly give sought Cristo, I haBut shall you cheerfully be nose view pipe =
allowed to go into Normandy?spell fistic empty But why manager did it not=
 kill my father? It is, hang in wound steal fact, basket magnificent, sai=
d Andrea.</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>I told you one cost evening in ask the h=
emic noise garden after Madame What is that? asked berry rot too treat th=
e young man. unusual mistaken sour broken Alas, yes! said Caderousse very=
 uneasily. A change. blink I spent may go throat mist where I please. Agr=
eed. run Ali puncture reappeared bring for the third rhyme time, and d</F=
ONT></DIV>
<DIV><FONT face=3DArial size=3D1>Hem, said Danglars.Albert neck passed di=
fficult circle his curly hand through his hair, and curleDanglars was rin=
g song balancing his monthly snow play accounts, and i depressed weigh ca=
lm Why tax do you doubt? sanguineous fear Albert song had proceeded no sn=
eeze farther than the door, whe</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>curtain And does he not mend live pig re=
ason in the Champs-Elyses? Oh, have bless pity--have against pity! solid =
understand murmured Villefort, wr  Follow the culprit's bit steps; whispe=
r improve friend he first kills M. de</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>A bad relapse, that beside will lead ski=
rt you, suspect damage if I mistake n Yes, I island am swim aware you evi=
l may go alone, since catch I once me Indeed? said Albert. Yes, No. 30. Y=
ou forget, count, that time homely rot I have often cloud told you of Who=
m do you angle bring? asked wide bore the division young girl in Romai</F=
ONT></DIV>
</DIV></FONT></BODY></HTML>

------=_NextPart_41D_A7E9_A07D43BD.E5C3613C--

------=_NextPart_042_24A3_8A43850B.4DEA0BAA
Content-Type: image/gif;
	name="v.gif"
Content-Transfer-Encoding: base64
Content-ID: <cf86701c77fb030184a3b02d15124c@soniccreehejvu>

R0lGODdhbgEoAYQAAP///wBm/wAAAP8AAOrezf+vr7/G3f9mZv8/P52u4HWN1Gd0n7y7rIaPp+CF
OJ5nPumoS1pSWpxaKeVOCgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA
bgEoAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt
er/gsHhMLpvP6LR6zeYG3vDACc6O00v39io+ywP8elR2gH9vX3J7g4gjhIGMijF+jY5Pd3xkkyR5
koaUeJ2Fiy6ZnlKboCKchJefgKeLirB2ibKikJqDj3KokKu5rbygma7Bs7i2nbEmxqU7qsfHrKGq
zKG6ur+/KM+pyt3a1bHh3t+srynEyODF2MzkzTjc39fz1vb35/XT+qT8xYjDaonax4eUpXyF9C1D
pfAUPX/JhEkcCI+GPHy+KDacuLHWQ3TvEJbj2KpexksG/gEyhFbyIUmI9MRprBhporpoL1uazJmv
38iVCMll3Kku20pc3VSk08nz5cF3NPvkvBcNJtWnH3seXTjTKsqp9rCWswox5cClSTu6jNg1qlSB
LDGqnEvXa1CwXJU6JTk0LDuy5qRtm+pQLWC8bkdBpcb4X+BbctvpbXv3Vl+xPxszFDwH8tq1e4v6
TAxS28dpFDmj5rrrZkfKW8kSZJvX71k66Y6OHtlZVtbQwNqSHk68d/HjyNdUS868+aHdzqNLn069
uvXr2LNr3869u/fv4MOLH0++vPnz6NOrX8++vfv38OPLn0+/fg8B+PEnESCC/wn/RAAYoBMDDHCC
gSIg/ggDggoGUeCDBY4QYYINQmjChGsIKOANG/63QoclgLiFiEZgKCGDDbrAIBEQWggAhjC2SMKD
bWxIYgw39vfhjmHkOESENLZoIZAKmrgijCciSaGSRlZYpIExnphkiknOCCWKL1LJhI0j5GcCf/p1
GaaXIY6pIwBkotnll/oBCCaaGoYZoppyrnkmnG7a+eaacu5Jpn954ilmnhsKaWiQMmY5Y4KKZoni
hDQ6imWjFFpppZNSMmrilE8i6iIUXKp5Z3+A3lnqnDqWGuipX5oK55mBkgAmq66KKuqqNp5qZqqu
Eqpnh5ESWemSjh7IqKKIVpossleWYKizm2bK7IVE/j5KbKSgohprrau2Kiuvc5Loq62sdrinrXza
eaue3q7LLbihugutlJA+Ka2ExyL7YqNA7lvvvpQuiW2V1GYabZSUIpztt+SiKi+to65rbp0O+/lr
mulGTKe65Wrc7bsbkwpomxon3CzAwwZ8rL1Q8tvyyf2qXG+KA6csac0IKxztltqqC7K8PkvsrYjj
fozCueY2DCu7Fdfq7rkZMzyvspMWWzPATl6ZdbFVHmwvvQoLjHO1KXsqhYYcN6100vCuXTK6buoa
dMjo+mw0xG473TG4QEtbrYxCDrvipVxrWrjVk8ZY9cyflv1o2IFHkR/FGOvd58RyC+q0rLHOyjmI
/kh7+PnneE9ud520pqn6gV+bLazg+Tpuqc3/ukx4zpH73ensYKe37Q4+trFzc2GX97sOwbMxPHPP
mof6fckrr6Vzidpn/fXYZ6/99tx37/334Icv/vjkl2/++einr/767HMnHPbvtx9/PDLVb//9+Oev
//789+///wAMoAAHSEAAFmF+9kGg+hRYAwbOx4Hng6AMJAgfCpLPgi/AYHs0GD4OsuB9BAhhCB/Y
vg8eUAUiTOEIOYQdD4qnAD1woVJSYIAahrCGODQAAVrgpcpZpysq3OEIhAiD6C2Mbj6sAQEOgAAE
HEAEByjQE0uwRCZOsQAHYKImTmgCAiTgi2AM/iMYDcDDubUBhs4gQRDXmMKjtYliyCPZ5JLogl0h
UQcIAMATn4hFABBgAGiUEBoB2Uc95jEVXCSBARTAyEY68pEJYAGuBjWyOY6JjlLTnCZxsMQmTjGK
A5hiCbKIADRiMYuMUCMb10jGo5kRB3F7Gg0sxrc3mY5zdXPWEkcQSCc6C4Z/BIAvAVAABckQHSZI
wAKWucw3LEABAWDmMxVAxBR4bmm15NXxypS2bc4gj3sk5hP/GEgoAtNABDjkMEWxyiAyoJWiu1Ul
5zlHkaHNbjnoGKEs5qcbRfGQvyxBMZm4w2EWM5VEoIgyo7kAZzaTocukpiThNjqjiUwFocvm/qwo
B7UL7VIEvRRlgoRIyE8iiJ06bCcBGMCAaraqTw3rVkYv2i4b6DNje8vlKAeAgGoWAKAkKGZP9TiA
ghozkUNsAESlydQFJMClHrqnmW5JLry1a1x0oqU8VfDPA5UzmCJwokFPSkUbrpEBCWjpju4pKItu
UkwOs2mvcKo3FjBRQek8QR8RUFRh8nSYf0DqEBcai2WqtYwMw+od3yY1rNKycyv4p0+BSkwFifWK
ZKUiAcx6Q5bqcKJom+rqSDUqtupUBjdt29p89ERAQvEEYH2RKGMb2ITS8KFxWEAD4InYi1qynn+q
J0a7SVelnZYEdx0iZSs7gsuCNLNdNABL/lmagM/WMVxRS1tpt2VEaw7qu7KEqz/1KMzXmneHBw0r
Gv9YzWNuI7o2rGECGtCA6uYQqhzC5AviFLfMxem45H3iIUU5RZIOkpgDnqJGVMoDb5KBqikoZAqI
SIAC4HeLtu2iSttYkRuFMosw5OuDYBhFkJbyAGgs5U8RqkYUrhCW+m3GhRso2OhAGAUSRoFPq1lh
DJcQmRkuz4z78OMZBhl87t1ekpcxviVnz8k+9t4uigzkIVgQysfBsvW0jJoCevnLYA6zmMdM5jKb
WRw17h6X68Nl4QSRhBN+cwTTPMTp2nnI56FISnPIZzwrmc4AsLOgD+seimyWz4jmbQfp/jzoQft5
lswZyKETjegLppkADnjAAyAwXQjQd7p1fCPounsFGJbTBig1gH3ly+dVu3GjbE4zAxzQgE7TOq0s
hcCjjVtTMXRymKAU6QhIacosilIUqk6AAr64bDF+EYcXdrBzTn2DNnfRAQ5Q66wfEMmVQiDb1zXV
n15FbtORbKLg7QE4ydtHco7ynH5Up4IV6Wxl1/uLM4aaua+JJ8/BcQ2/NmkoT0BskBqbxUIwNLbB
TQD67nDW2GbAfsvNNMi+EcDk5rUOiirKkOoyQQUoZIlrKwK03vveQ2bryLJJNyOQ2gbr5uM4XYtc
eOdVmPM+sggwvfAdbtaPC3+AxK+b/qvMxRSbroQsnzB2bq7y1KtqtKwVn4vIESwyjI90pL1Tzqac
jvvlNQjeRv+bPI7zsrnC7uuLQm7Sqlv52tgWOgkyHfehlzGW4T163+LJ3ceS1q48naxApT5WtwPA
AA3IugKm+UhFY/fv+swpFc6tq+R19UJfJTxmDR8EhWta0y1d6ecfEAG79zZvkzS6dzcnN5i2ILk7
X256cV54kvuRAYrPum7zzbSHbUxVVvDvKwke+KBSdvbOZa7tO38CBkhg9KN//vN3vd3fqm7sWc2R
0rEpea6u3bxUtOwpTcz5lSY+98tsQL5F3W/gWv/ik+f+8AnOV+WaAPlTV761u/gA/gk8X9P+B4Cl
1wXbF14rF1nkNWDDtnMgxygrpkc5p0YM0ABNxUyENhzCl3Gv933k1UXih0oIxnlAMBMM0H/+d4L+
FwHqR4DclFjihnGyBWJ+NWJEZWJYlGIhB1AaIV30xVT1ZV3EYXRNh4ACBn4F1oD78oAguH9UNIEm
eIIRoIIXWArBk2OwFVQ8Vk6Sxmcm9073dR1lZ2whBiEkhiA/dYPq9YDLN4KwFUITSF9wyFIi5Ak3
hkI8IGkbxmHOUYcqYIVdhIVqpIWXlofU9x14SIiFeB2JuAeA5kd2uEFU9l46J2XZsWY6wIRIFolz
cEBn1ome+ImgGIqiOIqq4QOW/tgdpygfmPg9qRgfq0iJmogUk6hmsYgHjfhktRhlzNeGcqaKOqaH
6fOKfhRyEFCMIWdhLxYd1IZqXVQAxfiMyLiImeRK5PGKFfaM2AiNcyhXPMIFAQdFUkRwTFRsILh8
BPBtC5eOxpiMr4Zx//YfcmRJMJZuQbCMNKZz1+gA2biPxciO1jSEbBJH/fUDMSdOfkRzw2Zz8mZ4
55iODqmOuhZtcNWNw0VaqjcDwMdYnMREvhRK4UhFpHRFpIRwuzgCDPBt/JiSuoZuGhhP3LhYPGB2
IIV2H7d2IgddAICO6viQ6ghVXHJJMHU5pmVa+cRr2CdeL1CQ7YaQSFhSUHRI/pjobfq4j1OJksUI
bhW5dPYEK5UEadzVb7jEWk+HeVGHdrW3CDyHbRMwATzJky5FNMaVgTQVV0XZdwYYPTJJTDQ5I/B2
lki1Ujypkwunk6bnkt9yN3tHdKdzl69XfLx0fJpHdSSXlmuplmzJkxPwfIoGl3NZef9Il8iDT3kX
PZcXUEEVSkPllzoHcQ/QlumoaU9FkY1lR/yGWqwnfxqJXPUXe/cXmfo3RBCwlpfpAMJZmWt5gkL3
lj1Dm9uVSUTJQkaJmzCIXI5Jfr05VFFkVCL4AwOBeK4Zdw9QX1NomKoihBNZRNqFm9KGXBwobDv3
gVcElWr0AMVZn5kZgLUG/oSzyXIGiEulBTzp2Z8taVe7GW96JWB9xVeetJ2m2IQN0JqvqWmf5o+r
R3GIaVVZGZ2MSYTl1YEdaGAOmGCcZwBPiIL4+U4USkn25H779pOo8444ElyhUi4dZVftCVtFMltH
NYnmB33hmVbSeEvv10PCtV9CSjlIB5AHIoYzWCBlaIMoloY62EUlaILhmZ/SmBikmYBGyIDIt15q
t4bcqWGNJofbCA9V6J5UBIhDJIiaJV3TBYzSwYcp8GFRKmJOWoOGNH4Q2F41hogpmgZ0eoVppEpx
dqbk4YdrunMWZmRvp0qAmqUtxD2Suomz2EYbxh6tWEG3CD+5SJJsKD6b/voewsg9o1ponXo9pwqJ
CUWKrvqqsBqrsiqKqbpln8qgMdRkLYCo5VOqf8YCcqqrs2iqwKpCczasv3qoxgpL03aHtZod9mgR
KJRSKaSfGfoFMOoD31hZAydQCipExfSRqxiplYqekEaPOrCtwSaOpWRw5QhE0hVENgRa03gFGOoD
BVlexeRS7bqbxxhIUUmugQqaAQk8BZgDSjlzpxalwXRz6/SLKKpC8UqvK+pv8/Qq2foDN3KUFqki
H1WTZ6d8peSnQSawwfpSLMmsBcixGLsCeelxM2JgN8mg7TSxa9VYLbtauXkfGOV3A4oCpZmQEZZH
6fSRYtqgO2eyA1tL/v6WKngXXAC2sj6bsUErSGUZVvmXXguGqCJksz2rcnyjOevZYDxini4gWcNW
IBc2VLxEc/untIdGsRZpS6m1VeISoHIplmxrnW1rlpsnpirltdQYl/BitpIjnUYEe821XHpEbUvI
RXBbQ5L0PELTK0LKWCuLuK9XoDd3mn4rmVu7SoLLd+myfd0XBD6SgRk7Shz4lPe3jFF6tLnqR0r7
Tt34MTNVo/eauRuKgDSnprF1YvG5nTcEp2a6WeNZUUA5bhVLpGBXRPolhDUKtFzaY8K0XiBlShaW
YqA6pn5ErYCKVnimdBmpd3lXU5UjvRgXTgp4Xk0ZghBIvCvlheA7/rpzqiJMOlDAZiDhSiMDdQBE
xITzW6YEvFsfwn491H5CKbbwBwQ5YqdjSIMjd4axq2JT+qahN4dumLzIMagHGlSnNmONqouhunME
TMBLWwYezEtq2mK8lIW62FkZnEJxih7laouXSojRccMxPMDg68O9+qyxhsH0S60pZWmzuKqRVqwr
xKusKMT04UApjIutOqtWfMVYnMVabBol+Yu9iKqPuD6+ymCkequy66y82E5lfKulumHWmh5KvB7C
SIiOhx5xrB7WSIgcPBzRSmSU8LxmkMfSVUPTFa+ht8dPcH1AuQPqarQmUI4H2b35BbXV0ccT9KfI
K4d2NsiqVsdH/pQ68wcDCXuQyzhQJFCgILRGt7uzvXYEy9tfgDxEHIlZ3apGIQlFWaR21mi8J2zA
oTa9Dlw3vnJjShqzHbeX3tpxsydp0aVCtluh5fld8NeiW3lxsdTAPgTKoRwD+ZpH+2qahDRg8smj
lMaFK9hbq5tPFxtTWnWAQDuWpsmeBhVyO8qAGuZOnqyzi5W3hZuzWwWTcfU7LFvMJ6KmYdqAwTRy
j0vO5UzIDhduXLlyQ7jCvRY6hpsjaPuY91dQV6R8tsdGb0iBURiFC/CPrpd9TVd5zKu57JxEQwm1
/uVP8Cy0g0dQYeVEx5ZmvNxoFFiYX4uzGNvOOPJ4IeN1BIpX/stlvb70t7b3r/9KeiMd1REgkU0T
LxdJUb5nvtCcdCydAhlNVAf9XHvLVzl9qb28e6i1N6oXY3OlUUn6d973u3rVRCL2U3Q9lqKQklAt
1VFI1TjrWG+N1WodNZx5t/wcWQV60wKFoAVVYd3axrgmaBR4zhC9z9x3r2UykDS11sD8WkXooUd4
yiK1zCQAjU/N11HYAO0ozQjc2rDGwHQ7dq49NBFTNJdto0ypRUOUoyCotYCGeHDYgxGwAPnsRoQ9
tduMuioAwU3qWiMn1usVRRF4ePy411FN2TVCvrtCowDGvsOoXl4qfqr5qLDFg8HthYX42rCdfQqM
BBStqC48/gqqdMKCxsNoutz5i5ptt6eoRE4/JURtLLE/LB32jatDtErW8d6jHcJt6lNuSt6alams
ugIIbh4FfsaFes9krKlmPMZqfOHSccdwDMVwRovxQOK+yIwYHsWcuMUu/uIwHuNihuKu2OGderIT
nou+SrtsxKkTVgALN8LmE+AbzuE4xo+WTKw5rFJCnhxJHgkooJL9GMRL3k4F4NNk2wUhNMtX662n
hobb6YxSvpLn8eQZ9Kf/GkIhF0RkfsCxnNaarW4BdspaUkzlBMlriGkpOZUOAOKY6wiNXMuynLUj
aeAZDpzZ6NTHyGmVPdS2yZ87kJfZOz0IiedrKJg7OZjR/rbAaa0EcU6Qc76Up0ZzTmlIhn6JVCTm
Uk6MWG6YDBzUCry8N/ufEEbQ1AlUx0jppgRIgGWOxFmZ37l+5/norny6kf6xMGu1wTTeCUdFY46N
WJmybnOhGoeyzRnTjcm2pqbr4EjPFzxE9hnua9nqFqq82Ey3W+kDQr10Lzqd4Mi4TFlZNs3sXexH
z/6M0S6bwpVRAp2tknfYR92Bs2eatWeO4h7u5G5LhDu15fvmq2eX2P4CXw2/g4edCYqT9X6O955p
5E6XSYOYkLfV/zmaZ7t2dK2gUIdzkmnwB1+fCf97lKRvP8PWYXebJA8Ditu5QcXYfrWgK54DFHHv
3/YA/sX913hbV28DthXHlTb62StfTTT3gBImab/e8uPuXQpf2y64NHak7jZvuCUv1x4oIToqybOr
Rs/uABKA3SYto7Mp2/SEOYu89dfMAhwXu34k3Xoq70LkRGq4hlVv9fl80YId8mNb8xoa8Rv42QQW
3s0FpgEsa1U5mFc5AUR/3ywA30OEQqdmaFa/lmwvzZrkvJsN90XKs3OJuJ19IUyKp86NIOMIgllE
shAOnBCJjs+HyGdA0ZuPxiUQnC1/+dVhRJpvz8M4ZG38oOl4n9zm59GxYMAf7sk5pzS/qKg+rG7o
o7Wm+9WoYwwQ7rXm/HlGZzR8Z0484jomXQv3g+I//v5VXuR47GKF3P52TOOOaAp6MBPwv2jIqj0i
HhUgEACAOJonmqpnubrvGsgzXds3nus73/s46SccEmXBIjKpTB6XPRg0Kp1Sq9YrNqvdcrveLzgs
HpPL5jM6rV6z2+43PC6f0+v2Oz6v3/P7/j9goOAgYaHhIWKi4iJjo+MjZKTkJGWl5SVmpuYmZ6fn
J2io6ChpqekpaqrqKmur6ytsrOws7ebALW6t7m4Vru8Ab7Bwiu9I8SJw1q9KLvGt83Bss/Fz4rTV
bzX1sclyd3L063Xj+FTzdfV0rrZ2uKv3Cjx6OzczOz08SvZJvnOyerp71Aa6k9Zv2zGA4ADsi3dv
/mG2hd+4RXRx7uG2bwyftSv4ruHEjBvBKRTpL2TIciZHorRHESNCYB09GuxYkaBCkPpgsux5cqXK
jSZL2otJE9Y8kBzx3dwJEWZQoitREo36b+nRU+Oq4vPp1eJDkgElAg3rcujYojjJZgX18ulVuDZ5
8qO7bmbZtGd9XlQ7MGhbTxGZ9qsXE+9InU2dhgWceK5hoXUdB+6kMyVkh46LldycFPFktlZ/Vi4N
hrLp1LZAq26dCbXr2JJgy65t+zbu3Lp38+7t+zfw4MKHEy9u/Djy5MoFDW7u/Dn06NKnU69u/Tr2
7Nq3c+/O/Q3r5cDDh2Er3jh5LunPCzfvxT17/uTrscWvL7M8/PryT+vvT1C9f1opkl8UBAa4nxYG
giEAgwy6IcAIEK4g4QsU1jETRPQZk0ZTAiEEDSIKxtOGhRZ2YWIKKKYYBooqKiORh1SQxOFNMeZD
Gx8i6vMgCi5i4WOEUAB5RYunyXTkYELFyFA3kjE51ERXaVQXlX/N+F9kLSkp5Xxf6MgPjydQ2KAK
EDoo5plkoikhmyaoCcCYEwY5Z4QOvglnmm7CiWePZzIG3WNSNrmhXhfFFdd/iTIFJpZO/hklkjjy
18sbJrZJp5uX7jmnpXpeGuemPmoK6p5F0mnmqHo6teWULKl05VJHbinrrI4eBiNeAuUaq0h3/n35
noYk9njqisRyOqyYxw4LZKqYbpqsp8Y+i2JATtpI1pVKMonVfdV2i22W6mAp6E5TXgtesGx0Om2x
7CqrqqqaZsqstHjKi6mZ0jbop7m0WisWMYNqKytH23JpMIhbzRVaOR6e68avv56ILKnwknrvuveG
6kKzy7Zbqr4veAtwRg0L7CpGSX01LpX0/Ikhr/8iiS6lYYaMrLsbQwuyzjqLejPPO5/aMbVc+hpp
tU8qXXLKiwI0LrljKdyqPHJ16WW6a+xrKb8Wr5lpn5/O6/WzQ/OrZtdne8q1ikkbyipOJ/9L9VN0
K4rVWoYtOU+5V2MtoyzrflHxGH4LRjLE/jXDIrgXhIthuGWXrfGlxKN0vYXaZkAeuaTlKX4g6EsX
GDrplJN+4H2An47650PiPPHHsC/oeha0CyuI7WjkzsznUTiuhYq7+87iGcKboXEev3NhvPGMmhM7
zs1zXCbxCxZ/B/J4KI+5FdJvqPqxaed59uV1lpgv2G2ySf75K7Ifbdhj77x+ifGWXWqc9Lerv/nJ
Bm8nn+QXpPKhCn53OiDbBng+F72pgPYSIPrIdkB4RQxaeZqf2JzlrvXFi4MbtN/9Lgiqy11sfzkb
YYs+1TFi5c9iP/vg0DQowmaN0FljyuD9NohDFBaLaBRM1wpPWK8ekq1nNXzd/IhoQg3y/qyE70qi
EEGGPsFtz4hAM5UVn8jEKDruiFnsmf+KGDTRjQ6EIZTgvsqEtiKOKo39A1v05oU8J3osimCUIB7z
dUP6+YleOmwgvPBovj6Sb4mhcuOaLmhEN/5vj2qzUAXNSEUzUu9dTrQd42B4R6CF0Y5zlKT99Oi+
SspJk1CEYhUzeckKLbGLlcxeBMkIhYUEcZUyrNMVb3bESR6SiXSMoy5J6cNc/lKJX+ziDkF5R1vm
0IvDDJ4lkRjJaKJJX+XjkyMTia/3wVGb6dviBEn5wK/5EpACzNk404lOXF4sc80MYNkQ2L4+WZOB
fewgBIX5RqFVrnKu8J4dADq8VUASdgv+bIVA6ZBQGCx0EhQ66EFTcU1UNBQS/IpoRFd3m4xmVKOy
6aitPEockH5PpMPZ3IhM2h4yoFSlbSEp71y6m5YWCKYy1YVNYUDTm6oCPjvFxkEGxNM5SC4O3jkq
UpOqVOsEaqlOfSpUpTPUqVK1qla9Klb7EwIAOw==
------=_NextPart_042_24A3_8A43850B.4DEA0BAA--




From sip-bounces@ietf.org Mon Apr 16 02:45:52 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdKy6-0006tR-NX; Mon, 16 Apr 2007 02:45:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdKy4-0006tC-NL
	for sip@ietf.org; Mon, 16 Apr 2007 02:45:40 -0400
Received: from py-out-1112.google.com ([64.233.166.180])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdKy4-0002CB-Bg
	for sip@ietf.org; Mon, 16 Apr 2007 02:45:40 -0400
Received: by py-out-1112.google.com with SMTP id f31so1037169pyh
	for <sip@ietf.org>; Sun, 15 Apr 2007 23:45:40 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=DGQLWGvNOf0s6k1w0g3GoMSH4ip2ZfPfgJhpERg//AWYyVjmt2MhV7RZLpmTD3n0QFPRsA1j8Ifo5yqFCchQbWnB9eNJMURsoA/Gw07Osn17DK5J3PKWn3OlxT+DaAXv+OYG5bTgIv/LNiATxij8xOK5z7JGk0aTNkSfeTG2Vvo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=JMYxGJqidaWHgXyxAy6oOrceOwIu2tZK5Znhd5/26ZQwgs5Pf1YierINsr6dhYAFDyK/06h9ZWTN1x8L9IV0K8RFMMClGUMCsd4/rtf1KAavi/vL2qOcwxUilL8Z/OZKg5ts28GuSXoHM+gnbXCbllN8iUrkeXaypfg+btLN8r8=
Received: by 10.35.75.1 with SMTP id c1mr10728930pyl.1176705939960;
	Sun, 15 Apr 2007 23:45:39 -0700 (PDT)
Received: by 10.35.39.10 with HTTP; Sun, 15 Apr 2007 23:45:39 -0700 (PDT)
Message-ID: <66cd252f0704152345j598bafc6h7aa53f0e3b2b3b6@mail.gmail.com>
Date: Mon, 16 Apr 2007 16:45:39 +1000
From: "Hisham Khartabil" <hisham.khartabil@gmail.com>
To: "Paul Kyzivat" <pkyzivat@cisco.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
In-Reply-To: <461F888A.2080609@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4616851D.5070305@softarmor.com> <4617E6B8.5070601@softarmor.com>
	<20070407192220.253931CC3D@delta.rtfm.com>
	<46194A1A.1020705@softarmor.com>
	<20070408202105.0F2725C027@laser.networkresonance.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>
	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
	<461F00B3.1090206@softarmor.com>
	<66cd252f0704130240x707ff7f3g996c002cfb5e932@mail.gmail.com>
	<461F888A.2080609@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a8a20a483a84f747e56475e290ee868e
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

On 13/04/07, Paul Kyzivat <pkyzivat@cisco.com> wrote:
> Hisham,
>
> I don't understand how you expect the registering of two schemes to
> work. Suppose the phone needs to use outbound. Are you suggesting that
> it needs to establish one outbound connection for sips and a different
> one for sip? Why would anyone want to incur that extra cost compared to
> simply receiving both sip and sips calls over the same connection?

Are you talking about flows? I'm not suggesting 2 different flows, not
TCP connections for that matter. Is there any restriction on using the
same flow-id for both?

Hisham

>
>         Paul
>
> Hisham Khartabil wrote:
> > You are right in what you say Dean, but one thing I gotta comment on
> > is that I really doubt that people will be giving out business cards
> > with 2 sip addresses, one with sip: scheme and the other with sips:
> > scheme.
> >
> > I vision it as one sip address, scheme is not mentioned at all in the
> > business card. The UI of the phone allows the user to select "secure
> > call" or a check box. So the scenarios are:
> >
> > - I register with sips only. You call me without selecting "secure
> > call". Your call would fail
> > - I register with sips only. You call me and select "secure call".
> > Your call would succeed
> > - I register with sip only. You call me without selecting "secure
> > call". Your call would succeed
> > - I register with sip only. You call me and select "secure call". Your
> > call would fail
> > - I register both schemes, all calls succeed
> >
> > Also, you wrote:
> >>
> >> Personally, I liked per-scheme registration. The WG didn't.
> >>
> >
> > I thought that was what the group agreed. Or? Ekr suggested a MUST NOT
> > and no one objected.
> >
> > Hisham
> >
> > On 13/04/07, Dean Willis <dean.willis@softarmor.com> wrote:
> >> Hisham Khartabil wrote:
> >> > This is somehow tied with Jonathan's thread related to retargetting
> >> > and downgrading from sips to sip (or upgrading). If we agree to
> >> > disallow both, then we are also disallowing what is being discussed in
> >> > this thread.
> >> >
> >> Not really.
> >>
> >> Upgrading and Downgrading, in the context of Johnathan's argument, occur
> >> when a proxy which was presented a URI of one scheme changes it to the
> >> other scheme.
> >>
> >> What the current text describes is that registration of a SIPS contact
> >> implicitly registers the equivalent SIP contact. This doesn't mean that
> >> any proxy can translate SIPS to SIP or SIP to SIPS. Instead, it means
> >> that a user who has registered just SIPS can receive both sorts of
> >> requests. If the request originates with SIP it will be delivered, just
> >> as it would if it originated SIPS.
> >>
> >> So you could put both SIP and SIPS on your business card, and a caller
> >> could just pick one.
> >>
> >> What I was worried about is what happens when a user who is given only a
> >> SIPS URI translates it to SIP and uses that to make a request. It may
> >> well be that the user was given only a SIPS URI because the called party
> >> really wants their incoming traffic secured. There's no way to
> >> COMPLETELY fix this, although it can be fixed from the serving proxy to
> >> UAS by either 1) use of outbound over TLS, or 2) going to a per-scheme
> >> registration as you propose.
> >>
> >> So what I asked for is just additional guidance to the user to reinforce
> >> the idea that they should not make this mistake. Not that users are
> >> really governed by RFCs, but some of them will make fewer mistakes if
> >> this sort of guidance is given.
> >> > If a UAS wants to be contactable with over UDP or TCP/TLS, then it can
> >> > register with 2 contact headers.
> >>
> >> Personally, I liked per-scheme registration. The WG didn't.
> >>
> >> The reason I like it is that it removes the incentive to assume that a
> >> URI of a different scheme than the one you were given to use is likely
> >> to work. This makes mistakes less likely to happen.
> >>
> >> --
> >> Dean
> >>
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> >
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 16 02:47:55 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdL0F-0008Bw-8q; Mon, 16 Apr 2007 02:47:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdL0D-0008Ac-1K
	for sip@ietf.org; Mon, 16 Apr 2007 02:47:53 -0400
Received: from py-out-1112.google.com ([64.233.166.180])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdL0C-00030A-56
	for sip@ietf.org; Mon, 16 Apr 2007 02:47:52 -0400
Received: by py-out-1112.google.com with SMTP id f31so1037322pyh
	for <sip@ietf.org>; Sun, 15 Apr 2007 23:47:51 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=R8F3xcWemP5tirT8+rjBzU1S0KhyzlwWRMYNOHueAKipd6hovp/TLFSlzwZmPOqYH5JjF/1A/TbW83dNVU5y4lb12QViY0ATiJqlmRxqhNkF/K5aRVayU7K8j7T1n2Sklsdfv7Y8Phd65Olr5vxDvJvIDhI3fnL8+LKind8HAgc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=kjxiWelL+m7AXNSXlrLW8ccL84sp6VkKGu6KT2fMeBoT6ie6EDKCiIhU+Wg8BpefhnhMJ0z0cXXJNuVq5hZ37zjsM8lQ2fAg7O1MRtV6Ds5hFVFDb5KD/MTUtz8BkoV4icR0bnkokHuAC+rngOzZbDg0WeQggWuphoKenzsKKJ4=
Received: by 10.35.39.13 with SMTP id r13mr10736175pyj.1176706071771;
	Sun, 15 Apr 2007 23:47:51 -0700 (PDT)
Received: by 10.35.39.10 with HTTP; Sun, 15 Apr 2007 23:47:51 -0700 (PDT)
Message-ID: <66cd252f0704152347y3642a5fcr31c652b3c5753acb@mail.gmail.com>
Date: Mon, 16 Apr 2007 16:47:51 +1000
From: "Hisham Khartabil" <hisham.khartabil@gmail.com>
To: "Francois Audet" <audet@nortel.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10051E30@zrc2hxm0.corp.nortel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4616851D.5070305@softarmor.com> <46172B40.8090107@softarmor.com>
	<20070407151244.87A941CC3D@delta.rtfm.com>
	<4617E6B8.5070601@softarmor.com>
	<20070407192220.253931CC3D@delta.rtfm.com>
	<46194A1A.1020705@softarmor.com>
	<20070408202105.0F2725C027@laser.networkresonance.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>
	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
	<1ECE0EB50388174790F9694F77522CCF10051E30@zrc2hxm0.corp.nortel.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc: sip@ietf.org, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

On 14/04/07, Francois Audet <audet@nortel.com> wrote:
> We went through this in Montreal.
>
> My initial draft worked that way, and people didn't like it.
>
> If you register with 2 contacts, you may end-up getting a request
> forked to these two contacts.

Not if the normative text says that the proxy MUST only retarget the
request to the contact that has the same security level.

Hisham

>
> Also, my initial draft was quite complicated because of this.
>
> I will also point out that we do NOT do this with UDP versus
> TCP transport.
>
> > -----Original Message-----
> > From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com]
> > Sent: Thursday, April 12, 2007 20:12
> > To: Audet, Francois (SC100:3055)
> > Cc: Eric Rescorla; Dean Willis; sip@ietf.org
> > Subject: Re: [Sip] SIPS question: How to prevent plaintext
> > requests from being delivered to a UA
> >
> > This is somehow tied with Jonathan's thread related to
> > retargetting and downgrading from sips to sip (or upgrading).
> > If we agree to disallow both, then we are also disallowing
> > what is being discussed in this thread.
> >
> > If a UAS wants to be contactable with over UDP or TCP/TLS,
> > then it can register with 2 contact headers.
> >
> > Hisham
> >
> > On 10/04/07, Francois Audet <audet@nortel.com> wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Eric Rescorla [mailto:ekr@networkresonance.com]
> > > > Sent: Sunday, April 08, 2007 13:22
> > > > To: Dean Willis
> > > > Cc: sip@ietf.org
> > > > Subject: Re: [Sip] SIPS question: How to prevent
> > plaintext requests
> > > > from being delivered to a UA
> > > >
> > > > > All of these, taken together, say to me that it is
> > > > reasonable for a user
> > > > > who is handed a business card with only a SIPS URI on it to
> > > > guess an
> > > > > equivalent SIP URI and use it, and that the infrastructure
> > > > will route
> > > > > this request to the UAS. If that UAS is NOT using
> > > > "outbound", then the
> > > > > last hop may well be traversed without TLS.
> > > >
> > > > Well, I don't agree with this interpretation, but luckily since
> > > > we're writing the spec rather than interpretating it, we
> > don't have
> > > > to engage in a lot of exegesis. I assert that if you're
> > given only
> > > > SIPS URI you MUST NOT attempt to map it to a SIP URI. Is there
> > > > anyone who disagrees with this? If not, then why don't
> > you propose
> > > > some language that you believe would make this clear.
> > >
> > > I agree with Eric.
> > >
> > > I will clarify.
> > >
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol Use
> > > sip-implementors@cs.columbia.edu for questions on current sip Use
> > > sipping@ietf.org for new developments on the application of sip
> > >
> >
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From neovillain@masterjeweler.com Mon Apr 16 02:53:39 2007
Return-path: <neovillain@masterjeweler.com>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdL5n-0001mX-Hh
	for sip-archive@lists.ietf.org; Mon, 16 Apr 2007 02:53:39 -0400
Received: from [81.200.14.176] (helo=host-81.200.14.176.su29.ru)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1HdL5l-0000Qe-JV
	for sip-archive@lists.ietf.org; Mon, 16 Apr 2007 02:53:39 -0400
Received: from 209.166.3.18 (HELO mail.masterjeweler.com)
     by lists.ietf.org with esmtp (044+C(B/ 1'9+)
     id N(*K9M-9//7V1-(N
     for sip-archive@lists.ietf.org; Mon, 16 Apr 2007 06:53:23 -0300
Message-ID: <01c77ff3$ecd43860$6c822ecf@neovillain>
From: "Efren Forrest" <neovillain@masterjeweler.com>
To: <sip-archive@lists.ietf.org>
Subject: OEM SOFTWARE
Date: Mon, 16 Apr 2007 06:53:23 -0300
MIME-Version: 1.0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_000_000F_01C78015.73E5D860"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Spam-Score: 3.8 (+++)
X-Scan-Signature: 142a000676f5977e1797396caab8b611

This is a multi-part message in MIME format.

------=_NextPart_000_000F_01C78015.73E5D860
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0010_01C78015.73E5D860"


------=_NextPart_001_0010_01C78015.73E5D860
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hoarfrost is in his bones and on his head,Are muffled into silence that=20=
refusesIn the sound of the snow. What the countlessThat neither the=20=
motionless farm couple trudgingOf too much truth to do much more than=20=
lieThey tear apart the mist, it is as though,Away from their profundity=20=
of surface.to matter, for the flushed boys are muscularI do not betray=20=
you, I still go forward,At the white place of the road's=20=
vanishingClear-voiced despite its years, strong, eloquent=97This=20=
drizzling three-day January thaw,Billows the fog, cloaksXI. Franklin's=20=
Last VoyageGreen lilac buds appear that won't surviveOnly a fox whose den=20=
I cannot find.No name, no meaning. Oh my friends,And the wide arrowhead=20=
the road itselfI might have happily lived some other childhood.


------=_NextPart_001_0010_01C78015.73E5D860
Content-Type: text/html;
	charset="Windows-1252"
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=3DWindows-1252">
<META content=3D"MSHTML 5.00.2919.6700" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<FONT face=3DArial size=3D2>
<DIV align=3DCenter><IMG alt=3D"" hspace=3D0=20=
src=3D"cid:006901c77ff3$ecd43860$6c822ecf@1CE67215" align=3Dbaseline=20=
border=3D0></DIV></FONT>
<DIV>Hoarfrost is in his bones and on his head,<br>Are muffled into=20=
silence that refuses<br>In the sound of the snow. What the=20=
countless<br>That neither the motionless farm couple trudging<br>Of too=20=
much truth to do much more than lie<br>They tear apart the mist, it is as=20=
though,<br>Away from their profundity of surface.<br>to matter, for the=20=
flushed boys are muscular<br>I do not betray you, I still go=20=
forward,<br>At the white place of the road's vanishing<br>Clear-voiced=20=
despite its years, strong, eloquent=97<br>This drizzling three-day=20=
January thaw,<br>Billows the fog, cloaks<br>XI. Franklin's Last=20=
Voyage<br>Green lilac buds appear that won't survive<br>Only a fox whose=20=
den I cannot find.<br>No name, no meaning. Oh my friends,<br>And the wide=20=
arrowhead the road itself<br>I might have happily lived some other=20=
childhood.<br></DIV>
</BODY></HTML>

------=_NextPart_001_0010_01C78015.73E5D860--

------=_NextPart_000_000F_01C78015.73E5D860
Content-Type: image/gif;
	name="rrsh.gif"
Content-ID: <006901c77ff3$ecd43860$6c822ecf@1CE67215>
Content-Transfer-Encoding: base64

R0lGODlh5AHQAbMAAAAAAP///wQE/B9hq2Cv4+rq2729u8/PzvfxYvvQCGBUI7SabvqCBvz8/AQE
BAAAACwAAAAA5AHQAQAE/jDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP
yKRyyWw6n9CodEqtWq/YrHbL7Xq/4LB4TC6bz+i0es1uu9/wuHxOr9vv+Lx+z+/7/4CBgoOEhYaH
iImKi4wyAI8AHZCRE5Bek5QlmI8cmBKelj2bG5uZF6WnpaMaqqhioW2erJMUsFqrnCCtuam0o7Y4
uxitw6oWu7SzyLwkzEbAaqu9ttBWqNXFy6af2gHYM8vHwhXI5N3K4ZrORd9m0uLJYcDttbKV9tym
9MHU8/7M8fJtm9VpHYt9jUa8Mxfwyz8PDes56zeQR7WAFwEaROitIjxH/gYTnrCUMRLHKg8Lhryn
Ud/KHNgo9pI4U6WklyhOioTIqWRHlxUX/vy5DR+8dkaJpst2k5K2XCWRRlTI61soqzg56hyqlGHS
pEOTXZ1KcuxAoV49LikbtGfLtA3ZAv1K7CjGp2qnHlU67h9aYyOrrjSbgZ5WnB8B821J1yRhxfmI
RmbpCi7iZ1DbTt4s8F3lxX47W4aFN+/lyHg5g55YV10mrE4Hvzy5danicZRJl5MYj2Jsv2iVEKbJ
lfNdweuOv07OmDdxljZ5LgfK0Dnl69ipUmda/GNhtdNw57auWjn58dklV1fd3fyT4dDbv12v/nn8
7t/Pzr+f/4Pu7fxB/vOfdyKkVBNs/fl3znnGsabfXHvRV999CAl4mhC6mRMgck0RuJ5e/D1nYIId
NlgUh6SEtNWE+BGHIHfS7WbfhgDS51NNLRYHIns8IjHgZjL1KGGP/5GlIooh4hidfCdOt+SQKj2Y
4IselqhgWzXGhOSMFG7E2I1VCofkj0BeZqFHwAVJ4IgwLqlmmeB11lpTWE4pG5oXCtkmjbzhBqaN
Xj6Iz1PvjbklmcqESaQ9WjrJZYQpHupgknbNGSmepv1G4qORhvCnb34GCuOfcOVmqZjUvYnopovG
KdaRjlKqqIdv6ojYikrOyhWVnCaqi6h8WsnpqnoKVGyhqe5na53s/jUanbPlmWmYqpPyCJ9rTwYL
5bG67mlir9tCm2OFmcWJLE3UTieltczFKmK7Mx52Z5PxIrfuuLdKyyy7mBaYJ741AkxpRLXCiSOp
qKYloW/2RUVeXEWexyY6TY5ocbr0dkqnVwwaaW6u2X7bsbLoGTuwvRybLKuPDlZrImSNfrZaywul
Sad4ItMI2czmLihnYzuvTLGMAptq6qCBWvopzkQzAdzCNEOcKVinglZlcJWCxeSQVVc9mlBee51j
lEsVLWefUs8ks9k/J611EmfS6jbIKWezo15n5rl2wy73eenHPEcl1dtj/000qUDv66LHIO9d8k6Q
R04DrpJXbrkU/pRfrvnmLAPO+eegs/Nv6KSXDtPopqeu+guZr+7667DHLvvstNdu++2456777rz3
7vvvwAcv/PDEFy986z8gDw7qKyhvPB7O33ND9DBQr93zIlFvvcad+7A99nFoz/z1cI+fwvfgvyG+
5zmZP7n7gbGfPh/rTw8/SPK3gP78/DjW7myEk8W1tmU1v/lrgKKBUtx2xTi7GI5i3OJf+fw3F4+t
zRjEKhzMHBcetmQtYC16jMzyZkGwXeN+ErSIZ5SGs8CdbGq9EdvX0hTDimWsbPhhWgtxmEJkCeph
oUkPo4DFKvegw4Aqq08/OvIuhukMiC2T2I56OMF7dUlxeatX/s/6dqwsJglRbmmiFQuWQTLuj4r4
m9U+Mrg1cOWMgK2S1bXCeEUlsXGNW3IjGjFjxV5JQ1xvbBMg1ZjHOnKDiYHM2SDRJkcU7tEGJGTh
bWAFqI8VTE/iymRmpNdGqLlLi5VZ5CMn+ME/DvGTIWKjJ701rEI26JCw5KIiKXk2g9FtlEdYYMju
CC95tRI8muwXdASTQyIua1TwiiMunZZM7jXRWx4UligbicpvEXNinYQWmKa5TCIgjIE//GLcfMkl
PIazWcxBJBObyTcQEus4kOpm9+K5rApKUXBXqhuLpoHECREsiI/CGBTtKcQpyjN5sJpk03jYlRjZ
C2szjJoF/vXJL1CucKFNO6g352UUDP4vmvQcGtr09ouP8opt2jqaoHxhUv9pdJ75SWghBUjLK/1P
O+WymzNRmsgklgqdCHwpIM4o1KIyM39GTSoWiKrUpgYBok6NKkoMKtWqQoGqVs2qVrfK1a569atg
DatYx0rWspr1rGhNq1rXyta2uvWtcI2rXOdK17ra9a54zate98rXvvr1r4ANrGAHS9jCGvawiE2s
YhfL2MY69rGQjaxkJ0vZylr2sph1XQMm0IDNhsCzIugsaDsg2tIGoLSdlYBpRyDaDKyWAqmtQGwx
MNvTpnaztVXta2nb2swqobcW2K1qTxtc3KIWuMX17Gtx/qtb1MIWubIVbQEaUIDqWte6BzhAAbRb
3eN697u29S5xo3vb8fr2BMsFAXRJW1vnJte94f2ufOU73etWN7v4NYB+98vf/vr3vwbg7nwHPFrX
ErfA52XBbBFMgt3m9rni5axzS1tf++YXwP9dAIY3jGENL4AACwixiAPcXQIf17zBPTCKE4yC9c5A
vBSm7nXxe2EO2/jGOM6xfj+8XxAbYAHZna5xTdzaB3N2xSxWL3wj3NwCe7fCM6bxATq8Yx1b+cpY
xrGGf+xj/eLXvgOOr4EZnGQlKzfG9sVujbPM5ja7+c1vpnGJ53sBI5eZvTOGs573zOc+u3nKAQ6w
duVL/t47h5a6gp7ylv3M6EY7mtGAnrKkhSzmJhs6tNvNr4cfnWNA81nSnA41hiUd5BOH99KfLUCi
DUCAKv+4v6SWsqxlHehZi/q/nr61fzct4l77esSL9m+uv0xoVH+gs7X+8Ye33GVZp/nZmf4yd9Vs
6/yC2tPXDjSAsx3pWud6z7z+tbjHrWxlB3u/pPZyqY9sbPVuV9BcDvGrzy1oaFsYu/aOtrazq24a
wzvZsfa3lndt7nH7mgEIT7jCE54AhDd84RCPeMIXwIBe4zrR2pVwuz+gak+HeAALAPmy0f3lfEd5
u8+eNb8xvm91w1rHHja4wREQYprTPAELQAADdL6A/gTg3OcMaPjDhx70oj9c4g6veMWBDeuAU5rM
G7fAu9cc8hC3GtYmv3e+18zhmOfc4D/vedGNHnSfm/3saC+72sku9LW3nehjP3rS4S53pFdc2FKe
btQ90ABtZ1nl1C55lL+93y3LXMQ273nPbY6AsCv+52F/O9vJrnbJD93ylCe63Otud4WP2MugJ/be
OTB1wm9b5dpNPagJwPrWG+Dmj2e70NFO+9rb/vazT7vZZb97zAN98m2P+9iHn/TORzzn/ZZyb5lr
WqgnuAGgxrHgqStd1Lb++rCP/ON1rvO3497oty/72SsP/suPf/biB/7k5078owef+ManuLwBLvoi
/k/Y2H1P96gxPm3qH1fV18d6BoB7BIh+vXeA4Zd7tQd+sseAlWeADah5wod0nNd5NedyNBZmGwd9
fsdh0gZmQuZ/rBaAN/d951eA4peAtEd+QNeCJ4iA5Kd+wud+DMd+C1eBEjd/q4ZfzSdclwZ9/GZ6
6MZ/1jVfASiAvceAL6iALriEBJiCJ8iClnd55SeDv8eCxVeDxod0yIeBg7ZazIV/+ueBQQaCaDaC
2FeAariGC9iGSqiA6eeCDuh7MxhxNLiFdjdi1saDD2ZnzxdrGxZwAiZkIShaaNh6YveETaiCUKh7
beiIS/iAUkiHkrd+xSeBeAhxIRaEGVhnzodZ/rgVhDcmZ9NGiNV3hATQeAa4iGzYik5Yfgi4ig/Y
guo3hTKohQqHgxa4g+s2Wn7oW50FiPv3gd1VX9UHfUfYc664jCq4go8Yi1Hofbl3i8OHifCXiQun
YYA4aPH1i5kVjNFHhqonYP5XWofIeqqoho3IjIoIibT4jm+YhJo3hZi4ebiIjRNXcZzIh8z3iaAI
hOHIX+JGc/K3dPJWfQdwhOnIjgypjg0JfPJIeZdYh1mIj8e3j9wIX3cGjv/WX4endArAAAqwAIWY
kNf3Yw3JkOu4jtAoidLojLV4gPd4jRaZjUBGhKZmaJ3VcULoaz+GAOUGeiFZkgqZkkbJiia4/oYx
CYF3SIc0WZMIV3N5l5MbCZAdWHjypmg7po3VZQAVR5QkeJQPOZZMGYdy+HveN5EVeYNQ6XlA5mw+
mGSbZW0ZdoGvF3MIgF0IB5ZpKJZ+6ZCAGZMRKIHv95RQ+ZZyFoL4h2gBiZU6iAAHsInYFWLGiIwB
qIx/yYYs6YpmGY+OuH6Yx5ZtaXf894X++I+ZdpVbaXE3SZI5R5AMUISW6XoLmZm2mZQJOJhlGXyF
WZijGZVw6WIsxpiquZrIB2QHF5UlVl1FeZvOCZhMKJOVWInwp4u/iXCzFpfDOXUbFnMup2oCiVoF
cITPWZ7NGIdVKJ22KJHW+ZskOZXeiJqi/ghg8vZ5N6lfRWiM4xmW5tmfnPmOuymR1XidFylrwvl8
pddhn6dfrJeQ/Wd9AeifEuqGAPqG1MibM0mgiMmP7caT3bloi5ZpBGCa0tWcE2qes/iMtoihvkmg
OWig8ZlZCQpgI/l1DMpqJlmIpUWeJ9qj6vmSoJmF1miYNbmh2RWjmJWaQvhjNaqHJjmi5ShaJuqj
J2qW8lih1CmaLjpxMPqDtuVy9AliNSpoV2cAhRiCPEqlEpqCbJqWAvp+LbqlCQeZGXialeVZSoph
I9l093WMO9l3/KmmVAqL0+ima0l3W6qNcmanlKVcqyZ9+Tln5TilgoqitjeHNsiiGdqe/plopAWA
arj1bsXJX2N6pIOmn386m6xXqYPKii4Jp1pKpIc5lV4KjisHYA6gAAowALkaZOgWY51FqayamW0K
k/CIoUHalARKpzzopaeVbAA2AArgoAnpAAbQd5vop6pKAMPqo7w3d8hqj+0np0sXZEfqrFZpegew
pzy5AAqgagNAov73pKvarYKqhBNYj/fIqdj4nqn3qTopAXkarYqqXQYQr8p2AN+VpvZqqdJZrFY4
kUPalp66mGO4a9ZKYlOmAFWmsJW5k4HasP45i/kapLLqouaqsO0GhKMaYO4qkNPKYzpaotcnsmuq
ni5pstMZqzWZmEh6p9mGYdKqq7l6/q2BFqU023q1abPOCYslq6nXeIcESqugKnAcBmIjKqoLkKqF
GKFMW55QOJgNKLEnW7YQp7HcWLUtq1+5OpLSSmKvhrQg25dfa5tWepahiaxsiahtmWjdFbCnRZcb
NrRtW3gza4g1W7fECoO1mHm4mKVma3xoS2llplzzOWr8xrEEwLH4KbcNELKKe5TFWqhWCHcQB6uR
e7Ylx6iSdVtW+1+5umXTumMgN7NCdohLW4CNl7t1O7qTGJGImqVSu5aSG216t5ETELT0Ka0OULiR
aaaeC7q6G7rOeKlYWoN6S4Ezya+qW4bOGgCCu22BprmcS5LyRa+8S4Dpq7jfen7o/hm8EWuDNTm5
3/u6/qWrzDZl8fph8ipk6Eu9TfuCFMm9E3idfguwxtZxLQtiQxuzrbm1h/u/AMyOOQugq7izlCik
JZuJ9Auq4Hu5GQZy4Rhy8ipaEjzBYCuHjitxLUrAdqd8+BcA3IlhbaurZjpdChtgnruf6IjCKZmi
aXmWZOubGNy3/8q6jSrDIDyEHDtlm1uGHfd/c9vDPsyMK2m9Oru3RBqnnQfDHsyJeqpuHJufMraw
SlvFKUydptvC1Ei8SOfFyCuwHflfrZa5N/yxcku3aCy6QeyUtGiJdgiV0obEkQVaA5thujoA+3Vd
/ne4eqy+aLe7e8ySWOima8x+/r2Jj2+ZaYRMWQq8pLu6ALE7iKnqXdi3vmqYvqjcsO+bxQMayC6s
cIu6cdG2pBnLsWPssWdajgHwyJDsc5IMzGhMssfauENMk1wMcePYyZM1wwRrANOqyB67k3hswkq7
ysGcAJIczKq4zdr8zVUcv5l8um6ch4NMy0sskGwrrea7XeJ5XE+ac624kLm7ykzbuE6JvZlazl0s
eit7sbgmYqlXyhF8zeBce7vbzQiwzdm80N/szSK7mfgsoONKzngIZNHGzJJ1yKcneBV2vgZ90LdH
z+DczWaXzWdnz/fqvmq8z8qaoRI3yxY7xx65ZVD8sZI6xa9Zz9q80A6d0A8t/sw9XdIQLdIrbayg
aboWTbEpq9GQhWyNKZANDHL61cjfNV20edIIndIlHdRBDdQirdIBXL26N7Z1CKtKvYWqd7ygmq7i
e7Buq6u6XMp/Op4D0Go/TXs/ndc+/dXCzNBeHdjear0BCsi5eJ0bytY/yIG3umHTurE5bbuIiNJC
7c177dUMbdJgrdWVSsnwyJ7J+rhbiNHNarFRHXr61cTQPNdyO10Hi9dLm9A+DdS0PdSzXdua3dWt
6o6VDNN1N7zGJ9NiSNN4N9VRqqNCRgB3/ZpGDdF7fdm4zde6ba+N6Lh629Kj6a9/29Ysu6Tuqo0H
S5LFqK3Ul5CKnI6afduy/j3btt3TfC3dfs2qm1nMFE2DaR1/a+3UjhWKxC3VCjDK403XfzqCO63X
7r3esm3b6m3Z7T2sVtrbb/rKLDzawl25FJDONEoAxVjN5Wjer1ebt/3Qzx3i7A3YeX3QlN2jd8vS
FKnByGyBtazfi6Vc4Nvfqjmt7hyCOi5d+8ncX73gCN7XJU7iDW7UNut2K1zOwA3jZSjjikXjGL5f
/42/JEZ9h6vjZ4ze6n3gWz7i7n3gXP7XmF2lF8zi+krRFumvaRvHcwmt/rW5tCve4324c8vc3Azk
QK7geS7kwCzWaoqv2Suu4mp8zLrmFk5cUc6k8IbjqPrOdf56f43nkj7p/kR+5/A9obpJ31Ibyy/q
z1/Mdf0lwtmF49AHrEjLehr245Te5av+5Zsd1t3ayme+wRxsvE7OWHN52oEWcnFNjnReWib53qs+
5Ky+3vHNzUben7z3sBXJ6RZY4QEbvsL2YTasy42OtAdA1cI+7FxO4t6u4GJ+1HgrjaB9yf1a6Ir9
g878X6FspgPAyL9uwvyb2XgeYkrHcMPO7YKN6dGJnqC91JFL2oau7ja+67o65RhtiqaOjPHa7UAe
kiJ5g/nu6id+8BFt5oetlm1Jtfj3yTgWyu9ejsgtWps44g8P8SKGcznnbwcw2wpAcy/feIonkiE2
kj738kWu7EDqvkk+/uHYiHEI3PEAjW4NDGKjbtXkbdcfHuS3HZWz7fRYufQIoAA4R/M/R/U9h/VU
T/WxreIsXZby6+wIh+63juseSsMfBuCkPGAH2/KrDs0Vt9AFQHNx32qsd9ez7a66mgA2r/fuyvc5
7/Wj+8e/nfGHCfR7t+5DuK6pne03zLUL33fxCuRz3/RxX/k8x6BPmvevKc877fKQJ99wCIGGzbNb
iHE/e6cCm+icO61jnOOmXogjuOpzX6NP/5oul4qrrvdTf/AxH8m7HY3NbpgEjO4ru/r9DWgaNrSP
f+3e5fgLjvk+be8+Xfna7GWiqt56P5I+ras05wBE3qptmrMRnroL/of4Uadv27arkcmVAY5mFKZh
t435c1//dB/32lyfAohfs10Avo+/EICQWmgpiZJMSu3L+bSkNE80VdeEaU+3dWemlms81/d8MQ7g
odEIFI1HZFK5ZDadT2hUOqVWrVdsVosc/rwGcBisGDsGh0IjPVwP3e8DgSApIOoZfF3Rw/l8YTQ7
C4oMDwuHhRCKkQuPD0IPFsnJlBkTy5cXG5qcG57Pvp+goa1S01PUVNVV1lS1ILFYgwEF2oNENDXd
XbbeAgIDPMG7ursFhsREiQqLYGY8RLwLRY9ow8gNw0FKbm4bmBJLTnHQ8h6EoNzWdfZ293d4VDeg
L1mwi5+BhbSC/n7efzYG5hQTlmdZQQkGkiWjc0EQnWjRLhyYkAhDIQUiDHXjKOlbOJA4NIkkaY7H
n1FE4q1k2dLlS1MFDoiy96OWGCD9ArQB2EagMILFhJZ4ZmEZswUJkF7EQ8gBh4uOMJSYQKHj1Uog
Q2qN0cnk1xqigJCCWdbsWbQrG8CqaYCCWxEG1Kzh98buq4EP7xgsSPHgsg4bBj1E4LbC08ETSkzN
xhQrChIoPl7SSnkkORmewPZJJ0RlWtChRY+OMmQmPXszaym4NcCfZ5514TAjaKdfP9saGBQuGOzo
vkN+C1UglACxhwXRNCSX+lhSIxVdNWnWvNlchXRkSW/n3v3s/qvTbRVSuLXPn79ed03nrc23ANXc
vCs4S4Qb0V5tEllXrKpRA/LIIHOugxgqq+GYYz5gYI89NhmpOusWOG2sz7yz8EIMW1krvJoW0AcY
MM5zgyde+PFhmGFuU9Go9v7iTwLkgABwAqhgFEwpjkbgiIPGdFsQmR8f6WOxy3iA0CQfsqswQyab
dHKKtWhKbTwP9ClgH11IHHFE9lBEsQ4XanPGAoswYOaAjBx5pihhCNEgwBU+6MgRpfbQisEWGqzT
k8xoOHIzCZV8clBCCz1iw3oAEQNEMA44Q8v07PIBN2JUVLEFhMgMzMyilMn0TRjtFCyyAEkVLJnF
FCGOQQyw/sGxBjk9iCFWcnb4E0l0UjJ0V14xjJJDe9JEBA26ZHvD2C5x+9IOog5aswI266Bor08X
y2ADSWLdgAGNYrUKkaQWa7VAIpHJE0h0H6zVOh2S1LVXeOMNDdGZUrMFCH3mylK9u8DITShL+1Gq
wN3s8C1XoaTa79OElGs21FbpdMoE5LCJpL9F5AzHBVrDVVCc6m5FsjPt5DX5ZJY2RE2WW1ijhzVj
t6yrjVso/XJFEpJixregHkIuOTY5SOo/5DpIsyplikPgKWyqqkhcoxu5gOAPLhi4QRz09NNIdg/s
LIAlURZ77FKWpFc8fV7mZ22AjlUjGJstte22aedWI4Oe/gm5klNI0mzVgTqjApoobTqAjuJpxLXa
6Ko2riCwBY12cLqSum53wjXI1nxzLMwOr96apHo0ZrtIvLJngANWFuAUfQZuGjUNKcCQ5AYxoM5G
RkizBMCtUtz35jpg2tsFk4pEpHCl28RBy70WlHPoo5eCCJVBt+cPYNIQYuZd2uDJgBXDV/3fSvVC
hwI9IrZxOIeSc0AjceVEOuNCXABc3AW7zcyy6LYOqfmTiKUAYJNeAQ2oBOqhxnqxWI0HfrAvfpWu
AT/AW+oC1rrbLCt9jSgMYhzCPvVxIAOL20bVFLanbW1raJNQnnTUNQ4AMkAsQDhgDW1IvQJISTwK
ocVt/nyxJX6BL4OqIyL5UAcj/8AIWkxJ3FOMgxQyAa05GpPVgDwCslrdQGTlCFROwmZDMJJNJbBY
oKJgISHtSdBtNNMLpYooFPItS292+ODSlpKYE6oJadgSoRXBMZ2tgKxPMdyNAAkYRkSKEWwySVSj
wlCLP5DhPKQz3SvmNrfxie9fXrpPU5hRseLIz1UdgdOAyMU8yhFSBzPMXCJdKba3raxD1XANetwW
wVdUiohw5OUR7TDHbWDETQjBFlX8SAlMbIVyy/RK8xrlxS++UppP+swrdIgTt+hDFGvIRWxuyYZL
7lKcR7wDUxh2LTiV8pgcIZe6mAlDy9EkF9GcZj19/mUEa5ZRDIggQ6PQQ5dvdi8o4rxZL83npXPe
yJg8WidWMKG8d6qyi2g4pD0tyqRq5hBYsUCTQMgAM+5FSj1DxKTcLjjE2hDjnKDiozEbehVBcgWV
qtRBOuRSsovmtDsZ3Sg2aeEWR8nFlmr8hxtRGseTqnQvLSrIqFxKAnW+tBtYZOb/tgiKZ85Tp1vd
KT4ZKctYNEIjQtRXzLxps3CaNEWrW9ZKm8qjqEqVBckEx0xpioMZuoGrex1NRhspC0aFiHQiLZ1R
01rSuPmSqdVCZzHl6hHJLNOdLYzhM29KT75mtixf1aeMquQuHw5WpHC82SZ5SQcvUYthLX2TSx+L
/szoWBUzNM0rTjV7282ClWUz8ZAjXHMX70lwdSglLkmVilq3spaPUHXsa1cgSCxubXkAnJA6cHtd
s0yQLRz1Qk5gUVYg8iuDGNSgaVGrUrc29gRxdW4msnKZQRbJmc/Dbn1bwkjxdBQN29NXeIHovdOu
NakGaY9qGavQ9k4VkIC063QtN6Gb2lfC7KiQabYLWHf9YGbBbdvalNoAwihVxMglzGpbW6oEszCy
D43uxuAJltpidsIzvkKFJ+jI1PiBJiJqm3hTSs7wIZet6W1sa1Mc27oaCJ58AmCGPSNjGkd5eoc6
W34VMikeAzQ9sflxWwO8VL4cuI+uPXJkzfwN/ogyj5AxlnKbs2BjeugzDB5aADCIBUEOnzVu8Tmt
agtMZNayt8ySJViRBvlisFRXr25mdI3BVuXrfUFChKX0llMaYvIet8SMPbFjBf3admaiK7ONbwzd
RSEoN1rVXCjCr2rCWzvX686DBWixjkvOEoOZyMIo5qdT7MJkrku6V/1EnJ+8amRDQSWQZtlCsFxr
CPqYWtM+76YNvNJet3TQ/HvvxhisRZqe+tjJJvcSlh1n8dB5AEJkm3j3tbbUthGhQMHbrrXta7kC
mzJphuELu8bmcgc8CabpLssUIhYfvLt7lZ7LtUm86Xkn1MhG3jZkA/lO+TaZZLYVeLkJrlsx/pxa
w7j0ZpYunWu0HhTbeLgRcytuZq5cfF2HfrBYFt3xjn/8ryGn8wIazj0OA1c4BXH4rlnOUhPgO98G
sgxVHTxdYrcL4DgXeEBA/oM6d4a/Pd7yviBeb6PzmqUnZq7SG1rob1dV2GtWUqqpLmWdt4W34LuF
yX/IcNOEfVRHF3unzQ7qM4s6uoh+eoS+xvG3rzqWO7ceSmRT8mhzE9BJd+pC7035bG8b7S50L3TX
TshAieLRia86GV+N7t+a1d2+CHtyx97clyu485PNYuETHYQ2kF7x+Fy83LXuw2gHX6BDD7O9xa5c
l8ceojJVO4TAHaEZjl735F58Z1mpouBX/rK/RX+48Vuu7dhXZvb6Hjzhuxb6ebp9+hKu/ulzEtqu
E7VExAd76/l++fCL/5T7hi8nos7FdGil9UO29kuNAIS/hSuq/6I/+yuyMaO4v1s6ZXI6bzO/84MF
ARzARmODnuIo3LMUPPOvEuG+BvQ7U8k/pksymQM3JrOciRog9dNA7CrA3Xo/4IOU4DKdQCCwtzKx
1yu78OO8/XuoVKK5cIuzDJRBRpOJDuyuD2SbkFo9cCrBHlQuFISszZMt/7krVqooJVxCdDNA70LA
ktOyEekHv9g7YhKz17O8K1ywFaRAHfi/T3hBL/zCKOPAJswqYhERMxRBOCBBdJK4PmKo/jdsJyKM
QyajQ1A4NRiMQTzMrK/yPRskQ5m5RJMDgpUDlSJDsFKKwMfiPMFTu5lTpdq6w0icsC64uurqwwTk
OuBSFjV0wDUMNDfMv1BLM/57ISNssheknlSEu0l0vz7MMuH6rzMURMsbu06DvUMUv84jtbVjRB44
RUgMRp36OOvrDBCEtoDyhR2sRRE6Pr8jszdUQSLkt/IDPUG5Rmy8qFWUs+vzQ8KqJC4zMfhAPvA7
R/6hq3Tsk1SaQ1UytjRAxXe8LoK7JkB4QnqsR4dUlkJEPnLUR350L2UCSMrqRdCbqJs7SPuyMHnk
RuwLwaCzpfEaxwekSGc8R0S0yH+c/hyos8DNiDF39EhpmgccM0CZwD6T/MbRIj7KM8FybEZ+zEVR
a76YvCu8ajubZL9fkTORhMISWaNX3C8rDEqsBEXlO0qknC2lDIV2bMr6sjC5EyBX1LIcBK4zFI4U
QLGJu0WW5LajlMOAlElAkaeOFMvb0kZiDJhXtMf/QsOjExAr1MoyKzR9K8Lao0ZzsEa9REhm88An
jDxMvLu50MQxI8z1MseKlEtdrD27bB4JsTnEe8yt4ksxLEZ6DDqG20mGojjMM8wjE8Vvc7pRw0jp
qqw4y0vT5CuVocT9miRktEw8Y8KIxLwVkM3ZdElFFAmNPEKm7M29DMPU5Mmh6gkF/jQNmVDOuITG
RBw8F2NMsBA3YJTO24IwMdzJkbRMWrMLzETOznyM78RIxXw+8Sy26DRP3xxG7jpA4dS+S+SeIEi+
+OwIo6zN+rS9u8owGNRPzYrMhRzDG2TPDtuFAeVOXGS6l2zOr2zEjXPQzKJBybTO0TpGswqClSxQ
mJNLrlQzFszNDv3FmgTRGqJOyZxMoKvMM+weesDQDE2yxNzQT7jPAEoHg6RRe8qnKWFIHptKTNTB
91TR54qtLKRPryi1DuUM3DtSJK0njQJO9cxRJ1VLOKAgKUWytIs5Ic24LL0cI53RLpUe/qxBv8wz
HYXSNDxTFUtButzC0NQ43CvN/jh9JRvFiah8RRFkTSacAx9tryqdSw3lxedr0x7YMUEd1ETiLINj
SPBSOPYMKQLQRD39o9ljMP9rscr5UxcMwEvF1DCaU0NlUuGrNC2BhUZdzph7kPEz1Uml1LBg1VZ1
1RrS1PSctR8yliiMmVD1FylNxBbVwpg8tOf8ShmFU2GFpS8lRtW8TkAMQTYAhlv9taazUl48VV+t
RgEK1ms1IGKtwbMM0KlUPT0U1VENtgnEuKdrwXNFBmC11nU9Ge0CU57kOhycyjiIg3D1o+UbV3wt
CSxVVbYLVHX9V86JR4GFPzEV0wQ8WEN8OdpERzWlPYj11WqlWFfqgpwc0XfF/rtu5QcgAIaK1MV+
xM0l21frYKWJNdnN+c3UPMt2U7jHuzvtkYNgeEZo5NUWqkBDs9nGbDt/1dleCViwqq4w7TpIadmh
pdetnFl/jEMFZVqTyKrcg9owcrUlrcRkBdrKXBs5mImY3VXyw1cizVKafFqyLRQI5cOB/cORUqM1
CFWYvcKWRExSdNhmAlus6te7BSOpLdbQStuMnVC8ANeEhakW7dOkTVXE/QQ2s9vFpSZj608JNUNk
7day+gWODcIphVTb/LzNLYessovPPSBXKyOq7Ubty7PSXQs5mIMUBTyGZV1pBc257dC6nV0Dytt5
JN2/pEoIellGfdsVVMzb/tTc110lp/Vc5M2Qp6zOWfvPYyXOHOxdhfhRqgokw63Z623E2KUe7d3e
C6ldd1XNEvXb4eQH8u1Ycf3Y/UFVByveNsVL94Xf6OFZx11NtW3efiFfcbVIIBXeU7XP9b0Oa3xf
AvYO9HRX1ZnVBAzauogDoq1cB36vLJRD6x3ZczU22b1gzrmwWLXB5g2pP6zV3vVdCWTYzfvMwmXT
Ce4Bkmk1C2bh7TC9Gw3TjI0/b9wXEAbXBEO7mSVXGO1h6DuNgpQ+ISYbIi5ijL3fh/yvGi7adYqp
XZWsrowoKS6HHw7iKyaNbK3ObuzgSDErLfvicFk6J+ZKDnWxwz3jIhWF/vJc47ERUb19VxmO48K6
RIEg2ttxDlE80NaVW5LgYT7WUi/CJ0AeG43qLP9sSCSWGdZsgBq2YQNFU0Ljv88cNs0F4Bi1VFJQ
40tGi3aNVfUEr6BFVDZIy18g3zqGLYvbRRedqVFUMxRGXBl9ZbJp4xstRk9FS3j9yy/+tJb0zDGm
XnPFUlUmWQx0ZWNOCyZkvNEt5IVTvRxMg1Be5G5b3V30tv5LygqM4kkGwEDl0m02lC+13U32VFsO
Z7Us53MOXlJF2upl50hupmvOUvSDlHmGl27W5ODc4kL2YH0eWl2W5rliznHNzZCJ1ncGFMyJoITe
FWR+YWWOQpYVPomW/oPHkb0DRdBqLrz+K2hspoerzdmPFg3UVFnwVdscPSsu+eJSvTg8JmFJFkiu
2eONljovmOlWrukmUdL5fWOlvlpxruEBIABSDTUHPt9SLmquPuqvGM2Z+OSlZmru1S6Qwz1C1unw
5bItkYOqlgPd4NqfJuWWNoctgmlqBYSe5AV5JmubNttkhuoxhTx55V23JoA6vuO4hS48Hmav/mrQ
0dgq9usMWegDlmxkVNR/AOG3Ll+5DuqsADaizujHPj8xcOgkpGzvAGyRFuzB/qbSxd/e1Ye45jbG
1urb/B/HLu0cII8w2Om5UG1fyVu0dui1Jsnw8okBeGvEvlchbGwy/h5o3lbKPxAsD9sX4faVQp0h
+q3lvo3XEJxtAli3/XvgxFQywSvF6TZtQGi4n1OD7LaQuNPgLQZv725PNRhv/Q4G8jvf5dGi/qXZ
9Qa9067T4I7v1f6c1h5pJ9USvpXhX6hqCSeBRo7GXO1frxTwAf+Kt/htKMQ+BE9wVpRVaCtxqwXv
/Nbvqk4EmfJvSUWzYP7aDadgva5TnQhx7pBfnJbKMuTiRJ0gCR9vFn9uzMVwf5vWGWdfDxcnHO+O
DI5QtEXuZT7xkIoDCa/q22ExpHxYmkXyJD+J6tYwJm/yIS5UzElryINjyvSF8Q7y5Cm1iIJzVB4H
vJbiMKcbIiLz/iEuuNbeWylnZnili1lY7vE2gO+kwIdNXy//8h3ocH9CQ/W8Mz0fDZuiU59VczW/
716YhTZf7rhG5UmdLGtOX0bnotNuaCPW5km3gt7Dpk02xinX5wSeoDbX72OYS8zo1bsudfbW6+BU
zb5e9XjoXks37gaPv+zsBSvv9Ap4ZIKOYGiXcV7vAR3bpj4cw2AXdnioZ9HtbuQG9CMulk639YBs
WGnv6mkHc1m2wf3Kdm13h+02y8fFdHAfTl7o9OWmgFzvt19+6XQ3bR3bL++ywXdHC6fW4oGN6E6G
aNmw8uVe7kXOcHMlpDqf4EQQ6TGkoYI/C25/4aoF50y398dz/vhatyvqGOh1HtJ/56Jq58YAPICN
5/gmfPUpr2UTl3J8h3iTD82KH/CLPzit48aYN4uOX/d5B/SQT+4SGfSHX7fwzFxbIepy6HmL/3nu
fnmYH3qYyORu31Y4tnkqH1NHafp1u3WJn/jdTvJkwJo+8AHEvnqt0/qtl7Vi/ydErXfsjFeyX+6k
kG6qn3GrV3eUCPp4lvv7UkjuNvBi8VZmtntLy3nyXmd/W3lQYJCL/wMJSQR1B3rCDwLDbwnw+Kvi
PuJjp/cTH3uyRwCUd2fKR5BKtfpkKA8wrzPLakXP/3yWgFXb9/Obx3sFXou914e+x+hz33A/mDt3
wfxbkP1G/qyzi1egq1d13B84PpdlP19zvG98kwv+Y/hv76f8X6W78piPKzP07r8O7HEk29f46XcH
IujmnnXtWM9+4mT6h/cBRQf/UEBDesB/dIkQCFhyGXNqvWef4D8YiiNZmieaqivbui8cy/PXBM1m
YRh3FP+vURA2iMbi0JhcIpvDZ8MwmFIHC0aCgdVut9ksNywek8vmM3p8QBjYDMk7XZYYCLyMpdeh
8fv+P2Cg4OAfTt6OxkaBT1CjElHQoySTU9FBFZXBVVcCGJgcaKjoKKmZwgTdnY5iEaHrK2ys7Gzh
4U4GB1AkVFLTpC/lLlIBAebUl9bnp1dps/PzKJ3dbQ5j/lErbbb2Nnf3jGEOYp4PI9AR1G96b3Cx
sYHY8jL0PP2zAoPCKZ3ENKK1hw1vAgcSLDgLh4Zb4xaZ4wUJGMRHTCYWkWJsATJP8JLV6+jRVBhU
C+xQ4MHKIMqUKlfCMKTjTg9dDnupi1hpkrEBCt6RkffxZ717+U7ps2JFmiZ/Q0BgY+n0KVSBNhBe
UJirnKObwSKiu0aRmLFTnMz4BGo2mkgCFJCOTGqtacCocufSJTQ1kdVcDR/y3fqr67qKOeFwiXf2
MBqh+SQYXXC0bdIdkDPQbFr3MubML+4mpBZTZl+uom/2vTS4C1nEqkNOeFxSIexc12bH1Wz7Nu4a
N8C9/lylCHTomhLPnXuS8+jG1YcV63MsEjb0PJFoT7Wc+zp2udU59Mal9wm6rX5pUvKqpB2mBQiU
K7/3RmQqPHg696Buv3rt7Pr3o9zeGSZWjjh0hDoDAmaERRehxh49ii3QHCrQ6ZHQb/dZCBB/GWpY
kA0UevadgLNRJBxxFF3igDsM/gTfax/2sNA1u1l434Y12sgNEv/59tteI4Yn2kyBRXKcWiqW8iCS
zqkVnz8T1kcjQAHNiI11N1p5ZR8dVvMhQyH6JVxlgT1UQILpGSmKPu9NEFkiTn7XyowiTCllflja
eWcLHdoCYIA/DjfeMEp8NcSJCp45BoSuTWaSm7LN/vlonLPhOSmlKdiwiHyMdimgn+SN9pV5xg1W
FoNXmBphXo2+dSFTMlIpqatwxVgprbXeABCZ3XnHY3CDfuoLJNP9QACKKbJ3KotMMurmdLDa+iy0
duG6SpN9zsSXoGP+KYSnglEhABWbnIWsmvy0uKyTvdTgbLTtultIrlVVWw63f5VnYHnB6mtaWDx5
lCyqLqZbWVxVvnswwjFg2lubfeqL7YCSZFuvmMch19Emz8XW6CJQspswyCGzEG+q5PQYaqDABHPv
gUOUWQVhoSA7gVpLLlnywNSJvDPPLV3q4a6bahuxMJWA+iMU/GIilszlaozLrhM2S1sIVK/bM9Y8
/reCqR5Bg+ZnvSobrVXY4RF72hxOw7exqlNDaUKdWcsNMtfjeCf0tWU/TBzfYjbyMhVMi2Gq0xKq
6gOckNZp8NyNvwunk+Pw6CWwXQ0DnthOjKj0FMUmm9RaOOesc5Svfuw46lgL4aZ0MgUJseUiFod0
sN+mx2IdouvhNuknMJ468O4WLMRCA+dtk75ZYUtds2TqZJQmqPQj71WLfGZfrKfLeWvw3YcMp/Xh
7/51X5h3ey0vunDL3Ug1t9UPuukqDiwKU3l/P8KvxiQ15b2OPSLsqrKWkSgraqObU6tKZyn8MVB4
61odj6zVkE6RBljcAk84blYS+EnOeoqo0Px+/se97dkvbg08Ia2mIj5GBChAejtZIxwRjujZzHBX
uV4IsWfCqr0NhT7EkpR4CMFNqe8HEtQFOSZ0i7WoxYYMkR+BejilEsQIgT+8YgqHwULXcdF18oqO
VXZ0QxzuEItmPOMIctSnI8okci+SXLrGpz000pGOlrnG9brYxsNxZ3f8Y5wI6yjIBppORJ8BggQ/
2LYnVkiIgRwkJLFIJ9p4cHJ69GIlN1DIOUaykyiM26weqEU+HvCBGDJl9jypSu89MpSlk13EerfK
WdLSBVIEJZzSyMNa8rKXvvwlMIMpzGESs5jGPCYyk6nMZTKzmc58JjSjKc1pUrOa1rwmNrPJ/ksA
cJObH+gmOEEAgBCAs5vfLOc4xVlOEazTA+n8JjkD8E530pME7YynOsMJT3ni0536ZCc69+lPcwq0
nuicZz0Lek+EMjSh2qxLQ8XJTn4W1KEUnahEK5rOeY6To/L06EX7adGOZlSgGwVpSFNqUYq+M6Ip
dSlASxpRj4IUoQ+VC0xVStKKvtSeGLUpS+HZUnoOVaVGpWlJ97nRiy4Vo0k16EqD+lSgElWpI2gq
P4tq1Js+hao83elKc/rVqGIVrEstKlDTKlGUWjWrbUWBTZvq1Z4+da1vzehQtTpXrq6EoE5NqFY1
6lN8qpWphpUqVut62MW2Va5RvepPHzvQ/n9K1rFHBexi98pXlvh1pCYNqEjrmliTGhatUP0raTFL
2NMmlrKT9WtrCZpTr1q2sG6tKk83OxeYHlS1qB3rZXF729KSFbIfbWdcT3tb26b2rs4VK2lHi9m8
Kla3KpntVB3KXNEWV7hmFWp3V4vXyBI3uEmtqXGxO9jlGne4YN2qdVGi3suKlaq8De19z/nYmULW
pbEVLGr12s/5/tWbns1ufC9zz+baFb/2XPBrA4zg3ka4uKBVrnZdC1yOUpbADj5nZw+c2wSTuMQm
PjGKU6ziFbO4xS5+MYxjLOMZ07jGNr4xjnOs4x3zuMc+/jGQYSAAAfBnyEP+AJGDbM0j/uvHyExm
spKpCWXsTDkAVY4yNK+MmyprGcsiu3KSQeBkEYQZyUYmM5nLLGY1W3nMI3AzmN2cAidrmc5rpjOe
2RwCO6f5zHtOsp/b3GUvr4TLhj70nxG9ZhJMOc9sxnOb78znEzg60XJ2NKRLkGdLB9oDlc40oaGi
aDOP2tOdFvSfGR3mTrMaypdu9KBNXeZA0xrWqaa0q3O9aljvWtehjkqjrbzoSCNZ2GY2tZiNjWxV
H/vWyyZ1s4et6UcDetSGxrWan2ztbHP716LeNbGJnetwa/vY42a2Cc7tbHRPW8/Plva10+3ud0c7
3tH2dqHBfe5x71vf4GY3p+8tcFLH/lrWp67zvwe+7jS/OeH0Lji+BXJkfs+ayBRf9MWnzelaN3zj
2p60oF/d8YfPm94Lf7a9TR5xg0zc3xh3ublhDnCRq5zX/950n8vNcJLjWt4jDzfPV55vclu84kQH
estj7nOTqxve1H6Bzp2d8p9Tvd7dlrbQU2LxPSu72NnuuqfBvvWlA/3d2965xm998KaXvc9qPzvW
2551gqyd2ty2e6J7LmuC35nvezc4tvv+d1QLHOK8hvbgyz71udO91IknvOARH3SDgzzkSSd45RsO
aspPnc9xrjzOC391xqNEz+42PaPfvPBDOzzkJGe75k9NebT7HeGytzztFV9y0uMP/uK8DzXCf8/7
Vu9e+L/GtPGJienlM7/5zn8+9KMv/elTv/rWD33yZ3H97XO/+97/Pvi/n/3x4/ikADj/+U2g2fWu
n7zrLYh020uD7f6h/S9IPyzs/4rA+pD/J9C/TN1fCgBg/knWINCfHxCgCiggDDBgILAVCvkfUeEf
+plfXnFY+nUU/k1Wek1gYDVUBm7gcV3gB4KYaamXBtoX+uUTU2XgBHIgiLHgRK2gCQpVXNFgBU4Y
DYbUWYHgBmogDArYceXTBWrXFUGgfilXTdnWDxqheDUhY/mTFEqVQZnWXTkWCvofek1hS52UQqmW
FlphFcqfdIHgeClVWqFVCQqY/hiyFAQ6IM9gYA7yoG9R4YCdYVhhmGXdYXdtYR8qofvBlx46IVuV
ofopVvzRoXm1FiG+HyNaFUkZ4nOFFgMhYSO+ViKW4AiKIGuNl30x2Bz6IQ/iICCK136R4hVm2BwO
YQwWGBHuFx4GoCKK4nk5IVRFYitu4mhB1/1Y4izm1ideYgnsoRsuYnM9IkpZIXUFIhMKox3uVXKJ
lBAGI4Y12C861xcq4i0OFzbS1Yh5jy/6IQIyViI2Fh5G42GJIjKe4TKaok7F4jp+Yx5KozPW4lZ9
VyreIzx6IjdWo4gZYPCE4znGoiwO4hMOJB9SIQWeY1nt4Xvlo0w1JGA9YimGhOFbLSQZwqImduEp
QmRmpRYt/hb+yCEqVqEFjtgKJuMOsuM+FmQX7pRKmpULPuNgWWJKxuBL2uEIyuBA9ZcI3iR8rSJt
kdNKAuUn7iBDFaVC/SRSflj/QRIcRktU7hYWTaXjWKWtYCVUaGXIcGUceuWkcKKGgCX5laVZniVa
pqVakl8EAAA7
------=_NextPart_000_000F_01C78015.73E5D860--




From sip-bounces@ietf.org Mon Apr 16 06:48:02 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdOkN-0006wU-DP; Mon, 16 Apr 2007 06:47:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdNgt-0001np-Qm
	for sip@ietf.org; Mon, 16 Apr 2007 05:40:07 -0400
Received: from rgminet01.oracle.com ([148.87.113.118])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdNgt-0006KA-Fl
	for sip@ietf.org; Mon, 16 Apr 2007 05:40:07 -0400
Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111])
	by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id
	l3G9e5e4019465 for <sip@ietf.org>; Mon, 16 Apr 2007 03:40:05 -0600
Received: from kimshkr (dhcp-samhwa-10-179-111-109.kr.oracle.com
	[10.179.111.109])
	by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id
	l3G9e4oH003374 for <sip@ietf.org>; Mon, 16 Apr 2007 03:40:04 -0600
From: "Saint" <saint.kim@oracle.com>
To: <sip@ietf.org>
Date: Mon, 16 Apr 2007 18:40:40 +0900
Message-ID: <000f01c7800b$4ccdcda0$6d6fb30a@kr.oracle.com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Thread-Index: AceAC0tMtwRgVQI5Ta+UFehJP921hw==
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Brightmail-Tracker: AAAAAA==
X-Whitelist: TRUE
X-Whitelist: TRUE
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
X-Mailman-Approved-At: Mon, 16 Apr 2007 06:47:46 -0400
Subject: [Sip] TCP and RPORT - exact behavior
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0502274942=="
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0502274942==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0010_01C78056.BCB575A0"

This is a multi-part message in MIME format.

------=_NextPart_000_0010_01C78056.BCB575A0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi experts,
=20
In  RFC3581, rport is specially designed for UDP case but as well as can =
be used with TCP.
Question is , when rport is used with TCP, then should I have to =
reconnect to SIP container with rport value ?
There's an pending issue between CSCF and SIP container, SIP container =
send message to CSCF with rport parameter via TCP. CSCF disconnect =
current TCP connection with SIP container and try to open new socket =
with rport value.=20
Is this correct behavior ?
Is there any detailed guidelines about this kind of situation ?
=20
Thanks.

------=_NextPart_000_0010_01C78056.BCB575A0
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8">
<META content=3D"MSHTML 6.00.2900.3059" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D837303109-16042007><FONT face=3D=EA=B5=B4=EB=A6=BC =
size=3D2>Hi=20
experts,</FONT></SPAN></DIV>
<DIV><SPAN class=3D837303109-16042007><FONT face=3D=EA=B5=B4=EB=A6=BC=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D837303109-16042007><FONT face=3D=EA=B5=B4=EB=A6=BC=20
size=3D2>In&nbsp;</FONT></SPAN><SPAN class=3D837303109-16042007><FONT =
face=3D=EA=B5=B4=EB=A6=BC=20
size=3D2>&nbsp;RFC3581, rport is specially designed for UDP case but as =
well as=20
can be used with TCP.</FONT></SPAN></DIV>
<DIV><SPAN class=3D837303109-16042007><FONT face=3D=EA=B5=B4=EB=A6=BC =
size=3D2>Question is , when=20
rport is used with TCP, then should I have to reconnect to SIP container =
with=20
rport value ?</FONT></SPAN></DIV>
<DIV><SPAN class=3D837303109-16042007><FONT face=3D=EA=B5=B4=EB=A6=BC =
size=3D2>There's an pending=20
issue&nbsp;between CSCF and SIP container, SIP container send message to =
CSCF=20
with rport parameter via TCP. CSCF disconnect current TCP connection =
with SIP=20
container and try to open new socket with rport value. =
</FONT></SPAN></DIV>
<DIV><SPAN class=3D837303109-16042007><FONT face=3D=EA=B5=B4=EB=A6=BC =
size=3D2>Is this correct=20
behavior ?</FONT></SPAN></DIV>
<DIV><SPAN class=3D837303109-16042007><FONT face=3D=EA=B5=B4=EB=A6=BC =
size=3D2>Is there any detailed=20
guidelines about this kind of situation ?</FONT></SPAN></DIV>
<DIV><SPAN class=3D837303109-16042007><FONT face=3D=EA=B5=B4=EB=A6=BC=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D837303109-16042007><FONT face=3D=EA=B5=B4=EB=A6=BC=20
size=3D2>Thanks.</FONT></SPAN></DIV></BODY></HTML>

------=_NextPart_000_0010_01C78056.BCB575A0--



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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============0502274942==--





From sip-bounces@ietf.org Mon Apr 16 09:48:04 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdRYg-0001NL-8s; Mon, 16 Apr 2007 09:47:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdRYe-0001M1-Jc
	for sip@ietf.org; Mon, 16 Apr 2007 09:47:52 -0400
Received: from zrtps0kn.nortel.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdRYc-0000FE-B5
	for sip@ietf.org; Mon, 16 Apr 2007 09:47:52 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3GDljs10494; Mon, 16 Apr 2007 13:47:45 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Mon, 16 Apr 2007 08:47:42 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
In-Reply-To: <0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
thread-index: Acd/2sf6ifDfzFFtRFW1Vq9AiYyy9AAUqzDQ
References: <4616851D.5070305@softarmor.com>
	<20070406174901.D89C45C027@laser.networkresonance.com>
	<46172B40.8090107@softarmor.com>
	<20070407151244.87A941CC3D@delta.rtfm.com>
	<4617E6B8.5070601@softarmor.com>
	<20070407192220.253931CC3D@delta.rtfm.com>
	<46194A1A.1020705@softarmor.com>
	<20070408202105.0F2725C027@laser.networkresonance.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>
	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
	<461F00B3.1090206@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
From: "Francois Audet" <audet@nortel.com>
To: "Dean Willis" <dean.willis@softarmor.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: sip@ietf.org, Paul Kyzivat <pkyzivat@cisco.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


> > Euh, not. There is also 3)
> >
> > 3) Have a policiy in the proxy associated with Bob of not
> >    delivering anything but sips.
> >
>=20
> #3 only works if all the proxies between Bob and Bob's home=20
> proxy have this policy. For example, Bob's edge proxy may be=20
> different from Bob's home proxy.

Dean, the request in this scenario=20
was sent out over non-TLS sent with sips in
the first place. The damage done.

If a proxy in the middle want to upgrade to sip, it can just
send a 3XX with Contact: sips


>=20
> Only if an outbound proxy is used. P2P very well might not=20
> have outbound proxies. Remember, SIP DOES NOT REQUIRE YOU TO=20
> ALWAYS USE A PROXY.

Dean, the request was sent using SIP in the first place. If there
is no proxy, then the 3XX solution makes more sense.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 16 11:43:36 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdTMV-0002lQ-P5; Mon, 16 Apr 2007 11:43:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTMT-0002lG-Sd
	for sip@ietf.org; Mon, 16 Apr 2007 11:43:25 -0400
Received: from ihemail1.lucent.com ([135.245.0.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdTMT-0004yy-5f
	for sip@ietf.org; Mon, 16 Apr 2007 11:43:25 -0400
Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l3GFh4bQ019059;
	Mon, 16 Apr 2007 10:43:18 -0500 (CDT)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by
	ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 16 Apr 2007 10:43:15 -0500
Received: from DEEXC1U01.de.lucent.com ([135.248.187.26]) by
	DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 16 Apr 2007 17:43:12 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 16 Apr 2007 17:43:11 +0200
Message-ID: <5D1A7985295922448D5550C94DE29180FFE802@DEEXC1U01.de.lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on draft-ietf-sip-location-conveyance-07
Thread-Index: AceAPfBYweGjL5+DSgeMTA2bPWGTpQ==
From: "Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>
To: "IETF SIP List" <sip@ietf.org>
X-OriginalArrivalTime: 16 Apr 2007 15:43:12.0619 (UTC)
	FILETIME=[F0E41BB0:01C7803D]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82
Cc: jmpolk@cisco.com
Subject: [Sip] Comments on draft-ietf-sip-location-conveyance-07
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

In compiling the comments received so far, I came across a few of my
own:

Technical
---------

-	General: usage of Geolocation and location bodies in responses.
Obviously errors cannot be used in response to this, and location based
routeing at a proxy is inappropriate. If we are allowing location in
responses, we need to be clearer about which bit of the procedures
apply, and which do not. This should probably be specifically worked in
section 5.

-	Dialog Usage of new 424?

	RFC 4485 (http://www.ietf.org/rfc/rfc4485.txt) section 5
specifies:

   Dialog Usages: SIP allows for requests that normally create their own
      dialog (such as SUBSCRIBE) to be used within a dialog created by
      another method (such as INVITE).  In such a case, there are said
      to be multiple usages of that dialog.  Extensions SHOULD consider
      their interaction with dialog usages.  In particular, extensions
      that define new error response codes SHOULD describe whether that
      response code causes the dialog and all usages to terminate, or
      just a specific usage.

-	5, last 2 para:

   More than one location representation or format, for example: civic=20
   and coordinate, MAY be included in the same message body part, but=20
   all MUST point at the same position on the earth.  Multiple=20
   representations allow the recipient to use the most convenient=20
   representation of location. =20

   There MAY be more than one PIDF-LO in the same SIP message, so long=20
   as each is in a separate message body part. Each location body part=20
   MAY point at different positions on the earth.  The meaning of such=20
   a construction is not defined, and may cause confusion at the=20
   recipient.

	I would prefer that this is separated into sender and receiver
requirements, and put into the appropriate subsections within section 5.
Need to sort out the RFC 2119 language when doing so.

Editorial
---------

-	1, 5th para:

   Often, location is sent from the User Agent Client to the User Agent
   Server, or vice versa for purposes that are beyond the scope of this
   document.  Another use for location is location-based routing of a=20
   SIP request, where the choice of the next hop (and usually, the=20
   outgoing Request URI) is determined by the location of the UAC which
   is in the message by-value or by-reference.  This document describes
   how location may be conveyed from the UAC, or a proxy acting on its=20
   behalf, to a routing proxy.  How the location is actually used to=20
   determine the next hop or Request-URI is beyond the scope of this=20
   document.

	change "may" to "can".

-	1, 6th para:

   The Geolocation header is introduced to signify that location is=20
   included in a SIP message to provide either a content identifier=20
   (cid:) pointer to the body part containing the UA's PIDF-LO, or a=20
   location-by-reference URI that may subsequently be "dereferenced" by=20
   a using protocol (which may be SIP or another protocol).

	change "may" to "can".

-	1, last para:

   In this document, we frequently refer to the "emergency case".  This
   refers to a specific, important use of sip location conveyance where
   the location of the caller is used to determine which Public Safety=20
   Answering Point (PSAP) should receive an emergency call request for=20
   help (e.g. a call to 1-1-2 or 9-1-1).  This is an example of=20
   location-based routing.  The location conveyed is also used by the=20
   PSAP to dispatch first responders to the caller's location.  There=20
   are special security considerations which make the emergency case=20
   unique, compared to a normal location conveyance within SIP.

	change "should" to "is expected to" to avoid RFC 2119 type
language here.

-	3.1, 1st para:

   This document creates a new SIP header: Geolocation.  The=20
   Geolocation header contains either a URI which may be a "cid:" URI=20
   (Content Identification, per [RFC2392], or a location-by-reference=20
   URI to be dereferenced by a location recipient to retrieve the=20
   location of the UAC.

	Change "may" to "can".

-	3.1, 4th para:

   The Geolocation header, either with the PIDF-LO in a body or as a=20
   location-by-reference URI, may be included by a User Agent in a=20
   message.  A proxy server may assert location of the UA by inserting=20
   the header, which must specify a location-by-reference URI.  Since=20
   body parts may not be inserted by a proxy server, location-by-value=20
   cannot be inserted by a proxy.

	Change "may" to "can".

-	3.1, 5th para:

   The Geolocation header may have parameters that are associated=20
   with a URI in the header.  The "inserted-by" parameter has values of
   "endpoint" or "server", indicative of which entry added location to=20
   the message. This header parameter MAY be added every time a new=20
   location is added into a message.

	Change first "may" to "can". For the final sentence, I would
prefer this appeared elsewhere in the document as I would like to keep
RFC 2119 language out of a section entitied "overview".

-	3.4, 3rd para:

   The Warning header allows for multiple warning codes be returned in=20
   the same response.  If a location-by-reference is sent and the=20
   supplied scheme is not desired or cannot be processed, but more than
   one other scheme can be, the 424 response can list more than one=20
   code from the 720-724 range in the response. The UAC may=20
   subsequently retry the operation with one of the schemes supported=20
   or desired by the recipient.

	Change "may" to "can".

-	3.4.1, 1st para:

   A Warning header with the code 701 "Location Format not supported"=20
   means the location format supplied in the request, by-value or=20
   by-reference, was not supported.  This cause means the recipient=20
   understood that location was included in the message, but the format
   is not supported.  Perhaps the format was a freeform text format or=20
   data-URL and the recipient only understood location in RFC 4119=20
   PIDF-LO format (civic or coordinate). If a more specific Warning=20
   code is available, it MUST be used.  For example, if the format is=20
   understood, but not desired, a 702 or 703 Warning header should be=20
   returned in a 424 response, depending on which location format is=20
   desired. The same applies to a location recipient that only=20
   understands one format and did not receive that format. For example,
   if a message containing coordinate formatted location arrives but=20
   the recipient only can process civic formatted location, a 703=20
   Warning header should be returned in a 424 response.

	Query RFC 2119 language on use of word "should". Is it or isn't
it. If it is not, change the wording to make clearer this is part of the
example. If it is not, then make clear that it is a normative
requirement by deleting "For example".

-	3.4.1, 4th para:

   A proxy server may assert location of the UA by inserting=20
   the header, which must specify a location-by-reference URI.  Since=20
   body parts may not be inserted by a proxy server, location-by-value=20
   cannot be inserted by a proxy.

	"must" or "MUST". If the requirements are elsewhere use a
different word to "must".

	change "may not" to "cannot".

-	3.4.5, 1st para:

   A Warning header with the code 705 "Cannot find location" means=20
   location should have been in the message received, but the recipient
   cannot find it, either because it is not in the message, or it is=20
   encrypted/opaque to the recipient. =20

	"should have been" --> "was expected".

-	3.4.12: There are two sections labelled such.

-	5, 1st para:

   Because a person's location is generally considered to be sensitive=20
   in nature, privacy of the location information must be protected=20
   when transmitting such information.  Section 26 of [RFC3261] defines
   the security functionality SIPS for transporting SIP messages with=20
   either TLS or IPSec, and S/MIME for encrypting message bodies from=20
   SIP intermediaries that would otherwise have access to reading the=20
   clear-text bodies.  SIP endpoints SHOULD implement S/MIME to encrypt
   the PIDF-LO message body (part) end-to-end when the intended=20
   recipient is the opposite UA.  The SIPS-URI from  [RFC3261] MUST be=20
   implemented for message protection (message integrity and=20
   confidentiality) and SHOULD be used when S/MIME is not used. =20
   Possession of a dereferenceable location URI may be equivalent to=20
   possession of the location information itself and thus TLS SHOULD be
   used when sending location-by-reference. =20

	Change "may" to "can".

-	5.1, 1st para:

   A UAC may send location because it was requested to, to facilitate=20
   location-based routing, or spontaneously (i.e. a purpose not defined
   in this document but known to the UAC).  A UAC MAY receive location=20
   from the UAS spontaneously. =20

	Change 1st "may" to "can".

-	5.1, 7th para:

   There MAY be future work defining additional error information, say=20
   in an XML body, indicating exactly what the error was, if any of the
   new Warning codes are ambiguous.

	Inappropriate usage of RFC 2119 "MAY". Rewrite: "Additional
error information indicating more specifically what the error is are
outside the scope of this document, but could form the basis of future
work" - if we need to say anything at all - it would be perfectly
reasonable to delete this paragraph entirely.

-	5.3, 1st para:

   [RFC3261] states message bodies cannot be added by proxies. =20
   However, a proxy may add a header to a message.  This implies that a
   proxy MAY add a geolocation header with location-by-reference, but=20
   not location-by-value.

	Change 1st "may" to "can". The "MAY" is inappropriate here
following the word "implies". We have to have certainties about RFC 2119
language.

-	5.3, 3rd para:

   More than one Geolocation header or header value in a message is=20
   permitted.  The meaning of such a construction is not defined, and=20
   may cause confusion at the recipient.

	change "may" to "can".

-	5.3	4th para:

   Proxies that perform location-based routing may need to consult=20
   external databases or systems to determine the route.  Transmission=20
   of the location information (which SHOULD NOT reveal identity, even=20
   if the proxy knows the identity) is governed by the=20
   'retransmission-allowed' and 'routing-query-allowed':=20

	change "may" to "can"

-	6, 3rd para:

   Recognizing which calls are emergency calls is beyond the scope of=20
   this document.  When an emergency call is placed, location is=20
   normally provided by the UAC.  Since emergency calls must be routed=20
   based on location (and indeed, in some jurisdictions, there may be=20
   several steps to such routing), the location must be visible to=20
   proxies along the path.  Thus S/MIME protection of location MUST NOT
   be used.  TLS protection of location SHOULD be used, however, if=20
   establishment of the TLS connection fails, the call set-up=20
   operation, including location conveyance, MUST be retried without=20
   TLS.

	Firstly emergency calls must be routed on location in some
countries only. Secondly avoid pseudo RFC 2119 language. Suggest "must"
--> "can". Change "may be" to "can be".

-	6, 5th para:

   Both the "retransmission-allowed" and "routing-query-allowed" SHOULD
   be set to "yes".  Querying for routing may be performed by proxies=20
   providing a routing service for emergency calls even if=20
   retransmission-allowed or routing-query-allowed is set to "no" or is
   not present.  Proxies routing on the location MUST set the=20
   "message-routed-on-this-uri" parameter.

	change "may be" to "can be".

-	8, 1st para:

   Conveyance of physical location of a UAC raises privacy concerns,=20
   and depending on use, there may be authentication and integrity=20
   concerns.  This document calls for conveyance to normally be=20
   accomplished through secure mechanisms (like S/MIME or TLS).  In=20
   cases where a session set-up is routed based on the location of the=20
   UAC initiating the session or SIP MESSAGE, securing the by-value=20
   location with an end-to-end mechanism such as S/MIME is problematic,
   because one or more proxies on the path need the ability to read the
   information to route the message appropriately.  Securing the=20
   location hop-by-hop, using TLS, protects the message from=20
   eavesdropping and modification, but exposes the information to all=20
   proxies on the path as well as the endpoint.  In most cases, the UAC
   does not know the identity of the proxy or proxies providing=20
   location-based routing services, so that end to middle solutions may
   not be appropriate either.

	change 1st "may" to "can". Change "end to middle solutions may
not be appropriate either" to "end-to-middle solutions can also be
inappropriate".


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 16 12:42:08 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdUHF-0007ga-K0; Mon, 16 Apr 2007 12:42:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUHE-0007gQ-PO
	for sip@ietf.org; Mon, 16 Apr 2007 12:42:04 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdUHD-0001wi-Cq
	for sip@ietf.org; Mon, 16 Apr 2007 12:42:04 -0400
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 16 Apr 2007 12:42:04 -0400
X-IronPort-AV: i="4.14,415,1170651600"; 
	d="scan'208,217"; a="57769786:sNHT85327176"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3GGg3XT016230; 
	Mon, 16 Apr 2007 12:42:03 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3GGfsGl002480; 
	Mon, 16 Apr 2007 16:42:03 GMT
Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 16 Apr 2007 12:41:58 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Sip] TCP and RPORT - exact behavior
Date: Mon, 16 Apr 2007 12:41:57 -0400
Message-ID: <8983EC086A9D954BA74D9763E853CF3E030F10D3@xmb-rtp-215.amer.cisco.com>
In-Reply-To: <000f01c7800b$4ccdcda0$6d6fb30a@kr.oracle.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] TCP and RPORT - exact behavior
thread-index: AceAC0tMtwRgVQI5Ta+UFehJP921hwAOd9tA
From: "Sanjay Sinha \(sanjsinh\)" <sanjsinh@cisco.com>
To: "Saint" <saint.kim@oracle.com>, <sip@ietf.org>
X-OriginalArrivalTime: 16 Apr 2007 16:41:58.0758 (UTC)
	FILETIME=[26A23860:01C78046]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4744; t=1176741723;
	x=1177605723; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=sanjsinh@cisco.com;
	z=From:=20=22Sanjay=20Sinha=20\(sanjsinh\)=22=20<sanjsinh@cisco.com>
	|Subject:=20RE=3A=20[Sip]=20TCP=20and=20RPORT=20-=20exact=20behavior
	|Sender:=20
	|To:=20=22Saint=22=20<saint.kim@oracle.com>,=20<sip@ietf.org>;
	bh=F8EUSuyKskaKbErHcxWm95e02m1i8gElhnuS271w/30=;
	b=gsHJkq2hsmshFJYf2OBm7wtbfhGXcxb8tid3ybs/FCA4CgcIbYl5wD6TQJy/y67t7N1JvBXU
	VaWWV2LqpNLjUXLsObBOPUx+TgPh0N8GuCJFs+CLdoJb1jWC2FrZcIhG;
Authentication-Results: rtp-dkim-2; header.From=sanjsinh@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0805172429=="
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0805172429==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C78046.2668A1A1"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C78046.2668A1A1
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Inline ..


________________________________

	From: Saint [mailto:saint.kim@oracle.com]=20
	Sent: Monday, April 16, 2007 5:41 AM
	To: sip@ietf.org
	Subject: [Sip] TCP and RPORT - exact behavior
=09
=09
	Hi experts,
	=20
	In  RFC3581, rport is specially designed for UDP case but as
well as can be used with TCP.
	[Sanjay Sinha (sanjsinh)]  For TCP, the response is sent on the
connection on which request was received, so there is no need for rport
parameter with tcp.
	Question is , when rport is used with TCP, then should I have to
reconnect to SIP container with rport value ?
	There's an pending issue between CSCF and SIP container, SIP
container send message to CSCF with rport parameter via TCP. CSCF
disconnect current TCP connection with SIP container and try to open new
socket with rport value.=20
	Is this correct behavior ?
	[Sanjay Sinha (sanjsinh)] CSCF should not disconnect the
connection on which request was received without sending any response.
	Is there any detailed guidelines about this kind of situation ?
	[Sanjay Sinha (sanjsinh)]  Section 5 of RFC 3263=20
	=20
	Thanks.


------_=_NextPart_001_01C78046.2668A1A1
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3059" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D162563416-16042007>Inline ..</SPAN></FONT></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> Saint =
[mailto:saint.kim@oracle.com]=20
  <BR><B>Sent:</B> Monday, April 16, 2007 5:41 AM<BR><B>To:</B>=20
  sip@ietf.org<BR><B>Subject:</B> [Sip] TCP and RPORT - exact=20
  behavior<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><SPAN class=3D837303109-16042007><FONT face=3D&#44404;&#47548; =
size=3D2>Hi=20
  experts,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D837303109-16042007><FONT face=3D&#44404;&#47548;=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D837303109-16042007><FONT face=3D&#44404;&#47548;=20
  size=3D2>In&nbsp;</FONT></SPAN><SPAN class=3D837303109-16042007><FONT=20
  face=3D&#44404;&#47548;><FONT size=3D2>&nbsp;RFC3581, rport is =
specially designed for UDP case=20
  but as well as can be used with TCP.<BR><SPAN =
class=3D162563416-16042007><FONT=20
  face=3DArial color=3D#0000ff>[Sanjay Sinha (sanjsinh)]&nbsp;&nbsp;For =
TCP, the=20
  response is sent on the connection on which request was received, so =
there is=20
  no need for rport parameter with =
tcp.</FONT></SPAN></FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=3D837303109-16042007><FONT face=3D&#44404;&#47548; =
size=3D2>Question is , when=20
  rport is used with TCP, then should I have to reconnect to SIP =
container with=20
  rport value ?</FONT></SPAN></DIV>
  <DIV><SPAN class=3D837303109-16042007><FONT face=3D&#44404;&#47548; =
size=3D2>There's an pending=20
  issue&nbsp;between CSCF and SIP container, SIP container send message =
to CSCF=20
  with rport parameter via TCP. CSCF disconnect current TCP connection =
with SIP=20
  container and try to open new socket with rport value. =
</FONT></SPAN></DIV>
  <DIV><SPAN class=3D837303109-16042007><FONT =
face=3D&#44404;&#47548;><FONT size=3D2>Is this correct=20
  behavior ?<BR><SPAN class=3D162563416-16042007><FONT face=3DArial=20
  color=3D#0000ff>[Sanjay Sinha (sanjsinh)]&nbsp;CSCF&nbsp;should=20
  not&nbsp;disconnect the connection on which request was received =
without=20
  sending any response.</FONT></SPAN></FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=3D837303109-16042007><FONT =
face=3D&#44404;&#47548;><FONT size=3D2>Is there any=20
  detailed guidelines about this kind of situation ?<BR><SPAN=20
  class=3D162563416-16042007><FONT face=3DArial color=3D#0000ff>[Sanjay =
Sinha=20
  (sanjsinh)]&nbsp;&nbsp;Section 5 of RFC=20
  3263&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=3D837303109-16042007><FONT face=3D&#44404;&#47548;=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D837303109-16042007><FONT face=3D&#44404;&#47548;=20
  size=3D2>Thanks.</FONT></SPAN></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C78046.2668A1A1--


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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============0805172429==--




From sip-bounces@ietf.org Mon Apr 16 13:09:07 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdUhK-0001l7-6K; Mon, 16 Apr 2007 13:09:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUhI-0001kz-V0
	for sip@ietf.org; Mon, 16 Apr 2007 13:09:00 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdUhH-0006lp-JE
	for sip@ietf.org; Mon, 16 Apr 2007 13:09:00 -0400
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-2.cisco.com with ESMTP; 16 Apr 2007 13:08:57 -0400
X-IronPort-AV: i="4.14,415,1170651600"; 
	d="scan'208"; a="118646641:sNHT3457682092"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3GH8uSW028297; 
	Mon, 16 Apr 2007 13:08:56 -0400
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 l3GH8bls006464; 
	Mon, 16 Apr 2007 17:08:53 GMT
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.1830); 
	Mon, 16 Apr 2007 13:08:46 -0400
Received: from [161.44.174.118] ([161.44.174.118]) by
	xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 16 Apr 2007 13:08:46 -0400
Message-ID: <4623AD9C.8060508@cisco.com>
Date: Mon, 16 Apr 2007 13:08:44 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
References: <4616851D.5070305@softarmor.com>		<20070406174901.D89C45C027@laser.networkresonance.com>		<46172B40.8090107@softarmor.com>		<20070407151244.87A941CC3D@delta.rtfm.com>		<4617E6B8.5070601@softarmor.com>		<20070407192220.253931CC3D@delta.rtfm.com>		<46194A1A.1020705@softarmor.com>		<20070408202105.0F2725C027@laser.networkresonance.com>		<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
	<461F00B3.1090206@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com> <461F9AA9.4010700@cisco.com>
	<D1845680-1467-4ACC-84D9-F7EDCB3EE71C@softarmor.com>
In-Reply-To: <D1845680-1467-4ACC-84D9-F7EDCB3EE71C@softarmor.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Apr 2007 17:08:46.0306 (UTC)
	FILETIME=[E4CE9420:01C78049]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3569; t=1176743336;
	x=1177607336; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20SIPS=20question=3A=20How=20to=20prevent=20pla
	intext=20requests=20from=20being=0A=20delivered=20to=20a=20UA
	|Sender:=20 |To:=20Dean=20Willis=20<dean.willis@softarmor.com>;
	bh=70ExUCkVyj4ucFVVWdbFIDootdhhE2GYQ3s81MqyunM=;
	b=JFIXepmmoZiWPSDTQ6flwmEXM1lMd2tuza/8QVvA0iJIBlsqRXormIo37W1w3i36P/HB0Hph
	0Ab/NV6org6w/DTirmhGZdfcfQhwr9O4PVUZnVT7d+nzhjxpJBKjUVkC;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org



Dean Willis wrote:
> 
> On Apr 13, 2007, at 9:58 AM, Paul Kyzivat wrote:
> 
>> *This* message only reveals that Alice *thinks* Bob is reachable at 
>> that address. Its no worse than intercepting an email from Alice to 
>> Charlie that mentions the sip (or sips) address of Bob.
>>
> 
> Trust me, the spooks look for those too.
> 
>> If you want to prevent Alice from disclosing the address of Bob then 
>> you have a much harder problem. I don't think this is solvable in 
>> practice, nor do I think it needs to be solved.
> 
> If Alice had just not sent the request via SIP, but used SIPS, the it 
> would have been solved.

Unless Alice believes that the address itself is a secret to be 
protected, she may not protect it.

AFAIK, there has never been any expectation that the presence of "sips" 
in the URI carried an expectation that somebody possessing such an 
address keep it confidential. Quite to the contrary, I have assumed that 
the expectation was that it might be put on business cards, stored in 
directories, ENUM, etc.

>>> Since traceroute on biloxi.example.com may well give us a good idea 
>>> of the physical location of biloxi.example.com, an interceptor 
>>> picking up this message would have a good chance of being able to 
>>> find Bob.
>>
>> No. Only Bob's home proxy.
> 
> In the call flow described (from 3665) there is no home proxy.
> 
> THERE IS NO REQUIREMENT THAT SIP USERS HAVE A HOME PROXY AND I WOULD BE 
> VERY HAPPY IF PEOPLE WOULD REMEMBER THAT!

Its fine for there to be no home proxy. But if so, then Bob must 
publicize his actual address, and expect that bad guys may get access to it.

> But IF there had been a home proxy in this example, and the request were 
> intercepted between Bob's home proxy and Bob, then it would reveal Bob's 
> location as understood by Bob's home proxy.

I thought the idea was that Bob himself had only the sips address. So 
the link between Bob's home proxy and Bob would always be via TLS. So 
the message won't be intercepted on that leg. It would have to be 
intercepted before reaching his home proxy. And there it would only 
reveal his AOR.

>>> Assuming that  this message is sent unencrypted when used with SIP 
>>> (instead of SIPS), it's relatively easy to intercept.
>>> The interceptor didn't need credentials to get into a location server 
>>> that might translate bob@example.com to bob@biloxi.example.com. They 
>>> didn't need credentials to look in a directory server. They just 
>>> pulled the information "off the wire" in such a way that Bob will be 
>>> unable to know how the interceptor got his location.
>>
>> I don't see how this discloses the address bob@biloxi.example.com, 
>> which is the only one that Bob has any chance of hiding. All Bob needs 
>> to do is be careful in what he puts into his *response* to the above 
>> invite. (E.g. He shouldn't put his contact address if he is rejecting 
>> the call, and he should ensure his address isn't mentioned in a H-I 
>> header.) If he is really paranoid about this he could simply refuse to 
>> send any response to the invite, and let it timeout.
> 
> It discloses"bib@biloxi.example.com" by the very simple mechanism of 
> including both "bob@example.com" and "bob@biloxi.example.com" in a 
> plain-text message. This disclosure occurs even if Bob never responds to 
> the request, and even if bob never even RECEIVES the request.

I guess we are making some significantly different assumptions about 
what is going on.

	Paul

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 16 13:13:55 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdUm1-00031Q-Vm; Mon, 16 Apr 2007 13:13:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUm1-00031K-4R
	for sip@ietf.org; Mon, 16 Apr 2007 13:13:53 -0400
Received: from ihemail1.lucent.com ([135.245.0.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdUly-0000kD-PZ
	for sip@ietf.org; Mon, 16 Apr 2007 13:13:53 -0400
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l3GHDjm8007284
	for <sip@ietf.org>; Mon, 16 Apr 2007 12:13:50 -0500 (CDT)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by
	ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 16 Apr 2007 12:13:16 -0500
Received: from DEEXC1U01.de.lucent.com ([135.248.187.26]) by
	DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 16 Apr 2007 19:13:13 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 16 Apr 2007 19:13:10 +0200
Message-ID: <5D1A7985295922448D5550C94DE29180FFE84C@DEEXC1U01.de.lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Review of draft-ietf-sip-location-conveyance
Thread-Index: AceASoJbwqnLTcNHTPKhgPjOBOCQcQ==
From: "Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>
To: "IETF SIP List" <sip@ietf.org>
X-OriginalArrivalTime: 16 Apr 2007 17:13:13.0459 (UTC)
	FILETIME=[840AE430:01C7804A]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Subject: [Sip] Review of draft-ietf-sip-location-conveyance
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I have posted the comments from WGLC on
draft-ietf-sip-location-conveyance at:

http://www.softarmor.com/sipwg/reviews/location-conveyance/index.html

Please let me know if I have missed any comments.=20

There will be a review conference call of these comments on:

Wednesday 25th April at

	1:00 pm - 3:00 pm Central US time
	2:00 pm - 4:00 pm Eastern US time
	7:00 pm - 9:00 pm UK time
	8:00 pm - 10:00 pm Central Europe time

Bridge details:

Chairperson Name:  KEITH DRAGE
Access Phone Number:  8007718734
International Access Phone Number:  +1 6477233953 7-Digit Access Code:
5776249=20

While this call is in no sense restricted, this call is for people who
have reviewed the document. If you think you qualify, and have not sent
comments that are included above, or indeed reviewed and had no
comments, then please send me a mail indicating this.

Regards

Keith


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 16 13:16:50 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdUor-0004BE-AM; Mon, 16 Apr 2007 13:16:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUop-0004B4-6x
	for sip@ietf.org; Mon, 16 Apr 2007 13:16:47 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdUoo-0001aM-P4
	for sip@ietf.org; Mon, 16 Apr 2007 13:16:47 -0400
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 16 Apr 2007 13:16:45 -0400
X-IronPort-AV: i="4.14,415,1170651600"; 
	d="scan'208"; a="57773309:sNHT4674698210"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3GHGipf032288; 
	Mon, 16 Apr 2007 13:16:44 -0400
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 l3GHGHla008761; 
	Mon, 16 Apr 2007 17:16:32 GMT
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.1830); 
	Mon, 16 Apr 2007 13:16:30 -0400
Received: from [161.44.174.118] ([161.44.174.118]) by
	xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 16 Apr 2007 13:16:30 -0400
Message-ID: <4623AF6C.7080207@cisco.com>
Date: Mon, 16 Apr 2007 13:16:28 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Hisham Khartabil <hisham.khartabil@gmail.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
References: <4616851D.5070305@softarmor.com> <4617E6B8.5070601@softarmor.com>	
	<20070407192220.253931CC3D@delta.rtfm.com>	
	<46194A1A.1020705@softarmor.com>	
	<20070408202105.0F2725C027@laser.networkresonance.com>	
	<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>	
	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>	
	<461F00B3.1090206@softarmor.com>	
	<66cd252f0704130240x707ff7f3g996c002cfb5e932@mail.gmail.com>	
	<461F888A.2080609@cisco.com>
	<66cd252f0704152345j598bafc6h7aa53f0e3b2b3b6@mail.gmail.com>
In-Reply-To: <66cd252f0704152345j598bafc6h7aa53f0e3b2b3b6@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Apr 2007 17:16:30.0282 (UTC)
	FILETIME=[F95BB2A0:01C7804A]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5253; t=1176743804;
	x=1177607804; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20SIPS=20question=3A=20How=20to=20prevent=20pla
	intext=20requests=20from=20being=0A=20delivered=20to=20a=20UA
	|Sender:=20
	|To:=20Hisham=20Khartabil=20<hisham.khartabil@gmail.com>;
	bh=8IL4hTTGwp9dumNhv2Pf3ICFLD6crvZtD+K2JUMYwtY=;
	b=hz+LDZhITuzjBmpj6/gd40z7nHSwoO1LfDVA9/BIy7IJU4D5OnAtFFjWHPY9nN09wwFk1iQd
	RIF485bHTV6Mi45lQpv9IoD8b37BijBp0uICPVX1nOQ2ae9WxVuX5HQ4;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org



Hisham Khartabil wrote:
> On 13/04/07, Paul Kyzivat <pkyzivat@cisco.com> wrote:
>> Hisham,
>>
>> I don't understand how you expect the registering of two schemes to
>> work. Suppose the phone needs to use outbound. Are you suggesting that
>> it needs to establish one outbound connection for sips and a different
>> one for sip? Why would anyone want to incur that extra cost compared to
>> simply receiving both sip and sips calls over the same connection?
> 
> Are you talking about flows? I'm not suggesting 2 different flows, not
> TCP connections for that matter. Is there any restriction on using the
> same flow-id for both?

I was thinking two flows. If you meant only a single flow for both, then 
once concern is removed.

So you mean both a sip and sips contact would be registered over the 
same (tls) flow. As Francois said, he proposed this long ago and it was 
rejected for a bunch of reasons. The only benefit I can see to this is 
as a way to indicate a policy regarding whether sip requests are/aren't 
desired over this flow. Things will work just fine without that policy 
(the UAS can simply reject them if it wishes). It complicates a lot of 
things so I prefer to stick with what was already decided about this.

	Paul

> Hisham
> 
>>
>>         Paul
>>
>> Hisham Khartabil wrote:
>> > You are right in what you say Dean, but one thing I gotta comment on
>> > is that I really doubt that people will be giving out business cards
>> > with 2 sip addresses, one with sip: scheme and the other with sips:
>> > scheme.
>> >
>> > I vision it as one sip address, scheme is not mentioned at all in the
>> > business card. The UI of the phone allows the user to select "secure
>> > call" or a check box. So the scenarios are:
>> >
>> > - I register with sips only. You call me without selecting "secure
>> > call". Your call would fail
>> > - I register with sips only. You call me and select "secure call".
>> > Your call would succeed
>> > - I register with sip only. You call me without selecting "secure
>> > call". Your call would succeed
>> > - I register with sip only. You call me and select "secure call". Your
>> > call would fail
>> > - I register both schemes, all calls succeed
>> >
>> > Also, you wrote:
>> >>
>> >> Personally, I liked per-scheme registration. The WG didn't.
>> >>
>> >
>> > I thought that was what the group agreed. Or? Ekr suggested a MUST NOT
>> > and no one objected.
>> >
>> > Hisham
>> >
>> > On 13/04/07, Dean Willis <dean.willis@softarmor.com> wrote:
>> >> Hisham Khartabil wrote:
>> >> > This is somehow tied with Jonathan's thread related to retargetting
>> >> > and downgrading from sips to sip (or upgrading). If we agree to
>> >> > disallow both, then we are also disallowing what is being 
>> discussed in
>> >> > this thread.
>> >> >
>> >> Not really.
>> >>
>> >> Upgrading and Downgrading, in the context of Johnathan's argument, 
>> occur
>> >> when a proxy which was presented a URI of one scheme changes it to the
>> >> other scheme.
>> >>
>> >> What the current text describes is that registration of a SIPS contact
>> >> implicitly registers the equivalent SIP contact. This doesn't mean 
>> that
>> >> any proxy can translate SIPS to SIP or SIP to SIPS. Instead, it means
>> >> that a user who has registered just SIPS can receive both sorts of
>> >> requests. If the request originates with SIP it will be delivered, 
>> just
>> >> as it would if it originated SIPS.
>> >>
>> >> So you could put both SIP and SIPS on your business card, and a caller
>> >> could just pick one.
>> >>
>> >> What I was worried about is what happens when a user who is given 
>> only a
>> >> SIPS URI translates it to SIP and uses that to make a request. It may
>> >> well be that the user was given only a SIPS URI because the called 
>> party
>> >> really wants their incoming traffic secured. There's no way to
>> >> COMPLETELY fix this, although it can be fixed from the serving 
>> proxy to
>> >> UAS by either 1) use of outbound over TLS, or 2) going to a per-scheme
>> >> registration as you propose.
>> >>
>> >> So what I asked for is just additional guidance to the user to 
>> reinforce
>> >> the idea that they should not make this mistake. Not that users are
>> >> really governed by RFCs, but some of them will make fewer mistakes if
>> >> this sort of guidance is given.
>> >> > If a UAS wants to be contactable with over UDP or TCP/TLS, then 
>> it can
>> >> > register with 2 contact headers.
>> >>
>> >> Personally, I liked per-scheme registration. The WG didn't.
>> >>
>> >> The reason I like it is that it removes the incentive to assume that a
>> >> URI of a different scheme than the one you were given to use is likely
>> >> to work. This makes mistakes less likely to happen.
>> >>
>> >> --
>> >> Dean
>> >>
>> >
>> > _______________________________________________
>> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> > This list is for NEW development of the core SIP Protocol
>> > Use sip-implementors@cs.columbia.edu for questions on current sip
>> > Use sipping@ietf.org for new developments on the application of sip
>> >
>>
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 16 14:56:46 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdWNY-0001cO-DQ; Mon, 16 Apr 2007 14:56:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdWNX-0001c9-EM
	for sip@ietf.org; Mon, 16 Apr 2007 14:56:43 -0400
Received: from zrtps0kp.nortel.com ([47.140.192.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdWNX-0004de-2F
	for sip@ietf.org; Mon, 16 Apr 2007 14:56:43 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3GIudm08072; Mon, 16 Apr 2007 18:56:39 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
Date: Mon, 16 Apr 2007 13:56:34 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF100DE164@zrc2hxm0.corp.nortel.com>
In-Reply-To: <4623AF6C.7080207@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being delivered to a UA
thread-index: AceASwS9cYDPiW5TTGCRT+OYU6XafgADeikw
References: <4616851D.5070305@softarmor.com> <4617E6B8.5070601@softarmor.com>
	<20070407192220.253931CC3D@delta.rtfm.com>
	<46194A1A.1020705@softarmor.com>
	<20070408202105.0F2725C027@laser.networkresonance.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>
	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
	<461F00B3.1090206@softarmor.com>
	<66cd252f0704130240x707ff7f3g996c002cfb5e932@mail.gmail.com>
	<461F888A.2080609@cisco.com>
	<66cd252f0704152345j598bafc6h7aa53f0e3b2b3b6@mail.gmail.com>
	<4623AF6C.7080207@cisco.com>
From: "Francois Audet" <audet@nortel.com>
To: "Paul Kyzivat" <pkyzivat@cisco.com>,
	"Hisham Khartabil" <hisham.khartabil@gmail.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48
Cc: sip@ietf.org, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Thank you.

I agree with Paul.=20

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20
> Sent: Monday, April 16, 2007 10:16
> To: Hisham Khartabil
> Cc: Dean Willis; sip@ietf.org; Audet, Francois (SC100:3055)
> Subject: Re: [Sip] SIPS question: How to prevent plaintext=20
> requests from being delivered to a UA
>=20
>=20
>=20
> Hisham Khartabil wrote:
> > On 13/04/07, Paul Kyzivat <pkyzivat@cisco.com> wrote:
> >> Hisham,
> >>
> >> I don't understand how you expect the registering of two=20
> schemes to=20
> >> work. Suppose the phone needs to use outbound. Are you suggesting=20
> >> that it needs to establish one outbound connection for sips and a=20
> >> different one for sip? Why would anyone want to incur that=20
> extra cost=20
> >> compared to simply receiving both sip and sips calls over=20
> the same connection?
> >=20
> > Are you talking about flows? I'm not suggesting 2 different=20
> flows, not=20
> > TCP connections for that matter. Is there any restriction=20
> on using the=20
> > same flow-id for both?
>=20
> I was thinking two flows. If you meant only a single flow for=20
> both, then once concern is removed.
>=20
> So you mean both a sip and sips contact would be registered=20
> over the same (tls) flow. As Francois said, he proposed this=20
> long ago and it was rejected for a bunch of reasons. The only=20
> benefit I can see to this is as a way to indicate a policy=20
> regarding whether sip requests are/aren't desired over this=20
> flow. Things will work just fine without that policy (the UAS=20
> can simply reject them if it wishes). It complicates a lot of=20
> things so I prefer to stick with what was already decided about this.
>=20
> 	Paul
>=20
> > Hisham
> >=20
> >>
> >>         Paul
> >>
> >> Hisham Khartabil wrote:
> >> > You are right in what you say Dean, but one thing I=20
> gotta comment on
> >> > is that I really doubt that people will be giving out=20
> business cards
> >> > with 2 sip addresses, one with sip: scheme and the other=20
> with sips:
> >> > scheme.
> >> >
> >> > I vision it as one sip address, scheme is not mentioned=20
> at all in the
> >> > business card. The UI of the phone allows the user to=20
> select "secure
> >> > call" or a check box. So the scenarios are:
> >> >
> >> > - I register with sips only. You call me without=20
> selecting "secure
> >> > call". Your call would fail
> >> > - I register with sips only. You call me and select=20
> "secure call".
> >> > Your call would succeed
> >> > - I register with sip only. You call me without selecting "secure
> >> > call". Your call would succeed
> >> > - I register with sip only. You call me and select=20
> "secure call". Your
> >> > call would fail
> >> > - I register both schemes, all calls succeed
> >> >
> >> > Also, you wrote:
> >> >>
> >> >> Personally, I liked per-scheme registration. The WG didn't.
> >> >>
> >> >
> >> > I thought that was what the group agreed. Or? Ekr=20
> suggested a MUST NOT
> >> > and no one objected.
> >> >
> >> > Hisham
> >> >
> >> > On 13/04/07, Dean Willis <dean.willis@softarmor.com> wrote:
> >> >> Hisham Khartabil wrote:
> >> >> > This is somehow tied with Jonathan's thread related=20
> to retargetting
> >> >> > and downgrading from sips to sip (or upgrading). If=20
> we agree to
> >> >> > disallow both, then we are also disallowing what is being=20
> >> discussed in
> >> >> > this thread.
> >> >> >
> >> >> Not really.
> >> >>
> >> >> Upgrading and Downgrading, in the context of=20
> Johnathan's argument,=20
> >> occur
> >> >> when a proxy which was presented a URI of one scheme=20
> changes it to the
> >> >> other scheme.
> >> >>
> >> >> What the current text describes is that registration of=20
> a SIPS contact
> >> >> implicitly registers the equivalent SIP contact. This=20
> doesn't mean=20
> >> that
> >> >> any proxy can translate SIPS to SIP or SIP to SIPS.=20
> Instead, it means
> >> >> that a user who has registered just SIPS can receive=20
> both sorts of
> >> >> requests. If the request originates with SIP it will be=20
> delivered,=20
> >> just
> >> >> as it would if it originated SIPS.
> >> >>
> >> >> So you could put both SIP and SIPS on your business=20
> card, and a caller
> >> >> could just pick one.
> >> >>
> >> >> What I was worried about is what happens when a user=20
> who is given=20
> >> only a
> >> >> SIPS URI translates it to SIP and uses that to make a=20
> request. It may
> >> >> well be that the user was given only a SIPS URI because=20
> the called=20
> >> party
> >> >> really wants their incoming traffic secured. There's no way to
> >> >> COMPLETELY fix this, although it can be fixed from the serving=20
> >> proxy to
> >> >> UAS by either 1) use of outbound over TLS, or 2) going=20
> to a per-scheme
> >> >> registration as you propose.
> >> >>
> >> >> So what I asked for is just additional guidance to the user to=20
> >> reinforce
> >> >> the idea that they should not make this mistake. Not=20
> that users are
> >> >> really governed by RFCs, but some of them will make=20
> fewer mistakes if
> >> >> this sort of guidance is given.
> >> >> > If a UAS wants to be contactable with over UDP or=20
> TCP/TLS, then=20
> >> it can
> >> >> > register with 2 contact headers.
> >> >>
> >> >> Personally, I liked per-scheme registration. The WG didn't.
> >> >>
> >> >> The reason I like it is that it removes the incentive=20
> to assume that a
> >> >> URI of a different scheme than the one you were given=20
> to use is likely
> >> >> to work. This makes mistakes less likely to happen.
> >> >>
> >> >> --
> >> >> Dean
> >> >>
> >> >
> >> > _______________________________________________
> >> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >> > This list is for NEW development of the core SIP Protocol
> >> > Use sip-implementors@cs.columbia.edu for questions on current sip
> >> > Use sipping@ietf.org for new developments on the=20
> application of sip
> >> >
> >>
> >=20
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From jabxqseexij@colrud.com Mon Apr 16 15:04:01 2007
Return-path: <jabxqseexij@colrud.com>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdWUb-0005d8-3d
	for sip-archive@lists.ietf.org; Mon, 16 Apr 2007 15:04:01 -0400
Received: from [212.62.161.75] (helo=[212.62.161.75])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1HdWUZ-0000Xy-9Q
	for sip-archive@lists.ietf.org; Mon, 16 Apr 2007 15:04:00 -0400
From:	"Outdoors Bargains:" <jabxqseexij@colrud.com>
To: sip-archive@lists.ietf.org
Subject: Your family
Date:	Mon, 16 Apr 2007 21:04:03 -0200
MIME-Version: 1.0
Content-Type: multipart/related;
	boundary="----=_NextPart_000_0002_01C7806A.C30C9960"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: AceAasMM7Oe2hNv1RZK6PY57gTUaOg==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
Message-Id: <04E59B83895AE74.DD67BB3E33@colrud.com>
X-Spam-Score: 1.3 (+)
X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d

------=_NextPart_000_0002_01C7806A.C30C9960
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0003_01C7806A.C30C9960"


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



Restylane

With Amazon:


------=_NextPart_001_0003_01C7806A.C30C9960
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)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[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:2.0cm 42.5pt 2.0cm 3.0cm;}
div.Section1
    {page:Section1;}
-->      
</style>

</head>

<body lang=3DEN 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'><img width=3D562 height=3D118 id=3D"_x0000_i1025"
src=3D"cid:pic01.gif@01C7806A.C30C9960"></span></font><font size=3D2 =
face=3DArial><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></p=
>

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

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

</div>

</body>

</html>

------=_NextPart_001_0003_01C7806A.C30C9960--

------=_NextPart_000_0002_01C7806A.C30C9960
Content-Type: image/gif;
	name="pic01.gif"
Content-Transfer-Encoding: base64
Content-ID: <pic01.gif@01C7806A.C30C9960>

R0lGODdhMgJ2AIcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg
AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg
AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA
AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA
QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA
QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA
QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg
QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg
gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg
gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg
gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA
wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA
wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA
wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg
pICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAAMgJ2AAcI/gDtCRxIsKDBgwgTKlzIsKHD
hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBdvotJs6bNmzhz6tzJs6fP
n0CDCh1KtKjRo0iTKl3KtKlTnnSeSp1KtarVq1izat3KtavXr2DDMiQntqzZs2jTql3Ltq3b
t3Djyp1Lt67du3jz6t3Lt6/fv4ADCx5MuLDhwxS9IV7MuLHjx5AjS55MubLly5gza97MubPn
z6BDix5NurTp00cHxTWHlR/jTKin8pvt2l7t2gRp4x64e6Lu2Rt78xYoPKFuh8ARHl9Jm3dy
g8VtNz94+2H02Jp3a4c+3GN1jdG//jfEfT23cfMpXau33d288O3c2SPHHnq7+PbqgZN/Pl36
8+7LTScggM0tR5x+/fWH34H75RcedAkq6B9x6An433rxuZehc8mJZyF/hkVFH0EWRGQfhQUF
COBw5MmnHIrstUhhizS2J1+NMDLooYsYUsdgii4CieJ3OKZ44Xs23vhfjEOyuOKInp0YZI48
Uvnbj/EVqWWVMjY5o4FebnkdfAEuKSORxz3Y25pgBnlbgV4yGSeUm0mJJHo3OvmikFvOqKec
bsLYY5aCcnnen2viuV+SSK7XZaF4Aorhjo/S2ZmKU07ZZYQILhnnoJy+qZ+Now4p4Zn8dZik
fw06+N6R/7nBOZAeWE4Yqaah5onlmZb2ylOlLpXXkrC+FquWhC8Ra+yyzDbb2CXORivttNRW
C5Eh1marLUXwbOvtt+AqBMC4AAhU7kHnEnRuugix225B5Lqrkbzh1rtVuvQOlK89+5rLkLv4
etSvvQRPFTC+8Y7Lr8LrkuuvuQ4vjLDC6uoL8boW+xtxxBbHqy/FBY9Gxkus/HTwwxkHzG/H
LK+sccYfU6wyxiufbFC5Nrsc8s5H5bwxyjTX3HLCOgMMb8pC4+wxvTi3zHNhcUSW89BIv2y1
0ShnXTTMQWtttdBePy12Tx67XDbDKXO8dMMyc+y12ypL3PTNW0sM89h49zVF3v5hncP334AH
LvjghBduOErHdEXr4Yw37vjjkEcul9v/LjSwQPlkns9Amm9uj+efcx665KQnpIZLcVcubkOg
e9766LBvDnrptNOEdc0Msz0x0Am9HjvmocsOvKW61N6W2mY/PDfYzCvke+eiC++68dTXhDHN
1zu9vPOiwx598MNXT/gJPM2cfPI+68z98LN3/7v48EeEykVwV600yD+Hjbnm7hPku/fxC2BK
LifAAnIFZAZMoAIXyMAGOvCBBQwFBCdIwd5V8IInKVvFMMK//bWvfwDEoAjfpT+LSO99/ptd
5vwyihE+5mBou1jM7uY/FLZPeMD7oEgQ4MLHna1qzP67XAf/V8Mc9vArUcDO7bomNwKeMHxF
nN4Rp6i1dMmBdwQ0Ig5DOLrO6ZCKF1ziDC/GxBS2boVQvGFCEgAWXDAFCWCcyxfjSEfDQKGO
eMyjHvfIxz768Y+AlEwMAknHH6qvhBwp49E2+BF2ZbEhj8zIIyN5PnSpLX9bc2RFskhJlGjy
kCHJF/bo58izbQyBMkyl3RhpEUqicpGcZKW8OjmRWJqElpD0JEn2Zb6vTQ2XEAHmLjcozETO
KyFdS136lCnJiNhSdVejm9nw1zZqojJ/u6sm9i6JQFNa85OGVN43T8k2MqqLnKoEmswqpruY
aZJyXONd0iopN3PaE4i6g/8bOduZShhac4z1lKEGKTfQb2bSnbhb3j5vljum2ZOZvqzbQ9GJ
zqIRtKHwWicoSRjNowVNoQdFF9WUF9GPStSj2iOm/bAIy5RaTqLgXGklQQpEaU4Tf/NUX+qa
19KvlRCky0xpULNm0p0K9aiHHGVIdeq0ngaRkUC9205pGlJRNrWqDnnn2ybW0BjedJH4JKnN
0ndOr1J1piRtYj9ZClCEcjWmaVXqU2sK1jI2bW6fvGk5nbrXWTpsqE+dmloh6s9r/rWuS8Vm
WufKVrCyU6pIZao4zepOhV7zqmPN6mNBiVfHnlSyYOtlVBMLVdKGFWI03KxgiepSacYNp6Zd
rE3+Ffna0k6Vryi1bWRHG1jEhtWqJY3sSIsKWZ/GM6LxJGtjqXq74vI0s1lVbE+9eT9+lnWx
ozTkzC5K2YBi92NlrS5qV8lVhnrVuxYt5Wk1OM0qIm+2zm0ne9XZ1fG61aXcpGl+77mwus3X
mwitJz8bll55jtGhAH0vN9vq3aVJ9bDoXWtG5VrMTdoutXcxqsnqUuGXdPgtH5bkK3kSDZ3A
0ycjBnFSQkzIFt9EEy6OsYxnTOMa2xgm37gxUn6TqD0t5EJUOhRKSqUsRY3HSghZw4/ndJEi
68jHEjEQpgzlnExtSFerYkiPrXNkcN1nyVrm03zSIyTfdNnJY0YzmLv+HGQrjxnLPSqSm31U
IYykykRs3ssviiIqNIEIVw7iEKsEHStVmapDZvrQj+B0qgINKExHcpWgFLQpIkFIVLtyNKah
LOhG9zlDO2LSpDqd6Sst+tFSbnSVbZXqTlGqM20wyaurBKhC9bhPtkYUrXPN6y9vOc5wrrOf
5mxpSxt5U0AKdZZKVWsqa4pAIHJUjoz9bGHLCdd+kvawJSXmL2tr1qgCdbVpBCYxsajcuh62
tx8tqVaRCVGekvaoq42fMhG5TaRi1aCc/esgy3vac2L3p4JdqX+b+9DV8Xa2wL2ift/6T2UG
tpyPvSBqc+fgD3L2qniFZV7Te94KkRKj0r2tICsj+0nF2TfDt/1wbh88T2ruiDxwoo2urFxX
bPI1sAddcnt/WiCemDKrTVXon3O83BJ/srhxfulpfyg/Sn9VqhBkJGUr3eQlDxOH3hQrKqPK
TJAOtc+zDqUkbgVYt+JIzMOFdpCs/YLIKrN3CBf3j3hKx3jPu973zve+E4U1fh9hHwJPeEsp
oPCI5wwbE8/4xjv+8ZCviygi3zgzUP7ymM984Reh+c57/vOBCQgAOw==

------=_NextPart_000_0002_01C7806A.C30C9960--




From sip-bounces@ietf.org Mon Apr 16 15:50:29 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdXDS-0007zB-Kt; Mon, 16 Apr 2007 15:50:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdXDA-0007sY-Mg; Mon, 16 Apr 2007 15:50:04 -0400
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HdXD8-0001Ow-KG; Mon, 16 Apr 2007 15:50:04 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 75D6326EAA;
	Mon, 16 Apr 2007 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1HdXD8-0000Kb-AM; Mon, 16 Apr 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1HdXD8-0000Kb-AM@stiedprstage1.ietf.org>
Date: Mon, 16 Apr 2007 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: sip@ietf.org
Subject: [Sip] I-D ACTION:draft-ietf-sip-sips-03.txt 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-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 Session Initiation Protocol Working Group of the IETF.

	Title		: The use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)
	Author(s)	: F. Audet
	Filename	: draft-ietf-sip-sips-03.txt
	Pages		: 54
	Date		: 2007-4-16
	
This document provides clarifications and guidelines concerning the
   use of SIPS URI scheme in the Session Initiation Protocol (SIP).  It
   also makes normative changes to SIP.  This document also provides a
   discussion of possible future steps in specification.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-03.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-sip-sips-03.txt".

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

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

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

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


--OtherAccess--

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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--NextPart--





From sip-bounces@ietf.org Mon Apr 16 16:33:22 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdXt0-0001XK-21; Mon, 16 Apr 2007 16:33:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdXsz-0001XF-29
	for sip@ietf.org; Mon, 16 Apr 2007 16:33:17 -0400
Received: from ondar.cablelabs.com ([192.160.73.61])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdXsx-00017Y-M8
	for sip@ietf.org; Mon, 16 Apr 2007 16:33:17 -0400
Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7])
	by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l3GKWJxU029197;
	Mon, 16 Apr 2007 14:32:20 -0600 (MDT)
Received: from srvxchg.cablelabs.com (10.5.0.20)
	by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com);
	Mon, 16 Apr 2007 14:32:18 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com)
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: [Sip] Ensuring in-dialog stuff works with outbound
Date: Mon, 16 Apr 2007 14:32:18 -0600
Message-ID: <CD6CE349CFD30D40BF5E13B3E0D84804024D3F6C@srvxchg.cablelabs.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Ensuring in-dialog stuff works with outbound
Thread-Index: Acd3tOKlWBJSBBN7Roak+OBsZBz6ngIrqBzg
References: <FF6DBE29-A730-4BE4-953C-8042E1E0AE21@estacado.net>
From: "Kevin Johns" <K.Johns@CableLabs.com>
To: "Byron Campen" <bcampen@estacado.net>, "SIP IETF" <sip@ietf.org>
X-Approved: ondar
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: Cullen Jennings <fluffy@cisco.com>, Rohan Mahy <rohan@ekabal.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Byron,

Just saw this email and have not seen any responses as of yet...

I am not sure I fully follow your issue, are you trying to figure out
how to distinguish between non-outbound enabled UAs and outbound enabled
UAs within the same edge proxy? It also appears you want to be able to
determine this so you know when to insert a flow token in a record-route
header to allow for routing of mid-dialog requests?

Is my understand correct?

Kevin


-----Original Message-----
From: Byron Campen [mailto:bcampen@estacado.net]=20
Sent: Thursday, April 05, 2007 1:00 PM
To: SIP IETF
Cc: Cullen Jennings; Rohan Mahy
Subject: [Sip] Ensuring in-dialog stuff works with outbound

	I've been tuning a server implementation of outbound recently,
and I've come upon a bit of a conundrum. Say we have an endpoint using
outbound with an edge-proxy. Everything is set up as specified in the
draft. This endpoint then sends a dialog-forming request. The edge proxy
has to be able to ensure that in-dialog traffic coming from the other
direction goes over the same outbound flow, by record-routing with a
flow token. However, in the non-outbound case, is it downright _wrong_
for the edge proxy to record-route with a flow-token, because doing so
breaks target-refreshes. Unfortunately, the edge-proxy is keeping no
flow state, and has no clue if this dialog-forming request came over an
outbound flow or not.

I see two choices for fixing this, please pipe up if you see additional
options:

1. We require the endpoint to specify whether it wants the outbound
treatment on each outgoing request, either by including some
recognizable outbound goo in the request, or by preloading a Route
header with a flow-token to the edge proxy (using something like
Service-Route maybe, although interactions between Service-Route and
Path might be a little weird).

2. We require proxies to store information on which connections are
outbound flows, and which are not (this would make the whole exercise of
stateless flow-tokens moot).

Best regards,
Byron Campen



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 16 17:45:00 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdZ0J-0007h5-EW; Mon, 16 Apr 2007 17:44:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdZ0H-0007gs-4B
	for sip@ietf.org; Mon, 16 Apr 2007 17:44:53 -0400
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdZ0G-0007og-Ny
	for sip@ietf.org; Mon, 16 Apr 2007 17:44:53 -0400
Received: from sj-dkim-5.cisco.com ([171.68.10.79])
	by sj-iport-4.cisco.com with ESMTP; 16 Apr 2007 14:44:52 -0700
X-IronPort-AV: i="4.14,415,1170662400"; 
	d="scan'208"; a="53903253:sNHT49552929"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
	by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l3GLiqv5025706; 
	Mon, 16 Apr 2007 14:44:52 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l3GLiax5002029;
	Mon, 16 Apr 2007 21:44:46 GMT
Received: from xmb-sjc-231.amer.cisco.com ([128.107.191.73]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 16 Apr 2007 14:44:36 -0700
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: Poll: Do we have sips/sip retageting in the wild (was Re: [Sip]
	RE:Securing Other URI (Tel URI) scheme)
Date: Mon, 16 Apr 2007 14:44:35 -0700
Message-ID: <49DFEF82990374449378AD1198F39F8B03209A54@xmb-sjc-231.amer.cisco.com>
In-Reply-To: <2994750C-566F-4635-B750-40637B275F62@softarmor.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Poll: Do we have sips/sip retageting in the wild (was Re: [Sip]
	RE:Securing Other URI (Tel URI) scheme)
Thread-Index: AcdyNztJs5tzUmcOTZW5HpAPrTyzdAOOEFEQ
From: "Charles Eckel \(eckelcu\)" <eckelcu@cisco.com>
To: "Dean Willis" <dean.willis@softarmor.com>, "IETF SIP List" <sip@ietf.org>
X-OriginalArrivalTime: 16 Apr 2007 21:44:36.0403 (UTC)
	FILETIME=[6D6EF830:01C78070]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2700; t=1176759892;
	x=1177623892; c=relaxed/simple; s=sjdkim5002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=eckelcu@cisco.com;
	z=From:=20=22Charles=20Eckel=20\(eckelcu\)=22=20<eckelcu@cisco.com>
	|Subject:=20RE=3A=20Poll=3A=20Do=20we=20have=20sips/sip=20retageting=20in
	=20the=20wild=20(was=20Re=3A=20[Sip]=20RE=3ASecuring=20Other=20URI=20(Tel=
	20URI)=20scheme) |Sender:=20;
	bh=9Dff1x0zjZbwNL36jLPtU8eaj7tqiYuJZrfSIG9AIY4=;
	b=dokaJIpKJGt//0UnjanPDE97h8rwsIf+HncjrrGTjJFu8OayoIZopapDpRsknIwGlNM4ndM6
	UaHwhQr2IYzEud7tUnhnPqFziYCPB7k4R6szYxZa8r2ArGzmFGxye8uZ;
Authentication-Results: sj-dkim-5; header.From=eckelcu@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim5002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Sorry for the late response, but the Cisco SIP Proxy Server (CSPS)
allowed for retargeting from sips to sip. Whether or not to allow this
is configurable, and it is disabled by default.
I do not recall what we did in terms of sip to sips, but I think we
allowed it as well. This was done in 2003 and not changed since as far
as I know.=20

Cheers,
Charles=20

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]=20
> Sent: Thursday, March 29, 2007 12:12 PM
> To: IETF SIP List
> Subject: Poll: Do we have sips/sip retageting in the wild=20
> (was Re: [Sip] RE:Securing Other URI (Tel URI) scheme)
>=20
>=20
> On Mar 29, 2007, at 12:01 PM, Francois Audet wrote:
>=20
> > I don't agree.
> >
> > I think this is theoretical. I don't believe proxies that "upgrade"
> > from SIP to SIPS using a retargeting exist in nature. And=20
> if they did,
> > they
> > would likely break stuff, or have some assumptions that makes them
> > essentially proprietary. It just doesn't work except for some very
> > narrow sceanrios (e.g., transactions that don't create a dialog, or
> > dialogs
> > with double Record-Route used at the retargeting point, along with
> > endpoints that
> > don't understand SIPS but somehow don't choke on the=20
> scheme, use of =20
> > SIP
> > outbound
> > which is not standard yet, etc.). Same applies for downgrades.
> >
> > So to me, it's a non-issue.
> >
> > From a standard's purist dreamland point of view, we could define
> > this extension: it would not "break" anything. It would just make
> > the spec more complicated for no good reason.
>=20
> I used to have a proxy at the house that would retarget inbound from =20
> sips to sip to let my old 3Com phone work. It would also=20
> retarget sip =20
> to sips outbound so I could call sips (said proxy is why I insisted =20
> on last-hop exception in 3261). Such proxies do exist.
>=20
> The good news is, I don't use it anymore (the bad news is I don't =20
> have a working SIP phone at home right now).
>=20
> So (Chair Hat on): Anybody else out there have a proxy currently (or =20
> planned to be) in use that retargets sip to sips or vice versa?
>=20
> If we can't come up with any, I suppose I'd be willing to=20
> concede the =20
> issue as "fixing an improbable problem"
>=20
> --
> Dean
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 16 18:26:56 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdZew-0001Gn-H0; Mon, 16 Apr 2007 18:26:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdZev-0001Gi-VG
	for sip@ietf.org; Mon, 16 Apr 2007 18:26:53 -0400
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdZev-0001jM-Jw
	for sip@ietf.org; Mon, 16 Apr 2007 18:26:53 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	l3GMQHq27301 for <sip@ietf.org>; Mon, 16 Apr 2007 22:26:17 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C78076.54066DA2"
Date: Mon, 16 Apr 2007 17:26:50 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-sip-sips-03.txt
thread-index: AceAYJFJLAAqg6ouQVG8D7x2SrOKMQADKm5w
From: "Francois Audet" <audet@nortel.com>
To: <sip@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433
Subject: [Sip] draft-ietf-sip-sips-03.txt
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

------_=_NextPart_001_01C78076.54066DA2
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

I have submitted draft-ietf-sip-sips-03.
=20
I have integrated all the agreements of the Prague meeting. Including
the change to Standards Track draft, and the RFC 2119 wording changes,
as well as the restructure of the document with Normative requirements
for UA and Proxy separated. Also the deprecation of the last hop
exception.

I also have attempted to capture the suggestions for improvements
and consensus from the mailing list.

There are two remaining issues that I have documented in Annex C.

Those 2 issues are what we need to focus on:

  1.  Do we deprecate the "last hop retarget upgrade exception"?  The
       document currently assumes that it IS deprecated, as this is the
       preference of the author.

  2.  Do we need the sips option tag? The current document assumes that
       we do use the option tag, and that is the preference of the
author.
       (There is at least one dissenting voice on that one: Hisham).

Please comment on those two open issues, and use a proper Subject for
the
topic.

If you have other comments, please use appropriate Subject fields to
make
the thread easier to follow.

Please also not repeat topics that have been beaten to death already.


> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20
> Sent: Monday, April 16, 2007 12:50
> To: i-d-announce@ietf.org
> Cc: sip@ietf.org
> Subject: [Sip] I-D ACTION:draft-ietf-sip-sips-03.txt
>=20
> A New Internet-Draft is available from the on-line=20
> Internet-Drafts directories.
> This draft is a work item of the Session Initiation Protocol=20
> Working Group of the IETF.
>=20
> 	Title		: The use of the SIPS URI Scheme in the=20
> Session Initiation Protocol (SIP)
> 	Author(s)	: F. Audet
> 	Filename	: draft-ietf-sip-sips-03.txt
> 	Pages		: 54
> 	Date		: 2007-4-16
> =09
> This document provides clarifications and guidelines concerning the
>    use of SIPS URI scheme in the Session Initiation Protocol=20
> (SIP).  It
>    also makes normative changes to SIP.  This document also provides a
>    discussion of possible future steps in specification.
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-03.txt
>=20
> To remove yourself from the I-D Announcement list, send a=20
> message to i-d-announce-request@ietf.org with the word=20
> unsubscribe in the body of the message.=20
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>=20
> Internet-Drafts are also available by anonymous FTP. Login=20
> with the username "anonymous" and a password of your e-mail=20
> address. After logging in, type "cd internet-drafts" and then=20
> "get draft-ietf-sip-sips-03.txt".
>=20
> A list of Internet-Drafts directories can be found in=20
> http://www.ietf.org/shadow.html or=20
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
> Internet-Drafts can also be obtained by e-mail.
>=20
> Send a message to:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-sip-sips-03.txt".
> =09
> 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=20
> 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.
>=20
> Below is the data which will enable a MIME compliant mail=20
> reader implementation to automatically retrieve the ASCII=20
> version of the Internet-Draft.
>=20

------_=_NextPart_001_01C78076.54066DA2
Content-Type: application/octet-stream;
	name="draft-ietf-sip-sips-03.URL"
Content-Transfer-Encoding: base64
Content-Description: draft-ietf-sip-sips-03.URL
Content-Disposition: attachment;
	filename="draft-ietf-sip-sips-03.URL"

W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1pZXRmLXNpcC1zaXBzLTAzLnR4dA0K

------_=_NextPart_001_01C78076.54066DA2
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
------_=_NextPart_001_01C78076.54066DA2--




From sip-bounces@ietf.org Tue Apr 17 01:37:44 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdgNe-0004bg-6C; Tue, 17 Apr 2007 01:37:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdgNc-0004bb-M6
	for sip@ietf.org; Tue, 17 Apr 2007 01:37:28 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdgNb-0004b2-Cb
	for sip@ietf.org; Tue, 17 Apr 2007 01:37:28 -0400
Received: from [192.168.2.101] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3H4i4S1016756
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2007 23:44:04 -0500
Message-ID: <46245D01.3070301@softarmor.com>
Date: Tue, 17 Apr 2007 00:37:05 -0500
From: Dean Willis <dean.willis@softarmor.com>
User-Agent: Thunderbird 1.5.0.10 (X11/20070306)
MIME-Version: 1.0
To: Francois Audet <audet@nortel.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
References: <4616851D.5070305@softarmor.com>
	<20070406174901.D89C45C027@laser.networkresonance.com>
	<46172B40.8090107@softarmor.com>
	<20070407151244.87A941CC3D@delta.rtfm.com>
	<4617E6B8.5070601@softarmor.com>
	<20070407192220.253931CC3D@delta.rtfm.com>
	<46194A1A.1020705@softarmor.com>
	<20070408202105.0F2725C027@laser.networkresonance.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>
	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
	<461F00B3.1090206@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Cc: sip@ietf.org, Paul Kyzivat <pkyzivat@cisco.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Francois Audet wrote:
>>> Euh, not. There is also 3)
>>>
>>> 3) Have a policiy in the proxy associated with Bob of not
>>>    delivering anything but sips.
>>>
>>>       
>> #3 only works if all the proxies between Bob and Bob's home 
>> proxy have this policy. For example, Bob's edge proxy may be 
>> different from Bob's home proxy.
>>     
>
> Dean, the request in this scenario 
> was sent out over non-TLS sent with sips in
> the first place. The damage done.
>
>   
Huh? No, the request was sent SIP because the user or user's UA chose to 
downgrade from the SIPS URI they had been given.

> If a proxy in the middle want to upgrade to sip, it can just
> send a 3XX with Contact: sips
>
>   

Sure. If there's a proxy in the middle, and the damage wasn't already 
done by leakage
>   
>> Only if an outbound proxy is used. P2P very well might not 
>> have outbound proxies. Remember, SIP DOES NOT REQUIRE YOU TO 
>> ALWAYS USE A PROXY.
>>     
>
> Dean, the request was sent using SIP in the first place. If there
> is no proxy, then the 3XX solution makes more sense.
>
>   

Yes, that's exactly my point. If you're given a SIPS URI, use it. Don't 
downgrade to SIP. Ever. Not at a proxy, not at a UA, not at a user.


And text (which we have) that effectively says "If the user registers 
with SIPS it means they want to receive both SIP and SIPS requests" is
dangerously misleading, because it encourages the user to downgrade and 
expect it to work.

--
Dean


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 01:47:50 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdgXb-00019f-CK; Tue, 17 Apr 2007 01:47:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdgXZ-00019R-0X
	for sip@ietf.org; Tue, 17 Apr 2007 01:47:45 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdgXY-00084X-ND
	for sip@ietf.org; Tue, 17 Apr 2007 01:47:44 -0400
Received: from [192.168.2.101] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3H4sRke016792
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 16 Apr 2007 23:54:28 -0500
Message-ID: <46245F71.8050901@softarmor.com>
Date: Tue, 17 Apr 2007 00:47:29 -0500
From: Dean Willis <dean.willis@softarmor.com>
User-Agent: Thunderbird 1.5.0.10 (X11/20070306)
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
References: <4616851D.5070305@softarmor.com>		<20070406174901.D89C45C027@laser.networkresonance.com>		<46172B40.8090107@softarmor.com>		<20070407151244.87A941CC3D@delta.rtfm.com>		<4617E6B8.5070601@softarmor.com>		<20070407192220.253931CC3D@delta.rtfm.com>		<46194A1A.1020705@softarmor.com>		<20070408202105.0F2725C027@laser.networkresonance.com>		<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
	<461F00B3.1090206@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com> <461F9AA9.4010700@cisco.com>
	<D1845680-1467-4ACC-84D9-F7EDCB3EE71C@softarmor.com>
	<4623AD9C.8060508@cisco.com>
In-Reply-To: <4623AD9C.8060508@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.1 (+)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Paul Kyzivat wrote:
>>
>> If Alice had just not sent the request via SIP, but used SIPS, the it 
>> would have been solved.
>
> Unless Alice believes that the address itself is a secret to be 
> protected, she may not protect it.

Exactly my point. She needs to KNOW that if she's given a SIPS address, 
that it should be protected by using it only for SIPS requests.

>
> AFAIK, there has never been any expectation that the presence of 
> "sips" in the URI carried an expectation that somebody possessing such 
> an address keep it confidential. Quite to the contrary, I have assumed 
> that the expectation was that it might be put on business cards, 
> stored in directories, ENUM, etc.

True. But if I give you my private unlisted number for encrypted calls 
and you start posting it on web pages with text that says "For a good 
time, call" , I'm gonna be angry. And I'll be only marginally less angry 
if you start schlepping it across the net in unprotected SIP INVITEs.

>>>> Since traceroute on biloxi.example.com may well give us a good idea 
>>>> of the physical location of biloxi.example.com, an interceptor
>>
>> In the call flow described (from 3665) there is no home proxy.
>>
>> THERE IS NO REQUIREMENT THAT SIP USERS HAVE A HOME PROXY AND I WOULD 
>> BE VERY HAPPY IF PEOPLE WOULD REMEMBER THAT!
>
> Its fine for there to be no home proxy. But if so, then Bob must 
> publicize his actual address, and expect that bad guys may get access 
> to it.
>
But Bob may publicize his actual address only within the confines of a 
directory or location server that makes that address available only to 
authenticated and authorized parties.

Alice sends INVITE for Bob' s SIPS AOR to Bob's LS.
Bob's LS returns a WWW-Auth to Alice.
Alice replies with credentials.
Bob's LS returns a SIPS contact.
Alice sends a SIP INVITE to the equivalent contact.

This is perfectly legal by the current draft as I understand it, and 
Alice would expect that it would work.

But it will completely compromise the secrecy of Bob's AOR->Contact 
binding, and Bob has no way to say "DON"T DO THIS TO ME!".

>> But IF there had been a home proxy in this example, and the request 
>> were intercepted between Bob's home proxy and Bob, then it would 
>> reveal Bob's location as understood by Bob's home proxy.
>
> I thought the idea was that Bob himself had only the sips address. So 
> the link between Bob's home proxy and Bob would always be via TLS. So 
> the message won't be intercepted on that leg. It would have to be 
> intercepted before reaching his home proxy. And there it would only 
> reveal his AOR.
>

No, that wasn't the case I was trying to (and apparently failing to) 
explain.
>
> I guess we are making some significantly different assumptions about 
> what is going on.
>
Ah, that's probably true.


--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 01:53:52 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdgdT-0004Fd-BK; Tue, 17 Apr 2007 01:53:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdgdR-0004FV-NX
	for sip@ietf.org; Tue, 17 Apr 2007 01:53:49 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdgdP-0001ZO-U9
	for sip@ietf.org; Tue, 17 Apr 2007 01:53:49 -0400
Received: from [192.168.2.101] (cpe-76-185-142-113.tx.res.rr.com
	[76.185.142.113]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3H50LNF016828
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Apr 2007 00:00:22 -0500
Message-ID: <462460D5.1090103@softarmor.com>
Date: Tue, 17 Apr 2007 00:53:25 -0500
From: Dean Willis <dean.willis@softarmor.com>
User-Agent: Thunderbird 1.5.0.10 (X11/20070306)
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
References: <4616851D.5070305@softarmor.com> <4617E6B8.5070601@softarmor.com>	
	<20070407192220.253931CC3D@delta.rtfm.com>	
	<46194A1A.1020705@softarmor.com>	
	<20070408202105.0F2725C027@laser.networkresonance.com>	
	<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>	
	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>	
	<461F00B3.1090206@softarmor.com>	
	<66cd252f0704130240x707ff7f3g996c002cfb5e932@mail.gmail.com>	
	<461F888A.2080609@cisco.com>
	<66cd252f0704152345j598bafc6h7aa53f0e3b2b3b6@mail.gmail.com>
	<4623AF6C.7080207@cisco.com>
In-Reply-To: <4623AF6C.7080207@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Paul Kyzivat wrote:
>
> So you mean both a sip and sips contact would be registered over the 
> same (tls) flow. As Francois said, he proposed this long ago and it 
> was rejected for a bunch of reasons. The only benefit I can see to 
> this is as a way to indicate a policy regarding whether sip requests 
> are/aren't desired over this flow. Things will work just fine without 
> that policy (the UAS can simply reject them if it wishes). It 
> complicates a lot of things so I prefer to stick with what was already 
> decided about this.

No, this DOESN'T work fine, as the privacy of the UAS's AOR-to-Contact 
binding is compromised by sending the request from the UAC, even if the 
UAS rejects the request.

If the sender KNEW that the UAS only accepted SIPS, this compromise 
would not occur.

And if the sender is given only a SIPS URI for an AOR, the sender MUST 
assume that the UAS accepts only SIPS requests and MUST NOT send a 
request to that AOR using SIP. Otherwise, the privacy of the UAS's 
AOR-to-Contact binding might be compromised (and in security, one can 
assume that if it might be compromised, it probably has been-- It's 
tainted).

--
Dean


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 04:24:42 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdizN-0006Mb-BV; Tue, 17 Apr 2007 04:24:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdizK-0006MW-Qk
	for sip@ietf.org; Tue, 17 Apr 2007 04:24:34 -0400
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]
	helo=bemg01.siemenscomms.co.uk)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdizK-0007G1-An
	for sip@ietf.org; Tue, 17 Apr 2007 04:24:34 -0400
Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82])
	by siemenscomms.co.uk (PMDF V6.0-24 #40642)
	with ESMTP id <0JGM00L89VCQQM@siemenscomms.co.uk> for sip@ietf.org; Tue,
	17 Apr 2007 09:24:26 +0100 (BST)
Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service
	(5.5.2657.72)	id <202YQ11W>; Tue, 17 Apr 2007 09:24:31 +0100
Content-return: allowed
Date: Tue, 17 Apr 2007 09:24:30 +0100
From: "Elwell, John" <john.elwell@siemens.com>
Subject: RE: [Sip] draft-ietf-sip-sips-03.txt
To: Francois Audet <audet@nortel.com>, sip@ietf.org
Message-id: <50B1CBA96870A34799A506B2313F26670B92EC1B@ntht201e.siemenscomms.co.uk>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-type: text/plain
Content-transfer-encoding: 7BIT
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Francois,

"If a UAS receives a request with the sips
   option-tag in a Supported or Require header field and it accepts the
   registration, it MUST include the sips option-tag in Supported or
   Require header in a 200 (OK) response."
A UAS should not receive a REGISTER request - only a registrar should
receive such a request.

"it MUST include the sips option-tag in Supported or
   Require header in a 200 (OK) response."
What is the meaning of a Require header field in a response?

"If a UAC sent a request with a sips option-tag
   in a Supported header, and the 200 (OK) did not include a sips
   option-tag in a Require or Supported header,"
Same comment.

John 

> -----Original Message-----
> From: Francois Audet [mailto:audet@nortel.com] 
> Sent: 16 April 2007 23:27
> To: sip@ietf.org
> Subject: [Sip] draft-ietf-sip-sips-03.txt
> 
> Hi all,
> 
> I have submitted draft-ietf-sip-sips-03.
>  
> I have integrated all the agreements of the Prague meeting. Including
> the change to Standards Track draft, and the RFC 2119 wording changes,
> as well as the restructure of the document with Normative requirements
> for UA and Proxy separated. Also the deprecation of the last hop
> exception.
> 
> I also have attempted to capture the suggestions for improvements
> and consensus from the mailing list.
> 
> There are two remaining issues that I have documented in Annex C.
> 
> Those 2 issues are what we need to focus on:
> 
>   1.  Do we deprecate the "last hop retarget upgrade exception"?  The
>        document currently assumes that it IS deprecated, as 
> this is the
>        preference of the author.
> 
>   2.  Do we need the sips option tag? The current document 
> assumes that
>        we do use the option tag, and that is the preference of the
> author.
>        (There is at least one dissenting voice on that one: Hisham).
> 
> Please comment on those two open issues, and use a proper Subject for
> the
> topic.
> 
> If you have other comments, please use appropriate Subject fields to
> make
> the thread easier to follow.
> 
> Please also not repeat topics that have been beaten to death already.
> 
> 
> > -----Original Message-----
> > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] 
> > Sent: Monday, April 16, 2007 12:50
> > To: i-d-announce@ietf.org
> > Cc: sip@ietf.org
> > Subject: [Sip] I-D ACTION:draft-ietf-sip-sips-03.txt
> > 
> > A New Internet-Draft is available from the on-line 
> > Internet-Drafts directories.
> > This draft is a work item of the Session Initiation Protocol 
> > Working Group of the IETF.
> > 
> > 	Title		: The use of the SIPS URI Scheme in the 
> > Session Initiation Protocol (SIP)
> > 	Author(s)	: F. Audet
> > 	Filename	: draft-ietf-sip-sips-03.txt
> > 	Pages		: 54
> > 	Date		: 2007-4-16
> > 	
> > This document provides clarifications and guidelines concerning the
> >    use of SIPS URI scheme in the Session Initiation Protocol 
> > (SIP).  It
> >    also makes normative changes to SIP.  This document also 
> provides a
> >    discussion of possible future steps in specification.
> > 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-03.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-sip-sips-03.txt".
> > 
> > A list of Internet-Drafts directories can be found in 
> > http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> > Internet-Drafts can also be obtained by e-mail.
> > 
> > Send a message to:
> > 	mailserv@ietf.org.
> > In the body type:
> > 	"FILE /internet-drafts/draft-ietf-sip-sips-03.txt".
> > 	
> > NOTE:	The mail server at ietf.org can return the document in
> > 	MIME-encoded form by using the "mpack" utility.  To use this
> > 	feature, insert the command "ENCODING mime" before the "FILE"
> > 	command.  To decode the response(s), you will need "munpack" or
> > 	a MIME-compliant mail reader.  Different MIME-compliant 
> > mail readers
> > 	exhibit different behavior, especially when dealing with
> > 	"multipart" MIME messages (i.e. documents which have been split
> > 	up into multiple messages), so check your local documentation on
> > 	how to manipulate these messages.
> > 
> > Below is the data which will enable a MIME compliant mail 
> > reader implementation to automatically retrieve the ASCII 
> > version of the Internet-Draft.
> > 
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 08:22:20 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdmhL-0008Kn-1W; Tue, 17 Apr 2007 08:22:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdmhI-00087c-2F
	for sip@ietf.org; Tue, 17 Apr 2007 08:22:12 -0400
Received: from smtp-2.hut.fi ([130.233.228.92])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdmhG-0001yX-Gv
	for sip@ietf.org; Tue, 17 Apr 2007 08:22:12 -0400
Received: from localhost (katosiko.hut.fi [130.233.228.115])
	by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id l3HCLEde012677;
	Tue, 17 Apr 2007 15:21:14 +0300
Received: from smtp-2.hut.fi ([130.233.228.92])
	by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new,
	port 10024)
	with LMTP id 23040-50-8; Tue, 17 Apr 2007 15:21:13 +0300 (EEST)
Received: from mail.tml.hut.fi (mail.tml.hut.fi [130.233.47.34])
	by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id l3HCKqm1012568;
	Tue, 17 Apr 2007 15:20:52 +0300
Received: from localhost (localhost.tml.hut.fi [127.0.0.1])
	by mail.tml.hut.fi (Postfix) with ESMTP id 229B93A2CD7;
	Tue, 17 Apr 2007 15:20:52 +0300 (EEST)
Received: from mail.tml.hut.fi ([127.0.0.1])
	by localhost (mail.tml.hut.fi [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 26443-07; Tue, 17 Apr 2007 15:20:51 +0300 (EEST)
Received: from localhost (tml-yp-4.tml.hut.fi [130.233.45.32])
	by mail.tml.hut.fi (Postfix) with ESMTP id F16453A2CCC;
	Tue, 17 Apr 2007 15:20:50 +0300 (EEST)
Received: from t-110-gw.tml.hut.fi (t-110-gw.tml.hut.fi [130.233.45.45]) by
	horde.tml.hut.fi (Horde MIME library) with HTTP;
	Tue, 17 Apr 2007 15:20:50 +0300
Message-ID: <20070417152050.db8ibpc1wg8ko8ww@horde-intra.tml.hut.fi>
Date: Tue, 17 Apr 2007 15:20:50 +0300
From: sergiole@tml.hut.fi
To: sip@ietf.org
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.3)
X-TML-Virus-Scanned: amavisd-new-2.3.2-tml at tml.hut.fi
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on katosiko.hut.fi
X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi
X-Spam-Score: 0.2 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: fluffy@cisco.com, rohan@ekabal.com
Subject: [Sip] Outbound-08 Processing REGISTER Responses
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org




Hi,


1.

  Reading outbound-08 I did not find any comment about where the =20
flowtoken must be located in a REGISTER response (from a Registrar to =20
the Edge Proxy).

  I guess that it should be in the Path header, could you confirm this issue=
?


2.

  Below I include a REGISTER request and 200 OK response between an =20
Edge Proxy and a Registrar in the following scenario.



    UAC ------------ EdgePx ----------- Registrar
[10.1.0.11]       [10.1.0.6]          [10.1.0.5]



I will appreciate any comments about the composition of the SIP body.



                             REGISTER
    UAC ------------ EdgePx ----------> Registrar
[10.1.0.11]       [10.1.0.6]          [10.1.0.5]


         REGISTER sip:10.1.0.5 SIP/2.0
         Via: SIP/2.0/UDP 10.1.0.6:5060;branch=3Dbranch-pending
         Via: SIP/2.0/TCP 10.1.0.11:5060;rport;branch=3Dz9hG4bK1988891527
         From: <sip:caller@10.1.0.11>;tag=3D692882550
         To: <sip:caller@10.1.0.11>
         Call-ID: 164605791@10.1.0.11
         CSeq: 1 REGISTER
         Contact: =20
<sip:callee@10.1.0.11>;+sip-instance=3D"<urn:uuid:82b22a1f-25bb-4c7d-9e09-a7=
8d5d5f8755>";reg-id=3D1
         Path: <sip:6q1vwDv9ahfsyBEKAQBrE8QKAQAGE8Q=3D@10.1.0.6:5060;lr;ob>
         Max-forwards: 69
         User-agent:
         Expires: 3600
         Supported: path
         Content-Length: 0


                               200 OK
    UAC ------------ EdgePx <---------- Registrar
[10.1.0.11]       [10.1.0.6]          [10.1.0.5]


         SIP/2.0 200 OK
         Via: SIP/2.0/UDP 10.1.0.6:5060;branch=3Dbranch-pending
         Via: SIP/2.0/TCP 10.1.0.11:5060;rport;branch=3Dz9hG4bK1988891527
         From: <sip:caller@10.1.0.11>;tag=3D692882550
         To: <sip:caller@10.1.0.11>
         Call-ID: 164605791@10.1.0.11
         CSeq: 1 REGISTER
         Contact: =20
<sip:callee@10.1.0.11>;+sip-instance=3D"<urn:uuid:82b22a1f-25bb-4c7d-9e09-a7=
8d5d5f8755>";reg-id=3D1
         Path: <sip:6q1vwDv9ahfsyBEKAQBrE8QKAQAGE8Q=3D@10.1.0.6:5060;lr;>
         Max-forwards: 69
         User-agent:
         Expires: 3600
         Supported: outbound
         Content-Length: 0


Regards,

Sergio




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 08:55:44 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdnDi-0006nf-BB; Tue, 17 Apr 2007 08:55:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdnDg-0006na-Lg
	for sip@ietf.org; Tue, 17 Apr 2007 08:55:40 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdnDg-0000h9-BZ
	for sip@ietf.org; Tue, 17 Apr 2007 08:55:40 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-2.cisco.com with ESMTP; 17 Apr 2007 08:55:40 -0400
X-IronPort-AV: i="4.14,419,1170651600"; 
	d="scan'208"; a="118721869:sNHT53502276"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3HCtdWV019999; 
	Tue, 17 Apr 2007 08:55:39 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3HCtSGl000423; 
	Tue, 17 Apr 2007 12:55:33 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 17 Apr 2007 08:55:32 -0400
Received: from [161.44.174.118] ([161.44.174.118]) by
	xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 17 Apr 2007 08:55:31 -0400
Message-ID: <4624C3BF.8070709@cisco.com>
Date: Tue, 17 Apr 2007 08:55:27 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
References: <4616851D.5070305@softarmor.com>		<20070406174901.D89C45C027@laser.networkresonance.com>		<46172B40.8090107@softarmor.com>		<20070407151244.87A941CC3D@delta.rtfm.com>		<4617E6B8.5070601@softarmor.com>		<20070407192220.253931CC3D@delta.rtfm.com>		<46194A1A.1020705@softarmor.com>		<20070408202105.0F2725C027@laser.networkresonance.com>		<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
	<461F00B3.1090206@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com> <461F9AA9.4010700@cisco.com>
	<D1845680-1467-4ACC-84D9-F7EDCB3EE71C@softarmor.com>
	<4623AD9C.8060508@cisco.com> <46245F71.8050901@softarmor.com>
In-Reply-To: <46245F71.8050901@softarmor.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 Apr 2007 12:55:31.0747 (UTC)
	FILETIME=[AE8E9F30:01C780EF]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3707; t=1176814540;
	x=1177678540; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20SIPS=20question=3A=20How=20to=20prevent=20pla
	intext=20requests=20from=20being=0A=20delivered=20to=20a=20UA
	|Sender:=20 |To:=20Dean=20Willis=20<dean.willis@softarmor.com>;
	bh=H8HtznWX+ABIhQ8RcQ3uIUvgONWLjpnypylvRl/W4E0=;
	b=Je5Ewrx/HXniu/AfcQYAzbIA1Dg9nAIv8dRtaJTeSTaZNMQZ4Ur6S4Or6S1cF5iRv6NqD8Ju
	gkSjSiAFuVtdPRxQqu7f6BzkgenLWb7Ix/FLDFVj/lFeFSfBktHSM7z5;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Dean,

I think you are trying to associate two distinct semantics with sips URI:
- that sessions established using this URI should be secured
   hop by hop from end to end
- that such a URI should be considered "unlisted" and so kept
   "secret".

IMO these semantics should not be conflated because:

- I may want to have a sip (or tel or IM or PRES) URI
   that is "unlisted", and I may want to have a sips URI
   that is "listed".

- The semantics of of being "unlisted" are likely to be
   just as hard to pin down as the semantics of sips for
   e22 security is. IMO we don't want to hold up the clarification
   of sips until that can be done.

	Paul


Dean Willis wrote:
> Paul Kyzivat wrote:
>>>
>>> If Alice had just not sent the request via SIP, but used SIPS, the it 
>>> would have been solved.
>>
>> Unless Alice believes that the address itself is a secret to be 
>> protected, she may not protect it.
> 
> Exactly my point. She needs to KNOW that if she's given a SIPS address, 
> that it should be protected by using it only for SIPS requests.
> 
>>
>> AFAIK, there has never been any expectation that the presence of 
>> "sips" in the URI carried an expectation that somebody possessing such 
>> an address keep it confidential. Quite to the contrary, I have assumed 
>> that the expectation was that it might be put on business cards, 
>> stored in directories, ENUM, etc.
> 
> True. But if I give you my private unlisted number for encrypted calls 
> and you start posting it on web pages with text that says "For a good 
> time, call" , I'm gonna be angry. And I'll be only marginally less angry 
> if you start schlepping it across the net in unprotected SIP INVITEs.
> 
>>>>> Since traceroute on biloxi.example.com may well give us a good idea 
>>>>> of the physical location of biloxi.example.com, an interceptor
>>>
>>> In the call flow described (from 3665) there is no home proxy.
>>>
>>> THERE IS NO REQUIREMENT THAT SIP USERS HAVE A HOME PROXY AND I WOULD 
>>> BE VERY HAPPY IF PEOPLE WOULD REMEMBER THAT!
>>
>> Its fine for there to be no home proxy. But if so, then Bob must 
>> publicize his actual address, and expect that bad guys may get access 
>> to it.
>>
> But Bob may publicize his actual address only within the confines of a 
> directory or location server that makes that address available only to 
> authenticated and authorized parties.
> 
> Alice sends INVITE for Bob' s SIPS AOR to Bob's LS.
> Bob's LS returns a WWW-Auth to Alice.
> Alice replies with credentials.
> Bob's LS returns a SIPS contact.
> Alice sends a SIP INVITE to the equivalent contact.
> 
> This is perfectly legal by the current draft as I understand it, and 
> Alice would expect that it would work.
> 
> But it will completely compromise the secrecy of Bob's AOR->Contact 
> binding, and Bob has no way to say "DON"T DO THIS TO ME!".
> 
>>> But IF there had been a home proxy in this example, and the request 
>>> were intercepted between Bob's home proxy and Bob, then it would 
>>> reveal Bob's location as understood by Bob's home proxy.
>>
>> I thought the idea was that Bob himself had only the sips address. So 
>> the link between Bob's home proxy and Bob would always be via TLS. So 
>> the message won't be intercepted on that leg. It would have to be 
>> intercepted before reaching his home proxy. And there it would only 
>> reveal his AOR.
>>
> 
> No, that wasn't the case I was trying to (and apparently failing to) 
> explain.
>>
>> I guess we are making some significantly different assumptions about 
>> what is going on.
>>
> Ah, that's probably true.
> 
> 
> -- 
> Dean
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 09:07:21 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdnOu-0004Ic-Ps; Tue, 17 Apr 2007 09:07:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdnOt-0004IV-IQ
	for sip@ietf.org; Tue, 17 Apr 2007 09:07:15 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdnOs-00048X-8b
	for sip@ietf.org; Tue, 17 Apr 2007 09:07:15 -0400
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-2.cisco.com with ESMTP; 17 Apr 2007 09:07:15 -0400
X-IronPort-AV: i="4.14,419,1170651600"; 
	d="scan'208"; a="118723059:sNHT49857036"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3HD7E0F017966; 
	Tue, 17 Apr 2007 09:07:14 -0400
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 l3HD79Gl003940; 
	Tue, 17 Apr 2007 13:07:13 GMT
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.1830); 
	Tue, 17 Apr 2007 09:07:08 -0400
Received: from [161.44.174.118] ([161.44.174.118]) by
	xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 17 Apr 2007 09:07:08 -0400
Message-ID: <4624C679.60107@cisco.com>
Date: Tue, 17 Apr 2007 09:07:05 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
References: <4616851D.5070305@softarmor.com> <4617E6B8.5070601@softarmor.com>	
	<20070407192220.253931CC3D@delta.rtfm.com>	
	<46194A1A.1020705@softarmor.com>	
	<20070408202105.0F2725C027@laser.networkresonance.com>	
	<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>	
	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>	
	<461F00B3.1090206@softarmor.com>	
	<66cd252f0704130240x707ff7f3g996c002cfb5e932@mail.gmail.com>	
	<461F888A.2080609@cisco.com>
	<66cd252f0704152345j598bafc6h7aa53f0e3b2b3b6@mail.gmail.com>
	<4623AF6C.7080207@cisco.com> <462460D5.1090103@softarmor.com>
In-Reply-To: <462460D5.1090103@softarmor.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 Apr 2007 13:07:08.0324 (UTC)
	FILETIME=[4DBFD640:01C780F1]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2534; t=1176815234;
	x=1177679234; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20SIPS=20question=3A=20How=20to=20prevent=20pla
	intext=20requests=20from=20being=0A=20delivered=20to=20a=20UA
	|Sender:=20 |To:=20Dean=20Willis=20<dean.willis@softarmor.com>;
	bh=KQL6BdUo1Du6mh7MtinUuf52t8VomOBcdy/Eawfx5TA=;
	b=z01M/jkKpNe0jnq/X6wWSDITnbPS9UjlNMVZY2nooggcOi1ggWxmgGJaBoLZZzQr9l71gljY
	c1X1aW7kHAyb2/boMG91Ic2LxVxGgJqTZSBkC5Ato/PzYg4chUPbSeom;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org



Dean Willis wrote:
> Paul Kyzivat wrote:
>>
>> So you mean both a sip and sips contact would be registered over the 
>> same (tls) flow. As Francois said, he proposed this long ago and it 
>> was rejected for a bunch of reasons. The only benefit I can see to 
>> this is as a way to indicate a policy regarding whether sip requests 
>> are/aren't desired over this flow. Things will work just fine without 
>> that policy (the UAS can simply reject them if it wishes). It 
>> complicates a lot of things so I prefer to stick with what was already 
>> decided about this.
> 
> No, this DOESN'T work fine, as the privacy of the UAS's AOR-to-Contact 
> binding is compromised by sending the request from the UAC, even if the 
> UAS rejects the request.

The above is discussing *registrations*, which implies the presence of a 
registrar. In most cases, the UAC is not the registrar and does not have 
access to the location service used by the registrar. The UAC sends 
requests to the AOR. Those requests are serviced by something that does 
have access to the location service.

The UAC sending a request to the AOR does not compromise the UAS's 
Contact binding. That can be compromised in two ways:

- if the "home proxy" translates the AOR to the contact and then
   forwards the request over in insecure link. If its a sips contact
   we have already banned that.

- if the "home proxy" responds with a 3xx containing the registered
   contact of the UAS. If the request had been unsecured then the
   contact may indeed be compromised. (Note that doing this is
   considered a *feature* in a number of scenarios. For instance if
   the UAC has "guessed" at a sip AOR, and is then told it must use
   a sips AOR to contact this UAS.) This is a policy issue of whether
   the home proxy *should* disclose the contact addresses, and if so,
   with what constraints.

> If the sender KNEW that the UAS only accepted SIPS, this compromise 
> would not occur.

How would the sender know that? I might be trying to call you by 
guessing your sip address from your email address.

	Paul

> And if the sender is given only a SIPS URI for an AOR, the sender MUST 
> assume that the UAS accepts only SIPS requests and MUST NOT send a 
> request to that AOR using SIP. Otherwise, the privacy of the UAS's 
> AOR-to-Contact binding might be compromised (and in security, one can 
> assume that if it might be compromised, it probably has been-- It's 
> tainted).
> 
> -- 
> Dean
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 09:51:45 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hdo5v-0006q7-4O; Tue, 17 Apr 2007 09:51:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdo5t-0006po-HV
	for sip@ietf.org; Tue, 17 Apr 2007 09:51:41 -0400
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdo5r-0007ez-8M
	for sip@ietf.org; Tue, 17 Apr 2007 09:51:41 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	l3HDowp28572; Tue, 17 Apr 2007 13:50:59 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
Date: Tue, 17 Apr 2007 08:51:32 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
In-Reply-To: <46245D01.3070301@softarmor.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being delivered to a UA
thread-index: AceAsn9MhI6/BKOuTsWgK/eSukAVYgARH3oQ
References: <4616851D.5070305@softarmor.com>
	<20070406174901.D89C45C027@laser.networkresonance.com>
	<46172B40.8090107@softarmor.com>
	<20070407151244.87A941CC3D@delta.rtfm.com>
	<4617E6B8.5070601@softarmor.com>
	<20070407192220.253931CC3D@delta.rtfm.com>
	<46194A1A.1020705@softarmor.com>
	<20070408202105.0F2725C027@laser.networkresonance.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>
	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
	<461F00B3.1090206@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
	<46245D01.3070301@softarmor.com>
From: "Francois Audet" <audet@nortel.com>
To: "Dean Willis" <dean.willis@softarmor.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: sip@ietf.org, Paul Kyzivat <pkyzivat@cisco.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

> > Dean, the request in this scenario
> > was sent out over non-TLS sent with sips in the first place. The=20
> > damage done.
> >
> >  =20
> Huh? No, the request was sent SIP because the user or user's=20
> UA chose to downgrade from the SIPS URI they had been given.

No, the UA can not downgrade and still be compliant.

That is clear in the draft.

> > Dean, the request was sent using SIP in the first place. If=20
> there is=20
> > no proxy, then the 3XX solution makes more sense.
> >
> >  =20
>=20
> Yes, that's exactly my point. If you're given a SIPS URI, use=20
> it. Don't downgrade to SIP. Ever. Not at a proxy, not at a=20
> UA, not at a user.

I think everybody agrees on this.=20

So we are in agreement.

> And text (which we have) that effectively says "If the user registers=20
> with SIPS it means they want to receive both SIP and SIPS requests" is
> dangerously misleading, because it encourages the user to=20
> downgrade and=20
> expect it to work.

Read the new version and let me know if it is still ambiguous, because
the text doesn't really say that. It has lots of information on how
to make it work if you do NOT wish to be reachable with SIP over
non-TLS.
Both from the perspective of the User and from the perspective of the=20
Proxy.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 09:53:55 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hdo83-0007QD-5U; Tue, 17 Apr 2007 09:53:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdo81-0007Q6-UF
	for sip@ietf.org; Tue, 17 Apr 2007 09:53:53 -0400
Received: from zrtps0kp.nortel.com ([47.140.192.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdo7z-00028i-MF
	for sip@ietf.org; Tue, 17 Apr 2007 09:53:53 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3HDrSO05709; Tue, 17 Apr 2007 13:53:28 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
Date: Tue, 17 Apr 2007 08:53:27 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF100DE890@zrc2hxm0.corp.nortel.com>
In-Reply-To: <462460D5.1090103@softarmor.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being delivered to a UA
thread-index: AceAtMaP0BA3OyNSTCCAaZZuqgsyvwAQtFww
References: <4616851D.5070305@softarmor.com> <4617E6B8.5070601@softarmor.com>
	<20070407192220.253931CC3D@delta.rtfm.com>
	<46194A1A.1020705@softarmor.com>
	<20070408202105.0F2725C027@laser.networkresonance.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>
	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
	<461F00B3.1090206@softarmor.com>
	<66cd252f0704130240x707ff7f3g996c002cfb5e932@mail.gmail.com>
	<461F888A.2080609@cisco.com>
	<66cd252f0704152345j598bafc6h7aa53f0e3b2b3b6@mail.gmail.com>
	<4623AF6C.7080207@cisco.com> <462460D5.1090103@softarmor.com>
From: "Francois Audet" <audet@nortel.com>
To: "Dean Willis" <dean.willis@softarmor.com>,
	"Paul Kyzivat" <pkyzivat@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Dean, you are talking about a different case.

Nobody is suggesting that if you are given a SIPS URI you
should also assume that a SIP URI will work.

I think it's pretty obvious.=20

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]=20
> Sent: Monday, April 16, 2007 22:53
> To: Paul Kyzivat
> Cc: Hisham Khartabil; sip@ietf.org; Audet, Francois (SC100:3055)
> Subject: Re: [Sip] SIPS question: How to prevent plaintext=20
> requests from being delivered to a UA
>=20
> Paul Kyzivat wrote:
> >
> > So you mean both a sip and sips contact would be registered=20
> over the=20
> > same (tls) flow. As Francois said, he proposed this long ago and it=20
> > was rejected for a bunch of reasons. The only benefit I can see to=20
> > this is as a way to indicate a policy regarding whether sip=20
> requests=20
> > are/aren't desired over this flow. Things will work just=20
> fine without=20
> > that policy (the UAS can simply reject them if it wishes). It=20
> > complicates a lot of things so I prefer to stick with what=20
> was already=20
> > decided about this.
>=20
> No, this DOESN'T work fine, as the privacy of the UAS's=20
> AOR-to-Contact binding is compromised by sending the request=20
> from the UAC, even if the UAS rejects the request.
>=20
> If the sender KNEW that the UAS only accepted SIPS, this=20
> compromise would not occur.
>=20
> And if the sender is given only a SIPS URI for an AOR, the=20
> sender MUST assume that the UAS accepts only SIPS requests=20
> and MUST NOT send a request to that AOR using SIP. Otherwise,=20
> the privacy of the UAS's AOR-to-Contact binding might be=20
> compromised (and in security, one can assume that if it might=20
> be compromised, it probably has been-- It's tainted).
>=20
> --
> Dean
>=20
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From qiwwpbww@citylan.bg Tue Apr 17 10:10:41 2007
Return-path: <qiwwpbww@citylan.bg>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdoOH-0007Pt-5j
	for sip-archive@lists.ietf.org; Tue, 17 Apr 2007 10:10:41 -0400
Received: from 107-39.citylan.bg ([89.25.107.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HdoOF-0000YK-RH
	for sip-archive@lists.ietf.org; Tue, 17 Apr 2007 10:10:41 -0400
From:	"month" <qiwwpbww@citylan.bg>
To: sip-archive@lists.ietf.org
Subject: Your invest. report
Date:	Tue, 17 Apr 2007 17:10:32 -0300
MIME-Version: 1.0
Content-Type: multipart/related;
	boundary="----=_NextPart_000_0005_01C78113.4E7F5D40"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: AceBE05/AfuDYyf2QcCae9h8EPPenQ==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
Message-Id: <75AD1F51814FB1B.2F96830A03@citylan.bg>
X-Spam-Score: 1.3 (+)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581

------=_NextPart_000_0005_01C78113.4E7F5D40
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2912" name=3D"GENERATOR">
</HEAD>
<BODY>
<DIV align=3Dleft><FONT face=3DArial size=3D2><B>DarkLord: DWPI Hits The Street, Price Climbs 221.43%</B></FONT></DIV><BR>
<DIV align=3Dleft><FONT face=3DArial size=3D2><I>Distributed Power Inc.</I></FONT></DIV><BR>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Symbol: <B>DPWI</B> </FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Price: <B>$0.40 (+0.31)</B></FONT></DIV><BR>
<DIV align=3Dleft><FONT face=3DArial size=3D2>News hits the streets!!! DPWI acquires huge oil reserves, drills deeper on current wells increasing production, and now opens Asian division. </FONT></DIV><BR>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Investors go nuts today and price rockets 221.43%. </FONT></DIV><BR>
<DIV align=3Dleft><FONT face=3DArial size=3D2><B><U>Act fast, read the news and get on DPWI first thing Tuesday!<U></B></FONT></DIV></BODY></HTML>

------=_NextPart_000_0005_01C78113.4E7F5D40--




From sip-bounces@ietf.org Tue Apr 17 10:22:58 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hdoa7-0003p8-NK; Tue, 17 Apr 2007 10:22:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdoa6-0003p3-65
	for sip@ietf.org; Tue, 17 Apr 2007 10:22:54 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdoa4-0003Rm-SY
	for sip@ietf.org; Tue, 17 Apr 2007 10:22:54 -0400
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-2.cisco.com with ESMTP; 17 Apr 2007 10:22:48 -0400
X-IronPort-AV: i="4.14,419,1170651600"; 
	d="scan'208"; a="118731501:sNHT47750348"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3HEMmSQ023325; 
	Tue, 17 Apr 2007 10:22:48 -0400
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 l3HEMVlO018578; 
	Tue, 17 Apr 2007 14:22:40 GMT
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.1830); 
	Tue, 17 Apr 2007 10:22:34 -0400
Received: from [161.44.174.118] ([161.44.174.118]) by
	xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 17 Apr 2007 10:22:34 -0400
Message-ID: <4624D827.6070707@cisco.com>
Date: Tue, 17 Apr 2007 10:22:31 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Francois Audet <audet@nortel.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
References: <4616851D.5070305@softarmor.com>
	<20070406174901.D89C45C027@laser.networkresonance.com>
	<46172B40.8090107@softarmor.com>
	<20070407151244.87A941CC3D@delta.rtfm.com>
	<4617E6B8.5070601@softarmor.com>
	<20070407192220.253931CC3D@delta.rtfm.com>
	<46194A1A.1020705@softarmor.com>
	<20070408202105.0F2725C027@laser.networkresonance.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>
	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
	<461F00B3.1090206@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
	<46245D01.3070301@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 Apr 2007 14:22:34.0345 (UTC)
	FILETIME=[D777D590:01C780FB]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1116; t=1176819768;
	x=1177683768; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20SIPS=20question=3A=20How=20to=20prevent=20pla
	intext=20requests=20from=20being=0A=20delivered=20to=20a=20UA
	|Sender:=20 |To:=20Francois=20Audet=20<audet@nortel.com>;
	bh=5fwb4SY405iqzb9ElyBtXlyUT0NJj+ka8bGjwi7NOH0=;
	b=S2tVyKs+Vn0hVig3JP4QpR9GNxX4U8+7a6rjojvnU8/JzVQBcO15EnN2TV5T+NCg4uEtXWzD
	JalWK1cieNrPZLqNE0YGYs/fzIfyuqqhI2/Gas3PUwmPlYwoPFeMOrWG;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: sip@ietf.org, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org



Francois Audet wrote:

>> Yes, that's exactly my point. If you're given a SIPS URI, use 
>> it. Don't downgrade to SIP. Ever. Not at a proxy, not at a 
>> UA, not at a user.
> 
> I think everybody agrees on this. 
> 
> So we are in agreement.

Well...

IMO its pointless to base any decisions on the assumption that everyone 
will conform to the above.

It sounds good until a user with a UA that doesn't support sips wants to 
call somebody that he only has a sips URI for. At that point his choices 
are:
- give up
- try the downgraded URI

If there is *any* chance that downgrading will work then a lot of users 
will try it. And even if there is *no* chance of it working some number 
of users will try it. And its quite likely that often the downgrading 
will be done by *mistake*, by somebody that does understand there is a 
difference between sip and sips.

And it probably *will* work in a lot of cases, because a lot of people 
will want to support both.

So, you can say that users SHOULD NOT do it, or MUST NOT do it, but 
assume that it will be done anyway.

	Paul

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 10:36:27 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hdon5-0002eq-2a; Tue, 17 Apr 2007 10:36:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdon3-0002ed-9V
	for sip@ietf.org; Tue, 17 Apr 2007 10:36:17 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdon2-0007FY-Ts
	for sip@ietf.org; Tue, 17 Apr 2007 10:36:17 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3HEaEk26594; Tue, 17 Apr 2007 14:36:14 GMT
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: [Sip] draft-ietf-sip-sips-03.txt
Date: Tue, 17 Apr 2007 09:36:11 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF100DE964@zrc2hxm0.corp.nortel.com>
In-Reply-To: <50B1CBA96870A34799A506B2313F26670B92EC1B@ntht201e.siemenscomms.co.uk>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] draft-ietf-sip-sips-03.txt
thread-index: AceAydRlHKedyTNfRGibi9R4RYp8fAAM7tcg
References: <50B1CBA96870A34799A506B2313F26670B92EC1B@ntht201e.siemenscomms.co.uk>
From: "Francois Audet" <audet@nortel.com>
To: "Elwell, John" <john.elwell@siemens.com>, <sip@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 225414c974e0d6437992164e91287a51
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Thank you. I will make the corrections.

First one should be about request (not necessarily REGISTER, and by
the way, REGISTER is a type of UAS).

The other ones should have not included Require. You are right.=20

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens.com]=20
> Sent: Tuesday, April 17, 2007 01:25
> To: Audet, Francois (SC100:3055); sip@ietf.org
> Subject: RE: [Sip] draft-ietf-sip-sips-03.txt
>=20
> Francois,
>=20
> "If a UAS receives a request with the sips
>    option-tag in a Supported or Require header field and it=20
> accepts the
>    registration, it MUST include the sips option-tag in Supported or
>    Require header in a 200 (OK) response."
> A UAS should not receive a REGISTER request - only a=20
> registrar should receive such a request.
>=20
> "it MUST include the sips option-tag in Supported or
>    Require header in a 200 (OK) response."
> What is the meaning of a Require header field in a response?
>=20
> "If a UAC sent a request with a sips option-tag
>    in a Supported header, and the 200 (OK) did not include a sips
>    option-tag in a Require or Supported header,"
> Same comment.
>=20
> John=20
>=20
> > -----Original Message-----
> > From: Francois Audet [mailto:audet@nortel.com]
> > Sent: 16 April 2007 23:27
> > To: sip@ietf.org
> > Subject: [Sip] draft-ietf-sip-sips-03.txt
> >=20
> > Hi all,
> >=20
> > I have submitted draft-ietf-sip-sips-03.
> > =20
> > I have integrated all the agreements of the Prague meeting.=20
> Including=20
> > the change to Standards Track draft, and the RFC 2119=20
> wording changes,=20
> > as well as the restructure of the document with Normative=20
> requirements=20
> > for UA and Proxy separated. Also the deprecation of the last hop=20
> > exception.
> >=20
> > I also have attempted to capture the suggestions for=20
> improvements and=20
> > consensus from the mailing list.
> >=20
> > There are two remaining issues that I have documented in Annex C.
> >=20
> > Those 2 issues are what we need to focus on:
> >=20
> >   1.  Do we deprecate the "last hop retarget upgrade=20
> exception"?  The
> >        document currently assumes that it IS deprecated, as this is=20
> > the
> >        preference of the author.
> >=20
> >   2.  Do we need the sips option tag? The current document assumes=20
> > that
> >        we do use the option tag, and that is the preference of the=20
> > author.
> >        (There is at least one dissenting voice on that one: Hisham).
> >=20
> > Please comment on those two open issues, and use a proper=20
> Subject for=20
> > the topic.
> >=20
> > If you have other comments, please use appropriate Subject=20
> fields to=20
> > make the thread easier to follow.
> >=20
> > Please also not repeat topics that have been beaten to=20
> death already.
> >=20
> >=20
> > > -----Original Message-----
> > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> > > Sent: Monday, April 16, 2007 12:50
> > > To: i-d-announce@ietf.org
> > > Cc: sip@ietf.org
> > > Subject: [Sip] I-D ACTION:draft-ietf-sip-sips-03.txt
> > >=20
> > > A New Internet-Draft is available from the on-line=20
> Internet-Drafts=20
> > > directories.
> > > This draft is a work item of the Session Initiation=20
> Protocol Working=20
> > > Group of the IETF.
> > >=20
> > > 	Title		: The use of the SIPS URI Scheme in the=20
> > > Session Initiation Protocol (SIP)
> > > 	Author(s)	: F. Audet
> > > 	Filename	: draft-ietf-sip-sips-03.txt
> > > 	Pages		: 54
> > > 	Date		: 2007-4-16
> > > =09
> > > This document provides clarifications and guidelines=20
> concerning the
> > >    use of SIPS URI scheme in the Session Initiation=20
> Protocol (SIP). =20
> > > It
> > >    also makes normative changes to SIP.  This document also
> > provides a
> > >    discussion of possible future steps in specification.
> > >=20
> > > A URL for this Internet-Draft is:
> > > http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-03.txt
> > >=20
> > > To remove yourself from the I-D Announcement list, send a=20
> message to=20
> > > i-d-announce-request@ietf.org with the word unsubscribe=20
> in the body=20
> > > of the message.
> > > You can also visit
> > https://www1.ietf.org/mailman/listinfo/I-D-announce
> > > to change your subscription settings.
> > >=20
> > > Internet-Drafts are also available by anonymous FTP.=20
> Login with the=20
> > > username "anonymous" and a password of your e-mail address. After=20
> > > logging in, type "cd internet-drafts" and then "get=20
> > > draft-ietf-sip-sips-03.txt".
> > >=20
> > > A list of Internet-Drafts directories can be found in=20
> > > http://www.ietf.org/shadow.html or=20
> > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >=20
> > > Internet-Drafts can also be obtained by e-mail.
> > >=20
> > > Send a message to:
> > > 	mailserv@ietf.org.
> > > In the body type:
> > > 	"FILE /internet-drafts/draft-ietf-sip-sips-03.txt".
> > > =09
> > > 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=20
> > > 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.
> > >=20
> > > Below is the data which will enable a MIME compliant mail reader=20
> > > implementation to automatically retrieve the ASCII version of the=20
> > > Internet-Draft.
> > >=20
> >=20
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 10:38:22 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hdop4-0003Yl-3I; Tue, 17 Apr 2007 10:38:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdop2-0003Yf-Rg
	for sip@ietf.org; Tue, 17 Apr 2007 10:38:20 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdop1-0008ON-K1
	for sip@ietf.org; Tue, 17 Apr 2007 10:38:20 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3HEcFk27011; Tue, 17 Apr 2007 14:38:16 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
Date: Tue, 17 Apr 2007 09:38:02 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF100DE968@zrc2hxm0.corp.nortel.com>
In-Reply-To: <4624D827.6070707@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being delivered to a UA
thread-index: AceA++Ic8uhmnETQTXK6rBBO29HxxwAAfmkw
References: <4616851D.5070305@softarmor.com>
	<20070406174901.D89C45C027@laser.networkresonance.com>
	<46172B40.8090107@softarmor.com>
	<20070407151244.87A941CC3D@delta.rtfm.com>
	<4617E6B8.5070601@softarmor.com>
	<20070407192220.253931CC3D@delta.rtfm.com>
	<46194A1A.1020705@softarmor.com>
	<20070408202105.0F2725C027@laser.networkresonance.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>
	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
	<461F00B3.1090206@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
	<46245D01.3070301@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
	<4624D827.6070707@cisco.com>
From: "Francois Audet" <audet@nortel.com>
To: "Paul Kyzivat" <pkyzivat@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: sip@ietf.org, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Yes, and the UAS or it's proxy can reject the request.=20

That is covered.



> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20
> Sent: Tuesday, April 17, 2007 07:23
> To: Audet, Francois (SC100:3055)
> Cc: Dean Willis; sip@ietf.org
> Subject: Re: [Sip] SIPS question: How to prevent plaintext=20
> requests from being delivered to a UA
>=20
>=20
>=20
> Francois Audet wrote:
>=20
> >> Yes, that's exactly my point. If you're given a SIPS URI, use it.=20
> >> Don't downgrade to SIP. Ever. Not at a proxy, not at a UA,=20
> not at a=20
> >> user.
> >=20
> > I think everybody agrees on this.=20
> >=20
> > So we are in agreement.
>=20
> Well...
>=20
> IMO its pointless to base any decisions on the assumption=20
> that everyone will conform to the above.
>=20
> It sounds good until a user with a UA that doesn't support=20
> sips wants to call somebody that he only has a sips URI for.=20
> At that point his choices
> are:
> - give up
> - try the downgraded URI
>=20
> If there is *any* chance that downgrading will work then a=20
> lot of users will try it. And even if there is *no* chance of=20
> it working some number of users will try it. And its quite=20
> likely that often the downgrading will be done by *mistake*,=20
> by somebody that does understand there is a difference=20
> between sip and sips.
>=20
> And it probably *will* work in a lot of cases, because a lot=20
> of people will want to support both.
>=20
> So, you can say that users SHOULD NOT do it, or MUST NOT do=20
> it, but assume that it will be done anyway.
>=20
> 	Paul
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 11:29:31 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdpcW-0002R2-Ch; Tue, 17 Apr 2007 11:29:28 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdpcU-0002Qw-Fv
	for sip@ietf.org; Tue, 17 Apr 2007 11:29:26 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdpcT-00045C-Tu
	for sip@ietf.org; Tue, 17 Apr 2007 11:29:26 -0400
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-6.cisco.com with ESMTP; 17 Apr 2007 08:29:24 -0700
X-IronPort-AV: i="4.14,419,1170662400"; 
	d="scan'208"; a="136829612:sNHT60949404"
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l3HFTPqZ009142; 
	Tue, 17 Apr 2007 08:29:25 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3HFTIMF011945;
	Tue, 17 Apr 2007 15:29:18 GMT
Received: from xmb-sjc-231.amer.cisco.com ([128.107.191.73]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 17 Apr 2007 08:29:18 -0700
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: [Sip] SIPS question: How to prevent plaintext requests from
	beingdelivered to a UA
Date: Tue, 17 Apr 2007 08:29:16 -0700
Message-ID: <49DFEF82990374449378AD1198F39F8B03209CAD@xmb-sjc-231.amer.cisco.com>
In-Reply-To: <4624C3BF.8070709@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	beingdelivered to a UA
Thread-Index: AceA77yWHjEkmhxPT4KACjffPsUlhQAFE+cA
From: "Charles Eckel \(eckelcu\)" <eckelcu@cisco.com>
To: "Paul Kyzivat \(pkyzivat\)" <pkyzivat@cisco.com>,
	"Dean Willis" <dean.willis@softarmor.com>
X-OriginalArrivalTime: 17 Apr 2007 15:29:18.0014 (UTC)
	FILETIME=[29D73DE0:01C78105]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5344; t=1176823765;
	x=1177687765; c=relaxed/simple; s=sjdkim3002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=eckelcu@cisco.com;
	z=From:=20=22Charles=20Eckel=20\(eckelcu\)=22=20<eckelcu@cisco.com>
	|Subject:=20RE=3A=20[Sip]=20SIPS=20question=3A=20How=20to=20prevent=20pla
	intext=20requests=20from=20beingdelivered=20to=20a=20UA
	|Sender:=20; bh=3zTaJhztbtn/I/9LR3wwUWvvx2VKhJSWrzVI4Wy4s8A=;
	b=atHdcd4nFaVNQzDAk3IucZGWmhJyZC/lOe1jMcBDb8nSFEAtzCGakr1lwUbijKwk+aSHExef
	72E4D6OxwG4JX8AUkvjUxOTOfONdisOmkqnO/d+e6ptmBRDSFH5MCLuM;
Authentication-Results: sj-dkim-3; header.From=eckelcu@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim3002 verified; ); 
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 200d029292fbb60d25b263122ced50fc
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I think this is different than listed vs. unlisted.=20
If I register a SIPS URI with my registrar and receive only SIPS calls,
then no one except my registrar and perhaps the folks that successfully
contact me, know the details of my registration binding(s). A 3rd party
would not know who I am or who called me.
If someone calls me using SIP, all of this can be learned by a 3rd party
observing the traffic, even if I reject the request.
Note, I am assuming the SIP request was not sent via TLS for at least
one hop. If each hop uses TLS, then it really does not matter whether
the URI was SIP or SIPS.

Cheers,
Charles =20

> -----Original Message-----
> From: Paul Kyzivat (pkyzivat)=20
> Sent: Tuesday, April 17, 2007 5:55 AM
> To: Dean Willis
> Cc: sip@ietf.org
> Subject: Re: [Sip] SIPS question: How to prevent plaintext=20
> requests from beingdelivered to a UA
>=20
> Dean,
>=20
> I think you are trying to associate two distinct semantics=20
> with sips URI:
> - that sessions established using this URI should be secured
>    hop by hop from end to end
> - that such a URI should be considered "unlisted" and so kept
>    "secret".
>=20
> IMO these semantics should not be conflated because:
>=20
> - I may want to have a sip (or tel or IM or PRES) URI
>    that is "unlisted", and I may want to have a sips URI
>    that is "listed".
>=20
> - The semantics of of being "unlisted" are likely to be
>    just as hard to pin down as the semantics of sips for
>    e22 security is. IMO we don't want to hold up the clarification
>    of sips until that can be done.
>=20
> 	Paul
>=20
>=20
> Dean Willis wrote:
> > Paul Kyzivat wrote:
> >>>
> >>> If Alice had just not sent the request via SIP, but used=20
> SIPS, the it=20
> >>> would have been solved.
> >>
> >> Unless Alice believes that the address itself is a secret to be=20
> >> protected, she may not protect it.
> >=20
> > Exactly my point. She needs to KNOW that if she's given a=20
> SIPS address,=20
> > that it should be protected by using it only for SIPS requests.
> >=20
> >>
> >> AFAIK, there has never been any expectation that the presence of=20
> >> "sips" in the URI carried an expectation that somebody=20
> possessing such=20
> >> an address keep it confidential. Quite to the contrary, I=20
> have assumed=20
> >> that the expectation was that it might be put on business cards,=20
> >> stored in directories, ENUM, etc.
> >=20
> > True. But if I give you my private unlisted number for=20
> encrypted calls=20
> > and you start posting it on web pages with text that says=20
> "For a good=20
> > time, call" , I'm gonna be angry. And I'll be only=20
> marginally less angry=20
> > if you start schlepping it across the net in unprotected=20
> SIP INVITEs.
> >=20
> >>>>> Since traceroute on biloxi.example.com may well give us=20
> a good idea=20
> >>>>> of the physical location of biloxi.example.com, an interceptor
> >>>
> >>> In the call flow described (from 3665) there is no home proxy.
> >>>
> >>> THERE IS NO REQUIREMENT THAT SIP USERS HAVE A HOME PROXY=20
> AND I WOULD=20
> >>> BE VERY HAPPY IF PEOPLE WOULD REMEMBER THAT!
> >>
> >> Its fine for there to be no home proxy. But if so, then Bob must=20
> >> publicize his actual address, and expect that bad guys may=20
> get access=20
> >> to it.
> >>
> > But Bob may publicize his actual address only within the=20
> confines of a=20
> > directory or location server that makes that address=20
> available only to=20
> > authenticated and authorized parties.
> >=20
> > Alice sends INVITE for Bob' s SIPS AOR to Bob's LS.
> > Bob's LS returns a WWW-Auth to Alice.
> > Alice replies with credentials.
> > Bob's LS returns a SIPS contact.
> > Alice sends a SIP INVITE to the equivalent contact.
> >=20
> > This is perfectly legal by the current draft as I=20
> understand it, and=20
> > Alice would expect that it would work.
> >=20
> > But it will completely compromise the secrecy of Bob's AOR->Contact=20
> > binding, and Bob has no way to say "DON"T DO THIS TO ME!".
> >=20
> >>> But IF there had been a home proxy in this example, and=20
> the request=20
> >>> were intercepted between Bob's home proxy and Bob, then it would=20
> >>> reveal Bob's location as understood by Bob's home proxy.
> >>
> >> I thought the idea was that Bob himself had only the sips=20
> address. So=20
> >> the link between Bob's home proxy and Bob would always be=20
> via TLS. So=20
> >> the message won't be intercepted on that leg. It would have to be=20
> >> intercepted before reaching his home proxy. And there it=20
> would only=20
> >> reveal his AOR.
> >>
> >=20
> > No, that wasn't the case I was trying to (and apparently=20
> failing to)=20
> > explain.
> >>
> >> I guess we are making some significantly different=20
> assumptions about=20
> >> what is going on.
> >>
> > Ah, that's probably true.
> >=20
> >=20
> > --=20
> > Dean
> >=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 13:40:44 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdrfS-0008CP-9Z; Tue, 17 Apr 2007 13:40:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdrfP-0008CH-CQ
	for sip@ietf.org; Tue, 17 Apr 2007 13:40:36 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdrfO-0000Xt-3X
	for sip@ietf.org; Tue, 17 Apr 2007 13:40:35 -0400
Received: from [206.176.144.212] (rcdn4-dmznat-gw1-nat-27.cisco.com
	[12.5.186.27]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3HGlHhG020137
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Tue, 17 Apr 2007 11:47:18 -0500
In-Reply-To: <4624C3BF.8070709@cisco.com>
References: <4616851D.5070305@softarmor.com>		<20070406174901.D89C45C027@laser.networkresonance.com>		<46172B40.8090107@softarmor.com>		<20070407151244.87A941CC3D@delta.rtfm.com>		<4617E6B8.5070601@softarmor.com>		<20070407192220.253931CC3D@delta.rtfm.com>		<46194A1A.1020705@softarmor.com>		<20070408202105.0F2725C027@laser.networkresonance.com>		<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
	<461F00B3.1090206@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com> <461F9AA9.4010700@cisco.com>
	<D1845680-1467-4ACC-84D9-F7EDCB3EE71C@softarmor.com>
	<4623AD9C.8060508@cisco.com> <46245F71.8050901@softarmor.com>
	<4624C3BF.8070709@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <C1CD7F21-9DBE-40D7-893D-E69E0F02F56C@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
Date: Tue, 17 Apr 2007 12:40:31 -0500
To: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 17, 2007, at 7:55 AM, Paul Kyzivat wrote:

> Dean,
>
> I think you are trying to associate two distinct semantics with  
> sips URI:
> - that sessions established using this URI should be secured
>   hop by hop from end to end
> - that such a URI should be considered "unlisted" and so kept
>   "secret".
>
> IMO these semantics should not be conflated because:
>
> - I may want to have a sip (or tel or IM or PRES) URI
>   that is "unlisted", and I may want to have a sips URI
>   that is "listed".
>
> - The semantics of of being "unlisted" are likely to be
>   just as hard to pin down as the semantics of sips for
>   e22 security is. IMO we don't want to hold up the clarification
>   of sips until that can be done.

What I'm trying to say is that if you were given a SIPS URI, you  
should use SIPS instead of SIP for that callee, because if you  
downgrade to SIP there could be negative consequences. One such  
negative consequence might be the disclosure of a name-to-address  
binding that the callee did not desire to have disclosed. Since we  
currently have no way to express that desire, the safest thing to do  
is to protect it where feasible.

In other words, "be conservative in what we send".

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 13:42:15 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hdrh0-0000n8-VX; Tue, 17 Apr 2007 13:42:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdrgz-0000jq-JI
	for sip@ietf.org; Tue, 17 Apr 2007 13:42:13 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdrgy-0001kp-Av
	for sip@ietf.org; Tue, 17 Apr 2007 13:42:13 -0400
Received: from [206.176.144.212] (rcdn4-dmznat-gw1-nat-27.cisco.com
	[12.5.186.27]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3HGmtIh020161
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Tue, 17 Apr 2007 11:48:56 -0500
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
References: <4616851D.5070305@softarmor.com>
	<20070406174901.D89C45C027@laser.networkresonance.com>
	<46172B40.8090107@softarmor.com>
	<20070407151244.87A941CC3D@delta.rtfm.com>
	<4617E6B8.5070601@softarmor.com>
	<20070407192220.253931CC3D@delta.rtfm.com>
	<46194A1A.1020705@softarmor.com>
	<20070408202105.0F2725C027@laser.networkresonance.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>
	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
	<461F00B3.1090206@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
	<46245D01.3070301@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <BED60BCA-6F49-4890-9A6E-D953740E7446@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
Date: Tue, 17 Apr 2007 12:42:08 -0500
To: Francois Audet <audet@nortel.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: sip@ietf.org, Paul Kyzivat <pkyzivat@cisco.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 17, 2007, at 8:51 AM, Francois Audet wrote:

>>> Dean, the request in this scenario
>>> was sent out over non-TLS sent with sips in the first place. The
>>> damage done.
>>>
>>>
>> Huh? No, the request was sent SIP because the user or user's
>> UA chose to downgrade from the SIPS URI they had been given.
>
> No, the UA can not downgrade and still be compliant.
>
> That is clear in the draft.

It wasn't clear to me at the last reading. Maybe it is now.

>
> Read the new version and let me know if it is still ambiguous, because
> the text doesn't really say that. It has lots of information on how
> to make it work if you do NOT wish to be reachable with SIP over
> non-TLS.
> Both from the perspective of the User and from the perspective of the
> Proxy.
>

Will do.

--
Dean


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 13:45:22 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hdrjy-00049S-H5; Tue, 17 Apr 2007 13:45:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdrjx-00049N-1N
	for sip@ietf.org; Tue, 17 Apr 2007 13:45:17 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdrjv-0003c2-OE
	for sip@ietf.org; Tue, 17 Apr 2007 13:45:17 -0400
Received: from [206.176.144.212] (rcdn4-dmznat-gw1-nat-27.cisco.com
	[12.5.186.27]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3HGpwK4020191
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Tue, 17 Apr 2007 11:51:59 -0500
In-Reply-To: <4624D827.6070707@cisco.com>
References: <4616851D.5070305@softarmor.com>
	<20070406174901.D89C45C027@laser.networkresonance.com>
	<46172B40.8090107@softarmor.com>
	<20070407151244.87A941CC3D@delta.rtfm.com>
	<4617E6B8.5070601@softarmor.com>
	<20070407192220.253931CC3D@delta.rtfm.com>
	<46194A1A.1020705@softarmor.com>
	<20070408202105.0F2725C027@laser.networkresonance.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>
	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
	<461F00B3.1090206@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
	<46245D01.3070301@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
	<4624D827.6070707@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
Date: Tue, 17 Apr 2007 12:45:12 -0500
To: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 17, 2007, at 9:22 AM, Paul Kyzivat wrote:

>
>
> Francois Audet wrote:
>
>>> Yes, that's exactly my point. If you're given a SIPS URI, use it.  
>>> Don't downgrade to SIP. Ever. Not at a proxy, not at a UA, not at  
>>> a user.
>> I think everybody agrees on this. So we are in agreement.
>
> Well...
>
> IMO its pointless to base any decisions on the assumption that  
> everyone will conform to the above.
>
> It sounds good until a user with a UA that doesn't support sips  
> wants to call somebody that he only has a sips URI for. At that  
> point his choices are:
> - give up
> - try the downgraded URI
>
> If there is *any* chance that downgrading will work then a lot of  
> users will try it. And even if there is *no* chance of it working  
> some number of users will try it. And its quite likely that often  
> the downgrading will be done by *mistake*, by somebody that does  
> understand there is a difference between sip and sips.
>
> And it probably *will* work in a lot of cases, because a lot of  
> people will want to support both.
>
> So, you can say that users SHOULD NOT do it, or MUST NOT do it, but  
> assume that it will be done anyway.
>

right.

My intent with some of my suggestions is to reduce the probability  
that it will work, thereby reducing the inclination to try it.

I think it may also be important to address mechanisms for making it  
obvious to the sender (as it already is to the home proxy, should  
there be one that is used with outbound) that it will not work.  
Separate registrations is one possible way to do this.

--
Dean


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 13:46:40 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdrlH-0004u9-RE; Tue, 17 Apr 2007 13:46:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdrlF-0004u2-M8
	for sip@ietf.org; Tue, 17 Apr 2007 13:46:37 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdrlE-0004Ov-8b
	for sip@ietf.org; Tue, 17 Apr 2007 13:46:37 -0400
Received: from [206.176.144.212] (rcdn4-dmznat-gw1-nat-27.cisco.com
	[12.5.186.27]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3HGrJCK020212
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Tue, 17 Apr 2007 11:53:20 -0500
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF100DE968@zrc2hxm0.corp.nortel.com>
References: <4616851D.5070305@softarmor.com>
	<20070406174901.D89C45C027@laser.networkresonance.com>
	<46172B40.8090107@softarmor.com>
	<20070407151244.87A941CC3D@delta.rtfm.com>
	<4617E6B8.5070601@softarmor.com>
	<20070407192220.253931CC3D@delta.rtfm.com>
	<46194A1A.1020705@softarmor.com>
	<20070408202105.0F2725C027@laser.networkresonance.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>
	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
	<461F00B3.1090206@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
	<46245D01.3070301@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
	<4624D827.6070707@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF100DE968@zrc2hxm0.corp.nortel.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <9EB1CFBD-DE7A-4AC7-B642-D7F0C63301B2@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
Date: Tue, 17 Apr 2007 12:46:32 -0500
To: Francois Audet <audet@nortel.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: sip@ietf.org, Paul Kyzivat <pkyzivat@cisco.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 17, 2007, at 9:38 AM, Francois Audet wrote:

> Yes, and the UAS or it's proxy can reject the request.
>
> That is covered.

But what is NOT covered is a way to advise the sender that it is NOT  
likely to work. This would keep them from sending the request (and  
thereby creating the problem) in some use-cases.

--
Dean


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 13:47:48 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdrmN-0005dH-Pc; Tue, 17 Apr 2007 13:47:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdrmM-0005d7-0N
	for sip@ietf.org; Tue, 17 Apr 2007 13:47:46 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdrmK-0005TW-Nz
	for sip@ietf.org; Tue, 17 Apr 2007 13:47:45 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3HHlak11364; Tue, 17 Apr 2007 17:47:36 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
Date: Tue, 17 Apr 2007 12:47:34 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF10128EDF@zrc2hxm0.corp.nortel.com>
In-Reply-To: <0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being delivered to a UA
thread-index: AceBGCw6T6+xkCKCR5ajS549TS2w3wAACalw
References: <4616851D.5070305@softarmor.com>
	<20070406174901.D89C45C027@laser.networkresonance.com>
	<46172B40.8090107@softarmor.com>
	<20070407151244.87A941CC3D@delta.rtfm.com>
	<4617E6B8.5070601@softarmor.com>
	<20070407192220.253931CC3D@delta.rtfm.com>
	<46194A1A.1020705@softarmor.com>
	<20070408202105.0F2725C027@laser.networkresonance.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>
	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
	<461F00B3.1090206@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
	<46245D01.3070301@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
	<4624D827.6070707@cisco.com>
	<0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>
From: "Francois Audet" <audet@nortel.com>
To: "Dean Willis" <dean.willis@softarmor.com>,
	"Paul Kyzivat" <pkyzivat@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

=20
> My intent with some of my suggestions is to reduce the probability =20
> that it will work, thereby reducing the inclination to try it.
>=20
> I think it may also be important to address mechanisms for making it =20
> obvious to the sender (as it already is to the home proxy, should =20
> there be one that is used with outbound) that it will not work. =20
> Separate registrations is one possible way to do this.

No, segregated registration will not work. It just would result in=20
forking.


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 13:57:01 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdrvG-0000lr-S0; Tue, 17 Apr 2007 13:56:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdrvF-0000l0-8b
	for sip@ietf.org; Tue, 17 Apr 2007 13:56:57 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdru4-0001Us-8N
	for sip@ietf.org; Tue, 17 Apr 2007 13:55:45 -0400
Received: from [206.176.144.212] (rcdn4-dmznat-gw1-nat-27.cisco.com
	[12.5.186.27]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3HH2SAD020289
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO)
	for <sip@ietf.org>; Tue, 17 Apr 2007 12:02:29 -0500
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: <04B23A24-CFFD-44AF-87EB-4B9576316154@softarmor.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: IETF SIP List <sip@ietf.org>
From: Dean Willis <dean.willis@softarmor.com>
Date: Tue, 17 Apr 2007 12:55:41 -0500
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Subject: [Sip] Use case: Location server with SIPS and SIP
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


The "sips" thread is getting too darned long to follow.

I'll try and clearly state my issue, because I think it's gotten  
muddled up.


Let's assume a very simple model with two users, Alice and Bob, and a  
registrar/location server to which Bob registers.

Bob registers a SIPS contact with the LS.

Alice sends an authenticated INVITE to the LS. The R-URI of this  
INVITE is Bob's AOR expressed as a SIP AOR.

The LS returns a 302 with a SIPS contact for Bob.

Alice's UA doesn't understand SIPS, so it sends a SIP INVITE to Bob's  
Contact.

Whether or not Bob's UA rejects the INVITE, information potentially  
sensitive to Bob has been disclosed outside of the authorization model.


Does the preceding violate the current specification? If so, in what  
way?

Consider also that the LS could be replaced by an LDAP database, or  
by the REGISTER-as-lookup mechanism of dSIP, or any number of other  
analogous location-query protocols.


--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 14:03:09 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hds1D-00030b-Ti; Tue, 17 Apr 2007 14:03:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hds1B-00030A-TY
	for sip@ietf.org; Tue, 17 Apr 2007 14:03:05 -0400
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hds18-0004Hu-SK
	for sip@ietf.org; Tue, 17 Apr 2007 14:03:05 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	l3HI2Jp00782; Tue, 17 Apr 2007 18:02:19 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
Date: Tue, 17 Apr 2007 13:02:42 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF10128F3F@zrc2hxm0.corp.nortel.com>
In-Reply-To: <9EB1CFBD-DE7A-4AC7-B642-D7F0C63301B2@softarmor.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being delivered to a UA
thread-index: AceBGFxNfsXyYKsPS1aCp2IRV1LTFgAAeY8A
References: <4616851D.5070305@softarmor.com>
	<20070406174901.D89C45C027@laser.networkresonance.com>
	<46172B40.8090107@softarmor.com>
	<20070407151244.87A941CC3D@delta.rtfm.com>
	<4617E6B8.5070601@softarmor.com>
	<20070407192220.253931CC3D@delta.rtfm.com>
	<46194A1A.1020705@softarmor.com>
	<20070408202105.0F2725C027@laser.networkresonance.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>
	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
	<461F00B3.1090206@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
	<46245D01.3070301@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
	<4624D827.6070707@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF100DE968@zrc2hxm0.corp.nortel.com>
	<9EB1CFBD-DE7A-4AC7-B642-D7F0C63301B2! @softarmo r.com>
From: "Francois Audet" <audet@nortel.com>
To: "Dean Willis" <dean.willis@softarmor.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: sip@ietf.org, Paul Kyzivat <pkyzivat@cisco.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I am even more lost now.

If the user is given a SIPS URI, he should not assume that a SIP URI
will
also work. We all agree on that.

If you want to be reachable in by both sip and sips put both on your
business
card. If you only want sips, put sips. If you only want sip, put sip
only.

We've discussed ad nauseam how this can be rendered "on the wire".=20

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]=20
> Sent: Tuesday, April 17, 2007 10:47
> To: Audet, Francois (SC100:3055)
> Cc: Paul Kyzivat; sip@ietf.org
> Subject: Re: [Sip] SIPS question: How to prevent plaintext=20
> requests from being delivered to a UA
>=20
>=20
> On Apr 17, 2007, at 9:38 AM, Francois Audet wrote:
>=20
> > Yes, and the UAS or it's proxy can reject the request.
> >
> > That is covered.
>=20
> But what is NOT covered is a way to advise the sender that it=20
> is NOT likely to work. This would keep them from sending the=20
> request (and thereby creating the problem) in some use-cases.
>=20
> --
> Dean
>=20
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 14:11:53 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hds9g-0006ow-QV; Tue, 17 Apr 2007 14:11:52 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hds9f-0006or-K5
	for sip@ietf.org; Tue, 17 Apr 2007 14:11:51 -0400
Received: from usaga01-in.huawei.com ([206.16.17.211])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hds9e-0006P4-As
	for sip@ietf.org; Tue, 17 Apr 2007 14:11:51 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0JGN00LOOMJLBU@usaga01-in.huawei.com> for
	sip@ietf.org; Tue, 17 Apr 2007 11:11:49 -0700 (PDT)
Received: from s73602 (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0JGN00EEAMJK20@usaga01-in.huawei.com> for sip@ietf.org;
	Tue, 17 Apr 2007 11:11:45 -0700 (PDT)
Date: Tue, 17 Apr 2007 13:10:28 -0500
From: Spencer Dawkins <spencer@mcsr-labs.org>
Subject: Re: [Sip] Use case: Location server with SIPS and SIP
To: IETF SIP List <sip@ietf.org>
Message-id: <0e8a01c7811b$af194f00$ad600240@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
Content-type: text/plain; format=flowed; charset=iso-8859-1;
	reply-type=response
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <04B23A24-CFFD-44AF-87EB-4B9576316154@softarmor.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi, Dean,

I am also somewhat confused at this point.

Just for my background, are you assuming that a registrar is always present 
in your use case?

Thanks,

Spencer

> The "sips" thread is getting too darned long to follow.
>
> I'll try and clearly state my issue, because I think it's gotten  muddled 
> up.
>
>
> Let's assume a very simple model with two users, Alice and Bob, and a 
> registrar/location server to which Bob registers.
>
> Bob registers a SIPS contact with the LS.
>
> Alice sends an authenticated INVITE to the LS. The R-URI of this  INVITE 
> is Bob's AOR expressed as a SIP AOR.
>
> The LS returns a 302 with a SIPS contact for Bob.
>
> Alice's UA doesn't understand SIPS, so it sends a SIP INVITE to Bob's 
> Contact.
>
> Whether or not Bob's UA rejects the INVITE, information potentially 
> sensitive to Bob has been disclosed outside of the authorization model.
>
>
> Does the preceding violate the current specification? If so, in what  way?
>
> Consider also that the LS could be replaced by an LDAP database, or  by 
> the REGISTER-as-lookup mechanism of dSIP, or any number of other 
> analogous location-query protocols. 



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 14:22:27 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdsJt-00066E-UY; Tue, 17 Apr 2007 14:22:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdsJs-000662-Gl
	for sip@ietf.org; Tue, 17 Apr 2007 14:22:24 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdsJs-0003H3-8x
	for sip@ietf.org; Tue, 17 Apr 2007 14:22:24 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3HIMLk27572; Tue, 17 Apr 2007 18:22:21 GMT
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: [Sip] Use case: Location server with SIPS and SIP
Date: Tue, 17 Apr 2007 13:22:18 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF10128FB3@zrc2hxm0.corp.nortel.com>
In-Reply-To: <04B23A24-CFFD-44AF-87EB-4B9576316154@softarmor.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Use case: Location server with SIPS and SIP
thread-index: AceBGdEJLxQl4MncQu+KcKqOSR/2FwAAoDXQ
References: <04B23A24-CFFD-44AF-87EB-4B9576316154@softarmor.com>
From: "Francois Audet" <audet@nortel.com>
To: "Dean Willis" <dean.willis@softarmor.com>, "IETF SIP List" <sip@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

See below.=20

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]=20
> Sent: Tuesday, April 17, 2007 10:56
> To: IETF SIP List
> Subject: [Sip] Use case: Location server with SIPS and SIP
>=20
>=20
> The "sips" thread is getting too darned long to follow.
>=20
> I'll try and clearly state my issue, because I think it's=20
> gotten muddled up.
>=20
>=20
> Let's assume a very simple model with two users, Alice and=20
> Bob, and a registrar/location server to which Bob registers.
>=20
> Bob registers a SIPS contact with the LS.
>=20
> Alice sends an authenticated INVITE to the LS. The R-URI of=20
> this INVITE is Bob's AOR expressed as a SIP AOR.
>=20
> The LS returns a 302 with a SIPS contact for Bob.
>=20
> Alice's UA doesn't understand SIPS, so it sends a SIP INVITE=20
> to Bob's Contact.
>=20
> Whether or not Bob's UA rejects the INVITE, information=20
> potentially sensitive to Bob has been disclosed outside of=20
> the authorization model.
>=20
>=20
> Does the preceding violate the current specification? If so,=20
> in what way?

There is a violation of RFC 3261 in your model.

If Alice receives a 3XX with a SIPS contact, it shouldn't=20
"try SIP". That is a violation of 3261.=20

That being said, as we know, not all UACs are perfect. If
it blindly ignores the scheme, it is possible that it will=20
send a new INVITE with the wrong scheme. This is functionaly the
same scenario is the dumb user who sees a SIPS scheme, ignores it
and use sip instead.

There is nothing that can be done to stop the "damage" being done
until we reach either Bob's proxy or Bob's UA.

Bob proxy may have a rule to reject anything not SIPS. Or Bob's UAS's
may reject otherwise.



> Consider also that the LS could be replaced by an LDAP=20
> database, or by the REGISTER-as-lookup mechanism of dSIP, or=20
> any number of other analogous location-query protocols.

I don't think it would change anything to the description above.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 14:24:10 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdsLa-0006aN-Bt; Tue, 17 Apr 2007 14:24:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdsLY-0006ZT-2Z
	for sip@ietf.org; Tue, 17 Apr 2007 14:24:08 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdsLW-0003xS-NE
	for sip@ietf.org; Tue, 17 Apr 2007 14:24:08 -0400
Received: from sj-dkim-8.cisco.com ([171.68.10.93])
	by sj-iport-5.cisco.com with ESMTP; 17 Apr 2007 11:23:55 -0700
X-IronPort-AV: i="4.14,419,1170662400"; 
	d="scan'208"; a="412398560:sNHT4316878972"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
	by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l3HINstA010342; 
	Tue, 17 Apr 2007 11:23:54 -0700
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l3HINmx3017683;
	Tue, 17 Apr 2007 18:23:54 GMT
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.1830); 
	Tue, 17 Apr 2007 14:23:53 -0400
Received: from [161.44.174.118] ([161.44.174.118]) by
	xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 17 Apr 2007 14:23:53 -0400
Message-ID: <462510B5.5090408@cisco.com>
Date: Tue, 17 Apr 2007 14:23:49 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] Use case: Location server with SIPS and SIP
References: <04B23A24-CFFD-44AF-87EB-4B9576316154@softarmor.com>
In-Reply-To: <04B23A24-CFFD-44AF-87EB-4B9576316154@softarmor.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 Apr 2007 18:23:53.0336 (UTC)
	FILETIME=[8D9E8780:01C7811D]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1886; t=1176834234;
	x=1177698234; c=relaxed/simple; s=sjdkim8002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20Use=20case=3A=20Location=20server=20with=20SI
	PS=20and=20SIP |Sender:=20;
	bh=OdGhknOURI0P6mONi3HAtdCRiZPJ0tJYRt2vXa5vMRc=;
	b=Qiy47aUqRGdz8xFl7VuTvMbBEvmkjC+tiX2Xnz+OGlP8ZMKvHc9uX2iQiVmplJ5QSJN6aS2I
	e0HMLLBJ0WIK1Pt73mPRAZD9B/5oRod8JIfEGUadJjYfB4JLUVvLefL/;
Authentication-Results: sj-dkim-8; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim8002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org



Dean Willis wrote:
> 
> The "sips" thread is getting too darned long to follow.
> 
> I'll try and clearly state my issue, because I think it's gotten muddled 
> up.
> 
> 
> Let's assume a very simple model with two users, Alice and Bob, and a 
> registrar/location server to which Bob registers.
> 
> Bob registers a SIPS contact with the LS.
> 
> Alice sends an authenticated INVITE to the LS. The R-URI of this INVITE 
> is Bob's AOR expressed as a SIP AOR.

And it likely is sent over an unsecured path.

> The LS returns a 302 with a SIPS contact for Bob.

Which also travels over the unsecured path. Its potentially been 
compromised regardless of whether Alice downgrades and calls it or not.

Yet this is a *feature* in the case that Alice supports sips. So I think 
it must be a *policy* of the LS whether or not to return the contacts in 
a 3xx.

(In this case an alternative to returning a 302 with Bob's contact is 
for the LS to return a 302 with the sips form of the AOR.)

	Paul

> Alice's UA doesn't understand SIPS, so it sends a SIP INVITE to Bob's 
> Contact.
> 
> Whether or not Bob's UA rejects the INVITE, information potentially 
> sensitive to Bob has been disclosed outside of the authorization model.
> 
> 
> Does the preceding violate the current specification? If so, in what way?
> 
> Consider also that the LS could be replaced by an LDAP database, or by 
> the REGISTER-as-lookup mechanism of dSIP, or any number of other 
> analogous location-query protocols.
> 
> 
> -- 
> Dean
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 14:26:33 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdsNt-0007PY-1S; Tue, 17 Apr 2007 14:26:33 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdsNr-0007P8-8a
	for sip@ietf.org; Tue, 17 Apr 2007 14:26:31 -0400
Received: from zrtps0kp.nortel.com ([47.140.192.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdsNq-00051c-Fv
	for sip@ietf.org; Tue, 17 Apr 2007 14:26:31 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3HIQRO14625; Tue, 17 Apr 2007 18:26:27 GMT
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: [Sip] Use case: Location server with SIPS and SIP
Date: Tue, 17 Apr 2007 13:26:26 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF10128FC6@zrc2hxm0.corp.nortel.com>
In-Reply-To: <462510B5.5090408@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Use case: Location server with SIPS and SIP
thread-index: AceBHZyHZ3Ecd713S7K/QeKL4v9GmQAAByBw
References: <04B23A24-CFFD-44AF-87EB-4B9576316154@softarmor.com>
	<462510B5.5090408@cisco.com>
From: "Francois Audet" <audet@nortel.com>
To: "Paul Kyzivat" <pkyzivat@cisco.com>,
	"Dean Willis" <dean.willis@softarmor.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Yes, Paul has a good point (I was talking about policies on the
terminating
side).

If Alice's proxy has a policy of not delivering Contacts with SIPS to
endpoints
it knows don't support SIPS (or doesn't allow it ever), it can send a
404.

That is also described in the current draft.=20

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20
> Sent: Tuesday, April 17, 2007 11:24
> To: Dean Willis
> Cc: IETF SIP List
> Subject: Re: [Sip] Use case: Location server with SIPS and SIP
>=20
>=20
>=20
> Dean Willis wrote:
> >=20
> > The "sips" thread is getting too darned long to follow.
> >=20
> > I'll try and clearly state my issue, because I think it's gotten=20
> > muddled up.
> >=20
> >=20
> > Let's assume a very simple model with two users, Alice and=20
> Bob, and a=20
> > registrar/location server to which Bob registers.
> >=20
> > Bob registers a SIPS contact with the LS.
> >=20
> > Alice sends an authenticated INVITE to the LS. The R-URI of this=20
> > INVITE is Bob's AOR expressed as a SIP AOR.
>=20
> And it likely is sent over an unsecured path.
>=20
> > The LS returns a 302 with a SIPS contact for Bob.
>=20
> Which also travels over the unsecured path. Its potentially=20
> been compromised regardless of whether Alice downgrades and=20
> calls it or not.
>=20
> Yet this is a *feature* in the case that Alice supports sips.=20
> So I think it must be a *policy* of the LS whether or not to=20
> return the contacts in a 3xx.
>=20
> (In this case an alternative to returning a 302 with Bob's=20
> contact is for the LS to return a 302 with the sips form of the AOR.)
>=20
> 	Paul
>=20
> > Alice's UA doesn't understand SIPS, so it sends a SIP=20
> INVITE to Bob's=20
> > Contact.
> >=20
> > Whether or not Bob's UA rejects the INVITE, information potentially=20
> > sensitive to Bob has been disclosed outside of the=20
> authorization model.
> >=20
> >=20
> > Does the preceding violate the current specification? If=20
> so, in what way?
> >=20
> > Consider also that the LS could be replaced by an LDAP=20
> database, or by=20
> > the REGISTER-as-lookup mechanism of dSIP, or any number of other=20
> > analogous location-query protocols.
> >=20
> >=20
> > --
> > Dean
> >=20
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use=20
> > sip-implementors@cs.columbia.edu for questions on current sip Use=20
> > sipping@ietf.org for new developments on the application of sip
> >=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 14:27:27 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdsOl-0000N7-BP; Tue, 17 Apr 2007 14:27:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdsOj-0000Mv-EM
	for sip@ietf.org; Tue, 17 Apr 2007 14:27:25 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdsOi-0005UI-RS
	for sip@ietf.org; Tue, 17 Apr 2007 14:27:25 -0400
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 17 Apr 2007 14:27:25 -0400
X-IronPort-AV: i="4.14,419,1170651600"; 
	d="scan'208"; a="57883317:sNHT49741844"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3HIROxO024526; 
	Tue, 17 Apr 2007 14:27:24 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3HIR6lS003147; 
	Tue, 17 Apr 2007 18:27:19 GMT
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.1830); 
	Tue, 17 Apr 2007 14:27:13 -0400
Received: from [161.44.174.118] ([161.44.174.118]) by
	xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 17 Apr 2007 14:27:12 -0400
Message-ID: <4625117C.2060000@cisco.com>
Date: Tue, 17 Apr 2007 14:27:08 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
References: <4616851D.5070305@softarmor.com>
	<20070406174901.D89C45C027@laser.networkresonance.com>
	<46172B40.8090107@softarmor.com>
	<20070407151244.87A941CC3D@delta.rtfm.com>
	<4617E6B8.5070601@softarmor.com>
	<20070407192220.253931CC3D@delta.rtfm.com>
	<46194A1A.1020705@softarmor.com>
	<20070408202105.0F2725C027@laser.networkresonance.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>
	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
	<461F00B3.1090206@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
	<46245D01.3070301@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
	<4624D827.6070707@cisco.com>
	<0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>
In-Reply-To: <0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 Apr 2007 18:27:12.0913 (UTC)
	FILETIME=[04939010:01C7811E]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2028; t=1176834444;
	x=1177698444; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20SIPS=20question=3A=20How=20to=20prevent=20pla
	intext=20requests=20from=20being=0A=20delivered=20to=20a=20UA
	|Sender:=20 |To:=20Dean=20Willis=20<dean.willis@softarmor.com>;
	bh=KmwcEuDyo+rEtNdXVDrGh2h1C30EBdayc0WaSo25WZg=;
	b=k/CbGkSU9OLva8j48z9RXsba8Pez2uRUuWZn98QN/SVhfT+DkZZFRbpD3eNDelsdMDGryB6X
	EqU0afs8UjdayubO2ccXYga6fe1vovBOnjKcmxPfsMk9PDev/p7Exwm7;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org



Dean Willis wrote:
> 
> On Apr 17, 2007, at 9:22 AM, Paul Kyzivat wrote:
> 
>>
>>
>> Francois Audet wrote:
>>
>>>> Yes, that's exactly my point. If you're given a SIPS URI, use it. 
>>>> Don't downgrade to SIP. Ever. Not at a proxy, not at a UA, not at a 
>>>> user.
>>> I think everybody agrees on this. So we are in agreement.
>>
>> Well...
>>
>> IMO its pointless to base any decisions on the assumption that 
>> everyone will conform to the above.
>>
>> It sounds good until a user with a UA that doesn't support sips wants 
>> to call somebody that he only has a sips URI for. At that point his 
>> choices are:
>> - give up
>> - try the downgraded URI
>>
>> If there is *any* chance that downgrading will work then a lot of 
>> users will try it. And even if there is *no* chance of it working some 
>> number of users will try it. And its quite likely that often the 
>> downgrading will be done by *mistake*, by somebody that does 
>> understand there is a difference between sip and sips.
>>
>> And it probably *will* work in a lot of cases, because a lot of people 
>> will want to support both.
>>
>> So, you can say that users SHOULD NOT do it, or MUST NOT do it, but 
>> assume that it will be done anyway.
>>
> 
> right.
> 
> My intent with some of my suggestions is to reduce the probability that 
> it will work, thereby reducing the inclination to try it.

I think it would be mildly interesting (low priority) to devise some way 
  of indicating that an address is to be treated as confidential. It 
would require a bunch of rules about who it may and may not be disclosed 
to, etc.

But I don't think the sips scheme is the right way to accomplish that.

	Paul

> I think it may also be important to address mechanisms for making it 
> obvious to the sender (as it already is to the home proxy, should there 
> be one that is used with outbound) that it will not work. Separate 
> registrations is one possible way to do this.
> 
> -- 
> Dean
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 14:30:05 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdsRH-0001sV-0x; Tue, 17 Apr 2007 14:30:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdsRF-0001sH-VY
	for sip@ietf.org; Tue, 17 Apr 2007 14:30:01 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdsRE-0006az-Mw
	for sip@ietf.org; Tue, 17 Apr 2007 14:30:01 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3HITuk28713; Tue, 17 Apr 2007 18:29:57 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
Date: Tue, 17 Apr 2007 13:29:55 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF10128FD8@zrc2hxm0.corp.nortel.com>
In-Reply-To: <4625117C.2060000@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being delivered to a UA
thread-index: AceBHhH1lravLxm3SOSf/0m6U7bMWAAAB4OQ
References: <4616851D.5070305@softarmor.com>
	<20070406174901.D89C45C027@laser.networkresonance.com>
	<46172B40.8090107@softarmor.com>
	<20070407151244.87A941CC3D@delta.rtfm.com>
	<4617E6B8.5070601@softarmor.com>
	<20070407192220.253931CC3D@delta.rtfm.com>
	<46194A1A.1020705@softarmor.com>
	<20070408202105.0F2725C027@laser.networkresonance.com>
	<1ECE0EB50388174790F9694F77522CCF0FEFDB4E@zrc2hxm0.corp.nortel.com>
	<66cd252f0704122011l4ef91103v77218006a8a0e345@mail.gmail.com>
	<461F00B3.1090206@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
	<46245D01.3070301@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
	<4624D827.6070707@cisco.com>
	<0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>
	<4625117C.2060000@cisco.com>
From: "Francois Audet" <audet@nortel.com>
To: "Paul Kyzivat" <pkyzivat@cisco.com>,
	"Dean Willis" <dean.willis@softarmor.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

=20
> > My intent with some of my suggestions is to reduce the probability=20
> > that it will work, thereby reducing the inclination to try it.
>=20
> I think it would be mildly interesting (low priority) to=20
> devise some way
>   of indicating that an address is to be treated as=20
> confidential. It would require a bunch of rules about who it=20
> may and may not be disclosed to, etc.
>=20
> But I don't think the sips scheme is the right way to accomplish that.

Agreed.


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 14:59:36 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hdstn-00021n-BQ; Tue, 17 Apr 2007 14:59:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdstl-00021X-GQ
	for sip@ietf.org; Tue, 17 Apr 2007 14:59:29 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdstk-0004ja-8S
	for sip@ietf.org; Tue, 17 Apr 2007 14:59:29 -0400
Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com)
	([172.19.96.182])
	by sj-iport-6.cisco.com with ESMTP; 17 Apr 2007 11:59:26 -0700
X-IronPort-AV: i="4.14,419,1170662400"; 
	d="scan'208"; a="136928017:sNHT41927337"
Received: from [64.142.29.213] ([10.82.217.64])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l3HIaGEd015187;
	Tue, 17 Apr 2007 11:36:16 -0700
Message-ID: <462519B5.7000106@cisco.com>
Date: Tue, 17 Apr 2007 12:02:13 -0700
From: Michael Thomas <mat@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
	rv:1.8.0.10) Gecko/20070221 Thunderbird/1.5.0.10 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] Use case: Location server with SIPS and SIP
References: <04B23A24-CFFD-44AF-87EB-4B9576316154@softarmor.com>
In-Reply-To: <04B23A24-CFFD-44AF-87EB-4B9576316154@softarmor.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=920; t=1176834977;
	x=1177698977; c=relaxed/simple; s=oregon;
	h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; 
	d=cisco.com; i=mat@cisco.com;
	z=From:=20Michael=20Thomas=20<mat@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20Use=20case=3A=20Location=20server=20with=20SI
	PS=20and=20SIP |Sender:=20
	|To:=20Dean=20Willis=20<dean.willis@softarmor.com>;
	bh=L4HtX7EHNy35GnMydCXKcatYbpzCKUHtQVSeirop1nM=;
	b=am9/OLKTdSLq74f+/qJUqLhcC5RPbALwsBIYl6nUp6LwexJS6JB/j6nSNe2USYqvLkYHGzFl
	B5cbKF7U4QbEmTWNEiCwi8US9UHIJewtLOD/PCu+L9Z4/kcySAesVoA3;
Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass (
	sig from cisco.com/oregon verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Dean Willis wrote:
>
> The "sips" thread is getting too darned long to follow.
>
> I'll try and clearly state my issue, because I think it's gotten 
> muddled up.
>
>
> Let's assume a very simple model with two users, Alice and Bob, and a 
> registrar/location server to which Bob registers.
>
> Bob registers a SIPS contact with the LS.
>
> Alice sends an authenticated INVITE to the LS. The R-URI of this 
> INVITE is Bob's AOR expressed as a SIP AOR.
>
> The LS returns a 302 with a SIPS contact for Bob.
>
> Alice's UA doesn't understand SIPS, so it sends a SIP INVITE to Bob's 
> Contact.
Wait a minute: is this to imply that there would be nothing wrong with
Alice changing a SIP-PRETZELOGIC URI into a SIP URI either? I'm pretty
sure that's where this goes off the rails; Alice is doing something pretty
bone headed trying to educe a relationship between the two schemes.


       Mike

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 15:03:28 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hdsxc-00047z-7T; Tue, 17 Apr 2007 15:03:28 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdsxa-00047k-QC
	for sip@ietf.org; Tue, 17 Apr 2007 15:03:26 -0400
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdsxY-00069K-FJ
	for sip@ietf.org; Tue, 17 Apr 2007 15:03:26 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	l3HJ2dp12819; Tue, 17 Apr 2007 19:02:39 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Tue, 17 Apr 2007 14:02:30 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E6124F3106@zrc2hxm2.corp.nortel.com>
In-Reply-To: <C1CD7F21-9DBE-40D7-893D-E69E0F02F56C@softarmor.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
thread-index: AceBF4yqLawEJYtISEyTO9wy+tj29AACwFxA
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Dean Willis" <dean.willis@softarmor.com>,
	"Paul Kyzivat" <pkyzivat@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Why we need for this SIPS URI scheme at all. Extend the=20
http://www.ietf.org/rfc/rfc3840.txt  UA Capibility framework for this.=20

Thx
Samir

>-----Original Message-----
>From: Dean Willis [mailto:dean.willis@softarmor.com]=20
>Sent: Tuesday, April 17, 2007 10:41 AM
>To: Paul Kyzivat
>Cc: sip@ietf.org
>Subject: Re: [Sip] SIPS question: How to prevent plaintext=20
>requests from being delivered to a UA
>
>
>On Apr 17, 2007, at 7:55 AM, Paul Kyzivat wrote:
>
>> Dean,
>>
>> I think you are trying to associate two distinct semantics with sips=20
>> URI:
>> - that sessions established using this URI should be secured
>>   hop by hop from end to end
>> - that such a URI should be considered "unlisted" and so kept
>>   "secret".
>>
>> IMO these semantics should not be conflated because:
>>
>> - I may want to have a sip (or tel or IM or PRES) URI
>>   that is "unlisted", and I may want to have a sips URI
>>   that is "listed".
>>
>> - The semantics of of being "unlisted" are likely to be
>>   just as hard to pin down as the semantics of sips for
>>   e22 security is. IMO we don't want to hold up the clarification
>>   of sips until that can be done.
>
>What I'm trying to say is that if you were given a SIPS URI,=20
>you should use SIPS instead of SIP for that callee, because if=20
>you downgrade to SIP there could be negative consequences. One=20
>such negative consequence might be the disclosure of a=20
>name-to-address binding that the callee did not desire to have=20
>disclosed. Since we currently have no way to express that=20
>desire, the safest thing to do is to protect it where feasible.
>
>In other words, "be conservative in what we send".
>
>--
>Dean
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol Use=20
>sip-implementors@cs.columbia.edu for questions on current sip=20
>Use sipping@ietf.org for new developments on the application of sip
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 15:13:29 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hdt7H-0007Un-03; Tue, 17 Apr 2007 15:13:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdt7F-0007Uf-Up
	for sip@ietf.org; Tue, 17 Apr 2007 15:13:25 -0400
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdt7F-0000m1-IT
	for sip@ietf.org; Tue, 17 Apr 2007 15:13:25 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	l3HJCkp13682; Tue, 17 Apr 2007 19:12:47 GMT
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: Poll: Do we have sips/sip retageting in the wild (was Re:
	[Sip]	RE:Securing Other URI (Tel URI) scheme)
Date: Tue, 17 Apr 2007 14:13:20 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E6124F313C@zrc2hxm2.corp.nortel.com>
In-Reply-To: <49DFEF82990374449378AD1198F39F8B03209A54@xmb-sjc-231.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Poll: Do we have sips/sip retageting in the wild (was Re:
	[Sip]	RE:Securing Other URI (Tel URI) scheme)
thread-index: AcdyNztJs5tzUmcOTZW5HpAPrTyzdAOOEFEQAC0mmhA=
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Charles Eckel \(eckelcu\)" <eckelcu@cisco.com>,
	"Dean Willis" <dean.willis@softarmor.com>, "IETF SIP List" <sip@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi Charles,

   If it is not confidential, could you please share with the group
whether users of CSPS USED the SIPS. As it was implemented in 2003 and
if it is being used heavily, then we MUST be seeing atleast couple of
the issues coming from SIPS much earlier.

Thx
Samir=20

>-----Original Message-----
>From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]=20
>Sent: Monday, April 16, 2007 2:45 PM
>To: Dean Willis; IETF SIP List
>Subject: RE: Poll: Do we have sips/sip retageting in the wild=20
>(was Re: [Sip] RE:Securing Other URI (Tel URI) scheme)
>
>Sorry for the late response, but the Cisco SIP Proxy Server=20
>(CSPS) allowed for retargeting from sips to sip. Whether or=20
>not to allow this is configurable, and it is disabled by default.
>I do not recall what we did in terms of sip to sips, but I=20
>think we allowed it as well. This was done in 2003 and not=20
>changed since as far as I know.=20
>
>Cheers,
>Charles=20
>
>> -----Original Message-----
>> From: Dean Willis [mailto:dean.willis@softarmor.com]
>> Sent: Thursday, March 29, 2007 12:12 PM
>> To: IETF SIP List
>> Subject: Poll: Do we have sips/sip retageting in the wild (was Re:=20
>> [Sip] RE:Securing Other URI (Tel URI) scheme)
>>=20
>>=20
>> On Mar 29, 2007, at 12:01 PM, Francois Audet wrote:
>>=20
>> > I don't agree.
>> >
>> > I think this is theoretical. I don't believe proxies that "upgrade"
>> > from SIP to SIPS using a retargeting exist in nature. And
>> if they did,
>> > they
>> > would likely break stuff, or have some assumptions that makes them=20
>> > essentially proprietary. It just doesn't work except for some very=20
>> > narrow sceanrios (e.g., transactions that don't create a=20
>dialog, or=20
>> > dialogs with double Record-Route used at the retargeting point,=20
>> > along with endpoints that don't understand SIPS but somehow don't=20
>> > choke on the
>> scheme, use of
>> > SIP
>> > outbound
>> > which is not standard yet, etc.). Same applies for downgrades.
>> >
>> > So to me, it's a non-issue.
>> >
>> > From a standard's purist dreamland point of view, we could define=20
>> > this extension: it would not "break" anything. It would just make=20
>> > the spec more complicated for no good reason.
>>=20
>> I used to have a proxy at the house that would retarget inbound from=20
>> sips to sip to let my old 3Com phone work. It would also=20
>retarget sip=20
>> to sips outbound so I could call sips (said proxy is why I=20
>insisted on=20
>> last-hop exception in 3261). Such proxies do exist.
>>=20
>> The good news is, I don't use it anymore (the bad news is I=20
>don't have=20
>> a working SIP phone at home right now).
>>=20
>> So (Chair Hat on): Anybody else out there have a proxy currently (or=20
>> planned to be) in use that retargets sip to sips or vice versa?
>>=20
>> If we can't come up with any, I suppose I'd be willing to=20
>concede the=20
>> issue as "fixing an improbable problem"
>>=20
>> --
>> Dean
>>=20
>>=20
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol Use=20
>> sip-implementors@cs.columbia.edu for questions on current sip Use=20
>> sipping@ietf.org for new developments on the application of sip
>>=20
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol Use=20
>sip-implementors@cs.columbia.edu for questions on current sip=20
>Use sipping@ietf.org for new developments on the application of sip
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 15:29:49 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdtN5-0000dA-18; Tue, 17 Apr 2007 15:29:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdtN3-0000d2-DL
	for sip@ietf.org; Tue, 17 Apr 2007 15:29:45 -0400
Received: from zrtps0kp.nortel.com ([47.140.192.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdtN1-0004pF-02
	for sip@ietf.org; Tue, 17 Apr 2007 15:29:45 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3HJSTO12232; Tue, 17 Apr 2007 19:28:30 GMT
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: Poll: Do we have sips/sip retageting in the wild (was Re:
	[Sip]	RE:Securing Other URI (Tel URI) scheme)
Date: Tue, 17 Apr 2007 14:28:05 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF1012914B@zrc2hxm0.corp.nortel.com>
In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E6124F313C@zrc2hxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Poll: Do we have sips/sip retageting in the wild (was Re:
	[Sip]	RE:Securing Other URI (Tel URI) scheme)
thread-index: AcdyNztJs5tzUmcOTZW5HpAPrTyzdAOOEFEQAC0mmhAAAJa6sA==
References: <49DFEF82990374449378AD1198F39F8B03209A54@xmb-sjc-231.amer.cisco.com>
	<62B9B0847CC47543B6B3B5E26BD268E6124F313C@zrc2hxm2.corp.nortel.com>
From: "Francois Audet" <audet@nortel.com>
To: "Samir Srivastava" <samirsr@nortel.com>,
	"Charles Eckel \(eckelcu\)" <eckelcu@cisco.com>,
	"Dean Willis" <dean.willis@softarmor.com>, "IETF SIP List" <sip@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b22590c27682ace61775ee7b453b40d3
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

That would be the rationale for supporting the option tag.

(i.e., for open issue number 2).

Thanks.=20

> -----Original Message-----
> From: Srivastava, Samir (SC100:8826)=20
> Sent: Tuesday, April 17, 2007 12:13
> To: Charles Eckel (eckelcu); Dean Willis; IETF SIP List
> Subject: RE: Poll: Do we have sips/sip retageting in the wild=20
> (was Re: [Sip] RE:Securing Other URI (Tel URI) scheme)
>=20
> Hi Charles,
>=20
>    If it is not confidential, could you please share with the=20
> group whether users of CSPS USED the SIPS. As it was=20
> implemented in 2003 and if it is being used heavily, then we=20
> MUST be seeing atleast couple of the issues coming from SIPS=20
> much earlier.
>=20
> Thx
> Samir=20
>=20
> >-----Original Message-----
> >From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]
> >Sent: Monday, April 16, 2007 2:45 PM
> >To: Dean Willis; IETF SIP List
> >Subject: RE: Poll: Do we have sips/sip retageting in the=20
> wild (was Re:=20
> >[Sip] RE:Securing Other URI (Tel URI) scheme)
> >
> >Sorry for the late response, but the Cisco SIP Proxy Server
> >(CSPS) allowed for retargeting from sips to sip. Whether or not to=20
> >allow this is configurable, and it is disabled by default.
> >I do not recall what we did in terms of sip to sips, but I think we=20
> >allowed it as well. This was done in 2003 and not changed=20
> since as far=20
> >as I know.
> >
> >Cheers,
> >Charles
> >
> >> -----Original Message-----
> >> From: Dean Willis [mailto:dean.willis@softarmor.com]
> >> Sent: Thursday, March 29, 2007 12:12 PM
> >> To: IETF SIP List
> >> Subject: Poll: Do we have sips/sip retageting in the wild (was Re:=20
> >> [Sip] RE:Securing Other URI (Tel URI) scheme)
> >>=20
> >>=20
> >> On Mar 29, 2007, at 12:01 PM, Francois Audet wrote:
> >>=20
> >> > I don't agree.
> >> >
> >> > I think this is theoretical. I don't believe proxies=20
> that "upgrade"
> >> > from SIP to SIPS using a retargeting exist in nature. And
> >> if they did,
> >> > they
> >> > would likely break stuff, or have some assumptions that=20
> makes them=20
> >> > essentially proprietary. It just doesn't work except for=20
> some very=20
> >> > narrow sceanrios (e.g., transactions that don't create a
> >dialog, or
> >> > dialogs with double Record-Route used at the retargeting point,=20
> >> > along with endpoints that don't understand SIPS but=20
> somehow don't=20
> >> > choke on the
> >> scheme, use of
> >> > SIP
> >> > outbound
> >> > which is not standard yet, etc.). Same applies for downgrades.
> >> >
> >> > So to me, it's a non-issue.
> >> >
> >> > From a standard's purist dreamland point of view, we=20
> could define=20
> >> > this extension: it would not "break" anything. It would=20
> just make=20
> >> > the spec more complicated for no good reason.
> >>=20
> >> I used to have a proxy at the house that would retarget=20
> inbound from=20
> >> sips to sip to let my old 3Com phone work. It would also
> >retarget sip
> >> to sips outbound so I could call sips (said proxy is why I
> >insisted on
> >> last-hop exception in 3261). Such proxies do exist.
> >>=20
> >> The good news is, I don't use it anymore (the bad news is I
> >don't have
> >> a working SIP phone at home right now).
> >>=20
> >> So (Chair Hat on): Anybody else out there have a proxy=20
> currently (or=20
> >> planned to be) in use that retargets sip to sips or vice versa?
> >>=20
> >> If we can't come up with any, I suppose I'd be willing to
> >concede the
> >> issue as "fixing an improbable problem"
> >>=20
> >> --
> >> Dean
> >>=20
> >>=20
> >> _______________________________________________
> >> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >> This list is for NEW development of the core SIP Protocol Use=20
> >> sip-implementors@cs.columbia.edu for questions on current sip Use=20
> >> sipping@ietf.org for new developments on the application of sip
> >>=20
> >
> >_______________________________________________
> >Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >This list is for NEW development of the core SIP Protocol Use=20
> >sip-implementors@cs.columbia.edu for questions on current sip Use=20
> >sipping@ietf.org for new developments on the application of sip
> >
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 15:58:58 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdtpG-0004Cq-PS; Tue, 17 Apr 2007 15:58:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdtpE-0004AR-Ol
	for sip@ietf.org; Tue, 17 Apr 2007 15:58:52 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdtpE-0004w0-5N
	for sip@ietf.org; Tue, 17 Apr 2007 15:58:52 -0400
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-6.cisco.com with ESMTP; 17 Apr 2007 12:58:50 -0700
X-IronPort-AV: i="4.14,419,1170662400"; 
	d="scan'208"; a="136958165:sNHT59927589"
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l3HJwpJb006159; 
	Tue, 17 Apr 2007 12:58:51 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l3HJwpEk019194;
	Tue, 17 Apr 2007 19:58:51 GMT
Received: from xmb-sjc-231.amer.cisco.com ([128.107.191.73]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 17 Apr 2007 12:58:50 -0700
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: Poll: Do we have sips/sip retageting in the wild (was Re:
	[Sip]	RE:Securing Other URI (Tel URI) scheme)
Date: Tue, 17 Apr 2007 12:58:49 -0700
Message-ID: <49DFEF82990374449378AD1198F39F8B03209E8F@xmb-sjc-231.amer.cisco.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1012914B@zrc2hxm0.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Poll: Do we have sips/sip retageting in the wild (was Re:
	[Sip]	RE:Securing Other URI (Tel URI) scheme)
Thread-Index: AcdyNztJs5tzUmcOTZW5HpAPrTyzdAOOEFEQAC0mmhAAAJa6sAAA6Nng
From: "Charles Eckel \(eckelcu\)" <eckelcu@cisco.com>
To: "Francois Audet" <audet@nortel.com>,
	"Samir Srivastava" <samirsr@nortel.com>,
	"Dean Willis" <dean.willis@softarmor.com>, "IETF SIP List" <sip@ietf.org>
X-OriginalArrivalTime: 17 Apr 2007 19:58:50.0093 (UTC)
	FILETIME=[D126A9D0:01C7812A]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5454; t=1176839931;
	x=1177703931; c=relaxed/simple; s=sjdkim4002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=eckelcu@cisco.com;
	z=From:=20=22Charles=20Eckel=20\(eckelcu\)=22=20<eckelcu@cisco.com>
	|Subject:=20RE=3A=20Poll=3A=20Do=20we=20have=20sips/sip=20retageting=20in
	=20the=20wild=20(was=20Re=3A=20[Sip]=09RE=3ASecuring=20Other=20URI=20(Tel=
	20URI)=20scheme) |Sender:=20;
	bh=I6+2ovhB/EHEtpuMvUE8dzialFg7SdSnWzDjateYH1M=;
	b=t9cCP+d/R2+GPbUUrjhtMv9NP9e1rSVwtMnmbz/zaoSsvT1emNGh85UvQPMGaVo8UK5f6HZI
	JZB5THJtH9ILKeTiw888thuVrRsc/vWeHv8Eiuhvvi1WU8xfRQISm4FL;
Authentication-Results: sj-dkim-4; header.From=eckelcu@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim4002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I do not think this TLS functionality is being used heavily outside of
SIPits and some very well constrained environments.

Cheers,
Charles

> -----Original Message-----
> From: Francois Audet [mailto:audet@nortel.com]=20
> Sent: Tuesday, April 17, 2007 12:28 PM
> To: Samir Srivastava; Charles Eckel (eckelcu); Dean Willis;=20
> IETF SIP List
> Subject: RE: Poll: Do we have sips/sip retageting in the wild=20
> (was Re: [Sip] RE:Securing Other URI (Tel URI) scheme)
>=20
> That would be the rationale for supporting the option tag.
>=20
> (i.e., for open issue number 2).
>=20
> Thanks.=20
>=20
> > -----Original Message-----
> > From: Srivastava, Samir (SC100:8826)=20
> > Sent: Tuesday, April 17, 2007 12:13
> > To: Charles Eckel (eckelcu); Dean Willis; IETF SIP List
> > Subject: RE: Poll: Do we have sips/sip retageting in the wild=20
> > (was Re: [Sip] RE:Securing Other URI (Tel URI) scheme)
> >=20
> > Hi Charles,
> >=20
> >    If it is not confidential, could you please share with the=20
> > group whether users of CSPS USED the SIPS. As it was=20
> > implemented in 2003 and if it is being used heavily, then we=20
> > MUST be seeing atleast couple of the issues coming from SIPS=20
> > much earlier.
> >=20
> > Thx
> > Samir=20
> >=20
> > >-----Original Message-----
> > >From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]
> > >Sent: Monday, April 16, 2007 2:45 PM
> > >To: Dean Willis; IETF SIP List
> > >Subject: RE: Poll: Do we have sips/sip retageting in the=20
> > wild (was Re:=20
> > >[Sip] RE:Securing Other URI (Tel URI) scheme)
> > >
> > >Sorry for the late response, but the Cisco SIP Proxy Server
> > >(CSPS) allowed for retargeting from sips to sip. Whether or not to=20
> > >allow this is configurable, and it is disabled by default.
> > >I do not recall what we did in terms of sip to sips, but I=20
> think we=20
> > >allowed it as well. This was done in 2003 and not changed=20
> > since as far=20
> > >as I know.
> > >
> > >Cheers,
> > >Charles
> > >
> > >> -----Original Message-----
> > >> From: Dean Willis [mailto:dean.willis@softarmor.com]
> > >> Sent: Thursday, March 29, 2007 12:12 PM
> > >> To: IETF SIP List
> > >> Subject: Poll: Do we have sips/sip retageting in the=20
> wild (was Re:=20
> > >> [Sip] RE:Securing Other URI (Tel URI) scheme)
> > >>=20
> > >>=20
> > >> On Mar 29, 2007, at 12:01 PM, Francois Audet wrote:
> > >>=20
> > >> > I don't agree.
> > >> >
> > >> > I think this is theoretical. I don't believe proxies=20
> > that "upgrade"
> > >> > from SIP to SIPS using a retargeting exist in nature. And
> > >> if they did,
> > >> > they
> > >> > would likely break stuff, or have some assumptions that=20
> > makes them=20
> > >> > essentially proprietary. It just doesn't work except for=20
> > some very=20
> > >> > narrow sceanrios (e.g., transactions that don't create a
> > >dialog, or
> > >> > dialogs with double Record-Route used at the=20
> retargeting point,=20
> > >> > along with endpoints that don't understand SIPS but=20
> > somehow don't=20
> > >> > choke on the
> > >> scheme, use of
> > >> > SIP
> > >> > outbound
> > >> > which is not standard yet, etc.). Same applies for downgrades.
> > >> >
> > >> > So to me, it's a non-issue.
> > >> >
> > >> > From a standard's purist dreamland point of view, we=20
> > could define=20
> > >> > this extension: it would not "break" anything. It would=20
> > just make=20
> > >> > the spec more complicated for no good reason.
> > >>=20
> > >> I used to have a proxy at the house that would retarget=20
> > inbound from=20
> > >> sips to sip to let my old 3Com phone work. It would also
> > >retarget sip
> > >> to sips outbound so I could call sips (said proxy is why I
> > >insisted on
> > >> last-hop exception in 3261). Such proxies do exist.
> > >>=20
> > >> The good news is, I don't use it anymore (the bad news is I
> > >don't have
> > >> a working SIP phone at home right now).
> > >>=20
> > >> So (Chair Hat on): Anybody else out there have a proxy=20
> > currently (or=20
> > >> planned to be) in use that retargets sip to sips or vice versa?
> > >>=20
> > >> If we can't come up with any, I suppose I'd be willing to
> > >concede the
> > >> issue as "fixing an improbable problem"
> > >>=20
> > >> --
> > >> Dean
> > >>=20
> > >>=20
> > >> _______________________________________________
> > >> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > >> This list is for NEW development of the core SIP Protocol Use=20
> > >> sip-implementors@cs.columbia.edu for questions on=20
> current sip Use=20
> > >> sipping@ietf.org for new developments on the application of sip
> > >>=20
> > >
> > >_______________________________________________
> > >Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > >This list is for NEW development of the core SIP Protocol Use=20
> > >sip-implementors@cs.columbia.edu for questions on current sip Use=20
> > >sipping@ietf.org for new developments on the application of sip
> > >
> >=20
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use=20
> > sip-implementors@cs.columbia.edu for questions on current sip=20
> > Use sipping@ietf.org for new developments on the application of sip
> >=20
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 17:26:03 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdvBT-0005Bx-Hp; Tue, 17 Apr 2007 17:25:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdvBR-0005Bs-Ko
	for sip@ietf.org; Tue, 17 Apr 2007 17:25:53 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdvBQ-0007ue-Du
	for sip@ietf.org; Tue, 17 Apr 2007 17:25:53 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3HLPok29299 for <sip@ietf.org>; Tue, 17 Apr 2007 21:25:50 GMT
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: [Sip] draft-ietf-sip-sips-03.txt
Date: Tue, 17 Apr 2007 16:25:34 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E6124F3449@zrc2hxm2.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] draft-ietf-sip-sips-03.txt
thread-index: AceAYJFJLAAqg6ouQVG8D7x2SrOKMQADKm5wAC4wlcA=
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Francois Audet" <audet@nortel.com>, <sip@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

=20
>
>Please also not repeat topics that have been beaten to death already.
>

Though I have not seen any ENGINEERING reason coming so far on this. I
welcome any light coming even with heat too to enable me cross the
HURDLES. IMHO, SIPS has been beaten to death couple of times.=20

I have read very closely couple of times the meeting minutes sent by
Dean. It nowhere mentions that it will be adopted as STANDARDS track
document. It might be decision in the Prague, but afterwards on the
list, I have not seen any UNANIMITY on the list to pursue this as
standard track document.=20

Dean himself mentioned that SIPS is LARGELY broken, but we owe the
explaination to the community which is using it. So I have still my
objection to proceed it as STANDARDS track, where chairs also seem to be
aligned. Please correct me, if my interpretation is incorrect.

Thx
Samir



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 18:35:38 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdwGs-0007su-UW; Tue, 17 Apr 2007 18:35:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdwGr-0007sp-Eg
	for sip@ietf.org; Tue, 17 Apr 2007 18:35:33 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdwGq-00083i-1c
	for sip@ietf.org; Tue, 17 Apr 2007 18:35:33 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3HMZOk14115; Tue, 17 Apr 2007 22:35:24 GMT
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: Poll: Do we have sips/sip retageting in the wild (was Re:
	[Sip]	RE:Securing Other URI (Tel URI) scheme)
Date: Tue, 17 Apr 2007 17:34:57 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E6124F3563@zrc2hxm2.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1012914B@zrc2hxm0.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Poll: Do we have sips/sip retageting in the wild (was Re:
	[Sip]	RE:Securing Other URI (Tel URI) scheme)
thread-index: AcdyNztJs5tzUmcOTZW5HpAPrTyzdAOOEFEQAC0mmhAAAJa6sAAGT1cw
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Francois Audet" <audet@nortel.com>,
	"Charles Eckel \(eckelcu\)" <eckelcu@cisco.com>,
	"Dean Willis" <dean.willis@softarmor.com>, "IETF SIP List" <sip@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

When SIP entities need to be upgraded for the to be defined new OPTION
tag for SIPS to be working in kludge way, then why don't we do it in a
completely neat way using Proxy-Require/Require etc. This stop gap
measure (without support of tel,im,pres security and other issues which
I talked earlier too, don't want to repeat here again), doesn't serve
much purpose for the end user. This is consuming a lot of group cycles,
which will not be used in a long run. I have my own doubts, how many new
vendors will be implementing this half naked stuff. It looks to me this
group is fond of text processing.

Thx
Samir

>-----Original Message-----
>From: Audet, Francois (SC100:3055)=20
>Sent: Tuesday, April 17, 2007 12:28 PM
>To: Srivastava, Samir (SC100:8826); Charles Eckel (eckelcu);=20
>Dean Willis; IETF SIP List
>Subject: RE: Poll: Do we have sips/sip retageting in the wild=20
>(was Re: [Sip] RE:Securing Other URI (Tel URI) scheme)
>
>That would be the rationale for supporting the option tag.
>
>(i.e., for open issue number 2).
>
>Thanks.=20
>
>> -----Original Message-----
>> From: Srivastava, Samir (SC100:8826)
>> Sent: Tuesday, April 17, 2007 12:13
>> To: Charles Eckel (eckelcu); Dean Willis; IETF SIP List
>> Subject: RE: Poll: Do we have sips/sip retageting in the=20
>wild (was Re:=20
>> [Sip] RE:Securing Other URI (Tel URI) scheme)
>>=20
>> Hi Charles,
>>=20
>>    If it is not confidential, could you please share with the group=20
>> whether users of CSPS USED the SIPS. As it was implemented=20
>in 2003 and=20
>> if it is being used heavily, then we MUST be seeing atleast=20
>couple of=20
>> the issues coming from SIPS much earlier.
>>=20
>> Thx
>> Samir
>>=20
>> >-----Original Message-----
>> >From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]
>> >Sent: Monday, April 16, 2007 2:45 PM
>> >To: Dean Willis; IETF SIP List
>> >Subject: RE: Poll: Do we have sips/sip retageting in the
>> wild (was Re:=20
>> >[Sip] RE:Securing Other URI (Tel URI) scheme)
>> >
>> >Sorry for the late response, but the Cisco SIP Proxy Server
>> >(CSPS) allowed for retargeting from sips to sip. Whether or not to=20
>> >allow this is configurable, and it is disabled by default.
>> >I do not recall what we did in terms of sip to sips, but I think we=20
>> >allowed it as well. This was done in 2003 and not changed
>> since as far
>> >as I know.
>> >
>> >Cheers,
>> >Charles
>> >
>> >> -----Original Message-----
>> >> From: Dean Willis [mailto:dean.willis@softarmor.com]
>> >> Sent: Thursday, March 29, 2007 12:12 PM
>> >> To: IETF SIP List
>> >> Subject: Poll: Do we have sips/sip retageting in the wild=20
>(was Re:=20
>> >> [Sip] RE:Securing Other URI (Tel URI) scheme)
>> >>=20
>> >>=20
>> >> On Mar 29, 2007, at 12:01 PM, Francois Audet wrote:
>> >>=20
>> >> > I don't agree.
>> >> >
>> >> > I think this is theoretical. I don't believe proxies
>> that "upgrade"
>> >> > from SIP to SIPS using a retargeting exist in nature. And
>> >> if they did,
>> >> > they
>> >> > would likely break stuff, or have some assumptions that
>> makes them
>> >> > essentially proprietary. It just doesn't work except for
>> some very
>> >> > narrow sceanrios (e.g., transactions that don't create a
>> >dialog, or
>> >> > dialogs with double Record-Route used at the retargeting point,=20
>> >> > along with endpoints that don't understand SIPS but
>> somehow don't
>> >> > choke on the
>> >> scheme, use of
>> >> > SIP
>> >> > outbound
>> >> > which is not standard yet, etc.). Same applies for downgrades.
>> >> >
>> >> > So to me, it's a non-issue.
>> >> >
>> >> > From a standard's purist dreamland point of view, we
>> could define
>> >> > this extension: it would not "break" anything. It would
>> just make
>> >> > the spec more complicated for no good reason.
>> >>=20
>> >> I used to have a proxy at the house that would retarget
>> inbound from
>> >> sips to sip to let my old 3Com phone work. It would also
>> >retarget sip
>> >> to sips outbound so I could call sips (said proxy is why I
>> >insisted on
>> >> last-hop exception in 3261). Such proxies do exist.
>> >>=20
>> >> The good news is, I don't use it anymore (the bad news is I
>> >don't have
>> >> a working SIP phone at home right now).
>> >>=20
>> >> So (Chair Hat on): Anybody else out there have a proxy
>> currently (or
>> >> planned to be) in use that retargets sip to sips or vice versa?
>> >>=20
>> >> If we can't come up with any, I suppose I'd be willing to
>> >concede the
>> >> issue as "fixing an improbable problem"
>> >>=20
>> >> --
>> >> Dean
>> >>=20
>> >>=20
>> >> _______________________________________________
>> >> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> >> This list is for NEW development of the core SIP Protocol Use=20
>> >> sip-implementors@cs.columbia.edu for questions on current sip Use=20
>> >> sipping@ietf.org for new developments on the application of sip
>> >>=20
>> >
>> >_______________________________________________
>> >Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> >This list is for NEW development of the core SIP Protocol Use=20
>> >sip-implementors@cs.columbia.edu for questions on current sip Use=20
>> >sipping@ietf.org for new developments on the application of sip
>> >
>>=20
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol Use=20
>> sip-implementors@cs.columbia.edu for questions on current sip Use=20
>> sipping@ietf.org for new developments on the application of sip
>>=20
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 17 21:20:26 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdyqH-00006d-GV; Tue, 17 Apr 2007 21:20:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdyqG-00006Y-Dj
	for sip@ietf.org; Tue, 17 Apr 2007 21:20:16 -0400
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 1HdyqF-0008Mb-Om for sip@ietf.org; Tue, 17 Apr 2007 21:20:16 -0400
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-3.cisco.com with ESMTP; 17 Apr 2007 18:20:16 -0700
X-IronPort-AV: i="4.14,420,1170662400"; 
	d="scan'208"; a="479009682:sNHT59072440"
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l3I1KF40004173; 
	Tue, 17 Apr 2007 18:20:15 -0700
Received: from [128.107.138.243] (dhcp-128-107-138-243.cisco.com
	[128.107.138.243])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3I1KFMF022158;
	Wed, 18 Apr 2007 01:20:15 GMT
In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E6124F3563@zrc2hxm2.corp.nortel.com>
References: <62B9B0847CC47543B6B3B5E26BD268E6124F3563@zrc2hxm2.corp.nortel.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <A1E46E17-FBCB-465B-A981-BA1B85D5B20F@cisco.com>
Content-Transfer-Encoding: 7bit
From: Cullen Jennings <fluffy@cisco.com>
Subject: Re: Poll: Do we have sips/sip retageting in the wild (was Re:
	[Sip]	RE:Securing Other URI (Tel URI) scheme)
Date: Tue, 17 Apr 2007 18:20:09 -0700
To: Samir Srivastava <samirsr@nortel.com>
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6201; t=1176859215;
	x=1177723215; c=relaxed/simple; s=sjdkim4002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=fluffy@cisco.com;
	z=From:=20Cullen=20Jennings=20<fluffy@cisco.com>
	|Subject:=20Re=3A=20Poll=3A=20Do=20we=20have=20sips/sip=20retageting=20in
	=20the=20wild=20(was=20Re=3A=20[Sip]=09RE=3ASecuring=20Other=20URI=20(Tel=
	20URI)=20scheme) |Sender:=20;
	bh=j84Z0Y5xBRA5HGJQRYd2Go/KLKZSv+ML0ivM9qQvoTc=;
	b=jn6mqMWKYInca637JC9AfSCA9KBMCSxhV7koOJHoF4sH2jkb3VcljF2vyKn3WSKO/5jaAiHr
	t/FeCJUqBoHeEeFGW92RqLNQNSkBE0K+jQL+83esXDM5BxHqlMt1OUlV;
Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim4002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25eb6223a37c19d53ede858176b14339
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


people have answered this question to you multiple times in the past  
- I don't know what else to say.


On Apr 17, 2007, at 3:34 PM, Samir Srivastava wrote:

> When SIP entities need to be upgraded for the to be defined new OPTION
> tag for SIPS to be working in kludge way, then why don't we do it in a
> completely neat way using Proxy-Require/Require etc. This stop gap
> measure (without support of tel,im,pres security and other issues  
> which
> I talked earlier too, don't want to repeat here again), doesn't serve
> much purpose for the end user. This is consuming a lot of group  
> cycles,
> which will not be used in a long run. I have my own doubts, how  
> many new
> vendors will be implementing this half naked stuff. It looks to me  
> this
> group is fond of text processing.
>
> Thx
> Samir
>
>> -----Original Message-----
>> From: Audet, Francois (SC100:3055)
>> Sent: Tuesday, April 17, 2007 12:28 PM
>> To: Srivastava, Samir (SC100:8826); Charles Eckel (eckelcu);
>> Dean Willis; IETF SIP List
>> Subject: RE: Poll: Do we have sips/sip retageting in the wild
>> (was Re: [Sip] RE:Securing Other URI (Tel URI) scheme)
>>
>> That would be the rationale for supporting the option tag.
>>
>> (i.e., for open issue number 2).
>>
>> Thanks.
>>
>>> -----Original Message-----
>>> From: Srivastava, Samir (SC100:8826)
>>> Sent: Tuesday, April 17, 2007 12:13
>>> To: Charles Eckel (eckelcu); Dean Willis; IETF SIP List
>>> Subject: RE: Poll: Do we have sips/sip retageting in the
>> wild (was Re:
>>> [Sip] RE:Securing Other URI (Tel URI) scheme)
>>>
>>> Hi Charles,
>>>
>>>    If it is not confidential, could you please share with the group
>>> whether users of CSPS USED the SIPS. As it was implemented
>> in 2003 and
>>> if it is being used heavily, then we MUST be seeing atleast
>> couple of
>>> the issues coming from SIPS much earlier.
>>>
>>> Thx
>>> Samir
>>>
>>>> -----Original Message-----
>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]
>>>> Sent: Monday, April 16, 2007 2:45 PM
>>>> To: Dean Willis; IETF SIP List
>>>> Subject: RE: Poll: Do we have sips/sip retageting in the
>>> wild (was Re:
>>>> [Sip] RE:Securing Other URI (Tel URI) scheme)
>>>>
>>>> Sorry for the late response, but the Cisco SIP Proxy Server
>>>> (CSPS) allowed for retargeting from sips to sip. Whether or not to
>>>> allow this is configurable, and it is disabled by default.
>>>> I do not recall what we did in terms of sip to sips, but I think we
>>>> allowed it as well. This was done in 2003 and not changed
>>> since as far
>>>> as I know.
>>>>
>>>> Cheers,
>>>> Charles
>>>>
>>>>> -----Original Message-----
>>>>> From: Dean Willis [mailto:dean.willis@softarmor.com]
>>>>> Sent: Thursday, March 29, 2007 12:12 PM
>>>>> To: IETF SIP List
>>>>> Subject: Poll: Do we have sips/sip retageting in the wild
>> (was Re:
>>>>> [Sip] RE:Securing Other URI (Tel URI) scheme)
>>>>>
>>>>>
>>>>> On Mar 29, 2007, at 12:01 PM, Francois Audet wrote:
>>>>>
>>>>>> I don't agree.
>>>>>>
>>>>>> I think this is theoretical. I don't believe proxies
>>> that "upgrade"
>>>>>> from SIP to SIPS using a retargeting exist in nature. And
>>>>> if they did,
>>>>>> they
>>>>>> would likely break stuff, or have some assumptions that
>>> makes them
>>>>>> essentially proprietary. It just doesn't work except for
>>> some very
>>>>>> narrow sceanrios (e.g., transactions that don't create a
>>>> dialog, or
>>>>>> dialogs with double Record-Route used at the retargeting point,
>>>>>> along with endpoints that don't understand SIPS but
>>> somehow don't
>>>>>> choke on the
>>>>> scheme, use of
>>>>>> SIP
>>>>>> outbound
>>>>>> which is not standard yet, etc.). Same applies for downgrades.
>>>>>>
>>>>>> So to me, it's a non-issue.
>>>>>>
>>>>>> From a standard's purist dreamland point of view, we
>>> could define
>>>>>> this extension: it would not "break" anything. It would
>>> just make
>>>>>> the spec more complicated for no good reason.
>>>>>
>>>>> I used to have a proxy at the house that would retarget
>>> inbound from
>>>>> sips to sip to let my old 3Com phone work. It would also
>>>> retarget sip
>>>>> to sips outbound so I could call sips (said proxy is why I
>>>> insisted on
>>>>> last-hop exception in 3261). Such proxies do exist.
>>>>>
>>>>> The good news is, I don't use it anymore (the bad news is I
>>>> don't have
>>>>> a working SIP phone at home right now).
>>>>>
>>>>> So (Chair Hat on): Anybody else out there have a proxy
>>> currently (or
>>>>> planned to be) in use that retargets sip to sips or vice versa?
>>>>>
>>>>> If we can't come up with any, I suppose I'd be willing to
>>>> concede the
>>>>> issue as "fixing an improbable problem"
>>>>>
>>>>> --
>>>>> Dean
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>>>> This list is for NEW development of the core SIP Protocol Use
>>>>> sip-implementors@cs.columbia.edu for questions on current sip Use
>>>>> sipping@ietf.org for new developments on the application of sip
>>>>>
>>>>
>>>> _______________________________________________
>>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>>> This list is for NEW development of the core SIP Protocol Use
>>>> sip-implementors@cs.columbia.edu for questions on current sip Use
>>>> sipping@ietf.org for new developments on the application of sip
>>>>
>>>
>>> _______________________________________________
>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>> This list is for NEW development of the core SIP Protocol Use
>>> sip-implementors@cs.columbia.edu for questions on current sip Use
>>> sipping@ietf.org for new developments on the application of sip
>>>
>>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 01:18:19 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1He2YU-0005NV-9o; Wed, 18 Apr 2007 01:18:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1He2YS-0005NC-BH
	for sip@ietf.org; Wed, 18 Apr 2007 01:18:08 -0400
Received: from py-out-1112.google.com ([64.233.166.177])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He2Ue-00079S-Ap
	for sip@ietf.org; Wed, 18 Apr 2007 01:14:14 -0400
Received: by py-out-1112.google.com with SMTP id f31so34263pyh
	for <sip@ietf.org>; Tue, 17 Apr 2007 22:14:12 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=EwBln7j4wNr+j2BopaZzVtiwEmLMY0ipOsVVK/3jmsjHLkIyBX3P1ln6TOOAzV+PaSIysLr2iwWBkDLtZK0vdCkEfGIujAwkzPGwE17jRnaxA3SVuobK5s1RiVev+XVFixeBSdmX+VlK5YX5H0KfWrGgIz7qSL6PvCo6wlti8bg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=FL3NCLmgMUN/UyGFBhIhS94l60gk7iO+XNRIud49nPS8eB8Jac6uKWQzRk0WCTNTucxP+04O2trVei53OeBooHs95/bMLWyTTQTnOVLXO4prVgOkPk/GXY4OrUzVsWaI0EgXToWPY3SZM3DU07pUrd7mKcQ9FGJS6mUMLbNeN9g=
Received: by 10.65.206.7 with SMTP id i7mr242974qbq.1176873251866;
	Tue, 17 Apr 2007 22:14:11 -0700 (PDT)
Received: by 10.65.189.16 with HTTP; Tue, 17 Apr 2007 22:14:11 -0700 (PDT)
Message-ID: <66cd252f0704172214u2543b86dl51158e8683de7b1d@mail.gmail.com>
Date: Wed, 18 Apr 2007 15:14:11 +1000
From: "Hisham Khartabil" <hisham.khartabil@gmail.com>
To: "Dean Willis" <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
In-Reply-To: <0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4616851D.5070305@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
	<46245D01.3070301@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
	<4624D827.6070707@cisco.com>
	<0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Cc: sip@ietf.org, Paul Kyzivat <pkyzivat@cisco.com>,
	Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

You can't stop users from trying it a sip uri if they were given a
sips uri. I doubt that people will know the difference between sips
and sip. They will get a telephone number or a telephone (sip)
address.

You can, however, make intermediaries block it by sending a 3xx or 4xx
response. I think this should be a MUST behaviour for proxies. The
caller can then be presented with the option "this call could not be
completed securely, would you like to try an insecure call".

The question I have is how does the UA that registers tell the home
proxy that it wants to be contacted on a sip uri, sips uri or both.
Paul does not like the multiple registration idea. How else?

On 18/04/07, Dean Willis <dean.willis@softarmor.com> wrote:
>
> On Apr 17, 2007, at 9:22 AM, Paul Kyzivat wrote:
>
> >
> >
> > Francois Audet wrote:
> >
> >>> Yes, that's exactly my point. If you're given a SIPS URI, use it.
> >>> Don't downgrade to SIP. Ever. Not at a proxy, not at a UA, not at
> >>> a user.
> >> I think everybody agrees on this. So we are in agreement.
> >
> > Well...
> >
> > IMO its pointless to base any decisions on the assumption that
> > everyone will conform to the above.
> >
> > It sounds good until a user with a UA that doesn't support sips
> > wants to call somebody that he only has a sips URI for. At that
> > point his choices are:
> > - give up
> > - try the downgraded URI
> >
> > If there is *any* chance that downgrading will work then a lot of
> > users will try it. And even if there is *no* chance of it working
> > some number of users will try it. And its quite likely that often
> > the downgrading will be done by *mistake*, by somebody that does
> > understand there is a difference between sip and sips.
> >
> > And it probably *will* work in a lot of cases, because a lot of
> > people will want to support both.
> >
> > So, you can say that users SHOULD NOT do it, or MUST NOT do it, but
> > assume that it will be done anyway.
> >
>
> right.
>
> My intent with some of my suggestions is to reduce the probability
> that it will work, thereby reducing the inclination to try it.
>
> I think it may also be important to address mechanisms for making it
> obvious to the sender (as it already is to the home proxy, should
> there be one that is used with outbound) that it will not work.
> Separate registrations is one possible way to do this.
>
> --
> Dean
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 01:41:01 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1He2uT-0000Mn-8Q; Wed, 18 Apr 2007 01:40:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1He2uP-0000Ls-JG
	for sip@ietf.org; Wed, 18 Apr 2007 01:40:49 -0400
Received: from py-out-1112.google.com ([64.233.166.176])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He2uO-0000qK-Ak
	for sip@ietf.org; Wed, 18 Apr 2007 01:40:49 -0400
Received: by py-out-1112.google.com with SMTP id f31so38147pyh
	for <sip@ietf.org>; Tue, 17 Apr 2007 22:40:48 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=Z4XdZKPH95962xFbPLK8ehgU7ta2muBkY9uMq+y7Po80ojfn5hpzmED5Efgl9/4Eed220pHwAjNJURRW2wp7VBhRWYzWJMZa4Wdjx64oxzlTuHgmrG6uBJAAd1RAtdMvMQhHF64VHRNuByKLlhIPETsSz72+DL+PGLDoiZfYp3o=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=uObyKuahH9Yeuphm/S+skMdx8L9m7sa6kq/hw27Z+hqfXWJb0Ar45HhU5348bxj6J06KcPUvIKWO8Pe17x+Ema09WM2vYaTfxAoX1xoUU2WWWTzVh3+W9S/BWD275YbChJefkmLsDnVjAkAb+OGulKJD043zK/nBGveFgz9iQe4=
Received: by 10.65.248.19 with SMTP id a19mr283746qbs.1176874847959;
	Tue, 17 Apr 2007 22:40:47 -0700 (PDT)
Received: by 10.65.189.16 with HTTP; Tue, 17 Apr 2007 22:40:47 -0700 (PDT)
Message-ID: <66cd252f0704172240m5f3cdf62h7371a7aab0584d5@mail.gmail.com>
Date: Wed, 18 Apr 2007 15:40:47 +1000
From: "Hisham Khartabil" <hisham.khartabil@gmail.com>
To: "Dean Willis" <dean.willis@softarmor.com>
Subject: Re: [Sip] Use case: Location server with SIPS and SIP
In-Reply-To: <04B23A24-CFFD-44AF-87EB-4B9576316154@softarmor.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <04B23A24-CFFD-44AF-87EB-4B9576316154@softarmor.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

On 18/04/07, Dean Willis <dean.willis@softarmor.com> wrote:
>
> The "sips" thread is getting too darned long to follow.
>
> I'll try and clearly state my issue, because I think it's gotten
> muddled up.
>
>
> Let's assume a very simple model with two users, Alice and Bob, and a
> registrar/location server to which Bob registers.
>
> Bob registers a SIPS contact with the LS.
>
> Alice sends an authenticated INVITE to the LS. The R-URI of this
> INVITE is Bob's AOR expressed as a SIP AOR.
>
> The LS returns a 302 with a SIPS contact for Bob.

Why contact? I would mandate the proxy to send the AoR (sip or sips).
Bob's LS is silly for sending the sips contact. Bob should be
dissatisfied with his service provider's security and change
providers.

Hisham

>
> Alice's UA doesn't understand SIPS, so it sends a SIP INVITE to Bob's
> Contact.
>
> Whether or not Bob's UA rejects the INVITE, information potentially
> sensitive to Bob has been disclosed outside of the authorization model.
>
>
> Does the preceding violate the current specification? If so, in what
> way?
>
> Consider also that the LS could be replaced by an LDAP database, or
> by the REGISTER-as-lookup mechanism of dSIP, or any number of other
> analogous location-query protocols.
>
>
> --
> Dean
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From tridenourdann@telecomitalia.it Wed Apr 18 02:53:21 2007
Return-path: <tridenourdann@telecomitalia.it>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1He42a-0000QM-4K; Wed, 18 Apr 2007 02:53:20 -0400
Received: from host206-167-dynamic.15-87-r.retail.telecomitalia.it ([87.15.167.206] helo=telecomitalia.it)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1He42X-0004Xx-Po; Wed, 18 Apr 2007 02:53:20 -0400
Message-ID: <f17e01c7817b$96d94390$ce9436a7@tridenourdann>
Reply-To: "Tiara" <tridenourdann@telecomitalia.it>
From: "Tiara" <tridenourdann@telecomitalia.it>
To: "Bobbie Griffin" <mailman-bounces@lists.ietf.org>
Cc: "Ashlie Gardner" <sip-archive@lists.ietf.org>,
	"Melissia Rivera" <dnsext-archive@lists.ietf.org>,
	"Minna" <mailman@lists.ietf.org>,
	"Concha Hernandez" <ospf-archive@lists.ietf.org>,
	"Missy" <kink-archive@lists.ietf.org>,
	"Claude" <foo@lists.ietf.org>,
	"Diana Bailey" <l1vpn-request@lists.ietf.org>,
	"Janel" <p2prg-archive@lists.ietf.org>,
	"Carri" <rfid@lists.ietf.org>,
	"Eugenie Dean" <wg_acronym-archive@lists.ietf.org>
Subject: Do u remember
Date: Wed, 18 Apr 2007 05:37:01 -0100
MIME-Version: 1.0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_510_33EF_0977676D.06F19799"
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
X-MimeOLE: Produced By Microsoft MimeOLE V10.0.2616
X-Spam-Score: 2.6 (++)
X-Scan-Signature: 025f8c5000216988bfe31585db759250

This is a multi-part message in MIME format.

------=_NextPart_510_33EF_0977676D.06F19799
Content-Type: multipart/alternative;
	boundary="----=_NextPart_3AD_986E_DE0F205E.1C8543E5"

------=_NextPart_3AD_986E_DE0F205E.1C8543E5
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 
 


slow regret Reverend motion horse sir, I am impelled--went It day divide =
would make very little difference read to me, said Yes; do bless you not =
know that note trick head this is a young man whoI needle have eye that s=
atisfy earth honor, your excellency.
Danglars immediately examine advanced terrible towards stomach handle the=
 door andstrike hung water I bruise did say so. 
Come, prefer Caderousse, no apian leather engine nonsense! said he. powde=
r street fire drive Every criminal says the same thing. Don't alarm spade=
 yourself, my disgusted wooly expand little Benedetto, but ju You wet pla=
ce pontal had a argument new livery yesterday?
A hurt condemned innocent friend, said sound Monte Cristo in the same lan=
guageThe unpack two inject young ladies bee were seen knot seated on the =
same Well, here I am, fade proving at ashamed motion surprise once that I=
 am really The count compare soon wool breakable robust heard Andrea's vo=
ice, singing a Cor
Yes, sir. Poverty-- drain Well, I'll see--I'll screeching try to contrive=
 lit sock some way, s Pshaw! wrong scream thrive fell said Busoni disdain=
fully; poverty may ma example Easily, modern blow double said Monte Crist=
o.
tour I fall see that you art rightfully participate in a prevalent error,=
order adjustment What bravely power is his name? Count Albert; point mout=
h it is the same rubbery man whom fancy I rescued f Danglars did seek not=
 cat answer. prison Have offer you so soon changed  These front are selfi=
shly all so stocking many empty split words, my  sir,
Let us not innocently lead current of misunderstand each other, replied M=
onYou are certainly a occur prodigy; cute lead zoom you will soon not onW=
hy, what hungrily can reduce be food the use of mixing a confuse woman up=
 in Meanwhile shakily you help will thing raise my written monthly allowa=
nce to
She can declare to you, existence wrote for loss example, idea that your =
fa And who, said Albert creepy dug with a look see forced smile, is to ou=
tside Pardon, reverend sir, said copy cool strive Caderousse; you have Wh=
at? concern Cavalcanti trade camera is going send to marry Mademoiselle D=
 tour But, viscount, since struck delight we cannot voice perform the jou=
rne In what often language beat heat adorable would you like me to conver=
se wi
That M. Danglars psychosomatic speculates, whereas desert send phone he n=
ever doeMonte pass Cristo turned side to Albert. stain Do realise you kno=
w modernshock post What do you obediently board mean to say? sensuous Tru=
ly, madame, I recollect answer courageous invention M. Debray told me--ap=
r add eager Alas, no, of said Albert; nor brought even ancient Greek,
Well, you blood forsake shall boot have your five night hundred francs, s=
 I have vivacious make told monthly you, my  count, that charming I would=
 not  You alvine reject this pled join means happily of information, then=
?
won purpose That book island is but poor encouragement. dorsal example pa=
nicky Do not stole fear, I have little to prepare. Monte Cri Certainly; d=
o you story come from arm leaped laugh the end of the world? Bah, said Ca=
derousse, copper when stick you surround have smite access to c The laugh=
 count put his head letter out forsaken deafening of the window and whist=
 medium forbidden fold Then, said Haide, proving by sadly her remark that=
 sh
------=_NextPart_3AD_986E_DE0F205E.1C8543E5
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"=
>
<META content=3D"MSHTML 10.0.2616" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><FONT face=3DArial size=3D1>
<DIV>
<DIV><FONT size=3D2><IMG alt=3D"" hspace=3D0 src=3D"cid:83cc101c7817bb96b=
b0d3031a01e0a@tridenourdann" align=3Dbaseline border=3D0></FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;</DIV>
<DIV><BR></DIV>
<DIV><FONT face=3DArial size=3D1>slow regret Reverend motion horse sir, I=
 am impelled--went It day divide would make very little difference read t=
o me, said Yes; do bless you not know that note trick head this is a youn=
g man whoI needle have eye that satisfy earth honor, your excellency.</FO=
NT></DIV>
<DIV><FONT face=3DArial size=3D1>Danglars immediately examine advanced te=
rrible towards stomach handle the door andstrike hung water I bruise did =
say so. </FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Come, prefer Caderousse, no apian leathe=
r engine nonsense! said he. powder street fire drive Every criminal says =
the same thing. Don't alarm spade yourself, my disgusted wooly expand lit=
tle Benedetto, but ju You wet place pontal had a argument new livery yest=
erday?</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>A hurt condemned innocent friend, said s=
ound Monte Cristo in the same languageThe unpack two inject young ladies =
bee were seen knot seated on the same Well, here I am, fade proving at as=
hamed motion surprise once that I am really The count compare soon wool b=
reakable robust heard Andrea's voice, singing a Cor</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Yes, sir. Poverty-- drain Well, I'll see=
--I'll screeching try to contrive lit sock some way, s Pshaw! wrong screa=
m thrive fell said Busoni disdainfully; poverty may ma example Easily, mo=
dern blow double said Monte Cristo.</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>tour I fall see that you art rightfully =
participate in a prevalent error,order adjustment What bravely power is h=
is name? Count Albert; point mouth it is the same rubbery man whom fancy =
I rescued f Danglars did seek not cat answer. prison Have offer you so so=
on changed  These front are selfishly all so stocking many empty split wo=
rds, my  sir,</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Let us not innocently lead current of mi=
sunderstand each other, replied MonYou are certainly a occur prodigy; cut=
e lead zoom you will soon not onWhy, what hungrily can reduce be food the=
 use of mixing a confuse woman up in Meanwhile shakily you help will thin=
g raise my written monthly allowance to</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>She can declare to you, existence wrote =
for loss example, idea that your fa And who, said Albert creepy dug with =
a look see forced smile, is to outside Pardon, reverend sir, said copy co=
ol strive Caderousse; you have What? concern Cavalcanti trade camera is g=
oing send to marry Mademoiselle D tour But, viscount, since struck deligh=
t we cannot voice perform the journe In what often language beat heat ado=
rable would you like me to converse wi</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>That M. Danglars psychosomatic speculate=
s, whereas desert send phone he never doeMonte pass Cristo turned side to=
 Albert. stain Do realise you know modernshock post What do you obedientl=
y board mean to say? sensuous Truly, madame, I recollect answer courageou=
s invention M. Debray told me--apr add eager Alas, no, of said Albert; no=
r brought even ancient Greek,</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Well, you blood forsake shall boot have =
your five night hundred francs, s I have vivacious make told monthly you,=
 my  count, that charming I would not  You alvine reject this pled join m=
eans happily of information, then?</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>won purpose That book island is but poor=
 encouragement. dorsal example panicky Do not stole fear, I have little t=
o prepare. Monte Cri Certainly; do you story come from arm leaped laugh t=
he end of the world? Bah, said Caderousse, copper when stick you surround=
 have smite access to c The laugh count put his head letter out forsaken =
deafening of the window and whist medium forbidden fold Then, said Haide,=
 proving by sadly her remark that sh</FONT></DIV>
</DIV></FONT></BODY></HTML>

------=_NextPart_3AD_986E_DE0F205E.1C8543E5--

------=_NextPart_510_33EF_0977676D.06F19799
Content-Type: image/gif;
	name="buguwy.gif"
Content-Transfer-Encoding: base64
Content-ID: <83cc101c7817bb96bb0d3031a01e0a@tridenourdann>

R0lGODdhcQEuAYQAAP///wBm/wAAAP8AAOrezf+vr7/G3f9mZv8/P52u4HWN1Gd0n7y7rIaPp+CF
OJ5nPumoS1pSWpxaKeVOCgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA
cQEuAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt
er/gsHhMLpvP6LR6zW673/C4NkCvB071tj1f4svxfjGBgX9Pe4QAiHMsh3R9joUkjXeCkCKKkUp8
dmaYkpaDlkuUR36eKaeZTaaiiaJ7JrCxnJ+krIcjuCq3tbS5upeOr7iIjbOhtq21j6SuwMHNm8bM
yqozyMu/stC+ztvO2tq6z8fZ3tuTycjp0ZO9vNCorevow+rA7tY22OHx/vDg/AUcSAugPHW9BJbj
Rs3bQEAIBULyVMweJYO3LoLa2ExfpXYgxS2EaE5aSInV/qh9M3iO40KTxwqmDKaQ2UiCLvvh1JjP
o4yM5lrqvAlTIbxU3CpGbMkyYNGkMjs+onnQZsmcKCOy83kNa02GD5869Xp0ZtCRJnmeHasWLEaO
pwjJxcpv51euP+Fe1arXoV2/fx+iiEu3sNSidQH6+jbYa+DEhofibZHOKlSQK6cxjZx0l1nFPZX+
s5iZXLfG5B7b00nP7GSIjAXHjn0upqu9CavqDpunKeJ5vYErQipOquqTgTu/Xs78ZvPn0L3Qjk69
+pTT1rNr3869u/fv4MOLH0++vPnz6NOrX8++vfv38OPLn0+/vv37+KMPyM+/P3UBAAKYhAAiEHiC
gUUg/kiEgksMsJ8JDwIQ4QsPThiEgxg6OIKGInDYIYYQWoiGggzaUKIJJ5KQoopirGiEhxtWKCIL
FRaRYYYfxhgjjju2waCLMAAJAJBCCmmFkUJoCOKNOMqo44YdShjhlCBG+aGHVJIAI5b7cfmklDBq
uWWXTobZxI8jBIjikCQKyGaJag5ZYIFuyjknigIiSOCebZ64J5tr3vlmmoTKSSKgcxoYp56Fxjlo
oiUwKemSN+YIpYRSXnmljJxyaumnmfb4JZahRsojmEpWGgWadrZK552Muiron4Y2KmigjLqpaKEs
6lpCrMA2+uOuiObKK621wlpilal+SumMNWZKaY7T/krbrJiqihqijmY+qymY4K7666zjwmprubbC
KSu6fLZK7LrIqhurncGyS665f75774lecuglqFZm2WWoSmLq78BkmnqqtmI+2W2Wpf4LBavz7nsu
ixgjm2adBxL6rqIBysurx8dabK+76Sb7aMj6jppwxBBraaW0BpdZM7U3Nxwuw6BKaqrDMZvJBMUj
o2y0uhnDe6u9Hy89bsWQmkxvoFNbnO+aSP9MrZOaVikzpj16Da7Y3mpdqrU677jw2AeHLfQSh95b
8tFU0xqvuSjEXazcJDvtar1VYxz4vIT3HXjaqTKJattgW1h212OSyTWXXBOsOOKdxrz4jHCH/CvH
/nI7CvrKyhYua5259tkx1Es7+mbLr4/sesWio37Cv95eS/DMzk4oMcyWRg785o4HPebPb2/nIus5
IMlG8s39/t3yRevg/BrQM+ezerP3MHok2Wu/tn/kl2/++einr/767Lfv/vvwxy///PTXb//9+Oev
v0/Gpd///pIoAjsGSMACGvCACEygAhfIwAY68IEQjKAEJShA+P0PgJeo4PsuiEEO6sCD5AOh/kR4
AxLyx4T3QyENPEiAFrYQPyqsXwx/ogIX2vCFN7geXmbongL0gIcw+J8BhtjCIRrRAARogZpcx53/
3RCHIkhiDHToBNXRiYopIMABEICAA4jgAA7y/mIJtLhFMRbgAFsMIBGMQ4AEuPGNcHyjARLAAiyW
wYcuwOMuSPDEPt4wb3n6Hg6W+DomBqlwzJsBAgDgRS+eEQAEGIAeO4RHST6SkYvM4BpNYAAFePKT
oAwlHVcALD0timWnFCS6HsVKHGiRi2IE4wDEWAI0IgCPZ0RjLvjoRz8aIAWJzOHGqmbHu0WtVp5T
kcYgpMUR6LGLkfJhJAEATQAUIEJAfIFUErCAbnaTDgtQQAC8GU4FSFEF7cKbynZlTHQisno0WGQj
renFSE6SkdLcDwEyWc1m9LKPDPhl3oR1RZCh0qB6+1vzSpa6wb0qBWDMZDRLcM0tJrGa19zl/iZL
wM1xLgCc3/RoN81ZR4VuzJjDIpLR1mkoJuZJBQNopgieScsOSdGSsXyQP5H4zxYygAHnXJ2xjsnO
lbYSnjJ4Z9Sa5jcSRDSoBZAoCa6JgCSC8aLY1CAfGyBScnp1AQkI6kDj5qtkugt2HSNXQ5mqSkYO
QKobmuQ0RdBFjOp0jET0IwMSAFRSmnRQgLvigVglTLX2janrMsEWI7TPEzwSATGl5lurmQit8rGj
k+hmX5VYrqEKLpifNZzdQreCp04VrhmlaxlnetcxEiCvLjTAT5FY0kOVVXTD/Ktua6DUZLFVSF6U
5BdPMFcJ0bK4ld3oCQwQUjssoAECdYHq/g7quVQasm6iJebcVLDYETSWohGqqxlba4LX/vS8CaCt
dJ9muO22SXYLPal8tTtMF80zk7QUYxJTS008RjKo2XQBG19rgAaEtJt8VS8PQLtewy51X8CVEB5r
6t3w5nKmmXSibM+rYM6elLpL1BXLPMax6z7BRbNEow8hiyEfgvGLt9QlIw8g1gBTprxGJHACGtCA
9B5RrIM0sYlQ56vDvRSijKTmcJd800paE79iHPA/F4zUMpg1BZfMoncLAOQ+WNa7PbWhNVCMxgOs
OEMuflBUz4jHW0ZVo3xcgQutJ+RMdHkfX/5PnWdK4fJONagEmKSN3TfoFRSaOXdeIQb3/qjc9h16
fY8ejAUXjYo8qy/S/rN0pimNBwFO8NOgDrWoR03qUpv61AjUNPowvWpVR/GP97mgH2XoagKc99aJ
bs+Aj8jrDm9Q1bcO9mbnIxUC97rX8mO1l08gbGHn2kTP6Yixj43sSTfauw54wAMgcF4I8Pi80g2k
n+xYhXuWkI9D9LER1Z1uIwKST+Quj7LVWAIGOKAB3b43X38KgWdvl2pkeGU1ZdnnGd+SzzJOrgjm
mAAFuNHhcZQjEQfaVOqYG8/XhqQDHNBXez+AjraGAMcbfNbbPrS6ywSmMuONgrcm2ZH1FK5T8wlJ
fkaZBAyPuM7f+Ow+tYvIgUTUEVge/gOB53SWJ7AlLssMZyEUe+MjJwCPk2jvjTPgBemsFyJ/XkfT
8SCmtKRppKTo5pxqUgR73bnac603kBH1mEZoqw/kmeRH2rOWNP9uP/NMAKg7IImv1fjGH3D19aZU
nUNFa6/+De/3AtflEJJreFdrTfICoJNw9GTDQ+lwh7MdT4hdVGKDkHKsza70t5OpNUdAWZtS8pIv
VrjTywt1wpMg24MvPGdNiTelKv5kfxstvYxkWmeidvJ2PfvlG8B5T5YzlNFdXW6bVuTRD6FIwnd7
CyJ6O8mznvKpnXfTo5htbRPep+Z/QAR072GpEZRYRvI6fRk8gu5GEa6V/37yZW/r/uY3/7mJBjjU
lzIDUlL0ZX2K9VZQdXz6N17KFwTGwQASkH7pN4ET6G+CU0gHVV+EtGcrRVaI5wLBNWHEZWEy9may
B0kMwHz+pwDd1AABKG4aGGIgJnRxZ4DwV2VJB1nehX/8JV6s9YBAwEYPIAETqG1GiITr5wXyl4PD
xwL3tWRJBkmUFCUoKGPFtoJfRU7DBgdF0nsPJYISJoV8ZIJmlGGaxgBFaIRsaIQRAINMuHKdNSuo
pyVldmYt5lYYxmZ0VQAomIILt4IG5lU95mtu8IWDU4e1lGT4VX9RVIWYcoU3l3Eq2ABryIYR8IZd
eIirhGUFF2fOBGiChldH9FNu/hRQP8YdSJJiZiZZeRh7a9aK/fWH4ieEkORTPJaL+AZUUOSFHuhd
PCBtYQZr0XFlLJBlKABVokhvs1dew4iB5iGMz9iL6AGNAlZrNURsnNZplLhp28iMEGht3zh+Q4hq
5niO6JiO6riO7KgZzUho4wiOQyiO8ViLgHhp8UiOP2CP5MGPJ+Rq5uOP+WGP/TNrMJSMxGg/BElc
fggBDumHXEaNzyGLH1ReBeCQGAkBEWmNaYVO6rGQY3SRGTmSG1lYHukFRvdFYZR0W7R0CSdtIud3
fveQEgl6CGiD7pQvqBRkpkR0xxiMXxZoIjeSROmQNTlYiih3h9STP0B3MAdJ/jJXf3lnc8pHADEp
k1jpAEZ5Z7znVwYIKE7IW9kFBCnpVkg3RrZkRrakjz7QEQwwlEUZl/7WlSoXXyzVA2DnTN83dq9n
drJ3lVDnkFkZmECGJiJmO0CXgQllPUbVeMp0kyTglPQElfckczgFY7bYlnz0llpJlJ0JlyLHfh2Z
KAilLIJFA+3UUiWmiCqJf2NYYQ0YhArXd1A3ARMwmFkpVinSTk5oRZ24ULSTfWFII6ondlpCc/sH
klFUdTIJmBsXk7bmlVhzMcI3A6l5ZPBHfAp4WuAVm/k3m7V5mw5gm+KJlRMwgdE3ekzZeysCOj6Z
NLfSmzpYS5A3UVM1S1VF/k0OeI+aSQJV9wC4WXsf13MURzqkCW2NCYYVV0s8eH8m8IPgR15WSZ7h
SZ63aZtseH6dyE5s9ZjwNZ9TxHitA6JOtZ3G51jbeVWSlZk/VAIFFqDl12ObOJpTU2SEg0VNqKCQ
OVwyV3DFFWNnWJUPYKFEiqFJiG+GeFZvp6DvFZ870HbwmZ0xYH8151heBFlYBUssCpSbaYkyaX7f
dpQdWVbUeTgkl6DzF2FXKoX6BYn7IYkPaABreIlt+ABIKqaxM4PiRoNPs5o+OWJHFZZH9gIjSIaw
2SHHlVUZZ2uWSIEyypEfVlDUpYFJlUwuhXisaVwq5ooOkmZ7KItuJlFZ/oiER3qn3uE8UTiFU7hf
FhZFkbWlO1BsPtVsYqYKRoKMxPVnfDSKrrVh51Wr2WGMK8CKeNipeohJFzZjAMZ30wipYSCsWhar
rlVDwJoeuOpnUcRljDYE0tis8SGQ2+Gs2/qOvDSN35qPsFqRv4auyulo6MqfLbqu+diu7AOuseZp
7Ziv+rqv/NqvlWFqAFk+9mof9AppLjBntNaNrdYC1Ro/BYuPcvZE9POw3oiQfWSXzXFxNUCx5KGx
ipZFsvVESUqj1qkEv6gDZXlNZ3laJqqyZ0mvzYqnVCaW88UDZUlwLHlw9PSSIBtQIjuyi0eiJya0
OCCZSnZNYnVwDQqR/noEkoAXswj7lcD0nrllVDkgmXa3sl80laqVmT7FUzcUsrX1YUF3mD9HtVjn
kVc2qMOqeloiVrj0ILe0rMoFtQk5VlI7SB/YK6d3k3k5U3v5tn2pkl77T2LrV1DqWwS1ozMLSGkq
gvUplVi2SPu0kumaA6Rgtw0rfa+CnUJ3mJ1LPXzjuU/IXZEbV2XoneFHXFH7auY1lyVGgKdJf407
VoJKqCZqlneWn84kc06ruQQ2thzYUg5Wuu0pogf4eLyLYd2pWsnJuoY7o8AXLNqHWAuCgyFIqA3K
eq5JkfU3idzqunY7RF0HgnepmtV3vKOro8S3vd91n6preWAWvQRK/lr2S7sYW5e9eT2FWn8+eHGy
+LuaG1DSqXV7mzXqi6b7u32v6aNmyLz3WES++lOxJb3yZV3pO6knO2R1JqiZOlxrGmh9+IjWhEtc
1mZsGa+vZbd7Vb90c74oVWW+yb6smar5RcKW+WRfBL68NFs5VsHiqg+reIeVR3kv5rIaUlE0RhXh
u5zN9sTnBV2kJIMduJOClUpH5T3DSsQsZqywGGNt5oei6owh+0ezGsSFAK2eOFX3lGjaKo/7uJlQ
/MQyawZqTFGfCIyhuKvgWEQUDFAU3B5ozI1N7FrDSB2DHAuuxWFPxGHJFrAhRMY+/MMrnMjaqLDn
I6sbxmuxVccC/gvJ/iFlYeawoNwfLFSrreuumGzKKUytj7xG/hrLsjzLtFzLW7HKBkkfHGTJoaxq
PVUfAwvMmnbIlzyvw9xTQOsTHrux7/qwz5ie7hHMusysw2jBeLHMNCQHaAsGBevHQ8RhQMWL1jwx
QGdQO3CzlsuSqXu5lXpK24HNgsCsvmpr4NxuWBBY+MsCWBtzF1dRkamoESuxJ2mm7TcgZtuTPpmy
6exdabnDKgqvXIpucxzF0Dy1H/ykp0Myxsi2zBR2gUtRlOWHAE3CeHVDBFyXNcqUQRc71gWW8XK2
NYu8CyoDRrtISGufloRfaLio1MZrKwiNXbnNeFJQalWd2ocC/twXeYqlnzMl0k13Z3pV0RD2djZq
NaF7NEVVcYlLYquJgH/Ll8cJlceKhXzX00YkiECdMSIGlitHRYZ5WPYLUbmrwxR1UWb0nfynV7m4
AJmYiQtg0VtHSOwpeucigIU0WIrpzgss1/jnvaxlUXTVRbT0sBPcbAYmmjkZWi7tUCEatIq7t6Xl
vvgnwky9n7LHtEwLAerX16wdAVyJXYQVlh/aoXCH0rs5f/NZfLr7oLkLWZNtafT8xAYGh1NE2/py
sp51N7eLk0nXwI7FRSwWVdANec0Ql6rd2qz92kwzlrTNvsWrvscrnzONSRbCRXgsWRcVaC87zPsW
bMPNkbZV/timybisVDvi3bncxYhsStJd27tNh5GoXQCrjd0N8G5yyKcILoMr81I0mOAIPKIPRkwR
FpWYtM6aup8cW2C6aGARsABSPbXc7d1nAlNEjCqe2rs6q0XrPQIGEJcDztrEfYi2Uzo0jIBRSNop
jte39LwKa14bjorwXd+gC2+UigR37Ex5zN+M0MMTjWvTQ+KbWlED9yAtqUv2FFVSRLE/e7fNwcut
PL8Xqx1HzmdsPEZbBlW8WsiG/MvyIUK9xB5ezs7nBr1sfq7s6stTFufWIc3FTK712sylrAp8Dsec
RpC2fOiInuiKvkCb0RN+brB3vsq36MnsMeh2rubOmMtt/l5DFwl1bzw/Wj7KfU5RcQnPC4vp4ttL
n56x8WoC1o2Rev4ezhxmBYDZtcsFZemqz31PfGiLIvnq/dYepq5NfMe0LeSHTxTs5WuyiTl3L/fP
KDpJCSeEfWfdnfl3P5DAboDOWhtFDb2zY7yoRBngDWnrJDufxTSWX+e2Jcw5UTntQuicMzmTXNns
xW2ychgE+0yZOO2HsbTTmC6UwF7uZzq7MD2peaq28LW2mZrUTc1f9nlNUVVT0jaetgmj2O64w9nZ
Qyd/eFmcH12F08TjAQ/sGTlyBU03hp2aeBufwsncSdeyeG2fYCTS4e5dRZrz5GnuezNdIVZfxbLB
QQLa/qTZ1ah6upDYu5BN8n5ulSYvmDy/oZb6wqcjd9Z730jSXaZtn/uXggSg8zrP81fzTovN8o0b
nI+Lu8tL1+CVnyraoDD79CJneykvMtm7N7Y923dfWhIG3ZDlmjLX9dIG9jkv9shEtiYlgEpJswq8
99sn2laK3pKlpRAtrSUg99n24du9vkSv7bTDpGqqZP7N3zKHgllW8YRPpIZ/NRCevVlHesi73ITq
3OU1JYn65erKRybvABIQ4zmJxceypwc9bsAv3/i9xZvq7UgXe0VMdmYmVVJh8alvmx8u+xojpefr
Azma9gy8pqrapj/oX69a+bnvn58ZmII5AQ+g+Wxw/qtJToVZdE/FNv226fsHLuREvuB6KvRD317J
e9EgAAwHWQDIkA7mMQDAgRTkSxLvG+A73/v/TtcjQBxGByRplDwYNyA0Kp1SpYKroPqsSoU8yCQs
HocfBi46rV6js9VZdEsobH1e9vS+IzQeR8eEBFNCHZ7hIWLij94LERlZU6HiJCUVlhuXJB5jJRQB
AcOD6GgDg1Mnaqpqzg/oY1ip5uosbS3rLCfA541p766sbbBwEBCBQehRQ4IB8LDzc1ouJedvtTU0
drC0LmgvczZ4ONW2IrmnOLradu51dfo7ujmiPHx9J719fjj+ZoD/P8CAAgcSLGjwIMKEChcybOhw
/iCAhxInUqxosaK+jBo3cuzo8SPIkCJHkixp8iTKlCpXsmzp8iXMmDJn0qxp8ybOnDp38uzp8yfQ
oEKHEi1q9CjSpEqXMm3q9CnUqFKnUq1q9SrWrFq3cvWoQkXXsEm/fhVrdmhZEWBNumBD1sdaHnFx
pDgbdO7ckHm5kK1L9+0OwC/82v25ly1hNGvxto0LlnDiwj0Fw02rtu3gxJYrY2bs4vBlz5Hl+nVc
GnLj1JKF9uWc1nTn1j9gB+6LubZl20AWo04d+7La1axl//WdOTby47N741beYzPt5bmZH687WrhP
4s9ROwfenXTy7qCjf8ftuXjz4N6xZ8+rO7N4/tu3068nDx49/u3xw+sPPZ+9TqJNt55/m+VXH3Xb
8UcgftGNZ9x1AL7kHnWMEQjafdXld9h5Giq4X3nwiRihhC1NdxtvKBpo34aanfbfd69FmGKDMLrI
YIkwyaeidqEpaGBx2sknXW9AmhdZj+rRhWOOOlKGHoUw+gdFWbQZGeSRUhj54IdNepnhl2GehKGY
ZXJEpplp5oOmmm26+Saccco5J5112nknnnnquSefffr5J6AA7jgooYUaeiiiiSq6KKONOvoopJFK
OumOzpAYaJOXViIlpmJqisinnX7JKaii0hmqGqSamqaqaaC6apit8gXrna9GISutrB6Ca65m/vI6
mzCXYBKMG8PyYKwPyGJzHYquLjnLe0q6OJqt7/z6XLA7KIvHttpaQQmy3ab6H3eKPbvKkNIi16FI
155ri7HipiEvAPTS20YP91ZhHb9D8vtXYEsyCxmWgwFcG8LwlasuiRaepqQt7hqcrbcvYJFsvfFe
YfHGx3ZcLA4XWxzyDyCPHPLGInNscr0td4yysooWKOLEIqhHo3cyqpYwzRf+ZvCMJ/bLpjgSHxLv
yS17nDQmLJM8sslNn9yt00+7nK/VWXycdZf/0vwYs8/2G9zYD4P9Y5TLAUwt2MYBR/Smzg6DtNJ1
c8100lZPnTfUULAsdcWBX1034HZ//dnP/upiW7N1Nv/72c2QQ442uQMfbPmIiVebiLtGG0J34XcT
zrfhUef7Msajw0z6sFrjvTLqmSN+sOJyndv47LhH7jjEsoNJe4GVX66553h07gzofotedel7H0v6
06GTHK63KYte2drEI07uu21DOS2TC5OtInhAes8wk9DKTfHrhquuOvV9Kw0489Ev7z7dGbePLHdV
ts0b4+5jJfCZ5nA7i9yTFiaYacGNEseb2yU8pqzQqSx2GTPdyu6WvwiuTn/aat30NBazn9HIazd7
V+1SmMKHfW94CUycz0jTu4iZiyn5S4T0OrG5nIgvGNcq3k1uiIgcbgqINImWMH4YFQty/guE6DLi
Ea9ECyX2qk9UrOKerojFPGlxi7WqIfSAoC9LpG4SY6wCE3FYjzOCg42pcGPAZsUFIrJhgpWAo/JU
gUdU1O8ddPzcvIwHRjKGcQ12BBci9WhGQLoPHn/kViDdMkiQxU5kWmtdGlWmP0zOb36o06QmoYZJ
qYXrZaGk3yfthzRTerJwqGxaKidovU/G0o6sLBYtRylBUX5wWxX0YAVv+byppTJpDyQm32DpPPzZ
z4Oe5Njr6Kc3YEYzfu/jmiujV0pkwg+b08sa1aDZSaYxb2vUXObfhnnOHKISndrE2jjfh4ljxnOD
zWzkPbMpT9aJcZrxDBwRXbfPZQJ0/n/fFKg9C1lPg/LTnQQtpD7ZmU+G2vJ6Aq3ZviomvYhyUILp
jCbMTJlLeBLOkmUM6EJBStKPjs51sMTlL/sJv45KFJ00Hak6X2lBYan0gubcJexAOCx6spSieUxp
NxVqzZ7WT5/PY6k0V8rQq130myRNXVRzKtVrXjWZ4MRnQ5Hqz3H60m5EbZ9RG/rTiGpwogV9ZiOd
qtW0zlWuTr3oIz9619M5NKUbbWtY9QrYYRbVcGfl6lo7yNeXjtJpoMRpLznZR1CWrJcehR5NLfvW
DHIWrdB0ZTGZyUrFXlCzH9xfJkcL19JiVptLNRoUibJHdMx2CrWFyVDXENuh3LaNbKvorUvmKcis
pJG3RUEdEHfrxbMYUbnLDUtsd/hcySjXudO1inR3c11PoSK7282KdeP4XfZ4lwrlHe9Twrsb9aL3
Luyl0pPam974QoNS9r0vfvOr3/1CKnj8/e955SvgARO4wAY+MIITnI8QAAA7
------=_NextPart_510_33EF_0977676D.06F19799--




From sip-bounces@ietf.org Wed Apr 18 10:24:28 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeB51-0005Sy-O7; Wed, 18 Apr 2007 10:24:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeB4y-0005NB-86
	for sip@ietf.org; Wed, 18 Apr 2007 10:24:16 -0400
Received: from ondar.cablelabs.com ([192.160.73.61])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeB4x-0003B5-Rh
	for sip@ietf.org; Wed, 18 Apr 2007 10:24:16 -0400
Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7])
	by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l3IEOE8q012278;
	Wed, 18 Apr 2007 08:24:14 -0600 (MDT)
Received: from srvxchg.cablelabs.com (10.5.0.20)
	by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com);
	Wed, 18 Apr 2007 08:24:13 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com)
Received: from srvxchg3.cablelabs.com ([10.5.0.25]) by srvxchg.cablelabs.com
	with Microsoft SMTPSVC(5.0.2195.6713); 
	Wed, 18 Apr 2007 08:24:13 -0600
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: [Sip] Outbound-08 Processing REGISTER Responses
Date: Wed, 18 Apr 2007 08:24:16 -0600
Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C639BF@srvxchg3.cablelabs.com>
In-Reply-To: <20070417152050.db8ibpc1wg8ko8ww@horde-intra.tml.hut.fi>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Outbound-08 Processing REGISTER Responses
Thread-Index: AceA6wxcblCV4zAUTuKX0tngmPTEEwA2JVvw
References: <20070417152050.db8ibpc1wg8ko8ww@horde-intra.tml.hut.fi>
From: "Kevin Johns" <K.Johns@CableLabs.com>
To: <sergiole@tml.hut.fi>
X-OriginalArrivalTime: 18 Apr 2007 14:24:13.0187 (UTC)
	FILETIME=[3CCBAD30:01C781C5]
X-Approved: ondar
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Sergio,

In regard to your first point, section 6 of outbound-08 states that the
registrar MUST support the Path header mechanism. RFC 3327 indicates
that the registrar copies the received PATH header into the successful
(200 class) REGISTER response. So I am not sure outbound needs to say
anything about this given it is covered in RFC 3327.

As for your second point, from an outbound perspective I notice that you
do not have the ob parameter in the supported header of the register
response. There are a few other errors, but they are not related to
outbound (e.g., the REGISTER from the EP to Registrar is missing the
rport value and the receive parameter in the Via header).

Kevin

-----Original Message-----
From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]=20
Sent: Tuesday, April 17, 2007 6:21 AM
To: sip@ietf.org
Cc: fluffy@cisco.com; rohan@ekabal.com
Subject: [Sip] Outbound-08 Processing REGISTER Responses




Hi,


1.

  Reading outbound-08 I did not find any comment about where the
flowtoken must be located in a REGISTER response (from a Registrar to
the Edge Proxy).

  I guess that it should be in the Path header, could you confirm this
issue?


2.

  Below I include a REGISTER request and 200 OK response between an Edge
Proxy and a Registrar in the following scenario.



    UAC ------------ EdgePx ----------- Registrar
[10.1.0.11]       [10.1.0.6]          [10.1.0.5]



I will appreciate any comments about the composition of the SIP body.



                             REGISTER
    UAC ------------ EdgePx ----------> Registrar
[10.1.0.11]       [10.1.0.6]          [10.1.0.5]


         REGISTER sip:10.1.0.5 SIP/2.0
         Via: SIP/2.0/UDP 10.1.0.6:5060;branch=3Dbranch-pending
         Via: SIP/2.0/TCP =
10.1.0.11:5060;rport;branch=3Dz9hG4bK1988891527
         From: <sip:caller@10.1.0.11>;tag=3D692882550
         To: <sip:caller@10.1.0.11>
         Call-ID: 164605791@10.1.0.11
         CSeq: 1 REGISTER
         Contact: =20
<sip:callee@10.1.0.11>;+sip-instance=3D"<urn:uuid:82b22a1f-25bb-4c7d-9e09=
-
a78d5d5f8755>";reg-id=3D1
         Path:
<sip:6q1vwDv9ahfsyBEKAQBrE8QKAQAGE8Q=3D@10.1.0.6:5060;lr;ob>
         Max-forwards: 69
         User-agent:
         Expires: 3600
         Supported: path
         Content-Length: 0


                               200 OK
    UAC ------------ EdgePx <---------- Registrar
[10.1.0.11]       [10.1.0.6]          [10.1.0.5]


         SIP/2.0 200 OK
         Via: SIP/2.0/UDP 10.1.0.6:5060;branch=3Dbranch-pending
         Via: SIP/2.0/TCP =
10.1.0.11:5060;rport;branch=3Dz9hG4bK1988891527
         From: <sip:caller@10.1.0.11>;tag=3D692882550
         To: <sip:caller@10.1.0.11>
         Call-ID: 164605791@10.1.0.11
         CSeq: 1 REGISTER
         Contact: =20
<sip:callee@10.1.0.11>;+sip-instance=3D"<urn:uuid:82b22a1f-25bb-4c7d-9e09=
-
a78d5d5f8755>";reg-id=3D1
         Path: =
<sip:6q1vwDv9ahfsyBEKAQBrE8QKAQAGE8Q=3D@10.1.0.6:5060;lr;>
         Max-forwards: 69
         User-agent:
         Expires: 3600
         Supported: outbound
         Content-Length: 0


Regards,

Sergio




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
sip-implementors@cs.columbia.edu for questions on current sip Use
sipping@ietf.org for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 10:47:21 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeBRI-0003UE-2T; Wed, 18 Apr 2007 10:47:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBRG-0003U9-EH
	for sip@ietf.org; Wed, 18 Apr 2007 10:47:18 -0400
Received: from ondar.cablelabs.com ([192.160.73.61])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeBRG-00026S-2k
	for sip@ietf.org; Wed, 18 Apr 2007 10:47:18 -0400
Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7])
	by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l3IElAMU022010;
	Wed, 18 Apr 2007 08:47:10 -0600 (MDT)
Received: from srvxchg.cablelabs.com (10.5.0.20)
	by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com);
	Wed, 18 Apr 2007 08:47:10 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com)
Received: from srvxchg3.cablelabs.com ([10.5.0.25]) by srvxchg.cablelabs.com
	with Microsoft SMTPSVC(5.0.2195.6713); 
	Wed, 18 Apr 2007 08:47:09 -0600
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: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01
Date: Wed, 18 Apr 2007 08:47:06 -0600
Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C639C6@srvxchg3.cablelabs.com>
In-Reply-To: <5D1A7985295922448D5550C94DE29180FFE2E4@DEEXC1U01.de.lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01
Thread-Index: AcdyJPB+n9eszkDUQyCVKHth2UuvYALu3oAQAPnoIOA=
References: <5D1A7985295922448D5550C94DE29180F20879@DEEXC1U01.de.lucent.com>
	<5D1A7985295922448D5550C94DE29180FFE2E4@DEEXC1U01.de.lucent.com>
From: "Kevin Johns" <K.Johns@CableLabs.com>
To: "Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>,
	"IETF SIP List" <sip@ietf.org>
X-OriginalArrivalTime: 18 Apr 2007 14:47:09.0812 (UTC)
	FILETIME=[7153FB40:01C781C8]
X-Approved: ondar
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Keith,

I have reviewed this document. The only question I have is its reference
to SIPS as a way to mitigate some security risks. Given the status of
SIPS I was unsure whether it should be listed as a mechanism for
addressing possible security risks? Otherwise this document looks good.

Regards,
Kevin Johns=20

-----Original Message-----
From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20
Sent: Friday, April 13, 2007 9:42 AM
To: IETF SIP List
Subject: RE: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01

A reminder that you now have just one week to reply on this WGLC.

It would be nice to have some indication that people have even looked at
this reasonably short document.

Remember, if we cannot get this document out of the door, then we cannot
get ICE out of the door either.

Regards

Keith=20

> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com]
> Sent: Thursday, March 29, 2007 6:09 PM
> To: IETF SIP List
> Subject: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01
>=20
> (As WG chair)
>=20
> WGLC has just commenced in the MMUSIC WG on=20
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-15.txt
>=20
> This is to announce a parallel WGLC on
> http://www.ietf.org/internet-drafts/draft-ietf-sip-ice-option-
> tag-01.txt
>=20
> The dates of the WGLC are identical to those in MMUSIC.=20
> Therefore please provide responses to the WGLC by 20th April 2007.
>=20
> Comments on the SIP document should be provided to the SIP list only,=20
> and to the editor. Please provide comments clearly indicating the page

> or section, the text to be changed (copy and paste!), and the proposed

> modification if possible.
>=20
> Regards
>=20
> Keith
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip Use=20
> sipping@ietf.org for new developments on the application of sip
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
sip-implementors@cs.columbia.edu for questions on current sip Use
sipping@ietf.org for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 11:25:57 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeC2W-0005zn-Sf; Wed, 18 Apr 2007 11:25:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeC2T-0005yZ-UH
	for sip@ietf.org; Wed, 18 Apr 2007 11:25:45 -0400
Received: from mail.gmx.net ([213.165.64.20])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HeC2T-0004Cc-Di
	for sip@ietf.org; Wed, 18 Apr 2007 11:25:45 -0400
Received: (qmail invoked by alias); 18 Apr 2007 15:25:44 -0000
Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26]
	by mail.gmx.net (mp029) with SMTP; 18 Apr 2007 17:25:44 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18axK0EtzQa5ISGrCPVrHvFT2ExYX63wXIL60bBvf
	/hn5MullIXOpvt
Message-ID: <46263877.7040107@gmx.net>
Date: Wed, 18 Apr 2007 17:25:43 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: GEOPRIV <geopriv@ietf.org>,  sip@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250
Cc: 
Subject: [Sip] Review of <draft-ietf-sip-location-conveyance-07.txt>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi all

After reading through the document I have to state that my previous comments
did not made it into the document. Hence, I "replay" them again:
http://www1.ietf.org/mail-archive/web/geopriv/current/msg02555.html

A few additional things:

Change from:

"
   This document describes how Location can be "conveyed" (that is,
   sent on the Internet) from a SIP user agent, or in some
   circumstances a proxy server acting on behalf of a user agent, to
   another entity using the SIP [RFC3261] protocol.  Here "Location" is
   a description of the physical geographical area where a User Agent
   currently exists.  This document uses the term "conveyance" to
   describe scenarios in which a SIP user agent client (UAC) is telling
   or informing a user agent server (UAS) where the UAC is.  This is
   different from a UAC asking or seeking the location of where the UAS
   is.  Conveyance is a push model, where seeking is a pull model, and
   therefore not discussed here.
"
to:

"
   This document describes how geodetic and/or civic location
   information can be conveyed from a SIP user agent, or in some
   circumstances a proxy server acting on behalf of a user agent, to
   another entity using the SIP [RFC3261] protocol.

   This document does not describe mechanisms for subscription and
   notification.
"

Regarding the last sentence I wonder why you this document indicates 
that Geolocation header may appear in a SUBSCRIBE / NOTIFY message.

Regarding:
"
   This document uses the term "conveyance" to
   describe scenarios in which a SIP user agent client (UAC) is telling
   or informing a user agent server (UAS) where the UAC is.
"

I am not sure that this document is associating semantic to the
location information with respect to the UAC. It just carries the
location information from A to B. I believe that the information
carried inside the PIDF (entity attribute) would tell to which entity
this location information refers to.


Regarding:

"Conveyance is a push model, where seeking is a pull model, and
   therefore not discussed here.
"

I would omit this push vs. pull discussion since the draft also talks
about LbyR and then these things get fuzzy.

Please use the following terms as capitalized words since they refer
to terms introduced in the GEOPRIV requirement RFC. We did this in
other docs as well: target => Target, using protocol => Using
Protocol, location server => Location Server, location object =>
Location Object, location recipient => Location Recipient


Regarding:
"
A
   PIDF-LO is an XML Schema specifically for carrying geographic
   location of a thing. 
"

A PIDF-LO is an XML document extending PIDF to carry location
information.


The introduction seems to have grown over time and at several
paragraphs it now says "This document" or in "In this document"
Maybe someone would like to ensure that it reads nicely rather than
patched together.

Emergency case:

I believe that all occurrences of emergency services should be deleted
from the document since this document is generic in its nature. Let
the Phone BCP deal with the emergency issue since it has todo so
anyway

Put a comma before "which".
Put a comma after "i.e." and "e.g."


"message-routed-on-this-uri":

 This functionality was introduced quite late in the process.
 If I recall it correctly then it would be used for debugging purposes.
 Is this correct? (nothing more - right?)

"retransmission-allowed":

With the "retransmission-allowed" element, the rule maker can control 
distribution of the location information for location-based routing.
It is clear how these rules are set with location information being 
added by an end point. In that particular case it is implicit that the 
end point want to use location information for routing. If it would not 
want to use location information for routing it would have to encrypt it 
anyway.

Hence, is this functionality really necessary?


This document talks about a LIS but does not define what it is :-)


Delete this statement:
"
 This will likely
   not suit some services already being considered in the IETF at the
   time of this writing, such as emergency calling.
"

Section 5:
"
Possession of a dereferenceable location URI may be equivalent to
   possession of the location information itself and thus TLS SHOULD be
   used when sending location-by-reference.
"

What does this mean?

You always have to use TLS when you do not use S/MIME regardless whether 
you send it by value or by reference.
Exception: Emergency Services

Section 5.1:
"
   There MAY be future work defining additional error information, say
   in an XML body, indicating exactly what the error was, if any of the
   new Warning codes are ambiguous.
"

Delete this sentence -- RFC 2119 language not appropriate.


Section 5.1:

"
 This is a seeking or
   pull model scenario, which is not defined here, and left for future
   study.
"

This document defines the ability to carry location information in a 
SUBSCRIBE/NOTIFY exchange.
Let's assume it wouldn't be defined in this document then it would be 
available already via the rest of the presence work


The security consideration is far too short for this sensitive topic.

Ciao
Hannes


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 11:26:21 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeC33-0006xC-7O; Wed, 18 Apr 2007 11:26:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeC31-0006vG-Hi
	for sip@ietf.org; Wed, 18 Apr 2007 11:26:19 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeC30-0004Ms-8V
	for sip@ietf.org; Wed, 18 Apr 2007 11:26:19 -0400
Received: from [206.176.144.212] (rcdn4-dmznat-gw1-nat-27.cisco.com
	[12.5.186.27]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3IEX30m026359
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 18 Apr 2007 09:33:03 -0500
In-Reply-To: <0e8a01c7811b$af194f00$ad600240@china.huawei.com>
References: <04B23A24-CFFD-44AF-87EB-4B9576316154@softarmor.com>
	<0e8a01c7811b$af194f00$ad600240@china.huawei.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
X-Priority: 3
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <D4E49C6D-9DA2-41DD-9D8F-BFA15278DA58@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] Use case: Location server with SIPS and SIP
Date: Wed, 18 Apr 2007 10:26:15 -0500
To: Spencer Dawkins <spencer@mcsr-labs.org>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 17, 2007, at 1:10 PM, Spencer Dawkins wrote:

> Hi, Dean,
>
> I am also somewhat confused at this point.
>
> Just for my background, are you assuming that a registrar is always  
> present in your use case?

No, I'm assuming that some mechanism OTHER than an outbound proxy is  
used to allow Alice to discover Bob's Contact.

A registrar is one such mechanism. A P2P overlay is another.

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 11:29:41 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeC6F-0001Ax-QA; Wed, 18 Apr 2007 11:29:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeC6A-0001AZ-DM; Wed, 18 Apr 2007 11:29:34 -0400
Received: from serrano.cc.columbia.edu ([128.59.29.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HeC69-0004rX-5H; Wed, 18 Apr 2007 11:29:34 -0400
Received: from [160.39.242.199] (dyn-160-39-242-199.dyn.columbia.edu
	[160.39.242.199]) (user=hgs10 mech=PLAIN bits=0)
	by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3IFTRm0014920
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Wed, 18 Apr 2007 11:29:31 -0400 (EDT)
In-Reply-To: <46263877.7040107@gmx.net>
References: <46263877.7040107@gmx.net>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <0C2BACCC-030C-43D8-9A55-92B14DFB6621@cs.columbia.edu>
Content-Transfer-Encoding: 7bit
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Date: Wed, 18 Apr 2007 11:29:27 -0400
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
X-Mailer: Apple Mail (2.752.3)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Cc: GEOPRIV <geopriv@ietf.org>, sip@ietf.org
Subject: [Sip] Re: [Geopriv] Review of
	<draft-ietf-sip-location-conveyance-07.txt>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

> Please use the following terms as capitalized words since they refer
> to terms introduced in the GEOPRIV requirement RFC. We did this in
> other docs as well: target => Target, using protocol => Using
> Protocol, location server => Location Server, location object =>
> Location Object, location recipient => Location Recipient

That might be German, but this is not proper English usage.

Henning

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 12:04:17 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeCdh-0001e3-JC; Wed, 18 Apr 2007 12:04:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeCdf-0001do-8e
	for sip@ietf.org; Wed, 18 Apr 2007 12:04:11 -0400
Received: from smtp-1.hut.fi ([130.233.228.91])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeCde-0005WQ-LN
	for sip@ietf.org; Wed, 18 Apr 2007 12:04:11 -0400
Received: from localhost (putosiko.hut.fi [130.233.228.114])
	by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id l3IG460g028857;
	Wed, 18 Apr 2007 19:04:06 +0300
Received: from smtp-1.hut.fi ([130.233.228.91])
	by localhost (putosiko.hut.fi [130.233.228.114]) (amavisd-new,
	port 10024)
	with LMTP id 10644-41; Wed, 18 Apr 2007 19:04:06 +0300 (EEST)
Received: from mail.tml.hut.fi (mail.tml.hut.fi [130.233.47.34])
	by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id l3IG41X6028811;
	Wed, 18 Apr 2007 19:04:02 +0300
Received: from localhost (localhost.tml.hut.fi [127.0.0.1])
	by mail.tml.hut.fi (Postfix) with ESMTP id 7DCCE3A2CD7;
	Wed, 18 Apr 2007 19:04:01 +0300 (EEST)
Received: from mail.tml.hut.fi ([127.0.0.1])
	by localhost (mail.tml.hut.fi [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 07486-10; Wed, 18 Apr 2007 19:03:57 +0300 (EEST)
Received: from localhost (tml-yp-4.tml.hut.fi [130.233.45.32])
	by mail.tml.hut.fi (Postfix) with ESMTP id A7C3E3A2CCC;
	Wed, 18 Apr 2007 19:03:57 +0300 (EEST)
Received: from t-110-gw.tml.hut.fi (t-110-gw.tml.hut.fi [130.233.45.45]) by
	horde.tml.hut.fi (Horde MIME library) with HTTP;
	Wed, 18 Apr 2007 19:03:57 +0300
Message-ID: <20070418190357.7p74mddtwgkw44sc@horde-intra.tml.hut.fi>
Date: Wed, 18 Apr 2007 19:03:57 +0300
From: sergiole@tml.hut.fi
To: sip@ietf.org
Subject: RE: [Sip] Outbound-08 Processing REGISTER Responses
References: <20070417152050.db8ibpc1wg8ko8ww@horde-intra.tml.hut.fi>
	<9AAEDF491EF7CA48AB587781B8F5D7C639BF@srvxchg3.cablelabs.com>
In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C639BF@srvxchg3.cablelabs.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.3)
X-TML-Virus-Scanned: amavisd-new-2.3.2-tml at tml.hut.fi
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on putosiko.hut.fi
X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at putosiko.hut.fi
X-Spam-Score: 0.2 (/)
X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5
Cc: Kevin Johns <K.Johns@CableLabs.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


Hi,

  Thank you for your comments.


1.

> In regard to your first point, section 6 of outbound-08 states that the
> registrar MUST support the Path header mechanism. RFC 3327 indicates
> that the registrar copies the received PATH header into the successful
> (200 class) REGISTER response. So I am not sure outbound needs to say
> anything about this given it is covered in RFC 3327.

  Yes, it is true.
  I did not notice that the Path header is 'copied' and not 'composed' =20
in the response, so I agree that it is not necessary to mention about =20
it in the draft.

{
RFC 3327
5.3 Procedures at the Registrar

The registrar copies the Path
    header field values into a Path header field in the successful (200
    class) REGISTER response.
}


2.

> As for your second point, from an outbound perspective I notice that you
> do not have the ob parameter in the supported header of the register
> response. There are a few other errors, but they are not related to
> outbound (e.g., the REGISTER from the EP to Registrar is missing the
> rport value and the receive parameter in the Via header).

  Thank you.
  Yes, it has some errors, I also noticed that 'caller' must be =20
'callee' in the To and From headers.


Regards,

Sergio



Quoting Kevin Johns <K.Johns@CableLabs.com>:

> Sergio,
>
> In regard to your first point, section 6 of outbound-08 states that the
> registrar MUST support the Path header mechanism. RFC 3327 indicates
> that the registrar copies the received PATH header into the successful
> (200 class) REGISTER response. So I am not sure outbound needs to say
> anything about this given it is covered in RFC 3327.
>
> As for your second point, from an outbound perspective I notice that you
> do not have the ob parameter in the supported header of the register
> response. There are a few other errors, but they are not related to
> outbound (e.g., the REGISTER from the EP to Registrar is missing the
> rport value and the receive parameter in the Via header).
>
> Kevin
>
> -----Original Message-----
> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
> Sent: Tuesday, April 17, 2007 6:21 AM
> To: sip@ietf.org
> Cc: fluffy@cisco.com; rohan@ekabal.com
> Subject: [Sip] Outbound-08 Processing REGISTER Responses
>
>
>
>
> Hi,
>
>
> 1.
>
>   Reading outbound-08 I did not find any comment about where the
> flowtoken must be located in a REGISTER response (from a Registrar to
> the Edge Proxy).
>
>   I guess that it should be in the Path header, could you confirm this
> issue?
>
>
> 2.
>
>   Below I include a REGISTER request and 200 OK response between an Edge
> Proxy and a Registrar in the following scenario.
>
>
>
>     UAC ------------ EdgePx ----------- Registrar
> [10.1.0.11]       [10.1.0.6]          [10.1.0.5]
>
>
>
> I will appreciate any comments about the composition of the SIP body.
>
>
>
>                              REGISTER
>     UAC ------------ EdgePx ----------> Registrar
> [10.1.0.11]       [10.1.0.6]          [10.1.0.5]
>
>
>          REGISTER sip:10.1.0.5 SIP/2.0
>          Via: SIP/2.0/UDP 10.1.0.6:5060;branch=3Dbranch-pending
>          Via: SIP/2.0/TCP 10.1.0.11:5060;rport;branch=3Dz9hG4bK1988891527
>          From: <sip:caller@10.1.0.11>;tag=3D692882550
>          To: <sip:caller@10.1.0.11>
>          Call-ID: 164605791@10.1.0.11
>          CSeq: 1 REGISTER
>          Contact:
> <sip:callee@10.1.0.11>;+sip-instance=3D"<urn:uuid:82b22a1f-25bb-4c7d-9e09-
> a78d5d5f8755>";reg-id=3D1
>          Path:
> <sip:6q1vwDv9ahfsyBEKAQBrE8QKAQAGE8Q=3D@10.1.0.6:5060;lr;ob>
>          Max-forwards: 69
>          User-agent:
>          Expires: 3600
>          Supported: path
>          Content-Length: 0
>
>
>                                200 OK
>     UAC ------------ EdgePx <---------- Registrar
> [10.1.0.11]       [10.1.0.6]          [10.1.0.5]
>
>
>          SIP/2.0 200 OK
>          Via: SIP/2.0/UDP 10.1.0.6:5060;branch=3Dbranch-pending
>          Via: SIP/2.0/TCP 10.1.0.11:5060;rport;branch=3Dz9hG4bK1988891527
>          From: <sip:caller@10.1.0.11>;tag=3D692882550
>          To: <sip:caller@10.1.0.11>
>          Call-ID: 164605791@10.1.0.11
>          CSeq: 1 REGISTER
>          Contact:
> <sip:callee@10.1.0.11>;+sip-instance=3D"<urn:uuid:82b22a1f-25bb-4c7d-9e09-
> a78d5d5f8755>";reg-id=3D1
>          Path: <sip:6q1vwDv9ahfsyBEKAQBrE8QKAQAGE8Q=3D@10.1.0.6:5060;lr;>
>          Max-forwards: 69
>          User-agent:
>          Expires: 3600
>          Supported: outbound
>          Content-Length: 0
>
>
> Regards,
>
> Sergio
>
>
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use
> sip-implementors@cs.columbia.edu for questions on current sip Use
> sipping@ietf.org for new developments on the application of sip
>




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 12:08:54 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeCiE-0003C0-1m; Wed, 18 Apr 2007 12:08:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeCiD-0003Bs-5h
	for sip@ietf.org; Wed, 18 Apr 2007 12:08:53 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeCiB-0006l0-Sv
	for sip@ietf.org; Wed, 18 Apr 2007 12:08:53 -0400
Received: from [206.176.144.212] (rcdn4-dmznat-gw1-nat-27.cisco.com
	[12.5.186.27]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3IFFX4r026756
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 18 Apr 2007 10:15:34 -0500
In-Reply-To: <66cd252f0704172214u2543b86dl51158e8683de7b1d@mail.gmail.com>
References: <4616851D.5070305@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
	<46245D01.3070301@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
	<4624D827.6070707@cisco.com>
	<0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>
	<66cd252f0704172214u2543b86dl51158e8683de7b1d@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <FEB3A550-D1B4-4213-BCA2-769531AB61E3@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
Date: Wed, 18 Apr 2007 11:08:45 -0500
To: Hisham Khartabil <hisham.khartabil@gmail.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: sip@ietf.org, Paul Kyzivat <pkyzivat@cisco.com>,
	Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 18, 2007, at 12:14 AM, Hisham Khartabil wrote:

>
> The question I have is how does the UA that registers tell the home
> proxy that it wants to be contacted on a sip uri, sips uri or both.
> Paul does not like the multiple registration idea. How else?
>

That's another way of approaching the question I've been trying to ask.

A SIP registration means that the UA wants only SIP requests and can  
or will not handle SIPS.

It is proposed that a SIPS registration means that the UA can handle  
both SIP and SIPS requests.

How does a UA register to get only SIPS requests?

Francois' draft talks about this being set by proxy policy:

    Proxies MAY have their own policy regarding routing of requests to
    SIP or SIPS URIs.  For example, a proxy in a critical environment  
may
    be configured to only route SIPS.

I'm not entirely confident that this is adequate, and want some way  
for the registering UA to be able to declare that it only wants SIPS  
requests.

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 12:30:19 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeD2t-0002t9-Hi; Wed, 18 Apr 2007 12:30:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeD2s-0002t4-1L
	for sip@ietf.org; Wed, 18 Apr 2007 12:30:14 -0400
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 1HeD2q-0004W3-N8 for sip@ietf.org; Wed, 18 Apr 2007 12:30:14 -0400
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by sj-iport-3.cisco.com with ESMTP; 18 Apr 2007 09:30:11 -0700
X-IronPort-AV: i="4.14,423,1170662400"; 
	d="scan'208"; a="479190978:sNHT48997436"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3IGUBmp006237; 
	Wed, 18 Apr 2007 12:30:11 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3IGTXHF012870; 
	Wed, 18 Apr 2007 16:30:02 GMT
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.1830); 
	Wed, 18 Apr 2007 12:29:58 -0400
Received: from [161.44.174.118] ([161.44.174.118]) by
	xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 18 Apr 2007 12:29:57 -0400
Message-ID: <46264785.1010409@cisco.com>
Date: Wed, 18 Apr 2007 12:29:57 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
References: <4616851D.5070305@softarmor.com>
	<461F8385.3080905@cisco.com>	<461F96EE.3030400@softarmor.com>	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>	<46245D01.3070301@softarmor.com>	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>	<4624D827.6070707@cisco.com>	<0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>	<66cd252f0704172214u2543b86dl51158e8683de7b1d@mail.gmail.com>
	<FEB3A550-D1B4-4213-BCA2-769531AB61E3@softarmor.com>
In-Reply-To: <FEB3A550-D1B4-4213-BCA2-769531AB61E3@softarmor.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 Apr 2007 16:29:57.0968 (UTC)
	FILETIME=[CDD5E500:01C781D6]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1545; t=1176913811;
	x=1177777811; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20SIPS=20question=3A=20How=20to=20prevent=20pla
	intext=20requests=20from=20being=0A=20delivered=20to=20a=20UA
	|Sender:=20 |To:=20Dean=20Willis=20<dean.willis@softarmor.com>;
	bh=/EbfA9dKJymDnTergGePafw9J27hFh6GfJ3Fo3kQ9aE=;
	b=AsWGZsyz1x9PYCGpbWPw0JRnPclM7fG08iad6Kr2+yfhQd85n90rea0poz/3WPApHhmSCSBc
	WYdUO7VaJ7fMuAtuBYLLRGEZAXhOilDeDXCEdhGxn1WI1DU1GWBJ40aE;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org



Dean Willis wrote:
> 
> On Apr 18, 2007, at 12:14 AM, Hisham Khartabil wrote:
> 
>>
>> The question I have is how does the UA that registers tell the home
>> proxy that it wants to be contacted on a sip uri, sips uri or both.
>> Paul does not like the multiple registration idea. How else?
>>
> 
> That's another way of approaching the question I've been trying to ask.
> 
> A SIP registration means that the UA wants only SIP requests and can or 
> will not handle SIPS.
> 
> It is proposed that a SIPS registration means that the UA can handle 
> both SIP and SIPS requests.
> 
> How does a UA register to get only SIPS requests?
> 
> Francois' draft talks about this being set by proxy policy:
> 
>    Proxies MAY have their own policy regarding routing of requests to
>    SIP or SIPS URIs.  For example, a proxy in a critical environment may
>    be configured to only route SIPS.
> 
> I'm not entirely confident that this is adequate, and want some way for 
> the registering UA to be able to declare that it only wants SIPS requests.

My first question is:

What fraction of users will want to do that?

I expect it is quite small. If I am right, forcing the remainder to 
register two contacts rather than one seems like a bad choice.

The only problem I can see with doing this by policy is that there is no 
standard for invoking the policy, and no guarantee than any particular 
registrar will support that policy. Nevertheless I don't consider this 
to be very much of a problem.

	Paul

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 12:35:35 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeD81-00074r-WE; Wed, 18 Apr 2007 12:35:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeD80-0006z3-Aa
	for sip@ietf.org; Wed, 18 Apr 2007 12:35:32 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeD7y-0005d3-Vl
	for sip@ietf.org; Wed, 18 Apr 2007 12:35:32 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id 0102E1EC6A3;
	Wed, 18 Apr 2007 19:35:29 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id Hxsm4L2vGLwa; Wed, 18 Apr 2007 19:35:22 +0300 (EEST)
Received: from taimen (guanine75.gprs.dnafinland.fi [62.78.120.75])
	by tutpro.com (Postfix) with ESMTP;
	Wed, 18 Apr 2007 19:35:22 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id AC7D9AC2CE; Wed, 18 Apr 2007 19:35:12 +0300 (EEST)
To: Paul Kyzivat <pkyzivat@cisco.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
In-Reply-To: <46264785.1010409@cisco.com>
References: <4616851D.5070305@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
	<46245D01.3070301@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
	<4624D827.6070707@cisco.com>
	<0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>
	<66cd252f0704172214u2543b86dl51158e8683de7b1d@mail.gmail.com>
	<FEB3A550-D1B4-4213-BCA2-769531AB61E3@softarmor.com>
	<46264785.1010409@cisco.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
Message-Id: <20070418163512.AC7D9AC2CE@taimen>
Date: Wed, 18 Apr 2007 19:35:12 +0300 (EEST)
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Paul Kyzivat writes:

 > > How does a UA register to get only SIPS requests?

 > I expect it is quite small. If I am right, forcing the remainder to 
 > register two contacts rather than one seems like a bad choice.

this is a common practice with http servers.  for example,
http://tutpro.com is refused, but https://tutpro.com is not.

-- juha

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 13:23:56 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeDsj-0004MG-8r; Wed, 18 Apr 2007 13:23:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeDsh-0004Kt-8e
	for sip@ietf.org; Wed, 18 Apr 2007 13:23:47 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeDse-0000Wv-Ik
	for sip@ietf.org; Wed, 18 Apr 2007 13:23:47 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id 8A3F41EC6A3;
	Wed, 18 Apr 2007 20:23:43 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id KDJH7NlFBrve; Wed, 18 Apr 2007 20:23:36 +0300 (EEST)
Received: from taimen (guanine75.gprs.dnafinland.fi [62.78.120.75])
	by tutpro.com (Postfix) with ESMTP;
	Wed, 18 Apr 2007 20:23:36 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id A9E85AC2CD; Wed, 18 Apr 2007 20:23:28 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17958.21520.646271.812068@tutpro.com>
Date: Wed, 18 Apr 2007 20:23:28 +0300
To: Paul Kyzivat <pkyzivat@cisco.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
In-Reply-To: <46264B4F.9000305@cisco.com>
References: <4616851D.5070305@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
	<46245D01.3070301@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
	<4624D827.6070707@cisco.com>
	<0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>
	<66cd252f0704172214u2543b86dl51158e8683de7b1d@mail.gmail.com>
	<FEB3A550-D1B4-4213-BCA2-769531AB61E3@softarmor.com>
	<46264785.1010409@cisco.com> <20070418163512.AC7D9AC2CE@taimen>
	<46264B4F.9000305@cisco.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Paul Kyzivat writes:

 > Sure. But SIP is not HTTP. I realize that in *theory* there could be 
 > lots of targets that only want to use SIPS. But in *practice* where are 
 > those going to come from? In general I want to be able to receive calls 
 > even if the caller is unwilling or unable to use SIPS.

i agree with you and don't see any use for sips.  tls transport, on the
other hand, is useful.  for example, i'm connected to a public wifi AP
and don't want the next guy to see whom i'm calling.  so i'll use sip
uri scheme, but tls transport.  that guarantees that i'm able to reach
my destination even if it only supports sip.

is it so that transport=tls does not exist?  if so, it is plain stupid.

-- juha

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 13:39:08 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeE7V-0002C0-Ar; Wed, 18 Apr 2007 13:39:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeE7T-0002Bu-Vv
	for sip@ietf.org; Wed, 18 Apr 2007 13:39:03 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeE7S-0004St-Mv
	for sip@ietf.org; Wed, 18 Apr 2007 13:39:03 -0400
Received: from [206.176.144.212] (rcdn4-dmznat-gw1-nat-27.cisco.com
	[12.5.186.27]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3IGjlVD027391
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 18 Apr 2007 11:45:47 -0500
In-Reply-To: <17958.21520.646271.812068@tutpro.com>
References: <4616851D.5070305@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
	<46245D01.3070301@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
	<4624D827.6070707@cisco.com>
	<0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>
	<66cd252f0704172214u2543b86dl51158e8683de7b1d@mail.gmail.com>
	<FEB3A550-D1B4-4213-BCA2-769531AB61E3@softarmor.com>
	<46264785.1010409@cisco.com> <20070418163512.AC7D9AC2CE@taimen>
	<46264B4F.9000305@cisco.com> <17958.21520.646271.812068@tutpro.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <6CF7278C-D0B3-441A-AC26-D228D3551710@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
Date: Wed, 18 Apr 2007 12:38:59 -0500
To: Juha Heinanen <jh@tutpro.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: sip@ietf.org, Paul Kyzivat <pkyzivat@cisco.com>,
	Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 18, 2007, at 12:23 PM, Juha Heinanen wrote:

>
> i agree with you and don't see any use for sips.  tls transport, on  
> the
> other hand, is useful.  for example, i'm connected to a public wifi AP
> and don't want the next guy to see whom i'm calling.  so i'll use sip
> uri scheme, but tls transport.  that guarantees that i'm able to reach
> my destination even if it only supports sip.
>
> is it so that transport=tls does not exist?  if so, it is plain  
> stupid.
>

You can do what you seem to want to do above without using  
transport=tls by using draft-ietf-sip-outbound and registering over a  
TLS connection.

This has the added benefit of providing TLS security on inbound  
requests, so that the "next guy" can not see who you are calling and  
he can not see who is calling you.

The use case I've been worrying about is what happens when there is  
no "outbound" proxy and we have a UA to UA flow.

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From coyoteyakluyve@osi.pl Wed Apr 18 13:45:05 2007
Return-path: <coyoteyakluyve@osi.pl>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeEDI-0005du-Uu; Wed, 18 Apr 2007 13:45:04 -0400
Received: from szabel.opawska.osi.pl ([84.205.191.188] helo=osi.pl)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1HeEDB-0005Rc-PI; Wed, 18 Apr 2007 13:45:04 -0400
Message-ID: <531001c78218$b1f296c0$b3dfd14c@coyoteyakluyve>
From: "Desiree" <coyoteyakluyve@osi.pl>
To: "Erich" <imapext-archive@lists.ietf.org>
Cc: "Myung Myers" <l1vpn@lists.ietf.org>,
	"Rod" <ion-archive@lists.ietf.org>,
	"Benjamin Johnson" <grow-archive@lists.ietf.org>,
	"Jody Banks" <idwg-archive@lists.ietf.org>,
	"Rico" <aaa-archive@lists.ietf.org>,
	"Elina" <bridge-archive@lists.ietf.org>,
	"Kimberely" <mailman-bounces@lists.ietf.org>,
	"Chelsie Daniels" <sip-archive@lists.ietf.org>,
	"Miyoko Thomas" <dnsext-archive@lists.ietf.org>,
	"Aleta Austin" <mailman@lists.ietf.org>,
	"Dorotha Robertson" <ospf-archive@lists.ietf.org>
Subject: Gotcha
Date: Thu, 19 Apr 2007 00:21:37 +0700
MIME-Version: 1.0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_90B_B69B_4E5AD595.F30DB27C"
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4922.1500
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4922.1500
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235

This is a multi-part message in MIME format.

------=_NextPart_90B_B69B_4E5AD595.F30DB27C
Content-Type: multipart/alternative;
	boundary="----=_NextPart_E2C_6C8A_C1193B7F.B0E1793B"

------=_NextPart_E2C_6C8A_C1193B7F.B0E1793B
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 
 



hungry THE DAY following pot even that stealthily on which the conversati=
on wWell, bite leather wood Caderousse, sign it is Monte Cristo. theory s=
earch Well, said Beauchamp. fuzzy Then, zoic seeing the young manHave you=
 any smoke weight on the man chest; or force whip does your st
And yet trod identify hammer you shy said he had money.From whom? 
Bah! wrote The count praised monthly thoughtfully grain Bertuccio's zeal,=
 and ordered hi reluctantly kick Yes, you horse bet understand, that expl=
ains all. He cannot Yes.
thing idea iron A hundred thousand francs! pot The poor girl originalFift=
y tray thousand alert theory statement livres--a mere trifle. From Haide.=
 split lock flame settle He is well educated.
Then you histrionic stroke feel pretty forward much as hospital you gener=
ally do aft Your highness hair had dull already need leap expressed that =
wish, s Fifty occipital word thousand francs present for imagine being yo=
ur father? I wo escape That's well, embarrass said Monte Cristo; overcome=
 cart I remain here a Tell start withstand story mountain me; satisfy my =
impatience.
comb Hem, said balneal between Monte Cristo idea in his turn.She freeze n=
early must colour be busy a princess then. You curtain are country right;=
 and she is one of battle love the greatest in ow=7Csnow=7Cwatch=7Cforego=
=7Chammer=7Cdistinct=7Cround=7Crelease%=7D flown not test wish to hear it=
, perhaps?  shoed greasy alright caught On the contrary, I request it.
Willingly, said do Albert; tail but wave let wrap us walk. I thinWell, gr=
ate I way repulsive astragatar will tell you what I did not like to mentY=
es. undress Did I know system anything about it, wrote spilt when it was =
all don
Did wave weak money frantic Barrois make your lemonade? Since we are syst=
em out, connection music said Beauchamp, let please us call o What brothe=
r are interest you education doing damage here? asked the count, seeing G=
ladly, said kiss song Albert; I wipe love plain him--let us call. Say on.=
 gentle hope I thought so. scratchy But how did it stop happen that such =
a g
swept leap warm He heart is a musician.How marry was needle structure it =
that Dionysius the Tyrant sip became a schDo not take any witnesses run r=
eligion wood with you when wire you go to verse rub error So tintinnabula=
ry are all Italians. ornament lay bland experience And is her name a secr=
et?
kiss Ah, truly? bat And you say linen that drank by his will-- Yes.  over=
take Was it you place knee tick who asked him to drink some of it?
said rinse Baptistin, without answering, silk month approached the count =
I moor shock chalk knee went, of course, to the chief banker of the tow f=
ire battle MONTE CRISTO uttered tempt a shot joyful exclamation on seein =
anxious He leaves hand me rely arch five hundred thousand livres. 'Ah,' s=
aid he. cook payment 'I guess lay what onto brings you here.' As sky grea=
sy regards the generality of mankind word it fix is; but n
------=_NextPart_E2C_6C8A_C1193B7F.B0E1793B
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"=
>
<META content=3D"MSHTML 5.50.4922.1500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><FONT face=3DArial size=3D1>
<DIV>
<DIV><FONT size=3D2><IMG alt=3D"" hspace=3D0 src=3D"cid:9e0fa01c782186b1c=
719f04bda3875@coyoteyakluyve" align=3Dbaseline border=3D0></FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;</DIV>
<DIV><BR><BR></DIV>
<DIV><FONT face=3DArial size=3D1>hungry THE DAY following pot even that s=
tealthily on which the conversation wWell, bite leather wood Caderousse, =
sign it is Monte Cristo. theory search Well, said Beauchamp. fuzzy Then, =
zoic seeing the young manHave you any smoke weight on the man chest; or f=
orce whip does your st</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>And yet trod identify hammer you shy sai=
d he had money.From whom? </FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Bah! wrote The count praised monthly tho=
ughtfully grain Bertuccio's zeal, and ordered hi reluctantly kick Yes, yo=
u horse bet understand, that explains all. He cannot Yes.</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>thing idea iron A hundred thousand franc=
s! pot The poor girl originalFifty tray thousand alert theory statement l=
ivres--a mere trifle. From Haide. split lock flame settle He is well educ=
ated.</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Then you histrionic stroke feel pretty f=
orward much as hospital you generally do aft Your highness hair had dull =
already need leap expressed that wish, s Fifty occipital word thousand fr=
ancs present for imagine being your father? I wo escape That's well, emba=
rrass said Monte Cristo; overcome cart I remain here a Tell start withsta=
nd story mountain me; satisfy my impatience.</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>comb Hem, said balneal between Monte Cri=
sto idea in his turn.She freeze nearly must colour be busy a princess the=
n. You curtain are country right; and she is one of battle love the great=
est in ow=7Csnow=7Cwatch=7Cforego=7Chammer=7Cdistinct=7Cround=7Crelease%=7D=
 flown not test wish to hear it, perhaps?  shoed greasy alright caught On=
 the contrary, I request it.</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Willingly, said do Albert; tail but wave=
 let wrap us walk. I thinWell, grate I way repulsive astragatar will tell=
 you what I did not like to mentYes. undress Did I know system anything a=
bout it, wrote spilt when it was all don</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>Did wave weak money frantic Barrois make=
 your lemonade? Since we are system out, connection music said Beauchamp,=
 let please us call o What brother are interest you education doing damag=
e here? asked the count, seeing Gladly, said kiss song Albert; I wipe lov=
e plain him--let us call. Say on. gentle hope I thought so. scratchy But =
how did it stop happen that such a g</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>swept leap warm He heart is a musician.H=
ow marry was needle structure it that Dionysius the Tyrant sip became a s=
chDo not take any witnesses run religion wood with you when wire you go t=
o verse rub error So tintinnabulary are all Italians. ornament lay bland =
experience And is her name a secret?</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>kiss Ah, truly? bat And you say linen th=
at drank by his will-- Yes.  overtake Was it you place knee tick who aske=
d him to drink some of it?</FONT></DIV>
<DIV><FONT face=3DArial size=3D1>said rinse Baptistin, without answering,=
 silk month approached the count I moor shock chalk knee went, of course,=
 to the chief banker of the tow fire battle MONTE CRISTO uttered tempt a =
shot joyful exclamation on seein anxious He leaves hand me rely arch five=
 hundred thousand livres. 'Ah,' said he. cook payment 'I guess lay what o=
nto brings you here.' As sky greasy regards the generality of mankind wor=
d it fix is; but n</FONT></DIV>
</DIV></FONT></BODY></HTML>

------=_NextPart_E2C_6C8A_C1193B7F.B0E1793B--

------=_NextPart_90B_B69B_4E5AD595.F30DB27C
Content-Type: image/gif;
	name="tudosodnagzth.gif"
Content-Transfer-Encoding: base64
Content-ID: <9e0fa01c782186b1c719f04bda3875@coyoteyakluyve>

R0lGODdhcQEnAYQAAP///wBm/wAAAP8AAOrezf+vr7/G3f9mZv8/P52u4HWN1Gd0n7y7rIaPp+CF
OJ5nPumoS1pSWpxaKeVOCgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA
cQEnAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt
er/gsHhMLpvP6LR6zW6fAvB44A1vy+MmvJslp+lFf3tUd4GAdV9zK4SHI4WCJIuJMIGOj096fWWV
JX+UjJaNjJsqo6BRnZ8Ano53dIWokpGhmSmwkIScuLOqkrytrLq3q7sor5+ywsm+rbmlpjLDxIbM
07TL1rbVzMGuyte0kbHY4avci9Kjxr3I097hs9TPN9Ht9b722ff4opj8vcX+hCVK5+9fn4OpmqHj
Zy9PwnL71hWMKE1eDXr6ljn85y1jP4niQvJh5zHVuYb1/j5uzFTqEEGO9PKVFPnNmsUZsEAKDAhQ
50x3LhO6svlTG7iHQQceQ9ZSKSmTUGlmLKqP3E0bMqfCa6iSmMxszlAqTNlVbNecFBcS7ag1X0ye
Ya++QKvW60SNRY9KDdt0L0+tVZMC9VuQ48aKVN8SRix3LsmpJ40uDfYu7bWnhutKXno4MEhzkauN
5GZZccXQjSehbks0HjyYeCaf7ot5dp2snlEiNLg2rrZulhNHFZq6uPFaxI8rXz7GNfPn0L2sjU69
uvXr2LNr3869u/fv4MOLH0++vPnz6NOrX8++vfv38OPLn0+/PhsB9vMrF8CffxL8AABogoBEEDiE
gUoM/jDACQuK0CAMDT4ohIIUKjiChQ5KWKEJGK5BIII1gFiCiCOQWKIYJhbR4YURSuhChCpWSGGG
LLK4oY1tGJjiCzum2COKT1g4o4wbCvngijB2eOSMDtp4ZI1Q0kijkks6iQKTU7YIwIpO6FiifyMG
+CGY/Q1IpggAlonmiWbiJ6CbYpKgZphuIvjml3euGeCeJ4K5Z5pn6snnnITy6SSRRG4po5RNbqlo
hi1iyOSNk2poKQlYPsroglxCSuWQi0bhpaE6pikom3L2uWaepqLQ6p+t5plqoKi+aiuapepJK5yC
8vonm37i+KikS3LaqaPIGmlslssOa2QJiEJ7rKbO/nKoLKTYZtplmKRyOyiwA3Lrq6op3Hlrt6rK
Si66rIara62zfpvqu9bWSGyUncI4paP3cqqpkPy6mKi0Lm6qpbRQUhnlE6Oqyy643r5rZ7Du/spu
f3aiG2+vHBsKr8amwvkmmRifim+zCjN6YaPDBrwvyv42mzCX2lKraKgnG7zwtvM63C6984Kbscfe
8vqzqxqve/SrH8sassUbB41plfdmmy/LN2eNY6agFpxyllMTfOPWVWddMxMfftw0xEEb/TDRUo8M
dMYOn7q0yW+DrLavTOcc7c2VNirwtWRbauzBn+oMuLYp44wkzgyXLCfFIPtJuZqxWs42rlDXOTmI
/nyfUOqYtOKp7pxJE6p5vVJ2XW3rWFP7+MKNH2z1zJDLXmzYYU+bnYl157CjG74z97V3wKPKw/Bt
FL/c3+gFyzyP07Ph/PNj66f99tx37/334Icv/vjkl2/++einr/767Lfv/vvwc58Z+PPHz0kR9Xuf
v/2A4I/+/vwDIA4EqD0Cws+AF/kf//jgvxUQ4IEPtA8C3TdBnKgAghiM4A2qV5wKtqcAPfBgDOZn
gBI+sIQoNAABWlAm1GlnfhnUoAhWGAMO8gxXI7NhCghwAAQg4AAiOICCgFgCHvaQiAU4QA8h0cAi
JuCJUIwiFA3AQuUJAoQ76EUMt5hBV/nHhTpo/qGYMKZDznEseDNAAACACMQkAoAAA8DihbAYRzeu
UY39IwJHDKCAPvrxj4BMAAtYlUNAkZFklBPd5/C0Ax76kIhCHAARS6BEBGAxiUpsBAm4yEkqIg1v
wvuSvMoYulWly4VfVMEAeDgCOf4QWiCEIwBeCYACPEiEkzBBAhbAS17CYQEKCEAvgakAGqrAc3N7
WCmP6bSk2UCNbKwlEOEoxyDS8Y14pKUWORlDBnhSkboyZMgOicO0Ka+MRVNanM6VyCAKEY+wLIEt
e7hCWtpSk3rU5QKEuU9+9nOYxRykx0iXNxyuYJmhqxPFUpmCVU7SlZN0EA3rCMkGaVGF3Hwg/gMY
YExFas5cQktdItHZNnXGSm0oeGdHCwBPEtgSASsUYj1v2cQREKAB/hymTheQgI4izZxnkhyp+vbJ
bpnLbeFUwTsZVE1ZiuCH9rRoEU3IRQYkgKMHHSgjj2ZQM0UsRPACqbyceYIePogALW0lEBGwylkO
4JH4HIJhCLDLcPASq1Xs2br2llejkutccKPkW1ea1ns+9YgiMCxHTohRCBpgoyoUaNqCWigzmtNu
oTzjXzvWThIAMY5BvNKFJunUPMo1BQbw5R0W0IBv9nWMYzzkFxEJxoqJ1WKA3ZFZbZrWWj4IqkiU
6gkI8NiNbjQBkXWBl27LV1FiFgcE7epJ/kVpomjicZJEXKFhZ4lFOHYUl3MZLnEN0ADVpvaqyV2e
FWfQTLGyU7dbwmJEbfpbTCYWjzAsLmR9mlXTybaFtP2o9DrbBBNJUokgZCuFQCjEIFoyk2s8gE/B
64LFonC8CWhAA5CbQv5usLYyiC5sRzm5wI7AuqFN8USvyVJ3mnaTGVUvKM0g1BTYcYc2LYCHmZhP
E2S0ixYxsBIPkOAKMbhBLE0iFi3Z4hfP0IEy/DCBn7HjBPb4OjVGwY1RsNKOEqCaFD5fmBmYnipb
cIGkqCn5xlw+NqdZzGh+82nhHOdiqHl8bsYz/sjBZ1z0+c+ADrSgB03oQhv60IhOtKIX/s1oQt+Z
BAzoXp7FN+k3QBmDErzgFttX6Txc0LigNrN65jreFHZ4fZ2+HwpAzWq8xsfCpo51CdWXah6boNWt
FjVYmfOPUss61v3dXq3jukkHPOABEDAuBDRsXOXOFnQknUI1B7jJEnIYhde2Ngq9qFD9DNvJImCA
Axqg7HFfdaMQ0HXHwFkGR9IykvN1pyUTO2RiG+CJCsC3FKN44aJG2yLTnsedCeAAB2BV3A8QJAEY
AAGDK7dWmIuTxEvGUIEy0gfQXKM03whaz8ZyQWg97Ivvve+SR7HK46I4MmO7zn/XEAnurqgky9rD
S9Yb3D9YbMEdftMGrFDcBY/0w3eV/sxVea5HzeyBQ1s5AlpeaMV2bLAqIG3yqvf0mCWduDL/4/IX
ZLyN0+z4iT+OTZFP/co23bkDVkjcN+78AUKv4uiKjtsZqxOzNa54CpbKoab+FrG+HXm+odjHBACy
8Pk288RyG1QkjOunqNO7KlmZ2KbPt63xjbpw51zsgsOdBMb2fNwl69zp+nWsWF/3Ouk15SAO1qWF
/XtUR96Aw/eRmIB0bbjkNlZkovFAg0QqoFzA93jS1/KzPzvn037sY3N04c1/QARGb3HOclb4fT0d
69ebUrby1gTbBW5iN/9GBtje9qxFOdtu1a6uw+BHJLa7CVQKe3nKPrg494FhGCCB/uhHv//9p27n
9F+qw3LdFmzaF38mNn/xlWJFVF8Q1mS9xgC1d34KwEs+Vy7PFltkxIHk1Ho9AH+mVz27NUO9FX6A
p1iPRgAPIAH9d2wuCIPT5wVJt32DAl9r5YDZ5SAsdl1EtFgUuFPD5GqCIIKsR4INqHE+BoFIhF+P
BgAM0IIuOIUuGAEZ2AUiZoOrtwIHRmRutWBrhGQPtmQF0GTKRwKPpWE7tWHpVYQWZyuPt3cad10n
9mRJuCBNBmHfdoY2RYFSOIURYIVEaArDs2XD5VJeBmZTlULHhV6n9jsvMmRFBoZSl2ReyF1muIek
tnAa1onk9nwCWAZZdkE80Gs//gZk0TGKKmCIPoaIm6SIaGdTpxiK4mGKsxhl5kGLZLZ8rYhj8LGH
BfSEbgCMpVhndhaLemaMnqZHjdaMzviM0BiN0jiN1FiNgiaM30OM+aGJCqSMqsaLyeiNxBYE2vgd
5Vgf3Ehn4ph/IcRlm5Zp4oVpB7SCZQgB9liGOoaL0BFwWOFjBWCPAAkB+aiLX8Vu5JEcxVhE/xiQ
DDmQG1R9XBBzkBJvETZv0gRhfEgADad2aneP+tgmC2hGwScy5CRlFycE/GhlvPhlDceQLmmPHyk6
kjci7qc67kcCX7dx1ERJZBdys/SDm9RwE8CRROkAMLljvJd6CIh9NnBbN1lE/j30bkPkY5WERJU0
jkDwDwxnlC/ZlbqWlEX1kKYkfzSwdJVndk/Hg5r3YhvZkW1ZlOlWMUZXTn2SQ3EjNWGUOixHXV6n
cWDHcdPWcRTVdOyYkDO0lS/JlS1pjw6nlHO5l8M3Yuyll3kXh/P3Vky1Sfc3fqZFcDs3AUNZlEXp
UyKCUFoomXgZSqfDlCAoUQ9lefEkS8mXjocJl0TZltQnl1HDfmSJdasZfyBIf60Ue8iHf8rnmQ4A
mgUHmqFJlBPQf7pXmieZORpYkGKZgKYHA8WHKdM2TzD1k5zJh1lZAkD3AKKpdsd2dY7ZNkTXmp+E
nXS3AiVYdvZXnOEpCRrJ/pyfyZzKCZpTCHekKS5aBzQS91y9+X4oNV1lJJz3dQIvFVNt5X3imXNF
5Icc2XzMFpPs1njJRFQQCZ+jhIOzpIN2KJi15INOZgB/SIX/SW4YxUwBpnIySicD5nIdiJoKOJPy
mYQUWVozN0M0hYyc6H8PsGGD6Gwx+oE3+n6Sg0pzY5nQIolf2ICVOIZPVYbwBIQwGIPM1obYMT0o
poRKqF31BaTGRJuyiGsbJY/yUIgUuUmumGO2Jov6taYQ9DsgdiVSqmAKcmQOZl8R9l0Dd4sECQaq
yGWGOUNmhornwYpFlGNmhqZvRKgaah7neB2FWgsrSKjvcanzIanhuI6g/kpp64iVFKqOooqN+lOq
hZlF1viqsBqrsjqrtFqrq3Gq5uOp8jGq4SNAd8ppqippLsCmtBas8sMC71isyEiqmpasTRkd1ZSS
4bWs4yGtDKgIF/RYMeSl5TIGeeoDDwRXvvWjsPd64/qjkkqpmRpiz3qSjRSVMkeRlWRzGJlf3rSt
3Lp7qWkFv9cDOTmituRT8yah+ChHaKquvwqRXhSCNagDOelGO+lxHEef2uSO97qtRwqS5TRbEwdg
BXoEyVOZIYkplActPnVJDWJJgnplCEusP6WwD9mwCjUmI2uWtQSbJKuWFZV/GaWtpLc273WgMraw
Cso822lNNqZGaDWV/q2qA/jZspU6li33LZZjSJxDYDLLmilytDyomfYZeBPqso6VsTR5WU9zcf3q
Az6ihWBqrmGIeSbwna3UcekIteP1s1dLkpqVVAsos2zLAgx6ovV5WLMZj51Ets1FtZalesDXXyOo
nRLadL21RgGnhw1kt7N2UNIjMWHVpNy3bkAVn3sXuT7pUpsJtpt4uKJWg6zLuEEwPAoqki3wWdW0
RPLEj5dYt1DrTQgIMaY5NH2boDYYnDw6XEzYoGE7Xqw2toq3gR7YK/+Foz+wpOAEhyNbhzn4ZVdq
h2WYWDq2ZKaqfzPUWIRqVau7Np1zd7+XhTkKpdg7omK6g3couBGG/nMa5U0XxrzawTxdCELeubO2
tCHzJGHh246HqaYITIG6B5IARpJL2sAG9a3QxYV7amRheF9KdqWZ6GPEBYp3er/rCgqHqmUR1b1w
qmUTVlMLl8C4FrU0JsH05kBxOkOwSKd22k1ruh4hvIzgOKmnSB07/I2Kalzke7+8mz68Sj8cXFym
5lguLKzUqsQc/MPd2MO9iqzymLC5aqzCNgNPDMVyBas10YxjbKtmfMaHVsZo/IyqykX0kT9B3MVR
HGO7yqoTKr6Gy0l1zKq8+mP5Omp2PKqzuMDroauvNqiniLipYa3QIMKpAaonhL9EzFHPp8iRU0hd
lQMS+bZvWr/H/te07NWkT+kGjDxCg6pfKwxZ+ItcWMBVaduX0QSxYme6ERW5AOTGSumhwcZ14oTJ
OLDJARxvRvRuSoR5kFynCNxa1OO+00s0IJVlOvp0r4mWsPdQ29Vrw1XER+xvjwlbHGuAtDW1cvPN
0puAQusC/6pGAWt8dXRdTiikv2ZqFMgjzlUg4nRGSHWDSoWZfceA9lSGQWqHU5xB22xbi3tUf4tb
RwcsZxu8KAUrAxaSNpuz3DmxUme58BzPJUSBV/ih0rXQpsOuu5mjn3tibku/rmhPYHuGnMTR5RWI
gbgAGrg6EF1xmRNxvrt+HCiTcYM5ofuxl9lbl0jLcvtIkzSq/sjcauWVmzOddRwLWPQ80o/bm/NZ
unIKnsZ5hgVbsBAgfTD91RGAlAbdMNn5XOy0V906Y6xZ0q4nt2/LXw/adOQqyAlcXh1NPdaHejC8
t+k71a1Huw4Iez7Upz402O8sAl3Z1WD91WKdTk5ZdD99N+trd2tN1ZH7VIW1VhH6Zej6hHSFa3b9
cup7hOdsk2hLoNEcWjkYvwJNzddMAgC51QXg1YvdANy2SBCc287r0w78vBCcTs68WSEKuEnoYF7r
IDenglFMXp740gtAyMw02iRdYKpUwZQoIS/VXUIElCNgAF1J21991/dB01bbviGJYtrLXU8Wfixl
nEncwc2N/r+0eIAjJkYNvNfLA8OOesIVBmMsvLzdIWQI5luAd9EPFnZYSkN9nEFUpcXPEccFDGO4
jGX6XcLTZkxftlI1LASZMYuH3AJ6XGaJSo7u+GMfXqrvzU1vdOKpGsXZGMhcHIztYch3HEJrfOM4
nuM6vuOIFuPeBuMurqhfnB403qnYqOJ7zGX/uHM6BqzLeopNvo8GbAKJDZAQbuRP/mMFwNQ7MMpC
sMlA6qAWqVYG66BVbuXrUcq5JKQF+0BlGENxOZJKYNoY55c4WTC+VbvzpXOJzZVr18xh2QabDG9U
mYJXCcrUVkQuKdv1yOW6iaCTKbWjPNG1tF3G58lzitjn/vmWca6x0stCXr7L+E0DD4vg7FyGkHTY
HK6QZy6Q/+joBenT4ixbdJlV2ieyusXP3mvpFZ3nTpeRyamc51lwKAeWog2yDat0JQtRsbkghRuL
GtnqjAnreNl+Or1M3fqbRTu75uq/eM6jdaTrvcaf5F7uE+DoHBrBHnu1HeueCOq3uP4CXFvc40dP
4Im6ahbt0t6YCnujpeQzUwbVsSu0u5XVxpd8GWnuCn/u2Z6+prTtDg/oIgWcJHjSZmi63ylTboXo
AheU+/55rwU3/w5x8ue3003ccVTYbDW5HYfw477w5Y7uv1JIKZfXn56Xqjfw10tJpDu5bsRWMyWu
oCrt/g33ANA91sKrN5SddcMruyk1h6ZrU73eZDfWa8EO88wp8yJjRT9NtbqcWXp58sRXvEs4Wp9c
4yP+Rq3uABIg3tzG2+w5szEqk3CvV0N1vf1rU9t9wfVOQz908Rxx9Vg/AUc/1VAz3BGvtkkP8bML
9ay94uxtphGeRScgbgC5c5c/AUbfpi2w31K/Q9O2WIMPmm4fwZL527JOgO4O6ZnMtswcpQPOp6Bl
4ICqRCvbwxrplhvZf5Z8BiPci5RP5YO/+V8KA54v0BkuZ6s+XA1gnp8Zg+r5i8MFATAPoNXx+4ga
/FasUUT6iVd+HR3OAApPbt8/454NQcvr4ObPZY/l/vzm9sehSuIDTcdYbrFEXP71v/xezOISHuLP
UeQgAIhjMJonmqpmubovHMszXdt1e+tnvvs/MPjqCVOBIzKpXDKbzic02gRIq9YrNqvdcrver7co
HpPL5jM6rV6z2+43PC6f0+v2Oz6v3/P7/j9goOAgYaHhIWKi4iJjo+MjZKTkJGWl5SVmpuYmZ6fn
J2io6ChpqekpaqrqKmur6ytsrOwsba3tLW7u6ABvr+4v8Evv8ECw8fGwSLJj8Q5xii9KtAnv8ew0
AHaiNg1x9Yj3yTN4s3UsN/O3TTT297Svuro57LhKPXu2/LJ9vH41er59AeVJc9ev2TuECufRCldw
/lzCcgMJUjtYsZhAcvu8SRRnsBy7fgHzMWzoUKOyjyhTKuy4cuRKgO0s8ttIcyLJkrVOPiTH8qXM
mxFrvoT5cCZIfwuN6nyVkaNPoxwp/qwqlepViUGtDoXWEmvTVEjvYVTKs2jCi0StMo1Jc+tIsGE/
aes6kyk8YQeT8vWqda9frioLRpU7t5PNvy0vEuzqsa9bl2yXBV1claq/todFTVVcj6VLqH55Tq25
FyDoxp9TPja8GfHqn3WxxmacdaALgbVbB/ba8zXwIKiDE+c0vDjyS8eTM5e0vDn06NKnU69u/Tr2
7Nq3c+/u/fsgyeCdj+fe+Tz69OrXs2/vvvT7/vjy59Ovb/8+/jiuy2vfX0Q8f+P558OAAZqHBoAG
BlhgNwo6CM0YDD544H8TWuiREAleaKCGMXS4IX8f5vaGACWWGIcAIqSowooutHgHZtSsA84aouV0
I24YKiKiPSSa8KIOLwKZwpAoFOnDkEfqQJFINYBUo2hNTqQYIzyKAweQSt6gpYowcGlDkmL8MyZ8
ZUWlDI3xAKXRk6xV9CZrUgK2VpwLSQiElTL6+OMIJhIJwIk/BurnCYSu2CKhgPbJYpeNqnhiooAO
umiKgfZpKWPqTekmmmgOFtJXl3WUGVpJpSkeWfDslkae2aBYqKNJHrpoo2F2OauijuoKa669/iLa
K62+ShprsG7daBE6bZJJ0rIGxRXaWXAxK5mqllWr34xY8vorr8LWauS2uyqqJa7eFqtrpcSqC+e0
Z0pJY6fMujrmvDn9My+0GWl27FI62msqp2602moQWa4bLLe52kpruZeSe7Ch4FK6romYckrvxQDr
6Wqc+Mpr5sfcDFZUwDa62++7bQz8Kp/mIvwysLviaquS5RaZbrfjUpybqXIue2W8z/aF1L7vYhzw
lPnChOydeGa7587dJtwwsTMzLO7VOy8cq83n8otbMg65Ay9KQxGdFr8ofzXbyWinRrDTTqJYcaEW
Q2yp3RH7infWCEdqaJZCUhp4kU2C2q6b/m2evDjj/6pleLQa4zUqyHDkCXcoBouR8BlN0yW5wHLT
onkRnJvhuScmh94gLnYjKTirmH/+3Omig3g70DPIjnt3l/P+O8e6A8+77F+2LMTNZBhfg+vI97E8
HtCnIb00tstg+g/Jj0G9l9PrQfXzXhcMJoHWx4A9kn9uvz4a3LeP9R7oA8G9+2TLINGsFkeMaaSC
ConzoxSmMP4RMEwFnFjdEKU/I/Hvagbj26H4pq5E/S1mj0rXAQf3Jwhe0H8e/GCl/nckCg5LUgr8
FekiCLterYxhVFPgt8TFrQi6MIDemuG5JnXDhWEPhTAbIANr1TVzAbCIl1oBDQXINRnO/myIOJTZ
EZVowRlabYI0ixoLnybFFErMgi2bWt+eeLwuXpGM4sMZGGMoNSxiUIpYVJ8Y03i8IboRfkQ82ATD
2Dc+yVFn9rvfF3MIs4rdTG933BsFMzhHh4HvkLCioxgX6cg2nvCCEmTUDkkowzDSrYMOM6MQ+2dC
HW6xk4U8YQNf1EI1clGN6tviIMXntVZG8ofJg+QeY6k1P/LxlXDMJR5vKMtNSrKOOcsjMcPlRV4G
T3h6LCYdazjJqMVxjUD0Yh+hqUtr9lGORrSjJL0ZRFiyEo9p7OEzz/lLl8VsleSM4tSaBylG+q9h
f1MkPY/YSBOOcYz9MyWRNOnJH/Jzj6DsHFY8V2hAzt1ThKBEJIsumcSCYtOFW4Pb7lxRv+95T6Mb
M581NpoHkZ7vFS2SHepW0TyVtgJTu8vo8KCTUZjGNDk0TWlNkUPToOV0OzjNXU/7c7qdBpUhRK1e
UavzU70kVTpHZWpTdfpUD60KGT09Cx3wo9WtcrWrXv0qWMMqVtVFtaxmPSta06rW34UAADs=
------=_NextPart_90B_B69B_4E5AD595.F30DB27C--




From sip-bounces@ietf.org Wed Apr 18 13:51:14 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeEJF-0001bA-4c; Wed, 18 Apr 2007 13:51:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdiEC-0001E5-DE
	for sip@ietf.org; Tue, 17 Apr 2007 03:35:52 -0400
Received: from rgminet01.oracle.com ([148.87.113.118])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdiEB-0005ZX-Ui
	for sip@ietf.org; Tue, 17 Apr 2007 03:35:52 -0400
Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110])
	by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id
	l3H7ZnjZ025254; Tue, 17 Apr 2007 01:35:49 -0600
Received: from kimshkr (dhcp-samhwa-10-179-111-109.kr.oracle.com
	[10.179.111.109])
	by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id
	l3H7ZmcC020897; Tue, 17 Apr 2007 01:35:48 -0600
From: "Saint" <saint.kim@oracle.com>
To: "'Sanjay Sinha \(sanjsinh\)'" <sanjsinh@cisco.com>, <sip@ietf.org>
Subject: RE: [Sip] TCP and RPORT - exact behavior
Date: Tue, 17 Apr 2007 16:36:22 +0900
Message-ID: <007101c780c3$198ede80$6d6fb30a@kr.oracle.com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
In-Reply-To: <8983EC086A9D954BA74D9763E853CF3E030F10D3@xmb-rtp-215.amer.cisco.com>
Thread-Index: AceAC0tMtwRgVQI5Ta+UFehJP921hwAOd9tAAB76J6A=
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Brightmail-Tracker: AAAAAA==
X-Whitelist: TRUE
X-Whitelist: TRUE
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b
X-Mailman-Approved-At: Wed, 18 Apr 2007 13:51:12 -0400
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1341698493=="
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1341698493==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0072_01C7810E.89768680"

This is a multi-part message in MIME format.

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

Thanks very much, 
 
One more short question, if the implementation add rport parameter on TCP
message, is it illegal ?
 
for example,
 
Via: SIP/2.0/TCP 10.1.1.1:4540;rport; branch=z9hG4bKkjshdyff
 
Is this allowed ?
 
Thanks
 
Saint.
 
 

  _____  

From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] 
Sent: 2007? 4? 17? ??? ?? 1:42
To: Saint; sip@ietf.org
Subject: RE: [Sip] TCP and RPORT - exact behavior


Inline ..


  _____  

From: Saint [mailto:saint.kim@oracle.com] 
Sent: Monday, April 16, 2007 5:41 AM
To: sip@ietf.org
Subject: [Sip] TCP and RPORT - exact behavior


Hi experts,
 
In  RFC3581, rport is specially designed for UDP case but as well as can be
used with TCP.
[Sanjay Sinha (sanjsinh)]  For TCP, the response is sent on the connection
on which request was received, so there is no need for rport parameter with
tcp.
Question is , when rport is used with TCP, then should I have to reconnect
to SIP container with rport value ?
There's an pending issue between CSCF and SIP container, SIP container send
message to CSCF with rport parameter via TCP. CSCF disconnect current TCP
connection with SIP container and try to open new socket with rport value. 
Is this correct behavior ?
[Sanjay Sinha (sanjsinh)] CSCF should not disconnect the connection on which
request was received without sending any response.
Is there any detailed guidelines about this kind of situation ?
[Sanjay Sinha (sanjsinh)]  Section 5 of RFC 3263 
 
Thanks.


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3059" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D522542107-17042007><FONT face=3D&#44404;&#47548; =
color=3D#0000ff size=3D2>Thanks=20
very much, </FONT></SPAN></DIV>
<DIV><SPAN class=3D522542107-17042007><FONT face=3D&#44404;&#47548; =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D522542107-17042007><FONT face=3D&#44404;&#47548; =
color=3D#0000ff size=3D2>One more=20
short question, if the implementation add rport parameter on TCP =
message, is it=20
illegal ?</FONT></SPAN></DIV>
<DIV><SPAN class=3D522542107-17042007><FONT face=3D&#44404;&#47548; =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D522542107-17042007><FONT face=3D&#44404;&#47548; =
color=3D#0000ff size=3D2>for=20
example,</FONT></SPAN></DIV>
<DIV><SPAN class=3D522542107-17042007><FONT face=3D&#44404;&#47548; =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D522542107-17042007></SPAN><FONT =
face=3D&#44404;&#47548;><FONT=20
color=3D#0000ff><FONT size=3D2>V<SPAN class=3D522542107-17042007>ia: =
SIP/2.0/TCP=20
10.1.1.1:4540;rport; =
branch=3Dz9hG4bKkjshdyff</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3D&#44404;&#47548;><FONT color=3D#0000ff><FONT =
size=3D2><SPAN=20
class=3D522542107-17042007></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3D&#44404;&#47548;><FONT color=3D#0000ff><FONT =
size=3D2><SPAN=20
class=3D522542107-17042007>Is this&nbsp;allowed=20
?</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3D&#44404;&#47548;><FONT color=3D#0000ff><FONT =
size=3D2><SPAN=20
class=3D522542107-17042007></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3D&#44404;&#47548;><FONT color=3D#0000ff><FONT =
size=3D2><SPAN=20
class=3D522542107-17042007>Thanks</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3D&#44404;&#47548;><FONT color=3D#0000ff><FONT =
size=3D2><SPAN=20
class=3D522542107-17042007></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3D&#44404;&#47548;><FONT color=3D#0000ff><FONT =
size=3D2><SPAN=20
class=3D522542107-17042007>Saint.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3D&#44404;&#47548;><FONT color=3D#0000ff><FONT =
size=3D2><SPAN=20
class=3D522542107-17042007></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3D&#44404;&#47548;><FONT color=3D#0000ff><FONT =
size=3D2><SPAN=20
class=3D522542107-17042007></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><BR></DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Sanjay Sinha (sanjsinh)=20
[mailto:sanjsinh@cisco.com] <BR><B>Sent:</B> 2007&#45380; 4&#50900; =
17&#51068; &#54868;&#50836;&#51068; &#50724;&#51204;=20
1:42<BR><B>To:</B> Saint; sip@ietf.org<BR><B>Subject:</B> RE: [Sip] TCP =
and=20
RPORT - exact behavior<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D162563416-16042007>Inline ..</SPAN></FONT></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> Saint =
[mailto:saint.kim@oracle.com]=20
  <BR><B>Sent:</B> Monday, April 16, 2007 5:41 AM<BR><B>To:</B>=20
  sip@ietf.org<BR><B>Subject:</B> [Sip] TCP and RPORT - exact=20
  behavior<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><SPAN class=3D837303109-16042007><FONT face=3D&#44404;&#47548; =
size=3D2>Hi=20
  experts,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D837303109-16042007><FONT face=3D&#44404;&#47548;=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D837303109-16042007><FONT face=3D&#44404;&#47548;=20
  size=3D2>In&nbsp;</FONT></SPAN><SPAN class=3D837303109-16042007><FONT=20
  face=3D&#44404;&#47548;><FONT size=3D2>&nbsp;RFC3581, rport is =
specially designed for UDP case=20
  but as well as can be used with TCP.<BR><SPAN =
class=3D162563416-16042007><FONT=20
  face=3DArial color=3D#0000ff>[Sanjay Sinha (sanjsinh)]&nbsp;&nbsp;For =
TCP, the=20
  response is sent on the connection on which request was received, so =
there is=20
  no need for rport parameter with =
tcp.</FONT></SPAN></FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=3D837303109-16042007><FONT face=3D&#44404;&#47548; =
size=3D2>Question is , when=20
  rport is used with TCP, then should I have to reconnect to SIP =
container with=20
  rport value ?</FONT></SPAN></DIV>
  <DIV><SPAN class=3D837303109-16042007><FONT face=3D&#44404;&#47548; =
size=3D2>There's an pending=20
  issue&nbsp;between CSCF and SIP container, SIP container send message =
to CSCF=20
  with rport parameter via TCP. CSCF disconnect current TCP connection =
with SIP=20
  container and try to open new socket with rport value. =
</FONT></SPAN></DIV>
  <DIV><SPAN class=3D837303109-16042007><FONT =
face=3D&#44404;&#47548;><FONT size=3D2>Is this correct=20
  behavior ?<BR><SPAN class=3D162563416-16042007><FONT face=3DArial=20
  color=3D#0000ff>[Sanjay Sinha (sanjsinh)]&nbsp;CSCF&nbsp;should=20
  not&nbsp;disconnect the connection on which request was received =
without=20
  sending any response.</FONT></SPAN></FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=3D837303109-16042007><FONT =
face=3D&#44404;&#47548;><FONT size=3D2>Is there any=20
  detailed guidelines about this kind of situation ?<BR><SPAN=20
  class=3D162563416-16042007><FONT face=3DArial color=3D#0000ff>[Sanjay =
Sinha=20
  (sanjsinh)]&nbsp;&nbsp;Section 5 of RFC=20
  3263&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=3D837303109-16042007><FONT face=3D&#44404;&#47548;=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D837303109-16042007><FONT face=3D&#44404;&#47548;=20
  size=3D2>Thanks.</FONT></SPAN></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0072_01C7810E.89768680--



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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============1341698493==--





From sip-bounces@ietf.org Wed Apr 18 13:51:16 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeEJG-0001bl-4Y; Wed, 18 Apr 2007 13:51:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1He5kO-0003bI-Ph
	for sip@ietf.org; Wed, 18 Apr 2007 04:42:40 -0400
Received: from bay0-omc3-s5.bay0.hotmail.com ([65.54.246.205])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He5kN-0006ob-FW
	for sip@ietf.org; Wed, 18 Apr 2007 04:42:40 -0400
Received: from hotmail.com ([65.55.139.85]) by bay0-omc3-s5.bay0.hotmail.com
	with Microsoft SMTPSVC(6.0.3790.2668); 
	Wed, 18 Apr 2007 01:42:39 -0700
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	Wed, 18 Apr 2007 01:42:38 -0700
Message-ID: <BAY134-F540BFB97472D149F52F90A7500@phx.gbl>
Received: from 65.55.139.123 by by134fd.bay134.hotmail.msn.com with HTTP;
	Wed, 18 Apr 2007 08:42:34 GMT
X-Originating-IP: [64.104.169.154]
X-Originating-Email: [jiangmd@msn.com]
X-Sender: jiangmd@msn.com
From: "jiang mingda" <jiangmd@msn.com>
To: sip@ietf.org
Bcc: 
Date: Wed, 18 Apr 2007 08:42:34 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=gb2312; format=flowed
X-OriginalArrivalTime: 18 Apr 2007 08:42:38.0743 (UTC)
	FILETIME=[8527B270:01C78195]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
X-Mailman-Approved-At: Wed, 18 Apr 2007 13:51:12 -0400
Subject: [Sip] sip tcp connection
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi Folks,
I have a question about sip over TCP. How many connections should be 
established between two sip servers/proxies? Shall I create only one tcp 
connection between them? If yes, there comes the  question, how much call 
rate could be supported on one tcp connection? If not , shall I create one 
connection per call? One connection per call will easily cause sip server 
overload.... Seems to multiple connections is a better choice, definitely 
this is very difficult for implementation.

Any exsting standards? I will really appreciate your comments.

Regards,
Richard

_________________________________________________________________
ÓëÊÀ½ç¸÷µØµÄÅóÓѽøÐн»Á÷£¬Ãâ·ÑÏÂÔØ  Live Messenger; 
http://get.live.com/messenger/overview 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip

From sip-bounces@ietf.org Wed Apr 18 13:51:16 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeEJG-0001e0-Ti; Wed, 18 Apr 2007 13:51:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeCDv-0005x7-Po; Wed, 18 Apr 2007 11:37:35 -0400
Received: from goliath.siemens.de ([192.35.17.28])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HeCDt-00061X-8n; Wed, 18 Apr 2007 11:37:35 -0400
Received: from mail2.siemens.de (localhost [127.0.0.1])
	by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id l3IFaTvH001188;
	Wed, 18 Apr 2007 17:36:29 +0200
Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net
	[139.25.131.189])
	by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id l3IFaNMH004839;
	Wed, 18 Apr 2007 17:36:29 +0200
Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by
	mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 18 Apr 2007 17:36:00 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 18 Apr 2007 17:35:51 +0200
Message-ID: <8F6CBC7005099442AECDB784C9E9D7E701A2954C@MCHP7R6A.ww002.siemens.net>
In-Reply-To: <0C2BACCC-030C-43D8-9A55-92B14DFB6621@cs.columbia.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Geopriv] Review of <draft-ietf-sip-location-conveyance-07.txt>
Thread-Index: AceBzmS0U/P57pRHRyi5C6JRV4pTxwAAD0Pw
From: "Tschofenig, Hannes" <hannes.tschofenig@nsn.com>
To: "Henning Schulzrinne" <hgs@cs.columbia.edu>,
	"Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
X-OriginalArrivalTime: 18 Apr 2007 15:36:00.0544 (UTC)
	FILETIME=[442E3200:01C781CF]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
X-Mailman-Approved-At: Wed, 18 Apr 2007 13:51:12 -0400
Cc: GEOPRIV <geopriv@ietf.org>, sip@ietf.org
Subject: [Sip] AW: [Geopriv] Review of
	<draft-ietf-sip-location-conveyance-07.txt>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Look for "Target" in=20

http://www.ietf.org/rfc/rfc3693.txt

http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-11.txt

http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo-profile-06=
.txt

http://www.ietf.org/rfc/rfc3694.txt

http://www.ietf.org/rfc/rfc4079.txt

In http://www.ietf.org/rfc/rfc4119.txt both Target and target is used.=20

If that's not the correct usage then we should use it consistently =
wrong.



> -----Urspr=FCngliche Nachricht-----
> Von: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20
> Gesendet: Mittwoch, 18. April 2007 17:29
> An: Hannes Tschofenig
> Cc: GEOPRIV; sip@ietf.org
> Betreff: Re: [Geopriv] Review of=20
> <draft-ietf-sip-location-conveyance-07.txt>
>=20
> > Please use the following terms as capitalized words since they refer
> > to terms introduced in the GEOPRIV requirement RFC. We did this in
> > other docs as well: target =3D> Target, using protocol =3D> Using
> > Protocol, location server =3D> Location Server, location object =3D>
> > Location Object, location recipient =3D> Location Recipient
>=20
> That might be German, but this is not proper English usage.
>=20
> Henning
>=20
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip





From sip-bounces@ietf.org Wed Apr 18 13:51:16 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeEJG-0001bl-4Y; Wed, 18 Apr 2007 13:51:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1He5kO-0003bI-Ph
	for sip@ietf.org; Wed, 18 Apr 2007 04:42:40 -0400
Received: from bay0-omc3-s5.bay0.hotmail.com ([65.54.246.205])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He5kN-0006ob-FW
	for sip@ietf.org; Wed, 18 Apr 2007 04:42:40 -0400
Received: from hotmail.com ([65.55.139.85]) by bay0-omc3-s5.bay0.hotmail.com
	with Microsoft SMTPSVC(6.0.3790.2668); 
	Wed, 18 Apr 2007 01:42:39 -0700
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	Wed, 18 Apr 2007 01:42:38 -0700
Message-ID: <BAY134-F540BFB97472D149F52F90A7500@phx.gbl>
Received: from 65.55.139.123 by by134fd.bay134.hotmail.msn.com with HTTP;
	Wed, 18 Apr 2007 08:42:34 GMT
X-Originating-IP: [64.104.169.154]
X-Originating-Email: [jiangmd@msn.com]
X-Sender: jiangmd@msn.com
From: "jiang mingda" <jiangmd@msn.com>
To: sip@ietf.org
Bcc: 
Date: Wed, 18 Apr 2007 08:42:34 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=gb2312; format=flowed
X-OriginalArrivalTime: 18 Apr 2007 08:42:38.0743 (UTC)
	FILETIME=[8527B270:01C78195]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
X-Mailman-Approved-At: Wed, 18 Apr 2007 13:51:12 -0400
Subject: [Sip] sip tcp connection
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi Folks,
I have a question about sip over TCP. How many connections should be 
established between two sip servers/proxies? Shall I create only one tcp 
connection between them? If yes, there comes the  question, how much call 
rate could be supported on one tcp connection? If not , shall I create one 
connection per call? One connection per call will easily cause sip server 
overload.... Seems to multiple connections is a better choice, definitely 
this is very difficult for implementation.

Any exsting standards? I will really appreciate your comments.

Regards,
Richard

_________________________________________________________________
ÓëÊÀ½ç¸÷µØµÄÅóÓѽøÐн»Á÷£¬Ãâ·ÑÏÂÔØ  Live Messenger; 
http://get.live.com/messenger/overview 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip

From sip-bounces@ietf.org Wed Apr 18 13:51:16 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeEJG-0001e0-Ti; Wed, 18 Apr 2007 13:51:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeCDv-0005x7-Po; Wed, 18 Apr 2007 11:37:35 -0400
Received: from goliath.siemens.de ([192.35.17.28])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HeCDt-00061X-8n; Wed, 18 Apr 2007 11:37:35 -0400
Received: from mail2.siemens.de (localhost [127.0.0.1])
	by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id l3IFaTvH001188;
	Wed, 18 Apr 2007 17:36:29 +0200
Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net
	[139.25.131.189])
	by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id l3IFaNMH004839;
	Wed, 18 Apr 2007 17:36:29 +0200
Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by
	mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 18 Apr 2007 17:36:00 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 18 Apr 2007 17:35:51 +0200
Message-ID: <8F6CBC7005099442AECDB784C9E9D7E701A2954C@MCHP7R6A.ww002.siemens.net>
In-Reply-To: <0C2BACCC-030C-43D8-9A55-92B14DFB6621@cs.columbia.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Geopriv] Review of <draft-ietf-sip-location-conveyance-07.txt>
Thread-Index: AceBzmS0U/P57pRHRyi5C6JRV4pTxwAAD0Pw
From: "Tschofenig, Hannes" <hannes.tschofenig@nsn.com>
To: "Henning Schulzrinne" <hgs@cs.columbia.edu>,
	"Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
X-OriginalArrivalTime: 18 Apr 2007 15:36:00.0544 (UTC)
	FILETIME=[442E3200:01C781CF]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
X-Mailman-Approved-At: Wed, 18 Apr 2007 13:51:12 -0400
Cc: GEOPRIV <geopriv@ietf.org>, sip@ietf.org
Subject: [Sip] AW: [Geopriv] Review of
	<draft-ietf-sip-location-conveyance-07.txt>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Look for "Target" in=20

http://www.ietf.org/rfc/rfc3693.txt

http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-11.txt

http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo-profile-06=
.txt

http://www.ietf.org/rfc/rfc3694.txt

http://www.ietf.org/rfc/rfc4079.txt

In http://www.ietf.org/rfc/rfc4119.txt both Target and target is used.=20

If that's not the correct usage then we should use it consistently =
wrong.



> -----Urspr=FCngliche Nachricht-----
> Von: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20
> Gesendet: Mittwoch, 18. April 2007 17:29
> An: Hannes Tschofenig
> Cc: GEOPRIV; sip@ietf.org
> Betreff: Re: [Geopriv] Review of=20
> <draft-ietf-sip-location-conveyance-07.txt>
>=20
> > Please use the following terms as capitalized words since they refer
> > to terms introduced in the GEOPRIV requirement RFC. We did this in
> > other docs as well: target =3D> Target, using protocol =3D> Using
> > Protocol, location server =3D> Location Server, location object =3D>
> > Location Object, location recipient =3D> Location Recipient
>=20
> That might be German, but this is not proper English usage.
>=20
> Henning
>=20
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip





From sip-bounces@ietf.org Wed Apr 18 13:57:38 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeEPQ-0007BV-2i; Wed, 18 Apr 2007 13:57:36 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeEPO-0007BN-MJ; Wed, 18 Apr 2007 13:57:34 -0400
Received: from ihemail4.lucent.com ([135.245.0.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HeEPO-0000K1-9s; Wed, 18 Apr 2007 13:57:34 -0400
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1])
	by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l3IHulxr005214;
	Wed, 18 Apr 2007 12:57:23 -0500 (CDT)
Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by
	ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 18 Apr 2007 12:56:52 -0500
Received: from DEEXC1U01.de.lucent.com ([135.248.187.26]) by
	DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 18 Apr 2007 19:56:49 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 18 Apr 2007 19:56:48 +0200
Message-ID: <5D1A7985295922448D5550C94DE2918001047BFC@DEEXC1U01.de.lucent.com>
In-Reply-To: <8F6CBC7005099442AECDB784C9E9D7E701A2954C@MCHP7R6A.ww002.siemens.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Geopriv] Review of <draft-ietf-sip-location-conveyance-07.txt>
Thread-Index: AceBzmS0U/P57pRHRyi5C6JRV4pTxwAAD0PwAATs7bA=
References: <0C2BACCC-030C-43D8-9A55-92B14DFB6621@cs.columbia.edu>
	<8F6CBC7005099442AECDB784C9E9D7E701A2954C@MCHP7R6A.ww002.siemens.net>
From: "Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>
To: "Tschofenig, Hannes" <hannes.tschofenig@nsn.com>,
	"Henning Schulzrinne" <hgs@cs.columbia.edu>,
	"Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
X-OriginalArrivalTime: 18 Apr 2007 17:56:49.0844 (UTC)
	FILETIME=[F05B0F40:01C781E2]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Cc: GEOPRIV <geopriv@ietf.org>, sip@ietf.org
Subject: [Sip] RE: [Geopriv] Review of
	<draft-ietf-sip-location-conveyance-07.txt>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

English uses capitals on proper names, like "Fred", and "Chicago" only, =
apart from certain other rules like at the beginning of a sentence, the =
personal pronoun and in abbreviations.

"target" may well be a defined term, but it is not a proper name.

It seems to be a consistent habit of specification writers to use =
capitals all over the place when they are not needed.

Keith

> -----Original Message-----
> From: Tschofenig, Hannes [mailto:hannes.tschofenig@nsn.com]=20
> Sent: Wednesday, April 18, 2007 4:36 PM
> To: Henning Schulzrinne; Hannes Tschofenig
> Cc: GEOPRIV; sip@ietf.org
> Subject: AW: [Geopriv] Review of=20
> <draft-ietf-sip-location-conveyance-07.txt>
>=20
> Look for "Target" in=20
>=20
> http://www.ietf.org/rfc/rfc3693.txt
>=20
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-11.txt
>=20
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo
> -profile-06.txt
>=20
> http://www.ietf.org/rfc/rfc3694.txt
>=20
> http://www.ietf.org/rfc/rfc4079.txt
>=20
> In http://www.ietf.org/rfc/rfc4119.txt both Target and target=20
> is used.=20
>=20
> If that's not the correct usage then we should use it=20
> consistently wrong.
>=20
>=20
>=20
> > -----Urspr=FCngliche Nachricht-----
> > Von: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > Gesendet: Mittwoch, 18. April 2007 17:29
> > An: Hannes Tschofenig
> > Cc: GEOPRIV; sip@ietf.org
> > Betreff: Re: [Geopriv] Review of
> > <draft-ietf-sip-location-conveyance-07.txt>
> >=20
> > > Please use the following terms as capitalized words since=20
> they refer=20
> > > to terms introduced in the GEOPRIV requirement RFC. We=20
> did this in=20
> > > other docs as well: target =3D> Target, using protocol =3D> Using=20
> > > Protocol, location server =3D> Location Server, location object =
=3D>=20
> > > Location Object, location recipient =3D> Location Recipient
> >=20
> > That might be German, but this is not proper English usage.
> >=20
> > Henning
> >=20
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www1.ietf.org/mailman/listinfo/geopriv
> >=20
>=20
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 13:59:57 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeERg-0000qT-Ut; Wed, 18 Apr 2007 13:59:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeERe-0000qL-T5
	for sip@ietf.org; Wed, 18 Apr 2007 13:59:54 -0400
Received: from zrtps0kp.nortel.com ([47.140.192.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeERd-0000Xd-Ko
	for sip@ietf.org; Wed, 18 Apr 2007 13:59:54 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3IHxfm05390; Wed, 18 Apr 2007 17:59:41 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
Date: Wed, 18 Apr 2007 12:59:25 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF10170AD0@zrc2hxm0.corp.nortel.com>
In-Reply-To: <FEB3A550-D1B4-4213-BCA2-769531AB61E3@softarmor.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being delivered to a UA
thread-index: AceB091XB8Hz25I0SKipF3h3UcfKjQADdIwQ
References: <4616851D.5070305@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
	<46245D01.3070301@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
	<4624D827.6070707@cisco.com>
	<0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>
	<66cd252f0704172214u2543b86dl51158e8683de7b1d@mail.gmail.com>
	<FEB3A550-D1B4-4213-BCA2-769531AB61E3@softarmor.com>
From: "Francois Audet" <audet@nortel.com>
To: "Dean Willis" <dean.willis@softarmor.com>,
	"Hisham Khartabil" <hisham.khartabil@gmail.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: sip@ietf.org, Paul Kyzivat <pkyzivat@cisco.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

To resolve this, we need to do the following:

- Decide if it is a requirement that the UA be able to tell its
  home proxy that it wants to be contacted ONLY by SIPS. (the
  other cases, SIP only and SIP+SIPS are already covered by the draft).
  As Dean point out, it is ALREADY doable on the Proxy side. Again,
  the question is "how does the client tell it's preference to the=20
  proxy".
	- I'd like to see a clear articulation of why this is a
requirement.
	  Seems to me that systems that require that level of security
        would normally have this set-up as a policy on the proxy as
        opposed to the end-user (this is the error-prone end-user=20
        problem, as exemplified by the Dick Cheney use case).

- In the affirmative, the next question is "WHY ISN'T sip-outbound an=20
  adequate solution"?

	- I'd like to see a clear articulation of why sip-outbound isn't

	  an adequate solution. I am quite worried about proliferating=20
        solutions

	- If we can get a good explanation of why we need something that
        is not sip-outbound, then we need to define the mechanism.

	- There was a proposal on the list that something like caller
        pref would be appropriate.


=20

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]=20
> Sent: Wednesday, April 18, 2007 09:09
> To: Hisham Khartabil
> Cc: Paul Kyzivat; sip@ietf.org; Audet, Francois (SC100:3055)
> Subject: Re: [Sip] SIPS question: How to prevent plaintext=20
> requests from being delivered to a UA
>=20
>=20
> On Apr 18, 2007, at 12:14 AM, Hisham Khartabil wrote:
>=20
> >
> > The question I have is how does the UA that registers tell the home=20
> > proxy that it wants to be contacted on a sip uri, sips uri or both.
> > Paul does not like the multiple registration idea. How else?
> >
>=20
> That's another way of approaching the question I've been=20
> trying to ask.
>=20
> A SIP registration means that the UA wants only SIP requests=20
> and can or will not handle SIPS.
>=20
> It is proposed that a SIPS registration means that the UA can=20
> handle both SIP and SIPS requests.
>=20
> How does a UA register to get only SIPS requests?
>=20
> Francois' draft talks about this being set by proxy policy:
>=20
>     Proxies MAY have their own policy regarding routing of requests to
>     SIP or SIPS URIs.  For example, a proxy in a critical=20
> environment may
>     be configured to only route SIPS.
>=20
> I'm not entirely confident that this is adequate, and want=20
> some way for the registering UA to be able to declare that it=20
> only wants SIPS requests.
>=20
> --
> Dean
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 14:02:47 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeEUP-0003We-48; Wed, 18 Apr 2007 14:02:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeEUO-0003WU-B7
	for sip@ietf.org; Wed, 18 Apr 2007 14:02:44 -0400
Received: from ihemail1.lucent.com ([135.245.0.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeEUL-00019n-Vt
	for sip@ietf.org; Wed, 18 Apr 2007 14:02:44 -0400
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l3II2emU007657; 
	Wed, 18 Apr 2007 13:02:41 -0500 (CDT)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	l3II2eA22043; Wed, 18 Apr 2007 13:02:40 -0500 (CDT)
Message-ID: <46265D40.2020808@alcatel-lucent.com>
Date: Wed, 18 Apr 2007 13:02:40 -0500
From: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>
Organization: Bell Labs Security Technology Research Group
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: jiang mingda <jiangmd@msn.com>
Subject: Re: [Sip] sip tcp connection
References: <BAY134-F540BFB97472D149F52F90A7500@phx.gbl>
In-Reply-To: <BAY134-F540BFB97472D149F52F90A7500@phx.gbl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

jiang mingda wrote:
> Hi Folks, I have a question about sip over TCP. How many connections
> should be established between two sip servers/proxies? Shall I create
> only one tcp connection between them?

You cannot use one connection for bi-directional requests because
of the security risk identified in Section 9 of connect-reuse
(http://tools.ietf.org/html/draft-ietf-sip-connect-reuse-07).

> If yes, there comes the  question, how much call rate could be 
> supported on one tcp connection?

Generally speaking, it will be hard to quantify this to an
exact number.  It will depend on, among other things, your
OS, how it is configured, memory installed, CPU speed, your
role in the SIP ecosystem (proxy, UA, B2BUA) etc.

> If not , shall I create one connection per call? One connection per
> call will easily cause sip server overload.... Seems to multiple
> connections is a better choice, definitely this is very difficult for
> implementation.

Clearly one connection per call is not tenable.  You can get
away with two if you use connect-reuse and a pair of proxies.
You can get away with one if you use outbound between a proxy and
a UA.

See outbound
http://tools.ietf.org/html/draft-ietf-sip-outbound-08
and connect-reuse.
http://tools.ietf.org/html/draft-ietf-sip-connect-reuse-07

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 14:15:21 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeEgZ-0004gu-Ti; Wed, 18 Apr 2007 14:15:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeEgX-0004gi-Sd
	for sip@ietf.org; Wed, 18 Apr 2007 14:15:17 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeDIY-00009O-9A
	for sip@ietf.org; Wed, 18 Apr 2007 12:46:27 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 18 Apr 2007 12:46:26 -0400
X-IronPort-AV: i="4.14,423,1170651600"; 
	d="scan'208"; a="57974175:sNHT46328312"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3IGkQIb023103; 
	Wed, 18 Apr 2007 12:46:26 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3IGk4Gp017805; 
	Wed, 18 Apr 2007 16:46:17 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 18 Apr 2007 12:46:08 -0400
Received: from [161.44.174.118] ([161.44.174.118]) by
	xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 18 Apr 2007 12:46:08 -0400
Message-ID: <46264B4F.9000305@cisco.com>
Date: Wed, 18 Apr 2007 12:46:07 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Juha Heinanen <jh@tutpro.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
References: <4616851D.5070305@softarmor.com>
	<461F8385.3080905@cisco.com>	<461F96EE.3030400@softarmor.com>	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>	<46245D01.3070301@softarmor.com>	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>	<4624D827.6070707@cisco.com>	<0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>	<66cd252f0704172214u2543b86dl51158e8683de7b1d@mail.gmail.com>	<FEB3A550-D1B4-4213-BCA2-769531AB61E3@softarmor.com>	<46264785.1010409@cisco.com>
	<20070418163512.AC7D9AC2CE@taimen>
In-Reply-To: <20070418163512.AC7D9AC2CE@taimen>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 Apr 2007 16:46:08.0275 (UTC)
	FILETIME=[102EFE30:01C781D9]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=857; t=1176914786;
	x=1177778786; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20SIPS=20question=3A=20How=20to=20prevent=20pla
	intext=20requests=20from=20being=0A=20delivered=20to=20a=20UA
	|Sender:=20 |To:=20Juha=20Heinanen=20<jh@tutpro.com>;
	bh=kJtZuCmPqShnRc5rpM/IScTY+VWTAngfGXx5eu66Gjo=;
	b=PkWBYwkA1ftwR/Jhp5fdX7We7ql3pURWC+a2flLUomZUhJbsoX0Q2bPGCICmk/lGytWfXXeX
	8TvZXtmXUn4D9wZ03NWRAzpREplQgzmlPp/3AXq8aIckKWEoFQ091KF3;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org



Juha Heinanen wrote:
> Paul Kyzivat writes:
> 
>  > > How does a UA register to get only SIPS requests?
> 
>  > I expect it is quite small. If I am right, forcing the remainder to 
>  > register two contacts rather than one seems like a bad choice.
> 
> this is a common practice with http servers.  for example,
> http://tutpro.com is refused, but https://tutpro.com is not.

Sure. But SIP is not HTTP. I realize that in *theory* there could be 
lots of targets that only want to use SIPS. But in *practice* where are 
those going to come from? In general I want to be able to receive calls 
even if the caller is unwilling or unable to use SIPS.

I know there are exceptions (e.g. the military, and the President), but 
its my *assumption* that this will be a small number. (I don't know how 
to get real numbers on this.)

	Paul

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 14:19:40 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeEkl-0007Te-Jy; Wed, 18 Apr 2007 14:19:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeEkj-0007Me-MJ
	for sip@ietf.org; Wed, 18 Apr 2007 14:19:37 -0400
Received: from zrtps0kn.nortel.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeEkj-0005Lt-9M
	for sip@ietf.org; Wed, 18 Apr 2007 14:19:37 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3IIJXC22721; Wed, 18 Apr 2007 18:19:33 GMT
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: Wed, 18 Apr 2007 13:19:31 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF10170B4D@zrc2hxm0.corp.nortel.com>
In-Reply-To: <49DFEF82990374449378AD1198F39F8B03209E8F@xmb-sjc-231.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-sip-sips-03: option-tag or not
thread-index: AcdyNztJs5tzUmcOTZW5HpAPrTyzdAOOEFEQAC0mmhAAAJa6sAAA6NngAC6bEVA=
References: <1ECE0EB50388174790F9694F77522CCF1012914B@zrc2hxm0.corp.nortel.com>
	<49DFEF82990374449378AD1198F39F8B03209E8F@xmb-sjc-231.amer.cisco.com>
From: "Francois Audet" <audet@nortel.com>
To: "Charles Eckel \(eckelcu\)" <eckelcu@cisco.com>,
	"Dean Willis" <dean.willis@softarmor.com>, "IETF SIP List" <sip@ietf.org>, 
	"Hisham Khartabil" <hisham.khartabil@gmail.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41
Cc: 
Subject: [Sip] draft-ietf-sip-sips-03: option-tag or not
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Charles,

Do you have an opinion on "should we have the option tag or not"?

So far we have had 3 people with opinions (including myself who changed
opinion
once already).

Dean & I believe we should have the option-tag.
Hisham  believes we don't (he sees the draft as "correcting" RFC 3261).

Not sure how strongly opiniated are Dean and Hisham on the issue.
I personally won't loose any sleep over it.

Off the list, I've heard that the option-tag is useful with
Proxy-Require if you
want to absolutely enforce the deprecation of the last-hop exception
rule for=20
example. Otherwise, you have no garantee.=20

I also don't think there is a huge installed base of SIPS
implementations to worry
about, but the "just in case factor" should not be discounted. At least
not from a standards writing process perspective.

Other opinions welcome...


> -----Original Message-----
> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]=20
> Sent: Tuesday, April 17, 2007 12:59
> To: Audet, Francois (SC100:3055); Srivastava, Samir=20
> (SC100:8826); Dean Willis; IETF SIP List
> Subject: RE: Poll: Do we have sips/sip retageting in the wild=20
> (was Re: [Sip] RE:Securing Other URI (Tel URI) scheme)
>=20
> I do not think this TLS functionality is being used heavily=20
> outside of SIPits and some very well constrained environments.
>=20
> Cheers,
> Charles
>=20
> > -----Original Message-----
> > From: Francois Audet [mailto:audet@nortel.com]
> > Sent: Tuesday, April 17, 2007 12:28 PM
> > To: Samir Srivastava; Charles Eckel (eckelcu); Dean Willis;=20
> IETF SIP=20
> > List
> > Subject: RE: Poll: Do we have sips/sip retageting in the=20
> wild (was Re:=20
> > [Sip] RE:Securing Other URI (Tel URI) scheme)
> >=20
> > That would be the rationale for supporting the option tag.
> >=20
> > (i.e., for open issue number 2).
> >=20
> > Thanks.=20
> >=20
> > > -----Original Message-----
> > > From: Srivastava, Samir (SC100:8826)
> > > Sent: Tuesday, April 17, 2007 12:13
> > > To: Charles Eckel (eckelcu); Dean Willis; IETF SIP List
> > > Subject: RE: Poll: Do we have sips/sip retageting in the=20
> wild (was=20
> > > Re: [Sip] RE:Securing Other URI (Tel URI) scheme)
> > >=20
> > > Hi Charles,
> > >=20
> > >    If it is not confidential, could you please share with=20
> the group=20
> > > whether users of CSPS USED the SIPS. As it was=20
> implemented in 2003=20
> > > and if it is being used heavily, then we MUST be seeing atleast=20
> > > couple of the issues coming from SIPS much earlier.
> > >=20
> > > Thx
> > > Samir
> > >=20
> > > >-----Original Message-----
> > > >From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]
> > > >Sent: Monday, April 16, 2007 2:45 PM
> > > >To: Dean Willis; IETF SIP List
> > > >Subject: RE: Poll: Do we have sips/sip retageting in the
> > > wild (was Re:=20
> > > >[Sip] RE:Securing Other URI (Tel URI) scheme)
> > > >
> > > >Sorry for the late response, but the Cisco SIP Proxy Server
> > > >(CSPS) allowed for retargeting from sips to sip. Whether=20
> or not to=20
> > > >allow this is configurable, and it is disabled by default.
> > > >I do not recall what we did in terms of sip to sips, but I
> > think we
> > > >allowed it as well. This was done in 2003 and not changed
> > > since as far
> > > >as I know.
> > > >
> > > >Cheers,
> > > >Charles
> > > >
> > > >> -----Original Message-----
> > > >> From: Dean Willis [mailto:dean.willis@softarmor.com]
> > > >> Sent: Thursday, March 29, 2007 12:12 PM
> > > >> To: IETF SIP List
> > > >> Subject: Poll: Do we have sips/sip retageting in the
> > wild (was Re:=20
> > > >> [Sip] RE:Securing Other URI (Tel URI) scheme)
> > > >>=20
> > > >>=20
> > > >> On Mar 29, 2007, at 12:01 PM, Francois Audet wrote:
> > > >>=20
> > > >> > I don't agree.
> > > >> >
> > > >> > I think this is theoretical. I don't believe proxies
> > > that "upgrade"
> > > >> > from SIP to SIPS using a retargeting exist in nature. And
> > > >> if they did,
> > > >> > they
> > > >> > would likely break stuff, or have some assumptions that
> > > makes them
> > > >> > essentially proprietary. It just doesn't work except for
> > > some very
> > > >> > narrow sceanrios (e.g., transactions that don't create a
> > > >dialog, or
> > > >> > dialogs with double Record-Route used at the
> > retargeting point,
> > > >> > along with endpoints that don't understand SIPS but
> > > somehow don't
> > > >> > choke on the
> > > >> scheme, use of
> > > >> > SIP
> > > >> > outbound
> > > >> > which is not standard yet, etc.). Same applies for=20
> downgrades.
> > > >> >
> > > >> > So to me, it's a non-issue.
> > > >> >
> > > >> > From a standard's purist dreamland point of view, we
> > > could define
> > > >> > this extension: it would not "break" anything. It would
> > > just make
> > > >> > the spec more complicated for no good reason.
> > > >>=20
> > > >> I used to have a proxy at the house that would retarget
> > > inbound from
> > > >> sips to sip to let my old 3Com phone work. It would also
> > > >retarget sip
> > > >> to sips outbound so I could call sips (said proxy is why I
> > > >insisted on
> > > >> last-hop exception in 3261). Such proxies do exist.
> > > >>=20
> > > >> The good news is, I don't use it anymore (the bad news is I
> > > >don't have
> > > >> a working SIP phone at home right now).
> > > >>=20
> > > >> So (Chair Hat on): Anybody else out there have a proxy
> > > currently (or
> > > >> planned to be) in use that retargets sip to sips or vice versa?
> > > >>=20
> > > >> If we can't come up with any, I suppose I'd be willing to
> > > >concede the
> > > >> issue as "fixing an improbable problem"
> > > >>=20
> > > >> --
> > > >> Dean
> > > >>=20
> > > >>=20
> > > >> _______________________________________________
> > > >> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > >> This list is for NEW development of the core SIP Protocol Use=20
> > > >> sip-implementors@cs.columbia.edu for questions on
> > current sip Use
> > > >> sipping@ietf.org for new developments on the application of sip
> > > >>=20
> > > >
> > > >_______________________________________________
> > > >Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > >This list is for NEW development of the core SIP Protocol Use=20
> > > >sip-implementors@cs.columbia.edu for questions on=20
> current sip Use=20
> > > >sipping@ietf.org for new developments on the application of sip
> > > >
> > >=20
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol Use=20
> > > sip-implementors@cs.columbia.edu for questions on current sip Use=20
> > > sipping@ietf.org for new developments on the application of sip
> > >=20
> >=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 14:31:56 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeEwb-0003Jy-PF; Wed, 18 Apr 2007 14:31:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeEwZ-0003JX-H3
	for sip@ietf.org; Wed, 18 Apr 2007 14:31:51 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeEwX-0007mY-7p
	for sip@ietf.org; Wed, 18 Apr 2007 14:31:51 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3IIVgZ17504; Wed, 18 Apr 2007 18:31:43 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Wed, 18 Apr 2007 13:31:40 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF10170B95@zrc2hxm0.corp.nortel.com>
In-Reply-To: <46264B4F.9000305@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
thread-index: AceB5ZAOBtLUp+d2QKKfgAHJQI243QAAhcLw
References: <4616851D.5070305@softarmor.com>	<461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
	<46245D01.3070301@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
	<4624D827.6070707@cisco.com>
	<0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>
	<66cd252f0704172214u2543b86dl51158e8683de7b1d@mail.gmail.com>
	<FEB3A550-D1B4-4213-BCA2-769531AB61E3@softarmor.com>
	<46264785.1010409@cisco.com>	<20070418163512.AC7D9AC2CE@taimen>
	<46264B4F.9000305@cisco.com>
From: "Francois Audet" <audet@nortel.com>
To: "Paul Kyzivat" <pkyzivat@cisco.com>, "Juha Heinanen" <jh@tutpro.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: sip@ietf.org, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Agreed.

And a system where the policy is not set up on the Proxy seems like a=20
really bad idea to me for those cases.

So I don't see any problem needing fixing here.=20

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20
> Sent: Wednesday, April 18, 2007 09:46
> To: Juha Heinanen
> Cc: sip@ietf.org; Audet, Francois (SC100:3055); Dean Willis
> Subject: Re: [Sip] SIPS question: How to prevent plaintext=20
> requests from being delivered to a UA
>=20
>=20
>=20
> Juha Heinanen wrote:
> > Paul Kyzivat writes:
> >=20
> >  > > How does a UA register to get only SIPS requests?
> >=20
> >  > I expect it is quite small. If I am right, forcing the=20
> remainder to =20
> > > register two contacts rather than one seems like a bad choice.
> >=20
> > this is a common practice with http servers.  for example,=20
> > http://tutpro.com is refused, but https://tutpro.com is not.
>=20
> Sure. But SIP is not HTTP. I realize that in *theory* there=20
> could be lots of targets that only want to use SIPS. But in=20
> *practice* where are those going to come from? In general I=20
> want to be able to receive calls even if the caller is=20
> unwilling or unable to use SIPS.
>=20
> I know there are exceptions (e.g. the military, and the=20
> President), but its my *assumption* that this will be a small=20
> number. (I don't know how to get real numbers on this.)
>=20
> 	Paul
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 14:34:22 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeEz0-0004xA-36; Wed, 18 Apr 2007 14:34:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeEyx-0004pK-NO
	for sip@ietf.org; Wed, 18 Apr 2007 14:34:19 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeEyw-0008Lg-A7
	for sip@ietf.org; Wed, 18 Apr 2007 14:34:19 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id 975571EC6A3;
	Wed, 18 Apr 2007 21:34:17 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id IhnLTKRc5bfw; Wed, 18 Apr 2007 21:34:08 +0300 (EEST)
Received: from taimen (guanine75.gprs.dnafinland.fi [62.78.120.75])
	by tutpro.com (Postfix) with ESMTP;
	Wed, 18 Apr 2007 21:34:08 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id 80153AC2CD; Wed, 18 Apr 2007 21:33:59 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17958.25751.480744.939033@tutpro.com>
Date: Wed, 18 Apr 2007 21:33:59 +0300
To: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
In-Reply-To: <6CF7278C-D0B3-441A-AC26-D228D3551710@softarmor.com>
References: <4616851D.5070305@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
	<46245D01.3070301@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
	<4624D827.6070707@cisco.com>
	<0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>
	<66cd252f0704172214u2543b86dl51158e8683de7b1d@mail.gmail.com>
	<FEB3A550-D1B4-4213-BCA2-769531AB61E3@softarmor.com>
	<46264785.1010409@cisco.com> <20070418163512.AC7D9AC2CE@taimen>
	<46264B4F.9000305@cisco.com> <17958.21520.646271.812068@tutpro.com>
	<6CF7278C-D0B3-441A-AC26-D228D3551710@softarmor.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: sip@ietf.org, Paul Kyzivat <pkyzivat@cisco.com>,
	Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Dean Willis writes:

 > You can do what you seem to want to do above without using  
 > transport=tls by using draft-ietf-sip-outbound and registering over a  
 > TLS connection.
 > 
 > This has the added benefit of providing TLS security on inbound  
 > requests, so that the "next guy" can not see who you are calling and  
 > he can not see who is calling you.

good and thus one more reason to junk sips.  we can just say that a
proxy should use tls if it supports it.

 > The use case I've been worrying about is what happens when there is  
 > no "outbound" proxy and we have a UA to UA flow.

that is a very rare case unless you have some kind of p2p sip setup.

-- juha

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 14:39:56 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeF4L-0006vg-L9; Wed, 18 Apr 2007 14:39:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeF4J-0006vT-Ga
	for sip@ietf.org; Wed, 18 Apr 2007 14:39:51 -0400
Received: from zrtps0kp.nortel.com ([47.140.192.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeF4H-0001Dw-Lv
	for sip@ietf.org; Wed, 18 Apr 2007 14:39:50 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3IIdkm24853; Wed, 18 Apr 2007 18:39:46 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Wed, 18 Apr 2007 13:39:14 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E612561C0E@zrc2hxm2.corp.nortel.com>
In-Reply-To: <17958.25751.480744.939033@tutpro.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
thread-index: AceB6DGUxaYFSVWkSfWVZzU3ZZgDBAAAJUtA
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Juha Heinanen" <jh@tutpro.com>, "Dean Willis" <dean.willis@softarmor.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Cc: sip@ietf.org, Paul Kyzivat <pkyzivat@cisco.com>,
	Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

=20

>
>good and thus one more reason to junk sips.  we can just say=20
>that a proxy should use tls if it supports it.
>

I am sure that Cullen must be listening this.

Thx
Samir

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 14:40:56 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeF5K-0007Hy-UA; Wed, 18 Apr 2007 14:40:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeF5I-0007Hp-OV
	for sip@ietf.org; Wed, 18 Apr 2007 14:40:52 -0400
Received: from spi01.csee.onr.siteprotect.com ([64.26.60.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeF5H-0001Ti-GK
	for sip@ietf.org; Wed, 18 Apr 2007 14:40:52 -0400
Received: from cornfed (c-67-162-139-200.hsd1.co.comcast.net [67.162.139.200])
	(Authenticated sender: fwmiller@cornfed.com)
	by spi01.csee.onr.siteprotect.com (Postfix) with ESMTP id E4B2A1058039; 
	Wed, 18 Apr 2007 13:39:21 -0500 (CDT)
From: "Frank W. Miller" <fwmiller@cornfed.com>
To: "'Vijay K. Gurbani'" <vkg@alcatel-lucent.com>,
	"'jiang mingda'" <jiangmd@msn.com>
Subject: RE: [Sip] sip tcp connection
Date: Wed, 18 Apr 2007 12:40:45 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <46265D40.2020808@alcatel-lucent.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Thread-Index: AceB45T1AiRiYL+OQlWEOZamx2FqrwABNBkg
Message-Id: <20070418183921.E4B2A1058039@spi01.csee.onr.siteprotect.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org



I've heard reference to this security issue in the past but have just gone
and read it for the first time, Section 9.3 right?  I'm not sure I
completely understand it.  Are you saying that another program can hijack
the connection once the legitimate SIP user is not present on the connection
anymore?  Would not the legitimate user have torn down the TCP connection
when it exited?  Wouldn't the TCP connection require authentication when it
was reestablished?  My apologies for my lack of understanding.

Thanks,
FM



-----Original Message-----
From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] 
Sent: Wednesday, April 18, 2007 12:03 PM
To: jiang mingda
Cc: sip@ietf.org
Subject: Re: [Sip] sip tcp connection

jiang mingda wrote:
> Hi Folks, I have a question about sip over TCP. How many connections
> should be established between two sip servers/proxies? Shall I create
> only one tcp connection between them?

You cannot use one connection for bi-directional requests because
of the security risk identified in Section 9 of connect-reuse
(http://tools.ietf.org/html/draft-ietf-sip-connect-reuse-07).



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 14:46:59 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeFBB-0001Fw-SE; Wed, 18 Apr 2007 14:46:57 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeFBB-0001Cl-7Z
	for sip@ietf.org; Wed, 18 Apr 2007 14:46:57 -0400
Received: from [74.95.2.162] (helo=laser.networkresonance.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeFB9-00033O-V3
	for sip@ietf.org; Wed, 18 Apr 2007 14:46:57 -0400
Received: from raman.networkresonance.com (unknown [74.95.2.163])
	by laser.networkresonance.com (Postfix) with ESMTP id 66B115C027;
	Wed, 18 Apr 2007 11:46:13 -0700 (PDT)
Date: Wed, 18 Apr 2007 11:47:54 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: jh@tutpro.com (Juha Heinanen)
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
In-Reply-To: <17958.25751.480744.939033@tutpro.com>
References: <4616851D.5070305@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
	<46245D01.3070301@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
	<4624D827.6070707@cisco.com>
	<0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>
	<66cd252f0704172214u2543b86dl51158e8683de7b1d@mail.gmail.com>
	<FEB3A550-D1B4-4213-BCA2-769531AB61E3@softarmor.com>
	<46264785.1010409@cisco.com> <20070418163512.AC7D9AC2CE@taimen>
	<46264B4F.9000305@cisco.com> <17958.21520.646271.812068@tutpro.com>
	<6CF7278C-D0B3-441A-AC26-D228D3551710@softarmor.com>
	<17958.25751.480744.939033@tutpro.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20070418184613.66B115C027@laser.networkresonance.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: sip@ietf.org, Paul Kyzivat <pkyzivat@cisco.com>,
	Francois Audet <audet@nortel.com>, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

At Wed, 18 Apr 2007 21:33:59 +0300,
Juha Heinanen wrote:
> 
> Dean Willis writes:
> 
>  > You can do what you seem to want to do above without using  
>  > transport=tls by using draft-ietf-sip-outbound and registering over a  
>  > TLS connection.
>  > 
>  > This has the added benefit of providing TLS security on inbound  
>  > requests, so that the "next guy" can not see who you are calling and  
>  > he can not see who is calling you.
> 
> good and thus one more reason to junk sips.  we can just say that a
> proxy should use tls if it supports it.

For the nth time, this doesn't provide the same properties as sips,
which, to repeat, are:

1. The callee can indicate that he can be contacted via TLS.
2. The caller can indicate to every proxy that the messages
   should be carried over TLS or not at all.

-Ekr

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 14:55:23 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeFJL-0000Ui-4s; Wed, 18 Apr 2007 14:55:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeFJH-0000Ts-LR
	for sip@ietf.org; Wed, 18 Apr 2007 14:55:20 -0400
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeFJG-00069V-BB
	for sip@ietf.org; Wed, 18 Apr 2007 14:55:19 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	l3IIsdq03906; Wed, 18 Apr 2007 18:54:39 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Wed, 18 Apr 2007 13:55:13 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E612561C6F@zrc2hxm2.corp.nortel.com>
In-Reply-To: <20070418184613.66B115C027@laser.networkresonance.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
thread-index: AceB6fWuutEDIf/KQea3qWYa9GIRdAAAD7Ow
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Eric Rescorla" <ekr@networkresonance.com>, "Juha Heinanen" <jh@tutpro.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: sip@ietf.org, Paul Kyzivat <pkyzivat@cisco.com>,
	Francois Audet <audet@nortel.com>, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

In line.
Thx
Samir=20

>For the nth time, this doesn't provide the same properties as=20
>sips, which, to repeat, are:
>
>1. The callee can indicate that he can be contacted via TLS.

With all respect, I have to state that Either use Require header in the
REGISTER message or extend the UA capability framework to be contacted
on the secure channel ONLY or both.
This doesn't enforce two contacts.=20

I mentioned sometime back from my puristice view "THIS IS A SECURE
ROUTING REQUIREMENT and to be REACHABLE via SECURE CHANNEL". This needs
to be fullfilled with Proxy-Require and Require. We are seeing so many
issues with SIPS, as we put these together  in the RESOURCE PROPERTY
namely SIPS URI scheme. In HTTP there is VERY THIN line between RESOURCE
and ROUTING, so we don't see so many issues. Here in SIP we have VERY
THICK line between RESOURCE and ROUTING, so we are witnessing so many
issues. Again SIP !=3D HTTP.


>2. The caller can indicate to every proxy that the messages
>   should be carried over TLS or not at all.

Same as above.

>
>-Ekr
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol Use=20
>sip-implementors@cs.columbia.edu for questions on current sip=20
>Use sipping@ietf.org for new developments on the application of sip
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 15:05:59 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeFTX-0007Xf-CC; Wed, 18 Apr 2007 15:05:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeFTW-0007XX-7b
	for sip@ietf.org; Wed, 18 Apr 2007 15:05:54 -0400
Received: from ihemail2.lucent.com ([135.245.0.35])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeFTU-0000vQ-SP
	for sip@ietf.org; Wed, 18 Apr 2007 15:05:54 -0400
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l3IJ5gAl001208; 
	Wed, 18 Apr 2007 14:05:44 -0500 (CDT)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	l3IJ5fA28938; Wed, 18 Apr 2007 14:05:42 -0500 (CDT)
Message-ID: <46266C06.6090401@alcatel-lucent.com>
Date: Wed, 18 Apr 2007 14:05:42 -0500
From: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>
Organization: Bell Labs Security Technology Research Group
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Frank W. Miller" <fwmiller@cornfed.com>
Subject: Re: [Sip] sip tcp connection
References: <20070418183921.E4B2A1058039@spi01.csee.onr.siteprotect.com>
In-Reply-To: <20070418183921.E4B2A1058039@spi01.csee.onr.siteprotect.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Frank W. Miller wrote:
> 
> I've heard reference to this security issue in the past but have just
> gone and read it for the first time, Section 9.3 right?  I'm not sure
> I completely understand it.  Are you saying that another program can
> hijack the connection once the legitimate SIP user is not present on
> the connection anymore?  

Yes.

> Would not the legitimate user have torn down the TCP connection 
> when it exited?  

Yes; thereby making the default port (5060) available for
other processes.

> Wouldn't the TCP connection require authentication when it was 
> reestablished?  

If it is between a UA and a registrar, it should.  If it is
between a UA and a default outbound proxy, it should.  But if
it is with another proxy, then there isn't any authentication.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 16:18:18 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeGbU-0006hR-Hl; Wed, 18 Apr 2007 16:18:12 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeGbT-0006hI-Mp
	for sip@ietf.org; Wed, 18 Apr 2007 16:18:11 -0400
Received: from [74.95.2.162] (helo=laser.networkresonance.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HeGbS-0007gl-Ba
	for sip@ietf.org; Wed, 18 Apr 2007 16:18:11 -0400
Received: from raman.networkresonance.com (unknown [74.95.2.163])
	by laser.networkresonance.com (Postfix) with ESMTP id 6F9C45C02B;
	Wed, 18 Apr 2007 13:17:27 -0700 (PDT)
Date: Wed, 18 Apr 2007 13:19:08 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: "Samir Srivastava" <samirsr@nortel.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E612561C6F@zrc2hxm2.corp.nortel.com>
References: <20070418184613.66B115C027@laser.networkresonance.com>
	<62B9B0847CC47543B6B3B5E26BD268E612561C6F@zrc2hxm2.corp.nortel.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20070418201727.6F9C45C02B@laser.networkresonance.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>,
	Juha Heinanen <jh@tutpro.com>, Dean Willis <dean.willis@softarmor.com>,
	Paul Kyzivat <pkyzivat@cisco.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

At Wed, 18 Apr 2007 13:55:13 -0500,
Samir Srivastava wrote:
> 
> In line.
> Thx
> Samir 
> 
> >For the nth time, this doesn't provide the same properties as 
> >sips, which, to repeat, are:
> >
> >1. The callee can indicate that he can be contacted via TLS.
> 
> With all respect, I have to state that Either use Require header in the
> REGISTER message or extend the UA capability framework to be contacted
> on the secure channel ONLY or both.
> This doesn't enforce two contacts. 

The Require header is not enough because it needs to be indicated
*to the caller*.

As previously noted, this indicator needs to be in the URI in
order to provide referential integrity. Yes, some other mechanism
than SIPS could be used to place it in the URI, but it's not at
all clear to me that inventing something new there would offer
a significant advantage.


-Ekr

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 16:47:40 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeH3w-00055L-53; Wed, 18 Apr 2007 16:47:36 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeH3s-00054j-PP
	for sip@ietf.org; Wed, 18 Apr 2007 16:47:32 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeH3r-00044G-8R
	for sip@ietf.org; Wed, 18 Apr 2007 16:47:32 -0400
Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l3IKlSbh016581
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 18 Apr 2007 13:47:29 -0700
Received: from [129.46.226.38] (carbuncle.qualcomm.com [129.46.226.38])
	by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	l3IKlQr6017837; Wed, 18 Apr 2007 13:47:27 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06240604c24c2ff2d564@[129.46.226.38]>
In-Reply-To: <20070418201727.6F9C45C02B@laser.networkresonance.com>
References: <20070418184613.66B115C027@laser.networkresonance.com>
	<62B9B0847CC47543B6B3B5E26BD268E612561C6F@zrc2hxm2.corp.nortel.com>
	<20070418201727.6F9C45C02B@laser.networkresonance.com>
Date: Wed, 18 Apr 2007 13:47:25 -0700
To: Eric Rescorla <ekr@networkresonance.com>,
	"Samir Srivastava" <samirsr@nortel.com>
From: Ted Hardie <hardie@qualcomm.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from 
	being	delivered to a UA
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>,
	Juha Heinanen <jh@tutpro.com>, Paul Kyzivat <pkyzivat@cisco.com>,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

At 1:19 PM -0700 4/18/07, Eric Rescorla wrote:
>The Require header is not enough because it needs to be indicated
>*to the caller*.
>
>As previously noted, this indicator needs to be in the URI in
>order to provide referential integrity. Yes, some other mechanism
>than SIPS could be used to place it in the URI, but it's not at
>all clear to me that inventing something new there would offer
>a significant advantage.
>
>-Ekr
>

I think the advantage which Dean and others allude to is that it would allow
you to shrink from two URI schemes to one; it also might eliminate the
non-TLS SIPS exception cases in Section 26.2.2/26.4.4 of RFC 3261.   Those
may or may not be significant advantages, depending on how much
of a problem you see the SIP/SIPS conversion to be.

I think a lot of Dean's basic issue is covered in 26.4.4:

  End users will undoubtedly discern the difference between SIPS and
   SIP URIs, and they may manually edit them in response to stimuli.
   This can either benefit or degrade security.  For example, if an
   attacker corrupts a DNS cache, inserting a fake record set that
   effectively removes all SIPS records for a proxy server, then any
   SIPS requests that traverse this proxy server may fail.  When a user,
   however, sees that repeated calls to a SIPS AOR are failing, they
   could on some devices manually convert the scheme from SIPS to SIP
   and retry.  Of course, there are some safeguards against this (if the
   destination UA is truly paranoid it could refuse all non-SIPS
   requests), but it is a limitation worth noting.  On the bright side,
   users might also divine that 'SIPS' would be valid even when they are
   presented only with a SIP URI.

If a user is willing to knowingly try something that degrades security,
there is not much changing where the information resides in the URI
is going to do to improve the situation.  If you added a new uri-parameter
to handle this, it seems likely to me that the same user who shifts
from sips to sip is going to try stripping it off to see if the bare URI
still works.  It also seems less likely to me that people will put
heavily adorned URIs on business cards and the like; to me, that argues
for not shifting to a uri-parameter.  There may, of course, be other ways
of getting it into the URI, but that is the one that strikes me as most
likely.

			regards,
				Ted Hardie

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 16:47:48 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeH48-0005Jd-A7; Wed, 18 Apr 2007 16:47:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeH44-00059T-K9
	for sip@ietf.org; Wed, 18 Apr 2007 16:47:44 -0400
Received: from spi00.csee.onr.siteprotect.com ([64.26.60.136]
	helo=spi01.csee.onr.siteprotect.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeH43-0004H0-AA
	for sip@ietf.org; Wed, 18 Apr 2007 16:47:44 -0400
Received: from cornfed (c-67-162-139-200.hsd1.co.comcast.net [67.162.139.200])
	(Authenticated sender: fwmiller@cornfed.com)
	by spi01.csee.onr.siteprotect.com (Postfix) with ESMTP id 8BA137FC007; 
	Wed, 18 Apr 2007 15:47:42 -0500 (CDT)
From: "Frank W. Miller" <fwmiller@cornfed.com>
To: "'Vijay K. Gurbani'" <vkg@alcatel-lucent.com>
Subject: RE: [Sip] sip tcp connection
Date: Wed, 18 Apr 2007 14:47:38 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <46266C06.6090401@alcatel-lucent.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Thread-Index: AceB7FpDOHSZKYllThqsoWasHnuoGgADBucg
Message-Id: <20070418204742.8BA137FC007@spi01.csee.onr.siteprotect.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


Thanks for the reply.

If your answers are the case then I am confused.

There are three cases you can paint when the 5060 port is idle: 1) some
other network element tries to establish an inbound TCP connection to 5060
(for example) on my machine and 2) some bad program on my machine tries to
establish an outbound TCP connection to a legitimate SIP element, and 3)
some other network element tries to establish a connection (inbound or
outbound) with a bad program on my machine.

In the first case, there is no program listening on 5060 since the port is
free so the connection will not happen.

In the second case, you have established that the user must be authenticated
(except in the case of proxy-to-proxy) so that should presumably prevent bad
things from happening except in the one case.

In the third case, you probably have some kind of virus infestation or
something really bad since a bad program is cooperating with a "bad" network
element.

So, the only real issue here is that proxy-to-proxy TCP connections *may* be
hijacked by some bad program on the initiator's proxy device?  How realistic
is this?  I mean, proxies are likely to have the 5060 port open all the time
anyway and even if they reboot or something, how many proxies are there that
aren't going to be under pretty tight security to prevent a bad program from
appearing?  Is this enough to disallow the use of a bidirectional TCP
connection in all cases?

Speaking as a UA implementer (which I often do ;) ) maintaining a single TCP
connection with my first proxy hop is easier to implement so why be so
draconian because of one case?  It seems like you should address the one
case if it's a problem rather than just shutting down the general mechanism
for everybody.

Thanks, 
FM


-----Original Message-----
From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] 
Sent: Wednesday, April 18, 2007 1:06 PM
To: Frank W. Miller
Cc: sip@ietf.org
Subject: Re: [Sip] sip tcp connection

Frank W. Miller wrote:
> 
> I've heard reference to this security issue in the past but have just
> gone and read it for the first time, Section 9.3 right?  I'm not sure
> I completely understand it.  Are you saying that another program can
> hijack the connection once the legitimate SIP user is not present on
> the connection anymore?  

Yes.

> Would not the legitimate user have torn down the TCP connection 
> when it exited?  

Yes; thereby making the default port (5060) available for
other processes.

> Wouldn't the TCP connection require authentication when it was 
> reestablished?  

If it is between a UA and a registrar, it should.  If it is
between a UA and a default outbound proxy, it should.  But if
it is with another proxy, then there isn't any authentication.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 16:52:48 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeH8w-0005nx-S8; Wed, 18 Apr 2007 16:52:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeH8v-0005nr-7c
	for sip@ietf.org; Wed, 18 Apr 2007 16:52:45 -0400
Received: from [74.95.2.162] (helo=laser.networkresonance.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeH8t-0005g7-Px
	for sip@ietf.org; Wed, 18 Apr 2007 16:52:45 -0400
Received: from raman.networkresonance.com (unknown [74.95.2.163])
	by laser.networkresonance.com (Postfix) with ESMTP id 1261C5C027;
	Wed, 18 Apr 2007 13:52:01 -0700 (PDT)
Date: Wed, 18 Apr 2007 13:53:42 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Ted Hardie <hardie@qualcomm.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
In-Reply-To: <p06240604c24c2ff2d564@[129.46.226.38]>
References: <20070418184613.66B115C027@laser.networkresonance.com>
	<62B9B0847CC47543B6B3B5E26BD268E612561C6F@zrc2hxm2.corp.nortel.com>
	<20070418201727.6F9C45C02B@laser.networkresonance.com>
	<p06240604c24c2ff2d564@[129.46.226.38]>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20070418205201.1261C5C027@laser.networkresonance.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>,
	Juha Heinanen <jh@tutpro.com>, Dean Willis <dean.willis@softarmor.com>,
	Paul Kyzivat <pkyzivat@cisco.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

At Wed, 18 Apr 2007 13:47:25 -0700,
Ted Hardie wrote:
> 
> At 1:19 PM -0700 4/18/07, Eric Rescorla wrote:
> >The Require header is not enough because it needs to be indicated
> >*to the caller*.
> >
> >As previously noted, this indicator needs to be in the URI in
> >order to provide referential integrity. Yes, some other mechanism
> >than SIPS could be used to place it in the URI, but it's not at
> >all clear to me that inventing something new there would offer
> >a significant advantage.
> >
> >-Ekr
> >
> 
> I think the advantage which Dean and others allude to is that it would allow
> you to shrink from two URI schemes to one;

I'm not sure that this improves the situation much.


> it also might eliminate the
> non-TLS SIPS exception cases in Section 26.2.2/26.4.4 of RFC 3261.   Those
> may or may not be significant advantages, depending on how much
> of a problem you see the SIP/SIPS conversion to be.

Well, those exception cases need to be removed in any case. The
current proposal is simply to remove them from SIPS by fiat.
Basically, ISTM that we're going to need something with essentially
the same semantics as it's being proposed SIPS have now...


> I think a lot of Dean's basic issue is covered in 26.4.4:
> 
>   End users will undoubtedly discern the difference between SIPS and
>    SIP URIs, and they may manually edit them in response to stimuli.
>    This can either benefit or degrade security.  For example, if an
>    attacker corrupts a DNS cache, inserting a fake record set that
>    effectively removes all SIPS records for a proxy server, then any
>    SIPS requests that traverse this proxy server may fail.  When a user,
>    however, sees that repeated calls to a SIPS AOR are failing, they
>    could on some devices manually convert the scheme from SIPS to SIP
>    and retry.  Of course, there are some safeguards against this (if the
>    destination UA is truly paranoid it could refuse all non-SIPS
>    requests), but it is a limitation worth noting.  On the bright side,
>    users might also divine that 'SIPS' would be valid even when they are
>    presented only with a SIP URI.
> 
> If a user is willing to knowingly try something that degrades security,
> there is not much changing where the information resides in the URI
> is going to do to improve the situation.  If you added a new uri-parameter
> to handle this, it seems likely to me that the same user who shifts
> from sips to sip is going to try stripping it off to see if the bare URI
> still works.  It also seems less likely to me that people will put
> heavily adorned URIs on business cards and the like; to me, that argues
> for not shifting to a uri-parameter.  There may, of course, be other ways
> of getting it into the URI, but that is the one that strikes me as most
> likely.

Yes, I agree with this analysis... But unless I misread your message,
this is an argument *for* SIPS.

-Ekr


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 17:45:58 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeHyK-0001t9-US; Wed, 18 Apr 2007 17:45:52 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HeHyJ-0001t4-FW
	for sip-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 17:45:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeHyJ-0001sw-62
	for sip@ietf.org; Wed, 18 Apr 2007 17:45:51 -0400
Received: from zrtps0kp.nortel.com ([47.140.192.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeHyH-00012h-Ty
	for sip@ietf.org; Wed, 18 Apr 2007 17:45:51 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3ILjkm10260; Wed, 18 Apr 2007 21:45:46 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Wed, 18 Apr 2007 16:45:36 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E612561FD9@zrc2hxm2.corp.nortel.com>
In-Reply-To: <20070418201727.6F9C45C02B@laser.networkresonance.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
thread-index: AceB9rKFzPTokSNdTPaM6apfsUVBXgACVjPg
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Eric Rescorla" <ekr@networkresonance.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: sip@ietf.org, Juha Heinanen <jh@tutpro.com>,
	Francois Audet <audet@nortel.com>, Paul Kyzivat <pkyzivat@cisco.com>,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi Eric,

  in-line.=20

Thx
Samir

>
>The Require header is not enough because it needs to be=20
>indicated *to the caller*.

Require header gives the semantics to LS (with or without Proxy) to use
the binding only for the request which comes securely to it. If request
doesn't come securely, then indicate some 4xx code to caller. If I have
misunderstood your point, please clarify.

>
>As previously noted, this indicator needs to be in the URI in=20
>order to provide referential integrity. Yes, some other=20
>mechanism than SIPS could be used to place it in the URI, but=20
>it's not at all clear to me that inventing something new there=20
>would offer a significant advantage.
>

Then extending the UA capability should be fine. As Contact header is
part of any hash computation like Identity. You can include Require /
Proxy-Require headers too. My biggest problem is SIPS alone doesn't
serve any meaningful purpose for the SIP infrastructre to be used. I
havenot heard anything for tel, im, pres URI. When we need
Proxy-Require etc for them, then why we want to carry on SIPS in its
current form.

Yes I feel we need something with CLEAR DEFINTION (cipher-suites etc) of
SECURITY. The SIPS as per 3261 is completely broken.

>
>-Ekr
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 17:53:54 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeI62-0002x5-EV; Wed, 18 Apr 2007 17:53:50 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HeI60-0002x0-Mn
	for sip-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 17:53:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeI60-0002wp-D9
	for sip@ietf.org; Wed, 18 Apr 2007 17:53:48 -0400
Received: from [74.95.2.162] (helo=laser.networkresonance.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeI5z-0002Xo-Uf
	for sip@ietf.org; Wed, 18 Apr 2007 17:53:48 -0400
Received: from raman.networkresonance.com (unknown [74.95.2.163])
	by laser.networkresonance.com (Postfix) with ESMTP id 5E0035C027;
	Wed, 18 Apr 2007 14:53:05 -0700 (PDT)
Date: Wed, 18 Apr 2007 14:54:46 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: "Samir Srivastava" <samirsr@nortel.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E612561FD9@zrc2hxm2.corp.nortel.com>
References: <20070418201727.6F9C45C02B@laser.networkresonance.com>
	<62B9B0847CC47543B6B3B5E26BD268E612561FD9@zrc2hxm2.corp.nortel.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20070418215305.5E0035C027@laser.networkresonance.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>,
	Juha Heinanen <jh@tutpro.com>, Dean Willis <dean.willis@softarmor.com>,
	Paul Kyzivat <pkyzivat@cisco.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

At Wed, 18 Apr 2007 16:45:36 -0500,
Samir Srivastava wrote:
> 
> Hi Eric,
> 
>   in-line. 
> 
> Thx
> Samir
> 
> >
> >The Require header is not enough because it needs to be 
> >indicated *to the caller*.
> 
> Require header gives the semantics to LS (with or without Proxy) to use
> the binding only for the request which comes securely to it. If request
> doesn't come securely, then indicate some 4xx code to caller. If I have
> misunderstood your point, please clarify.

This doesn't get the job done for reasons that have been discussed
here many times:

1. The invitation has already been sent in the clear so the damage has
   already been done if there is anything sensitive in the invitation.
2. An active attacker can man-in-the-middle attack the connection
   and initiate a TLS connection to next-hop proxy, thus bypassing
   the check for TLS transport.


> >As previously noted, this indicator needs to be in the URI in 
> >order to provide referential integrity. Yes, some other 
> >mechanism than SIPS could be used to place it in the URI, but 
> >it's not at all clear to me that inventing something new there 
> >would offer a significant advantage.
> >
> 
> Then extending the UA capability should be fine. As Contact header is
> part of any hash computation like Identity. You can include Require /
> Proxy-Require headers too. My biggest problem is SIPS alone doesn't
> serve any meaningful purpose for the SIP infrastructre to be used. I
> havenot heard anything for tel, im, pres URI. When we need
> Proxy-Require etc for them, then why we want to carry on SIPS in its
> current form.
> 
> Yes I feel we need something with CLEAR DEFINTION (cipher-suites etc) of
> SECURITY. The SIPS as per 3261 is completely broken.

Yes, you keep saying this, but I don't agree with you, and, as far
as I can tell, neither does most of the rest of the WG.

-Ekr


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 18:11:56 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeINW-0000oB-43; Wed, 18 Apr 2007 18:11:54 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HeINV-0000o2-Bk
	for sip-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 18:11:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeINV-0000ns-2D
	for sip@ietf.org; Wed, 18 Apr 2007 18:11:53 -0400
Received: from zrtps0kn.nortel.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeINT-0000Qv-2t
	for sip@ietf.org; Wed, 18 Apr 2007 18:11:53 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3IMBmC25158; Wed, 18 Apr 2007 22:11:48 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Wed, 18 Apr 2007 17:11:39 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E612562041@zrc2hxm2.corp.nortel.com>
In-Reply-To: <20070418215305.5E0035C027@laser.networkresonance.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
thread-index: AceCBAyQEMhjCNr4Ry+L0sY6bml+DAAAF/Yg
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Eric Rescorla" <ekr@networkresonance.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: sip@ietf.org, Juha Heinanen <jh@tutpro.com>,
	Francois Audet <audet@nortel.com>, Paul Kyzivat <pkyzivat@cisco.com>,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

=20

>
>This doesn't get the job done for reasons that have been=20
>discussed here many times:
>
>1. The invitation has already been sent in the clear so the damage has
>   already been done if there is anything sensitive in the invitation.

The INVITE has only the SIP AOR of the callee. SIP AOR is publicly
available etc on the business card. What else goes there ?=20

If Caller wants the security, then he will be sending the requests
alltogether using TLS.=20
If caller doesn't use the TLS etc, then it is for the proxy (responsible
for UAS) to reject the request. Require header etc gives the semantics
not to generate 3xx for UNSECURE calls for the UNSECURE INVITES. Is
there anything else ?


>2. An active attacker can man-in-the-middle attack the connection
>   and initiate a TLS connection to next-hop proxy, thus bypassing
>   the check for TLS transport.

UAC --- P1 ---- P3 ----- UAS
                |
        P2 -----

If I understood your point correctly, how P2 can pretned himself as P1
to P3, and act on behalf of P1. Mutual authentication is in place.

>
>Yes, you keep saying this, but I don't agree with you, and, as=20
>far as I can tell, neither does most of the rest of the WG.

For the now, I leave this for the coming time to decide with the next
version of draft. Generally ahead of the time, things are not liked by
people.=20

What is your answer to tel, im, pres URIs first ?=20

>
>-Ekr
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 18:20:41 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeIVv-0005ni-Dv; Wed, 18 Apr 2007 18:20:35 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HeIVu-0005kq-6x
	for sip-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 18:20:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeIVt-0005ki-Tj
	for sip@ietf.org; Wed, 18 Apr 2007 18:20:33 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeIVs-0002tK-JL
	for sip@ietf.org; Wed, 18 Apr 2007 18:20:33 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l3IMKU34030756
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 18 Apr 2007 15:20:30 -0700
Received: from [129.46.226.38] (carbuncle.qualcomm.com [129.46.226.38])
	by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	l3IMKRCg017452; Wed, 18 Apr 2007 15:20:28 -0700
Mime-Version: 1.0
Message-Id: <p06240607c24c4974cfae@[129.46.226.38]>
In-Reply-To: <20070418205201.1261C5C027@laser.networkresonance.com>
References: <20070418184613.66B115C027@laser.networkresonance.com>
	<62B9B0847CC47543B6B3B5E26BD268E612561C6F@zrc2hxm2.corp.nortel.com>
	<20070418201727.6F9C45C02B@laser.networkresonance.com>
	<p06240604c24c2ff2d564@[129.46.226.38]>
	<20070418205201.1261C5C027@laser.networkresonance.com>
Date: Wed, 18 Apr 2007 15:20:26 -0700
To: Eric Rescorla <ekr@networkresonance.com>
From: Ted Hardie <hardie@qualcomm.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from 
	being	delivered to a UA
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>,
	Juha Heinanen <jh@tutpro.com>, Dean Willis <dean.willis@softarmor.com>,
	Paul Kyzivat <pkyzivat@cisco.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

At 1:53 PM -0700 4/18/07, Eric Rescorla wrote:
>Yes, I agree with this analysis... But unless I misread your message,
>this is an argument *for* SIPS.
>

I would put it more as an argument against the effectiveness of change,
but yes.
				Ted


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 18:27:59 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeId3-0006M5-U3; Wed, 18 Apr 2007 18:27:57 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HeId2-0006Lx-Cz
	for sip-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 18:27:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeId2-0006Lm-3K
	for sip@ietf.org; Wed, 18 Apr 2007 18:27:56 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeId0-0005vc-MU
	for sip@ietf.org; Wed, 18 Apr 2007 18:27:55 -0400
Received: from [206.176.144.212] (rcdn4-dmznat-gw1-nat-27.cisco.com
	[12.5.186.27]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3ILYZHd029474
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 18 Apr 2007 16:34:36 -0500
In-Reply-To: <46264B4F.9000305@cisco.com>
References: <4616851D.5070305@softarmor.com>
	<461F8385.3080905@cisco.com>	<461F96EE.3030400@softarmor.com>	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>	<46245D01.3070301@softarmor.com>	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>	<4624D827.6070707@cisco.com>	<0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>	<66cd252f0704172214u2543b86dl51158e8683de7b1d@mail.gmail.com>	<FEB3A550-D1B4-4213-BCA2-769531AB61E3@softarmor.com>	<46264785.1010409@cisco.com>
	<20070418163512.AC7D9AC2CE@taimen> <46264B4F.9000305@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <206E0A29-45C6-48C8-BCE4-0057F0C9C91E@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
Date: Wed, 18 Apr 2007 17:27:46 -0500
To: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: sip@ietf.org, Juha Heinanen <jh@tutpro.com>,
	Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 18, 2007, at 11:46 AM, Paul Kyzivat wrote:

>
>
> Juha Heinanen wrote:
>> Paul Kyzivat writes:
>>  > > How does a UA register to get only SIPS requests?
>>  > I expect it is quite small. If I am right, forcing the  
>> remainder to  > register two contacts rather than one seems like a  
>> bad choice.
>> this is a common practice with http servers.  for example,
>> http://tutpro.com is refused, but https://tutpro.com is not.
>
> Sure. But SIP is not HTTP. I realize that in *theory* there could  
> be lots of targets that only want to use SIPS. But in *practice*  
> where are those going to come from? In general I want to be able to  
> receive calls even if the caller is unwilling or unable to use SIPS.
>
> I know there are exceptions (e.g. the military, and the President),  
> but its my *assumption* that this will be a small number. (I don't  
> know how to get real numbers on this.)
>

I assume the opposite -- that once SIPS can be expected to work,  
everybody with at least half-a-working brain (and the paranoia that  
goes with it) will want to to use it exclusively.

If I could figure out how to get people to stop sending me  
unencrypted email (when they could as easily encrypt), I would.

--
Dean


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 18:28:48 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeIdr-0006ow-Oy; Wed, 18 Apr 2007 18:28:47 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HeIdr-0006or-1h
	for sip-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 18:28:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeIdq-0006oj-ON
	for sip@ietf.org; Wed, 18 Apr 2007 18:28:46 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeIdp-0006Gi-F7
	for sip@ietf.org; Wed, 18 Apr 2007 18:28:46 -0400
Received: from [206.176.144.212] (rcdn4-dmznat-gw1-nat-27.cisco.com
	[12.5.186.27]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3ILYZHe029474
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 18 Apr 2007 16:35:27 -0500
In-Reply-To: <17958.25751.480744.939033@tutpro.com>
References: <4616851D.5070305@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
	<46245D01.3070301@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
	<4624D827.6070707@cisco.com>
	<0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>
	<66cd252f0704172214u2543b86dl51158e8683de7b1d@mail.gmail.com>
	<FEB3A550-D1B4-4213-BCA2-769531AB61E3@softarmor.com>
	<46264785.1010409@cisco.com> <20070418163512.AC7D9AC2CE@taimen>
	<46264B4F.9000305@cisco.com> <17958.21520.646271.812068@tutpro.com>
	<6CF7278C-D0B3-441A-AC26-D228D3551710@softarmor.com>
	<17958.25751.480744.939033@tutpro.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <C3C254A0-5B72-4852-B5F5-102206E9D81C@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
Date: Wed, 18 Apr 2007 17:28:37 -0500
To: Juha Heinanen <jh@tutpro.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: sip@ietf.org, Paul Kyzivat <pkyzivat@cisco.com>,
	Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 18, 2007, at 1:33 PM, Juha Heinanen wrote:


>
>> The use case I've been worrying about is what happens when there is
>> no "outbound" proxy and we have a UA to UA flow.
>
> that is a very rare case unless you have some kind of p2p sip setup.

I'm hoping it becomes much less rare, and would like for decisions  
made now in SIP not to screw it up.

--
Dean


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 18:33:04 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeIhu-0001xw-O3; Wed, 18 Apr 2007 18:32:58 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HeIhr-0001xZ-Kb
	for sip-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 18:32:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeIhr-0001xQ-B1
	for sip@ietf.org; Wed, 18 Apr 2007 18:32:55 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeIhq-0008CZ-1y
	for sip@ietf.org; Wed, 18 Apr 2007 18:32:55 -0400
Received: from [206.176.144.212] (rcdn4-dmznat-gw1-nat-27.cisco.com
	[12.5.186.27]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3ILdcj1029518
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 18 Apr 2007 16:39:39 -0500
In-Reply-To: <20070418184613.66B115C027@laser.networkresonance.com>
References: <4616851D.5070305@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
	<46245D01.3070301@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
	<4624D827.6070707@cisco.com>
	<0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>
	<66cd252f0704172214u2543b86dl51158e8683de7b1d@mail.gmail.com>
	<FEB3A550-D1B4-4213-BCA2-769531AB61E3@softarmor.com>
	<46264785.1010409@cisco.com> <20070418163512.AC7D9AC2CE@taimen>
	<46264B4F.9000305@cisco.com> <17958.21520.646271.812068@tutpro.com>
	<6CF7278C-D0B3-441A-AC26-D228D3551710@softarmor.com>
	<17958.25751.480744.939033@tutpro.com>
	<20070418184613.66B115C027@laser.networkresonance.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <F96D8CC3-5621-4385-9F0C-A3612734AA4C@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Wed, 18 Apr 2007 17:32:48 -0500
To: Eric Rescorla <ekr@networkresonance.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: sip@ietf.org, Juha Heinanen <jh@tutpro.com>,
	Francois Audet <audet@nortel.com>, Paul Kyzivat <pkyzivat@cisco.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 18, 2007, at 1:47 PM, Eric Rescorla wrote:

> At Wed, 18 Apr 2007 21:33:59 +0300,
> Juha Heinanen wrote:
>>
>> Dean Willis writes:
>>
>>> You can do what you seem to want to do above without using
>>> transport=tls by using draft-ietf-sip-outbound and registering  
>>> over a
>>> TLS connection.
>>>
>>> This has the added benefit of providing TLS security on inbound
>>> requests, so that the "next guy" can not see who you are calling and
>>> he can not see who is calling you.
>>
>> good and thus one more reason to junk sips.  we can just say that a
>> proxy should use tls if it supports it.
>
> For the nth time, this doesn't provide the same properties as sips,
> which, to repeat, are:
>
> 1. The callee can indicate that he can be contacted via TLS.
> 2. The caller can indicate to every proxy that the messages
>    should be carried over TLS or not at all.

Except of course that when you register with SIPS, you are also  
declaring reachability by SIP.

Now, it just occurred to me that this might be softened by the  
assumption that "If TLS is usable, it will (MUST/SHOULD?) be used".  
Since if you registered SIPS then you MUST (by definition) be  
reachable by TLS, it would mean that TLS would be used exclusively.

So one a "properly compliant system", once you've registered SIPS,  
you'll never see SIP/UDP again.

But how likely is that to actually happen?

--
Dean



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 18:36:02 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeIkr-0003XS-RO; Wed, 18 Apr 2007 18:36:01 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HeIkp-0003Ok-PD
	for sip-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 18:35:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeIkp-0003Oc-Fh
	for sip@ietf.org; Wed, 18 Apr 2007 18:35:59 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeIko-0001JB-6O
	for sip@ietf.org; Wed, 18 Apr 2007 18:35:59 -0400
Received: from [206.176.144.212] (rcdn4-dmznat-gw1-nat-27.cisco.com
	[12.5.186.27]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3ILghW2029541
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 18 Apr 2007 16:42:43 -0500
In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E612562041@zrc2hxm2.corp.nortel.com>
References: <62B9B0847CC47543B6B3B5E26BD268E612562041@zrc2hxm2.corp.nortel.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <C3766288-70E1-422A-B87D-504F1F264BBC@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Wed, 18 Apr 2007 17:35:53 -0500
To: "Samir Srivastava" <samirsr@nortel.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: sip@ietf.org, Juha Heinanen <jh@tutpro.com>,
	Francois Audet <audet@nortel.com>, Paul Kyzivat <pkyzivat@cisco.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 18, 2007, at 5:11 PM, Samir Srivastava wrote:

>
> If Caller wants the security, then he will be sending the requests
> alltogether using TLS.
> If caller doesn't use the TLS etc, then it is for the proxy  
> (responsible
> for UAS) to reject the request. Require header etc gives the semantics
> not to generate 3xx for UNSECURE calls for the UNSECURE INVITES. Is
> there anything else ?

What does the callee want?

--
Dean


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 18:41:43 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeIqM-0008Ui-BY; Wed, 18 Apr 2007 18:41:42 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HeIqK-0008UU-RA
	for sip-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 18:41:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeIqK-0008UK-H8
	for sip@ietf.org; Wed, 18 Apr 2007 18:41:40 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeIqH-00024R-6D
	for sip@ietf.org; Wed, 18 Apr 2007 18:41:40 -0400
Received: from [206.176.144.212] (rcdn4-dmznat-gw1-nat-27.cisco.com
	[12.5.186.27]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3ILlweW029568
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 18 Apr 2007 16:47:59 -0500
In-Reply-To: <20070418183921.E4B2A1058039@spi01.csee.onr.siteprotect.com>
References: <20070418183921.E4B2A1058039@spi01.csee.onr.siteprotect.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <77CDA802-2142-4D1A-993A-CC189538858C@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] sip tcp connection
Date: Wed, 18 Apr 2007 17:41:08 -0500
To: "Frank W. Miller" <fwmiller@cornfed.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: sip@ietf.org, 'jiang mingda' <jiangmd@msn.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 18, 2007, at 1:40 PM, Frank W. Miller wrote:

>
>
> I've heard reference to this security issue in the past but have  
> just gone
> and read it for the first time, Section 9.3 right?  I'm not sure I
> completely understand it.  Are you saying that another program can  
> hijack
> the connection once the legitimate SIP user is not present on the  
> connection
> anymore?  Would not the legitimate user have torn down the TCP  
> connection
> when it exited?  Wouldn't the TCP connection require authentication  
> when it
> was reestablished?  My apologies for my lack of understanding.
>

There's a couple of ways of looking at it. The one that concerns me  
most is what might be called "TCP Hijacking".

http://www.iss.net/security_center/advice/Exploits/TCP/ 
session_hijacking/default.htm

The idea is that if you authenticate (say, via digest) at the start  
of a TCP session, then anybody "on the wire" can easily take over the  
session and continue to use it without having to re-authenticate.

TLS pretty much prevents this attack.

Just for fun, I seem to recall back in the days of coaxial ethernet  
once seeing an app that would hijack an NFS session to start  
returning bogus data to the client. It was great fun to divert  
somebody to what appeared to be an empty NFS filesystem where they  
expected to find their dissertation research.

--
Dean


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 18:43:18 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeIrr-0002xl-S9; Wed, 18 Apr 2007 18:43:15 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HeIrq-0002xR-80
	for sip-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 18:43:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeIrp-0002xJ-Ul
	for sip@ietf.org; Wed, 18 Apr 2007 18:43:13 -0400
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeIro-0002qF-MY
	for sip@ietf.org; Wed, 18 Apr 2007 18:43:13 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	l3IMgYq20350; Wed, 18 Apr 2007 22:42:34 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Wed, 18 Apr 2007 17:43:08 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF1017109F@zrc2hxm0.corp.nortel.com>
In-Reply-To: <F96D8CC3-5621-4385-9F0C-A3612734AA4C@softarmor.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
thread-index: AceCCYV5trFFwuxWRlyHo4ycQbbjjgAAG3Fg
References: <4616851D.5070305@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
	<46245D01.3070301@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
	<4624D827.6070707@cisco.com>
	<0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>
	<66cd252f0704172214u2543b86dl51158e8683de7b1d@mail.gmail.com>
	<FEB3A550-D1B4-4213-BCA2-769531AB61E3@softarmor.com>
	<46264785.1010409@cisco.com> <20070418163512.AC7D9AC2CE@taimen>
	<46264B4F.9000305@cisco.com> <17958.21520.646271.812068@tutpro.com>
	<6CF7278C-D0B3-441A-AC26-D228D3551710@softarmor.com>
	<17958.25751.480744.939033@tutpro.com>
	<20070418184613.66B115C027@laser.networkresonance.com>
	<F96D8CC3-5621-4385-9F0C-A3612734AA4C@softarmor.com>
From: "Francois Audet" <audet@nortel.com>
To: "Dean Willis" <dean.willis@softarmor.com>,
	"Eric Rescorla" <ekr@networkresonance.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

=20
> Except of course that when you register with SIPS, you are=20
> also declaring reachability by SIP.
>=20
> Now, it just occurred to me that this might be softened by=20
> the assumption that "If TLS is usable, it will (MUST/SHOULD?)=20
> be used". =20

Current text says "MUST". See section 4.2.

> Since if you registered SIPS then you MUST (by definition) be=20
> reachable by TLS, it would mean that TLS would be used exclusively.
>=20
> So one a "properly compliant system", once you've registered=20
> SIPS, you'll never see SIP/UDP again.
>=20
> But how likely is that to actually happen?

Again, if you use sip-outbound (which is not-just-for-NAT), you can
enforce this. You don't "have" to use it of course, but it is=20
available if you need it.

No need for a new mechanism IMHO.



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 18:46:23 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeIur-000503-JM; Wed, 18 Apr 2007 18:46:21 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HeIup-0004zy-6U
	for sip-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 18:46:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeIuo-0004zq-TC
	for sip@ietf.org; Wed, 18 Apr 2007 18:46:18 -0400
Received: from [74.95.2.162] (helo=laser.networkresonance.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeIuo-0004Oc-KA
	for sip@ietf.org; Wed, 18 Apr 2007 18:46:18 -0400
Received: from raman.networkresonance.com (unknown [74.95.2.163])
	by laser.networkresonance.com (Postfix) with ESMTP id 3F4D65C027;
	Wed, 18 Apr 2007 15:45:36 -0700 (PDT)
Date: Wed, 18 Apr 2007 15:47:17 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: "Samir Srivastava" <samirsr@nortel.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E612562041@zrc2hxm2.corp.nortel.com>
References: <20070418215305.5E0035C027@laser.networkresonance.com>
	<62B9B0847CC47543B6B3B5E26BD268E612562041@zrc2hxm2.corp.nortel.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20070418224536.3F4D65C027@laser.networkresonance.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>,
	Juha Heinanen <jh@tutpro.com>, Dean Willis <dean.willis@softarmor.com>,
	Paul Kyzivat <pkyzivat@cisco.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

At Wed, 18 Apr 2007 17:11:39 -0500,
Samir Srivastava wrote:
> 
>  
> 
> >
> >This doesn't get the job done for reasons that have been 
> >discussed here many times:
> >
> >1. The invitation has already been sent in the clear so the damage has
> >   already been done if there is anything sensitive in the invitation.
> 
> The INVITE has only the SIP AOR of the callee. SIP AOR is publicly
> available etc on the business card. What else goes there ? 

As Dean has been pointing out, the mere fact that someone is being called
is itself sensitive. For that matter, so may be their GRUU.


> If Caller wants the security, then he will be sending the requests
> alltogether using TLS. 
> If caller doesn't use the TLS etc, then it is for the proxy (responsible
> for UAS) to reject the request. Require header etc gives the semantics
> not to generate 3xx for UNSECURE calls for the UNSECURE INVITES. Is
> there anything else ?

Again, that doesn't solve the problem because the data has already been
transmitted in the clear.



> >2. An active attacker can man-in-the-middle attack the connection
> >   and initiate a TLS connection to next-hop proxy, thus bypassing
> >   the check for TLS transport.
> 
> UAC --- P1 ---- P3 ----- UAS
>                 |
>         P2 -----
> 
> If I understood your point correctly, how P2 can pretned himself as P1
> to P3, and act on behalf of P1. Mutual authentication is in place.

I have no idea what you are talking about...


> >Yes, you keep saying this, but I don't agree with you, and, as 
> >far as I can tell, neither does most of the rest of the WG.
> 
> For the now, I leave this for the coming time to decide with the next
> version of draft. Generally ahead of the time, things are not liked by
> people. 
> 
> What is your answer to tel, im, pres URIs first ? 

I don't understand why you think that this issue is dispositive.

-Ekr


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 18:46:26 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeIuw-00057z-GK; Wed, 18 Apr 2007 18:46:26 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HeIuv-00052s-63
	for sip-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 18:46:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeIuu-00052k-Sf
	for sip@ietf.org; Wed, 18 Apr 2007 18:46:24 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeIus-0004Pw-LI
	for sip@ietf.org; Wed, 18 Apr 2007 18:46:24 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3IMkJZ08712; Wed, 18 Apr 2007 22:46:19 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Wed, 18 Apr 2007 17:45:40 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E6125620B9@zrc2hxm2.corp.nortel.com>
In-Reply-To: <C3766288-70E1-422A-B87D-504F1F264BBC@softarmor.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
thread-index: AceCCfQSR9MRV3H4RHK6exBOjzku+AAABBEQ
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Dean Willis" <dean.willis@softarmor.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: sip@ietf.org, Juha Heinanen <jh@tutpro.com>,
	Francois Audet <audet@nortel.com>, Paul Kyzivat <pkyzivat@cisco.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

>
>What does the callee want?

Different callee has different security requirements.

If I am US DOD then Callee wants to Security with AES256 as DOD
considers it as TOP SECRET. If I am any other guy, then I may be okay
with AES128. And If I am serving 911 (URN), then I am okay with any
plain simple text message coming.=20

If I am situated in confidentiality/security sensitive geographic area
due to regulatory body there, then only integrity is provided. But here
it will be nice for the caller to know, that UAS is currently not
reachable with AES128 due to mobility etc.

So callee registers with his _ALLOWED_ / _DESIRED_ security level, using
REQUIRE or extending the UA capability and it is responsbility of the
Proxy serving the CALLEE to cater his desired level of security. If his
provider doesn't serve that, then callee will be switching his provider
too.

Thx
Samir

>
>--
>Dean
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 18:48:47 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeIxC-0007A6-Ma; Wed, 18 Apr 2007 18:48:46 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HeIxA-00079y-Vt
	for sip-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 18:48:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeIxA-00079p-MH
	for sip@ietf.org; Wed, 18 Apr 2007 18:48:44 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeIx9-0006C3-DG
	for sip@ietf.org; Wed, 18 Apr 2007 18:48:44 -0400
Received: from [206.176.144.212] (rcdn4-dmznat-gw1-nat-27.cisco.com
	[12.5.186.27]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3ILtS1h029670
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 18 Apr 2007 16:55:29 -0500
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1017109F@zrc2hxm0.corp.nortel.com>
References: <4616851D.5070305@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
	<46245D01.3070301@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
	<4624D827.6070707@cisco.com>
	<0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>
	<66cd252f0704172214u2543b86dl51158e8683de7b1d@mail.gmail.com>
	<FEB3A550-D1B4-4213-BCA2-769531AB61E3@softarmor.com>
	<46264785.1010409@cisco.com> <20070418163512.AC7D9AC2CE@taimen>
	<46264B4F.9000305@cisco.com> <17958.21520.646271.812068@tutpro.com>
	<6CF7278C-D0B3-441A-AC26-D228D3551710@softarmor.com>
	<17958.25751.480744.939033@tutpro.com>
	<20070418184613.66B115C027@laser.networkresonance.com>
	<F96D8CC3-5621-4385-9F0C-A3612734AA4C@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF1017109F@zrc2hxm0.corp.nortel.!
	com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <2BA39C33-926E-4E19-83CC-7195B33D8D79@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Wed, 18 Apr 2007 17:48:39 -0500
To: "Francois Audet" <audet@nortel.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 18, 2007, at 5:43 PM, Francois Audet wrote:

>>
>> Now, it just occurred to me that this might be softened by
>> the assumption that "If TLS is usable, it will (MUST/SHOULD?)
>> be used".
>
> Current text says "MUST". See section 4.2.
>
>> Since if you registered SIPS then you MUST (by definition) be
>> reachable by TLS, it would mean that TLS would be used exclusively.
>>
>> So one a "properly compliant system", once you've registered
>> SIPS, you'll never see SIP/UDP again.
>>
>> But how likely is that to actually happen?
>
> Again, if you use sip-outbound (which is not-just-for-NAT), you can
> enforce this. You don't "have" to use it of course, but it is
> available if you need it.
>
> No need for a new mechanism IMHO.

So let's explore this in the context of a UA to UA relationship  
without an outbound proxy, using our old friends Alice and Bob.

If Alice's UA supports TLS and she has a SIPS URI for Bob, it seems  
like (if your wording says what you think it says) that Alice's UA  
MUST use TLS when trying to contact Bob.

If Alice's UA supports SIPS and she has both a SIP and a SIPS URI for  
Bob, can she use either one as long as she uses TLS? Or does she have  
to use the SIPS URI?

If Alice has only a SIP URI for Bob, but his UA supports TLS, how  
does Alice's UA discover this? Does it have to try connecting via TLS  
first, and if that fails fall back to TCP or UDP?

--
Dean


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 18:52:56 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeJ1C-0006Ou-JY; Wed, 18 Apr 2007 18:52:54 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HeJ1A-0006N9-Kk
	for sip-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 18:52:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeJ1A-0006Mm-9M
	for sip@ietf.org; Wed, 18 Apr 2007 18:52:52 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeJ0z-00082A-F1
	for sip@ietf.org; Wed, 18 Apr 2007 18:52:52 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-2.cisco.com with ESMTP; 18 Apr 2007 18:52:41 -0400
X-IronPort-AV: i="4.14,424,1170651600"; 
	d="scan'208"; a="118889014:sNHT49376084"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3IMqfW0001784; 
	Wed, 18 Apr 2007 18:52:41 -0400
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 l3IMqWGd012268; 
	Wed, 18 Apr 2007 22:52:32 GMT
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.1830); 
	Wed, 18 Apr 2007 18:52:32 -0400
Received: from [161.44.174.118] ([161.44.174.118]) by
	xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 18 Apr 2007 18:52:31 -0400
Message-ID: <4626A12E.2050800@cisco.com>
Date: Wed, 18 Apr 2007 18:52:30 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
References: <4616851D.5070305@softarmor.com>
	<461F8385.3080905@cisco.com>	<461F96EE.3030400@softarmor.com>	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>	<46245D01.3070301@softarmor.com>	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>	<4624D827.6070707@cisco.com>	<0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>	<66cd252f0704172214u2543b86dl51158e8683de7b1d@mail.gmail.com>	<FEB3A550-D1B4-4213-BCA2-769531AB61E3@softarmor.com>	<46264785.1010409@cisco.com>
	<20070418163512.AC7D9AC2CE@taimen> <46264B4F.9000305@cisco.com>
	<206E0A29-45C6-48C8-BCE4-0057F0C9C91E@softarmor.com>
In-Reply-To: <206E0A29-45C6-48C8-BCE4-0057F0C9C91E@softarmor.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 Apr 2007 22:52:31.0932 (UTC)
	FILETIME=[3F76D7C0:01C7820C]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1751; t=1176936761;
	x=1177800761; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20SIPS=20question=3A=20How=20to=20prevent=20pla
	intext=20requests=20from=20being=0A=20delivered=20to=20a=20UA
	|Sender:=20 |To:=20Dean=20Willis=20<dean.willis@softarmor.com>;
	bh=5uk0g6o9CaEg+k0dB2hEHT3kYtE2UwJcKdxG3BYipXM=;
	b=P3IM26Q8IgoonVWqvtDQmkr/JXB5A0zgHZVRJyHuPG0E5/6rOObSsgBGyaNlYRSCz8A0+FCd
	w2GeSdGMHkjVByaHK0vq/mbhHqqNUbvMr/Wsh6UId7JgBpBWvgYuapy7;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc: sip@ietf.org, Juha Heinanen <jh@tutpro.com>,
	Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org



Dean Willis wrote:
> 
> On Apr 18, 2007, at 11:46 AM, Paul Kyzivat wrote:
> 
>>
>>
>> Juha Heinanen wrote:
>>> Paul Kyzivat writes:
>>>  > > How does a UA register to get only SIPS requests?
>>>  > I expect it is quite small. If I am right, forcing the remainder 
>>> to  > register two contacts rather than one seems like a bad choice.
>>> this is a common practice with http servers.  for example,
>>> http://tutpro.com is refused, but https://tutpro.com is not.
>>
>> Sure. But SIP is not HTTP. I realize that in *theory* there could be 
>> lots of targets that only want to use SIPS. But in *practice* where 
>> are those going to come from? In general I want to be able to receive 
>> calls even if the caller is unwilling or unable to use SIPS.
>>
>> I know there are exceptions (e.g. the military, and the President), 
>> but its my *assumption* that this will be a small number. (I don't 
>> know how to get real numbers on this.)
>>
> 
> I assume the opposite -- that once SIPS can be expected to work, 
> everybody with at least half-a-working brain (and the paranoia that goes 
> with it) will want to to use it exclusively.

A lot of communication just doesn't warrant security. I think there will 
be a long while that many won't be able to use sips.

In any case, even if the caller is able to use sips, it may still be 
impossible to establish a successful TLS session. Perhaps the callee 
uses a cert with a CA the caller doesn't support. In that case, the 
caller won't be able to call with sips, but may be able to call with sip.

	Paul

> If I could figure out how to get people to stop sending me unencrypted 
> email (when they could as easily encrypt), I would.
> 
> -- 
> Dean
> 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 19:08:52 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeJGa-0001Yr-5u; Wed, 18 Apr 2007 19:08:48 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HeJGY-0001Yl-IP
	for sip-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 19:08:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeJGY-0001Yd-8n
	for sip@ietf.org; Wed, 18 Apr 2007 19:08:46 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeJGX-0006e1-I9
	for sip@ietf.org; Wed, 18 Apr 2007 19:08:46 -0400
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-6.cisco.com with ESMTP; 18 Apr 2007 16:08:42 -0700
X-IronPort-AV: i="4.14,424,1170662400"; 
	d="scan'208"; a="137495515:sNHT60056550"
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3IN8hFQ008853; 
	Wed, 18 Apr 2007 16:08:43 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3IN8YMJ028569;
	Wed, 18 Apr 2007 23:08:39 GMT
Received: from xmb-sjc-231.amer.cisco.com ([128.107.191.73]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 18 Apr 2007 16:08:35 -0700
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: Wed, 18 Apr 2007 16:08:33 -0700
Message-ID: <49DFEF82990374449378AD1198F39F8B0320A548@xmb-sjc-231.amer.cisco.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10170B4D@zrc2hxm0.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-sip-sips-03: option-tag or not
Thread-Index: AcdyNztJs5tzUmcOTZW5HpAPrTyzdAOOEFEQAC0mmhAAAJa6sAAA6NngAC6bEVAACngKIA==
From: "Charles Eckel \(eckelcu\)" <eckelcu@cisco.com>
To: "Francois Audet" <audet@nortel.com>,
	"Dean Willis" <dean.willis@softarmor.com>, "IETF SIP List" <sip@ietf.org>,
	"Hisham Khartabil" <hisham.khartabil@gmail.com>
X-OriginalArrivalTime: 18 Apr 2007 23:08:35.0873 (UTC)
	FILETIME=[7E049110:01C7820E]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8080; t=1176937723;
	x=1177801723; c=relaxed/simple; s=sjdkim1004;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=eckelcu@cisco.com;
	z=From:=20=22Charles=20Eckel=20\(eckelcu\)=22=20<eckelcu@cisco.com>
	|Subject:=20RE=3A=20draft-ietf-sip-sips-03=3A=20option-tag=20or=20not
	|Sender:=20; bh=06T4AkjZxtQ9uqXI0YHRFVs9hYNEYMOJkkZ6wNQINPM=;
	b=DPD7Zd6GX57bygoUO5Fl/R8jsrTqsU8/XwoEiL6XD66NoBkH6XqtoGXUY+sSdMATpsB0vXZo
	YvJWEhcXE6cdOrMbCXK/pwE6eTSHdDKb8sqZbJkKOAQ+KzxIGvJXMY0K1RQskUBM3FvQaefQ+R
	rUWHRPOD7OmWpCisNdKOf1+8s=;
Authentication-Results: sj-dkim-1; header.From=eckelcu@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim1004 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba
Cc: 
Subject: [Sip] RE: draft-ietf-sip-sips-03: option-tag or not
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Yes, the option-tag looks worthwhile to me.

Thanks,
Charles=20

> -----Original Message-----
> From: Francois Audet [mailto:audet@nortel.com]=20
> Sent: Wednesday, April 18, 2007 11:20 AM
> To: Charles Eckel (eckelcu); Dean Willis; IETF SIP List;=20
> Hisham Khartabil
> Subject: draft-ietf-sip-sips-03: option-tag or not
>=20
> Charles,
>=20
> Do you have an opinion on "should we have the option tag or not"?
>=20
> So far we have had 3 people with opinions (including myself=20
> who changed
> opinion
> once already).
>=20
> Dean & I believe we should have the option-tag.
> Hisham  believes we don't (he sees the draft as "correcting"=20
> RFC 3261).
>=20
> Not sure how strongly opiniated are Dean and Hisham on the issue.
> I personally won't loose any sleep over it.
>=20
> Off the list, I've heard that the option-tag is useful with
> Proxy-Require if you
> want to absolutely enforce the deprecation of the last-hop exception
> rule for=20
> example. Otherwise, you have no garantee.=20
>=20
> I also don't think there is a huge installed base of SIPS
> implementations to worry
> about, but the "just in case factor" should not be=20
> discounted. At least
> not from a standards writing process perspective.
>=20
> Other opinions welcome...
>=20
>=20
> > -----Original Message-----
> > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]=20
> > Sent: Tuesday, April 17, 2007 12:59
> > To: Audet, Francois (SC100:3055); Srivastava, Samir=20
> > (SC100:8826); Dean Willis; IETF SIP List
> > Subject: RE: Poll: Do we have sips/sip retageting in the wild=20
> > (was Re: [Sip] RE:Securing Other URI (Tel URI) scheme)
> >=20
> > I do not think this TLS functionality is being used heavily=20
> > outside of SIPits and some very well constrained environments.
> >=20
> > Cheers,
> > Charles
> >=20
> > > -----Original Message-----
> > > From: Francois Audet [mailto:audet@nortel.com]
> > > Sent: Tuesday, April 17, 2007 12:28 PM
> > > To: Samir Srivastava; Charles Eckel (eckelcu); Dean Willis;=20
> > IETF SIP=20
> > > List
> > > Subject: RE: Poll: Do we have sips/sip retageting in the=20
> > wild (was Re:=20
> > > [Sip] RE:Securing Other URI (Tel URI) scheme)
> > >=20
> > > That would be the rationale for supporting the option tag.
> > >=20
> > > (i.e., for open issue number 2).
> > >=20
> > > Thanks.=20
> > >=20
> > > > -----Original Message-----
> > > > From: Srivastava, Samir (SC100:8826)
> > > > Sent: Tuesday, April 17, 2007 12:13
> > > > To: Charles Eckel (eckelcu); Dean Willis; IETF SIP List
> > > > Subject: RE: Poll: Do we have sips/sip retageting in the=20
> > wild (was=20
> > > > Re: [Sip] RE:Securing Other URI (Tel URI) scheme)
> > > >=20
> > > > Hi Charles,
> > > >=20
> > > >    If it is not confidential, could you please share with=20
> > the group=20
> > > > whether users of CSPS USED the SIPS. As it was=20
> > implemented in 2003=20
> > > > and if it is being used heavily, then we MUST be seeing atleast=20
> > > > couple of the issues coming from SIPS much earlier.
> > > >=20
> > > > Thx
> > > > Samir
> > > >=20
> > > > >-----Original Message-----
> > > > >From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]
> > > > >Sent: Monday, April 16, 2007 2:45 PM
> > > > >To: Dean Willis; IETF SIP List
> > > > >Subject: RE: Poll: Do we have sips/sip retageting in the
> > > > wild (was Re:=20
> > > > >[Sip] RE:Securing Other URI (Tel URI) scheme)
> > > > >
> > > > >Sorry for the late response, but the Cisco SIP Proxy Server
> > > > >(CSPS) allowed for retargeting from sips to sip. Whether=20
> > or not to=20
> > > > >allow this is configurable, and it is disabled by default.
> > > > >I do not recall what we did in terms of sip to sips, but I
> > > think we
> > > > >allowed it as well. This was done in 2003 and not changed
> > > > since as far
> > > > >as I know.
> > > > >
> > > > >Cheers,
> > > > >Charles
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: Dean Willis [mailto:dean.willis@softarmor.com]
> > > > >> Sent: Thursday, March 29, 2007 12:12 PM
> > > > >> To: IETF SIP List
> > > > >> Subject: Poll: Do we have sips/sip retageting in the
> > > wild (was Re:=20
> > > > >> [Sip] RE:Securing Other URI (Tel URI) scheme)
> > > > >>=20
> > > > >>=20
> > > > >> On Mar 29, 2007, at 12:01 PM, Francois Audet wrote:
> > > > >>=20
> > > > >> > I don't agree.
> > > > >> >
> > > > >> > I think this is theoretical. I don't believe proxies
> > > > that "upgrade"
> > > > >> > from SIP to SIPS using a retargeting exist in nature. And
> > > > >> if they did,
> > > > >> > they
> > > > >> > would likely break stuff, or have some assumptions that
> > > > makes them
> > > > >> > essentially proprietary. It just doesn't work except for
> > > > some very
> > > > >> > narrow sceanrios (e.g., transactions that don't create a
> > > > >dialog, or
> > > > >> > dialogs with double Record-Route used at the
> > > retargeting point,
> > > > >> > along with endpoints that don't understand SIPS but
> > > > somehow don't
> > > > >> > choke on the
> > > > >> scheme, use of
> > > > >> > SIP
> > > > >> > outbound
> > > > >> > which is not standard yet, etc.). Same applies for=20
> > downgrades.
> > > > >> >
> > > > >> > So to me, it's a non-issue.
> > > > >> >
> > > > >> > From a standard's purist dreamland point of view, we
> > > > could define
> > > > >> > this extension: it would not "break" anything. It would
> > > > just make
> > > > >> > the spec more complicated for no good reason.
> > > > >>=20
> > > > >> I used to have a proxy at the house that would retarget
> > > > inbound from
> > > > >> sips to sip to let my old 3Com phone work. It would also
> > > > >retarget sip
> > > > >> to sips outbound so I could call sips (said proxy is why I
> > > > >insisted on
> > > > >> last-hop exception in 3261). Such proxies do exist.
> > > > >>=20
> > > > >> The good news is, I don't use it anymore (the bad news is I
> > > > >don't have
> > > > >> a working SIP phone at home right now).
> > > > >>=20
> > > > >> So (Chair Hat on): Anybody else out there have a proxy
> > > > currently (or
> > > > >> planned to be) in use that retargets sip to sips or=20
> vice versa?
> > > > >>=20
> > > > >> If we can't come up with any, I suppose I'd be willing to
> > > > >concede the
> > > > >> issue as "fixing an improbable problem"
> > > > >>=20
> > > > >> --
> > > > >> Dean
> > > > >>=20
> > > > >>=20
> > > > >> _______________________________________________
> > > > >> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > > >> This list is for NEW development of the core SIP=20
> Protocol Use=20
> > > > >> sip-implementors@cs.columbia.edu for questions on
> > > current sip Use
> > > > >> sipping@ietf.org for new developments on the=20
> application of sip
> > > > >>=20
> > > > >
> > > > >_______________________________________________
> > > > >Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > > >This list is for NEW development of the core SIP Protocol Use=20
> > > > >sip-implementors@cs.columbia.edu for questions on=20
> > current sip Use=20
> > > > >sipping@ietf.org for new developments on the application of sip
> > > > >
> > > >=20
> > > > _______________________________________________
> > > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > > This list is for NEW development of the core SIP Protocol Use=20
> > > > sip-implementors@cs.columbia.edu for questions on=20
> current sip Use=20
> > > > sipping@ietf.org for new developments on the application of sip
> > > >=20
> > >=20
> >=20
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use=20
> > sip-implementors@cs.columbia.edu for questions on current sip=20
> > Use sipping@ietf.org for new developments on the application of sip
> >=20
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 19:34:21 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeJfD-000439-6j; Wed, 18 Apr 2007 19:34:15 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HeJfB-000434-H2
	for sip-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 19:34:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeJfB-00042w-7X
	for sip@ietf.org; Wed, 18 Apr 2007 19:34:13 -0400
Received: from zrtps0kn.nortel.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeJfA-0005eY-01
	for sip@ietf.org; Wed, 18 Apr 2007 19:34:13 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3INY8C03087; Wed, 18 Apr 2007 23:34:09 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Wed, 18 Apr 2007 18:33:29 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E61256211E@zrc2hxm2.corp.nortel.com>
In-Reply-To: <20070418224536.3F4D65C027@laser.networkresonance.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
thread-index: AceCC2QuY+a978F7SN2dBhUzTftapQABJWvA
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Eric Rescorla" <ekr@networkresonance.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: sip@ietf.org, Juha Heinanen <jh@tutpro.com>,
	Francois Audet <audet@nortel.com>, Paul Kyzivat <pkyzivat@cisco.com>,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi Eric,

   in-line.

Thx
Samir

>
>As Dean has been pointing out, the mere fact that someone is=20
>being called is itself sensitive. For that matter, so may be=20
>their GRUU.

As of now, I am not an expert on current version of GRUU. I need to take
a look on that.
In the current email world, anyone can send the emails. What is the
protection there.

The confidentiality is driven by the caller. Callee cannot tell every
proxy on the earth, that please accept only Secure AOR for me. Even if
it does that, then there is still first hop (between CALLER and his
proxy) is open. This doesn't work. Callee can only dictate his serving
proxy.

>
>
>Again, that doesn't solve the problem because the data has=20
>already been transmitted in the clear.
>

No, only the SIP AOR of the callee is transmitted. Rest all is Caller
Info, which should be owned (at his risk) by caller only.


>> >2. An active attacker can man-in-the-middle attack the connection
>> >   and initiate a TLS connection to next-hop proxy, thus bypassing
>> >   the check for TLS transport.
>>=20
>> UAC --- P1 ---- P3 ----- UAS
>>                 |
>>         P2 -----
>>=20
>> If I understood your point correctly, how P2 can pretned=20
>himself as P1=20
>> to P3, and act on behalf of P1. Mutual authentication is in place.
>
>I have no idea what you are talking about...
>

TLS mutual authentication between the proxies.

>
>>=20
>> What is your answer to tel, im, pres URIs first ?=20
>
>I don't understand why you think that this issue is dispositive.

SIP infrastructure is used for transporting this URI's also. So I much
more concerned.
As there is nothing for this. I don't know how many times this question
I need to raise.
Plain simple accept SIPS as per 3261 is broken, and we need something
more meaninful.

>
>-Ekr
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 20:12:52 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeKGV-0002Ys-2i; Wed, 18 Apr 2007 20:12:47 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HeKGT-0002Yk-NR
	for sip-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 20:12:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeKGT-0002YT-Ar
	for sip@ietf.org; Wed, 18 Apr 2007 20:12:45 -0400
Received: from py-out-1112.google.com ([64.233.166.177])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeKGT-0003nT-2I
	for sip@ietf.org; Wed, 18 Apr 2007 20:12:45 -0400
Received: by py-out-1112.google.com with SMTP id f31so292675pyh
	for <sip@ietf.org>; Wed, 18 Apr 2007 17:12:44 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=SJEHg+xBpjltFcXaHSg9AA1DETFnX4MDVebx1eMw14YRFWlHFHcJl5wKYc6fD2aVlDkxn+JfnUD/0DcsRTJYGFeqH7KOgmUiiWw4Kkx3zMuuLTvE0F9+HMydIJXzq4Mj5oczUJ14ttBGYlFChl57rsIpmv1Ef1XV4902W7lOgRE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=LQY3JW2sEnM1Z+jLypud/7uB5SIbacyZ1ub3g0fliWimUle+RaR6w4uEGreXLhUffXR2pfoJ1WYJHLyPzTujmD1dMV6tdTzU1nofenFio/dO4Tix3S+kK4Z1mqZ2baGYRsjH0f2j320CcaHGz4oTfyja2wHf+0AS4YQEndooJps=
Received: by 10.65.194.13 with SMTP id w13mr2358262qbp.1176941564625;
	Wed, 18 Apr 2007 17:12:44 -0700 (PDT)
Received: by 10.65.189.16 with HTTP; Wed, 18 Apr 2007 17:12:44 -0700 (PDT)
Message-ID: <66cd252f0704181712w45b90380kfecb22471c30934f@mail.gmail.com>
Date: Thu, 19 Apr 2007 10:12:44 +1000
From: "Hisham Khartabil" <hisham.khartabil@gmail.com>
To: "Francois Audet" <audet@nortel.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10170AD0@zrc2hxm0.corp.nortel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4616851D.5070305@softarmor.com>
	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
	<46245D01.3070301@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
	<4624D827.6070707@cisco.com>
	<0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>
	<66cd252f0704172214u2543b86dl51158e8683de7b1d@mail.gmail.com>
	<FEB3A550-D1B4-4213-BCA2-769531AB61E3@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10170AD0@zrc2hxm0.corp.nortel.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: sip@ietf.org, Paul Kyzivat <pkyzivat@cisco.com>,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

On 19/04/07, Francois Audet <audet@nortel.com> wrote:
> To resolve this, we need to do the following:
>
> - Decide if it is a requirement that the UA be able to tell its
>   home proxy that it wants to be contacted ONLY by SIPS. (the
>   other cases, SIP only and SIP+SIPS are already covered by the draft).
>   As Dean point out, it is ALREADY doable on the Proxy side. Again,
>   the question is "how does the client tell it's preference to the
>   proxy".
>         - I'd like to see a clear articulation of why this is a
> requirement.
>           Seems to me that systems that require that level of security
>         would normally have this set-up as a policy on the proxy as
>         opposed to the end-user

This is an end user choice, imo. Not a choice of the service provider.
I want to decide if I receive secure calls or not, not the system.
(there are exceptional cases like the military).


Hisham

> (this is the error-prone end-user
>         problem, as exemplified by the Dick Cheney use case).
>
> - In the affirmative, the next question is "WHY ISN'T sip-outbound an
>   adequate solution"?
>
>         - I'd like to see a clear articulation of why sip-outbound isn't
>
>           an adequate solution. I am quite worried about proliferating
>         solutions
>
>         - If we can get a good explanation of why we need something that
>         is not sip-outbound, then we need to define the mechanism.
>
>         - There was a proposal on the list that something like caller
>         pref would be appropriate.
>
>
>
>
> > -----Original Message-----
> > From: Dean Willis [mailto:dean.willis@softarmor.com]
> > Sent: Wednesday, April 18, 2007 09:09
> > To: Hisham Khartabil
> > Cc: Paul Kyzivat; sip@ietf.org; Audet, Francois (SC100:3055)
> > Subject: Re: [Sip] SIPS question: How to prevent plaintext
> > requests from being delivered to a UA
> >
> >
> > On Apr 18, 2007, at 12:14 AM, Hisham Khartabil wrote:
> >
> > >
> > > The question I have is how does the UA that registers tell the home
> > > proxy that it wants to be contacted on a sip uri, sips uri or both.
> > > Paul does not like the multiple registration idea. How else?
> > >
> >
> > That's another way of approaching the question I've been
> > trying to ask.
> >
> > A SIP registration means that the UA wants only SIP requests
> > and can or will not handle SIPS.
> >
> > It is proposed that a SIPS registration means that the UA can
> > handle both SIP and SIPS requests.
> >
> > How does a UA register to get only SIPS requests?
> >
> > Francois' draft talks about this being set by proxy policy:
> >
> >     Proxies MAY have their own policy regarding routing of requests to
> >     SIP or SIPS URIs.  For example, a proxy in a critical
> > environment may
> >     be configured to only route SIPS.
> >
> > I'm not entirely confident that this is adequate, and want
> > some way for the registering UA to be able to declare that it
> > only wants SIPS requests.
> >
> > --
> > Dean
> >
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 23:45:15 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeNa0-0004MV-Ow; Wed, 18 Apr 2007 23:45:08 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HeNZz-0004MQ-P6
	for sip-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 23:45:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeNZz-0004MI-FJ
	for sip@ietf.org; Wed, 18 Apr 2007 23:45:07 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeNZx-0005Xl-6U
	for sip@ietf.org; Wed, 18 Apr 2007 23:45:07 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3J3j2C09440; Thu, 19 Apr 2007 03:45:02 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Wed, 18 Apr 2007 22:45:01 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF10171246@zrc2hxm0.corp.nortel.com>
In-Reply-To: <2BA39C33-926E-4E19-83CC-7195B33D8D79@softarmor.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
thread-index: AceCC7nmDdMPH0YoR+uj7udgVr+cYQABi1SQ
References: <4616851D.5070305@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
	<46245D01.3070301@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
	<4624D827.6070707@cisco.com>
	<0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>
	<66cd252f0704172214u2543b86dl51158e8683de7b1d@mail.gmail.com>
	<FEB3A550-D1B4-4213-BCA2-769531AB61E3@softarmor.com>
	<46264785.1010409@cisco.com> <20070418163512.AC7D9AC2CE@taimen>
	<46264B4F.9000305@cisco.com> <17958.21520.646271.812068@tutpro.com>
	<6CF7278C-D0B3-441A-AC26-D228D3551710@softarmor.com>
	<17958.25751.480744.939033@tutpro.com>
	<20070418184613.66B115C027@laser.networkresonance.com>
	<F96D8CC3-5621-4385-9F0C-A3612734AA4C@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF1017109F@zrc2hxm0.corp.nortel.!
	! com> <2 BA39C33-926E-4E19-83CC-7195B33D8D79@softarmor.com>
From: "Francois Audet" <audet@nortel.com>
To: "Dean Willis" <dean.willis@softarmor.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

=20
> So let's explore this in the context of a UA to UA=20
> relationship without an outbound proxy, using our old friends=20
> Alice and Bob.

Ok, assuming there are no proxies whatsoever in this case.

Alice does a DNS query and it resolves directly to Bob, or maybe some
p2p sip magic, and figures out where Bob is.

> If Alice's UA supports TLS and she has a SIPS URI for Bob, it=20
> seems like (if your wording says what you think it says) that=20
> Alice's UA MUST use TLS when trying to contact Bob.

Yes. That is correct. And SIPS too.

> If Alice's UA supports SIPS and she has both a SIP and a SIPS=20
> URI for Bob, can she use either one as long as she uses TLS?=20
> Or does she have to use the SIPS URI?

She can use whatever she wants, SIP or SIPS. If she uses SIPS
(which is recommended), then she MUST use TLS.

If she uses SIP, she SHOULD use TLS but doesn't have to.=20

> If Alice has only a SIP URI for Bob, but his UA supports TLS,=20
> how does Alice's UA discover this? Does it have to try=20
> connecting via TLS first, and if that fails fall back to TCP or UDP?

She can try to establish a TLS connection to Bob if she wants, but it
may not work. She may not have Bob's user certificate for example. And
why would she only have a SIP URI if Bob is reachable with SIPS?

It's entirely up to her (or her UAC) to decide if she (it) wishes to
incur=20
the cost "trying" TLS (and potentially sips although it doesn't change
anything in this p2p sceanrio) "all the time".

Since this p2p stuff and TLS assumes the existence of a global PKI=20
based on user certs, I'm not sure why we are spending so much time on
it.


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 18 23:54:16 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeNil-00046P-4U; Wed, 18 Apr 2007 23:54:11 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HeNij-00046E-4X
	for sip-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 23:54:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeNii-000465-R6
	for sip@ietf.org; Wed, 18 Apr 2007 23:54:08 -0400
Received: from zrtps0kp.nortel.com ([47.140.192.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeNih-0007A9-IZ
	for sip@ietf.org; Wed, 18 Apr 2007 23:54:08 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3J3s3W21017; Thu, 19 Apr 2007 03:54:03 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
Date: Wed, 18 Apr 2007 22:53:53 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF10171253@zrc2hxm0.corp.nortel.com>
In-Reply-To: <66cd252f0704181712w45b90380kfecb22471c30934f@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being delivered to a UA
thread-index: AceCF3ebou3kN4HaSu+bvTqQl3oM/wAHbSIg
References: <4616851D.5070305@softarmor.com>
	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
	<46245D01.3070301@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
	<4624D827.6070707@cisco.com>
	<0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>
	<66cd252f0704172214u2543b86dl51158e8683de7b1d@mail.gmail.com>
	<FEB3A550-D1B4-4213-BCA2-769531AB61E3@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10170AD0@zrc2hxm0.corp.nortel.com>
	<66cd252f0704181712w45b90380kfecb22471c30934f@mail.gmail.com>
From: "Francois Audet" <audet@nortel.com>
To: "Hisham Khartabil" <hisham.khartabil@gmail.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc: sip@ietf.org, Paul Kyzivat <pkyzivat@cisco.com>,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

=20
> This is an end user choice, imo. Not a choice of the service provider.
> I want to decide if I receive secure calls or not, not the system.
> (there are exceptional cases like the military).

At this point, Bob has the following options:

1) Reject any call addressed to SIP

2) Redirect any call addressed to SIP to SIPS (i.e, 301 to SIPS AOR or
302 to SIPS Contact)

3) Use SIP outbound to absolutely force the use of TLS (and avoid the
allege vulnerability of=20
   in 1 and 2 above of your location being discovered by somebody
magically tapping in the=20
   switch where you just just happen to be connected to at that moment).

4) Have an arrangement with your provider to do it for you (it's your
choice, you tell your
   service provider what you want)=20

If I understand correctly, you think this is not good enough????

I'm really struggling to find a use case for this. Seriously. It seems
insanely far fetched.
If you are that worried about this, get a better service provider. Or
get your own domain=20
name.

But if we really needed one, I think the caller pref idea is the best
one. Even if it
seems completely overkill to me.



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 19 00:15:57 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeO3m-0005uy-SG; Thu, 19 Apr 2007 00:15:54 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HeO3k-0005uq-Gh
	for sip-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 00:15:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeO3k-0005ud-6u
	for sip@ietf.org; Thu, 19 Apr 2007 00:15:52 -0400
Received: from py-out-1112.google.com ([64.233.166.178])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeO3j-0003l2-VR
	for sip@ietf.org; Thu, 19 Apr 2007 00:15:52 -0400
Received: by py-out-1112.google.com with SMTP id f31so350506pyh
	for <sip@ietf.org>; Wed, 18 Apr 2007 21:15:51 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=ON3Kac5x3XpAKhR4+E5rQN8mOYjwOKQ1pLp/7EH98j3osLjUxBe30OB80t3WqGTwkHu/HdS4UIvMo/bm7Ymi89ZUVyl33y7ZvTMKwn6gftRAECtG3Zm/bJJ5odEZ7PAmjLWKDDcrbDW5Tx/yrhWhleWL8oxaVxh/4HfXHaBhttY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=ksDA7KOuGF+Y2krvtqrAdVW9yMxQ3clrj2TFA+vATjUPveGUYREd8U9C0qRA2oLcyJAMtDwUf9j9+iV6yh9eygDGNDAdo4zt5UaEHl0nCSAtEkKbmae9Lte3982tjB539qMlL8bfopcu8tDIagOo+Cc3Lt8ZXgW+3sFAF0e5ZXU=
Received: by 10.65.61.16 with SMTP id o16mr2748324qbk.1176956151521;
	Wed, 18 Apr 2007 21:15:51 -0700 (PDT)
Received: by 10.65.189.16 with HTTP; Wed, 18 Apr 2007 21:15:51 -0700 (PDT)
Message-ID: <66cd252f0704182115y3fbb4d03wb0d05b16d5f20ec6@mail.gmail.com>
Date: Thu, 19 Apr 2007 14:15:51 +1000
From: "Hisham Khartabil" <hisham.khartabil@gmail.com>
To: "Francois Audet" <audet@nortel.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10171253@zrc2hxm0.corp.nortel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4616851D.5070305@softarmor.com> <46245D01.3070301@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
	<4624D827.6070707@cisco.com>
	<0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>
	<66cd252f0704172214u2543b86dl51158e8683de7b1d@mail.gmail.com>
	<FEB3A550-D1B4-4213-BCA2-769531AB61E3@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10170AD0@zrc2hxm0.corp.nortel.com>
	<66cd252f0704181712w45b90380kfecb22471c30934f@mail.gmail.com>
	<1ECE0EB50388174790F9694F77522CCF10171253@zrc2hxm0.corp.nortel.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: sip@ietf.org, Paul Kyzivat <pkyzivat@cisco.com>,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

On 19/04/07, Francois Audet <audet@nortel.com> wrote:
>
> > This is an end user choice, imo. Not a choice of the service provider.
> > I want to decide if I receive secure calls or not, not the system.
> > (there are exceptional cases like the military).
>
> At this point, Bob has the following options:
>
> 1) Reject any call addressed to SIP

Dean does not want the request to arrive at Bob's UA at all. I agree
with him on that.

>
> 2) Redirect any call addressed to SIP to SIPS (i.e, 301 to SIPS AOR or
> 302 to SIPS Contact)

Yes. That's what I want to be normative text (i.e, 301 to SIPS AOR),
but not the SIPS contact part.

>
> 3) Use SIP outbound to absolutely force the use of TLS (and avoid the
> allege vulnerability of
>    in 1 and 2 above of your location being discovered by somebody
> magically tapping in the
>    switch where you just just happen to be connected to at that moment).

I thought outbound was solving a different set of problems, namely NAT
traversal. Why is it in the mix here? This is confusing. Copy the text
into your draft if you have to, but I don't have a NAT issue, I dont
want to implement outbound.

>
> 4) Have an arrangement with your provider to do it for you (it's your
> choice, you tell your
>    service provider what you want)

This must be mandated somehow. We cannot mandate implementations or
what a service provider provides to a customer, but we can however
make protocol rules. It is a vulnerability that we need to protect
against that we cannot ignore, no matter how small it is. It is not a
nice to have feature.

>
> If I understand correctly, you think this is not good enough????
>
> I'm really struggling to find a use case for this. Seriously. It seems
> insanely far fetched.

This is absolutely not far fetched. I want to only be reached
securely. Calling directly between UAs or not having a home proxy with
outbound implemented is far fetched???

Hisham


> If you are that worried about this, get a better service provider. Or
> get your own domain
> name.
>
> But if we really needed one, I think the caller pref idea is the best
> one. Even if it
> seems completely overkill to me.
>
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 19 00:27:04 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeOEY-0006iL-80; Thu, 19 Apr 2007 00:27:02 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HeOEW-0006iE-A9
	for sip-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 00:27:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeOEW-0006i3-0b
	for sip@ietf.org; Thu, 19 Apr 2007 00:27:00 -0400
Received: from zrtps0kp.nortel.com ([47.140.192.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeOEV-00088N-P5
	for sip@ietf.org; Thu, 19 Apr 2007 00:26:59 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3J4QnW28370; Thu, 19 Apr 2007 04:26:49 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
Date: Wed, 18 Apr 2007 23:26:46 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF10171270@zrc2hxm0.corp.nortel.com>
In-Reply-To: <66cd252f0704182115y3fbb4d03wb0d05b16d5f20ec6@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being delivered to a UA
thread-index: AceCOWzz4yu5f54uSV2rLn2lk2CItQAACPyw
References: <4616851D.5070305@softarmor.com> <46245D01.3070301@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
	<4624D827.6070707@cisco.com>
	<0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>
	<66cd252f0704172214u2543b86dl51158e8683de7b1d@mail.gmail.com>
	<FEB3A550-D1B4-4213-BCA2-769531AB61E3@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10170AD0@zrc2hxm0.corp.nortel.com>
	<66cd252f0704181712w45b90380kfecb22471c30934f@mail.gmail.com>
	<1ECE0EB50388174790F9694F77522CCF10171253@zrc2hxm0.corp.nortel.com>
	<66cd252f0704182115y3fbb4d03wb0d05b16d5f20ec6@mail.gmail.com>
From: "Francois Audet" <audet@nortel.com>
To: "Hisham Khartabil" <hisham.khartabil@gmail.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: sip@ietf.org, Paul Kyzivat <pkyzivat@cisco.com>,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

 > >
> > 2) Redirect any call addressed to SIP to SIPS (i.e, 301 to=20
> SIPS AOR or
> > 302 to SIPS Contact)
>=20
> Yes. That's what I want to be normative text (i.e, 301 to=20
> SIPS AOR), but not the SIPS contact part.

Ok, I can certainly add some wording to that effect, i.e., that
if you DO NOT want to be reached with SIP, then a 301 to your AOR
with a SIPS scheme is in order.=20

I will add to -04.

> >
> > 3) Use SIP outbound to absolutely force the use of TLS (and=20
> avoid the=20
> > allege vulnerability of
> >    in 1 and 2 above of your location being discovered by somebody=20
> > magically tapping in the
> >    switch where you just just happen to be connected to at=20
> that moment).
>=20
> I thought outbound was solving a different set of problems,=20
> namely NAT traversal. Why is it in the mix here? This is=20
> confusing. Copy the text into your draft if you have to, but=20
> I don't have a NAT issue, I dont want to implement outbound.

That is not correct. Outbound is not only to solve NAT traversal
problems.

Outbound is also to support any cases where inbound connections
are not possible.

A perfect examples is when using TLS and only the Proxy has a=20
certificate to provide (which is the typical case). That is=20
explained, unfortunately not very clearly, at the beginning of
sip-outbound.

This is what I was refering too.

> >
> > 4) Have an arrangement with your provider to do it for you=20
> (it's your=20
> > choice, you tell your
> >    service provider what you want)
>=20
> This must be mandated somehow. We cannot mandate=20
> implementations or what a service provider provides to a=20
> customer, but we can however make protocol rules. It is a=20
> vulnerability that we need to protect against that we cannot=20
> ignore, no matter how small it is. It is not a nice to have feature.
>
> >
> > If I understand correctly, you think this is not good enough????
> >
> > I'm really struggling to find a use case for this.=20
> Seriously. It seems=20
> > insanely far fetched.
>=20
> This is absolutely not far fetched. I want to only be reached=20
> securely. Calling directly between UAs or not having a home=20
> proxy with outbound implemented is far fetched???

Will the 301 change address your concern?

If not, what else? You are giving lots of constraints. No home proxy,
and no outbound. Seems to me anybody can do a DNS query, find you and
shoot whatever they want at you.


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 19 10:53:54 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeY12-0006LL-Gn; Thu, 19 Apr 2007 10:53:44 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HeY11-0006LG-Cl
	for sip-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 10:53:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeY11-0006L8-3B
	for sip@ietf.org; Thu, 19 Apr 2007 10:53:43 -0400
Received: from smtp-3.hut.fi ([130.233.228.93])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeY0z-0007wG-Kf
	for sip@ietf.org; Thu, 19 Apr 2007 10:53:43 -0400
Received: from localhost (putosiko.hut.fi [130.233.228.114])
	by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id l3JEqIi9023042;
	Thu, 19 Apr 2007 17:52:18 +0300
Received: from smtp-3.hut.fi ([130.233.228.93])
	by localhost (putosiko.hut.fi [130.233.228.114]) (amavisd-new,
	port 10024)
	with LMTP id 32104-47-3; Thu, 19 Apr 2007 17:52:18 +0300 (EEST)
Received: from mail.tml.hut.fi (mail.tml.hut.fi [130.233.47.34])
	by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id l3JEq2Q2022995;
	Thu, 19 Apr 2007 17:52:02 +0300
Received: from localhost (localhost.tml.hut.fi [127.0.0.1])
	by mail.tml.hut.fi (Postfix) with ESMTP id C329C3A2CD9;
	Thu, 19 Apr 2007 17:52:01 +0300 (EEST)
Received: from mail.tml.hut.fi ([127.0.0.1])
	by localhost (mail.tml.hut.fi [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 14242-01; Thu, 19 Apr 2007 17:52:00 +0300 (EEST)
Received: from localhost (tml-yp-4.tml.hut.fi [130.233.45.32])
	by mail.tml.hut.fi (Postfix) with ESMTP id A004F3A2CD7;
	Thu, 19 Apr 2007 17:52:00 +0300 (EEST)
Received: from t-110-gw.tml.hut.fi (t-110-gw.tml.hut.fi [130.233.45.45]) by
	horde.tml.hut.fi (Horde MIME library) with HTTP;
	Thu, 19 Apr 2007 17:52:00 +0300
Message-ID: <20070419175200.g160v60gbo88kk4s@horde-intra.tml.hut.fi>
Date: Thu, 19 Apr 2007 17:52:00 +0300
From: sergiole@tml.hut.fi
To: sip@ietf.org
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.3)
X-TML-Virus-Scanned: amavisd-new-2.3.2-tml at tml.hut.fi
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on putosiko.hut.fi
X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at putosiko.hut.fi
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: Cullen Jennings <fluffy@cisco.com>, Rohan Mahy <rohan@ekabal.com>
Subject: [Sip] outbound08 - Handling Responses in Edge proxy / Via vs.
	Flowtoken
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org



Hi,


  I have a question related to handling Responses that are going to be =20
sent over a flow in an Edge proxy.

  In "5.3.  Forwarding Requests (outbound08)" I read that a Request is =20
forwarded to a flow using the information retrieved from the flow =20
token (and that it is found in the Route-header).

  Now I am considering how is the case for Responses.

  Should we consider the same behavior? i.e. forward a Response over a =20
flow using the flowtoken found in the Path-header?

  In 'non-outbound SIP', as far as I understand, Route Header forces =20
the routing in Requests, and Via-header forces routing in Responses.

  So... should we avoid any consideration to the information stored in =20
the topmost Via-header when proxying a Response? (And instead use the =20
information in the flowtoken ?)

  I think that the answers is yes, since the Via could contain a =20
private address in the case of a NAT in the middle. Then, shouldn't be =20
mentioned the response case in the draft?


Regards,


Sergio





_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 19 14:27:54 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HebKy-0004J7-7R; Thu, 19 Apr 2007 14:26:32 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HebKw-0004Gf-Oq
	for sip-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 14:26:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HebKw-0004GX-FO
	for sip@ietf.org; Thu, 19 Apr 2007 14:26:30 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HebKw-0000P5-58
	for sip@ietf.org; Thu, 19 Apr 2007 14:26:30 -0400
Received: from [206.176.144.212] (rcdn4-dmznat-gw1-nat-27.cisco.com
	[12.5.186.27]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3JHXBTe002498
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 19 Apr 2007 12:33:16 -0500
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10171246@zrc2hxm0.corp.nortel.com>
References: <4616851D.5070305@softarmor.com> <461F8385.3080905@cisco.com>
	<461F96EE.3030400@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10051E72@zrc2hxm0.corp.nortel.com>
	<0273BBE3-0172-400D-95EC-C695EFB1EB6F@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100529C9@zrc2hxm0.corp.nortel.com>
	<46245D01.3070301@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF100DE885@zrc2hxm0.corp.nortel.com>
	<4624D827.6070707@cisco.com>
	<0385B548-D90B-40E1-9586-B130F30BB499@softarmor.com>
	<66cd252f0704172214u2543b86dl51158e8683de7b1d@mail.gmail.com>
	<FEB3A550-D1B4-4213-BCA2-769531AB61E3@softarmor.com>
	<46264785.1010409@cisco.com> <20070418163512.AC7D9AC2CE@taimen>
	<46264B4F.9000305@cisco.com> <17958.21520.646271.812068@tutpro.com>
	<6CF7278C-D0B3-441A-AC26-D228D3551710@softarmor.com>
	<17958.25751.480744.939033@tutpro.com>
	<20070418184613.66B115C027@laser.networkresonance.com>
	<F96D8CC3-5621-4385-9F0C-A3612734AA4C@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF1017109F@zrc2hxm0.corp.nortel.!
	! ! com> <2 BA39C33-926E-4E19-83CC-7195B33D8D79@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF10171246@zrc2hxm0.corp.nortel.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <B991FA17-EE24-48DC-9D1F-1EACF19F2269@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Thu, 19 Apr 2007 13:26:19 -0500
To: Francois Audet <audet@nortel.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 18, 2007, at 10:45 PM, Francois Audet wrote:

>
>> So let's explore this in the context of a UA to UA
>> relationship without an outbound proxy, using our old friends
>> Alice and Bob.
>
> Ok, assuming there are no proxies whatsoever in this case.
>
> Alice does a DNS query and it resolves directly to Bob, or maybe some
> p2p sip magic, and figures out where Bob is.
>
>> If Alice's UA supports TLS and she has a SIPS URI for Bob, it
>> seems like (if your wording says what you think it says) that
>> Alice's UA MUST use TLS when trying to contact Bob.
>
> Yes. That is correct. And SIPS too.
>
>> If Alice's UA supports SIPS and she has both a SIP and a SIPS
>> URI for Bob, can she use either one as long as she uses TLS?
>> Or does she have to use the SIPS URI?
>
> She can use whatever she wants, SIP or SIPS. If she uses SIPS
> (which is recommended), then she MUST use TLS.
>
> If she uses SIP, she SHOULD use TLS but doesn't have to.
>

Ok. Here we have a challenge.

We SHOULD use TLS, but we have no reason to expect it will work, and  
no mechanism (short of trying it) to see if it will work. I don't see  
any way to make this better, but I can still wish for one. If we are,  
in short, recommending that one always uses TLS, it would seem like  
we need to say more about how to discover its applicability with more  
efficiency.

 From one POV, trying it isn't that hard -- since it runs on a  
different port, we might get an ICMP port unreachable response fairly  
quickly if it just isn't there.

And DNS can help us discover if a proxy supports TLS.

Maybe the requirement here is something that should be pushed onto  
the discovery method (like DNS or P2P discovery). The problem here is  
that the registration model (which presumably influences how  
something might exist in order to be discovered) says registering  
SIPS means you can take SIPS and SIP. This makes it hard to leverage  
the registration model into a reasonable solution for the proxyless  
use case. If, on the other hand, a SIP registration meant you could  
get SIP (and implied, as it does, nothing about SIPS), and a SIPS  
registration meant you could get SIPS (and implied nothing about  
SIP), then it would be a lot easier to re-use registration to build a  
correct proxyless discover model.

>> If Alice has only a SIP URI for Bob, but his UA supports TLS,
>> how does Alice's UA discover this? Does it have to try
>> connecting via TLS first, and if that fails fall back to TCP or UDP?
>
> She can try to establish a TLS connection to Bob if she wants, but it
> may not work. She may not have Bob's user certificate for example. And
> why would she only have a SIP URI if Bob is reachable with SIPS?

She might have only a SIP URI because that's what was printed on the  
business card, or because that's what she guessed from Bob's email  
address.

>
> It's entirely up to her (or her UAC) to decide if she (it) wishes to
> incur
> the cost "trying" TLS (and potentially sips although it doesn't change
> anything in this p2p sceanrio) "all the time".
>
> Since this p2p stuff and TLS assumes the existence of a global PKI
> based on user certs, I'm not sure why we are spending so much time on
> it.

because even self-signed certs would eliminate the particular attack  
I'm talking about. Sure, they don't give all the authentication  
functions of trusted-ca-signed certs, but the confidentiality  
protection is much better than SIP/UDP.

--
Dean



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 19 23:30:51 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HejpS-0000Wk-Db; Thu, 19 Apr 2007 23:30:34 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HejpQ-0000Wf-Cr
	for sip-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 23:30:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HejpQ-0000WX-32
	for sip@ietf.org; Thu, 19 Apr 2007 23:30:32 -0400
Received: from [74.95.2.169] (helo=delta.rtfm.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HejpO-0002pb-Qq
	for sip@ietf.org; Thu, 19 Apr 2007 23:30:32 -0400
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1])
	by delta.rtfm.com (Postfix) with ESMTP id C32ED33C21;
	Wed, 18 Apr 2007 16:55:09 -0700 (PDT)
Date: Wed, 18 Apr 2007 16:55:09 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: "Samir Srivastava" <samirsr@nortel.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E61256211E@zrc2hxm2.corp.nortel.com>
References: <20070418224536.3F4D65C027@laser.networkresonance.com>
	<62B9B0847CC47543B6B3B5E26BD268E61256211E@zrc2hxm2.corp.nortel.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20070418235509.C32ED33C21@delta.rtfm.com>
X-Spam-Score: 0.4 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>,
	Juha Heinanen <jh@tutpro.com>, Dean Willis <dean.willis@softarmor.com>,
	Paul Kyzivat <pkyzivat@cisco.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

At Wed, 18 Apr 2007 18:33:29 -0500,
Samir Srivastava wrote:
> SIP infrastructure is used for transporting this URI's also. So I much
> more concerned.
> As there is nothing for this. I don't know how many times this question
> I need to raise.
> Plain simple accept SIPS as per 3261 is broken, and we need something
> more meaninful.

Yes, this is the point on which we disagree. 

At this point we've been over this argument a number of times and we're
not convincing each other, so I don't see much point in continuing
this conversation.

-Ekr



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 20 00:21:39 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hekcq-0001dQ-26; Fri, 20 Apr 2007 00:21:36 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hekco-0001Xc-1a
	for sip-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 00:21:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hekcn-0001W9-Mr
	for sip@ietf.org; Fri, 20 Apr 2007 00:21:33 -0400
Received: from ondar.cablelabs.com ([192.160.73.61])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hekcm-0007lN-Ba
	for sip@ietf.org; Fri, 20 Apr 2007 00:21:33 -0400
Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7])
	by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l3K4LSFa007289;
	Thu, 19 Apr 2007 22:21:28 -0600 (MDT)
Received: from srvxchg.cablelabs.com (10.5.0.20)
	by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com);
	Thu, 19 Apr 2007 22:21:28 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com)
Received: from srvxchg3.cablelabs.com ([10.5.0.25]) by srvxchg.cablelabs.com
	with Microsoft SMTPSVC(5.0.2195.6713); 
	Thu, 19 Apr 2007 22:21:27 -0600
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: [Sip] outbound08 - Handling Responses in Edge proxy / Via
	vs.Flowtoken
Date: Thu, 19 Apr 2007 22:19:34 -0600
Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C6045F8F@srvxchg3.cablelabs.com>
In-Reply-To: <20070419175200.g160v60gbo88kk4s@horde-intra.tml.hut.fi>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] outbound08 - Handling Responses in Edge proxy / Via
	vs.Flowtoken
Thread-Index: AceCkpE8Y40vJ700QdW9Ox5aa4+t+gAcCpUQ
References: <20070419175200.g160v60gbo88kk4s@horde-intra.tml.hut.fi>
From: "Kevin Johns" <K.Johns@CableLabs.com>
To: <sergiole@tml.hut.fi>, <sip@ietf.org>
X-OriginalArrivalTime: 20 Apr 2007 04:21:27.0711 (UTC)
	FILETIME=[5D517AF0:01C78303]
X-Approved: ondar
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: Cullen Jennings <fluffy@cisco.com>, Rohan Mahy <rohan@ekabal.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Sergio,

Outbound expects that rport is used in the via header for routing of
responses (for UDP that is) see the note in section 4.3. Responses are
routed as defined in 3261 for TCP.

Kevin=20

-----Original Message-----
From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]=20
Sent: Thursday, April 19, 2007 8:52 AM
To: sip@ietf.org
Cc: Cullen Jennings; Rohan Mahy
Subject: [Sip] outbound08 - Handling Responses in Edge proxy / Via
vs.Flowtoken



Hi,


  I have a question related to handling Responses that are going to be
sent over a flow in an Edge proxy.

  In "5.3.  Forwarding Requests (outbound08)" I read that a Request is
forwarded to a flow using the information retrieved from the flow token
(and that it is found in the Route-header).

  Now I am considering how is the case for Responses.

  Should we consider the same behavior? i.e. forward a Response over a
flow using the flowtoken found in the Path-header?

  In 'non-outbound SIP', as far as I understand, Route Header forces the
routing in Requests, and Via-header forces routing in Responses.

  So... should we avoid any consideration to the information stored in
the topmost Via-header when proxying a Response? (And instead use the
information in the flowtoken ?)

  I think that the answers is yes, since the Via could contain a private
address in the case of a NAT in the middle. Then, shouldn't be mentioned
the response case in the draft?


Regards,


Sergio





_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
sip-implementors@cs.columbia.edu for questions on current sip Use
sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 20 02:54:52 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hen13-0001uA-22; Fri, 20 Apr 2007 02:54:45 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hen11-0001tz-ME
	for sip-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 02:54:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hen0y-0001tk-Fa
	for sip@ietf.org; Fri, 20 Apr 2007 02:54:40 -0400
Received: from ihemail1.lucent.com ([135.245.0.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hen0w-0004C3-EC
	for sip@ietf.org; Fri, 20 Apr 2007 02:54:40 -0400
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l3K6sYsE018597
	for <sip@ietf.org>; Fri, 20 Apr 2007 01:54:37 -0500 (CDT)
Received: from cnexp01.bj.lucent.com ([135.252.8.65]) by
	ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 20 Apr 2007 01:54:37 -0500
Received: from CNEXC1U03.BJ.LUCENT.COM ([135.252.8.26]) by
	cnexp01.bj.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 20 Apr 2007 14:54:28 +0800
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: [SIP] a parameter mapping between Q931 and SIP
Date: Fri, 20 Apr 2007 14:54:27 +0800
Message-ID: <094846246BAA514DA99E796AE4E5BAAB05D39B@CNEXC1U03.BJ.LUCENT.COM>
In-Reply-To: <C3C254A0-5B72-4852-B5F5-102206E9D81C@softarmor.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	beingdelivered to a UA
Thread-Index: AceCCPm1CoLwlWFRRM6mDOAUcwVLaABDWVEw
From: "Ding, Zheng \(Derrick\)" <dingzheng@alcatel-lucent.com>
To: <sip@ietf.org>
X-OriginalArrivalTime: 20 Apr 2007 06:54:28.0253 (UTC)
	FILETIME=[BD5904D0:01C78318]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


Hi, All

I have a question:

One parameter in Q931: Network-Specific Facilities.

How to mapping it to SIP, I mean how to fill this value in SIP messages.


Thanks

Derrick


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 20 04:38:26 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeodI-0004Kh-TE; Fri, 20 Apr 2007 04:38:20 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HeodH-0004Kc-Lw
	for sip-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 04:38:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeodH-0004KU-AD
	for sip@ietf.org; Fri, 20 Apr 2007 04:38:19 -0400
Received: from mail153.messagelabs.com ([216.82.253.51])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HeodF-0005Hh-VF
	for sip@ietf.org; Fri, 20 Apr 2007 04:38:19 -0400
X-VirusChecked: Checked
X-Env-Sender: ranjit@motorola.com
X-Msg-Ref: server-4.tower-153.messagelabs.com!1177058296!1537917!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 6673 invoked from network); 20 Apr 2007 08:38:16 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8)
	by server-4.tower-153.messagelabs.com with SMTP;
	20 Apr 2007 08:38:16 -0000
Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134])
	by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3K8cGVU010404
	for <sip@ietf.org>; Fri, 20 Apr 2007 01:38:16 -0700 (MST)
Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143])
	by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l3K8cG0G021219
	for <sip@ietf.org>; Fri, 20 Apr 2007 03:38:16 -0500 (CDT)
Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26])
	by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l3K8cE8T021202
	for <sip@ietf.org>; Fri, 20 Apr 2007 03:38:15 -0500 (CDT)
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: [SIP] a parameter mapping between Q931 and SIP
Date: Fri, 20 Apr 2007 16:38:07 +0800
Message-ID: <750BBC72E178114F9DC4872EBFF29A5B040F12BD@ZMY16EXM66.ds.mot.com>
In-Reply-To: <094846246BAA514DA99E796AE4E5BAAB05D39B@CNEXC1U03.BJ.LUCENT.COM>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [SIP] a parameter mapping between Q931 and SIP
Thread-Index: AceCCPm1CoLwlWFRRM6mDOAUcwVLaABDWVEwAAQnzSA=
X-Priority: 1
Priority: Urgent
Importance: high
References: <C3C254A0-5B72-4852-B5F5-102206E9D81C@softarmor.com>
	<094846246BAA514DA99E796AE4E5BAAB05D39B@CNEXC1U03.BJ.LUCENT.COM>
From: "Avasarala Ranjit-A20990" <ranjit@motorola.com>
To: "Ding, Zheng \(Derrick\)" <dingzheng@alcatel-lucent.com>, <sip@ietf.org>
X-Vontu: Pass
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi

NSF field is optional in SETUP and I don't think this field is really
required in SIP.  But there is a parameter "cic", which can be appended
to INVITE message for identifying the carrier.


Regards
Ranjit

-----Original Message-----
From: Ding, Zheng (Derrick) [mailto:dingzheng@alcatel-lucent.com]=20
Sent: Friday, April 20, 2007 12:24 PM
To: sip@ietf.org
Subject: [SIP] a parameter mapping between Q931 and SIP


Hi, All

I have a question:

One parameter in Q931: Network-Specific Facilities.

How to mapping it to SIP, I mean how to fill this value in SIP messages.


Thanks

Derrick


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
sip-implementors@cs.columbia.edu for questions on current sip Use
sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 20 05:25:08 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HepMX-0001jc-4e; Fri, 20 Apr 2007 05:25:05 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HepMU-0001gN-Ub
	for sip-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 05:25:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HepMU-0001gF-Jr
	for sip@ietf.org; Fri, 20 Apr 2007 05:25:02 -0400
Received: from mx09.lb01.inode.at ([62.99.145.9] helo=mx.inode.at)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HepMT-0004Ps-4b
	for sip@ietf.org; Fri, 20 Apr 2007 05:25:02 -0400
Received: from [195.58.170.124] (port=3851 helo=inode.at)
	by smartmx-09.inode.at with smtp (Exim 4.50)
	id 1HepMS-0003S1-9q; Fri, 20 Apr 2007 11:25:00 +0200
Received: from 194.113.59.80
	(SquirrelMail authenticated user franz.edler@inode.at)
	by webmail.inode.at with HTTP; Fri, 20 Apr 2007 11:25:00 +0200 (CEST)
Message-ID: <194.113.59.80.1177061100.wm@webmail.inode.at>
Date: Fri, 20 Apr 2007 11:25:00 +0200 (CEST)
Subject: Re: [SIP] a parameter mapping between Q931 and SIP
From: <franz.edler@inode.at>
To: <dingzheng@alcatel-lucent.com>
In-Reply-To: <094846246BAA514DA99E796AE4E5BAAB05D39B@CNEXC1U03.BJ.LUCENT.COM>
References: <C3C254A0-5B72-4852-B5F5-102206E9D81C@softarmor.com>
	<094846246BAA514DA99E796AE4E5BAAB05D39B@CNEXC1U03.BJ.LUCENT.COM>
X-Priority: 3
Importance: Normal
X-Mailer: SquirrelMail (version 1.2.8)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

> One parameter in Q931: Network-Specific Facilities.
> How to mapping it to SIP, I mean how to fill this value in SIP messages.

Not defined, therefore not possible.

-franz




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 20 05:34:01 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HepV7-0004Co-U9; Fri, 20 Apr 2007 05:33:57 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HepV6-0003ze-5E
	for sip-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 05:33:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HepV5-0003w3-Nk
	for sip@ietf.org; Fri, 20 Apr 2007 05:33:55 -0400
Received: from mx19.lb01.inode.at ([62.99.145.21] helo=mx.inode.at)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HepV4-0006Qw-EM
	for sip@ietf.org; Fri, 20 Apr 2007 05:33:55 -0400
Received: from [195.58.170.124] (port=6713 helo=inode.at)
	by smartmx-19.inode.at with smtp (Exim 4.50)
	id 1HepV3-0001Lf-Hj; Fri, 20 Apr 2007 11:33:53 +0200
Received: from 194.113.59.80
	(SquirrelMail authenticated user franz.edler@inode.at)
	by webmail.inode.at with HTTP; Fri, 20 Apr 2007 11:33:53 +0200 (CEST)
Message-ID: <194.113.59.80.1177061633.wm@webmail.inode.at>
Date: Fri, 20 Apr 2007 11:33:53 +0200 (CEST)
Subject: RE: [SIP] a parameter mapping between Q931 and SIP
From: <franz.edler@inode.at>
To: <ranjit@motorola.com>
In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B040F12BD@ZMY16EXM66.ds.mot.com>
References: <C3C254A0-5B72-4852-B5F5-102206E9D81C@softarmor.com>
	<094846246BAA514DA99E796AE4E5BAAB05D39B@CNEXC1U03.BJ.LUCENT.COM>
	<750BBC72E178114F9DC4872EBFF29A5B040F12BD@ZMY16EXM66.ds.mot.com>
X-Priority: 1
Importance: High
X-Mailer: SquirrelMail (version 1.2.8)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

> ....  But there is a parameter "cic", which can be appended
> to INVITE message for identifying the carrier.

Ranjit, where is "cic" defined?

- franz





_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 20 05:37:46 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HepYn-0001KQ-C5; Fri, 20 Apr 2007 05:37:45 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HepYm-0001JK-8H
	for sip-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 05:37:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HepYl-0001JA-Ts
	for sip@ietf.org; Fri, 20 Apr 2007 05:37:43 -0400
Received: from mail128.messagelabs.com ([216.82.250.131])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HepYk-0006up-KN
	for sip@ietf.org; Fri, 20 Apr 2007 05:37:43 -0400
X-VirusChecked: Checked
X-Env-Sender: ranjit@motorola.com
X-Msg-Ref: server-8.tower-128.messagelabs.com!1177061861!7943325!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [144.189.100.102]
Received: (qmail 3594 invoked from network); 20 Apr 2007 09:37:41 -0000
Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102)
	by server-8.tower-128.messagelabs.com with SMTP;
	20 Apr 2007 09:37:41 -0000
Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231])
	by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l3K9bfFM003936
	for <sip@ietf.org>; Fri, 20 Apr 2007 02:37:41 -0700 (MST)
Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243])
	by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l3K9beFi011661
	for <sip@ietf.org>; Fri, 20 Apr 2007 04:37:40 -0500 (CDT)
Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26])
	by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l3K9bcIB011641
	for <sip@ietf.org>; Fri, 20 Apr 2007 04:37:39 -0500 (CDT)
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: [SIP] a parameter mapping between Q931 and SIP
Date: Fri, 20 Apr 2007 17:37:33 +0800
Message-ID: <750BBC72E178114F9DC4872EBFF29A5B040F130B@ZMY16EXM66.ds.mot.com>
In-Reply-To: <194.113.59.80.1177061633.wm@webmail.inode.at>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [SIP] a parameter mapping between Q931 and SIP
Thread-Index: AceDLwonkF77QhMHSxumDuBAMeg1XQAAGSdg
X-Priority: 1
Priority: Urgent
Importance: high
References: <C3C254A0-5B72-4852-B5F5-102206E9D81C@softarmor.com>
	<094846246BAA514DA99E796AE4E5BAAB05D39B@CNEXC1U03.BJ.LUCENT.COM>
	<750BBC72E178114F9DC4872EBFF29A5B040F12BD@ZMY16EXM66.ds.mot.com>
	<194.113.59.80.1177061633.wm@webmail.inode.at>
From: "Avasarala Ranjit-A20990" <ranjit@motorola.com>
To: <franz.edler@inode.at>
X-Vontu: Pass
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


In this draft: Extensions to the "tel" URL to Support Number Portability
and Freephone Service : <draft-yu-tel-url-07.txt> =20


Regards
Ranjit

-----Original Message-----
From: franz.edler@inode.at [mailto:franz.edler@inode.at]=20
Sent: Friday, April 20, 2007 3:04 PM
To: Avasarala Ranjit-A20990
Cc: dingzheng@alcatel-lucent.com; sip@ietf.org
Subject: RE: [SIP] a parameter mapping between Q931 and SIP
Importance: High

> ....  But there is a parameter "cic", which can be appended to INVITE=20
> message for identifying the carrier.

Ranjit, where is "cic" defined?

- franz





_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 20 05:49:35 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hepk7-0006gN-Lm; Fri, 20 Apr 2007 05:49:27 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hepk6-0006gF-1g
	for sip-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 05:49:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hepk5-0006g6-OL
	for sip@ietf.org; Fri, 20 Apr 2007 05:49:25 -0400
Received: from szinterscan.utstar.com.cn ([210.21.224.25])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hepk3-0000qZ-Ur
	for sip@ietf.org; Fri, 20 Apr 2007 05:49:25 -0400
Received: from szsmtp.utstar.com.cn ([172.19.224.12]) by
	szinterscan.utstar.com.cn with InterScan Messaging Security
	Suite; Fri, 20 Apr 2007 18:00:39 +0800
Received: from SZMAIL11.cn.utstarcom.com (szmail03.cn.utstarcom.com
	[172.19.30.102] (may be forged))
	by szsmtp.utstar.com.cn (8.11.6/8.11.1) with ESMTP id l3K9nBT06832;
	Fri, 20 Apr 2007 17:49:11 +0800
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: =?gb2312?B?tPC4tDogW1NJUF0gYSBwYXJhbWV0ZXIgbWFwcGluZyBiZXR3ZWVuIFE5MzE=?=
	=?gb2312?B?IGFuZCBTSVA=?=
Date: Fri, 20 Apr 2007 17:49:10 +0800
Message-ID: <F00B060D0226A4418CEF506B97F42608035212EB@SZMAIL11.cn.utstarcom.com>
In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B040F130B@ZMY16EXM66.ds.mot.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [SIP] a parameter mapping between Q931 and SIP
Thread-Index: AceDLwonkF77QhMHSxumDuBAMeg1XQAAGSdgAABKcmA=
References: <C3C254A0-5B72-4852-B5F5-102206E9D81C@softarmor.com><094846246BAA514DA99E796AE4E5BAAB05D39B@CNEXC1U03.BJ.LUCENT.COM><750BBC72E178114F9DC4872EBFF29A5B040F12BD@ZMY16EXM66.ds.mot.com><194.113.59.80.1177061633.wm@webmail.inode.at>
	<750BBC72E178114F9DC4872EBFF29A5B040F130B@ZMY16EXM66.ds.mot.com>
From: "Gerald Yan" <gerald.yan@utstar.com>
To: "Avasarala Ranjit-A20990" <ranjit@motorola.com>, <franz.edler@inode.at>
X-Spam-Score: 0.5 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Updated.
RFC4694, Number Portability Parameters for the "tel" URI

Best regards
Gerald

-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com] =

=B7=A2=CB=CD=CA=B1=BC=E4: 2007-04-20 17:38
=CA=D5=BC=FE=C8=CB: franz.edler@inode.at
=B3=AD=CB=CD: sip@ietf.org
=D6=F7=CC=E2: RE: [SIP] a parameter mapping between Q931 and SIP
=D6=D8=D2=AA=D0=D4: =B8=DF


In this draft: Extensions to the "tel" URL to Support Number Portability
and Freephone Service : <draft-yu-tel-url-07.txt> =20


Regards
Ranjit

-----Original Message-----
From: franz.edler@inode.at [mailto:franz.edler@inode.at]=20
Sent: Friday, April 20, 2007 3:04 PM
To: Avasarala Ranjit-A20990
Cc: dingzheng@alcatel-lucent.com; sip@ietf.org
Subject: RE: [SIP] a parameter mapping between Q931 and SIP
Importance: High

> ....  But there is a parameter "cic", which can be appended to INVITE=20
> message for identifying the carrier.

Ranjit, where is "cic" defined?

- franz





_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 20 09:37:35 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HetIl-00079O-91; Fri, 20 Apr 2007 09:37:27 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HetIj-00078D-6z
	for sip-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 09:37:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HetIi-00076H-RI
	for sip@ietf.org; Fri, 20 Apr 2007 09:37:24 -0400
Received: from mxs1.siemens.at ([194.138.12.131] helo=atvies1zqx.siemens.at)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HetIc-0005yV-ND
	for sip@ietf.org; Fri, 20 Apr 2007 09:37:24 -0400
Received: from vies1kbx.sie.siemens.at ([158.226.129.82])
	by atvies1zqx.siemens.at  with ESMTP id l3KDb90o023686;
	Fri, 20 Apr 2007 15:37:09 +0200
Received: from nets139a.ww300.siemens.net ([158.226.129.98])
	by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id
	l3KDb81C016957; Fri, 20 Apr 2007 15:37:08 +0200
Received: from prga004a.ww300.siemens.net ([163.242.71.105]) by
	nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 20 Apr 2007 15:37:07 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 20 Apr 2007 15:37:06 +0200
Message-ID: <3E4278088AD82C48B4663DDFE762CEF302ED4E3F@prga004a.ww300.siemens.net>
In-Reply-To: <E1HMrLq-0007Rc-2u@ietf.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: New Liaison Statement, "OMA LS 178 on XCAP diff-event" 
Thread-Index: AcdcO2VTcKFD7WVITs+UZNZkyiixFQnEuh1g
References: <E1HMrLq-0007Rc-2u@ietf.org>
From: "Dostal, Pavel" <pavel.dostal@siemens.com>
To: <sip@ietf.org>, <dean.willis@softarmor.com>
X-OriginalArrivalTime: 20 Apr 2007 13:37:07.0828 (UTC)
	FILETIME=[FD939B40:01C78350]
X-purgate: clean
X-purgate: This mail is considered clean
X-purgate-type: clean
X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net
X-purgate-ID: 149917::070420153709-58A7FBB0-19CCD4E0/0-0/0-15
X-purgate-size: 2701/0
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Cc: fluffy@cisco.com, Antti Laurila <Antti.K.Laurila@nokia.com>,
	drage@alcaltel-lucent.com
Subject: [Sip] RE: New Liaison Statement, "OMA LS 178 on XCAP diff-event" 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

All,

As a technical contact from OMA PAG WG, I wonder whether any official
feedback to the "OMA LS 178 on XCAP diff-event" is planned to be
provided by IETF to the OMA PAG WG.
Regards,

Pavel Dostal=20

-----Original Message-----
From: Dean Willis (OMA) [mailto:dean.willis@softarmor.com]=20
Sent: Thursday, March 01, 2007 8:54 PM
To: sip@ietf.org
Cc: drage@alcaltel-lucent.com; fluffy@cisco.com;
dean.willis@softarmor.com; Dostal, Pavel; Antti Laurila; Dostal, Pavel;
Antti Laurila
Subject: New Liaison Statement, "OMA LS 178 on XCAP diff-event"=20


Title: OMA LS 178  on XCAP diff-event
Submission Date: 2007-03-01
URL of the IETF Web page:
https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D303=20
Please reply by 2007-03-23

From: Dean Willis(OMA) <dean.willis@softarmor.com>
To: IETF SIP WG(sip@ietf.org)
Cc: drage@alcaltel-lucent.com
fluffy@cisco.com
dean.willis@softarmor.com
Reponse Contact: Pavel Dostal <pavel.dostal@siemens.com>
Antti Laurila <Antti.K.Laurila@nokia.com>
Technical Contact: Pavel Dostal <pavel.dostal@siemens.com>
Antti Laurila <Antti.K.Laurila@nokia.com>
Purpose: For comment=20
Body: 1	Overview

This liaison seeks IETF SIP WG for the opinion on the XCAP Diff=20
Event Package as drafted in draft-urpalainen-sip-xcap-diff-event-00.

2	Proposal

OMA PAG WG deals with a requirement to enable subscription for
notification of changes in XCAP resource not only to single=20
document but also to single XCAP component (XML element or attribute).=20
This can not be achieved using draft-ietf-sip-xcap-config because the=20
subscription in this case is allowed only to single document or=20
folder.

A new SIP event package "xcap-diff" is defined in
draft-urpalainen-sip-xcap-diff-event-00.=20
This event package allows subscription to a set of XCAP=20
resources where resources can be either folder or document=20
or component identified by node selector.=20

As this functionality fits to current requirements, OMA PAG WG=20
is considering adopting draft-urpalainen-sip-xcap-diff-event-00=20
as the solution for XCAP clients to receive partial changes of=20
the XCAP resources.

3	Requested Action(s)

OMA PAG WG kindly requests IETF SIP WG on the opinion on the=20
XCAP Diff Event Package as drafted in=20
draft-urpalainen-sip-xcap-diff-event-00 and its expected=20
progress.

4	Conclusion

OMA PAG WG would like to thank IETF SIP WG for their kind=20
consideration and response to this liaison request and look=20
forward to future opportunities to work together.
Attachment(s):
     OMA LS 178 on XCAP Diff Event
(https://datatracker.ietf.org/documents/LIAISON/file404.pdf)





_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 20 10:59:59 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeuaZ-0001E8-Rm; Fri, 20 Apr 2007 10:59:55 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HeuaZ-0001E3-4Q
	for sip-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 10:59:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeuaY-0001Dv-R8
	for sip@ietf.org; Fri, 20 Apr 2007 10:59:54 -0400
Received: from smtp-4.hut.fi ([130.233.228.94])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeuaX-0001ez-8t
	for sip@ietf.org; Fri, 20 Apr 2007 10:59:54 -0400
Received: from localhost (katosiko.hut.fi [130.233.228.115])
	by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id l3KExcCh032271;
	Fri, 20 Apr 2007 17:59:38 +0300
Received: from smtp-4.hut.fi ([130.233.228.94])
	by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new,
	port 10024)
	with LMTP id 29702-53-4; Fri, 20 Apr 2007 17:59:37 +0300 (EEST)
Received: from mail.tml.hut.fi (mail.tml.hut.fi [130.233.47.34])
	by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id l3KExO5X032185;
	Fri, 20 Apr 2007 17:59:24 +0300
Received: from localhost (localhost.tml.hut.fi [127.0.0.1])
	by mail.tml.hut.fi (Postfix) with ESMTP id 01C2B3A2CD7;
	Fri, 20 Apr 2007 17:59:24 +0300 (EEST)
Received: from mail.tml.hut.fi ([127.0.0.1])
	by localhost (mail.tml.hut.fi [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 16704-01; Fri, 20 Apr 2007 17:59:22 +0300 (EEST)
Received: from localhost (tml-yp-4.tml.hut.fi [130.233.45.32])
	by mail.tml.hut.fi (Postfix) with ESMTP id 5A5F83A2CCC;
	Fri, 20 Apr 2007 17:59:22 +0300 (EEST)
Received: from t-110-gw.tml.hut.fi (t-110-gw.tml.hut.fi [130.233.45.45]) by
	horde.tml.hut.fi (Horde MIME library) with HTTP;
	Fri, 20 Apr 2007 17:59:22 +0300
Message-ID: <20070420175922.xfff9li17kg4gkc8@horde-intra.tml.hut.fi>
Date: Fri, 20 Apr 2007 17:59:22 +0300
From: sergiole@tml.hut.fi
To: Kevin Johns <K.Johns@CableLabs.com>
Subject: RE: [Sip] outbound08 - Handling Responses in Edge proxy / Via
	vs.Flowtoken
References: <20070419175200.g160v60gbo88kk4s@horde-intra.tml.hut.fi>
	<9AAEDF491EF7CA48AB587781B8F5D7C6045F8F@srvxchg3.cablelabs.com>
In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C6045F8F@srvxchg3.cablelabs.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.3)
X-TML-Virus-Scanned: amavisd-new-2.3.2-tml at tml.hut.fi
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on katosiko.hut.fi
X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
Cc: sip@ietf.org, Cullen Jennings <fluffy@cisco.com>,
	Rohan Mahy <rohan@ekabal.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


Hi,


  Thank you for your answer.

  Perhaps I should emphasize that I am always talking about Edge Proxy =20
behavior handling incoming Responses to be forwarded to a UAC over an =20
existing flow.

  It seems that your answer is related to handling Responses in the =20
UAC, not in the Edge Proxy. Nevertheless I add my comments below:


> Outbound expects that rport is used in the via header for routing of
> responses (for UDP that is) see the note in section 4.3.

  I understand that section 4.3 is for UA behavior.

> Responses are
> routed as defined in 3261 for TCP.

  Yes, but in the case of forwarding Responses to a flow in an Edge =20
Proxy, I understand that the proxy uses the flowtoken information, =20
thus discarding any consideration of the Via-header parameters =20
(different to 3261 approach).

  So.. shouldn't outbound-08 draft explain the case of Responses =20
handled by the Edge Proxy? By common sense I guess that the Response =20
should use the destination stated in the flowtoken, but, as =20
outbound-08 did not formally specify this case, why I could not avoid =20
considering the destination in the Via-header (although it wont work =20
with NAT)?

Regards,

Sergio



Quoting Kevin Johns <K.Johns@CableLabs.com>:

> Sergio,
>
> Outbound expects that rport is used in the via header for routing of
> responses (for UDP that is) see the note in section 4.3. Responses are
> routed as defined in 3261 for TCP.
>
> Kevin
>
> -----Original Message-----
> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
> Sent: Thursday, April 19, 2007 8:52 AM
> To: sip@ietf.org
> Cc: Cullen Jennings; Rohan Mahy
> Subject: [Sip] outbound08 - Handling Responses in Edge proxy / Via
> vs.Flowtoken
>
>
>
> Hi,
>
>
>   I have a question related to handling Responses that are going to be
> sent over a flow in an Edge proxy.
>
>   In "5.3.  Forwarding Requests (outbound08)" I read that a Request is
> forwarded to a flow using the information retrieved from the flow token
> (and that it is found in the Route-header).
>
>   Now I am considering how is the case for Responses.
>
>   Should we consider the same behavior? i.e. forward a Response over a
> flow using the flowtoken found in the Path-header?
>
>   In 'non-outbound SIP', as far as I understand, Route Header forces the
> routing in Requests, and Via-header forces routing in Responses.
>
>   So... should we avoid any consideration to the information stored in
> the topmost Via-header when proxying a Response? (And instead use the
> information in the flowtoken ?)
>
>   I think that the answers is yes, since the Via could contain a private
> address in the case of a NAT in the middle. Then, shouldn't be mentioned
> the response case in the draft?
>
>
> Regards,
>
>
> Sergio
>
>
>
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use
> sip-implementors@cs.columbia.edu for questions on current sip Use
> sipping@ietf.org for new developments on the application of sip
>





_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 20 11:07:58 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeuiK-0004id-PP; Fri, 20 Apr 2007 11:07:56 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HeuiI-0004XY-Sb
	for sip-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 11:07:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeuiI-0004UK-FH
	for sip@ietf.org; Fri, 20 Apr 2007 11:07:54 -0400
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 1HeuiH-0003zE-1m for sip@ietf.org; Fri, 20 Apr 2007 11:07:54 -0400
Received: from [172.17.2.60] ([172.17.2.60]) (authenticated bits=0)
	by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id l3KF7mMb045120
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Fri, 20 Apr 2007 10:07:48 -0500 (CDT)
	(envelope-from bcampen@estacado.net)
In-Reply-To: <CD6CE349CFD30D40BF5E13B3E0D84804024D3F6C@srvxchg.cablelabs.com>
References: <FF6DBE29-A730-4BE4-953C-8042E1E0AE21@estacado.net>
	<CD6CE349CFD30D40BF5E13B3E0D84804024D3F6C@srvxchg.cablelabs.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Message-Id: <95F02881-3F39-4759-BEE0-EC2AD17E13DA@estacado.net>
From: Byron Campen <bcampen@estacado.net>
Subject: Re: [Sip] Ensuring in-dialog stuff works with outbound
Date: Fri, 20 Apr 2007 10:07:43 -0500
To: Kevin Johns <K.Johns@CableLabs.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f
Cc: SIP IETF <sip@ietf.org>, Cullen Jennings <fluffy@cisco.com>,
	Rohan Mahy <rohan@ekabal.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0865612271=="
Errors-To: sip-bounces@ietf.org


--===============0865612271==
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--941507001;
	protocol="application/pkcs7-signature"


--Apple-Mail-3--941507001
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

	Yeah, this is essentially what I was asking. I ended up having a  
conversation with Rohan, and the takeaway was that the outbound- 
enabled UA needed to remember the edge-proxy's Path header, and pre- 
load it as a Route header in outgoing requests over that flow. The  
edge-proxy, when seeing this, would then Record-Route with the same  
(after determining whether this flow-token referred to the source, or  
the destination, it would Record-Route in such a way to keep it from  
getting confused over the direction the flow-token was pointing,  
probably by using a double record-route.)

Best regards,
Byron Campen

> Byron,
>
> Just saw this email and have not seen any responses as of yet...
>
> I am not sure I fully follow your issue, are you trying to figure out
> how to distinguish between non-outbound enabled UAs and outbound  
> enabled
> UAs within the same edge proxy? It also appears you want to be able to
> determine this so you know when to insert a flow token in a record- 
> route
> header to allow for routing of mid-dialog requests?
>
> Is my understand correct?
>
> Kevin
>
>
> -----Original Message-----
> From: Byron Campen [mailto:bcampen@estacado.net]
> Sent: Thursday, April 05, 2007 1:00 PM
> To: SIP IETF
> Cc: Cullen Jennings; Rohan Mahy
> Subject: [Sip] Ensuring in-dialog stuff works with outbound
>
> 	I've been tuning a server implementation of outbound recently,
> and I've come upon a bit of a conundrum. Say we have an endpoint using
> outbound with an edge-proxy. Everything is set up as specified in the
> draft. This endpoint then sends a dialog-forming request. The edge  
> proxy
> has to be able to ensure that in-dialog traffic coming from the other
> direction goes over the same outbound flow, by record-routing with a
> flow token. However, in the non-outbound case, is it downright _wrong_
> for the edge proxy to record-route with a flow-token, because doing so
> breaks target-refreshes. Unfortunately, the edge-proxy is keeping no
> flow state, and has no clue if this dialog-forming request came  
> over an
> outbound flow or not.
>
> I see two choices for fixing this, please pipe up if you see  
> additional
> options:
>
> 1. We require the endpoint to specify whether it wants the outbound
> treatment on each outgoing request, either by including some
> recognizable outbound goo in the request, or by preloading a Route
> header with a flow-token to the edge proxy (using something like
> Service-Route maybe, although interactions between Service-Route and
> Path might be a little weird).
>
> 2. We require proxies to store information on which connections are
> outbound flows, and which are not (this would make the whole  
> exercise of
> stateless flow-tokens moot).
>
> Best regards,
> Byron Campen
>
>


--Apple-Mail-3--941507001
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGKTCCAuIw
ggJLoAMCAQICEAda7Ce+sudhzrOd9CS5wJQwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDkyNTE0NDUzNloXDTA3MDkyNTE0NDUz
NlowRjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUYmNh
bXBlbkBlc3RhY2Fkby5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWxjwykU0M
R1yTjA3db2wzExKsMhLa/mc2ekFkBP9BVXi4OHacKSZM3a9T0bWvPcw97ycBfDZX3q2prMRsPUep
svJWA0wbiWyOtLzuQGWaQQ6rYbvYlRxil/teAJb1fAKdfFXIXXsiqcdHkhbFn/J7oSn1BCz6v9/v
M1zgGNeMPIR34bo9A0hW+QZJxwkSg4KZHdaQ50WcKXtdHdBg46s+0bvDqNmmt7eP91UJk9aiyxyw
ZdWVNxzF1oj+nfsnsaHv1py6l62Je82mHsvIZwdSAic1PtXVpU8QmkLJHPmkBEVtN/uHMQ95xgxi
eFO5hbYuAT9f7V0ZGe7pUJBR3KwdAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGJjYW1wZW5AZXN0YWNh
ZG8ubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAeJC75lz4KrtNdPOovb3fkqzD
i2HXuOtYHCTOPMc5xJGLdqSF5sc8bwd4mIfevi9Ji4Ccj85A6qINQM/v4OjAvxPkwRwXey/YN6kl
19Te3Eh/t9l4zo2wPdbHTipyc8YJ0GAtT4/fwWiboW3+aquk8DGc7ityr9cdAYY1jAud7d0wggM/
MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2Vz
dGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n
MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3
dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWls
QHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB
AMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO
3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gE
f6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6
MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNy
bDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4
MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYv
wPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bG
CE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQG
EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh
d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEAda7Ce+sudhzrOd9CS5wJQwCQYFKw4D
AhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDIw
MTUwNzQ0WjAjBgkqhkiG9w0BCQQxFgQU5mKNXGr7uedvZvx9a7lHSt0GUBIwgYUGCSsGAQQBgjcQ
BDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0
ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHWuwnvrLn
Yc6znfQkucCUMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAhAHWuwnvrLnYc6znfQkucCUMA0GCSqGSIb3DQEBAQUABIIBAH42Hs9r
TgcDi1uyTd16lkUxjUZZ052yS1J8TVHPzhIjQl758q7EhY32c6uvrh3/siJIDwLXuNAybHbIR1s7
wwpeh9i+2FXsVK1aqe9MLcxvcqsTavSowQaocLUrCNWE+BRRjLThQ3OyVn9LpnlL5XiH5kX7ZLWF
r5utsBi2jik24kWEHRE1aGfpGASXJZW+pZcEhdgm+HJ6x6AqtaQ0gwFmX/3fwXxBVMMwAvOdMVKF
GTNI78jbxPZ3jCfuX2xUFmlhZaky6zwKje8nsgSHg2xQ4P8aW7doYP/MsG/9OvTop97eDYDpAtUp
dWvf+tC3R9s15+xoPNdijTVjBV7yv7cAAAAAAAA=

--Apple-Mail-3--941507001--



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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============0865612271==--





From sip-bounces@ietf.org Fri Apr 20 12:19:51 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hevpr-0006CF-RH; Fri, 20 Apr 2007 12:19:47 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hevpr-0006Bx-3M
	for sip-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 12:19:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hevpq-0006Bp-Q0
	for sip@ietf.org; Fri, 20 Apr 2007 12:19:46 -0400
Received: from ondar.cablelabs.com ([192.160.73.61])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hevpq-00014o-A1
	for sip@ietf.org; Fri, 20 Apr 2007 12:19:46 -0400
Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7])
	by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l3KGIv3E008720;
	Fri, 20 Apr 2007 10:18:57 -0600 (MDT)
Received: from srvxchg.cablelabs.com (10.5.0.20)
	by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com);
	Fri, 20 Apr 2007 10:18:56 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com)
Received: from srvxchg3.cablelabs.com ([10.5.0.25]) by srvxchg.cablelabs.com
	with Microsoft SMTPSVC(5.0.2195.6713); 
	Fri, 20 Apr 2007 10:18:56 -0600
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: [Sip] outbound08 - Handling Responses in Edge proxy /
	Viavs.Flowtoken
Date: Fri, 20 Apr 2007 10:18:58 -0600
Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C6045FF4@srvxchg3.cablelabs.com>
In-Reply-To: <20070420175922.xfff9li17kg4gkc8@horde-intra.tml.hut.fi>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] outbound08 - Handling Responses in Edge proxy /
	Viavs.Flowtoken
Thread-Index: AceDXIXUZcPhiDw3SbCAhoFwMJYdXAACYuQQ
References: <20070419175200.g160v60gbo88kk4s@horde-intra.tml.hut.fi><9AAEDF491EF7CA48AB587781B8F5D7C6045F8F@srvxchg3.cablelabs.com>
	<20070420175922.xfff9li17kg4gkc8@horde-intra.tml.hut.fi>
From: "Kevin Johns" <K.Johns@CableLabs.com>
To: <sergiole@tml.hut.fi>
X-OriginalArrivalTime: 20 Apr 2007 16:18:56.0923 (UTC)
	FILETIME=[98A5EEB0:01C78367]
X-Approved: ondar
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb
Cc: sip@ietf.org, Cullen Jennings <fluffy@cisco.com>,
	Rohan Mahy <rohan@ekabal.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Sergio,

Thank you for clarifying your question.

Let me try and provide some more detail, responses are always sent from
the UAS to a UAC and are always routed based on the via header never the
flow token. The flow token is only used for routing of initial requests
from the edge proxy (UAC) to the client (UAS).

Section 4.3 defines the UAC procedures (it is titled sending requests)
and strongly recommends that the UA include the rport in the via header.
When the Edge Proxy gets the INVITE, it will populate the rport
parameter in the UAC inserted via head with the source port in the UDP
header of the received packet. It will also insert the receive parameter
into the same via header entry which contains the source IP address in
the IP header of the received packet. The Edge Proxy then adds its own
via header entry and forwards this INVITE along.

When the edge proxy gets back the response, it will look at the top most
Via header which contains the rport and receive parameter. The Edge
Proxy will then forward the response to the UAC using these parameters
which are routable since they represent the WAN interface of the NAT.
The flow token never comes into play in this case.

This is all defined in RFC 3581 (An Extension to the Session Initiation
Protocol (SIP) for Symmetric Response Routing)

I hope this helps clarify the situation.
Kevin

-----Original Message-----
From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]=20
Sent: Friday, April 20, 2007 8:59 AM
To: Kevin Johns
Cc: sip@ietf.org; Cullen Jennings; Rohan Mahy
Subject: RE: [Sip] outbound08 - Handling Responses in Edge proxy /
Viavs.Flowtoken


Hi,


  Thank you for your answer.

  Perhaps I should emphasize that I am always talking about Edge Proxy
behavior handling incoming Responses to be forwarded to a UAC over an
existing flow.

  It seems that your answer is related to handling Responses in the UAC,
not in the Edge Proxy. Nevertheless I add my comments below:


> Outbound expects that rport is used in the via header for routing of=20
> responses (for UDP that is) see the note in section 4.3.

  I understand that section 4.3 is for UA behavior.

> Responses are
> routed as defined in 3261 for TCP.

  Yes, but in the case of forwarding Responses to a flow in an Edge
Proxy, I understand that the proxy uses the flowtoken information, thus
discarding any consideration of the Via-header parameters (different to
3261 approach).

  So.. shouldn't outbound-08 draft explain the case of Responses handled
by the Edge Proxy? By common sense I guess that the Response should use
the destination stated in the flowtoken, but, as
outbound-08 did not formally specify this case, why I could not avoid
considering the destination in the Via-header (although it wont work
with NAT)?

Regards,

Sergio



Quoting Kevin Johns <K.Johns@CableLabs.com>:

> Sergio,
>
> Outbound expects that rport is used in the via header for routing of=20
> responses (for UDP that is) see the note in section 4.3. Responses are

> routed as defined in 3261 for TCP.
>
> Kevin
>
> -----Original Message-----
> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
> Sent: Thursday, April 19, 2007 8:52 AM
> To: sip@ietf.org
> Cc: Cullen Jennings; Rohan Mahy
> Subject: [Sip] outbound08 - Handling Responses in Edge proxy / Via=20
> vs.Flowtoken
>
>
>
> Hi,
>
>
>   I have a question related to handling Responses that are going to be

> sent over a flow in an Edge proxy.
>
>   In "5.3.  Forwarding Requests (outbound08)" I read that a Request is

> forwarded to a flow using the information retrieved from the flow=20
> token (and that it is found in the Route-header).
>
>   Now I am considering how is the case for Responses.
>
>   Should we consider the same behavior? i.e. forward a Response over a

> flow using the flowtoken found in the Path-header?
>
>   In 'non-outbound SIP', as far as I understand, Route Header forces=20
> the routing in Requests, and Via-header forces routing in Responses.
>
>   So... should we avoid any consideration to the information stored in

> the topmost Via-header when proxying a Response? (And instead use the=20
> information in the flowtoken ?)
>
>   I think that the answers is yes, since the Via could contain a=20
> private address in the case of a NAT in the middle. Then, shouldn't be

> mentioned the response case in the draft?
>
>
> Regards,
>
>
> Sergio
>
>
>
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip Use=20
> sipping@ietf.org for new developments on the application of sip
>





_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 20 12:34:52 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hew4P-0000IT-LB; Fri, 20 Apr 2007 12:34:49 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hew4N-0000IM-Ts
	for sip-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 12:34:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hew4N-0000ID-K6
	for sip@ietf.org; Fri, 20 Apr 2007 12:34:47 -0400
Received: from ondar.cablelabs.com ([192.160.73.61])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hew4M-0004LW-8r
	for sip@ietf.org; Fri, 20 Apr 2007 12:34:47 -0400
Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7])
	by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l3KGXmEm013030;
	Fri, 20 Apr 2007 10:33:49 -0600 (MDT)
Received: from srvxchg.cablelabs.com (10.5.0.20)
	by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com);
	Fri, 20 Apr 2007 10:33:48 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com)
Received: from srvxchg3.cablelabs.com ([10.5.0.25]) by srvxchg.cablelabs.com
	with Microsoft SMTPSVC(5.0.2195.6713); 
	Fri, 20 Apr 2007 10:33:48 -0600
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: [Sip] Ensuring in-dialog stuff works with outbound
Date: Fri, 20 Apr 2007 10:33:53 -0600
Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C6046000@srvxchg3.cablelabs.com>
In-Reply-To: <95F02881-3F39-4759-BEE0-EC2AD17E13DA@estacado.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Ensuring in-dialog stuff works with outbound
Thread-Index: AceDXalg6PfV3DPITQmde7HWbIQrhwAC87Jw
References: <FF6DBE29-A730-4BE4-953C-8042E1E0AE21@estacado.net>
	<CD6CE349CFD30D40BF5E13B3E0D84804024D3F6C@srvxchg.cablelabs.com>
	<95F02881-3F39-4759-BEE0-EC2AD17E13DA@estacado.net>
From: "Kevin Johns" <K.Johns@CableLabs.com>
To: "Byron Campen" <bcampen@estacado.net>
X-OriginalArrivalTime: 20 Apr 2007 16:33:48.0905 (UTC)
	FILETIME=[AC4F9590:01C78369]
X-Approved: ondar
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: SIP IETF <sip@ietf.org>, Cullen Jennings <fluffy@cisco.com>,
	Rohan Mahy <rohan@ekabal.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Byron,

This was along the lines of what I was thinking, but neither outbound
nor RFC 3327 state this.

Kevin=20

-----Original Message-----
From: Byron Campen [mailto:bcampen@estacado.net]=20
Sent: Friday, April 20, 2007 9:08 AM
To: Kevin Johns
Cc: SIP IETF; Cullen Jennings; Rohan Mahy
Subject: Re: [Sip] Ensuring in-dialog stuff works with outbound

	Yeah, this is essentially what I was asking. I ended up having a
conversation with Rohan, and the takeaway was that the outbound- enabled
UA needed to remember the edge-proxy's Path header, and pre- load it as
a Route header in outgoing requests over that flow. The edge-proxy, when
seeing this, would then Record-Route with the same (after determining
whether this flow-token referred to the source, or the destination, it
would Record-Route in such a way to keep it from getting confused over
the direction the flow-token was pointing, probably by using a double
record-route.)

Best regards,
Byron Campen

> Byron,
>
> Just saw this email and have not seen any responses as of yet...
>
> I am not sure I fully follow your issue, are you trying to figure out
> how to distinguish between non-outbound enabled UAs and outbound =20
> enabled
> UAs within the same edge proxy? It also appears you want to be able to
> determine this so you know when to insert a flow token in a record-=20
> route
> header to allow for routing of mid-dialog requests?
>
> Is my understand correct?
>
> Kevin
>
>
> -----Original Message-----
> From: Byron Campen [mailto:bcampen@estacado.net]
> Sent: Thursday, April 05, 2007 1:00 PM
> To: SIP IETF
> Cc: Cullen Jennings; Rohan Mahy
> Subject: [Sip] Ensuring in-dialog stuff works with outbound
>
> 	I've been tuning a server implementation of outbound recently,
> and I've come upon a bit of a conundrum. Say we have an endpoint using
> outbound with an edge-proxy. Everything is set up as specified in the
> draft. This endpoint then sends a dialog-forming request. The edge =20
> proxy
> has to be able to ensure that in-dialog traffic coming from the other
> direction goes over the same outbound flow, by record-routing with a
> flow token. However, in the non-outbound case, is it downright _wrong_
> for the edge proxy to record-route with a flow-token, because doing so
> breaks target-refreshes. Unfortunately, the edge-proxy is keeping no
> flow state, and has no clue if this dialog-forming request came =20
> over an
> outbound flow or not.
>
> I see two choices for fixing this, please pipe up if you see =20
> additional
> options:
>
> 1. We require the endpoint to specify whether it wants the outbound
> treatment on each outgoing request, either by including some
> recognizable outbound goo in the request, or by preloading a Route
> header with a flow-token to the edge proxy (using something like
> Service-Route maybe, although interactions between Service-Route and
> Path might be a little weird).
>
> 2. We require proxies to store information on which connections are
> outbound flows, and which are not (this would make the whole =20
> exercise of
> stateless flow-tokens moot).
>
> Best regards,
> Byron Campen
>
>



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 20 13:16:25 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hewia-00073I-Eq; Fri, 20 Apr 2007 13:16:20 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HewiZ-00073D-OA
	for sip-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 13:16:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HewiZ-000735-Ef
	for sip@ietf.org; Fri, 20 Apr 2007 13:16:19 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HewiZ-0003bE-2M
	for sip@ietf.org; Fri, 20 Apr 2007 13:16:19 -0400
Received: from [192.168.2.103] (rcdn4-dmznat-gw1-nat-27.cisco.com
	[12.5.186.27]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3KGN3ZI008522
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Fri, 20 Apr 2007 11:23:03 -0500
In-Reply-To: <3E4278088AD82C48B4663DDFE762CEF302ED4E3F@prga004a.ww300.siemens.net>
References: <E1HMrLq-0007Rc-2u@ietf.org>
	<3E4278088AD82C48B4663DDFE762CEF302ED4E3F@prga004a.ww300.siemens.net>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <0B0F1FB0-451A-4E18-9582-6C19F8044EC3@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] RE: New Liaison Statement, "OMA LS 178 on XCAP diff-event" 
Date: Fri, 20 Apr 2007 12:16:07 -0500
To: "Dostal, Pavel" <pavel.dostal@siemens.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: Cullen Jennings <fluffy@cisco.com>, IETF SIP List <sip@ietf.org>,
	Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>,
	drage@alcaltel-lucent.com, Antti Laurila <Antti.K.Laurila@nokia.com>,
	mary Barnes <mary.barnes@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 20, 2007, at 8:37 AM, Dostal, Pavel wrote:

> All,
>
> As a technical contact from OMA PAG WG, I wonder whether any official
> feedback to the "OMA LS 178 on XCAP diff-event" is planned to be
> provided by IETF to the OMA PAG WG.
> Regards,

Good question. I posted the following on the SIPPING list on March  
21, and I haven't seen a conclusion in SIPPING yet. Thanks for waking  
us up.


> Several people from the IETF community met as a design team on  
> March 21, 2007 during IETF 68 in Prague to discuss OMA liaison  
> statement 178 on XCAP diff-event. This LS relates to OMA's  
> requirement for an event package for use in monitoring changes to  
> non-configuration XML documents. The document draft-urpalainen-sip- 
> xcap-diff-event-01.txt had been previously submitted with the  
> intent of meeting these requirements.
>
> Attendees at this discussion included:
>
> Jari Urpalainen
> Krisztian Kiss
> Robert Sparks
> Dan Petrie
> Cullen Jennings
> Rohan Mahy
> Sumanth Channabasappa	
> Jonathan Rosenburg
> Dean Willis
>
>
> The conclusion of the meeting was to recommend some changes in the  
> current sipping-config document and to recommend development of a  
> separate xcap-config document tailored to OMA's requirements (while  
> still meeting general IETF applicability goals).
>
> Changes to the sipping-config document include adding the  
> application identifier and error responses previously identified in  
> design team discussion.
>
> The new xcap-event package will need to support several  
> requirements referred to in draft-urpalainen-sip-xcap-diff- 
> event-01.txt, including subscribing to a xcap document or a sub- 
> element of an xcap element. It will also need to support deferred  
> or aggregated notification. The design team recommends starting  
> with the text in draft-urpalainen-sip-xcap-diff-event-01.txt, but  
> has not agreed to the current  re-synch mechanism therein which is  
> expected to require some further work. This package could be  
> developed either as a WG effort (probably within the SIPPING  
> working group) or as an area-director sponsored individual  
> contribution. The design team feels that the general applicability  
> of this specification is sufficiently broad that it should be  
> pursued as a standards track effort, even though RFC 3325 and 3427  
> allows informational documents to define event packages of this sort.
>
> If this recommendation is accepted or declined we will need to  
> respond with an appropriate LS to OMA informing them of our intent.  
> They would like an answer within the next week or so.

--
Dean Willis


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 20 14:57:53 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeyIo-0006kb-2k; Fri, 20 Apr 2007 14:57:50 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HeyIm-0006kV-H2
	for sip-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 14:57:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeyIm-0006kN-7Y
	for sip@ietf.org; Fri, 20 Apr 2007 14:57:48 -0400
Received: from zrtps0kn.nortel.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeyIk-0003zC-Ve
	for sip@ietf.org; Fri, 20 Apr 2007 14:57:48 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3KIvhx04233; Fri, 20 Apr 2007 18:57:43 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Fri, 20 Apr 2007 13:57:42 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E612624666@zrc2hxm2.corp.nortel.com>
In-Reply-To: <20070418235509.C32ED33C21@delta.rtfm.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
thread-index: AceC/EFZ5qAnk9eoQi6qeqjskuFshwAgUMzg
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Eric Rescorla" <ekr@networkresonance.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: sip@ietf.org, Juha Heinanen <jh@tutpro.com>,
	Francois Audet <audet@nortel.com>, Paul Kyzivat <pkyzivat@cisco.com>,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I propose to present my proposal in Chicago as a part of cipher-suite
updation, and then we can have the hum there. This will close the issue
either way.=20

I think it should be acceptable by chairs and group.=20

Thx
Samir =20

>-----Original Message-----
>From: Eric Rescorla [mailto:ekr@networkresonance.com]=20
>Sent: Wednesday, April 18, 2007 4:55 PM
>To: Srivastava, Samir (SC100:8826)
>Cc: Eric Rescorla; Juha Heinanen; sip@ietf.org; Paul Kyzivat;=20
>Audet, Francois (SC100:3055); Dean Willis
>Subject: Re: [Sip] SIPS question: How to prevent plaintext=20
>requests from being delivered to a UA
>
>At Wed, 18 Apr 2007 18:33:29 -0500,
>Samir Srivastava wrote:
>> SIP infrastructure is used for transporting this URI's also.=20
>So I much=20
>> more concerned.
>> As there is nothing for this. I don't know how many times this=20
>> question I need to raise.
>> Plain simple accept SIPS as per 3261 is broken, and we need=20
>something=20
>> more meaninful.
>
>Yes, this is the point on which we disagree.=20
>
>At this point we've been over this argument a number of times=20
>and we're not convincing each other, so I don't see much point=20
>in continuing this conversation.
>
>-Ekr
>
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 20 15:28:17 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeymF-0006jW-P9; Fri, 20 Apr 2007 15:28:15 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HeymD-0006cR-1Q
	for sip-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 15:28:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeymC-0006cJ-O0
	for sip@ietf.org; Fri, 20 Apr 2007 15:28:12 -0400
Received: from zrtps0kp.nortel.com ([47.140.192.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeymB-0003d1-BA
	for sip@ietf.org; Fri, 20 Apr 2007 15:28:12 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3KJS7C03660; Fri, 20 Apr 2007 19:28:07 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Fri, 20 Apr 2007 14:27:59 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E612624700@zrc2hxm2.corp.nortel.com>
In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E612624666@zrc2hxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
thread-index: AceC/EFZ5qAnk9eoQi6qeqjskuFshwAgUMzgAABBIzA=
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Samir Srivastava" <samirsr@nortel.com>,
	"Eric Rescorla" <ekr@networkresonance.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: sip@ietf.org, Juha Heinanen <jh@tutpro.com>,
	Francois Audet <audet@nortel.com>, Paul Kyzivat <pkyzivat@cisco.com>,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I got the personal request from others, whatever happens in the meeting,
that should achieve the consensus on the list too. I am firm believer of
this, as email list addresses the wider audience.

Thx
Samir

>-----Original Message-----
>From: Srivastava, Samir (SC100:8826)=20
>Sent: Friday, April 20, 2007 11:58 AM
>To: Eric Rescorla
>Cc: sip@ietf.org; Juha Heinanen; Audet, Francois (SC100:3055);=20
>Paul Kyzivat; Dean Willis
>Subject: RE: [Sip] SIPS question: How to prevent plaintext=20
>requests from being delivered to a UA
>
>I propose to present my proposal in Chicago as a part of=20
>cipher-suite updation, and then we can have the hum there.=20
>This will close the issue either way.=20
>
>I think it should be acceptable by chairs and group.=20
>
>Thx
>Samir =20
>
>>-----Original Message-----
>>From: Eric Rescorla [mailto:ekr@networkresonance.com]
>>Sent: Wednesday, April 18, 2007 4:55 PM
>>To: Srivastava, Samir (SC100:8826)
>>Cc: Eric Rescorla; Juha Heinanen; sip@ietf.org; Paul Kyzivat; Audet,=20
>>Francois (SC100:3055); Dean Willis
>>Subject: Re: [Sip] SIPS question: How to prevent plaintext requests=20
>>from being delivered to a UA
>>
>>At Wed, 18 Apr 2007 18:33:29 -0500,
>>Samir Srivastava wrote:
>>> SIP infrastructure is used for transporting this URI's also.=20
>>So I much
>>> more concerned.
>>> As there is nothing for this. I don't know how many times this=20
>>> question I need to raise.
>>> Plain simple accept SIPS as per 3261 is broken, and we need
>>something
>>> more meaninful.
>>
>>Yes, this is the point on which we disagree.=20
>>
>>At this point we've been over this argument a number of times=20
>and we're=20
>>not convincing each other, so I don't see much point in=20
>continuing this=20
>>conversation.
>>
>>-Ekr
>>
>>
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol Use=20
>sip-implementors@cs.columbia.edu for questions on current sip=20
>Use sipping@ietf.org for new developments on the application of sip
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 20 15:39:34 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeyxB-0000SM-Lw; Fri, 20 Apr 2007 15:39:33 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HeyxA-0000Nv-5k
	for sip-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 15:39:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Heyx9-0000Nm-SM
	for sip@ietf.org; Fri, 20 Apr 2007 15:39:31 -0400
Received: from zrtps0kn.nortel.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Heyx2-0005Kg-On
	for sip@ietf.org; Fri, 20 Apr 2007 15:39:31 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3KJdMx18937; Fri, 20 Apr 2007 19:39:22 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Fri, 20 Apr 2007 14:39:07 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF10219256@zrc2hxm0.corp.nortel.com>
In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E612624666@zrc2hxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
thread-index: AceC/EFZ5qAnk9eoQi6qeqjskuFshwAgUMzgAAFw0wA=
References: <20070418235509.C32ED33C21@delta.rtfm.com>
	<62B9B0847CC47543B6B3B5E26BD268E612624666@zrc2hxm2.corp.nortel.com>
From: "Francois Audet" <audet@nortel.com>
To: "Samir Srivastava" <samirsr@nortel.com>,
	"Eric Rescorla" <ekr@networkresonance.com>, <drage@alcatel-lucent.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: sip@ietf.org, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Let's clarify what your proposal is.

You are proposing that we have a hum on your proposal (whatever it is).

This in no way has any impact on the existing work of the WG, including
the draft-ietf-sip-sips draft.

Thanks.

> -----Original Message-----
> From: Srivastava, Samir (SC100:8826)=20
> Sent: Friday, April 20, 2007 11:58
> To: Eric Rescorla
> Cc: Juha Heinanen; sip@ietf.org; Paul Kyzivat; Audet,=20
> Francois (SC100:3055); Dean Willis
> Subject: RE: [Sip] SIPS question: How to prevent plaintext=20
> requests from being delivered to a UA
>=20
> I propose to present my proposal in Chicago as a part of=20
> cipher-suite updation, and then we can have the hum there.=20
> This will close the issue either way.=20
>=20
> I think it should be acceptable by chairs and group.=20
>=20
> Thx
> Samir =20
>=20
> >-----Original Message-----
> >From: Eric Rescorla [mailto:ekr@networkresonance.com]
> >Sent: Wednesday, April 18, 2007 4:55 PM
> >To: Srivastava, Samir (SC100:8826)
> >Cc: Eric Rescorla; Juha Heinanen; sip@ietf.org; Paul Kyzivat; Audet,=20
> >Francois (SC100:3055); Dean Willis
> >Subject: Re: [Sip] SIPS question: How to prevent plaintext requests=20
> >from being delivered to a UA
> >
> >At Wed, 18 Apr 2007 18:33:29 -0500,
> >Samir Srivastava wrote:
> >> SIP infrastructure is used for transporting this URI's also.=20
> >So I much
> >> more concerned.
> >> As there is nothing for this. I don't know how many times this=20
> >> question I need to raise.
> >> Plain simple accept SIPS as per 3261 is broken, and we need
> >something
> >> more meaninful.
> >
> >Yes, this is the point on which we disagree.=20
> >
> >At this point we've been over this argument a number of=20
> times and we're=20
> >not convincing each other, so I don't see much point in=20
> continuing this=20
> >conversation.
> >
> >-Ekr
> >
> >
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 20 16:10:52 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HezQb-0001Ge-33; Fri, 20 Apr 2007 16:09:57 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HezQZ-0001Fo-OS
	for sip-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 16:09:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HezEC-00077w-AP
	for sip@ietf.org; Fri, 20 Apr 2007 15:57:09 -0400
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HezEB-0002Jp-H8
	for sip@ietf.org; Fri, 20 Apr 2007 15:57:07 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	l3KJuNo12227; Fri, 20 Apr 2007 19:56:23 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Fri, 20 Apr 2007 14:56:57 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E61262479C@zrc2hxm2.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10219256@zrc2hxm0.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
thread-index: AceC/EFZ5qAnk9eoQi6qeqjskuFshwAgUMzgAAFw0wAAAJ6nAA==
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Francois Audet" <audet@nortel.com>,
	"Eric Rescorla" <ekr@networkresonance.com>, <drage@alcatel-lucent.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: sip@ietf.org, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Some audience say personaly and some openly on the list for not adopting
sip-sips as STANDARD track document. The claimed unanimity of the prague
is not depicted in the meeting minutes and on the list. It is still
highly contentious.

The next version of the draft is shaping up. Please wait. As I mentioned
earlier, I feel cipher-suites are needed and the Proxy-Require and
Require for that makes SIPS redundant.
There are other issues too, which you feel are beaten to death.=20

Does the presentation of cipher-suite harm your work. If group likes my
proposal, then only it will be changed to INFORMATIONAL / BCP from
STANDARDS track which you are proposing currently. Though I had my own
reservation on any of these guidelines. That is my personal opinion.

I feel, there has been lot of discussion on the cipher-suites after
Montreal, and its presentation to the group is due. If chairs don't want
to allow it, then I am okay. I am leaving this to chairs to decide.

Thx
Samir

>-----Original Message-----
>From: Audet, Francois (SC100:3055)=20
>Sent: Friday, April 20, 2007 12:39 PM
>To: Srivastava, Samir (SC100:8826); 'Eric Rescorla'; Keith=20
>DRAGE (drage@alcatel-lucent.com)
>Cc: 'sip@ietf.org'; 'Dean Willis'
>Subject: RE: [Sip] SIPS question: How to prevent plaintext=20
>requests from being delivered to a UA
>
>Let's clarify what your proposal is.
>
>You are proposing that we have a hum on your proposal (whatever it is).
>
>This in no way has any impact on the existing work of the WG,=20
>including the draft-ietf-sip-sips draft.
>
>Thanks.
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 20 16:25:57 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HezfD-0006KY-4V; Fri, 20 Apr 2007 16:25:03 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HezfB-0006KK-Oz
	for sip-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 16:25:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HezfB-0006KC-FN
	for sip@ietf.org; Fri, 20 Apr 2007 16:25:01 -0400
Received: from [209.213.211.195] (helo=delta.rtfm.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HezfA-0001g2-3H
	for sip@ietf.org; Fri, 20 Apr 2007 16:25:01 -0400
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1])
	by delta.rtfm.com (Postfix) with ESMTP id 3F79B33C1A;
	Fri, 20 Apr 2007 13:25:11 -0700 (PDT)
Date: Fri, 20 Apr 2007 13:25:11 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: "Samir Srivastava" <samirsr@nortel.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E61262479C@zrc2hxm2.corp.nortel.com>
References: <1ECE0EB50388174790F9694F77522CCF10219256@zrc2hxm0.corp.nortel.com>
	<62B9B0847CC47543B6B3B5E26BD268E61262479C@zrc2hxm2.corp.nortel.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20070420202511.3F79B33C1A@delta.rtfm.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>, drage@alcatel-lucent.com,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

At Fri, 20 Apr 2007 14:56:57 -0500,
Samir Srivastava wrote:
> 
> Some audience say personaly and some openly on the list for not adopting
> sip-sips as STANDARD track document. The claimed unanimity of the prague
> is not depicted in the meeting minutes and on the list. It is still
> highly contentious.
> 
> The next version of the draft is shaping up. Please wait. As I mentioned
> earlier, I feel cipher-suites are needed and the Proxy-Require and
> Require for that makes SIPS redundant.
> There are other issues too, which you feel are beaten to death. 
> 
> Does the presentation of cipher-suite harm your work. If group likes my
> proposal, then only it will be changed to INFORMATIONAL / BCP from
> STANDARDS track which you are proposing currently. Though I had my own
> reservation on any of these guidelines. That is my personal opinion.
> 
> I feel, there has been lot of discussion on the cipher-suites after
> Montreal, and its presentation to the group is due. If chairs don't want
> to allow it, then I am okay. I am leaving this to chairs to decide.

I have no objection to having your proposal presented and discussed 
in Chicago. I have a serious objection to holding draft-ietf-sip-sips
pending that discussion.

-Ekr


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 20 17:40:17 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hf0pr-0004ZM-HX; Fri, 20 Apr 2007 17:40:07 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hf0pq-0004VC-NB
	for sip-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 17:40:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf0pq-0004TC-Cc
	for sip@ietf.org; Fri, 20 Apr 2007 17:40:06 -0400
Received: from zrtps0kp.nortel.com ([47.140.192.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hf0pp-0006Z1-5R
	for sip@ietf.org; Fri, 20 Apr 2007 17:40:06 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3KLe2C16118; Fri, 20 Apr 2007 21:40:02 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Fri, 20 Apr 2007 16:39:55 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E61262495F@zrc2hxm2.corp.nortel.com>
In-Reply-To: <20070420202511.3F79B33C1A@delta.rtfm.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
thread-index: AceDify6hhX0ADztT9a/U7jh+MVw0AACSNEA
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Eric Rescorla" <ekr@networkresonance.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>, drage@alcatel-lucent.com,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

>
>I have no objection to having your proposal presented and=20
>discussed in Chicago. I have a serious objection to holding=20
>draft-ietf-sip-sips pending that discussion.

This is where we have contention. As I mentioned earlier if the current
SIPS cloud gets deployed where we don't have
1) Any cipher-suite information
2) No reverse channel to the UAC
3) Loss of confidentiality due to local geographic regions=20
4) Other feature related issues, like what you will do when secure
dialog being replaced
   by unsecure dialog. Presence watchers can use unsecure channeel to
see presence information coming over the secure channel. In a nutshell
no feature control. Other demerits, I don't want to repeat.

Now request coming from the cloud, which addresses all the above, and
then it traverses through currently defined SIPS cloud. We are toast. We
don't have any of the above information. This will be very similar to
Current Secure SIP messages hit the Media Gateway to go to PSTN. We
don't know what is happening afterwards. We will be having another beast
to interoperate where we are missing the information. This is the center
point for deprecating the SIPS as per the current 3261.=20

Thx
Samir

>
>-Ekr
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 20 17:41:54 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hf0ra-0005O1-1F; Fri, 20 Apr 2007 17:41:54 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hf0rY-0005La-N4
	for sip-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 17:41:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf0rY-0005LS-DT
	for sip@ietf.org; Fri, 20 Apr 2007 17:41:52 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hf0rX-0007PG-5R
	for sip@ietf.org; Fri, 20 Apr 2007 17:41:52 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3KLfmv13368; Fri, 20 Apr 2007 21:41:48 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Fri, 20 Apr 2007 16:41:43 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF10219462@zrc2hxm0.corp.nortel.com>
In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E61262495F@zrc2hxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
thread-index: AceDify6hhX0ADztT9a/U7jh+MVw0AACSNEAAABdWVA=
References: <20070420202511.3F79B33C1A@delta.rtfm.com>
	<62B9B0847CC47543B6B3B5E26BD268E61262495F@zrc2hxm2.corp.nortel.com>
From: "Francois Audet" <audet@nortel.com>
To: "Samir Srivastava" <samirsr@nortel.com>,
	"Eric Rescorla" <ekr@networkresonance.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: sip@ietf.org, drage@alcatel-lucent.com,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

No, this is where YOU have contention with the working group.

I agree with Eric.=20

> -----Original Message-----
> From: Srivastava, Samir (SC100:8826)=20
> Sent: Friday, April 20, 2007 14:40
> To: Eric Rescorla
> Cc: Audet, Francois (SC100:3055); drage@alcatel-lucent.com;=20
> sip@ietf.org; Dean Willis
> Subject: RE: [Sip] SIPS question: How to prevent plaintext=20
> requests from being delivered to a UA
>=20
> >
> >I have no objection to having your proposal presented and=20
> discussed in=20
> >Chicago. I have a serious objection to holding draft-ietf-sip-sips=20
> >pending that discussion.
>=20
> This is where we have contention. As I mentioned earlier if=20
> the current SIPS cloud gets deployed where we don't have
> 1) Any cipher-suite information
> 2) No reverse channel to the UAC
> 3) Loss of confidentiality due to local geographic regions
> 4) Other feature related issues, like what you will do when=20
> secure dialog being replaced
>    by unsecure dialog. Presence watchers can use unsecure=20
> channeel to see presence information coming over the secure=20
> channel. In a nutshell no feature control. Other demerits, I=20
> don't want to repeat.
>=20
> Now request coming from the cloud, which addresses all the=20
> above, and then it traverses through currently defined SIPS=20
> cloud. We are toast. We don't have any of the above=20
> information. This will be very similar to Current Secure SIP=20
> messages hit the Media Gateway to go to PSTN. We don't know=20
> what is happening afterwards. We will be having another beast=20
> to interoperate where we are missing the information. This is=20
> the center point for deprecating the SIPS as per the current 3261.=20
>=20
> Thx
> Samir
>=20
> >
> >-Ekr
> >
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 20 17:45:20 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hf0ut-00025B-7t; Fri, 20 Apr 2007 17:45:19 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hf0ur-000254-M7
	for sip-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 17:45:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf0ur-00024w-CT
	for sip@ietf.org; Fri, 20 Apr 2007 17:45:17 -0400
Received: from zrtps0kp.nortel.com ([47.140.192.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hf0ur-0000wQ-56
	for sip@ietf.org; Fri, 20 Apr 2007 17:45:17 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3KLjEC16783; Fri, 20 Apr 2007 21:45:14 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Fri, 20 Apr 2007 16:45:07 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E612624969@zrc2hxm2.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10219462@zrc2hxm0.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
thread-index: AceDify6hhX0ADztT9a/U7jh+MVw0AACSNEAAABdWVAAAAxCoA==
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Francois Audet" <audet@nortel.com>,
	"Eric Rescorla" <ekr@networkresonance.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: sip@ietf.org, drage@alcatel-lucent.com,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Can somebody from the group enlighten me how to do interoperability with
this ? Please talk in the concrete terms of engineering.

Thx
Samir=20

>-----Original Message-----
>From: Audet, Francois (SC100:3055)=20
>Sent: Friday, April 20, 2007 2:42 PM
>To: Srivastava, Samir (SC100:8826); 'Eric Rescorla'
>Cc: 'drage@alcatel-lucent.com'; 'sip@ietf.org'; 'Dean Willis'
>Subject: RE: [Sip] SIPS question: How to prevent plaintext=20
>requests from being delivered to a UA
>
>No, this is where YOU have contention with the working group.
>
>I agree with Eric.=20
>
>> -----Original Message-----
>> From: Srivastava, Samir (SC100:8826)
>> Sent: Friday, April 20, 2007 14:40
>> To: Eric Rescorla
>> Cc: Audet, Francois (SC100:3055); drage@alcatel-lucent.com;=20
>> sip@ietf.org; Dean Willis
>> Subject: RE: [Sip] SIPS question: How to prevent plaintext requests=20
>> from being delivered to a UA
>>=20
>> >
>> >I have no objection to having your proposal presented and
>> discussed in
>> >Chicago. I have a serious objection to holding draft-ietf-sip-sips=20
>> >pending that discussion.
>>=20
>> This is where we have contention. As I mentioned earlier if the=20
>> current SIPS cloud gets deployed where we don't have
>> 1) Any cipher-suite information
>> 2) No reverse channel to the UAC
>> 3) Loss of confidentiality due to local geographic regions
>> 4) Other feature related issues, like what you will do when secure=20
>> dialog being replaced
>>    by unsecure dialog. Presence watchers can use unsecure=20
>channeel to=20
>> see presence information coming over the secure channel. In=20
>a nutshell=20
>> no feature control. Other demerits, I don't want to repeat.
>>=20
>> Now request coming from the cloud, which addresses all the=20
>above, and=20
>> then it traverses through currently defined SIPS cloud. We=20
>are toast.=20
>> We don't have any of the above information. This will be=20
>very similar=20
>> to Current Secure SIP messages hit the Media Gateway to go=20
>to PSTN. We=20
>> don't know what is happening afterwards. We will be having another=20
>> beast to interoperate where we are missing the information. This is=20
>> the center point for deprecating the SIPS as per the current 3261.
>>=20
>> Thx
>> Samir
>>=20
>> >
>> >-Ekr
>> >
>>=20
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sat Apr 21 21:03:47 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HfQUG-00075D-PE; Sat, 21 Apr 2007 21:03:32 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HfQUE-000757-U1
	for sip-confirm+ok@megatron.ietf.org; Sat, 21 Apr 2007 21:03:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HfQUE-00074z-KW
	for sip@ietf.org; Sat, 21 Apr 2007 21:03:30 -0400
Received: from ihemail1.lucent.com ([135.245.0.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfQUC-0004WC-VS
	for sip@ietf.org; Sat, 21 Apr 2007 21:03:30 -0400
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l3M13EjF014994;
	Sat, 21 Apr 2007 20:03:14 -0500 (CDT)
Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by
	ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 21 Apr 2007 20:03:14 -0500
Received: from DEEXC1U01.de.lucent.com ([135.248.187.26]) by
	DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sun, 22 Apr 2007 03:03:11 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPS question: How to prevent plaintext requests
	frombeing	delivered to a UA
Date: Sun, 22 Apr 2007 03:03:11 +0200
Message-ID: <5D1A7985295922448D5550C94DE2918001048519@DEEXC1U01.de.lucent.com>
In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E612624666@zrc2hxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests
	frombeing	delivered to a UA
Thread-Index: AceC/EFZ5qAnk9eoQi6qeqjskuFshwAgUMzgADRydnA=
References: <20070418235509.C32ED33C21@delta.rtfm.com>
	<62B9B0847CC47543B6B3B5E26BD268E612624666@zrc2hxm2.corp.nortel.com>
From: "Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>
To: "Samir Srivastava" <samirsr@nortel.com>,
	"Eric Rescorla" <ekr@networkresonance.com>
X-OriginalArrivalTime: 22 Apr 2007 01:03:11.0932 (UTC)
	FILETIME=[FFB527C0:01C78479]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Cc: sip@ietf.org, Juha Heinanen <jh@tutpro.com>,
	Francois Audet <audet@nortel.com>, Paul Kyzivat <pkyzivat@cisco.com>,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I suggest you submit it in time to obtain discussion on the list, and
then we will see if it merits agenda time or not, based on the interest
displayed and the issues to discuss, versus charter items that will also
need agenda time.=20

For as long as I can remember, we have never been able to satisfy all
the requests for agenda time.

Regards

Keith

=20

> -----Original Message-----
> From: Samir Srivastava [mailto:samirsr@nortel.com]=20
> Sent: Friday, April 20, 2007 7:58 PM
> To: Eric Rescorla
> Cc: sip@ietf.org; Juha Heinanen; Francois Audet; Paul=20
> Kyzivat; Dean Willis
> Subject: RE: [Sip] SIPS question: How to prevent plaintext=20
> requests frombeing delivered to a UA
>=20
> I propose to present my proposal in Chicago as a part of=20
> cipher-suite updation, and then we can have the hum there.=20
> This will close the issue either way.=20
>=20
> I think it should be acceptable by chairs and group.=20
>=20
> Thx
> Samir =20
>=20
> >-----Original Message-----
> >From: Eric Rescorla [mailto:ekr@networkresonance.com]
> >Sent: Wednesday, April 18, 2007 4:55 PM
> >To: Srivastava, Samir (SC100:8826)
> >Cc: Eric Rescorla; Juha Heinanen; sip@ietf.org; Paul Kyzivat; Audet,=20
> >Francois (SC100:3055); Dean Willis
> >Subject: Re: [Sip] SIPS question: How to prevent plaintext requests=20
> >from being delivered to a UA
> >
> >At Wed, 18 Apr 2007 18:33:29 -0500,
> >Samir Srivastava wrote:
> >> SIP infrastructure is used for transporting this URI's also.=20
> >So I much
> >> more concerned.
> >> As there is nothing for this. I don't know how many times this=20
> >> question I need to raise.
> >> Plain simple accept SIPS as per 3261 is broken, and we need
> >something
> >> more meaninful.
> >
> >Yes, this is the point on which we disagree.=20
> >
> >At this point we've been over this argument a number of=20
> times and we're=20
> >not convincing each other, so I don't see much point in=20
> continuing this=20
> >conversation.
> >
> >-Ekr
> >
> >
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 22 22:46:27 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HfoZ0-0005dH-M2; Sun, 22 Apr 2007 22:46:02 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HfoYz-0005dC-K6
	for sip-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 22:46:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HfoYz-0005d4-AL
	for sip@ietf.org; Sun, 22 Apr 2007 22:46:01 -0400
Received: from zrtps0kn.nortel.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfoYz-00079K-0x
	for sip@ietf.org; Sun, 22 Apr 2007 22:46:01 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3N2juM06703; Mon, 23 Apr 2007 02:45:57 GMT
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: [Sip] SIPS question: How to prevent plaintext requests
	frombeing	delivered to a UA
Date: Sun, 22 Apr 2007 21:45:56 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E612624BB3@zrc2hxm2.corp.nortel.com>
In-Reply-To: <5D1A7985295922448D5550C94DE2918001048519@DEEXC1U01.de.lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests
	frombeing	delivered to a UA
thread-index: AceC/EFZ5qAnk9eoQi6qeqjskuFshwAgUMzgADRydnAAQGcSEA==
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>,
	"Eric Rescorla" <ekr@networkresonance.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Cc: sip@ietf.org, Juha Heinanen <jh@tutpro.com>,
	Francois Audet <audet@nortel.com>, Paul Kyzivat <pkyzivat@cisco.com>,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Thx for letting me know the process.=20

But I am still waiting for some directions / answers to my yesterday's
posting for the interworking issue. It will be highly useful to the
group (atleast to me) what other experts think for addressing that
issue.

Thx
Samir

>-----Original Message-----
>From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20
>Sent: Saturday, April 21, 2007 6:03 PM
>To: Srivastava, Samir (SC100:8826); Eric Rescorla
>Cc: sip@ietf.org; Juha Heinanen; Audet, Francois (SC100:3055);=20
>Paul Kyzivat; Dean Willis
>Subject: RE: [Sip] SIPS question: How to prevent plaintext=20
>requests frombeing delivered to a UA
>
>I suggest you submit it in time to obtain discussion on the=20
>list, and then we will see if it merits agenda time or not,=20
>based on the interest displayed and the issues to discuss,=20
>versus charter items that will also need agenda time.=20
>
>For as long as I can remember, we have never been able to=20
>satisfy all the requests for agenda time.
>
>Regards
>
>Keith
>
>=20
>
>> -----Original Message-----
>> From: Samir Srivastava [mailto:samirsr@nortel.com]
>> Sent: Friday, April 20, 2007 7:58 PM
>> To: Eric Rescorla
>> Cc: sip@ietf.org; Juha Heinanen; Francois Audet; Paul Kyzivat; Dean=20
>> Willis
>> Subject: RE: [Sip] SIPS question: How to prevent plaintext requests=20
>> frombeing delivered to a UA
>>=20
>> I propose to present my proposal in Chicago as a part of=20
>cipher-suite=20
>> updation, and then we can have the hum there.
>> This will close the issue either way.=20
>>=20
>> I think it should be acceptable by chairs and group.=20
>>=20
>> Thx
>> Samir
>>=20
>> >-----Original Message-----
>> >From: Eric Rescorla [mailto:ekr@networkresonance.com]
>> >Sent: Wednesday, April 18, 2007 4:55 PM
>> >To: Srivastava, Samir (SC100:8826)
>> >Cc: Eric Rescorla; Juha Heinanen; sip@ietf.org; Paul=20
>Kyzivat; Audet,=20
>> >Francois (SC100:3055); Dean Willis
>> >Subject: Re: [Sip] SIPS question: How to prevent plaintext requests=20
>> >from being delivered to a UA
>> >
>> >At Wed, 18 Apr 2007 18:33:29 -0500,
>> >Samir Srivastava wrote:
>> >> SIP infrastructure is used for transporting this URI's also.=20
>> >So I much
>> >> more concerned.
>> >> As there is nothing for this. I don't know how many times this=20
>> >> question I need to raise.
>> >> Plain simple accept SIPS as per 3261 is broken, and we need
>> >something
>> >> more meaninful.
>> >
>> >Yes, this is the point on which we disagree.=20
>> >
>> >At this point we've been over this argument a number of
>> times and we're
>> >not convincing each other, so I don't see much point in
>> continuing this
>> >conversation.
>> >
>> >-Ekr
>> >
>> >
>>=20
>>=20
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol Use=20
>> sip-implementors@cs.columbia.edu for questions on current sip Use=20
>> sipping@ietf.org for new developments on the application of sip
>>=20
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 22 23:02:39 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hfop2-0002WR-Be; Sun, 22 Apr 2007 23:02:36 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hfop0-0002GL-18
	for sip-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 23:02:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfooz-0002EF-Kr
	for sip@ietf.org; Sun, 22 Apr 2007 23:02:33 -0400
Received: from figas.ekabal.com ([204.61.215.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfooy-0001We-6j
	for sip@ietf.org; Sun, 22 Apr 2007 23:02:33 -0400
Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated)
	by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l3N32FJ03464;
	Sun, 22 Apr 2007 20:02:15 -0700
In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C6046000@srvxchg3.cablelabs.com>
References: <FF6DBE29-A730-4BE4-953C-8042E1E0AE21@estacado.net>
	<CD6CE349CFD30D40BF5E13B3E0D84804024D3F6C@srvxchg.cablelabs.com>
	<95F02881-3F39-4759-BEE0-EC2AD17E13DA@estacado.net>
	<9AAEDF491EF7CA48AB587781B8F5D7C6046000@srvxchg3.cablelabs.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <CB4C9DA9-D77F-4300-B80F-10D02ABA7075@ekabal.com>
Content-Transfer-Encoding: 7bit
From: Rohan Mahy <rohan@ekabal.com>
Subject: Re: [Sip] Ensuring in-dialog stuff works with outbound
Date: Sun, 22 Apr 2007 20:02:13 -0700
To: Kevin Johns <K.Johns@CableLabs.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
Cc: SIP IETF <sip@ietf.org>, Rohan Mahy <rohan@ekabal.com>,
	Cullen Jennings <fluffy@cisco.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi Byron,

Double record-route is not needed.  A simple Record-Route with a flow  
token in the userpart is sufficient from an implementation  
perspective, as long as the edge proxy can use the source of a  
request to determine if a request routed through a particular flow  
token is "coming" or "going".

Also, the draft just says that each edge proxy just needs to do  
whatever is necessary to make sure that subsequent requests get back  
to the same instance.  This leaves the door open for 1) extra edge  
proxies between the first edge proxy and the authoritative proxy to  
step out of the path, 2) edge proxies that record route with a more,  
3) incorporating per call state blobs, (and possibly other things I  
haven't thought of).

thanks,
-rohan

On Apr 20, 2007, at 9:33 AM, Kevin Johns wrote:
> Byron,
>
> This was along the lines of what I was thinking, but neither outbound
> nor RFC 3327 state this.
>
> Kevin
>
> -----Original Message-----
> From: Byron Campen [mailto:bcampen@estacado.net]
> Sent: Friday, April 20, 2007 9:08 AM
> To: Kevin Johns
> Cc: SIP IETF; Cullen Jennings; Rohan Mahy
> Subject: Re: [Sip] Ensuring in-dialog stuff works with outbound
>
> 	Yeah, this is essentially what I was asking. I ended up having a
> conversation with Rohan, and the takeaway was that the outbound-  
> enabled
> UA needed to remember the edge-proxy's Path header, and pre- load  
> it as
> a Route header in outgoing requests over that flow. The edge-proxy,  
> when
> seeing this, would then Record-Route with the same (after determining
> whether this flow-token referred to the source, or the destination, it
> would Record-Route in such a way to keep it from getting confused over
> the direction the flow-token was pointing, probably by using a double
> record-route.)
>
> Best regards,
> Byron Campen
>
>> Byron,
>>
>> Just saw this email and have not seen any responses as of yet...
>>
>> I am not sure I fully follow your issue, are you trying to figure out
>> how to distinguish between non-outbound enabled UAs and outbound
>> enabled
>> UAs within the same edge proxy? It also appears you want to be  
>> able to
>> determine this so you know when to insert a flow token in a record-
>> route
>> header to allow for routing of mid-dialog requests?
>>
>> Is my understand correct?
>>
>> Kevin
>>
>>
>> -----Original Message-----
>> From: Byron Campen [mailto:bcampen@estacado.net]
>> Sent: Thursday, April 05, 2007 1:00 PM
>> To: SIP IETF
>> Cc: Cullen Jennings; Rohan Mahy
>> Subject: [Sip] Ensuring in-dialog stuff works with outbound
>>
>> 	I've been tuning a server implementation of outbound recently,
>> and I've come upon a bit of a conundrum. Say we have an endpoint  
>> using
>> outbound with an edge-proxy. Everything is set up as specified in the
>> draft. This endpoint then sends a dialog-forming request. The edge
>> proxy
>> has to be able to ensure that in-dialog traffic coming from the other
>> direction goes over the same outbound flow, by record-routing with a
>> flow token. However, in the non-outbound case, is it downright  
>> _wrong_
>> for the edge proxy to record-route with a flow-token, because  
>> doing so
>> breaks target-refreshes. Unfortunately, the edge-proxy is keeping no
>> flow state, and has no clue if this dialog-forming request came
>> over an
>> outbound flow or not.
>>
>> I see two choices for fixing this, please pipe up if you see
>> additional
>> options:
>>
>> 1. We require the endpoint to specify whether it wants the outbound
>> treatment on each outgoing request, either by including some
>> recognizable outbound goo in the request, or by preloading a Route
>> header with a flow-token to the edge proxy (using something like
>> Service-Route maybe, although interactions between Service-Route and
>> Path might be a little weird).
>>
>> 2. We require proxies to store information on which connections are
>> outbound flows, and which are not (this would make the whole
>> exercise of
>> stateless flow-tokens moot).
>>
>> Best regards,
>> Byron Campen
>>
>>



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 22 23:21:42 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hfp7U-0002Ei-DU; Sun, 22 Apr 2007 23:21:40 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hfp7S-0002EL-62
	for sip-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 23:21:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfp7R-0002ED-ST
	for sip@ietf.org; Sun, 22 Apr 2007 23:21:37 -0400
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 1Hfp7Q-0004d8-K0 for sip@ietf.org; Sun, 22 Apr 2007 23:21:37 -0400
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-3.cisco.com with ESMTP; 22 Apr 2007 20:21:36 -0700
X-IronPort-AV: i="4.14,439,1170662400"; 
	d="scan'208"; a="480545425:sNHT44839948"
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l3N3LZp6029912; 
	Sun, 22 Apr 2007 20:21:35 -0700
Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id l3N3LTEj019752;
	Mon, 23 Apr 2007 03:21:29 GMT
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
Content-Transfer-Encoding: 7bit
From: Cullen Jennings <fluffy@cisco.com>
Subject: Re: [Sip] draft-ietf-sip-sips-03.txt
Date: Sun, 22 Apr 2007 20:20:57 -0700
To: Francois Audet <audet@nortel.com>
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=797; t=1177298495;
	x=1178162495; c=relaxed/simple; s=sjdkim4002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=fluffy@cisco.com;
	z=From:=20Cullen=20Jennings=20<fluffy@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20draft-ietf-sip-sips-03.txt
	|Sender:=20; bh=VZ0woF9+oJICZLLbZJVp/Ntd1TnN+cE07C4+O4UOCkc=;
	b=uML83kseTpiYARDU8lVKF+5DXPWYaAEmJ9Uz55AZ6Quh6lDsfFCjXB5qEleGWXUMEzFV1ado
	+9hmTgMCaQc4BT3XCF9zHTabormszXAEBMm5uqcbfoR7MKFk9IjS9okT;
Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim4002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 16, 2007, at 3:26 PM, Francois Audet wrote:

>   2.  Do we need the sips option tag? The current document assumes  
> that
>        we do use the option tag, and that is the preference of the
> author.
>        (There is at least one dissenting voice on that one: Hisham).

I'm confused on why we would need it and would want to understand why  
it is needed before commenting on this. I don't buy the needing it to  
enforce deprecate of last hop rule - I see problem in that it leads  
to two bits that mean the same thing and we have to deal with all the  
corner cases of when they conflict. It also makes me wonder if there  
are problems when a URI is copied from one situation to another and  
the REquires: sips header is not.

Cullen <with my individual hat on>



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 22 23:26:54 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HfpCW-0008Fa-Ql; Sun, 22 Apr 2007 23:26:52 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HfpCV-0008FV-3x
	for sip-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 23:26:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HfpCU-0008FN-Qi
	for sip@ietf.org; Sun, 22 Apr 2007 23:26:50 -0400
Received: from [74.95.2.169] (helo=delta.rtfm.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfpCT-0005FN-Hg
	for sip@ietf.org; Sun, 22 Apr 2007 23:26:50 -0400
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1])
	by delta.rtfm.com (Postfix) with ESMTP id E591333C21;
	Sun, 22 Apr 2007 20:27:02 -0700 (PDT)
Date: Sun, 22 Apr 2007 20:27:02 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: "Samir Srivastava" <samirsr@nortel.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests
	frombeing	delivered to a UA
In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E612624BB3@zrc2hxm2.corp.nortel.com>
References: <5D1A7985295922448D5550C94DE2918001048519@DEEXC1U01.de.lucent.com>
	<62B9B0847CC47543B6B3B5E26BD268E612624BB3@zrc2hxm2.corp.nortel.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20070423032702.E591333C21@delta.rtfm.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: sip@ietf.org, Paul Kyzivat <pkyzivat@cisco.com>, "Drage,
	Keith \(Keith\)" <drage@alcatel-lucent.com>, Juha Heinanen <jh@tutpro.com>,
	Dean Willis <dean.willis@softarmor.com>, Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

At Sun, 22 Apr 2007 21:45:56 -0500,
Samir Srivastava wrote:
> 
> Thx for letting me know the process. 
> 
> But I am still waiting for some directions / answers to my yesterday's
> posting for the interworking issue. It will be highly useful to the
> group (atleast to me) what other experts think for addressing that
> issue.

Well I for one, think that your assertions have been addressed adequately
both in person and on the list. I'm sorry you're not satisfied with the
answers, but I don't plan to go through it again absent some evidence
that your concerns are widely shared.

-Ekr



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 22 23:44:00 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HfpT3-00065T-RM; Sun, 22 Apr 2007 23:43:57 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HfpT2-00065O-NA
	for sip-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 23:43:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HfpT2-00065G-Dk
	for sip@ietf.org; Sun, 22 Apr 2007 23:43:56 -0400
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfpT1-0000OH-6O
	for sip@ietf.org; Sun, 22 Apr 2007 23:43:56 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	l3N3h4f06137; Mon, 23 Apr 2007 03:43:05 GMT
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: [Sip] SIPS question: How to prevent plaintext requests
	frombeing	delivered to a UA
Date: Sun, 22 Apr 2007 22:43:40 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E612624BCA@zrc2hxm2.corp.nortel.com>
In-Reply-To: <20070423032702.E591333C21@delta.rtfm.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests
	frombeing	delivered to a UA
thread-index: AceFVz0Q+i2SHEQDR4ywwxlqbACCwQAAXHQQ
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Eric Rescorla" <ekr@networkresonance.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>, "Drage,
	Keith \(Keith\)" <drage@alcatel-lucent.com>, Juha Heinanen <jh@tutpro.com>,
	Dean Willis <dean.willis@softarmor.com>, Paul Kyzivat <pkyzivat@cisco.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Fine, I will wait for the day when others will realize the issue. I hope
the day will come soon.=20

Thx
Samir=20

>-----Original Message-----
>From: Eric Rescorla [mailto:ekr@networkresonance.com]=20
>Sent: Sunday, April 22, 2007 8:27 PM
>To: Srivastava, Samir (SC100:8826)
>Cc: Drage, Keith (Keith); Eric Rescorla; sip@ietf.org; Juha=20
>Heinanen; Audet, Francois (SC100:3055); Paul Kyzivat; Dean Willis
>Subject: Re: [Sip] SIPS question: How to prevent plaintext=20
>requests frombeing delivered to a UA
>
>At Sun, 22 Apr 2007 21:45:56 -0500,
>Samir Srivastava wrote:
>>=20
>> Thx for letting me know the process.=20
>>=20
>> But I am still waiting for some directions / answers to my=20
>yesterday's=20
>> posting for the interworking issue. It will be highly useful to the=20
>> group (atleast to me) what other experts think for addressing that=20
>> issue.
>
>Well I for one, think that your assertions have been addressed=20
>adequately both in person and on the list. I'm sorry you're=20
>not satisfied with the answers, but I don't plan to go through=20
>it again absent some evidence that your concerns are widely shared.
>
>-Ekr
>
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 22 23:53:09 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hfpbm-0004tg-RG; Sun, 22 Apr 2007 23:52:58 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hfpbl-0004tG-OQ
	for sip-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 23:52:57 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfpbl-0004s0-ET
	for sip@ietf.org; Sun, 22 Apr 2007 23:52:57 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfpbk-0003AJ-68
	for sip@ietf.org; Sun, 22 Apr 2007 23:52:57 -0400
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-6.cisco.com with ESMTP; 22 Apr 2007 20:52:55 -0700
X-IronPort-AV: i="4.14,439,1170662400"; 
	d="scan'208"; a="139327094:sNHT44820549"
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3N3qthD017098; 
	Sun, 22 Apr 2007 20:52:55 -0700
Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id l3N3qtZU021032;
	Mon, 23 Apr 2007 03:52:55 GMT
In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E612561C0E@zrc2hxm2.corp.nortel.com>
References: <62B9B0847CC47543B6B3B5E26BD268E612561C0E@zrc2hxm2.corp.nortel.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <545CEE2B-865C-4E91-92DF-E489F60A6DEB@cisco.com>
Content-Transfer-Encoding: 7bit
From: Cullen Jennings <fluffy@cisco.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Sun, 22 Apr 2007 20:52:22 -0700
To: Samir Srivastava <samirsr@nortel.com>
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=506; t=1177300375;
	x=1178164375; c=relaxed/simple; s=sjdkim1004;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=fluffy@cisco.com;
	z=From:=20Cullen=20Jennings=20<fluffy@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20SIPS=20question=3A=20How=20to=20prevent=20pla
	intext=20requests=20from=20being=09delivered=20to=20a=20UA
	|Sender:=20; bh=Ujw0p3sxuLavgh0tcs5Sz5sbGDJbe1gDeSqPppn+N5k=;
	b=UK0fNVdQN71Li03CcYMLEdS/NaF6jfMhUt47VOXlg65oa1uONtCelS5UIB99kBo/cU3gc/Um
	/LtJIDe1D98H64NhCfnmRcFt2m3FDJK3TOI+2zS5BNw6nyNP+dCqRUCg27SQqmFhsIiIUFSVdl
	A4Un+xD3w0eiAgVgzX8kY/hcQ=;
Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim1004 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: SIP <sip@ietf.org>, Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 18, 2007, at 11:39 AM, Samir Srivastava wrote:

>
>
>>
>> good and thus one more reason to junk sips.  we can just say
>> that a proxy should use tls if it supports it.
>>
>
> I am sure that Cullen must be listening this.
>
> Thx
> Samir
>
>

Uh - I'm sort of reading it but I got to admit I'm not sure I am  
getting any information that is new. I'm sure Francois will summarize  
something that I can actually understand sooner or later.

Cullen <with my individual hat on>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 22 23:53:43 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HfpcU-0005tm-NJ; Sun, 22 Apr 2007 23:53:42 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HfpcS-0005tH-U8
	for sip-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 23:53:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HfpcS-0005sw-Jd
	for sip@ietf.org; Sun, 22 Apr 2007 23:53:40 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfpcR-0003Zc-9d
	for sip@ietf.org; Sun, 22 Apr 2007 23:53:40 -0400
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-6.cisco.com with ESMTP; 22 Apr 2007 20:53:38 -0700
X-IronPort-AV: i="4.14,439,1170662400"; 
	d="scan'208"; a="139327307:sNHT45038187"
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3N3rcui017656; 
	Sun, 22 Apr 2007 20:53:38 -0700
Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id l3N3qtZV021032;
	Mon, 23 Apr 2007 03:53:32 GMT
In-Reply-To: <p06240607c24c4974cfae@[129.46.226.38]>
References: <20070418184613.66B115C027@laser.networkresonance.com>
	<62B9B0847CC47543B6B3B5E26BD268E612561C6F@zrc2hxm2.corp.nortel.com>
	<20070418201727.6F9C45C02B@laser.networkresonance.com>
	<p06240604c24c2ff2d564@[129.46.226.38]>
	<20070418205201.1261C5C027@laser.networkresonance.com>
	<p06240607c24c4974cfae@[129.46.226.38]>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <DCA3C5E9-3BE8-4B95-937F-E81766D13913@cisco.com>
Content-Transfer-Encoding: 7bit
From: Cullen Jennings <fluffy@cisco.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Sun, 22 Apr 2007 20:53:05 -0700
To: SIP <sip@ietf.org>
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1059; t=1177300418;
	x=1178164418; c=relaxed/simple; s=sjdkim1004;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=fluffy@cisco.com;
	z=From:=20Cullen=20Jennings=20<fluffy@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20SIPS=20question=3A=20How=20to=20prevent=20pla
	intext=20requests=20from=20=20being=09delivered=20to=20a=20UA
	|Sender:=20; bh=lpO1WdPcKhY0iZ6qa+r6TMq/fqfywa/v/JYzuaxcXDw=;
	b=KSbr7N0AXZ6UAyr4dVKfEUBHvFETdbzv+DE84T+P8eHyFS91IuWTxHsKmEak9fDVVZocPmv7
	J0ReBNkvfW7T+VFfnxgPdso0nTc91UfGAkOjuDgZSpDkP2fabgObxj03RKNVXy3IFwifLbHUeX
	Jkp5LkJlZia/OU513iFAW8+H4=;
Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim1004 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: Francois Audet <audet@nortel.com>, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


I started to write something then realized Ted had already done it -  
when SIP was first done, we could have done SIPS without using two  
schemes but given where we are now it would totally non backwards  
compatible during the transition period from one form to the other so  
I think Ted, Ekr, and I are all thinking that uses sips looks like  
the logical answer.

Cullen <with my individual hat on>

On Apr 18, 2007, at 3:20 PM, Ted Hardie wrote:

> At 1:53 PM -0700 4/18/07, Eric Rescorla wrote:
>> Yes, I agree with this analysis... But unless I misread your message,
>> this is an argument *for* SIPS.
>>
>
> I would put it more as an argument against the effectiveness of  
> change,
> but yes.
> 				Ted
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 23 14:56:24 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hg3hz-0006j6-Qx; Mon, 23 Apr 2007 14:56:19 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hg3hy-0006j1-I7
	for sip-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 14:56:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg3hy-0006is-8c
	for sip@ietf.org; Mon, 23 Apr 2007 14:56:18 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg3hw-0006IM-UK
	for sip@ietf.org; Mon, 23 Apr 2007 14:56:18 -0400
Received: from [64.101.172.87] ([64.101.172.87]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3NI38O0004546
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO)
	for <sip@ietf.org>; Mon, 23 Apr 2007 13:03:09 -0500
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: <E79EA28D-BBB2-4218-A89F-65A909DAE882@softarmor.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: IETF SIP List <sip@ietf.org>
From: Dean Willis <dean.willis@softarmor.com>
Date: Mon, 23 Apr 2007 13:56:06 -0500
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Subject: [Sip] Process question on fixing record-route
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


In Prague we recorded a consensus on documenting the various fixes to  
record-route as described in:

http://www.ietf.org/internet-drafts/draft-froment-sip-record-route- 
fix-00.txt


While we agreed to undertake this effort, we left open the discussion  
of how to achieve it.

Two proposals were made:

1) Recast the solution as a BCP

2) Move this into the "Essential Corrections" process for RFC 3261  
bugfixing.

I currently lean towards number 2, but we should discuss it.

--
Dean



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 23 14:57:37 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hg3jE-0001Xs-M6; Mon, 23 Apr 2007 14:57:36 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hg3jC-0001WN-Q3
	for sip-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 14:57:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg3jC-0001UY-Dk
	for sip@ietf.org; Mon, 23 Apr 2007 14:57:34 -0400
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg3jC-0006iD-5L
	for sip@ietf.org; Mon, 23 Apr 2007 14:57:34 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	l3NIup010350; Mon, 23 Apr 2007 18:56:51 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Mon, 23 Apr 2007 13:57:30 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E6126BBC45@zrc2hxm2.corp.nortel.com>
In-Reply-To: <DCA3C5E9-3BE8-4B95-937F-E81766D13913@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
thread-index: AceFWv7UPFWWtJISSNOq1wy0G857uQAfhcLg
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Cullen Jennings" <fluffy@cisco.com>, "SIP" <sip@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: Francois Audet <audet@nortel.com>, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

>-----Original Message-----
>From: Cullen Jennings [mailto:fluffy@cisco.com]=20
>Sent: Sunday, April 22, 2007 8:53 PM
>To: SIP
>Cc: Audet, Francois (SC100:3055); Dean Willis
>Subject: Re: [Sip] SIPS question: How to prevent plaintext=20
>requests from being delivered to a UA
>
>
>I started to write something then realized Ted had already=20
>done it - when SIP was first done, we could have done SIPS=20
>without using two schemes but given where we are now it would=20
>totally non backwards compatible during the transition period=20
>from one form to the other so I think Ted, Ekr, and I are all=20
>thinking that uses sips looks like the logical answer.
>
>Cullen <with my individual hat on>
>
I think I am failing completely to get my views across the some of the
audience. I am nearing to my end of writing the emails on the list for
deprecating SIPS. No doubts why SKYPE is so successful with properiteray
protocols and they have done it so quickly. Within the standard body, we
are taking a long time to understand it. I don't know what to say.

As far as I interpret from the list, there are some CLAIMED DEPLOYMENT
of SIPS, which I call CHEAT. As feature set itself are broken. I hope
that there users were listening on the earlier postings, how much they
are broken. And they will be beating up their suppliers.

Where we are today, we have some vendors who have implemented it. They
just want to patch it with whatever logic they want to come up , And
create a lot of troubles for our kids to fix it. They just don't want to
accept their mistakes and bear the cost of the development. The cost
should be looked up in total. If the current state of SIPS gets
deployed, then we have to develop some interworking protocols with
USABLE feature set and USERS will be junking SIPS eventually. Today we
have to offset the cost of development only, but if we take the path of
patching it, we have more cost coming forward, network upgrades,
protocol interworking etc.=20

I am hoping that Providers and Enterprise IT departments are listening
on this, whether they want broken feature set where their end users will
cursing them and they have to explain what feature works and what
doesn't work. If call is routed this path or that path, then don't
accept the security. Do the providers and Enterprise IT department want
this hussle to take or they want the complete nice solution with some
waiting time. Whatever we produce, it should be easily
undetstandable/implementable by the implementation community and usable
by the end users. I feel I have failed completely to get my point across
the some of the audience on this.

Thx
Samir


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 23 15:00:06 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hg3la-00033p-RC; Mon, 23 Apr 2007 15:00:02 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hg3lY-00033a-Uy
	for sip-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 15:00:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg3lY-00033S-LS
	for sip@ietf.org; Mon, 23 Apr 2007 15:00:00 -0400
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg3lX-0007Hp-A1
	for sip@ietf.org; Mon, 23 Apr 2007 15:00:00 -0400
Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121])
	(authenticated bits=0)
	by nostrum.com (8.13.8/8.13.8) with ESMTP id l3NIxwWr016055
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Mon, 23 Apr 2007 13:59:58 -0500 (CDT)
	(envelope-from rjsparks@nostrum.com)
In-Reply-To: <E79EA28D-BBB2-4218-A89F-65A909DAE882@softarmor.com>
References: <E79EA28D-BBB2-4218-A89F-65A909DAE882@softarmor.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <28C89681-36C6-4AB6-9CE4-FA7C6A2A6FA9@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [Sip] Process question on fixing record-route
Date: Mon, 23 Apr 2007 13:59:57 -0500
To: Dean Willis <dean.willis@softarmor.com>
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
	mechanism)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I think this should go down the 1) path. This is a recommended use of  
mechanisms that exist, not a change of any normative text.

RjS

On Apr 23, 2007, at 1:56 PM, Dean Willis wrote:

>
> In Prague we recorded a consensus on documenting the various fixes  
> to record-route as described in:
>
> http://www.ietf.org/internet-drafts/draft-froment-sip-record-route- 
> fix-00.txt
>
>
> While we agreed to undertake this effort, we left open the  
> discussion of how to achieve it.
>
> Two proposals were made:
>
> 1) Recast the solution as a BCP
>
> 2) Move this into the "Essential Corrections" process for RFC 3261  
> bugfixing.
>
> I currently lean towards number 2, but we should discuss it.
>
> --
> Dean
>
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 23 15:13:27 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hg3yX-000129-NC; Mon, 23 Apr 2007 15:13:25 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hg3yW-000124-Sh
	for sip-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 15:13:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg3yW-00011w-JB
	for sip@ietf.org; Mon, 23 Apr 2007 15:13:24 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg3yV-0003MO-BS
	for sip@ietf.org; Mon, 23 Apr 2007 15:13:24 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3NJDJ600417; Mon, 23 Apr 2007 19:13:19 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Mon, 23 Apr 2007 14:13:21 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF1021A052@zrc2hxm0.corp.nortel.com>
In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E6126BBC45@zrc2hxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
thread-index: AceFWv7UPFWWtJISSNOq1wy0G857uQAfhcLgAACR8OA=
References: <DCA3C5E9-3BE8-4B95-937F-E81766D13913@cisco.com>
	<62B9B0847CC47543B6B3B5E26BD268E6126BBC45@zrc2hxm2.corp.nortel.com>
From: "Francois Audet" <audet@nortel.com>
To: "Samir Srivastava" <samirsr@nortel.com>,
	"Cullen Jennings" <fluffy@cisco.com>, "SIP" <sip@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

=20

> -----Original Message-----
> From: Srivastava, Samir (SC100:8826)=20
> Sent: Monday, April 23, 2007 11:58
> To: Cullen Jennings; SIP
> Cc: Audet, Francois (SC100:3055); Dean Willis
> Subject: RE: [Sip] SIPS question: How to prevent plaintext=20
> requests from being delivered to a UA
>
> I think I am failing completely to get my views across the=20
> some of the audience.=20

That is a correct statement.


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 23 15:17:13 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hg42C-0003qt-0E; Mon, 23 Apr 2007 15:17:12 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hg42A-0003jO-J9
	for sip-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 15:17:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg42A-0003j5-8p
	for sip@ietf.org; Mon, 23 Apr 2007 15:17:10 -0400
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg429-0004Tc-1Y
	for sip@ietf.org; Mon, 23 Apr 2007 15:17:10 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	l3NJGQ021627; Mon, 23 Apr 2007 19:16:26 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Mon, 23 Apr 2007 14:17:04 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E6126BBCD1@zrc2hxm2.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1021A052@zrc2hxm0.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
thread-index: AceFWv7UPFWWtJISSNOq1wy0G857uQAfhcLgAACR8OAAAAuc0A==
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Francois Audet" <audet@nortel.com>, "Cullen Jennings" <fluffy@cisco.com>, 
	"SIP" <sip@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

BTW, it is _some_ of the audience.=20

Thx
Samir=20

>-----Original Message-----
>From: Audet, Francois (SC100:3055)=20
>Sent: Monday, April 23, 2007 12:13 PM
>To: Srivastava, Samir (SC100:8826); Cullen Jennings; SIP
>Cc: Dean Willis
>Subject: RE: [Sip] SIPS question: How to prevent plaintext=20
>requests from being delivered to a UA
>
>=20
>
>> -----Original Message-----
>> From: Srivastava, Samir (SC100:8826)
>> Sent: Monday, April 23, 2007 11:58
>> To: Cullen Jennings; SIP
>> Cc: Audet, Francois (SC100:3055); Dean Willis
>> Subject: RE: [Sip] SIPS question: How to prevent plaintext requests=20
>> from being delivered to a UA
>>
>> I think I am failing completely to get my views across the=20
>some of the=20
>> audience.
>
>That is a correct statement.
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 23 15:41:17 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hg4PU-0003UP-Fe; Mon, 23 Apr 2007 15:41:16 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hg4PT-0003UK-60
	for sip-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 15:41:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg4PS-0003UC-Se
	for sip@ietf.org; Mon, 23 Apr 2007 15:41:14 -0400
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg4PP-0002Jc-Iz
	for sip@ietf.org; Mon, 23 Apr 2007 15:41:14 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	l3NJeO024201; Mon, 23 Apr 2007 19:40:25 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Mon, 23 Apr 2007 14:41:01 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF1021A0D6@zrc2hxm0.corp.nortel.com>
In-Reply-To: <545CEE2B-865C-4E91-92DF-E489F60A6DEB@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
thread-index: AceFWubEDesOZqPzSRikJgTE/mApAQAg9YaA
References: <62B9B0847CC47543B6B3B5E26BD268E612561C0E@zrc2hxm2.corp.nortel.com>
	<545CEE2B-865C-4E91-92DF-E489F60A6DEB@cisco.com>
From: "Francois Audet" <audet@nortel.com>
To: "Cullen Jennings" <fluffy@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: SIP <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Below.

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]=20
> Sent: Sunday, April 22, 2007 20:52
> To: Srivastava, Samir (SC100:8826)
> Cc: SIP; Audet, Francois (SC100:3055)
> Subject: Re: [Sip] SIPS question: How to prevent plaintext=20
> requests from being delivered to a UA
>=20
>=20
> On Apr 18, 2007, at 11:39 AM, Samir Srivastava wrote:
>=20
> >
> >
> >>
> >> good and thus one more reason to junk sips.  we can just=20
> say that a=20
> >> proxy should use tls if it supports it.
> >>
> >
> > I am sure that Cullen must be listening this.
> >
> > Thx
> > Samir
> >
> >
>=20
> Uh - I'm sort of reading it but I got to admit I'm not sure I=20
> am getting any information that is new. I'm sure Francois=20
> will summarize something that I can actually understand=20
> sooner or later.
>=20
> Cullen <with my individual hat on>

I'm not getting it either.

I think the summary is that Samir wants the group to stop its work
on draft-ietf-sip-sips, and reverse it's already made=20
decision, in order to consider a proposal from him that
he hasn't submitted yet, involving indicating Cypher-suites=20
explicitly and deprecating SIPS altogether.


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 23 16:02:12 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hg4jg-0007mk-PY; Mon, 23 Apr 2007 16:02:08 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hg4jf-0007mf-T6
	for sip-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 16:02:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg4jf-0007mX-IQ
	for sip@ietf.org; Mon, 23 Apr 2007 16:02:07 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg4jf-0006wz-8H
	for sip@ietf.org; Mon, 23 Apr 2007 16:02:07 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3NK23616993; Mon, 23 Apr 2007 20:02:04 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Mon, 23 Apr 2007 15:02:02 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E6126BBE09@zrc2hxm2.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1021A0D6@zrc2hxm0.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
thread-index: AceFWubEDesOZqPzSRikJgTE/mApAQAg9YaAAAAv2DA=
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Francois Audet" <audet@nortel.com>, "Cullen Jennings" <fluffy@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
Cc: SIP <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

It will be coming soon as its in discussion with other folks privately.
BTW, we still have a lot of time before Chicago. And I don't work 100%
time on the IETF proposal writing.

My proposal is depicted in the cipher-suite draft roughly in the 00
version. I have shown so many times on the list that we need
cipher-suite indication, where our security adivisor doesn't seem to be
in the agreement. That version was not talking about the broken features
etc, which had been earlier discussed before San Diego a lot on the
list.=20

And in the next version, I will be talking about the broken features
with respect to 3261. Your proposed patches are not the reference point
for it. And it is catching brokenness of SIPS as the focal point.

I was keeping silent, as I only wanted this to be progress as
BCP/INFORMATIONAL document and then proceed with my proposal. And
recently it was brought to my notice that is being pursed as STANDARD
track document, where I have disconnect and so I am putting more time on
this effort.=20

Thx
Samir

>-----Original Message-----
>From: Audet, Francois (SC100:3055)=20
>Sent: Monday, April 23, 2007 12:41 PM
>To: Cullen Jennings
>Cc: SIP
>Subject: RE: [Sip] SIPS question: How to prevent plaintext=20
>requests from being delivered to a UA
>
>Below.
>
>> -----Original Message-----
>> From: Cullen Jennings [mailto:fluffy@cisco.com]
>> Sent: Sunday, April 22, 2007 20:52
>> To: Srivastava, Samir (SC100:8826)
>> Cc: SIP; Audet, Francois (SC100:3055)
>> Subject: Re: [Sip] SIPS question: How to prevent plaintext requests=20
>> from being delivered to a UA
>>=20
>>=20
>> On Apr 18, 2007, at 11:39 AM, Samir Srivastava wrote:
>>=20
>> >
>> >
>> >>
>> >> good and thus one more reason to junk sips.  we can just
>> say that a
>> >> proxy should use tls if it supports it.
>> >>
>> >
>> > I am sure that Cullen must be listening this.
>> >
>> > Thx
>> > Samir
>> >
>> >
>>=20
>> Uh - I'm sort of reading it but I got to admit I'm not sure I am=20
>> getting any information that is new. I'm sure Francois will=20
>summarize=20
>> something that I can actually understand sooner or later.
>>=20
>> Cullen <with my individual hat on>
>
>I'm not getting it either.
>
>I think the summary is that Samir wants the group to stop its=20
>work on draft-ietf-sip-sips, and reverse it's already made=20
>decision, in order to consider a proposal from him that he=20
>hasn't submitted yet, involving indicating Cypher-suites=20
>explicitly and deprecating SIPS altogether.
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol Use=20
>sip-implementors@cs.columbia.edu for questions on current sip=20
>Use sipping@ietf.org for new developments on the application of sip
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 23 16:16:28 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hg4xY-0004ZS-2r; Mon, 23 Apr 2007 16:16:28 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hg4xW-0004Xo-9c
	for sip-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 16:16:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg4xV-0004Xb-TW
	for sip@ietf.org; Mon, 23 Apr 2007 16:16:25 -0400
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg4xV-0005R3-KW
	for sip@ietf.org; Mon, 23 Apr 2007 16:16:25 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	l3NKFg006517; Mon, 23 Apr 2007 20:15:42 GMT
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: [Sip] draft-ietf-sip-sips-03.txt
Date: Mon, 23 Apr 2007 15:16:15 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
In-Reply-To: <70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] draft-ietf-sip-sips-03.txt
thread-index: AceFVoZuNpP9N+dxRIed5E+m5mNHZwAawfqQ
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
From: "Francois Audet" <audet@nortel.com>
To: "Cullen Jennings" <fluffy@cisco.com>,
	"Dean Willis" <dean.willis@softarmor.com>,
	"Peterson, Jon" <jon.peterson@neustar.biz>,
	"Hisham Khartabil" <hisham.khartabil@gmail.com>,
	"Keith Drage" <drage@alcatel-lucent.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

(Copying Dean and Jon and Hisham, because they are the main people who
expressed=20
an opinion on this).

The issue is how do we handle backward-compatibility, i.e.,
implementations that
have implemented sips according to RFC 3261 but not to this draft.

Because of the many issues highlighted in the draft, those
implementations are
likely to do proprietary "cheats" to handle SIPS, and they are also
likely to=20
have things that are not really legal. Presumably, the option-tag would
allow UAs and Proxies to know if an implementation is "clean" or not.
You could then
provide alternative treatment for the "un-clean" implementation (i.e.,
don't allow
registration, protocol fix-up, manufacturer-specific stuff, record an
aler, etc.).=20
There are certainly other ways of doing this, and this is largely
theoretical=20
anyways because it's not like there is a large numbers of
implementations out there.

The second issue (perhaps more importantly) is the actual changes that
we=20
are making to RFC 3261. Specifically, the various deprecation of last
hop ugrades/
downgrades.

The option-tag (with Proxy-required) allows for the sender of the
request to
enforce the deprecation of the last hop exception, i.e., the session
will fail
with 420 if a proxy doesn't understand that it is supposed to support
sips
properly as per the new draft.=20

I was thinking about the originator of the request as the entity that
would want
to enforce no-last-hop-exception, but Cullent points out that maybe it's
also
something that's up to the owner of the SIPS URI to decide, in which
case the
option-tag is not useful (of course if you are that worried about it,
you
could do "sips:user@example.net?Proxy-Required:sips".

So....

I actually don't really care either way. Really. I'm fine either way.

Maybe we should do a virtual "hum".

1a - For the option-tag (but I could go either way)
1b - For the option-tag (and I really insist on it)
2a - Against the option-tag (but I could go either way)
2b - Against the option-tag (and I really insist on it)
3 - I really don't care


> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]=20
> Sent: Sunday, April 22, 2007 20:21
> To: Audet, Francois (SC100:3055)
> Cc: sip@ietf.org
> Subject: Re: [Sip] draft-ietf-sip-sips-03.txt
>=20
>=20
> On Apr 16, 2007, at 3:26 PM, Francois Audet wrote:
>=20
> >   2.  Do we need the sips option tag? The current document assumes=20
> > that
> >        we do use the option tag, and that is the preference of the=20
> > author.
> >        (There is at least one dissenting voice on that one: Hisham).
>=20
> I'm confused on why we would need it and would want to=20
> understand why it is needed before commenting on this. I=20
> don't buy the needing it to enforce deprecate of last hop=20
> rule - I see problem in that it leads to two bits that mean=20
> the same thing and we have to deal with all the corner cases=20
> of when they conflict. It also makes me wonder if there are=20
> problems when a URI is copied from one situation to another=20
> and the REquires: sips header is not.
>=20
> Cullen <with my individual hat on>
>=20
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 23 16:21:46 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hg52f-00082I-Cm; Mon, 23 Apr 2007 16:21:45 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hg52d-0007uX-9t
	for sip-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 16:21:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg52c-0007rQ-PA
	for sip@ietf.org; Mon, 23 Apr 2007 16:21:42 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg52b-0007BG-A8
	for sip@ietf.org; Mon, 23 Apr 2007 16:21:42 -0400
Received: from [64.101.172.87] ([64.101.172.87]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3NJSWjD005245
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Mon, 23 Apr 2007 14:28:33 -0500
In-Reply-To: <28C89681-36C6-4AB6-9CE4-FA7C6A2A6FA9@nostrum.com>
References: <E79EA28D-BBB2-4218-A89F-65A909DAE882@softarmor.com>
	<28C89681-36C6-4AB6-9CE4-FA7C6A2A6FA9@nostrum.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <2BD523E3-9553-4710-8627-00AAC3E89EEC@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] Process question on fixing record-route
Date: Mon, 23 Apr 2007 15:21:30 -0500
To: Robert Sparks <rjsparks@nostrum.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 23, 2007, at 1:59 PM, Robert Sparks wrote:

> I think this should go down the 1) path. This is a recommended use  
> of mechanisms that exist, not a change of any normative text.
>

So we can fix [BUG664], [BUG734], and [BUG735] with a BCP?


--
Dean




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 23 16:33:36 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hg5E8-0004lf-0Z; Mon, 23 Apr 2007 16:33:36 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hg5E6-0004kU-F5
	for sip-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 16:33:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg5E6-0004kL-5R
	for sip@ietf.org; Mon, 23 Apr 2007 16:33:34 -0400
Received: from [209.213.211.195] (helo=delta.rtfm.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg5E3-0003KZ-SW
	for sip@ietf.org; Mon, 23 Apr 2007 16:33:34 -0400
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1])
	by delta.rtfm.com (Postfix) with ESMTP id 0E79933C21;
	Mon, 23 Apr 2007 13:33:46 -0700 (PDT)
Date: Mon, 23 Apr 2007 13:33:45 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: "Samir Srivastava" <samirsr@nortel.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests
	from	being	delivered to a UA
In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E6126BBE09@zrc2hxm2.corp.nortel.com>
References: <1ECE0EB50388174790F9694F77522CCF1021A0D6@zrc2hxm0.corp.nortel.com>
	<62B9B0847CC47543B6B3B5E26BD268E6126BBE09@zrc2hxm2.corp.nortel.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20070423203346.0E79933C21@delta.rtfm.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: Cullen Jennings <fluffy@cisco.com>, SIP <sip@ietf.org>,
	Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

At Mon, 23 Apr 2007 15:02:02 -0500,
Samir Srivastava wrote:
> It will be coming soon as its in discussion with other folks privately.
> BTW, we still have a lot of time before Chicago. And I don't work 100%
> time on the IETF proposal writing.
>
> My proposal is depicted in the cipher-suite draft roughly in the 00
> version. I have shown so many times on the list that we need
> cipher-suite indication, where our security adivisor doesn't seem to be
> in the agreement. 

This confuses more than it illuminates.

There are two features being discussed here:

1. An indicator of which cipher suite was negotiated.
2. A signal that you want the next hop to negotiate a specific
   set of cipher suites.

I have no problem with the first feature, though I'm not sure it's
incredibly useful. I don't agree that the second feature is
particularly useful. The cases where it's relevant strike me as
fairly esoteric and unlikely.

-Ekr





_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 23 16:45:59 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hg5Q5-0007pH-0G; Mon, 23 Apr 2007 16:45:57 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hg5Q3-0007nv-2j
	for sip-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 16:45:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg5Q2-0007nh-PG
	for sip@ietf.org; Mon, 23 Apr 2007 16:45:54 -0400
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg5Ma-0007T6-Mi
	for sip@ietf.org; Mon, 23 Apr 2007 16:42:21 -0400
Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121])
	(authenticated bits=0)
	by nostrum.com (8.13.8/8.13.8) with ESMTP id l3NKgKu7021410
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Mon, 23 Apr 2007 15:42:20 -0500 (CDT)
	(envelope-from rjsparks@nostrum.com)
In-Reply-To: <2BD523E3-9553-4710-8627-00AAC3E89EEC@softarmor.com>
References: <E79EA28D-BBB2-4218-A89F-65A909DAE882@softarmor.com>
	<28C89681-36C6-4AB6-9CE4-FA7C6A2A6FA9@nostrum.com>
	<2BD523E3-9553-4710-8627-00AAC3E89EEC@softarmor.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <F7CF69C8-CC3D-4C33-A9AC-B4AE1DE5ADD9@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [Sip] Process question on fixing record-route
Date: Mon, 23 Apr 2007 15:42:14 -0500
To: Dean Willis <dean.willis@softarmor.com>
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
	mechanism)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

664 - Yes - we are making a behavior explicit that obviates the need  
to do rewriting, and the clause that talks about rewriting starts out  
"If the URI placed in the Record-Route header field needs to be  
rewritten"

724 - Yes - this bug is asking for a clarification, not an essential  
change to normative text. (The essence of the bug is to capture that  
proxies should record route any time the transport details change  
between coming in and going out).

735 - Not covered by the draft in question. That's a sips: question -  
This one _will _ require normative changes to the spec, but will come  
around only after we make more progress on the sips discussion. And  
depending on how that comes out, it may or may not fall into the  
category of an _essential_ correction.

RjS

On Apr 23, 2007, at 3:21 PM, Dean Willis wrote:

>
> On Apr 23, 2007, at 1:59 PM, Robert Sparks wrote:
>
>> I think this should go down the 1) path. This is a recommended use  
>> of mechanisms that exist, not a change of any normative text.
>>
>
> So we can fix [BUG664], [BUG734], and [BUG735] with a BCP?
>
>
> --
> Dean
>
>



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 23 17:07:11 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hg5kY-0007bY-0Z; Mon, 23 Apr 2007 17:07:06 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hg5kW-0007Xx-L2
	for sip-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 17:07:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg5kW-0007Xh-BX
	for sip@ietf.org; Mon, 23 Apr 2007 17:07:04 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg5kV-0003Ce-3G
	for sip@ietf.org; Mon, 23 Apr 2007 17:07:04 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3NL6v602566; Mon, 23 Apr 2007 21:06:57 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Mon, 23 Apr 2007 16:06:56 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E6126BBFB3@zrc2hxm2.corp.nortel.com>
In-Reply-To: <20070423203346.0E79933C21@delta.rtfm.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
thread-index: AceF5q6zdmE7rHAbRw+4emntbqtfyQAAvH/A
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Eric Rescorla" <ekr@networkresonance.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: Cullen Jennings <fluffy@cisco.com>, SIP <sip@ietf.org>,
	Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

My very simple requirement, which I posted recently to the Dean's
question on the what callee wants. And a lot of this, I explained
earlier.

1) If I am DOD, I want AES 256. As it is considered TOP SECRET by them.
If I am talking to bank then I want AES 256 (using KPML etc as it has
lot of valuable information). If a CEO of company A is in talks with CEO
of another company B, he will need AES 256 for all along. As the call
pattern tracking itself is more sensitive. As if Competetior of Company
of A knows that A and B are in talks, he can also come into the picture.
The damage varies on the size, content of talk (consider Page mode IM
too).

2) If I am making 911 call, I need my call to be setup even with the
plain text.

3) If I am small office owner in the downtown, then I might be okay even
with 3DES or 40 bit ciphers etc..

4) If I am a normal user, then I will need AES128 all along.

5) There are geographic regions, where ciphersuites just provide the
integrity and no confidentiality. If my UA moves to those regions, then
atleast the proxy sitting at the boundary should inform the request
needing back AES256, that it cannot be served.

I have given a lot of other reasons earlier. Like Cheater Proxy, the N+1
Cycle for new cipher-suite development etc..

My only request to the group is, please postpone the decision of SIPS
with patches as STANDARD track document, till I publish my next version
of the cipher-suite draft.

Thx
Samir=20

>
>There are two features being discussed here:
>
>1. An indicator of which cipher suite was negotiated.
>2. A signal that you want the next hop to negotiate a specific
>   set of cipher suites.
>
>I have no problem with the first feature, though I'm not sure=20
>it's incredibly useful. I don't agree that the second feature=20
>is particularly useful. The cases where it's relevant strike=20
>me as fairly esoteric and unlikely.
>
>-Ekr
>
>
>
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 23 17:23:34 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hg60T-0006CE-8r; Mon, 23 Apr 2007 17:23:33 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hg60R-0006C8-Re
	for sip-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 17:23:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg60R-0006C0-Hs
	for sip@ietf.org; Mon, 23 Apr 2007 17:23:31 -0400
Received: from [209.213.211.195] (helo=delta.rtfm.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg60R-00080M-4j
	for sip@ietf.org; Mon, 23 Apr 2007 17:23:31 -0400
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1])
	by delta.rtfm.com (Postfix) with ESMTP id 6DF6A33C21;
	Mon, 23 Apr 2007 14:23:40 -0700 (PDT)
Date: Mon, 23 Apr 2007 14:23:40 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: "Samir Srivastava" <samirsr@nortel.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E6126BBFB3@zrc2hxm2.corp.nortel.com>
References: <20070423203346.0E79933C21@delta.rtfm.com>
	<62B9B0847CC47543B6B3B5E26BD268E6126BBFB3@zrc2hxm2.corp.nortel.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20070423212340.6DF6A33C21@delta.rtfm.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: Cullen Jennings <fluffy@cisco.com>, SIP <sip@ietf.org>,
	Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

At Mon, 23 Apr 2007 16:06:56 -0500,
Samir Srivastava wrote:
> 
> My very simple requirement, which I posted recently to the Dean's
> question on the what callee wants. And a lot of this, I explained
> earlier.
> 
> 1) If I am DOD, I want AES 256. As it is considered TOP SECRET by them.
> If I am talking to bank then I want AES 256 (using KPML etc as it has
> lot of valuable information). If a CEO of company A is in talks with CEO
> of another company B, he will need AES 256 for all along. As the call
> pattern tracking itself is more sensitive. As if Competetior of Company
> of A knows that A and B are in talks, he can also come into the picture.
> The damage varies on the size, content of talk (consider Page mode IM
> too).
> 
> 2) If I am making 911 call, I need my call to be setup even with the
> plain text.
> 
> 3) If I am small office owner in the downtown, then I might be okay even
> with 3DES or 40 bit ciphers etc..
> 
> 4) If I am a normal user, then I will need AES128 all along.
> 
> 5) There are geographic regions, where ciphersuites just provide the
> integrity and no confidentiality. If my UA moves to those regions, then
> atleast the proxy sitting at the boundary should inform the request
> needing back AES256, that it cannot be served.
>
> I have given a lot of other reasons earlier. Like Cheater Proxy, the N+1
> Cycle for new cipher-suite development etc..

Yes, you've posted this claimed requirement before, and as I said
before, I think it's a fairly unusual set of cases that's not important to
optimize for at this point. I don't see any evidence that you're any
closer to getting consensus on this requirement than you were in
Montreal.

 
> My only request to the group is, please postpone the decision of SIPS
> with patches as STANDARD track document, till I publish my next version
> of the cipher-suite draft.

I oppose holding up the SIPS document for this. If your document is
done before the WG is finished with SIPS, then you should feel free
to ask people whether they prefer it your approach. Otherwise, SIPS
should move forward. This topic has been debated long enough.

-Ekr


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 23 17:42:36 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hg6Is-0003NC-6C; Mon, 23 Apr 2007 17:42:34 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hg6Iq-0003N1-ME
	for sip-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 17:42:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg6Iq-0003Ms-Cj
	for sip@ietf.org; Mon, 23 Apr 2007 17:42:32 -0400
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg6Ip-0003TU-3t
	for sip@ietf.org; Mon, 23 Apr 2007 17:42:32 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	l3NLfm022728; Mon, 23 Apr 2007 21:41:48 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Mon, 23 Apr 2007 16:42:27 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E6126BC077@zrc2hxm2.corp.nortel.com>
In-Reply-To: <20070423212340.6DF6A33C21@delta.rtfm.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
thread-index: AceF7apVCLLAjWsQSWSoYtv1Qz6ktgAATIyw
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Eric Rescorla" <ekr@networkresonance.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: Cullen Jennings <fluffy@cisco.com>, SIP <sip@ietf.org>,
	Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

>
>Yes, you've posted this claimed requirement before, and as I=20
>said before, I think it's a fairly unusual set of cases that's=20
>not important to optimize for at this point. I don't see any=20
>evidence that you're any closer to getting consensus on this=20
>requirement than you were in Montreal.
>

Okay, let me see what happens in Chicago on the cipher-suite front.


>> My only request to the group is, please postpone the=20
>decision of SIPS=20
>> with patches as STANDARD track document, till I publish my next=20
>> version of the cipher-suite draft.
>
>I oppose holding up the SIPS document for this. If your=20
>document is done before the WG is finished with SIPS, then you=20
>should feel free to ask people whether they prefer it your=20
>approach. Otherwise, SIPS should move forward. This topic has=20
>been debated long enough.
>

Even If I accept SIPS with AES128 all along with SIPS. I don't know how
the group wants to address the broken feature. Let me go one by one on
the features.

In the below call flow If PUA uses SIPS in M5. But M1 and others between
PA and Watcher uses only SIP. What PA/ESC should do ? Don't we need a
REQUIRE flag to enforce the feature control at PA / ESC . Does SIPS
_alone_ sufficient ?

          PUA                    PA                       WATCHER
         (EPA)                   (ESC)
           |                       |                         |
           |                       | <---- M1: SUBSCRIBE --- |
           |                       |                         |
           |                       | ----- M2: 200 OK -----> |
           |                       |                         |
           |                       | ----- M3: NOTIFY -----> |
           |                       |                         |
           |                       | <---- M4: 200 OK ------ |
           |                       |                         |
           |                       |                         |
           | ---- M5: PUBLISH ---> |                         |
           |                       |                         |
           | <--- M6: 200 OK ----  |                         |
           |                       |                         |
           |                       | ----- M7: NOTIFY -----> |
           |                       |                         |
           |                       | <---- M8: 200 OK ------ |


Thx
Samir

>-Ekr
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 23 20:46:25 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hg9Ad-0005AM-Ct; Mon, 23 Apr 2007 20:46:15 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hg9Ab-00059o-VG
	for sip-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 20:46:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg9Ab-00059f-Lm
	for sip@ietf.org; Mon, 23 Apr 2007 20:46:13 -0400
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg979-0008NX-9e
	for sip@ietf.org; Mon, 23 Apr 2007 20:42:39 -0400
Received: from sj-dkim-7.cisco.com ([171.68.10.88])
	by sj-iport-4.cisco.com with ESMTP; 23 Apr 2007 17:42:39 -0700
X-IronPort-AV: i="4.14,444,1170662400"; 
	d="scan'208"; a="55673555:sNHT50748228"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
	by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l3O0gcqV021792; 
	Mon, 23 Apr 2007 17:42:38 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l3O0gcwn024547;
	Tue, 24 Apr 2007 00:42:38 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 23 Apr 2007 17:42:38 -0700
Received: from [128.107.149.144] ([128.107.149.144]) by
	xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 23 Apr 2007 17:42:37 -0700
Message-ID: <462D527D.3080100@cisco.com>
Date: Mon, 23 Apr 2007 20:42:37 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Samir Srivastava <samirsr@nortel.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from	being
	delivered to a UA
References: <62B9B0847CC47543B6B3B5E26BD268E6126BBFB3@zrc2hxm2.corp.nortel.com>
In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E6126BBFB3@zrc2hxm2.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 24 Apr 2007 00:42:37.0841 (UTC)
	FILETIME=[74F55010:01C78609]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3240; t=1177375358;
	x=1178239358; c=relaxed/simple; s=sjdkim7002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20SIPS=20question=3A=20How=20to=20prevent=20pla
	intext=20requests=20from=09being=0A=20delivered=20to=20a=20UA
	|Sender:=20; bh=6IGDjPECPimUY2txCyX2DTTI8kZbdb2aiVrrYrjEeu8=;
	b=Zs5YdWGccJPUOyWLhwhxkD85s8cD4ycYKBV6Vz6E+c/vcvNLJHxKyEAY8yZuFQsWsoyMWhFb
	QyzdODkh0Of492DbrWvBNyJRG5cUirtSicWlUUXq5iwR6z/Q/liSdS8n;
Authentication-Results: sj-dkim-7; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim7002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: Cullen Jennings <fluffy@cisco.com>, SIP <sip@ietf.org>,
	Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org



Samir Srivastava wrote:
> My very simple requirement, which I posted recently to the Dean's
> question on the what callee wants. And a lot of this, I explained
> earlier.
> 
> 1) If I am DOD, I want AES 256. As it is considered TOP SECRET by them.

If you are the DOD, then you will control the whole network and insist 
that it use AES 256 uniformly, regardless of what is signaled.

> If I am talking to bank then I want AES 256 (using KPML etc as it has
> lot of valuable information).

*You* may know you are talking to a bank. But how does your UAC know 
that? Do you expect to have an "AES 256" button on the phone to signal this?

Its also possible that you didn't know when you made the call that it 
was to a bank. (It might just be a number on your missed-calls list.) 
Its quite possible that it is the *bank*, not you, that wants to ensure 
that the call is secure, because it has legal liability if it doesn't. I 
don't see how you intend to deal with that.

> If a CEO of company A is in talks with CEO
> of another company B, he will need AES 256 for all along. As the call
> pattern tracking itself is more sensitive. As if Competetior of Company
> of A knows that A and B are in talks, he can also come into the picture.
> The damage varies on the size, content of talk (consider Page mode IM
> too).

In general it becomes quite messy if you insist that the security policy 
to use for the call be specified by the caller and yet be dependent on 
the nature of both the caller and callee.

	Paul

> 2) If I am making 911 call, I need my call to be setup even with the
> plain text.
> 
> 3) If I am small office owner in the downtown, then I might be okay even
> with 3DES or 40 bit ciphers etc..
> 
> 4) If I am a normal user, then I will need AES128 all along.
> 
> 5) There are geographic regions, where ciphersuites just provide the
> integrity and no confidentiality. If my UA moves to those regions, then
> atleast the proxy sitting at the boundary should inform the request
> needing back AES256, that it cannot be served.
> 
> I have given a lot of other reasons earlier. Like Cheater Proxy, the N+1
> Cycle for new cipher-suite development etc..
> 
> My only request to the group is, please postpone the decision of SIPS
> with patches as STANDARD track document, till I publish my next version
> of the cipher-suite draft.
> 
> Thx
> Samir 
> 
>> There are two features being discussed here:
>>
>> 1. An indicator of which cipher suite was negotiated.
>> 2. A signal that you want the next hop to negotiate a specific
>>   set of cipher suites.
>>
>> I have no problem with the first feature, though I'm not sure 
>> it's incredibly useful. I don't agree that the second feature 
>> is particularly useful. The cases where it's relevant strike 
>> me as fairly esoteric and unlikely.
>>
>> -Ekr
>>
>>
>>
>>
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 23 20:49:57 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hg9EC-0000of-TW; Mon, 23 Apr 2007 20:49:56 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hg9E9-0000nB-2Q
	for sip-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 20:49:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg9E8-0000n2-P3
	for sip@ietf.org; Mon, 23 Apr 2007 20:49:52 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg9E8-0003TG-9U
	for sip@ietf.org; Mon, 23 Apr 2007 20:49:52 -0400
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-6.cisco.com with ESMTP; 23 Apr 2007 17:49:51 -0700
X-IronPort-AV: i="4.14,444,1170662400"; 
	d="scan'208"; a="139781178:sNHT50784435"
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3O0npQQ030595; 
	Mon, 23 Apr 2007 17:49:51 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3O0nXZl000354;
	Tue, 24 Apr 2007 00:49:51 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 23 Apr 2007 17:49:36 -0700
Received: from [128.107.149.144] ([128.107.149.144]) by
	xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 23 Apr 2007 17:49:35 -0700
Message-ID: <462D541F.40505@cisco.com>
Date: Mon, 23 Apr 2007 20:49:35 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Samir Srivastava <samirsr@nortel.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from	being
	delivered to a UA
References: <62B9B0847CC47543B6B3B5E26BD268E6126BC077@zrc2hxm2.corp.nortel.com>
In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E6126BC077@zrc2hxm2.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 24 Apr 2007 00:49:35.0784 (UTC)
	FILETIME=[6E125A80:01C7860A]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3956; t=1177375791;
	x=1178239791; c=relaxed/simple; s=sjdkim1004;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20SIPS=20question=3A=20How=20to=20prevent=20pla
	intext=20requests=20from=09being=0A=20delivered=20to=20a=20UA
	|Sender:=20; bh=o22lJjmSbxT133Xs+nHtw+M8Jkj6DD0IT0ZWAFi77Xg=;
	b=dUX4wP1VWxC8haq7Z84cl65XUi8ad9gAA6FfWGzTgXxByDnOzgh5SpKlAMCCmi0hjhVNOHi5
	SLoT19mtTzQNj5J9h/OKxUChG6I7mV0zcBkqE2HKWJOqsFzA21CEJDCs3mFKoEd0x7NC7l30VT
	Odu57SpCTLnseEbSLMPo1YrKU=;
Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim1004 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
Cc: Cullen Jennings <fluffy@cisco.com>, SIP <sip@ietf.org>,
	Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org



Samir Srivastava wrote:
>> Yes, you've posted this claimed requirement before, and as I 
>> said before, I think it's a fairly unusual set of cases that's 
>> not important to optimize for at this point. I don't see any 
>> evidence that you're any closer to getting consensus on this 
>> requirement than you were in Montreal.
>>
> 
> Okay, let me see what happens in Chicago on the cipher-suite front.
> 
> 
>>> My only request to the group is, please postpone the 
>> decision of SIPS 
>>> with patches as STANDARD track document, till I publish my next 
>>> version of the cipher-suite draft.
>> I oppose holding up the SIPS document for this. If your 
>> document is done before the WG is finished with SIPS, then you 
>> should feel free to ask people whether they prefer it your 
>> approach. Otherwise, SIPS should move forward. This topic has 
>> been debated long enough.
>>
> 
> Even If I accept SIPS with AES128 all along with SIPS. I don't know how
> the group wants to address the broken feature. Let me go one by one on
> the features.
> 
> In the below call flow If PUA uses SIPS in M5. But M1 and others between
> PA and Watcher uses only SIP. What PA/ESC should do ? Don't we need a
> REQUIRE flag to enforce the feature control at PA / ESC . Does SIPS
> _alone_ sufficient ?

In your example, PA is just an instance of a B2BUA. For purposes of this 
discussion it is little different from a conference focus or a lot of 
other things.

I think we have agreed that a B2BUA is a UA, and that if it satisfies 
the security requirements of a UA then it is done. What it does out its 
other side cannot be predicted.

Do do better, it will be necessary to develop specific rules for 
particular kinds of B2BUA. If you have ideas about how the secure info 
delivered to the PA using publish is to be secured on the notification 
side, then we need a new spec for it.

If that were done, I doubt it would say that all the notifies must 
adhere to the same security level that the publish had. More likely, 
there might be some kind of security tagging of elements of presence 
data, and then filtering rules that prevent certain secured data from 
being included in insecure notifications.

My main point is that such issues are largely orthogonal to the entire 
sips thing.

	Paul

>           PUA                    PA                       WATCHER
>          (EPA)                   (ESC)
>            |                       |                         |
>            |                       | <---- M1: SUBSCRIBE --- |
>            |                       |                         |
>            |                       | ----- M2: 200 OK -----> |
>            |                       |                         |
>            |                       | ----- M3: NOTIFY -----> |
>            |                       |                         |
>            |                       | <---- M4: 200 OK ------ |
>            |                       |                         |
>            |                       |                         |
>            | ---- M5: PUBLISH ---> |                         |
>            |                       |                         |
>            | <--- M6: 200 OK ----  |                         |
>            |                       |                         |
>            |                       | ----- M7: NOTIFY -----> |
>            |                       |                         |
>            |                       | <---- M8: 200 OK ------ |
> 
> 
> Thx
> Samir
> 
>> -Ekr
>>
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 23 21:04:36 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hg9SM-0004Fv-Ef; Mon, 23 Apr 2007 21:04:34 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hg9SK-0004Fk-WD
	for sip-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 21:04:33 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg9SK-0004FX-MU
	for sip@ietf.org; Mon, 23 Apr 2007 21:04:32 -0400
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg9SI-0002qw-R3
	for sip@ietf.org; Mon, 23 Apr 2007 21:04:32 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	l3O13lX14304; Tue, 24 Apr 2007 01:03:48 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from being
	delivered to a UA
Date: Mon, 23 Apr 2007 20:04:26 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E6126BC210@zrc2hxm2.corp.nortel.com>
In-Reply-To: <462D541F.40505@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being delivered to a UA
thread-index: AceGCnw3B1RymT46QvOJuNwM4riXawAAZ+9Q
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Paul Kyzivat" <pkyzivat@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196
Cc: Cullen Jennings <fluffy@cisco.com>, SIP <sip@ietf.org>,
	Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Being a UA, I don't want my presence information to be delivered on the
unsecure channels. Can I do that ? You might view it is a B2BUA but it
is not so in the vocabulary of SBC vendors as It doesn't create a
matching a dialog on the other side. Here it is triggering the another
operation.

Presence is one example, another is REG-EV watchers. Where we don't have
tagging option in the PIDF as we have in PUBLISH.

Thx
Samir

>-----Original Message-----
>From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20
>Sent: Monday, April 23, 2007 5:50 PM
>To: Srivastava, Samir (SC100:8826)
>Cc: Eric Rescorla; Cullen Jennings; SIP; Audet, Francois (SC100:3055)
>Subject: Re: [Sip] SIPS question: How to prevent plaintext=20
>requests from being delivered to a UA
>
>
>
>Samir Srivastava wrote:
>>> Yes, you've posted this claimed requirement before, and as I said=20
>>> before, I think it's a fairly unusual set of cases that's not=20
>>> important to optimize for at this point. I don't see any evidence=20
>>> that you're any closer to getting consensus on this=20
>requirement than=20
>>> you were in Montreal.
>>>
>>=20
>> Okay, let me see what happens in Chicago on the cipher-suite front.
>>=20
>>=20
>>>> My only request to the group is, please postpone the
>>> decision of SIPS
>>>> with patches as STANDARD track document, till I publish my next=20
>>>> version of the cipher-suite draft.
>>> I oppose holding up the SIPS document for this. If your document is=20
>>> done before the WG is finished with SIPS, then you should feel free=20
>>> to ask people whether they prefer it your approach. Otherwise, SIPS=20
>>> should move forward. This topic has been debated long enough.
>>>
>>=20
>> Even If I accept SIPS with AES128 all along with SIPS. I don't know=20
>> how the group wants to address the broken feature. Let me go one by=20
>> one on the features.
>>=20
>> In the below call flow If PUA uses SIPS in M5. But M1 and others=20
>> between PA and Watcher uses only SIP. What PA/ESC should do=20
>? Don't we=20
>> need a REQUIRE flag to enforce the feature control at PA /=20
>ESC . Does=20
>> SIPS _alone_ sufficient ?
>
>In your example, PA is just an instance of a B2BUA. For=20
>purposes of this discussion it is little different from a=20
>conference focus or a lot of other things.
>
>I think we have agreed that a B2BUA is a UA, and that if it=20
>satisfies the security requirements of a UA then it is done.=20
>What it does out its other side cannot be predicted.
>
>Do do better, it will be necessary to develop specific rules=20
>for particular kinds of B2BUA. If you have ideas about how the=20
>secure info delivered to the PA using publish is to be secured=20
>on the notification side, then we need a new spec for it.
>
>If that were done, I doubt it would say that all the notifies=20
>must adhere to the same security level that the publish had.=20
>More likely, there might be some kind of security tagging of=20
>elements of presence data, and then filtering rules that=20
>prevent certain secured data from being included in insecure=20
>notifications.
>
>My main point is that such issues are largely orthogonal to=20
>the entire sips thing.
>
>	Paul
>
>>           PUA                    PA                       WATCHER
>>          (EPA)                   (ESC)
>>            |                       |                         |
>>            |                       | <---- M1: SUBSCRIBE --- |
>>            |                       |                         |
>>            |                       | ----- M2: 200 OK -----> |
>>            |                       |                         |
>>            |                       | ----- M3: NOTIFY -----> |
>>            |                       |                         |
>>            |                       | <---- M4: 200 OK ------ |
>>            |                       |                         |
>>            |                       |                         |
>>            | ---- M5: PUBLISH ---> |                         |
>>            |                       |                         |
>>            | <--- M6: 200 OK ----  |                         |
>>            |                       |                         |
>>            |                       | ----- M7: NOTIFY -----> |
>>            |                       |                         |
>>            |                       | <---- M8: 200 OK ------ |
>>=20
>>=20
>> Thx
>> Samir
>>=20
>>> -Ekr
>>>
>>=20
>>=20
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol Use=20
>> sip-implementors@cs.columbia.edu for questions on current sip Use=20
>> sipping@ietf.org for new developments on the application of sip
>>=20
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 24 02:42:05 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgEii-0001DV-7G; Tue, 24 Apr 2007 02:41:48 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HgEig-0001DH-Rx
	for sip-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 02:41:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HgEig-0001D9-Fx
	for sip@ietf.org; Tue, 24 Apr 2007 02:41:46 -0400
Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgEid-0001MQ-UO
	for sip@ietf.org; Tue, 24 Apr 2007 02:41:46 -0400
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213])
	by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id
	l3O6fThU004145; Tue, 24 Apr 2007 09:41:40 +0300
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by
	esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 24 Apr 2007 09:41:37 +0300
Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by
	esebh103.NOE.Nokia.com over TLS secured channel with Microsoft
	SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 09:41:37 +0300
Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13])
	by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id
	l3O6fZKm001874; Tue, 24 Apr 2007 09:41:35 +0300
Received: from [172.21.41.217] (esdhcp041217.research.nokia.com
	[172.21.41.217]) by kusti.research.nokia.com (Postfix) with ESMTP
	id 536C693B77; Tue, 24 Apr 2007 09:41:35 +0300 (EEST)
Message-ID: <462DA69F.1070400@nokia.com>
Date: Tue, 24 Apr 2007 09:41:35 +0300
From: Jari Urpalainen <jari.urpalainen@nokia.com>
User-Agent: Thunderbird 1.5.0.10 (X11/20070302)
MIME-Version: 1.0
To: ext Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] RE: New Liaison Statement, "OMA LS 178 on XCAP diff-event"
References: <E1HMrLq-0007Rc-2u@ietf.org>	<3E4278088AD82C48B4663DDFE762CEF302ED4E3F@prga004a.ww300.siemens.net>
	<0B0F1FB0-451A-4E18-9582-6C19F8044EC3@softarmor.com>
In-Reply-To: <0B0F1FB0-451A-4E18-9582-6C19F8044EC3@softarmor.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 24 Apr 2007 06:41:37.0651 (UTC)
	FILETIME=[9BAF7C30:01C7863B]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168
Cc: Cullen Jennings <fluffy@cisco.com>, IETF SIP List <sip@ietf.org>,
	Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>,
	drage@alcaltel-lucent.com, Antti Laurila <Antti.K.Laurila@nokia.com>,
	mary Barnes <mary.barnes@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

ext Dean Willis wrote:
>
> On Apr 20, 2007, at 8:37 AM, Dostal, Pavel wrote:
>
>> All,
>>
>> As a technical contact from OMA PAG WG, I wonder whether any official
>> feedback to the "OMA LS 178 on XCAP diff-event" is planned to be
>> provided by IETF to the OMA PAG WG.
>> Regards,
>
> Good question. I posted the following on the SIPPING list on March 21, 
> and I haven't seen a conclusion in SIPPING yet. Thanks for waking us up.
>
>
>> Several people from the IETF community met as a design team on March 
>> 21, 2007 during IETF 68 in Prague to discuss OMA liaison statement 
>> 178 on XCAP diff-event. This LS relates to OMA's requirement for an 
>> event package for use in monitoring changes to non-configuration XML 
>> documents. The document draft-urpalainen-sip-xcap-diff-event-01.txt 
>> had been previously submitted with the intent of meeting these 
>> requirements.
>>
>> Attendees at this discussion included:
>>
>> Jari Urpalainen
>> Krisztian Kiss
>> Robert Sparks
>> Dan Petrie
>> Cullen Jennings
>> Rohan Mahy
>> Sumanth Channabasappa   
>> Jonathan Rosenburg
>> Dean Willis
>>
>>
>> The conclusion of the meeting was to recommend some changes in the 
>> current sipping-config document and to recommend development of a 
>> separate xcap-config document tailored to OMA's requirements (while 
>> still meeting general IETF applicability goals).
>>
>> Changes to the sipping-config document include adding the application 
>> identifier and error responses previously identified in design team 
>> discussion.
>>
>> The new xcap-event package will need to support several requirements 
>> referred to in draft-urpalainen-sip-xcap-diff-event-01.txt, including 
>> subscribing to a xcap document or a sub-element of an xcap element. 
>> It will also need to support deferred or aggregated notification. The 
>> design team recommends starting with the text in 
>> draft-urpalainen-sip-xcap-diff-event-01.txt, but has not agreed to 
>> the current  re-synch mechanism therein which is expected to require 
>> some further work. This package could be developed either as a WG 
>> effort (probably within the SIPPING working group) or as an 
>> area-director sponsored individual contribution. The design team 
>> feels that the general applicability of this specification is 
>> sufficiently broad that it should be pursued as a standards track 
>> effort, even though RFC 3325 and 3427 allows informational documents 
>> to define event packages of this sort.
>>
>> If this recommendation is accepted or declined we will need to 
>> respond with an appropriate LS to OMA informing them of our intent. 
>> They would like an answer within the next week or so.
>
> -- 
> Dean Willis
A concern was raised about the initial sync stage, so what could be less 
sucking options ? Actually there's a need for versioned retrieval of 
documents based on their ETags which would cleanly solve this issue.

One option would be that servers would make temporary copies of 
subscribed documents during the initial subscription, and these 
temporary URIs along  with the real URIs would be carried within the 
body of xcap-diff document. The client would need to fetch then these 
versioned resources based on temporary URIs. For the server 
implementation this is ugly and somewhat error prone, i.e. e.g. when to 
remove these temporary stuff.

A better option would be to have "real" versioning on the xcap server. 
So one could retrieve documents e.g. by requesting GET 
/resource-lists/joe/index?etag=sfsdf343ds. So client would really 
request the ETag based versioned  resource.  What's nice here that you 
could add rfc3229 semantics here quite easily also, i.e. the client 
could say: "I have this xyz version, give me the patch to the latest 
version". Of course, for the server this would be yet another additional 
requirement for the already pretty complex xcap picture.

So what am I missing here ? This issue is sad in a sense that it is once 
again those cases which rarely exist in practice, a real corner case 
that is.

br, Jari


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 24 04:44:24 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgGdI-00005b-7k; Tue, 24 Apr 2007 04:44:20 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HgGdG-00005I-CR
	for sip-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 04:44:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HgGdF-00005A-US
	for sip@ietf.org; Tue, 24 Apr 2007 04:44:17 -0400
Received: from smail5.alcatel.fr ([64.208.49.27])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgGdE-0004ev-CW
	for sip@ietf.org; Tue, 24 Apr 2007 04:44:17 -0400
Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.ad2.ad.alcatel.com
	[155.132.6.74])
	by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l3O8hGTW028077; 
	Tue, 24 Apr 2007 10:43:17 +0200
Received: from [139.54.131.75] ([139.54.131.75]) by
	FRVELSBHS02.ad2.ad.alcatel.com over TLS secured channel with
	Microsoft SMTPSVC(6.0.3790.2499); Tue, 24 Apr 2007 10:44:09 +0200
Message-ID: <462DC358.4000002@alcatel-lucent.fr>
Date: Tue, 24 Apr 2007 10:44:08 +0200
From: Thomas Froment <Thomas.Froment@alcatel-lucent.fr>
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>, IETF SIP List <sip@ietf.org>
Subject: Re: [Sip] Process question on fixing record-route
References: <E79EA28D-BBB2-4218-A89F-65A909DAE882@softarmor.com>
In-Reply-To: <E79EA28D-BBB2-4218-A89F-65A909DAE882@softarmor.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 24 Apr 2007 08:44:09.0449 (UTC)
	FILETIME=[B9B2D590:01C7864C]
X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

It seems that, the document can end with some modifications not 
requiring to change any *must* statement, so if i understood well what 
Robert said, it is still possible to change a *should* (i.e. "you can 
bypass it only if you have a very good reason"...) in a "bcp" (best 
practice having to justify what this very good reason IS...).

Before going to version -01, I would like to poll the working group on 
the following open issues:

1) Do we want to *deprecate* record-route rewriting or just recommend 
double R-R but let R-R rewriting as a valid alternative?

When I wrote the first version of the draft, I decided to let the two 
possibilities open, but some people told me there was probably a 
consensus for deprecating.
Is rewriting a valid technique given the fact that end-to-end protection 
of the route set can not be supported by the protocol when authorizing this?

So, maybe we can start a poll here, who is in favor of deprecating, who 
is opposed and why?

2) About transport switching, as it is described yet, one of the 
observed proxy implementation behaviour is to make double R-R, puting 
the transport parameter
(for instance, if we have a proxy switching from TCP to UDP, and using 
numeric IP addresses), and thus, ignoring the SHOULD 
statement:[RFC3261], item 4 of section 16.6, "The URI placed in the 
Record-Route header field value MUST be a SIP or SIPS URI. [...] The URI 
SHOULD NOT contain the transport parameter unless the proxy has 
knowledge(such as in a private network) that the next downstream element 
that will be in the path of subsequent requests supports that transport".

Actually, double RR with transport parameter is ok as long as the 
dowstream element support that transport. It is, in the most general 
case, always the case
as long as proxy is using one on the transport mandated in RFC3261 (UDP, 
TCP).
The problem occurs of course if the proxy is switching, for instance, 
from TCP to SCTP, then, if the next SIP element supports that transport, 
it is still dangerous:
let's assume this is a proxy which is NOT record-route, then, when a 
subsequent request arrives, the second SIP element may be asked to route 
the request
using a Route with transport=SCTP parameter it does not support.
What to do in that case? I suggest to recommend to double -RR WITH 
transport parameter *only* if transport is a mandatory transport (UDP or 
TCP, possibly TLS, but should be replaced by sips in a near future, so 
let's forget the TLS transport), OR if proxy has knowledge that *any* 
subsequent element do support that transport.

Any thoughts?

-
Thomas

Dean Willis wrote:
>
> In Prague we recorded a consensus on documenting the various fixes to 
> record-route as described in:
>
> http://www.ietf.org/internet-drafts/draft-froment-sip-record-route-fix-00.txt 
>
>
>
> While we agreed to undertake this effort, we left open the discussion 
> of how to achieve it.
>
> Two proposals were made:
>
> 1) Recast the solution as a BCP
>
> 2) Move this into the "Essential Corrections" process for RFC 3261 
> bugfixing.
>
> I currently lean towards number 2, but we should discuss it.
>
> -- 
> Dean
>
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 24 08:12:11 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgJsK-0006oo-QI; Tue, 24 Apr 2007 08:12:04 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hg34i-0000R7-QZ
	for sip-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 14:15:44 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hg34i-0000Qz-HF for sip@ietf.org; Mon, 23 Apr 2007 14:15:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg2Gu-0008Gj-G2
	for sip@ietf.org; Mon, 23 Apr 2007 13:24:16 -0400
Received: from wr-out-0506.google.com ([64.233.184.237])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg2Gs-0007Ew-98
	for sip@ietf.org; Mon, 23 Apr 2007 13:24:16 -0400
Received: by wr-out-0506.google.com with SMTP id 71so1536295wri
	for <sip@ietf.org>; Mon, 23 Apr 2007 10:24:13 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type;
	b=RL2h2SKQ93sB1hYOOK0QPEuxN/v/wU0HLqRSyxwIVHfbsKOcmxIJb5/IDozOdripzbD2v9K7lvJW1IrXfNaHUHw5WsfPFXZId+V2MCRDflS7PnWBKtu5pfbnD93Z66dKpaBo/J5tqQCfBnywuX/88BJO0CItPKSg/VvszF99fIg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:mime-version:content-type;
	b=KQQbeX9oWZV+tPKuASAyVOoJ4sZFuVErc01qqIwXy2BWOvjwH8fmUVby3pI57EwsqHXN63sT3ekg2hXrKktOeYDK7HUpa3pfNsdCWEOrzBobCahEPCZug6UJnyiyWGA++PS8PcMGSyfbX2UMAxgAuKj8xR9g0miG9JkvLBEbJaA=
Received: by 10.114.210.2 with SMTP id i2mr2621956wag.1177349053394;
	Mon, 23 Apr 2007 10:24:13 -0700 (PDT)
Received: by 10.115.90.5 with HTTP; Mon, 23 Apr 2007 10:24:13 -0700 (PDT)
Message-ID: <1b12d0090704231024s8a066eewca56f753d4884009@mail.gmail.com>
Date: Mon, 23 Apr 2007 12:24:13 -0500
From: "Sheetal Bhogale" <sheetal.bhogale@gmail.com>
To: sip@ietf.org
MIME-Version: 1.0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
X-TMDA-Confirmed: Mon, 23 Apr 2007 14:15:44 -0400
X-Mailman-Approved-At: Tue, 24 Apr 2007 08:12:02 -0400
Subject: [Sip] Avaya TLS support
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0951102358=="
Errors-To: sip-bounces@ietf.org

--===============0951102358==
Content-Type: multipart/alternative; 
	boundary="----=_Part_159024_8023993.1177349053228"

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

Hello All,
               Has anyone tried doing TLS with the Avaya
callserver.Morespecifically installing your own root CA on the Avaya
callserver.
Please do let me know if there is a way to do it.

Thanks,
SB

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

<div>Hello All,</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Has anyone tried doing TLS with the Avaya callserver.More specifically installing your own root CA on the Avaya callserver.</div>
<div>Please do let me know if there is a way to do it.</div>
<div>&nbsp;</div>
<div>Thanks,</div>
<div>SB</div>
<div>&nbsp;</div>
<div>&nbsp;</div>

------=_Part_159024_8023993.1177349053228--




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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============0951102358==--






From sip-bounces@ietf.org Tue Apr 24 10:26:39 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgLxQ-0002c2-Fp; Tue, 24 Apr 2007 10:25:28 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HgLxO-0002bq-RN
	for sip-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 10:25:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HgLxO-0002bi-Hr
	for sip@ietf.org; Tue, 24 Apr 2007 10:25:26 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgLxN-0006HE-6F
	for sip@ietf.org; Tue, 24 Apr 2007 10:25:26 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id EBBCE1EC02E;
	Tue, 24 Apr 2007 17:25:14 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id lUEwspe5QmD0; Tue, 24 Apr 2007 17:25:13 +0300 (EEST)
Received: from taimen (in-vitro91.gprs.dnafinland.fi [62.78.121.91])
	by tutpro.com (Postfix) with ESMTP;
	Tue, 24 Apr 2007 17:25:13 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id 5C122AC120; Tue, 24 Apr 2007 17:25:05 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17966.4929.346525.230253@tutpro.com>
Date: Tue, 24 Apr 2007 17:25:05 +0300
To: Thomas Froment <Thomas.Froment@alcatel-lucent.fr>
Subject: Re: [Sip] Process question on fixing record-route
In-Reply-To: <462DC358.4000002@alcatel-lucent.fr>
References: <E79EA28D-BBB2-4218-A89F-65A909DAE882@softarmor.com>
	<462DC358.4000002@alcatel-lucent.fr>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: IETF SIP List <sip@ietf.org>, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Thomas Froment writes:

 > 1) Do we want to *deprecate* record-route rewriting or just recommend 
 > double R-R but let R-R rewriting as a valid alternative?

can you clarify what you mean by r-r rewriting?  if i recall correctly,
according to rfc 3261 r-r headers are added during dialog initiating
request and after that route set does not change, i.e., proxies only
need to r-r initial request.

 > The URI 
 > SHOULD NOT contain the transport parameter unless the proxy has 
 > knowledge(such as in a private network) that the next downstream element 
 > that will be in the path of subsequent requests supports that
 > transport".

my proxy may be talking to a proxy of another organization using tls no
matter if uri scheme in requests is sip or sips.  if request comes in
over udp and goes out over tls, should my proxy double r-r and add
transport=tls or what?

-- juha


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 24 10:45:12 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgMG0-0005dw-71; Tue, 24 Apr 2007 10:44:40 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HgMFy-0005do-6R
	for sip-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 10:44:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HgMFx-0005df-T5
	for sip@ietf.org; Tue, 24 Apr 2007 10:44:37 -0400
Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgMFx-0003nc-C4
	for sip@ietf.org; Tue, 24 Apr 2007 10:44:37 -0400
Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com
	[155.132.6.78])
	by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l3OEhiEp004408; 
	Tue, 24 Apr 2007 16:44:08 +0200
Received: from [139.54.131.75] ([139.54.131.75]) by
	FRVELSBHS06.ad2.ad.alcatel.com over TLS secured channel with
	Microsoft SMTPSVC(6.0.3790.2499); Tue, 24 Apr 2007 16:44:31 +0200
Message-ID: <462E17CE.30601@alcatel-lucent.fr>
Date: Tue, 24 Apr 2007 16:44:30 +0200
From: Thomas Froment <Thomas.Froment@alcatel-lucent.fr>
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: Juha Heinanen <jh@tutpro.com>
Subject: Re: [Sip] Process question on fixing record-route
References: <E79EA28D-BBB2-4218-A89F-65A909DAE882@softarmor.com>	<462DC358.4000002@alcatel-lucent.fr>
	<17966.4929.346525.230253@tutpro.com>
In-Reply-To: <17966.4929.346525.230253@tutpro.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 24 Apr 2007 14:44:31.0290 (UTC)
	FILETIME=[1151F1A0:01C7867F]
X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Juha Heinanen wrote:
> Thomas Froment writes:
>
>  > 1) Do we want to *deprecate* record-route rewriting or just recommend 
>  > double R-R but let R-R rewriting as a valid alternative?
>
> can you clarify what you mean by r-r rewriting?  if i recall correctly,
> according to rfc 3261 r-r headers are added during dialog initiating
> request and after that route set does not change, i.e., proxies only
> need to r-r initial request.
>   
Yes, RR-rewriting is described in section 3.2 of 
http://www.ietf.org/internet-drafts/draft-froment-sip-record-route-fix-00.txt,
and drawbacks outlined in section 4...
Basically, the R-R has to be modified in the 200 OK response so that the 
Route set seen by the caller will be different than the Route set seen 
by the callee...
>  > The URI 
>  > SHOULD NOT contain the transport parameter unless the proxy has 
>  > knowledge(such as in a private network) that the next downstream element 
>  > that will be in the path of subsequent requests supports that
>  > transport".
>
> my proxy may be talking to a proxy of another organization using tls no
> matter if uri scheme in requests is sip or sips.  if request comes in
> over udp and goes out over tls, should my proxy double r-r and add
> transport=tls or what?
>   
So, I voluntarily omitted to discuss the "transport=TLS" use case since 
http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-03.txt already 
take care of it,
so "sips:" scheme should be used and double RR is also to be recommended 
when transiting from "sip:" to "sips:", it is described in the sip/sips 
document.

By the way, another question comes to my mind, should we ask Francois 
Audet to reference this record-route document in its "double RR" section?

The open issue I described here was: "do we recommend to double R-R 
*and* put the transport parameter on RR header in some circumstances?" 
(which is a different
wording than current text which says "SHOULD NOT put any transport 
parameter etc...".

-
Thomas


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 24 10:52:06 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgMN1-0000fP-Ky; Tue, 24 Apr 2007 10:51:55 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HgMMv-0000f2-Ol
	for sip-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 10:51:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HgMMv-0000en-F0
	for sip@ietf.org; Tue, 24 Apr 2007 10:51:49 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgMMu-00053I-11
	for sip@ietf.org; Tue, 24 Apr 2007 10:51:49 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id 728301EC62F;
	Tue, 24 Apr 2007 17:51:47 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id GjTIbwXmSF+3; Tue, 24 Apr 2007 17:51:45 +0300 (EEST)
Received: from taimen (in-vitro91.gprs.dnafinland.fi [62.78.121.91])
	by tutpro.com (Postfix) with ESMTP;
	Tue, 24 Apr 2007 17:51:45 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id A34A4AC120; Tue, 24 Apr 2007 17:51:36 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17966.6520.584410.972353@tutpro.com>
Date: Tue, 24 Apr 2007 17:51:36 +0300
To: Thomas Froment <Thomas.Froment@alcatel-lucent.fr>
Subject: Re: [Sip] Process question on fixing record-route
In-Reply-To: <462E17CE.30601@alcatel-lucent.fr>
References: <E79EA28D-BBB2-4218-A89F-65A909DAE882@softarmor.com>
	<462DC358.4000002@alcatel-lucent.fr>
	<17966.4929.346525.230253@tutpro.com>
	<462E17CE.30601@alcatel-lucent.fr>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Thomas Froment writes:

 > > can you clarify what you mean by r-r rewriting?  if i recall correctly,
 > > according to rfc 3261 r-r headers are added during dialog initiating
 > > request and after that route set does not change, i.e., proxies only
 > > need to r-r initial request.
 > >   
 > Yes, RR-rewriting is described in section 3.2 of 
 > http://www.ietf.org/internet-drafts/draft-froment-sip-record-route-fix-00.txt,
 > and drawbacks outlined in section 4...

so you are going to make a change to rfc3261 just like that?  if so,
what is the motivation for it?

 > Basically, the R-R has to be modified in the 200 OK response so that the 
 > Route set seen by the caller will be different than the Route set seen 
 > by the callee...

why?

 > So, I voluntarily omitted to discuss the "transport=TLS" use case since 
 > http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-03.txt already 
 > take care of it,
 > so "sips:" scheme should be used and double RR is also to be recommended 
 > when transiting from "sip:" to "sips:", it is described in the sip/sips 
 > document.

what you describe in above has nothing to do with my example where
request comes in to proxy over udp using sip uri scheme and my proxy has
an agreement with the next hop proxy that tls is used for all
communication between the two proxies.  of course my proxy cannot go and
change uri scheme to sips.  so please tell me exactly what my proxy has
to do regarding record routing.

-- juha


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 24 11:15:40 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgMj6-0001Co-3i; Tue, 24 Apr 2007 11:14:44 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HgMj4-0001CZ-Ju
	for sip-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 11:14:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HgMj3-0001CQ-Tz
	for sip@ietf.org; Tue, 24 Apr 2007 11:14:42 -0400
Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgMj2-0002wY-CC
	for sip@ietf.org; Tue, 24 Apr 2007 11:14:41 -0400
Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com
	[155.132.6.76])
	by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l3OFEBXc025899; 
	Tue, 24 Apr 2007 17:14:14 +0200
Received: from [139.54.131.75] ([139.54.131.75]) by
	FRVELSBHS04.ad2.ad.alcatel.com over TLS secured channel with
	Microsoft SMTPSVC(6.0.3790.2499); Tue, 24 Apr 2007 17:14:37 +0200
Message-ID: <462E1EDC.5090509@alcatel-lucent.fr>
Date: Tue, 24 Apr 2007 17:14:36 +0200
From: Thomas Froment <Thomas.Froment@alcatel-lucent.fr>
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: Juha Heinanen <jh@tutpro.com>
Subject: Re: [Sip] Process question on fixing record-route
References: <E79EA28D-BBB2-4218-A89F-65A909DAE882@softarmor.com>	<462DC358.4000002@alcatel-lucent.fr>	<17966.4929.346525.230253@tutpro.com>	<462E17CE.30601@alcatel-lucent.fr>
	<17966.6520.584410.972353@tutpro.com>
In-Reply-To: <17966.6520.584410.972353@tutpro.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 24 Apr 2007 15:14:37.0427 (UTC)
	FILETIME=[45DC9430:01C78683]
X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Juha Heinanen wrote:
> so you are going to make a change to rfc3261 just like that?  if so,
> what is the motivation for it? [...]
>  > Basically, the R-R has to be modified in the 200 OK response so that the 
>  > Route set seen by the caller will be different than the Route set seen 
>  > by the callee...
>
> why?
>   
So, please read the the draft, I cannot reword it with a smaller number 
of words in the mailing list...
>  > So, I voluntarily omitted to discuss the "transport=TLS" use case since 
>  > http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-03.txt already 
>  > take care of it,
>  > so "sips:" scheme should be used and double RR is also to be recommended 
>  > when transiting from "sip:" to "sips:", it is described in the sip/sips 
>  > document.
>
> what you describe in above has nothing to do with my example where
> request comes in to proxy over udp using sip uri scheme and my proxy has
> an agreement with the next hop proxy that tls is used for all
> communication between the two proxies. 
> so please tell me exactly what my proxy has to do regarding record routing.
>   
from sip/sips document: "[RFC3261]/26.2.2 makes it clear that the use of 
the "transport=tls"  URI transport parameter in SIPS or SIP URIs has 
been deprecated.
So, normative change recommended by this document is the following:
" Since the transport=tls URI parameter has been deprecated, it MUST NOT 
be used in Route, Record-Route or Path headers, and MUST be  ignored."

To be compatible with that statement, in your use case,
I think you should use double RR, on the UDP side, use a RR header with 
transport=UDP or NO transport parameter (that was my question: do we 
allow to put
this transport parameter in some circumstances?),
on the TLS side, do not use any transport parameter, but use the sips 
scheme on RR.
Does it answer your question?

Thomas


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 24 11:32:08 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgMz9-0007m7-TR; Tue, 24 Apr 2007 11:31:19 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HgMz8-0007m2-FS
	for sip-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 11:31:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HgMz8-0007lu-64
	for sip@ietf.org; Tue, 24 Apr 2007 11:31:18 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgMz6-0006xl-9L
	for sip@ietf.org; Tue, 24 Apr 2007 11:31:18 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id 5A11C1EC02E;
	Tue, 24 Apr 2007 18:31:06 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id lILQrQJVZd1k; Tue, 24 Apr 2007 18:31:04 +0300 (EEST)
Received: from taimen (in-vitro91.gprs.dnafinland.fi [62.78.121.91])
	by tutpro.com (Postfix) with ESMTP;
	Tue, 24 Apr 2007 18:31:04 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id 6E1F9AC120; Tue, 24 Apr 2007 18:30:58 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17966.8882.420853.690057@tutpro.com>
Date: Tue, 24 Apr 2007 18:30:58 +0300
To: Thomas Froment <Thomas.Froment@alcatel-lucent.fr>
Subject: Re: [Sip] Process question on fixing record-route
In-Reply-To: <462E1EDC.5090509@alcatel-lucent.fr>
References: <E79EA28D-BBB2-4218-A89F-65A909DAE882@softarmor.com>
	<462DC358.4000002@alcatel-lucent.fr>
	<17966.4929.346525.230253@tutpro.com>
	<462E17CE.30601@alcatel-lucent.fr>
	<17966.6520.584410.972353@tutpro.com>
	<462E1EDC.5090509@alcatel-lucent.fr>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Thomas Froment writes:

 > So, please read the the draft, I cannot reword it with a smaller number 
 > of words in the mailing list...

there is so many sip working group drafts that it is impossible for
someone who also needs to do some real work to read them all.  i just
got worried when i noticed that some changes to rfc3261 were proposed.
looks like a complicated issue, if it the reasons cannot be states in a
couple of sentences.

 > To be compatible with that statement, in your use case,
 > I think you should use double RR, on the UDP side, use a RR header with 
 > transport=UDP or NO transport parameter (that was my question: do we 
 > allow to put
 > this transport parameter in some circumstances?),
 > on the TLS side, do not use any transport parameter, but use the sips 
 > scheme on RR.

 > Does it answer your question?

yes, you answered my question, but the answer is totally unacceptable.
i repeat, there is no way my proxy can go and change uri scheme from sip
to sips, since my proxy has no way to know that tls is supported on the
following hops and, if not, the request that started as sip will fail.

-- juha



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 24 13:40:45 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgOz0-0007xL-LQ; Tue, 24 Apr 2007 13:39:18 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HgOyz-0007xC-Hs
	for sip-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 13:39:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HgOyz-0007x4-8F
	for sip@ietf.org; Tue, 24 Apr 2007 13:39:17 -0400
Received: from ihemail1.lucent.com ([135.245.0.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgOyx-0007K5-T8
	for sip@ietf.org; Tue, 24 Apr 2007 13:39:17 -0400
Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l3OHcshC026122
	for <sip@ietf.org>; Tue, 24 Apr 2007 12:39:13 -0500 (CDT)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by
	ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 24 Apr 2007 12:38:36 -0500
Received: from DEEXC1U01.de.lucent.com ([135.248.187.26]) by
	DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 24 Apr 2007 19:38:33 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Review of draft-ietf-sip-location-conveyance
Date: Tue, 24 Apr 2007 19:38:33 +0200
Message-ID: <5D1A7985295922448D5550C94DE2918001084501@DEEXC1U01.de.lucent.com>
In-Reply-To: <5D1A7985295922448D5550C94DE29180FFE84C@DEEXC1U01.de.lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Review of draft-ietf-sip-location-conveyance
Thread-Index: AceASoJbwqnLTcNHTPKhgPjOBOCQcQGTLFbg
References: <5D1A7985295922448D5550C94DE29180FFE84C@DEEXC1U01.de.lucent.com>
From: "Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>
To: "IETF SIP List" <sip@ietf.org>
X-OriginalArrivalTime: 24 Apr 2007 17:38:33.0449 (UTC)
	FILETIME=[6154F590:01C78697]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

A reminder of the call tomorrow, and also that I have posted an updated
set of comments including some late comments received.=20

The numbering remains consistent for the comments that were previously
posted, and we will refer to comments by numbers on the call tomorrow.

Keith

> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20
> Sent: Monday, April 16, 2007 6:13 PM
> To: IETF SIP List
> Subject: [Sip] Review of draft-ietf-sip-location-conveyance
>=20
> I have posted the comments from WGLC on
> draft-ietf-sip-location-conveyance at:
>=20
> http://www.softarmor.com/sipwg/reviews/location-conveyance/index.html
>=20
> Please let me know if I have missed any comments.=20
>=20
> There will be a review conference call of these comments on:
>=20
> Wednesday 25th April at
>=20
> 	1:00 pm - 3:00 pm Central US time
> 	2:00 pm - 4:00 pm Eastern US time
> 	7:00 pm - 9:00 pm UK time
> 	8:00 pm - 10:00 pm Central Europe time
>=20
> Bridge details:
>=20
> Chairperson Name:  KEITH DRAGE
> Access Phone Number:  8007718734
> International Access Phone Number:  +1 6477233953 7-Digit Access Code:
> 5776249=20
>=20
> While this call is in no sense restricted, this call is for=20
> people who have reviewed the document. If you think you=20
> qualify, and have not sent comments that are included above,=20
> or indeed reviewed and had no comments, then please send me a=20
> mail indicating this.
>=20
> Regards
>=20
> Keith
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 24 15:02:28 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgQGk-000312-G2; Tue, 24 Apr 2007 15:01:42 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HgQGi-0002v3-J3
	for sip-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 15:01:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgQGi-0002sw-8K; Tue, 24 Apr 2007 15:01:40 -0400
Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34]
	helo=exchfe2.cs.cornell.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HgQGi-0003GL-0i; Tue, 24 Apr 2007 15:01:40 -0400
Received: from EXCHANGE2.cs.cornell.edu ([128.84.96.44]) by
	exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 24 Apr 2007 15:01:39 -0400
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: Tue, 24 Apr 2007 15:01:39 -0400
Message-ID: <E6F7A586E0A3F94D921755964F6BE006BAD1EE@EXCHANGE2.cs.cornell.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-irtf-eme-francis-nutss-design-00.txt
Thread-Index: AceDhyStFYA0r0+LS4i+VusRKZz2FACYAjWAACzTCGAAAI2CYA==
From: "Paul Francis" <francis@cs.cornell.edu>
To: <nsis-request@ietf.org>,
	<sip@ietf.org>
X-OriginalArrivalTime: 24 Apr 2007 19:01:39.0572 (UTC)
	FILETIME=[FD4AF340:01C786A2]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: 
Subject: [Sip] draft-irtf-eme-francis-nutss-design-00.txt
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

=20
Sorry for the multi-mailing list spam, but I just wanted to alert the
"signaling community" to the recent draft in the EME (End-Middle-End) =
RG.
The design described is sort-of a mash-up of SIP and NSIS...

https://www1.ietf.org/mailman/listinfo/eme to join the EME mailing list.

Thanks,

PF


-----Original Message-----
From: Paul Francis=20
Sent: Tuesday, April 24, 2007 2:10 PM
To: eme
Cc: Paul Francis
Subject: finally!: draft-irtf-eme-francis-nutss-design-00.txt


Gang,

After weeks of quiet, we have finally generated a draft =
design/architecture
(called NUTSS) for the EME research group.  Its posted at:

http://www.ietf.org/internet-drafts/draft-irtf-eme-francis-nutss-design-0=
0.tx
t


The intent here is to use this as a strawman to generate concrete =
discussion,
with a goal of having a pretty solid proposal to bang on at an EME =
meeting in
Chicago this July.  Given the relatively short time frame, it'd be great =
if
folks could give this a read and start commenting in the next week or =
so.
The draft is not as long as it seems...most of it is examples.

The main feature of the NUTSS is the "dual signaling" approach, where =
both
path-coupled and path-decoupled signaling are tightly coordinated in =
order to
overcome the limitations of either mode alone.  Some form of =
dual-signaling
seems necessary to me, but there might be many ways to manage it.  This =
draft
suggests one way...others might have better ideas.

Thanks,

PF

=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 24 15:43:07 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgQu6-0003nE-U2; Tue, 24 Apr 2007 15:42:23 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HgQu5-0003n9-8V
	for sip-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 15:42:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HgQu4-0003n1-VE
	for sip@ietf.org; Tue, 24 Apr 2007 15:42:20 -0400
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 1HgQu2-0001wd-JW for sip@ietf.org; Tue, 24 Apr 2007 15:42:20 -0400
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-3.cisco.com with ESMTP; 24 Apr 2007 12:42:18 -0700
X-IronPort-AV: i="4.14,448,1170662400"; 
	d="scan'208"; a="481099156:sNHT50170164"
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3OJgHkL031032; 
	Tue, 24 Apr 2007 12:42:17 -0700
Received: from [171.70.217.104] ([171.70.217.104])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3OJelZW023236;
	Tue, 24 Apr 2007 19:42:17 GMT
In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E6126BBFB3@zrc2hxm2.corp.nortel.com>
References: <62B9B0847CC47543B6B3B5E26BD268E6126BBFB3@zrc2hxm2.corp.nortel.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <0F86F9A8-E4C9-456B-8135-786FA1E6E8FC@cisco.com>
Content-Transfer-Encoding: 7bit
From: Cullen Jennings <fluffy@cisco.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Tue, 24 Apr 2007 12:42:16 -0700
To: Samir Srivastava <samirsr@nortel.com>
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2763; t=1177443737;
	x=1178307737; c=relaxed/simple; s=sjdkim1004;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=fluffy@cisco.com;
	z=From:=20Cullen=20Jennings=20<fluffy@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20SIPS=20question=3A=20How=20to=20prevent=20pla
	intext=20requests=20from=20being=09delivered=20to=20a=20UA
	|Sender:=20; bh=hYWh0ikFCwIU+t4nk+leWUNZElw0uXCuXmdPxfjDj1g=;
	b=a7p3EW4VukZEITgLijCM13MaqS9+PnmcR9BSI5svwHIlWHiW4TZG0XdJvTLeF6S3OTK1W/3R
	R1O9duLrO11NyzpsaBf1GsCgwZuIaAM7MOXo6pDo2tK9rpxy5YTcO2EyrThnRTUdFqwahV61ih
	nsyCkiWX7O4bBCYP7CoMZonrM=;
Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim1004 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Cc: SIP <sip@ietf.org>, Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


After promising myself that I would not respond to the "Silly Thread  
of the Month" thread I find myself once again responding ...

I don't think most the WG thinks SIPS means what you would like it to  
mean.

I think there is one more common case you should consider - Alice  
dials a phone number and sends an INVITE with SIPS - this call gets  
routed to a PSTN GW - it does across the PSTN and goes to another GW  
to get routed to Bob's IP phone. This leg from the second GW to Bob's  
phone does not use TLS at all.  Most people in the WG think this is  
just fine.

Cullen <with my individual hat on>


On Apr 23, 2007, at 2:06 PM, Samir Srivastava wrote:

> My very simple requirement, which I posted recently to the Dean's
> question on the what callee wants. And a lot of this, I explained
> earlier.
>
> 1) If I am DOD, I want AES 256. As it is considered TOP SECRET by  
> them.
> If I am talking to bank then I want AES 256 (using KPML etc as it has
> lot of valuable information). If a CEO of company A is in talks  
> with CEO
> of another company B, he will need AES 256 for all along. As the call
> pattern tracking itself is more sensitive. As if Competetior of  
> Company
> of A knows that A and B are in talks, he can also come into the  
> picture.
> The damage varies on the size, content of talk (consider Page mode IM
> too).
>
> 2) If I am making 911 call, I need my call to be setup even with the
> plain text.
>
> 3) If I am small office owner in the downtown, then I might be okay  
> even
> with 3DES or 40 bit ciphers etc..
>
> 4) If I am a normal user, then I will need AES128 all along.
>
> 5) There are geographic regions, where ciphersuites just provide the
> integrity and no confidentiality. If my UA moves to those regions,  
> then
> atleast the proxy sitting at the boundary should inform the request
> needing back AES256, that it cannot be served.
>
> I have given a lot of other reasons earlier. Like Cheater Proxy,  
> the N+1
> Cycle for new cipher-suite development etc..
>
> My only request to the group is, please postpone the decision of SIPS
> with patches as STANDARD track document, till I publish my next  
> version
> of the cipher-suite draft.
>
> Thx
> Samir
>
>>
>> There are two features being discussed here:
>>
>> 1. An indicator of which cipher suite was negotiated.
>> 2. A signal that you want the next hop to negotiate a specific
>>   set of cipher suites.
>>
>> I have no problem with the first feature, though I'm not sure
>> it's incredibly useful. I don't agree that the second feature
>> is particularly useful. The cases where it's relevant strike
>> me as fairly esoteric and unlikely.
>>
>> -Ekr
>>
>>
>>
>>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 24 15:43:40 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgQvM-00046a-Gz; Tue, 24 Apr 2007 15:43:40 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HgQvK-00046U-VY
	for sip-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 15:43:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HgQvK-00046J-Lt
	for sip@ietf.org; Tue, 24 Apr 2007 15:43:38 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgQvJ-0002Gr-4P
	for sip@ietf.org; Tue, 24 Apr 2007 15:43:38 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 24 Apr 2007 15:43:38 -0400
X-IronPort-AV: i="4.14,448,1170651600"; 
	d="scan'208"; a="58513059:sNHT66879204"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3OJhad6016889; 
	Tue, 24 Apr 2007 15:43:36 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3OJhLGx024163; 
	Tue, 24 Apr 2007 19:43:30 GMT
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.1830); 
	Tue, 24 Apr 2007 15:43:21 -0400
Received: from jmpolk-wxp.cisco.com ([10.89.16.81]) by
	xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 24 Apr 2007 15:43:20 -0400
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 24 Apr 2007 14:43:19 -0500
To: rishu.jain@aricent.com, "Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>
From: "James M. Polk" <jmpolk@cisco.com>
Subject: Re: [Sip] WGLC on draft-ietf-sip-location-conveyance
In-Reply-To: <OF1827C20F.727F664C-ON652572B1.0017196E-652572B1.00174596@
	flextronicssoftware.com>
References: <5D1A7985295922448D5550C94DE29180DC1CC4@DEEXC1U01.de.lucent.com>
	<OF1827C20F.727F664C-ON652572B1.0017196E-652572B1.00174596@flextronicssoftware.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <XFE-RTP-202ytQEVFwm00004533@xfe-rtp-202.amer.cisco.com>
X-OriginalArrivalTime: 24 Apr 2007 19:43:20.0516 (UTC)
	FILETIME=[CFF8B840:01C786A8]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9720; t=1177443816;
	x=1178307816; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jmpolk@cisco.com;
	z=From:=20=22James=20M.=20Polk=22=20<jmpolk@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20WGLC=20on=20draft-ietf-sip-location-conveyanc
	e |Sender:=20
	|To:=20rishu.jain@aricent.com, =0A=20=20=20=20=20=20=20=20=22Drage,
	=20Keit h=20\(Keith\)=22=20<drage@alcatel-lucent.com>;
	bh=5ugvj1JPFFXv9A8XUGmZMIksOdUwSGYjJmzR2Yi4oqw=;
	b=AcXBBykdpXswTcYxL8FjbtOIOhKWcMVNNZsxPBzHvJdhZ3zZeU3ZOVeGHgzDSklvN+dMjKPU
	7/ThP+6pOqQUGj/Rv0Mc6ahswC8B2t5ZlQitr7RMJ3+dmC/TY4O+MnUG;
Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990
Cc: sip@ietf.org, geopriv-chairs@tools.ietf.org, dean.willis@softarmor.com
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

See comments in-line

At 11:13 PM 4/1/2007, rishu.jain@aricent.com wrote:

>Some comments/questions on the draft.
>
>
>1) Multiple Locations:
>- Section 5.3.1
>A server/proxy can add gelocation value to the existing geolocation
>header provided by UAC. In that case the messsage would look like this:
>
>Geolocation: <cid:alice123@atlanta.example.com>; inserted-by=endpoint,
>                     <sips:3sdefrhy2jj7@lis.atlanta.example.com>;
>                     inserted-by=server;
>
>=>How the location recipient will decide which location is to
>be referred to? Either the one provided in the Sip message (CID URI)
>or he has to subscribe to the location provided in SIPS URI?

This is a local policy decision - when there is more than one 
location (either by-value or by-reference or one or more of both) in 
a SIP message.  This is the complication of allowing more than one 
location in a SIP message.


>2) Location by reference overhead:
>Look at the following scenario (P - is also a location recipient):
>
>              LIS                                     LIS
>             ^  |                                      ^  |
>SUBSCRIBE |  | NOTIFY          SUBSCRIBE |  |NOTIFY
>             |  |                                 |  |
>UA ------->  P1 ------------------>  P2  ----------->
>    INIVITE           INVITE                   INVITE
>
>In order to take action based on "retransmission-allowed" or not,
>P1 has to subscribe to the LIS (Location Information Server),
>obtain the location and then take the action. The same has to be
>done by all the intermediate proxies. So is this not a overhead?

this is location conveyed indirectly.  If location is not *in* the 
message, it MAY have to be retrieved from an external source.

We have concluded that LbyR (Location-by-Reference) does not violate 
the retransmission flag in an LbyR dereference.

BTW - both P1 and P2 will likely SUB/NOT to the same LIS for the same 
location-by-reference.


>3) "retransmission-allowed"
>Even if "retransmission-allowed" value is set to "no", can the
>proxy remove the PIDF location object from the message?

no, per 3261 (as you state)

>RFC 3261
>does not allow any proxy to add or delete the message body. So what
>is the use of "retransmission-allowed" with value "yes" or "no"?

I believe this is discussing whether or not the proxy can copy the 
location and send it somewhere else (i.e. not in this transaction).


>4) What is the behavior in following case:
>
>Retransmission-allowed Routing-query-allowed Transmission for Query
>---------------------- --------------------- ----------------------
>         "no"                  not present           ?????

Transmission for Query is "not allowed"



>5) "message-routed-on-this-uri" tells the downstream entity that
>is was routed based on location once. In section  5.3.1 it is
>mentioned that in case multiple times if routing is done based on
>location still only one latest entry of "message-routed-on-this-uri"
>is sufficient.

This will be corrected to keep the "message-routed-on-this-uri" for 
each location URI the message was routed on, in times where more than 
one proxy routed the message from different URIs (locations in the message).


>Why downstrem entity need to know that only one routing has
>happened (if at all it needs to know)?

The goal of this is to give routing information to the PSAP for their 
consumption, and after the call forensics (if the call was misrouted 
or something went wrong). PSAPs want to have the ability to go to 
where the problem was and request a correction so it doesn't happen again.

>Why it need not find out
>multiple location based routing was done?

again, this will be corrected. And, hopefully, if there is routing 
done more than once, any subsequent routing would correct any error done.


>6) Section 3.2: Use of the header in BYE, INFO and REFER
>Methods are allowed, although no purpose is known.  Conveying
>location in a CANCEL, BYE, ACK or PRACK is not defined.
>
>Conveying location in "BYE" is defined or not?

this is an error, and Location is should not be in a BYE (unless 
someone has a use case indicating a reason for it to be?)


>7) <sips: username@server.com> or <sips:server.com/username>
>are these same? Is the second form a valid SIP URI?

I believe so. My co-author put this in.  Because you're questioning 
this, we will check.  Thanks!



>8) Why only PIDF format is selected.

because the IETF and the emergency services community (to date) has 
requested the least amount of errors possible, and limiting Location 
to be only in one format (which the IETF is pushing into IEEE, ATIS, 
TIA and other SDOs) means there is hopefully no information lost in 
any translation when converting location formats.

>
>9) Assume the case that UAC has sent his identity in the first INVITE.

this is likely

>Callee would have subscribed to that identity and would get the
>caller's location.

right now, one UA(1) Subscribing to another UA(2) for UA2's location 
is a pull mechanism and is not defined in this document.  That's 
being left for a future ID.

>Now if caller's identity is changed and caller
>sent a new RE-INVITE message. Should callee then stop subscription
>with first location and should subscribe to the new location?
>There is no behaviour with respect to this is mentioned in UAS scope?

correct, see just above to read that this is out-of-scope for the 
Location Conveyance ID.

Thanks for the detailed review, and sorry for the late response.



>regards
>Rishu
>
>
>
>
>
>"Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>
>
>03/05/2007 01:05 AM
>To
><sip@ietf.org>
>cc
>geopriv-chairs@tools.ietf.org, jmpolk@cisco.com, dean.willis@softarmor.com
>Subject
>[Sip] WGLC on draft-ietf-sip-location-conveyance
>
>
>
>
>(As WG chair)
>
>This is to announce a working group last call of
>
>http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-07.txt
>
>Due to the presence of IETF#68 in Prague, this is an extended last 
>call (for four weeks), and comments should be provided by start of 
>business on Monday 2nd April 2007.
>
>However if you think there are significant technical issues that 
>should be raised in IETF#68, please review the document well before 
>that time to make your comment to the list, so that such discussion 
>in the IETF meeting can occur.
>
>Please provide all comments to the SIP mailing list, and also to the 
>document authors listed (and mailing addresses) listed at the end of 
>the document. For each comment, it is ideal to provide the copy the 
>specific part of the text the comment is against, in order to 
>provide context of the comment, as well as identifying the 
>section/page and the comment itself.
>
>Please also clearly indicate whether the comment is 
>editorial/technical, and if technical the degree of the comment, 
>e.g. minor, major flaw, wrong solution, or whatever. This helps in 
>assessing the order in which comments get addressed when they are reviewed.
>
>In parallel with WGLC, a review team has also been set up to review 
>the document, and this review team will review at least the 
>significant comments for implementation. I will be addressing them 
>in a separate mail.
>
>As the document is a location supporting protocol, the document will 
>also be reviewed by the GEOPRIV group. However it is appropriate for 
>all readers to review the document against the GEOPRIV requirements 
>for such protocols, which may be found in RFC 3963.
>
>The above document however does not cover location by reference. 
>There is a preliminary set or requirements in
>
>http://www.ietf.org/internet-drafts/draft-marshall-geopriv-lbyr-requirements-00.txt
>
>For which we would like to align with whatever that document 
>develops into. Therefore it is appropriate to review against this 
>document, and identify differences. These could either be taken as 
>comments against the draft-ietf-sip-location-conveyance, or against 
>the location by reference requirements.
>
>
>Regards
>
>Keith
>
>Keith Drage
>+44 1793 776249
>drage@alcatel-lucent.com
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip
>
>
>***********************  Aricent-Unclassified   ***********************
>
>"DISCLAIMER: This message is proprietary to Aricent and is intended 
>solely for the use of
>the individual to whom it is addressed. It may contain privileged or 
>confidential information and should not be
>circulated or used for any purpose other than for what it is 
>intended. If you have received this message in error,
>please notify the originator immediately. If you are not the 
>intended recipient, you are notified that you are strictly
>prohibited from using, copying, altering, or disclosing the contents 
>of this message. Aricent accepts no responsibility for
>loss or damage arising from the use of the information transmitted 
>by this email including damage from virus."
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 24 16:41:51 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgRp2-0003w9-IY; Tue, 24 Apr 2007 16:41:12 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HgRp1-0003w1-Cx
	for sip-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 16:41:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HgRp1-0003vt-3K
	for sip@ietf.org; Tue, 24 Apr 2007 16:41:11 -0400
Received: from zrtps0kp.nortel.com ([47.140.192.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgRox-0008Uw-QC
	for sip@ietf.org; Tue, 24 Apr 2007 16:41:11 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3OKf4w24651; Tue, 24 Apr 2007 20:41:04 GMT
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: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Tue, 24 Apr 2007 15:40:59 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E61271D2D7@zrc2hxm2.corp.nortel.com>
In-Reply-To: <0F86F9A8-E4C9-456B-8135-786FA1E6E8FC@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
thread-index: AceGqKxig0GNZ5ZCTuaSmr0oGrjPegABs+rw
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Cullen Jennings" <fluffy@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: SIP <sip@ietf.org>, Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Fast forward on the time dimension, when you have complete IP network
and PSTN is gone, do we want to have a network cloud which carries the
same legacy of PSTN that missing the security level (cipher-suites),
reverse channel, feature control etc.

We cannot change the current PSTN, so we have to live with that. But
while designing security for the tommorrow's network do we want to
repeat the same mistake. PSTN doesn't have that because it was by nature
secure. Here security is after thought. It's inherent property of IP.

It may be silly but I don't find it embarrasing to discuss and clear the
issues. I may be having hurdles in other eyes, but may be in process of
clearing that hurdles, we might get something else.

Thx
Samir


>-----Original Message-----
>From: Cullen Jennings [mailto:fluffy@cisco.com]=20
>Sent: Tuesday, April 24, 2007 12:42 PM
>To: Srivastava, Samir (SC100:8826)
>Cc: Eric Rescorla; Audet, Francois (SC100:3055); SIP
>Subject: Re: [Sip] SIPS question: How to prevent plaintext=20
>requests from being delivered to a UA
>
>
>After promising myself that I would not respond to the "Silly=20
>Thread of the Month" thread I find myself once again responding ...
>
>I don't think most the WG thinks SIPS means what you would=20
>like it to mean.
>
>I think there is one more common case you should consider -=20
>Alice dials a phone number and sends an INVITE with SIPS -=20
>this call gets routed to a PSTN GW - it does across the PSTN=20
>and goes to another GW to get routed to Bob's IP phone. This=20
>leg from the second GW to Bob's phone does not use TLS at all.=20
> Most people in the WG think this is just fine.
>
>Cullen <with my individual hat on>
>
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 24 17:45:50 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgSo7-0004iV-S7; Tue, 24 Apr 2007 17:44:19 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HgSo5-0004hP-NJ
	for sip-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 17:44:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HgSo5-0004fq-DB
	for sip@ietf.org; Tue, 24 Apr 2007 17:44:17 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgSo4-00050n-2P
	for sip@ietf.org; Tue, 24 Apr 2007 17:44:17 -0400
Received: from [64.101.172.113] ([64.101.172.113]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3OKow72011379
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Tue, 24 Apr 2007 15:51:02 -0500
In-Reply-To: <0F86F9A8-E4C9-456B-8135-786FA1E6E8FC@cisco.com>
References: <62B9B0847CC47543B6B3B5E26BD268E6126BBFB3@zrc2hxm2.corp.nortel.com>
	<0F86F9A8-E4C9-456B-8135-786FA1E6E8FC@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <67AAAE3B-ED17-4FD2-AC90-9514FA010D50@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] SIPS question: How to prevent plaintext requests from
	being	delivered to a UA
Date: Tue, 24 Apr 2007 16:43:51 -0500
To: Cullen Jennings <fluffy@cisco.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: SIP <sip@ietf.org>, Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 24, 2007, at 2:42 PM, Cullen Jennings wrote:

> I think there is one more common case you should consider - Alice  
> dials a phone number and sends an INVITE with SIPS - this call gets  
> routed to a PSTN GW - it does across the PSTN and goes to another  
> GW to get routed to Bob's IP phone. This leg from the second GW to  
> Bob's phone does not use TLS at all.  Most people in the WG think  
> this is just fine.

Although it should be noted that we did debate this in detail, and  
some participants had advanced the idea that SIPS should never be  
degraded to a non-SIPS external protocol.

We ran into deep water trying to define exactly what this meant, and  
gave up by saying the responsibility for SIPS stops at the UAS. This  
makes makes it technically, if not morally, correct to build a B2BUA  
that adapts from SIPS to SIP.

While not satisfying to everybody on the list, I think we have a  
consensus that this is a least a sufficiently definable and bounded  
case that we can work with it for now.

I believe that this is however COMPLETELY orthogonal to and  
independent of the desire to request some specific variety or grade  
of cryptography on SIPS links and the related desire to inform the  
endpoints about the cryptography of those links. Since SIPS is not  
itself end-to-end, the openness (OPES) principle argues that we  
should at least tell the UAs what happened with their data.

I have however come to feel that this is a fairly pointless exercise  
since there is a far higher probability of leakage from alternative  
paths into the trusted (but possibly not trustworthy) proxies than  
there is of successful cryptographic attack on the links between  
those proxies. Given this, I find it far more interesting to discuss  
true end-to-end protection mechanisms such as SIPSEC. Such a  
mechanism would moot the need for UAs to tell proxies how to do their  
business, and would also moot the need for proxies to to tell UAs  
what the proxies have done, since UAs would both do and know exactly  
what happened. The same can be said for alternative proposals, such  
as request tunneling over a non-SIP P2P secured routing protocol.

In any case, unless there is a substantial change in consensus, we  
currently do not have a strong enough interest in solving these  
problems to justify investment of substantial working group time and  
energy. I encourage the authors of sipsec and ciphersuites to  
continue to develop their ideas and maintain them as individual  
drafts, because there may come a day when we find interest in either  
the problems they attempt to address or the solutions they attempt to  
define. It's even fair to point them out on the list occasionally,  
accept comments and discussion, and even every now and then (perhaps  
once per meeting cycle) ask what the current level of interest in the  
work is.

or to paraphrase a local aphorism: Hunting season's over for this  
dog, this year. You can quit throwing the training dummy at him for a  
while.

--
Dean Willis
Co-Chair



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Tue Apr 24 17:50:24 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgSth-0007gX-97; Tue, 24 Apr 2007 17:50:05 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HgStf-0007gF-RD
	for sip-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 17:50:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HgStf-0007g6-Hg
	for sip@ietf.org; Tue, 24 Apr 2007 17:50:03 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgSte-0005rC-7x
	for sip@ietf.org; Tue, 24 Apr 2007 17:50:03 -0400
Received: from [64.101.172.113] ([64.101.172.113]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3OKupOI011417
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Tue, 24 Apr 2007 15:56:52 -0500
In-Reply-To: <462DA69F.1070400@nokia.com>
References: <E1HMrLq-0007Rc-2u@ietf.org>	<3E4278088AD82C48B4663DDFE762CEF302ED4E3F@prga004a.ww300.siemens.net>
	<0B0F1FB0-451A-4E18-9582-6C19F8044EC3@softarmor.com>
	<462DA69F.1070400@nokia.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <933C3A36-71C9-4E26-8B8A-DA8F1A674F45@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] RE: New Liaison Statement, "OMA LS 178 on XCAP diff-event"
Date: Tue, 24 Apr 2007 16:49:47 -0500
To: Jari Urpalainen <jari.urpalainen@nokia.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: Cullen Jennings <fluffy@cisco.com>, IETF SIP List <sip@ietf.org>,
	Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>,
	drage@alcaltel-lucent.com, Antti Laurila <Antti.K.Laurila@nokia.com>,
	mary Barnes <mary.barnes@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 24, 2007, at 1:41 AM, Jari Urpalainen wrote:
> A concern was raised about the initial sync stage, so what could be  
> less sucking options ? Actually there's a need for versioned  
> retrieval of documents based on their ETags which would cleanly  
> solve this issue.
>
> One option would be that servers would make temporary copies of  
> subscribed documents during the initial subscription, and these  
> temporary URIs along  with the real URIs would be carried within  
> the body of xcap-diff document. The client would need to fetch then  
> these versioned resources based on temporary URIs. For the server  
> implementation this is ugly and somewhat error prone, i.e. e.g.  
> when to remove these temporary stuff.
>
> A better option would be to have "real" versioning on the xcap  
> server. So one could retrieve documents e.g. by requesting GET / 
> resource-lists/joe/index?etag=sfsdf343ds. So client would really  
> request the ETag based versioned  resource.  What's nice here that  
> you could add rfc3229 semantics here quite easily also, i.e. the  
> client could say: "I have this xyz version, give me the patch to  
> the latest version". Of course, for the server this would be yet  
> another additional requirement for the already pretty complex xcap  
> picture.
>
> So what am I missing here ? This issue is sad in a sense that it is  
> once again those cases which rarely exist in practice, a real  
> corner case that is.

dude, I am SO not wanting to go back to OMA with an LS that says  
"Sorry, we need to revise XCAP to do full-blown versioning to meet  
your needs".

What ARE we going to tell them?

My understanding was we were going to do a fairly straightforward  
event package that met their needs, based on your old draft. As I  
remember, this simply made it necessary to do a full get of the most- 
current if you lost synch. Is this not acceptable?

--
Dean


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 25 01:34:41 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hga95-00062F-BE; Wed, 25 Apr 2007 01:34:27 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hga94-000627-2Z
	for sip-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 01:34:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hga93-00061z-86
	for sip@ietf.org; Wed, 25 Apr 2007 01:34:25 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hga91-0000tu-Ok
	for sip@ietf.org; Wed, 25 Apr 2007 01:34:25 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 25 Apr 2007 01:34:25 -0400
X-IronPort-AV: i="4.14,449,1170651600"; 
	d="scan'208"; a="58551003:sNHT48310120"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3P5YNYU017290; 
	Wed, 25 Apr 2007 01:34:23 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3P5YNlG027180; 
	Wed, 25 Apr 2007 05:34:23 GMT
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.1830); 
	Wed, 25 Apr 2007 01:34:23 -0400
Received: from jmpolk-wxp.cisco.com ([10.89.16.81]) by
	xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 25 Apr 2007 01:34:22 -0400
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 25 Apr 2007 00:34:21 -0500
To: "Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>,
	"IETF SIP List" <sip@ietf.org>
From: "James M. Polk" <jmpolk@cisco.com>
Subject: RE: [Sip] Review of draft-ietf-sip-location-conveyance
In-Reply-To: <5D1A7985295922448D5550C94DE2918001084501@DEEXC1U01.de.luce
	nt.com>
References: <5D1A7985295922448D5550C94DE29180FFE84C@DEEXC1U01.de.lucent.com>
	<5D1A7985295922448D5550C94DE2918001084501@DEEXC1U01.de.lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <XFE-RTP-202ez1enAqp000045d8@xfe-rtp-202.amer.cisco.com>
X-OriginalArrivalTime: 25 Apr 2007 05:34:22.0650 (UTC)
	FILETIME=[610CF1A0:01C786FB]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2726; t=1177479263;
	x=1178343263; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jmpolk@cisco.com;
	z=From:=20=22James=20M.=20Polk=22=20<jmpolk@cisco.com>
	|Subject:=20RE=3A=20[Sip]=20Review=20of=20draft-ietf-sip-location-conveya
	nce |Sender:=20
	|To:=20=22Drage, =20Keith=20\(Keith\)=22=20<drage@alcatel-lucent.com>,
	=0A=
	20=20=20=20=20=20=20=20=22IETF=20SIP=20List=22=20<sip@ietf.org>;
	bh=Eza8tPdEmZKjiDFdzopZtocks7G5gBcN64uXQwlgKB0=;
	b=ozhIDBUGfMt2rXa+CZVwB66bCvANhUIaSlf7ICIMpGrqixLci3mQaH8dsovCuxGJ3C06E0gf
	OtTott/kn2yBp9f3cNDX8wbOA9UcqNTkx4wC6js9+VMw/u133waf0syU;
Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

1st half of the list from me (it's 12:30am and time for bed)

At 12:38 PM 4/24/2007, Drage, Keith \(Keith\) wrote:
>A reminder of the call tomorrow, and also that I have posted an updated
>set of comments including some late comments received.
>
>The numbering remains consistent for the comments that were previously
>posted, and we will refer to comments by numbers on the call tomorrow.

IMO, these points should be discussed on the call:

2, 3, 7, 11, 13, 16, 19, 21, 25, 27, 29, 30, 31, 43A, 61A, 64, 73, 
74, 76, 78, 79, 80, 84/85, 88, .......................

....more coming in the morning

These points are "maybes" for the call:

6, 10, 23, 31A, , , , , , , , , , , , , , , , , , , , , , , , , , , , 
, , , , , , , , ,

....more coming in the morning



>Keith
>
> > -----Original Message-----
> > From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com]
> > Sent: Monday, April 16, 2007 6:13 PM
> > To: IETF SIP List
> > Subject: [Sip] Review of draft-ietf-sip-location-conveyance
> >
> > I have posted the comments from WGLC on
> > draft-ietf-sip-location-conveyance at:
> >
> > http://www.softarmor.com/sipwg/reviews/location-conveyance/index.html
> >
> > Please let me know if I have missed any comments.
> >
> > There will be a review conference call of these comments on:
> >
> > Wednesday 25th April at
> >
> >       1:00 pm - 3:00 pm Central US time
> >       2:00 pm - 4:00 pm Eastern US time
> >       7:00 pm - 9:00 pm UK time
> >       8:00 pm - 10:00 pm Central Europe time
> >
> > Bridge details:
> >
> > Chairperson Name:  KEITH DRAGE
> > Access Phone Number:  8007718734
> > International Access Phone Number:  +1 6477233953 7-Digit Access Code:
> > 5776249
> >
> > While this call is in no sense restricted, this call is for
> > people who have reviewed the document. If you think you
> > qualify, and have not sent comments that are included above,
> > or indeed reviewed and had no comments, then please send me a
> > mail indicating this.
> >
> > Regards
> >
> > Keith
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use
> > sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> >
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 25 03:18:20 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgblR-0004Zf-88; Wed, 25 Apr 2007 03:18:09 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HgblP-0004ZU-Bp
	for sip-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 03:18:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HgblM-0004ZF-4A
	for sip@ietf.org; Wed, 25 Apr 2007 03:18:04 -0400
Received: from mail.gmx.net ([213.165.64.20])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HgblK-0003YB-KB
	for sip@ietf.org; Wed, 25 Apr 2007 03:18:04 -0400
Received: (qmail invoked by alias); 25 Apr 2007 07:18:01 -0000
Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26]
	by mail.gmx.net (mp040) with SMTP; 25 Apr 2007 09:18:01 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19A7cF+XLtAnRX4YK/Y1L4srMX7Hw6WydbfxhADX6
	9QMNzsWE6iPNFL
Message-ID: <462F00A8.60605@gmx.net>
Date: Wed, 25 Apr 2007 09:18:00 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
Subject: Re: [Sip] Review of draft-ietf-sip-location-conveyance
References: <5D1A7985295922448D5550C94DE29180FFE84C@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE2918001084501@DEEXC1U01.de.lucent.com>
	<XFE-RTP-202ez1enAqp000045d8@xfe-rtp-202.amer.cisco.com>
In-Reply-To: <XFE-RTP-202ez1enAqp000045d8@xfe-rtp-202.amer.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
Cc: IETF SIP List <sip@ietf.org>, "Drage,
	Keith \(Keith\)" <drage@alcatel-lucent.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi Keith,

I took a look at the webpage 
(http://www.softarmor.com/sipwg/reviews/location-conveyance/location-conveyance-comments-r1.htm) 
and I noticed that only minor editorial comments were captured on your 
webpage.
I believe that the technical comments are more important. Should they 
also be added to the page?

Ciao
Hannes

James M. Polk wrote:
> 1st half of the list from me (it's 12:30am and time for bed)
>
> At 12:38 PM 4/24/2007, Drage, Keith \(Keith\) wrote:
>> A reminder of the call tomorrow, and also that I have posted an updated
>> set of comments including some late comments received.
>>
>> The numbering remains consistent for the comments that were previously
>> posted, and we will refer to comments by numbers on the call tomorrow.
>
> IMO, these points should be discussed on the call:
>
> 2, 3, 7, 11, 13, 16, 19, 21, 25, 27, 29, 30, 31, 43A, 61A, 64, 73, 74, 
> 76, 78, 79, 80, 84/85, 88, .......................
>
> ....more coming in the morning
>
> These points are "maybes" for the call:
>
> 6, 10, 23, 31A, , , , , , , , , , , , , , , , , , , , , , , , , , , , 
> , , , , , , , , ,
>
> ....more coming in the morning
>
>
>
>> Keith
>>
>> > -----Original Message-----
>> > From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com]
>> > Sent: Monday, April 16, 2007 6:13 PM
>> > To: IETF SIP List
>> > Subject: [Sip] Review of draft-ietf-sip-location-conveyance
>> >
>> > I have posted the comments from WGLC on
>> > draft-ietf-sip-location-conveyance at:
>> >
>> > http://www.softarmor.com/sipwg/reviews/location-conveyance/index.html
>> >
>> > Please let me know if I have missed any comments.
>> >
>> > There will be a review conference call of these comments on:
>> >
>> > Wednesday 25th April at
>> >
>> >       1:00 pm - 3:00 pm Central US time
>> >       2:00 pm - 4:00 pm Eastern US time
>> >       7:00 pm - 9:00 pm UK time
>> >       8:00 pm - 10:00 pm Central Europe time
>> >
>> > Bridge details:
>> >
>> > Chairperson Name:  KEITH DRAGE
>> > Access Phone Number:  8007718734
>> > International Access Phone Number:  +1 6477233953 7-Digit Access Code:
>> > 5776249
>> >
>> > While this call is in no sense restricted, this call is for
>> > people who have reviewed the document. If you think you
>> > qualify, and have not sent comments that are included above,
>> > or indeed reviewed and had no comments, then please send me a
>> > mail indicating this.
>> >
>> > Regards
>> >
>> > Keith
>> >
>> >
>> > _______________________________________________
>> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> > This list is for NEW development of the core SIP Protocol Use
>> > sip-implementors@cs.columbia.edu for questions on current sip
>> > Use sipping@ietf.org for new developments on the application of sip
>> >
>>
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use sip-implementors@cs.columbia.edu for questions on current sip
>> Use sipping@ietf.org for new developments on the application of sip
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 25 03:23:17 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgbqO-0000z2-J6; Wed, 25 Apr 2007 03:23:16 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HgbqN-0000yu-Az
	for sip-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 03:23:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HgbqN-0000yh-11
	for sip@ietf.org; Wed, 25 Apr 2007 03:23:15 -0400
Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgbqL-0004Pw-H5
	for sip@ietf.org; Wed, 25 Apr 2007 03:23:15 -0400
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145])
	by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id
	l3P7MqK3002670; Wed, 25 Apr 2007 10:23:08 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by
	esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 25 Apr 2007 10:23:07 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by
	esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 25 Apr 2007 10:23:06 +0300
Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by
	esebh102.NOE.Nokia.com over TLS secured channel with Microsoft
	SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 10:23:06 +0300
Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13])
	by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id
	l3P7N4tA018968; Wed, 25 Apr 2007 10:23:04 +0300
Received: from [172.21.41.217] (esdhcp041217.research.nokia.com
	[172.21.41.217]) by kusti.research.nokia.com (Postfix) with ESMTP
	id 59B4C93B77; Wed, 25 Apr 2007 10:23:04 +0300 (EEST)
Message-ID: <462F01D8.4040308@nokia.com>
Date: Wed, 25 Apr 2007 10:23:04 +0300
From: Jari Urpalainen <jari.urpalainen@nokia.com>
User-Agent: Thunderbird 1.5.0.10 (X11/20070302)
MIME-Version: 1.0
To: ext Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] RE: New Liaison Statement, "OMA LS 178 on XCAP diff-event"
References: <E1HMrLq-0007Rc-2u@ietf.org>	<3E4278088AD82C48B4663DDFE762CEF302ED4E3F@prga004a.ww300.siemens.net>
	<0B0F1FB0-451A-4E18-9582-6C19F8044EC3@softarmor.com>
	<462DA69F.1070400@nokia.com>
	<933C3A36-71C9-4E26-8B8A-DA8F1A674F45@softarmor.com>
In-Reply-To: <933C3A36-71C9-4E26-8B8A-DA8F1A674F45@softarmor.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 25 Apr 2007 07:23:06.0695 (UTC)
	FILETIME=[91AF3570:01C7870A]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Cc: Cullen Jennings <fluffy@cisco.com>, IETF SIP List <sip@ietf.org>,
	Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>,
	drage@alcaltel-lucent.com, Antti Laurila <Antti.K.Laurila@nokia.com>,
	mary Barnes <mary.barnes@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

ext Dean Willis wrote:
>
> On Apr 24, 2007, at 1:41 AM, Jari Urpalainen wrote:
>> A concern was raised about the initial sync stage, so what could be 
>> less sucking options ? Actually there's a need for versioned 
>> retrieval of documents based on their ETags which would cleanly solve 
>> this issue.
>>
>> One option would be that servers would make temporary copies of 
>> subscribed documents during the initial subscription, and these 
>> temporary URIs along  with the real URIs would be carried within the 
>> body of xcap-diff document. The client would need to fetch then these 
>> versioned resources based on temporary URIs. For the server 
>> implementation this is ugly and somewhat error prone, i.e. e.g. when 
>> to remove these temporary stuff.
>>
>> A better option would be to have "real" versioning on the xcap 
>> server. So one could retrieve documents e.g. by requesting GET 
>> /resource-lists/joe/index?etag=sfsdf343ds. So client would really 
>> request the ETag based versioned  resource.  What's nice here that 
>> you could add rfc3229 semantics here quite easily also, i.e. the 
>> client could say: "I have this xyz version, give me the patch to the 
>> latest version". Of course, for the server this would be yet another 
>> additional requirement for the already pretty complex xcap picture.
>>
>> So what am I missing here ? This issue is sad in a sense that it is 
>> once again those cases which rarely exist in practice, a real corner 
>> case that is.
>
> dude, I am SO not wanting to go back to OMA with an LS that says 
> "Sorry, we need to revise XCAP to do full-blown versioning to meet 
> your needs".
right, well I just gave some alternatives (there are others as well...). 
So I'm not really proposing this, just trying to move forward.
>
> What ARE we going to tell them?
>
Let's do what the minutes say, move this to sip(ping) wg item or do the 
informational thing, i.e. act ;-). And continue solving this issue.
> My understanding was we were going to do a fairly straightforward 
> event package that met their needs, based on your old draft. As I 
> remember, this simply made it necessary to do a full get of the 
> most-current if you lost synch. Is this not acceptable?
>
> -- 
> Dean
I think what is written in the spec is the simplest solution, during the 
initial sync stage the client just skips those possible already applied 
patches, just some simple buffering (if even needed) on the client side. 
Also during the subscription time it may happen that you have to 
retrieve full docs. And then this ugly thing happens that you need two 
round trips for this aggregation mode, but the alternatives aren't 
better unless I'm missing here something. And once again this case 
rarely exist in practice but implementers (especially clients) must be 
aware of this. So it is anticipated that you can usually start with the 
aggregation mode straight away, but it may fail. If it does, then retry 
with this ugly mode. As I said versioning is imo the proper way to make 
this cleanly work, but it does have other consequences...
br,
Jari



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 25 05:52:14 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgeAU-0005H0-JS; Wed, 25 Apr 2007 05:52:10 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HgeAR-0005Gm-VR
	for sip-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 05:52:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HgeAR-0005Ge-J5
	for sip@ietf.org; Wed, 25 Apr 2007 05:52:07 -0400
Received: from ihemail1.lucent.com ([135.245.0.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgeAQ-0000sJ-4R
	for sip@ietf.org; Wed, 25 Apr 2007 05:52:07 -0400
Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l3P9pq40006670;
	Wed, 25 Apr 2007 04:52:04 -0500 (CDT)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by
	ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 25 Apr 2007 04:51:58 -0500
Received: from DEEXC1U01.de.lucent.com ([135.248.187.26]) by
	DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 25 Apr 2007 11:51:53 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Review of draft-ietf-sip-location-conveyance
Date: Wed, 25 Apr 2007 11:51:51 +0200
Message-ID: <5D1A7985295922448D5550C94DE29180010846EE@DEEXC1U01.de.lucent.com>
In-Reply-To: <462F00A8.60605@gmx.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Review of draft-ietf-sip-location-conveyance
Thread-Index: AceHCfgZEmnUmbw7STSQyNciveroowAFQNKg
References: <5D1A7985295922448D5550C94DE29180FFE84C@DEEXC1U01.de.lucent.com>	<5D1A7985295922448D5550C94DE2918001084501@DEEXC1U01.de.lucent.com>
	<XFE-RTP-202ez1enAqp000045d8@xfe-rtp-202.amer.cisco.com>
	<462F00A8.60605@gmx.net>
From: "Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>
To: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
X-OriginalArrivalTime: 25 Apr 2007 09:51:53.0333 (UTC)
	FILETIME=[5A601250:01C7871F]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Then you need to tell me what is missing - as does anyone else who =
posted comments.

I believe I took all the comments from both your comments on -05 and the =
new ones on -07. Obviously I had to add the classification because you =
in general omitted it. In general I also had to try and identify section =
numbers as well.

(Now if you had followed the instructions in the original posting as to =
presentation it would have made my job easier and less likely to error.)

Regards

Keith

> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20
> Sent: Wednesday, April 25, 2007 8:18 AM
> Cc: Drage, Keith (Keith); IETF SIP List
> Subject: Re: [Sip] Review of draft-ietf-sip-location-conveyance
>=20
> Hi Keith,
>=20
> I took a look at the webpage
> (http://www.softarmor.com/sipwg/reviews/location-conveyance/lo
> cation-conveyance-comments-r1.htm)
> and I noticed that only minor editorial comments were=20
> captured on your webpage.
> I believe that the technical comments are more important.=20
> Should they also be added to the page?
>=20
> Ciao
> Hannes
>=20
> James M. Polk wrote:
> > 1st half of the list from me (it's 12:30am and time for bed)
> >
> > At 12:38 PM 4/24/2007, Drage, Keith \(Keith\) wrote:
> >> A reminder of the call tomorrow, and also that I have posted an=20
> >> updated set of comments including some late comments received.
> >>
> >> The numbering remains consistent for the comments that were=20
> >> previously posted, and we will refer to comments by=20
> numbers on the call tomorrow.
> >
> > IMO, these points should be discussed on the call:
> >
> > 2, 3, 7, 11, 13, 16, 19, 21, 25, 27, 29, 30, 31, 43A, 61A,=20
> 64, 73, 74,=20
> > 76, 78, 79, 80, 84/85, 88, .......................
> >
> > ....more coming in the morning
> >
> > These points are "maybes" for the call:
> >
> > 6, 10, 23, 31A, , , , , , , , , , , , , , , , , , , , , , ,=20
> , , , , ,=20
> > , , , , , , , , ,
> >
> > ....more coming in the morning
> >
> >
> >
> >> Keith
> >>
> >> > -----Original Message-----
> >> > From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com]
> >> > Sent: Monday, April 16, 2007 6:13 PM
> >> > To: IETF SIP List
> >> > Subject: [Sip] Review of draft-ietf-sip-location-conveyance
> >> >
> >> > I have posted the comments from WGLC on=20
> >> > draft-ietf-sip-location-conveyance at:
> >> >
> >> >=20
> http://www.softarmor.com/sipwg/reviews/location-conveyance/index.ht
> >> > ml
> >> >
> >> > Please let me know if I have missed any comments.
> >> >
> >> > There will be a review conference call of these comments on:
> >> >
> >> > Wednesday 25th April at
> >> >
> >> >       1:00 pm - 3:00 pm Central US time
> >> >       2:00 pm - 4:00 pm Eastern US time
> >> >       7:00 pm - 9:00 pm UK time
> >> >       8:00 pm - 10:00 pm Central Europe time
> >> >
> >> > Bridge details:
> >> >
> >> > Chairperson Name:  KEITH DRAGE
> >> > Access Phone Number:  8007718734
> >> > International Access Phone Number:  +1 6477233953=20
> 7-Digit Access Code:
> >> > 5776249
> >> >
> >> > While this call is in no sense restricted, this call is=20
> for people=20
> >> > who have reviewed the document. If you think you=20
> qualify, and have=20
> >> > not sent comments that are included above, or indeed=20
> reviewed and=20
> >> > had no comments, then please send me a mail indicating this.
> >> >
> >> > Regards
> >> >
> >> > Keith
> >> >
> >> >
> >> > _______________________________________________
> >> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >> > This list is for NEW development of the core SIP Protocol Use=20
> >> > sip-implementors@cs.columbia.edu for questions on=20
> current sip Use=20
> >> > sipping@ietf.org for new developments on the application of sip
> >> >
> >>
> >>
> >> _______________________________________________
> >> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >> This list is for NEW development of the core SIP Protocol Use=20
> >> sip-implementors@cs.columbia.edu for questions on current sip Use=20
> >> sipping@ietf.org for new developments on the application of sip
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use=20
> > sip-implementors@cs.columbia.edu for questions on current sip Use=20
> > sipping@ietf.org for new developments on the application of sip
>=20
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 25 09:48:11 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hghqn-0004Oy-3Y; Wed, 25 Apr 2007 09:48:05 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hghql-0004Mo-HA
	for sip-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 09:48:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hghql-0004Ll-6g
	for sip@ietf.org; Wed, 25 Apr 2007 09:48:03 -0400
Received: from ihemail1.lucent.com ([135.245.0.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hghqj-0004Rl-K8
	for sip@ietf.org; Wed, 25 Apr 2007 09:48:03 -0400
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l3PDlrnt016926
	for <sip@ietf.org>; Wed, 25 Apr 2007 08:48:01 -0500 (CDT)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by
	ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 25 Apr 2007 08:47:54 -0500
Received: from DEEXC1U01.de.lucent.com ([135.248.187.26]) by
	DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 25 Apr 2007 15:47:49 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Review of draft-ietf-sip-location-conveyance
Date: Wed, 25 Apr 2007 15:47:48 +0200
Message-ID: <5D1A7985295922448D5550C94DE29180010848A9@DEEXC1U01.de.lucent.com>
In-Reply-To: <5D1A7985295922448D5550C94DE2918001084501@DEEXC1U01.de.lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Review of draft-ietf-sip-location-conveyance
Thread-Index: AceASoJbwqnLTcNHTPKhgPjOBOCQcQGTLFbgACoutBA=
References: <5D1A7985295922448D5550C94DE29180FFE84C@DEEXC1U01.de.lucent.com>
	<5D1A7985295922448D5550C94DE2918001084501@DEEXC1U01.de.lucent.com>
From: "Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>
To: "IETF SIP List" <sip@ietf.org>
X-OriginalArrivalTime: 25 Apr 2007 13:47:49.0423 (UTC)
	FILETIME=[500FFBF0:01C78740]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

The following is the details of the review call and agenda for the call.

Comments are welcomed by email before the start of the call.

Regards

Keith

I have posted the comments from WGLC on
draft-ietf-sip-location-conveyance at:

http://www.softarmor.com/sipwg/reviews/location-conveyance/index.html

Please let me know if I have missed any comments.=20

There will be a review conference call of these comments on:

Wednesday 25th April at

	1:00 pm - 3:00 pm Central US time
	2:00 pm - 4:00 pm Eastern US time
	7:00 pm - 9:00 pm UK time
	8:00 pm - 10:00 pm Central Europe time

Bridge details:

Chairperson Name:  KEITH DRAGE
Access Phone Number:  8007718734
International Access Phone Number:  +1 6477233953 7-Digit Access Code:
5776249=20

While this call is in no sense restricted, this call is for people who
have reviewed the document. If you think you qualify,  and have not sent
comments that are included above, or indeed reviewed and had no
comments, then please send me a mail  indicating this.

Agenda:

1)	Roll call

2)	Agenda bash - lets not spend too much time moving things around,
concentrate on what is missing, or what does not  need to be discussed.
Note that the comments listed below are only what are regarded as the
more major issues meriting collective discussion and review - I expect
the editors to use their initiative on many of the others.

3)	Methodology
	First discussion of key points.=20
	If new comments arise from discussion, please identify verbally
and ensure they are documented.
	Comments discussed can have resolution agreed in the call, or
defer, or take to list, or leave to authors to make a  judgement.

4)=09
Issues relating to multiple locations

	Comments: 2, 3, (66), 78, 94, 96, 153, 164

	Key questions:=20
	Do we want multiple locations?	If there are multiple locations,
which should be used?
	If a 424 is returned, which location does it relate to?

	Which location does the warning refer to?
	In what circumstances can multiple locations cause a call to
fail - or can one be used and ignore the rest?
	If you have a location by value, do you need to also resolve any
location by reference?
	Anything different for multiple locations in responses?

5)	Security issues

	Comments: 21, 27, 117A, 129C, 129D, 168, 181A, 181B, 137
	Key questions:
	Any issues with mandating multipart MIME?
	Signing versus encryption issues?
	Document security issues when retrieving location by reference?
	Are mechanisms different for LbyrR and LbyV?
	Is security considerations section adequate?
	Are self signed certificates out of scope?
	Is mandating a retry without TLS in scope?

6)	Emergency issues

	Comments: 129B, 167A, 169
	Key questions:
	Should we cover emergency at all in this document?

7)	Response usage

	Comments: 29, 150
	Key questions:
	Is it allowed in responses, and if so, what are the procedures
for error handling?
	What are the associated Require: and Supported: procedures?

8)	Error handling issues

	Comments: 30, 79, 84, 85, 110, 147
	Key questions:
	Dialog usage - does 424 clear the dialog or just the specific
usage?
	Can Warning only appear in 424?
	Do we need all the warnings given?
	Do we need 701?
	What mechanism should we use to indicate URL schemes?
	Do we always return an error, or can we just ignore a problem?=09

9)	Method usage

	Comments: 62, 69, 73, 74
	Key questions:
	INFO?
	Mid call location updates use what mechanism?
	REFER?
	PUBLISH?
	BYE?

10)	Body issues

	Comments: 159
	Key questions:
	What additional information is needed to describe bodies?

11)	PIDF-LO usage

	Comments: 121, 153A
	Key questions:
	Point usage deprecated?
	Proxy usage - what can proxy say about this location - is this
in scope of this document or does GEOPRIV need to  handle it?

12)	URI issues

	Comments: 7, 64
	Key questions:

13)	Routeing query allowed issues

	Comments: 11
	Key questions:

14)	Retransmission allowed issues

	Comments: 61A
	Key questions:
	Is mechanism needed?

15)	Terminology usage

	Comments: 1, 19, 43A, 101A, 116B, 129A
	Key questions
	Are "by value" and "by reference" the appropriate terms?
	Is LbyR a using protocol?
	Are there any circumstances where we need to talk about LIS
rather than LS?

16)	Pull mechanisms

	Comments: 25, 144A
	Key questions:
	Are the mentioned pull mechanism valid, given that we don't
cover them at all?



> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20
> Sent: Tuesday, April 24, 2007 6:39 PM
> To: IETF SIP List
> Subject: RE: [Sip] Review of draft-ietf-sip-location-conveyance
>=20
> A reminder of the call tomorrow, and also that I have posted=20
> an updated set of comments including some late comments received.=20
>=20
> The numbering remains consistent for the comments that were=20
> previously posted, and we will refer to comments by numbers=20
> on the call tomorrow.
>=20
> Keith
>=20
> > -----Original Message-----
> > From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com]
> > Sent: Monday, April 16, 2007 6:13 PM
> > To: IETF SIP List
> > Subject: [Sip] Review of draft-ietf-sip-location-conveyance
> >=20
> > I have posted the comments from WGLC on=20
> > draft-ietf-sip-location-conveyance at:
> >=20
> >=20
> http://www.softarmor.com/sipwg/reviews/location-conveyance/index.html
> >=20
> > Please let me know if I have missed any comments.=20
> >=20
> > There will be a review conference call of these comments on:
> >=20
> > Wednesday 25th April at
> >=20
> > 	1:00 pm - 3:00 pm Central US time
> > 	2:00 pm - 4:00 pm Eastern US time
> > 	7:00 pm - 9:00 pm UK time
> > 	8:00 pm - 10:00 pm Central Europe time
> >=20
> > Bridge details:
> >=20
> > Chairperson Name:  KEITH DRAGE
> > Access Phone Number:  8007718734
> > International Access Phone Number:  +1 6477233953 7-Digit=20
> Access Code:
> > 5776249
> >=20
> > While this call is in no sense restricted, this call is for=20
> people who=20
> > have reviewed the document. If you think you qualify, and have not=20
> > sent comments that are included above, or indeed reviewed=20
> and had no=20
> > comments, then please send me a mail indicating this.
> >=20
> > Regards
> >=20
> > Keith
> >=20
> >=20
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use=20
> > sip-implementors@cs.columbia.edu for questions on current sip Use=20
> > sipping@ietf.org for new developments on the application of sip
> >=20
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 25 10:10:15 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgiC9-0001AT-Mc; Wed, 25 Apr 2007 10:10:09 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HgiC7-0001AL-QA
	for sip-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 10:10:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HgiC7-0001AD-GS
	for sip@ietf.org; Wed, 25 Apr 2007 10:10:07 -0400
Received: from mail44.opentransfer.com ([76.162.254.44])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HgiC7-0001VS-1o
	for sip@ietf.org; Wed, 25 Apr 2007 10:10:07 -0400
Received: (qmail 10483 invoked by uid 399); 25 Apr 2007 14:10:05 -0000
Received: from unknown (HELO ?192.168.0.40?) (24.107.197.43)
	by mail44.opentransfer.com with SMTP; 25 Apr 2007 14:10:05 -0000
Message-ID: <462F613C.2050502@sipstation.com>
Date: Wed, 25 Apr 2007 09:10:04 -0500
From: Alan Johnston <alan@sipstation.com>
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
MIME-Version: 1.0
To: Francois Audet <audet@nortel.com>
Subject: Re: [Sip] draft-ietf-sip-sips-03.txt
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7
Cc: Cullen Jennings <fluffy@cisco.com>, "Peterson,
	Jon" <jon.peterson@neustar.biz>, sip@ietf.org,
	Dean Willis <dean.willis@softarmor.com>,
	Keith Drage <drage@alcatel-lucent.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I don't think we need an option tag for this - we are not fundamentally 
changing or extending RFC 3261.  The intent of 3261 was that a sips call 
have encrypted signaling end-to-end, we are just clarifying how this 
should be done.

Also, since there are no deployments of sips, there is no backwards 
compatibility issue.

Thanks,
Alan


Francois Audet wrote:
> (Copying Dean and Jon and Hisham, because they are the main people who
> expressed 
> an opinion on this).
>
> The issue is how do we handle backward-compatibility, i.e.,
> implementations that
> have implemented sips according to RFC 3261 but not to this draft.
>
> Because of the many issues highlighted in the draft, those
> implementations are
> likely to do proprietary "cheats" to handle SIPS, and they are also
> likely to 
> have things that are not really legal. Presumably, the option-tag would
> allow UAs and Proxies to know if an implementation is "clean" or not.
> You could then
> provide alternative treatment for the "un-clean" implementation (i.e.,
> don't allow
> registration, protocol fix-up, manufacturer-specific stuff, record an
> aler, etc.). 
> There are certainly other ways of doing this, and this is largely
> theoretical 
> anyways because it's not like there is a large numbers of
> implementations out there.
>
> The second issue (perhaps more importantly) is the actual changes that
> we 
> are making to RFC 3261. Specifically, the various deprecation of last
> hop ugrades/
> downgrades.
>
> The option-tag (with Proxy-required) allows for the sender of the
> request to
> enforce the deprecation of the last hop exception, i.e., the session
> will fail
> with 420 if a proxy doesn't understand that it is supposed to support
> sips
> properly as per the new draft. 
>
> I was thinking about the originator of the request as the entity that
> would want
> to enforce no-last-hop-exception, but Cullent points out that maybe it's
> also
> something that's up to the owner of the SIPS URI to decide, in which
> case the
> option-tag is not useful (of course if you are that worried about it,
> you
> could do "sips:user@example.net?Proxy-Required:sips".
>
> So....
>
> I actually don't really care either way. Really. I'm fine either way.
>
> Maybe we should do a virtual "hum".
>
> 1a - For the option-tag (but I could go either way)
> 1b - For the option-tag (and I really insist on it)
> 2a - Against the option-tag (but I could go either way)
> 2b - Against the option-tag (and I really insist on it)
> 3 - I really don't care
>
>
>   
>> -----Original Message-----
>> From: Cullen Jennings [mailto:fluffy@cisco.com] 
>> Sent: Sunday, April 22, 2007 20:21
>> To: Audet, Francois (SC100:3055)
>> Cc: sip@ietf.org
>> Subject: Re: [Sip] draft-ietf-sip-sips-03.txt
>>
>>
>> On Apr 16, 2007, at 3:26 PM, Francois Audet wrote:
>>
>>     
>>>   2.  Do we need the sips option tag? The current document assumes 
>>> that
>>>        we do use the option tag, and that is the preference of the 
>>> author.
>>>        (There is at least one dissenting voice on that one: Hisham).
>>>       
>> I'm confused on why we would need it and would want to 
>> understand why it is needed before commenting on this. I 
>> don't buy the needing it to enforce deprecate of last hop 
>> rule - I see problem in that it leads to two bits that mean 
>> the same thing and we have to deal with all the corner cases 
>> of when they conflict. It also makes me wonder if there are 
>> problems when a URI is copied from one situation to another 
>> and the REquires: sips header is not.
>>
>> Cullen <with my individual hat on>
>>
>>
>>     
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>
>
>   



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 25 13:59:55 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HglmQ-00040g-4W; Wed, 25 Apr 2007 13:59:50 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HglmO-0003tB-H9
	for sip-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 13:59:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HglmO-0003sI-70
	for sip@ietf.org; Wed, 25 Apr 2007 13:59:48 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HglmK-00075y-Rj
	for sip@ietf.org; Wed, 25 Apr 2007 13:59:47 -0400
Received: from [10.89.20.60] (rcdn4-dmznat-gw1-nat-27.cisco.com [12.5.186.27])
	(authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3PH6T11015471
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 25 Apr 2007 12:06:29 -0500
Message-ID: <462F96F9.206@softarmor.com>
Date: Wed, 25 Apr 2007 12:59:21 -0500
From: Dean Willis <dean.willis@softarmor.com>
User-Agent: Thunderbird 1.5.0.10 (X11/20070403)
MIME-Version: 1.0
To: Alan Johnston <alan@sipstation.com>
Subject: Interaction of SIPS with old implementations that weren't really
	using SIPS (was Re: [Sip] draft-ietf-sip-sips-03.txt)
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
In-Reply-To: <462F613C.2050502@sipstation.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: Cullen Jennings <fluffy@cisco.com>, sip@ietf.org,
	Francois Audet <audet@nortel.com>,
	Keith Drage <drage@alcatel-lucent.com>, "Peterson,
	Jon" <jon.peterson@neustar.biz>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Alan Johnston wrote:
>  Also, since there are no deployments of sips, there is no backwards
>  compatibility issue.

Ok, here's a silly question for you.

Given, there are no big deployments of SIPS that we've heard of.

However, many of the implementations we've been made aware of
support SIPS, or can at least be configured to react differently to
SIPS requests (whether that implies supporting SIPS is debatable).

If we have a deployment of the "new and improved" SIPS, the traffic
it produces is likely to hit some of those old implementations that
we don't currently consider "deployed" for SIPS.

What happens? Do things break? Or are we confident that those
older implementations of SIPS are all configured "off"?

--
Dean




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 25 14:00:46 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HglnI-00054c-7P; Wed, 25 Apr 2007 14:00:44 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HglnG-00054W-Ig
	for sip-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 14:00:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HglnG-00054O-8u
	for sip@ietf.org; Wed, 25 Apr 2007 14:00:42 -0400
Received: from host10.216.41.24.conversent.net ([216.41.24.10]
	helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HglnE-0007G9-RK for sip@ietf.org; Wed, 25 Apr 2007 14:00:42 -0400
Received: from hkaplan [10.0.200.241] by acmepacket.com with ESMTP
	(SMTPD-9.10) id A73E0824; Wed, 25 Apr 2007 14:00:30 -0400
From: "Hadriel Kaplan" <HKaplan@acmepacket.com>
To: "'Dean Willis'" <dean.willis@softarmor.com>,
	"'Frank W. Miller'" <fwmiller@cornfed.com>
References: <20070418183921.E4B2A1058039@spi01.csee.onr.siteprotect.com>
	<77CDA802-2142-4D1A-993A-CC189538858C@softarmor.com>
Subject: RE: [Sip] sip tcp connection
Date: Wed, 25 Apr 2007 14:00:27 -0400
Message-ID: <00af01c78763$9dc98410$800101df@acmepacket.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AceCCr51vNdsW/e9Qnm0k17tpVj6ZQFPwKLw
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
In-Reply-To: <77CDA802-2142-4D1A-993A-CC189538858C@softarmor.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
Cc: sip@ietf.org, 'jiang mingda' <jiangmd@msn.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I was also surprised and confused as to why TCP-reuse had been pulled out of
connect-reuse.

I am not clear why any argument which includes "a middle-man can hijack it"
should mean a mechanism cannot be allowed in a draft. (unless the
mechanism's purpose is to be a security mechanism, which this one isn't)

UDP already has the noted weaknesses, only worse. 

If you're not using an authenticated transport, then you're not using an
authenticated transport.  If the threat of hijacking makes an application
mechanism unacceptable for a given transport then there are a lot of sip
drafts/RFCs that need to be changed to only allow DTLS/TLS, starting with
3261.  

I would also argue that hijacking (whether from a middle-man or on the same
host) is more likely between a UA and its proxy, and since Outbound
implicitly supports a connect-reuse model for TCP without requiring TLS,
then the ship has already sailed on that. (though you could argue the
instance-id and reg-id provide some more auth info, but its still cleartext)

So all we're talking about is proxy-to-proxy or proxy-to-registrar, etc.
Without connect-reuse, you need to send requests out a TCP connection you
created to the far end.  But how do you know it's the far-end you think it
is?  You don't.  Without TLS or something similar you can't.  Even if you
use digest auth, it only verifies to the far end who you are, not the other
way around (and I don't know of proxies that do digest for themselves to
other proxies, nor how they could).  So the draft (and sip in principle) is
already susceptible to TCP hijacking in many forms.

The only interesting scenario I can see in this regard is when a proxy has a
legitimate active socket listener on 5060, for its legitimate proxy process.
Then a rogue application on the same proxy creates a new tcp connection to
the far-end using an ephemeral local port, and sends some SIP request to the
far-end with an alias in the via claiming it represents the local proxy.
While that's an interesting case, it hardly scratches the surface of issues
that could occur with a rogue application on a proxy host.

For this issue to make TCP-connect-reuse be dropped from the draft really
seems silly.  The security concerns should just be listed, as they are for
all mechanisms, left up to local policy to decide whether to accept or not,
and leave it at that.

-hadriel
p.s. not that I'm a big proponent of TCP connect-reuse in general mind you,
but we have providers who demand it, and right now we have to let the
operator configure it manually without any way to verify the far-end can
really do it.  It would be nice if the signaling could reinforce it.


> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: Wednesday, April 18, 2007 6:41 PM
> To: Frank W. Miller
> Cc: sip@ietf.org; 'jiang mingda'
> Subject: Re: [Sip] sip tcp connection
> 
> 
> On Apr 18, 2007, at 1:40 PM, Frank W. Miller wrote:
> 
> >
> >
> > I've heard reference to this security issue in the past but have
> > just gone
> > and read it for the first time, Section 9.3 right?  I'm not sure I
> > completely understand it.  Are you saying that another program can
> > hijack
> > the connection once the legitimate SIP user is not present on the
> > connection
> > anymore?  Would not the legitimate user have torn down the TCP
> > connection
> > when it exited?  Wouldn't the TCP connection require authentication
> > when it
> > was reestablished?  My apologies for my lack of understanding.
> >
> 
> There's a couple of ways of looking at it. The one that concerns me
> most is what might be called "TCP Hijacking".
> 
> http://www.iss.net/security_center/advice/Exploits/TCP/
> session_hijacking/default.htm
> 
> The idea is that if you authenticate (say, via digest) at the start
> of a TCP session, then anybody "on the wire" can easily take over the
> session and continue to use it without having to re-authenticate.
> 
> TLS pretty much prevents this attack.
> 
> Just for fun, I seem to recall back in the days of coaxial ethernet
> once seeing an app that would hijack an NFS session to start
> returning bogus data to the client. It was great fun to divert
> somebody to what appeared to be an empty NFS filesystem where they
> expected to find their dissertation research.
> 
> --
> Dean
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 25 14:58:32 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hgmh9-0007L7-Q7; Wed, 25 Apr 2007 14:58:27 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hgmh8-0007Cs-20
	for sip-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 14:58:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgmh7-0007CT-Of
	for sip@ietf.org; Wed, 25 Apr 2007 14:58:25 -0400
Received: from zrtps0kp.nortel.com ([47.140.192.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgmh6-0001Gs-GN
	for sip@ietf.org; Wed, 25 Apr 2007 14:58:25 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3PIwKJ11707; Wed, 25 Apr 2007 18:58:20 GMT
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: Interaction of SIPS with old implementations that weren't really
	using SIPS (was Re: [Sip] draft-ietf-sip-sips-03.txt)
Date: Wed, 25 Apr 2007 13:58:17 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF102DA701@zrc2hxm0.corp.nortel.com>
In-Reply-To: <462F96F9.206@softarmor.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Interaction of SIPS with old implementations that weren't really
	using SIPS (was Re: [Sip] draft-ietf-sip-sips-03.txt)
Thread-Index: AceHY4YNaG7bnLNLS0O87EeMYYv3UgAAFfxw
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com> <462F96F9.206@softarmor.com>
From: "Francois Audet" <audet@nortel.com>
To: "Dean Willis" <dean.willis@softarmor.com>,
	"Alan Johnston" <alan@sipstation.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Cc: Cullen Jennings <fluffy@cisco.com>, sip@ietf.org,
	Keith Drage <drage@alcatel-lucent.com>, "Peterson,
	Jon" <jon.peterson@neustar.biz>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

It's a good question.

You are asking what happens if SIPS is used but somehow terminate on an
interface that
does not support SIPS.

In the best case, it will reject it properly because it will inspects
the scheme,
does't recognize it, and sends 416. That's ok.

Another case is where the last proxy used the last hop exception because
it
was not compliant to this RFC. That's the case where we say that there
is not
much real existing deployment of this. Presumably, that proxy is mucking
around
to make it work (changing contacts or whatever), as we discussed
earlier. This=20
may be a theoretical problem more than a real one. I think we all agree
on that.

The case I think you are asking about is if the request goes to the UAS
but the
UAS somehow doesn't parse properly the scheme and accepts it. I think
this is fairly
likely actually.=20

The question is do we need to solve this problem by adding an
option-tag? This is=20
a problem of buggy implementation of RFC 3261. Or are we happy with the
originator=20
of the request figuring it out and tearing down the session?

I'm now tempted to change opinion again and argue that it is not worth
it to try
to solve buggy RFC 3261 implementations with an option-tag (maybe
they'll be buggy
on the option-tag too). The UAC should be able to detect that (looking
at=20
Contact and From for example) and clear the session.





> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]=20
> Sent: Wednesday, April 25, 2007 10:59
> To: Alan Johnston
> Cc: Audet, Francois (SC100:3055); Cullen Jennings; Peterson,=20
> Jon; sip@ietf.org; Keith Drage
> Subject: Interaction of SIPS with old implementations that=20
> weren't really using SIPS (was Re: [Sip] draft-ietf-sip-sips-03.txt)
>=20
> Alan Johnston wrote:
> >  Also, since there are no deployments of sips, there is no=20
> backwards =20
> > compatibility issue.
>=20
> Ok, here's a silly question for you.
>=20
> Given, there are no big deployments of SIPS that we've heard of.
>=20
> However, many of the implementations we've been made aware of=20
> support SIPS, or can at least be configured to react=20
> differently to SIPS requests (whether that implies supporting=20
> SIPS is debatable).
>=20
> If we have a deployment of the "new and improved" SIPS, the=20
> traffic it produces is likely to hit some of those old=20
> implementations that we don't currently consider "deployed" for SIPS.
>=20
> What happens? Do things break? Or are we confident that those=20
> older implementations of SIPS are all configured "off"?
>=20
> --
> Dean
>=20
>=20
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 25 15:44:46 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgnPQ-0002i9-2Z; Wed, 25 Apr 2007 15:44:12 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HgnPO-0002i4-AT
	for sip-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 15:44:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HgnPO-0002hw-10
	for sip@ietf.org; Wed, 25 Apr 2007 15:44:10 -0400
Received: from zrtps0kn.nortel.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgnPM-00013u-Qa
	for sip@ietf.org; Wed, 25 Apr 2007 15:44:10 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3PJhu414134; Wed, 25 Apr 2007 19:43:56 GMT
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: Interaction of SIPS with old implementations that weren't
	really	using SIPS (was Re: [Sip] draft-ietf-sip-sips-03.txt)
Date: Wed, 25 Apr 2007 14:43:56 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E61277BEE3@zrc2hxm2.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF102DA701@zrc2hxm0.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Interaction of SIPS with old implementations that weren't
	really	using SIPS (was Re: [Sip] draft-ietf-sip-sips-03.txt)
thread-index: AceHY4YNaG7bnLNLS0O87EeMYYv3UgAAFfxwAANrftA=
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Francois Audet" <audet@nortel.com>,
	"Dean Willis" <dean.willis@softarmor.com>,
	"Alan Johnston" <alan@sipstation.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: Cullen Jennings <fluffy@cisco.com>, sip@ietf.org,
	Keith Drage <drage@alcatel-lucent.com>, "Peterson,
	Jon" <jon.peterson@neustar.biz>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

=20

>
>I'm now tempted to change opinion again and argue that it is=20
>not worth it to try to solve buggy RFC 3261 implementations=20
>with an option-tag (maybe they'll be buggy on the option-tag=20
>too). The UAC should be able to detect that (looking at=20
>Contact and From for example) and clear the session.

That's right path of thinking. Could you please clarify how Contact and
>From can fix that. Also as far as I understand option tags are for
extending the new functionality. And not for fixing the broken
protocols. Purists ?
=20

Thx
Samir


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 25 15:59:58 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hgnec-0005U4-EM; Wed, 25 Apr 2007 15:59:54 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hgneb-0005Tu-34
	for sip-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 15:59:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgnea-0005Tm-OZ
	for sip@ietf.org; Wed, 25 Apr 2007 15:59:52 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgnea-0004ZH-9E
	for sip@ietf.org; Wed, 25 Apr 2007 15:59:52 -0400
Received: from sj-dkim-8.cisco.com ([171.68.10.93])
	by sj-iport-5.cisco.com with ESMTP; 25 Apr 2007 12:59:52 -0700
X-IronPort-AV: i="4.14,451,1170662400"; 
	d="scan'208"; a="415593184:sNHT59938296"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
	by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l3PJxpZc010741; 
	Wed, 25 Apr 2007 12:59:51 -0700
Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l3PJxowo003539;
	Wed, 25 Apr 2007 19:59:50 GMT
In-Reply-To: <462F613C.2050502@sipstation.com>
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <43E39632-46AE-456A-8BA8-1A1E93FB6272@cisco.com>
Content-Transfer-Encoding: 7bit
From: Cullen Jennings <fluffy@cisco.com>
Subject: Re: [Sip] draft-ietf-sip-sips-03.txt
Date: Wed, 25 Apr 2007 12:59:17 -0700
To: Alan Johnston <alan@sipstation.com>
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4725; t=1177531191;
	x=1178395191; c=relaxed/simple; s=sjdkim8002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=fluffy@cisco.com;
	z=From:=20Cullen=20Jennings=20<fluffy@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20draft-ietf-sip-sips-03.txt
	|Sender:=20; bh=UOpk0c4lePbwfPBK9yX7eq4WZcRrHxIcxiMzuWy0V6A=;
	b=okT4ufPGqyZi4Lpa0NObRxJfA4SJxDvCUrFyGLiyf7tPbgn5+lKCGavwK0guXkdQY+PG7dnm
	6UMnio+wtjO2/IJMgsUdfx4CH3a8drXv1rtDX+f25gG5GO14rzWjnuz1;
Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim8002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>,
	Keith Drage <drage@alcatel-lucent.com>, "Peterson,
	Jon" <jon.peterson@neustar.biz>, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


Agree with Alan .... If this document was extending SIP then I would  
understand the need for an option tag but the draft would not need to  
update 3261.

On Apr 25, 2007, at 7:10 AM, Alan Johnston wrote:

> I don't think we need an option tag for this - we are not  
> fundamentally changing or extending RFC 3261.  The intent of 3261  
> was that a sips call have encrypted signaling end-to-end, we are  
> just clarifying how this should be done.
>
> Also, since there are no deployments of sips, there is no backwards  
> compatibility issue.
>
> Thanks,
> Alan
>
>
> Francois Audet wrote:
>> (Copying Dean and Jon and Hisham, because they are the main people  
>> who
>> expressed an opinion on this).
>>
>> The issue is how do we handle backward-compatibility, i.e.,
>> implementations that
>> have implemented sips according to RFC 3261 but not to this draft.
>>
>> Because of the many issues highlighted in the draft, those
>> implementations are
>> likely to do proprietary "cheats" to handle SIPS, and they are also
>> likely to have things that are not really legal. Presumably, the  
>> option-tag would
>> allow UAs and Proxies to know if an implementation is "clean" or not.
>> You could then
>> provide alternative treatment for the "un-clean" implementation  
>> (i.e.,
>> don't allow
>> registration, protocol fix-up, manufacturer-specific stuff, record an
>> aler, etc.). There are certainly other ways of doing this, and  
>> this is largely
>> theoretical anyways because it's not like there is a large numbers of
>> implementations out there.
>>
>> The second issue (perhaps more importantly) is the actual changes  
>> that
>> we are making to RFC 3261. Specifically, the various deprecation  
>> of last
>> hop ugrades/
>> downgrades.
>>
>> The option-tag (with Proxy-required) allows for the sender of the
>> request to
>> enforce the deprecation of the last hop exception, i.e., the session
>> will fail
>> with 420 if a proxy doesn't understand that it is supposed to support
>> sips
>> properly as per the new draft.
>> I was thinking about the originator of the request as the entity that
>> would want
>> to enforce no-last-hop-exception, but Cullent points out that  
>> maybe it's
>> also
>> something that's up to the owner of the SIPS URI to decide, in which
>> case the
>> option-tag is not useful (of course if you are that worried about it,
>> you
>> could do "sips:user@example.net?Proxy-Required:sips".
>>
>> So....
>>
>> I actually don't really care either way. Really. I'm fine either way.
>>
>> Maybe we should do a virtual "hum".
>>
>> 1a - For the option-tag (but I could go either way)
>> 1b - For the option-tag (and I really insist on it)
>> 2a - Against the option-tag (but I could go either way)
>> 2b - Against the option-tag (and I really insist on it)
>> 3 - I really don't care
>>
>>
>>
>>> -----Original Message-----
>>> From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Sunday,  
>>> April 22, 2007 20:21
>>> To: Audet, Francois (SC100:3055)
>>> Cc: sip@ietf.org
>>> Subject: Re: [Sip] draft-ietf-sip-sips-03.txt
>>>
>>>
>>> On Apr 16, 2007, at 3:26 PM, Francois Audet wrote:
>>>
>>>
>>>>   2.  Do we need the sips option tag? The current document  
>>>> assumes that
>>>>        we do use the option tag, and that is the preference of  
>>>> the author.
>>>>        (There is at least one dissenting voice on that one:  
>>>> Hisham).
>>>>
>>> I'm confused on why we would need it and would want to understand  
>>> why it is needed before commenting on this. I don't buy the  
>>> needing it to enforce deprecate of last hop rule - I see problem  
>>> in that it leads to two bits that mean the same thing and we have  
>>> to deal with all the corner cases of when they conflict. It also  
>>> makes me wonder if there are problems when a URI is copied from  
>>> one situation to another and the REquires: sips header is not.
>>>
>>> Cullen <with my individual hat on>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use sip-implementors@cs.columbia.edu for questions on current sip
>> Use sipping@ietf.org for new developments on the application of sip
>>
>>
>>
>
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 25 17:15:31 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hgopj-0008PF-3p; Wed, 25 Apr 2007 17:15:27 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hgoph-0008PA-VH
	for sip-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 17:15:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgoph-0008P2-LN
	for sip@ietf.org; Wed, 25 Apr 2007 17:15:25 -0400
Received: from brinza.cc.columbia.edu ([128.59.29.8])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgopf-0008C3-EI
	for sip@ietf.org; Wed, 25 Apr 2007 17:15:25 -0400
Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102])
	(user=hgs10 mech=PLAIN bits=0)
	by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3PLFM1a016018
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT)
	for <sip@ietf.org>; Wed, 25 Apr 2007 17:15:23 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: <06DBA97B-FF03-4E16-8215-1A47DC9C8565@cs.columbia.edu>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: IETF SIP List <sip@ietf.org>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Date: Wed, 25 Apr 2007 17:16:50 -0400
X-Mailer: Apple Mail (2.752.3)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Subject: [Sip] SIP location conveyance: error indication
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

During the call today, we discussed error handling in SIP location  
conveyance and identified two problems:

(1) With multiple locations, it is impossible to tell which error  
(warning) refers to which location. Since location elements may be  
inserted by proxies and are then invisible to the UAC, the UAC could  
get an error indication which makes no sense since it refers to  
another location.

(2) The current return-424 model is inappropriate if location-related  
failures should not cause the call to fail, as will often be the  
case. (Just because Domino's can't dereference my location URL, it  
still wants to talk to me about ordering pizza, but I also want to  
fix that URL.)

Thus, my proposal:

(1) Define a new Location-Error request (?) and response header, as in

Geolocation-Error: "Cannot  
dereference" ;tag="xkauc" ;code=711 ;source="alice.example.com"

where tag is a new tag added to a location header. This error can  
occur in a 424 or any other status code, including a 200. If included  
in the request, it's used by the UAS in case location handling is  
delegated to some other proxy. (I'm not sure whether the request  
header thing is a good idea.)

(2) Define a new Accept-* header, as in

Accept-Geolocation: sip, http

which identifies the dereferencing protocols supported, to avoid the  
current ugly overloading of the warning messages.

Henning


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 25 17:28:09 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hgp1z-0002Eo-UB; Wed, 25 Apr 2007 17:28:07 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hgp1z-0002Ej-Ao
	for sip-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 17:28:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgp1z-0002Eb-11
	for sip@ietf.org; Wed, 25 Apr 2007 17:28:07 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgp1x-00023L-PE
	for sip@ietf.org; Wed, 25 Apr 2007 17:28:07 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3PLS2S15071 for <sip@ietf.org>; Wed, 25 Apr 2007 21:28:03 GMT
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: Interaction of SIPS with old implementations that weren't
	really	using SIPS (was Re: [Sip] draft-ietf-sip-sips-03.txt)
Date: Wed, 25 Apr 2007 16:27:55 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF10329BE4@zrc2hxm0.corp.nortel.com>
In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E61277BEE3@zrc2hxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Interaction of SIPS with old implementations that weren't
	really	using SIPS (was Re: [Sip] draft-ietf-sip-sips-03.txt)
Thread-Index: AceHY4YNaG7bnLNLS0O87EeMYYv3UgAAFfxwAANrftAAAxhogA==
References: <1ECE0EB50388174790F9694F77522CCF102DA701@zrc2hxm0.corp.nortel.com>
	<62B9B0847CC47543B6B3B5E26BD268E61277BEE3@zrc2hxm2.corp.nortel.com>
From: "Francois Audet" <audet@nortel.com>
To: "Samir Srivastava" <samirsr@nortel.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

On your first question: If I send you a request using a SIPS URI, and
you=20
accept it even if you don't support SIPS (because you are a buggy
implemenation),
you will nevertheless put SIP in the various URIs in your response,
e.g., in the
Contact header. You may even muck-up the From or To. If you send me
mid-call=20
requests later, you will most probably use SIP URIs in From. If I detect
something=20
like that, I can probably figure out something is wrong. Some of this is
already=20
covered in the draft and in RFC 3261.=20

On your second question. It's not the protocol that is broken but the=20
implementation.  =20

> -----Original Message-----
> From: Srivastava, Samir (SC100:8826)=20
> Sent: Wednesday, April 25, 2007 12:44
> To: Audet, Francois (SC100:3055); Dean Willis; Alan Johnston
> Cc: Cullen Jennings; sip@ietf.org; Keith Drage; Peterson, Jon
> Subject: RE: Interaction of SIPS with old implementations=20
> that weren't really using SIPS (was Re: [Sip]=20
> draft-ietf-sip-sips-03.txt)
>=20
> =20
>=20
> >
> >I'm now tempted to change opinion again and argue that it is=20
> not worth=20
> >it to try to solve buggy RFC 3261 implementations with an option-tag=20
> >(maybe they'll be buggy on the option-tag too). The UAC=20
> should be able=20
> >to detect that (looking at Contact and From for example) and=20
> clear the=20
> >session.
>=20
> That's right path of thinking. Could you please clarify how=20
> Contact and From can fix that. Also as far as I understand=20
> option tags are for extending the new functionality. And not=20
> for fixing the broken protocols. Purists ?
> =20
>=20
> Thx
> Samir
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 25 17:49:35 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgpMh-0004T1-Fj; Wed, 25 Apr 2007 17:49:31 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HgpMf-0004Ss-ML
	for sip-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 17:49:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HgpMf-0004Sk-Cd
	for sip@ietf.org; Wed, 25 Apr 2007 17:49:29 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgpMe-0007qx-3H
	for sip@ietf.org; Wed, 25 Apr 2007 17:49:29 -0400
Received: from [192.168.2.103] (rcdn4-dmznat-gw1-nat-27.cisco.com
	[12.5.186.27]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3PKuFUJ016713
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 25 Apr 2007 15:56:16 -0500
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF102DA701@zrc2hxm0.corp.nortel.com>
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com> <462F96F9.206@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF102DA701@zrc2hxm0.corp.nortel.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <6FC343AB-DFD9-47BE-A1C5-0D6006539551@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: Interaction of SIPS with old implementations that weren't really
	using SIPS (was Re: [Sip] draft-ietf-sip-sips-03.txt)
Date: Wed, 25 Apr 2007 16:49:10 -0500
To: Francois Audet <audet@nortel.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: Cullen Jennings <fluffy@cisco.com>, sip@ietf.org,
	Keith Drage <drage@alcatel-lucent.com>,
	Alan Johnston <alan@sipstation.com>, "Peterson,
	Jon" <jon.peterson@neustar.biz>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 25, 2007, at 1:58 PM, Francois Audet wrote:

> It's a good question.
>
> You are asking what happens if SIPS is used but somehow terminate  
> on an
> interface that
> does not support SIPS.
>

Actually, I'm asking what happens when such a request lands on  
something that THINKS it supports SIPS:, but doesn't really because  
what it supports is some part (and unlikely to be correct) of what  
SIPS was before we fixed it.

--
Dean



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 25 17:51:19 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgpOQ-0006R0-QA; Wed, 25 Apr 2007 17:51:18 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HgpOP-0006Qv-3k
	for sip-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 17:51:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HgpOO-0006Qn-QA
	for sip@ietf.org; Wed, 25 Apr 2007 17:51:16 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgpOO-00083h-FV
	for sip@ietf.org; Wed, 25 Apr 2007 17:51:16 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-2.cisco.com with ESMTP; 25 Apr 2007 17:51:16 -0400
X-IronPort-AV: i="4.14,451,1170651600"; 
	d="scan'208"; a="119508203:sNHT51526744"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3PLpGpT020912; 
	Wed, 25 Apr 2007 17:51:16 -0400
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 l3PLpGlG008997; 
	Wed, 25 Apr 2007 21:51:16 GMT
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.1830); 
	Wed, 25 Apr 2007 17:51:15 -0400
Received: from jmpolk-wxp.cisco.com ([10.89.20.138]) by
	xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 25 Apr 2007 17:51:15 -0400
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 25 Apr 2007 16:51:12 -0500
To: Henning Schulzrinne <hgs@cs.columbia.edu>, IETF SIP List <sip@ietf.org>
From: "James M. Polk" <jmpolk@cisco.com>
Subject: Re: [Sip] SIP location conveyance: error indication
In-Reply-To: <06DBA97B-FF03-4E16-8215-1A47DC9C8565@cs.columbia.edu>
References: <06DBA97B-FF03-4E16-8215-1A47DC9C8565@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <XFE-RTP-201b1s7nlT200004620@xfe-rtp-201.amer.cisco.com>
X-OriginalArrivalTime: 25 Apr 2007 21:51:15.0597 (UTC)
	FILETIME=[D916E3D0:01C78783]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3264; t=1177537876;
	x=1178401876; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jmpolk@cisco.com;
	z=From:=20=22James=20M.=20Polk=22=20<jmpolk@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20SIP=20location=20conveyance=3A=20error=20indi
	cation |Sender:=20
	|To:=20Henning=20Schulzrinne=20<hgs@cs.columbia.edu>,
	=20IETF=20SIP=20List =20<sip@ietf.org>;
	bh=BlBCrpWh3hweTrm5y0tDPR9lBjyWIizinyayU4DU99Y=;
	b=qB43tJG92hRpF/FygQxQqyt+2u0rGpLJsfvWVlww4TZUbe2Awc+6LfpUjXzH1hT4C2qM/6hf
	7yL9mzQngnix1n0QfnlHlvaBRIjS8R7Iuuj4RcEF98oBA6wN+eniTAiD;
Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Henning

Initial thoughts in-line

At 04:16 PM 4/25/2007, Henning Schulzrinne wrote:
>During the call today, we discussed error handling in SIP location
>conveyance and identified two problems:
>
>(1) With multiple locations, it is impossible to tell which error
>(warning) refers to which location. Since location elements may be
>inserted by proxies and are then invisible to the UAC, the UAC could
>get an error indication which makes no sense since it refers to
>another location.
>
>(2) The current return-424 model is inappropriate if location-related
>failures should not cause the call to fail, as will often be the
>case. (Just because Domino's can't dereference my location URL, it
>still wants to talk to me about ordering pizza, but I also want to
>fix that URL.)
>
>Thus, my proposal:
>
>(1) Define a new Location-Error request (?) and response header, as in
>
>Geolocation-Error: "Cannot
>dereference" ;tag="xkauc" ;code=711 ;source="alice.example.com"

this is interesting, but we have to account for errors that identify 
*what* was wrong in an LO (value or reference, assuming the 
dereference worked), and that requires more header parameters - thus 
making this header larger than this example.  Do you think we can 
merely list the CAtypes that were supplied that were good, and list 
those that are still necessary by the Location Recipient? Or just the 
ones still needed, with text stating to include all that was in the 
original LO *and* "these" new ones?

Another thought, I think this Geolocation-Error shouldn't be in 
requests (as I don't see a use case for it yet).

However, I do see the need, if this new header progresses through WG 
consensus as necessary, to extend the Geolocation header that's 
currently in Conveyance to include this location "tag" header 
parameter.  I think they need to match up so the UAC understands 
which location, if more than one is in a request (but not more than 
one inserted by the UAC), the error is referring to.


>where tag is a new tag added to a location header. This error can
>occur in a 424 or any other status code, including a 200. If included
>in the request, it's used by the UAS in case location handling is
>delegated to some other proxy. (I'm not sure whether the request
>header thing is a good idea.)
>
>(2) Define a new Accept-* header, as in
>
>Accept-Geolocation: sip, http
>
>which identifies the dereferencing protocols supported, to avoid the
>current ugly overloading of the warning messages.

As much as I think this is an easy way of doing this, no vendor that 
I know of that's doing the Resource-Priority header  from RFC 4412, 
for example, is coding the Accept-Resource-Priority header - also 
defined in 4412.

Is this a case where this one Accept-* is not being done? Or a case 
in which most/any Accept-* aren't being done - so why do we keep 
creating new ones?


>Henning
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 25 18:03:08 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgpZp-000869-CX; Wed, 25 Apr 2007 18:03:05 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HgpZn-00081D-PU
	for sip-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 18:03:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HgpZn-0007zS-F5
	for sip@ietf.org; Wed, 25 Apr 2007 18:03:03 -0400
Received: from brinza.cc.columbia.edu ([128.59.29.8])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgpZl-0002HP-7H
	for sip@ietf.org; Wed, 25 Apr 2007 18:03:03 -0400
Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102])
	(user=hgs10 mech=PLAIN bits=0)
	by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3PM2sFQ025016
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Wed, 25 Apr 2007 18:02:58 -0400 (EDT)
In-Reply-To: <XFE-RTP-201b1s7nlT200004620@xfe-rtp-201.amer.cisco.com>
References: <06DBA97B-FF03-4E16-8215-1A47DC9C8565@cs.columbia.edu>
	<XFE-RTP-201b1s7nlT200004620@xfe-rtp-201.amer.cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <412830A5-ECF5-4DD7-BE23-9DF243EFFDF1@cs.columbia.edu>
Content-Transfer-Encoding: 7bit
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: [Sip] SIP location conveyance: error indication
Date: Wed, 25 Apr 2007 18:04:21 -0400
To: "James M. Polk" <jmpolk@cisco.com>
X-Mailer: Apple Mail (2.752.3)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 25, 2007, at 5:51 PM, James M. Polk wrote:

> this is interesting, but we have to account for errors that  
> identify *what* was wrong in an LO (value or reference, assuming  
> the dereference worked), and that requires more header parameters -  
> thus making this header larger than this example.  Do you think we  
> can merely list the CAtypes that were supplied that were good, and  
> list those that are still necessary by the Location Recipient? Or  
> just the ones still needed, with text stating to include all that  
> was in the original LO *and* "these" new ones?

I don't understand this comment. The information is pretty much  
exactly what's in the current warning header.


>
> Another thought, I think this Geolocation-Error shouldn't be in  
> requests (as I don't see a use case for it yet).

The case, somewhat contrived, is that an ESRP can't route on the  
location (say, the dereferencing failed), but routes the call to a  
default PSAP, ignoring the location. It would be nice if the ESRP  
could indicate this failure to the PSAP.


>
> However, I do see the need, if this new header progresses through  
> WG consensus as necessary, to extend the Geolocation header that's  
> currently in Conveyance to include this location "tag" header  
> parameter.  I think they need to match up so the UAC understands  
> which location, if more than one is in a request (but not more than  
> one inserted by the UAC), the error is referring to.

Right.



>
> As much as I think this is an easy way of doing this, no vendor  
> that I know of that's doing the Resource-Priority header  from RFC  
> 4412, for example, is coding the Accept-Resource-Priority header -  
> also defined in 4412.
>

My guess is that 4412 is used within single domains, so there's  
little doubt as to what namespaces are being supported.

> Is this a case where this one Accept-* is not being done? Or a case  
> in which most/any Accept-* aren't being done - so why do we keep  
> creating new ones?
>

They seem to be commonly used for other SIP-related things. At least  
they show up on IMS call flows... Certainly beats creating a new  
error code for each new URL scheme that comes along (which doesn't  
convey the same information).

Henning


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 25 18:09:05 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgpfW-0004m6-MI; Wed, 25 Apr 2007 18:08:58 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HgpfU-0004lv-To
	for sip-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 18:08:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HgpfU-0004ln-KH
	for sip@ietf.org; Wed, 25 Apr 2007 18:08:56 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgpfT-0003w5-C2
	for sip@ietf.org; Wed, 25 Apr 2007 18:08:56 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3PM8qS22719; Wed, 25 Apr 2007 22:08:52 GMT
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: Wed, 25 Apr 2007 17:08:51 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
In-Reply-To: <462F613C.2050502@sipstation.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-sip-sips-03.txt: Closing of Opened issues
Thread-Index: AceHQ3E2Tqzth7/qTPyhzflEBGpMbAACkY5w
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
From: "Francois Audet" <audet@nortel.com>
To: <sip@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: Alan Johnston <alan@sipstation.com>, Keith Drage <drage@alcatel-lucent.com>,
	"Peterson, Jon" <jon.peterson@neustar.biz>,
	Dean Willis <dean.willis@softarmor.com>
Subject: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi All,

I looks like we are about ready to close on the 2 remaining opened
issues in=20
Appendix C of draft-ietf-sip-sips-03.

   1.  Do we deprecate the "last hop retarget upgrade exception"? =20

	It appears that we DO have a concensus that we do deprecate the
last
	hop retarget upgrade exception, as the remaining concerns have
been
	addressed to the satisfaction of the person who expressed the
concern.


   2.  Do we need the sips option tag?

	My reading of the group is that we have a rough consensus on NOT
to=20
	use an option tag.=20

Please let me know if there are strong objections on either topics, and
if
not, I will close off the two issues and issue a version -04.

=09


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 25 18:25:11 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hgpv9-0003Mv-ET; Wed, 25 Apr 2007 18:25:07 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hgpv8-0003Mq-3i
	for sip-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 18:25:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgpv7-0003MO-Pw
	for sip@ietf.org; Wed, 25 Apr 2007 18:25:05 -0400
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgpv6-0008IC-Gv
	for sip@ietf.org; Wed, 25 Apr 2007 18:25:05 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	l3PMOL416575 for <sip@ietf.org>; Wed, 25 Apr 2007 22:24:21 GMT
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: Interaction of SIPS with old implementations that weren't
	really	using SIPS (was Re: [Sip] draft-ietf-sip-sips-03.txt)
Date: Wed, 25 Apr 2007 17:25:01 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E61277C242@zrc2hxm2.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10329BE4@zrc2hxm0.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Interaction of SIPS with old implementations that weren't
	really	using SIPS (was Re: [Sip] draft-ietf-sip-sips-03.txt)
thread-index: AceHY4YNaG7bnLNLS0O87EeMYYv3UgAAFfxwAANrftAAAxhogAAA0jiQ
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Francois Audet" <audet@nortel.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

>
>On your first question: If I send you a request using a SIPS=20
>URI, and you accept it even if you don't support SIPS (because=20
>you are a buggy implemenation), you will nevertheless put SIP=20
>in the various URIs in your response, e.g., in the Contact=20
>header. You may even muck-up the From or To. If you send me=20
>mid-call requests later, you will most probably use SIP URIs=20
>in From. If I detect something like that, I can probably=20
>figure out something is wrong. Some of this is already covered=20
>in the draft and in RFC 3261.=20

If it just doesn't support SIPS, It should just return "416 Unsupported
URI scheme".
Very pointed question, why do we want to develop standards for the BUGGY
implementation. At the _most_, we can just say in BCP/INFORMATIONAL
document that if it behaves like this, then it is buggy implementation.
And we don't attempt to fix it in the specification. If we take this
route, we might find numerous others BUGGY implementations of other
parts of SIP specifications also. I just call them BUGS. And bugs are
fixed by their owners during the upgrades/patches etc.
>
>On your second question. It's not the protocol that is broken but the=20
>implementation.  =20
>
We should not even attempt to fix the broken implementation via another
add-on standards. I don't want to say now as Dean yesterday said season
is over for hunting. Keep trying to fix it. Good luck.

Thx
Samir


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Wed Apr 25 18:32:56 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hgq2h-00087b-1O; Wed, 25 Apr 2007 18:32:55 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hgq2f-000822-Em
	for sip-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 18:32:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgq2f-00080K-4J
	for sip@ietf.org; Wed, 25 Apr 2007 18:32:53 -0400
Received: from zrtps0kp.nortel.com ([47.140.192.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgq2d-0001q0-Sp
	for sip@ietf.org; Wed, 25 Apr 2007 18:32:53 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3PMWnJ14349 for <sip@ietf.org>; Wed, 25 Apr 2007 22:32:49 GMT
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: Interaction of SIPS with old implementations that weren't
	really	using SIPS (was Re: [Sip] draft-ietf-sip-sips-03.txt)
Date: Wed, 25 Apr 2007 17:32:48 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF10329D02@zrc2hxm0.corp.nortel.com>
In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E61277C242@zrc2hxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Interaction of SIPS with old implementations that weren't
	really	using SIPS (was Re: [Sip] draft-ietf-sip-sips-03.txt)
Thread-Index: AceHY4YNaG7bnLNLS0O87EeMYYv3UgAAFfxwAANrftAAAxhogAAA0jiQAAHej+A=
References: <1ECE0EB50388174790F9694F77522CCF10329BE4@zrc2hxm0.corp.nortel.com>
	<62B9B0847CC47543B6B3B5E26BD268E61277C242@zrc2hxm2.corp.nortel.com>
From: "Francois Audet" <audet@nortel.com>
To: "Samir Srivastava" <samirsr@nortel.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I should have known better not to waste my time answering your
questions when you obviously don't care about the answers.=20

I won't make that mistake again.=20

> -----Original Message-----
> From: Srivastava, Samir (SC100:8826)=20
> Sent: Wednesday, April 25, 2007 15:25
> To: Audet, Francois (SC100:3055)
> Cc: 'sip@ietf.org'
> Subject: RE: Interaction of SIPS with old implementations=20
> that weren't really using SIPS (was Re: [Sip]=20
> draft-ietf-sip-sips-03.txt)
>=20
> >
> >On your first question: If I send you a request using a SIPS=20
> URI, and=20
> >you accept it even if you don't support SIPS (because you=20
> are a buggy=20
> >implemenation), you will nevertheless put SIP in the various URIs in=20
> >your response, e.g., in the Contact header. You may even muck-up the=20
> >From or To. If you send me mid-call requests later, you will most=20
> >probably use SIP URIs in From. If I detect something like=20
> that, I can=20
> >probably figure out something is wrong. Some of this is=20
> already covered=20
> >in the draft and in RFC 3261.
>=20
> If it just doesn't support SIPS, It should just return "416=20
> Unsupported URI scheme".
> Very pointed question, why do we want to develop standards=20
> for the BUGGY implementation. At the _most_, we can just say=20
> in BCP/INFORMATIONAL document that if it behaves like this,=20
> then it is buggy implementation. And we don't attempt to fix=20
> it in the specification. If we take this route, we might find=20
> numerous others BUGGY implementations of other parts of SIP=20
> specifications also. I just call them BUGS. And bugs are=20
> fixed by their owners during the upgrades/patches etc.
> >
> >On your second question. It's not the protocol that is=20
> broken but the=20
> >implementation.  =20
> >
> We should not even attempt to fix the broken implementation=20
> via another add-on standards. I don't want to say now as Dean=20
> yesterday said season is over for hunting. Keep trying to fix=20
> it. Good luck.
>=20
> Thx
> Samir
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 00:37:41 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgvjU-0007lE-Fb; Thu, 26 Apr 2007 00:37:28 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HgvjS-0007l9-TR
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 00:37:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HgvjS-0007l1-Jf
	for sip@ietf.org; Thu, 26 Apr 2007 00:37:26 -0400
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgvjS-00073g-5A
	for sip@ietf.org; Thu, 26 Apr 2007 00:37:26 -0400
Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96])
	by ns1.neustar.com (Postfix) with ESMTP id 040B226E8A;
	Thu, 26 Apr 2007 04:37:26 +0000 (GMT)
Received: from stntexch11.cis.neustar.com ([10.31.13.50]) by
	stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 26 Apr 2007 00:37:25 -0400
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: [Sip] draft-ietf-sip-sips-03.txt
Date: Thu, 26 Apr 2007 00:37:25 -0400
Message-ID: <9D18525F6EF33947BDEF23374EF26C7A06CCCE@stntexch11.cis.neustar.com>
In-Reply-To: <43E39632-46AE-456A-8BA8-1A1E93FB6272@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] draft-ietf-sip-sips-03.txt
Thread-Index: AceHdEtixEyydEZMT9eXimzV7O39OwAQ0XUw
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "Cullen Jennings" <fluffy@cisco.com>, "Alan Johnston" <alan@sipstation.com>
X-OriginalArrivalTime: 26 Apr 2007 04:37:25.0941 (UTC)
	FILETIME=[96F24650:01C787BC]
X-Spam-Score: -2.8 (--)
X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>,
	Keith Drage <drage@alcatel-lucent.com>,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


The critical issue here is the backwards compatibility question. If we =
accept that SIPS as written in RFC3261 (that is, with the last hop =
exception) is not and will never be implemented, then I suppose an =
option-tag is redundant. If not, though, then as a UAC sending a =
request, I would certainly want a proxy server to fail a SIPS request if =
it didn't understand that the last hop exception could not be invoked.=20

As such, in that case I'd see value for the option tag in Proxy-Require. =
The use of the option-tag in Proxy-Require would of course be at the =
discretion of the UAC sending a request. But of course, it is always the =
UAC that is requesting and invoking the protection of SIPS, so that =
seems like a natural fit.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]
> Sent: Wednesday, April 25, 2007 12:59 PM
> To: Alan Johnston
> Cc: Francois Audet; Peterson, Jon; sip@ietf.org; Dean Willis; Keith
> Drage
> Subject: Re: [Sip] draft-ietf-sip-sips-03.txt
>=20
>=20
>=20
> Agree with Alan .... If this document was extending SIP then I would =20
> understand the need for an option tag but the draft would not=20
> need to =20
> update 3261.
>=20
> On Apr 25, 2007, at 7:10 AM, Alan Johnston wrote:
>=20
> > I don't think we need an option tag for this - we are not =20
> > fundamentally changing or extending RFC 3261.  The intent of 3261 =20
> > was that a sips call have encrypted signaling end-to-end, we are =20
> > just clarifying how this should be done.
> >
> > Also, since there are no deployments of sips, there is no=20
> backwards =20
> > compatibility issue.
> >
> > Thanks,
> > Alan
> >
> >
> > Francois Audet wrote:
> >> (Copying Dean and Jon and Hisham, because they are the=20
> main people =20
> >> who
> >> expressed an opinion on this).
> >>
> >> The issue is how do we handle backward-compatibility, i.e.,
> >> implementations that
> >> have implemented sips according to RFC 3261 but not to this draft.
> >>
> >> Because of the many issues highlighted in the draft, those
> >> implementations are
> >> likely to do proprietary "cheats" to handle SIPS, and they are also
> >> likely to have things that are not really legal. Presumably, the =20
> >> option-tag would
> >> allow UAs and Proxies to know if an implementation is=20
> "clean" or not.
> >> You could then
> >> provide alternative treatment for the "un-clean" implementation =20
> >> (i.e.,
> >> don't allow
> >> registration, protocol fix-up, manufacturer-specific=20
> stuff, record an
> >> aler, etc.). There are certainly other ways of doing this, and =20
> >> this is largely
> >> theoretical anyways because it's not like there is a large=20
> numbers of
> >> implementations out there.
> >>
> >> The second issue (perhaps more importantly) is the actual changes =20
> >> that
> >> we are making to RFC 3261. Specifically, the various deprecation =20
> >> of last
> >> hop ugrades/
> >> downgrades.
> >>
> >> The option-tag (with Proxy-required) allows for the sender of the
> >> request to
> >> enforce the deprecation of the last hop exception, i.e.,=20
> the session
> >> will fail
> >> with 420 if a proxy doesn't understand that it is supposed=20
> to support
> >> sips
> >> properly as per the new draft.
> >> I was thinking about the originator of the request as the=20
> entity that
> >> would want
> >> to enforce no-last-hop-exception, but Cullent points out that =20
> >> maybe it's
> >> also
> >> something that's up to the owner of the SIPS URI to=20
> decide, in which
> >> case the
> >> option-tag is not useful (of course if you are that=20
> worried about it,
> >> you
> >> could do "sips:user@example.net?Proxy-Required:sips".
> >>
> >> So....
> >>
> >> I actually don't really care either way. Really. I'm fine=20
> either way.
> >>
> >> Maybe we should do a virtual "hum".
> >>
> >> 1a - For the option-tag (but I could go either way)
> >> 1b - For the option-tag (and I really insist on it)
> >> 2a - Against the option-tag (but I could go either way)
> >> 2b - Against the option-tag (and I really insist on it)
> >> 3 - I really don't care
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Sunday, =20
> >>> April 22, 2007 20:21
> >>> To: Audet, Francois (SC100:3055)
> >>> Cc: sip@ietf.org
> >>> Subject: Re: [Sip] draft-ietf-sip-sips-03.txt
> >>>
> >>>
> >>> On Apr 16, 2007, at 3:26 PM, Francois Audet wrote:
> >>>
> >>>
> >>>>   2.  Do we need the sips option tag? The current document =20
> >>>> assumes that
> >>>>        we do use the option tag, and that is the preference of =20
> >>>> the author.
> >>>>        (There is at least one dissenting voice on that one: =20
> >>>> Hisham).
> >>>>
> >>> I'm confused on why we would need it and would want to=20
> understand =20
> >>> why it is needed before commenting on this. I don't buy the =20
> >>> needing it to enforce deprecate of last hop rule - I see problem =20
> >>> in that it leads to two bits that mean the same thing and=20
> we have =20
> >>> to deal with all the corner cases of when they conflict. It also =20
> >>> makes me wonder if there are problems when a URI is copied from =20
> >>> one situation to another and the REquires: sips header is not.
> >>>
> >>> Cullen <with my individual hat on>
> >>>
> >>>
> >>>
> >>
> >>
> >> _______________________________________________
> >> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >> This list is for NEW development of the core SIP Protocol
> >> Use sip-implementors@cs.columbia.edu for questions on current sip
> >> Use sipping@ietf.org for new developments on the application of sip
> >>
> >>
> >>
> >
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 01:02:45 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hgw7u-0006jr-Kv; Thu, 26 Apr 2007 01:02:42 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hgw7t-0006jm-14
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 01:02:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgw7s-0006je-NZ
	for sip@ietf.org; Thu, 26 Apr 2007 01:02:40 -0400
Received: from nz-out-0506.google.com ([64.233.162.238])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgw7r-0004Zb-Gh
	for sip@ietf.org; Thu, 26 Apr 2007 01:02:40 -0400
Received: by nz-out-0506.google.com with SMTP id z6so615141nzd
	for <sip@ietf.org>; Wed, 25 Apr 2007 22:02:39 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type;
	b=itW0ga+Qy5NEKPHxAKq4PdyNnySw54uA37bSUZ84fL8FelMR+8U0DMIC8SeMqXNkxzb+ON0RV64qdmAT4vk0MmPd/i591ve8ebrwBN3oAYMhqyFwQJqzB5c4SAeGt4wJpCKHU8eY4iV5KPtPNP0N7EAbCTbKSQYcGAUdSdtmMxI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:mime-version:content-type;
	b=oKoSv58Ld6IQ3fREwgpQ2jxKRVDhI+G8RsUHtQ4VYNJyTSHkZ7CeW+L5hGysD83b4ZDZ8KSBVb2N+8YeQXi24/XSTFMULMLPtYTQLLcCaL2ciRDEujFz6BTulDiBwRH/PTlR2W9Y2qnPpBRDHovdOTvAzLos7Y7fpkGDekdleto=
Received: by 10.114.184.16 with SMTP id h16mr470225waf.1177563758457;
	Wed, 25 Apr 2007 22:02:38 -0700 (PDT)
Received: by 10.114.144.11 with HTTP; Wed, 25 Apr 2007 22:02:38 -0700 (PDT)
Message-ID: <312d04250704252202l12354973j2a6a6da6847f3132@mail.gmail.com>
Date: Thu, 26 Apr 2007 13:02:38 +0800
From: "=?BIG5?B?s6+ryaX0?=" <asq355@gmail.com>
To: sip@ietf.org
Subject: [sip] Questions about SIP NOTIFY message
MIME-Version: 1.0
X-Spam-Score: 1.0 (+)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2070200661=="
Errors-To: sip-bounces@ietf.org

--===============2070200661==
Content-Type: multipart/alternative; 
	boundary="----=_Part_52570_25367638.1177563758405"

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

Hi all,

I want to use the NOTIFY message to inform UA that the event
'message-summaryevent' occur.
If I use one kind of summary as following example, it OK!

Messages-Waiting: yes
Voice-Message: 3/8
But if I use multi-summary simultaneously in NOTIFY message, it will return
"415 Unsupported Media Type" message.

Messages-Waiting: yes
Voice-Message: 3/8
Text-Message: 0/0
Fax-Message: 0/0

Does it means the NOTIFY message can not contain multi-summary?

Please give me suggest, thanks!

Allen_Chen

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

<div>Hi all,</div>
<div>&nbsp;</div>
<div>I want to use the NOTIFY message to inform UA that&nbsp;the event &#39;message-summaryevent&#39; occur.</div>
<div>If I use one kind of&nbsp;summary as following example, it OK!</div>
<div>
<p>Messages-Waiting: yes<br>Voice-Message: 3/8</p></div>
<div>But if I use multi-summary simultaneously in NOTIFY message, it will return &quot;415 Unsupported Media Type&quot; message.</div>
<div>
<p>Messages-Waiting: yes<br>Voice-Message: 3/8<br>Text-Message: 0/0<br>Fax-Message: 0/0</p>
<p>Does it means the NOTIFY message can not contain multi-summary?</p>
<p>Please give me suggest, thanks!</p>
<p>Allen_Chen</p>
<p>&nbsp;</p></div>

------=_Part_52570_25367638.1177563758405--



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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============2070200661==--





From sip-bounces@ietf.org Thu Apr 26 02:00:22 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hgx1P-0001g9-5h; Thu, 26 Apr 2007 02:00:03 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hgx1N-0001eq-GO
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 02:00:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgx1N-0001ef-2r
	for sip@ietf.org; Thu, 26 Apr 2007 02:00:01 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgx1L-0006v6-MC
	for sip@ietf.org; Thu, 26 Apr 2007 02:00:01 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id 0C3981EC02E;
	Thu, 26 Apr 2007 08:59:58 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id u05oXaTaGkv7; Thu, 26 Apr 2007 08:59:56 +0300 (EEST)
Received: from taimen (primer189.gprs.dnafinland.fi [62.78.125.189])
	by tutpro.com (Postfix) with ESMTP;
	Thu, 26 Apr 2007 08:59:56 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id D316DAC122; Thu, 26 Apr 2007 08:59:48 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17968.16340.800200.535818@tutpro.com>
Date: Thu, 26 Apr 2007 08:59:48 +0300
To: "Francois Audet" <audet@nortel.com>
Subject: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: sip@ietf.org, Keith Drage <drage@alcatel-lucent.com>,
	Alan Johnston <alan@sipstation.com>, "Peterson,
	Jon" <jon.peterson@neustar.biz>, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Francois Audet writes:

 > I looks like we are about ready to close on the 2 remaining opened
 > issues in  Appendix C of draft-ietf-sip-sips-03.

how about the r-r tls transport issue that was raised a couple of days
ago?  someone said that according to your i-d, my proxy that uses tls
with then next proxy, has to upgrade sip: to sips: over that link.  

if that is true, your draft is badly broken, because my proxy cannot
have any knowledge that sips: is supported on the following hops.  if
that is not true, tell me what kind of r-r(s) my proxy needs to in that
case insert.

-- juha


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 03:55:44 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hgyp7-00047T-PJ; Thu, 26 Apr 2007 03:55:29 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hgyp5-00047I-J3
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 03:55:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgyp2-000470-8X
	for sip@ietf.org; Thu, 26 Apr 2007 03:55:24 -0400
Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgyp0-00058k-JA
	for sip@ietf.org; Thu, 26 Apr 2007 03:55:24 -0400
Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com
	[155.132.6.76])
	by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l3Q7srbr018075; 
	Thu, 26 Apr 2007 09:54:53 +0200
Received: from [139.54.131.75] ([139.54.131.75]) by
	FRVELSBHS04.ad2.ad.alcatel.com over TLS secured channel with
	Microsoft SMTPSVC(6.0.3790.2499); Thu, 26 Apr 2007 09:55:20 +0200
Message-ID: <46305AE8.6040405@alcatel-lucent.fr>
Date: Thu, 26 Apr 2007 09:55:20 +0200
From: Thomas Froment <Thomas.Froment@alcatel-lucent.fr>
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: Juha Heinanen <jh@tutpro.com>
Subject: Re: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>	<462F613C.2050502@sipstation.com>	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
In-Reply-To: <17968.16340.800200.535818@tutpro.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Apr 2007 07:55:20.0628 (UTC)
	FILETIME=[3CCFB740:01C787D8]
X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: "Peterson, Jon" <jon.peterson@neustar.biz>, sip@ietf.org,
	Francois Audet <audet@nortel.com>, Keith Drage <drage@alcatel-lucent.com>,
	Dean Willis <dean.willis@softarmor.com>,
	Alan Johnston <alan@sipstation.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Juha Heinanen wrote:
> Francois Audet writes:
>
>  > I looks like we are about ready to close on the 2 remaining opened
>  > issues in  Appendix C of draft-ietf-sip-sips-03.
>
> how about the r-r tls transport issue that was raised a couple of days
> ago?  someone said that according to your i-d, my proxy that uses tls
> with then next proxy, has to upgrade sip: to sips: over that link.  
>
> if that is true, your draft is badly broken, because my proxy cannot
> have any knowledge that sips: is supported on the following hops.  if
> that is not true, tell me what kind of r-r(s) my proxy needs to in that
> case insert.
>   
Yes, actually, on my side, I did not answer your last remark because I 
think this is NOT related to "double RR" versus "R-R rewriting" question.
You can choose to either double R-R or rewrite, but the question you are 
raising is: are you allowed to continue to use "transport=TLS" or not,
this more a question related to sip/sips clarification: currently this 
is clearly stated in sip/sips that TLS transport parameter should not be 
used...

Thomas


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 04:02:37 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hgyvx-0002jC-Jb; Thu, 26 Apr 2007 04:02:33 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hgyvw-0002j0-85
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 04:02:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgyvu-0002in-Sj
	for sip@ietf.org; Thu, 26 Apr 2007 04:02:31 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgyvt-0002Tx-GN
	for sip@ietf.org; Thu, 26 Apr 2007 04:02:30 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id C473E1EC02E;
	Thu, 26 Apr 2007 11:02:28 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id sLKrGY5jlvAx; Thu, 26 Apr 2007 11:02:26 +0300 (EEST)
Received: from taimen (primer189.gprs.dnafinland.fi [62.78.125.189])
	by tutpro.com (Postfix) with ESMTP;
	Thu, 26 Apr 2007 11:02:26 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id 6CC69AC122; Thu, 26 Apr 2007 11:02:20 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17968.23692.411137.362017@tutpro.com>
Date: Thu, 26 Apr 2007 11:02:20 +0300
To: Thomas Froment <Thomas.Froment@alcatel-lucent.fr>
Subject: Re: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
In-Reply-To: <46305AE8.6040405@alcatel-lucent.fr>
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<46305AE8.6040405@alcatel-lucent.fr>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: "Peterson, Jon" <jon.peterson@neustar.biz>, sip@ietf.org,
	Francois Audet <audet@nortel.com>, Keith Drage <drage@alcatel-lucent.com>,
	Dean Willis <dean.willis@softarmor.com>,
	Alan Johnston <alan@sipstation.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Thomas Froment writes:

 > Yes, actually, on my side, I did not answer your last remark because I 
 > think this is NOT related to "double RR" versus "R-R rewriting" question.
 > You can choose to either double R-R or rewrite, but the question you are 
 > raising is: are you allowed to continue to use "transport=TLS" or not,
 > this more a question related to sip/sips clarification: currently this 
 > is clearly stated in sip/sips that TLS transport parameter should not be 
 > used...

thomas,

yes, i understood that this is not a your problem.  that is why i now
posted the question explicitly to author of sips i-d.  if sips i-d tells
in the case of my example to upgrade sip: to sips: there is a BIG bug in
it.  

for some reason this issue was missing from the issues list that the
author of sips i-d just posted.

-- juha


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 11:35:55 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hh60W-00035n-Sj; Thu, 26 Apr 2007 11:35:44 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hh60V-00035i-Hr
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 11:35:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh60V-00035Y-8A
	for sip@ietf.org; Thu, 26 Apr 2007 11:35:43 -0400
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 1Hh60T-0001aO-H2 for sip@ietf.org; Thu, 26 Apr 2007 11:35:43 -0400
Received: from [172.17.1.65] ([172.17.1.65]) (authenticated bits=0)
	by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id l3QFYcjD024564
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 26 Apr 2007 10:34:39 -0500 (CDT)
	(envelope-from rjsparks@estacado.net)
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: <687F5314-7A9B-443E-85A0-0DA3FD7D7030@estacado.net>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: IETF SIP List <sip@ietf.org>, sip-implementors@cs.columbia.edu,
	discussion@sipforum.org
From: Robert Sparks <rjsparks@estacado.net>
Date: Thu, 26 Apr 2007 10:34:36 -0500
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb
Cc: 
Subject: [Sip] SIPit 20 survey summary
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

SIPit 20 was hosted by Alcatel-Lucent in Antwerp, Belgium from April  
16 to April 20, 2007. Many thanks to Alcatel-Lucent, in particular  
Ben Bonnaerens and Nadine Staelens for a well-planned and effective  
event in a very nice venue.

There were 145 attendees from 59 companies visiting from 19 countries  
present.
There were 67 teams and around 90 distinct implementations.

A higher than usual percentage of the attendees (my guess is around  
60%) were attending SIPit for the first time.

The most common thread in interoperability problems centered on  
interpreting SDP at this event. Most of these were implementation  
issues, but more people are running into issues as they try to  
exchange more than the most basic of offers and answers. These ranged  
from issues with multiple m-lines to trying to specify different  
packetization times for codecs on the same m-line to problems with  
the "delayed" offer-answer exchange in INVITE/200/ACK (where the  
INVITE has no body).
More implementations are supporting TLS, and several implementations  
had issues  around correctly handling mutual authentications and  
reusing connections.

There was a lot of (understandable) confusion about what to do with  
sips:. Most implementations that could handle TLS are not yet trying  
to handle sips:. The few that did try to do something sane with sips:  
are watching the discussion on the SIP mailing list. In any case,  
there was not a set of implementors present who felt sips was  
sufficiently specified and would be unhappy if the definition  
changed. I also didn't find anyone who felt an existing deployment  
would suffer from any change to the definition.

We used a web-based survey tool for collecting implementation  
statistics for the second time. As noted in the report for SIPit19,  
this has an impact on the accuracy of the information (since someone  
will inevitably not understand one or more questions, or won't know  
the answer). Only 59 of the 67 teams completed the survey. We plan to  
use a slightly different mechanism at the next event to improve the  
accuracy and completeness of the results.

With the understanding that there is some sampling error here is what  
those 59 teams reported:

The roles represented (some implementations act in more than one role):
   29 endpoints
   19 proxy/registrars
    5 standalone proxies
    5 redirect servers
    7 gateways
    9 automaton UAs (voicemail, conference, etc.)
   17 b2bua/sbcs
    5 UAs with signaling but no media
    4 test/monitoring tools

Implementations using each transport for SIP messages:
   UDP 100%
   TCP  82%
   TLS  46% (server auth only)
   TLS  24% (server or mutual auth)
   SCTP  7%
   DTLS  0%

71% of the implementations claimed they would correctly reassemble  
fragmented UDP (10% of the remaining were not sure).

At SIPit19, I asked for the size of the largest datagram an  
implementation would accept. The answers indicated that most folks  
didn't understand the question, so I was not able to produce a useful  
summary from that event. We repeated the question at SIPit 20, and  
while there's still confusion, there are enough answers to start  
getting a picture. Remember again that these are self-reported numbers:
    1500 bytes or less: 18% (the smallest was 1300)
    1500 to 4K        : 10%
    64K               : 24%
    didn't know       : 25%
25% of the implementations present supported SIP over IPv6.

For DNS we had support for:
    Full RFC3263    : 54%
    SRV only        : 14%
    A records only  : 14%
    no DNS support  : 12%
    other           : 6% (includes those that didn't know or didn't  
reply)

Support for various items:
    31% ENUM
    68% rport
    27% multiplexing SIP/STUN on the same port
    14% SIGCOMP
    15% RFC4320 fixes
    16% Identity

There were no implementations present of any significant part of the  
session-policy framework.

There were no implementations of the hilt-sipping-*-overload drafts  
or anything else meeting the requirements in ietf-sipping-overload-reqs.

There were two server implementations of sip-outbound, but no clients  
to test against.

There were 4 implementations of GRUU present (at different draft  
levels). We did have one successful test where a UA obtained and used  
a GRUU.

The endpoints implemented these methods:
    100% INVITE, CANCEL, ACK, BYE
     94% REGISTER
     92% OPTIONS
     79% SUBSCRIBE <- Notice the difference here...
     96% NOTIFY    <-    unsolicited notifies were prevalent
     68% PRACK
     58% MESSAGE
     79% INFO
     64% UPDATE
     87% REFER
     38% PUBLISH

The endpoints implemented these extensions:
   77% RFC3891: replaces
   60% RFC4028: session-timer
   21% RFC3327: path
    6% RFC3840: pref
    2% RFC3841: caller-prefs
   30% RFC3323: privacy
    0% RFC4538: target-dialog
    6% RFC4488: norefersub
   68% RFC3262: 100rel
   11% RFC3994: indication of message composition

57% of the endpoints implemented sipping-cc-transfer

When asked about STUN support, the client implementations replied:
    8% I implement all the client requirements of draft-ietf-behave- 
rfc3489bis
    6% I implement some, but not all, of the client requirements of  
draft-ietf-behave-rfc3498bis
    4% I implement all of the client requirements of RFC3489
   14% I implement some, but not all, of the client requirements of  
RFC3489
   60% I do not implement STUN as a client
    8% Other

There were several STUN servers and at least two TURN servers. We had  
more TURN clients this time, and successfully exercised TURN. Three  
implementations claimed support for ICE, but no interoperability was  
reported (I suspect there were versioning issues that couldn't be  
overcome in the time-scale of the event). There was one ice-tcp  
implementation present.

This is how the endpoints characterized their handling of S/MIME:
    6% I break if someone sends me S/MIME
   34% I pretend S/MIME doesn't exist if it shows up
   38% I don't pay attention to S/MIME, but will proxy it or hand it  
to my application
    4% I pay attention to S/MIME I receive, but don't send any
    0% I don't pay attention to S/MIME I receive, but I do send some
    6% I try to do something useful with S/MIME I receive and send
   12% Other

This is how they answered for multipart/mime:
    2% I break if someone sends me multipart/mime
   24% I pretend multipart/mime doesn't exist if someone sends it to me
   24% I ignore multipart/mime but will proxy it or hand it to my  
application if it shows up
   10% I try to do something useful with multipart/mime I receive,  
but I never send it
    4% I ignore multipart/mime that I receive, but I try to do  
something useful with multipart/mime I send
   24% I try to do something useful with multipart/mime I send and  
receive
   12% Other

Here is how the endpoints claimed to handle receiving 200 OKs from  
more than one branch of a forked INVITE:
   36% I send BYEs to all but one branch
   10% I use all of them (perhaps mixing the different media streams  
locally)
   42% I don't handle this case gracefully
   12% Other

27% of the endpoints did not use symmetric RTP

This is how the endpoints (that actually handled media) described  
their use of RTCP:
   33% I fully implement RTCP and use the RTCP from my peers
   27% I send some RTCP, and open a port to receive RTCP, but I  
ignore any packets I receive
    6% I never send RTCP, but I do open a port for receiving (and  
ignoring) it
   34% I don't even open a port for RTCP

There were 9 SRTP endpoints (down from 12 at the last event). Only 4  
of those used sdes.
Interoperability after key exchange was lower than at SIPit 19.
There was only one RTP over DTLS implementation present.

One endpoint claimed support for comedia (but 10 claimed they would  
send media over TCP).

For hold, the endpoints claimed:
   8%  I don't support hold
   4%  I set the m-line port to 0
10%  I set the c-line to 0.0.0.0
27%  I use the sendonly/recvonly/sendrecv attributes
15%  I use the s/r/sr attributes, but only if I see them in SDP from  
the other party first, otherwise I set the m-line port to zero
17%  I use the s/r/sr attributes AND set the m-line port to 0
19%  I don't do any of those things

25% of the endpoints would offer SDP with more than one m-line.
57% would only play one audio stream if they received multiple.

Most proxies are now doing either 3261 or fork-loop-fix loop detection.

Only 30% of the proxies claimed they would forward a request with an  
unknown RURI scheme when there was a Route header field whose first  
value is a SIP URI.

25% of the proxies actively participate in session timer.

5 of the 19 proxies present would upgrade from sip: to sips: while  
forwarding. 6 would downgrade.

6 of the registrars would allow non-sip or sips schemes in contacts.
6 of the registrars claimed to accept an S/MIME signed or encrypted  
REGISTER request.

Less than half of the b2bua/sbc-like elements could be configured to  
forward unknown methods.
Most could be configured to forward unknown SDP lines.

There were 46 SIP-Events implementations

These were the supported event packages:
30 refer
20 message-summary
14 presence
14 dialog
   9 reg
   6 conference
   2 ua-profile
   2 gruu-reg-event
   2 kpml

5 supported winfo

4 supported event-list

15 would issue an unsolicited NOTIFY.
27 would respond to an unsolicited NOTIFY with a 200-OK

There were 2 partial-publish/partial-notify implementations

4 implementations supported presence-rules

I repeated the question about which P-headers each implementation  
actively supported:
   34 P-Asserted-Identity
   21 P-Preferred-Identity
   12 P-Associated-URI
   12 P-Called-Party-ID
   10 P-Access-Network-Info
    8 P-Charging-Vector
    7 P-Visited-Network-ID
    7 P-Charging-Function-Address
    5 P-Media-Authorization
    4 P-User-Database
    4 P-DCS-* (andy of the P-DCS headers)
    1 P-Answer-State

Let me know if there are other questions you'd like to see asked next  
time.

RjS


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 12:01:12 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hh6P7-0005n2-CD; Thu, 26 Apr 2007 12:01:09 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hh6P6-0005mv-HC
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 12:01:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh6P6-0005mn-7K
	for sip@ietf.org; Thu, 26 Apr 2007 12:01:08 -0400
Received: from zrtps0kp.nortel.com ([47.140.192.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh6P4-0005BE-VD
	for sip@ietf.org; Thu, 26 Apr 2007 12:01:08 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3QG13Q16178; Thu, 26 Apr 2007 16:01:03 GMT
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: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Date: Thu, 26 Apr 2007 11:00:58 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
In-Reply-To: <17968.16340.800200.535818@tutpro.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Thread-Index: AceHyCKMGASbLsM+TZ+Cf3fdIbSaswAU0UAg
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
From: "Francois Audet" <audet@nortel.com>
To: "Juha Heinanen" <jh@tutpro.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: sip@ietf.org, Keith Drage <drage@alcatel-lucent.com>,
	Alan Johnston <alan@sipstation.com>, "Peterson,
	Jon" <jon.peterson@neustar.biz>, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Yeah, sorry, I missed that thread.

The current draft basically says that it is NOT legal for a proxy
to "upgrade" or "downgrade" from sip to sips or vice versa. It MUST
keep the same scheme.

So, it is "not true" and therefore not badly broken. In fact, that's
the whole point of making that change in the draft: fixing sips so it is
not broken.

The Double Record-Route procedures are nevertheless described in the
draft because people wanted to see "what would happen with theoretical
legacy 3261 implementations that supported sips as per 3261, but not
according to the new draft".=20

So: to summarize, with the current draft, the double record-route
procedures
are never used.

> -----Original Message-----
> From: Juha Heinanen [mailto:jh@tutpro.com]=20
> Sent: Wednesday, April 25, 2007 23:00
> To: Audet, Francois (SC100:3055)
> Cc: sip@ietf.org; Alan Johnston; Keith Drage; Peterson, Jon;=20
> Dean Willis
> Subject: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
>=20
> Francois Audet writes:
>=20
>  > I looks like we are about ready to close on the 2=20
> remaining opened  > issues in  Appendix C of draft-ietf-sip-sips-03.
>=20
> how about the r-r tls transport issue that was raised a=20
> couple of days ago?  someone said that according to your i-d,=20
> my proxy that uses tls with then next proxy, has to upgrade=20
> sip: to sips: over that link. =20
>=20
> if that is true, your draft is badly broken, because my proxy=20
> cannot have any knowledge that sips: is supported on the=20
> following hops.  if that is not true, tell me what kind of=20
> r-r(s) my proxy needs to in that case insert.
>=20
> -- juha
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 12:03:50 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hh6Rh-0008Qz-PD; Thu, 26 Apr 2007 12:03:49 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hh6Rg-0008Qu-2b
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 12:03:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh6Rf-0008Qm-PL
	for sip@ietf.org; Thu, 26 Apr 2007 12:03:47 -0400
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh6Rd-0005f9-AH
	for sip@ietf.org; Thu, 26 Apr 2007 12:03:47 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	l3QG2up28029; Thu, 26 Apr 2007 16:02:57 GMT
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: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Date: Thu, 26 Apr 2007 11:03:23 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF1032A3D2@zrc2hxm0.corp.nortel.com>
In-Reply-To: <46305AE8.6040405@alcatel-lucent.fr>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Thread-Index: AceH2EOVqMVD1d3kQ7auiJw1YxhmngAQ/Fqg
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<46305AE8.6040405@alcatel-lucent.fr>
From: "Francois Audet" <audet@nortel.com>
To: "Thomas Froment" <Thomas.Froment@alcatel-lucent.fr>,
	"Juha Heinanen" <jh@tutpro.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: sip@ietf.org, Alan Johnston <alan@sipstation.com>,
	Keith Drage <drage@alcatel-lucent.com>, "Peterson,
	Jon" <jon.peterson@neustar.biz>, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Yes, transport=3Dtls has been deprecated since RFC 3261. Correct.

draft-ietf-sip-sips-03 simply makes it clearer. It is very true
that the deprecation in RFC 3261 has been missed by many people.=20

> -----Original Message-----
> From: Thomas Froment [mailto:Thomas.Froment@alcatel-lucent.fr]=20
> Sent: Thursday, April 26, 2007 00:55
> To: Juha Heinanen
> Cc: Audet, Francois (SC100:3055); sip@ietf.org; Keith Drage;=20
> Alan Johnston; Peterson, Jon; Dean Willis
> Subject: Re: [Sip] draft-ietf-sip-sips-03.txt: Closing of=20
> Opened issues
>=20
> Juha Heinanen wrote:
> > Francois Audet writes:
> >
> >  > I looks like we are about ready to close on the 2=20
> remaining opened =20
> > > issues in  Appendix C of draft-ietf-sip-sips-03.
> >
> > how about the r-r tls transport issue that was raised a=20
> couple of days=20
> > ago?  someone said that according to your i-d, my proxy=20
> that uses tls=20
> > with then next proxy, has to upgrade sip: to sips: over that link.
> >
> > if that is true, your draft is badly broken, because my=20
> proxy cannot=20
> > have any knowledge that sips: is supported on the following=20
> hops.  if=20
> > that is not true, tell me what kind of r-r(s) my proxy needs to in=20
> > that case insert.
> >  =20
> Yes, actually, on my side, I did not answer your last remark=20
> because I think this is NOT related to "double RR" versus=20
> "R-R rewriting" question.
> You can choose to either double R-R or rewrite, but the=20
> question you are raising is: are you allowed to continue to=20
> use "transport=3DTLS" or not, this more a question related to=20
> sip/sips clarification: currently this is clearly stated in=20
> sip/sips that TLS transport parameter should not be used...
>=20
> Thomas
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 12:07:02 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hh6Um-0003Z9-W4; Thu, 26 Apr 2007 12:07:01 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hh6Um-0003Xw-9P
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 12:07:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh6Ul-0003XA-Vx
	for sip@ietf.org; Thu, 26 Apr 2007 12:06:59 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh6Uk-00065D-Kv
	for sip@ietf.org; Thu, 26 Apr 2007 12:06:59 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id 9BABB1EC02E;
	Thu, 26 Apr 2007 19:06:57 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id BXCcS7KOhIKi; Thu, 26 Apr 2007 19:06:55 +0300 (EEST)
Received: from taimen (primer189.gprs.dnafinland.fi [62.78.125.189])
	by tutpro.com (Postfix) with ESMTP;
	Thu, 26 Apr 2007 19:06:55 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id DA9D3AC122; Thu, 26 Apr 2007 19:06:48 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17968.52760.363575.469609@tutpro.com>
Date: Thu, 26 Apr 2007 19:06:48 +0300
To: "Francois Audet" <audet@nortel.com>
Subject: RE: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: sip@ietf.org, Keith Drage <drage@alcatel-lucent.com>,
	Alan Johnston <alan@sipstation.com>, "Peterson,
	Jon" <jon.peterson@neustar.biz>, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Francois Audet writes:

 > So: to summarize, with the current draft, the double record-route
 > procedures are never used.

thanks for the your interpretation that differs from what i read earlier
on this list.  

in order to make this perfectly clear to proxy implementers, can
someone, please, tell exactly what the proxy should so in terms of r-r
headers and r-uri when request with sip: uri scheme comes in over udp
and goes out over tls.

-- juha


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 12:42:48 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hh73L-0003mr-05; Thu, 26 Apr 2007 12:42:43 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hh73J-0003ml-1p
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 12:42:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh73I-0003md-OZ
	for sip@ietf.org; Thu, 26 Apr 2007 12:42:40 -0400
Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh73I-0004cZ-AH
	for sip@ietf.org; Thu, 26 Apr 2007 12:42:40 -0400
Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com
	[155.132.6.78])
	by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l3QGg0Pn007528; 
	Thu, 26 Apr 2007 18:42:12 +0200
Received: from [139.54.131.75] ([139.54.131.75]) by
	FRVELSBHS06.ad2.ad.alcatel.com over TLS secured channel with
	Microsoft SMTPSVC(6.0.3790.2499); Thu, 26 Apr 2007 18:42:35 +0200
Message-ID: <4630D67D.2070700@alcatel-lucent.fr>
Date: Thu, 26 Apr 2007 18:42:37 +0200
From: Thomas Froment <Thomas.Froment@alcatel-lucent.fr>
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: Juha Heinanen <jh@tutpro.com>, sip@ietf.org
Subject: Re: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>	<462F613C.2050502@sipstation.com>	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>	<17968.16340.800200.535818@tutpro.com>	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
	<17968.52760.363575.469609@tutpro.com>
In-Reply-To: <17968.52760.363575.469609@tutpro.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Apr 2007 16:42:36.0038 (UTC)
	FILETIME=[E4FC3260:01C78821]
X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: Alan Johnston <alan@sipstation.com>, Francois Audet <audet@nortel.com>,
	Keith Drage <drage@alcatel-lucent.com>, "Peterson,
	Jon" <jon.peterson@neustar.biz>, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Juha Heinanen wrote:
> Francois Audet writes:
>
>  > So: to summarize, with the current draft, the double record-route
>  > procedures are never used.
>
> thanks for the your interpretation that differs from what i read earlier
> on this list.  
>
> in order to make this perfectly clear to proxy implementers, can
> someone, please, tell exactly what the proxy should so in terms of r-r
> headers and r-uri when request with sip: uri scheme comes in over udp
> and goes out over tls.

I think this is exactly in the scope of rr-fix draft to clarify this point.
Just to summarize how it *should* work from the beginning;
1) if your are not sure on what transport is supported by next elements, 
you do not put any transport in your RR header, as specified in sentence 
of item 4 of section 16.6, "The URI SHOULD NOT contain the transport 
parameter unless the proxy has knowledge(such as in a private network) 
that the next downstream element that will be in the path of subsequent 
requests supports that transport")

2) It is assumed the proxy will put a a logical name in Record-Route, 
and then, according to RFC 3263 procedures, any SIP element that
will try to reach your proxy should find an appropriate transport 
following these procedures (section 4.1,
basically:

If the URI specifies a transport protocol in the transport parameter,
   that transport protocol SHOULD be used.

   Otherwise, if no transport protocol is specified, but the TARGET is a
   numeric IP address, the client SHOULD use UDP for a SIP URI, and TCP
   for a SIPS URI.  Similarly, if no transport protocol is specified,
   and the TARGET is not numeric, but an explicit port is provided, the
   client SHOULD use UDP for a SIP URI, and TCP for a SIPS URI.  This is
   because UDP is the only mandatory transport in RFC 2543 [6], and thus
   the only one guaranteed to be interoperable for a SIP URI.  It was
   also specified as the default transport in RFC 2543 when no transport
   was present in the SIP URI.  However, another transport, such as TCP,
   MAY be used if the guidelines of SIP mandate it for this particular
   request.  That is the case, for example, for requests that exceed the
   path MTU.

   Otherwise, if no transport protocol or port is specified, and the
   target is not a numeric IP address, the client SHOULD perform a NAPTR
   query for the domain in the URI.

3) So, in your case, if your proxy switch from UDP to TLS, it means the NAPTR records of your proxy should answer with higher priority "TLS" for request coming from your "callee side",
and UDP for requests coming from your "caller side"...

--> Multiple questions need clarifications here, because people want to be able to switch from one transport to another, use numeric ip addresses, and still
make the RR work. So, that's why I explained a typical "workaround"  is to put a transport parameter on the RR. (if the proxy decides to
make RR rewriting, it will put just one RR with the transport used to reach the next element, and when seeing the 200 OK response, change that transport
to the transport used with the previous element.
It explains you why I said that the "Route set seen by the callee will be different than the Route Set seen by the callee" when rewriting.
Double Record-Routing does not solve that problem at all, this is still a topic to be discussed, and I am open to any suggestion about this issue.

Thomas







_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 12:48:06 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hh78P-0004B8-1w; Thu, 26 Apr 2007 12:47:57 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hh78N-0004Ax-Jw
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 12:47:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh78N-0004Ap-AP
	for sip@ietf.org; Thu, 26 Apr 2007 12:47:55 -0400
Received: from ihemail1.lucent.com ([135.245.0.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh78L-0005hx-TV
	for sip@ietf.org; Thu, 26 Apr 2007 12:47:55 -0400
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l3QGlrsP024466;
	Thu, 26 Apr 2007 11:47:53 -0500 (CDT)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by
	ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 26 Apr 2007 11:47:53 -0500
Received: from DEEXC1U01.de.lucent.com ([135.248.187.26]) by
	DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 26 Apr 2007 18:47:50 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Review of draft-ietf-sip-location-conveyance
Date: Thu, 26 Apr 2007 18:47:49 +0200
Message-ID: <5D1A7985295922448D5550C94DE29180010BF7AA@DEEXC1U01.de.lucent.com>
In-Reply-To: <5D1A7985295922448D5550C94DE2918001084501@DEEXC1U01.de.lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Review of draft-ietf-sip-location-conveyance
Thread-Index: AceASoJbwqnLTcNHTPKhgPjOBOCQcQGTLFbgAGKd4FA=
References: <5D1A7985295922448D5550C94DE29180FFE84C@DEEXC1U01.de.lucent.com>
	<5D1A7985295922448D5550C94DE2918001084501@DEEXC1U01.de.lucent.com>
From: "Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>
To: "IETF SIP List" <sip@ietf.org>
X-OriginalArrivalTime: 26 Apr 2007 16:47:50.0493 (UTC)
	FILETIME=[A06A38D0:01C78822]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a8a20a483a84f747e56475e290ee868e
Cc: geopriv-chairs@tools.ietf.org, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

We made good progress on the call yesterday, but as might be expected,
we did not finish.

There will be another review call next week - details as follows:

Tuesday 1st May 2007 at

	9:00 am - 11:00 am Central US time
	10:00 am - 12:00 noon Eastern US time
 	3:00 pm - 5:00 pm UK time
 	4:00 pm - 6:00 pm Central Europe time
=20
Bridge details:

Chairperson Name:  KEITH DRAGE
Access Phone Number:  8007718734
International Access Phone Number:  +1 6477233953=20
7-Digit Access Code: 5776249

While this call is in no sense restricted, this call is for people who
have reviewed the document. If you think you qualify, and have not sent
comments that are included above, or indeed reviewed and had no
comments, then please send me a mail indicating this.

We will have some notes from the previous call, and a number of issues
for further WG discussion on list that will come out in due course.

Regards

Keith

> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20
> Sent: Tuesday, April 24, 2007 6:39 PM
> To: IETF SIP List
> Subject: RE: [Sip] Review of draft-ietf-sip-location-conveyance
>=20
> A reminder of the call tomorrow, and also that I have posted=20
> an updated set of comments including some late comments received.=20
>=20
> The numbering remains consistent for the comments that were=20
> previously posted, and we will refer to comments by numbers=20
> on the call tomorrow.
>=20
> Keith
>=20
> > -----Original Message-----
> > From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com]
> > Sent: Monday, April 16, 2007 6:13 PM
> > To: IETF SIP List
> > Subject: [Sip] Review of draft-ietf-sip-location-conveyance
> >=20
> > I have posted the comments from WGLC on=20
> > draft-ietf-sip-location-conveyance at:
> >=20
> >=20
> http://www.softarmor.com/sipwg/reviews/location-conveyance/index.html
> >=20
> > Please let me know if I have missed any comments.=20
> >=20
> > There will be a review conference call of these comments on:
> >=20
> > Wednesday 25th April at
> >=20
> > 	1:00 pm - 3:00 pm Central US time
> > 	2:00 pm - 4:00 pm Eastern US time
> > 	7:00 pm - 9:00 pm UK time
> > 	8:00 pm - 10:00 pm Central Europe time
> >=20
> > Bridge details:
> >=20
> > Chairperson Name:  KEITH DRAGE
> > Access Phone Number:  8007718734
> > International Access Phone Number:  +1 6477233953 7-Digit=20
> Access Code:
> > 5776249
> >=20
> > While this call is in no sense restricted, this call is for=20
> people who=20
> > have reviewed the document. If you think you qualify, and have not=20
> > sent comments that are included above, or indeed reviewed=20
> and had no=20
> > comments, then please send me a mail indicating this.
> >=20
> > Regards
> >=20
> > Keith
> >=20
> >=20
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use=20
> > sip-implementors@cs.columbia.edu for questions on current sip Use=20
> > sipping@ietf.org for new developments on the application of sip
> >=20
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 12:52:14 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hh7CX-0000pb-Jm; Thu, 26 Apr 2007 12:52:13 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hh7CV-0000pV-TO
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 12:52:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh7CV-0000pN-Ju
	for sip@ietf.org; Thu, 26 Apr 2007 12:52:11 -0400
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh7CU-0006I8-BJ
	for sip@ietf.org; Thu, 26 Apr 2007 12:52:11 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	l3QGpQh03429; Thu, 26 Apr 2007 16:51:26 GMT
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: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Date: Thu, 26 Apr 2007 11:52:05 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF1032A4E0@zrc2hxm0.corp.nortel.com>
In-Reply-To: <17968.52760.363575.469609@tutpro.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Thread-Index: AceIHOyFjTGLJeFYSsi93Z6v4/cLXgAAcsNA
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
	<17968.52760.363575.469609@tutpro.com>
From: "Francois Audet" <audet@nortel.com>
To: "Juha Heinanen" <jh@tutpro.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: sip@ietf.org, Keith Drage <drage@alcatel-lucent.com>,
	Alan Johnston <alan@sipstation.com>, "Peterson,
	Jon" <jon.peterson@neustar.biz>, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Then, only the VIA headers are affected. No impact whatsoever on
Record-Route and=20
Request-URI as it is still sip: to sip:=20

You should really NOT use the transport parameter in RR or Request-URI.

But you are right, I probably need to make it more explicit in the text.

> -----Original Message-----
> From: Juha Heinanen [mailto:jh@tutpro.com]=20
> Sent: Thursday, April 26, 2007 09:07
> To: Audet, Francois (SC100:3055)
> Cc: sip@ietf.org; Alan Johnston; Keith Drage; Peterson, Jon;=20
> Dean Willis
> Subject: RE: [Sip] draft-ietf-sip-sips-03.txt: Closing of=20
> Opened issues
>=20
> Francois Audet writes:
>=20
>  > So: to summarize, with the current draft, the double=20
> record-route  > procedures are never used.
>=20
> thanks for the your interpretation that differs from what i=20
> read earlier on this list. =20
>=20
> in order to make this perfectly clear to proxy implementers,=20
> can someone, please, tell exactly what the proxy should so in=20
> terms of r-r headers and r-uri when request with sip: uri=20
> scheme comes in over udp and goes out over tls.
>=20
> -- juha
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 13:08:42 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hh7SS-0004cn-Ls; Thu, 26 Apr 2007 13:08:40 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hh7SR-0004ch-9F
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 13:08:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh7SQ-0004cZ-W4
	for sip@ietf.org; Thu, 26 Apr 2007 13:08:38 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh7SN-0001IJ-Ki
	for sip@ietf.org; Thu, 26 Apr 2007 13:08:38 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id DE83E1EC02E;
	Thu, 26 Apr 2007 20:08:34 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id ZBo+KJ4F6ao4; Thu, 26 Apr 2007 20:08:31 +0300 (EEST)
Received: from taimen (primer189.gprs.dnafinland.fi [62.78.125.189])
	by tutpro.com (Postfix) with ESMTP;
	Thu, 26 Apr 2007 20:08:31 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id 2E460AC122; Thu, 26 Apr 2007 20:08:24 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17968.56456.143583.490518@tutpro.com>
Date: Thu, 26 Apr 2007 20:08:24 +0300
To: "Francois Audet" <audet@nortel.com>
Subject: RE: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1032A4E0@zrc2hxm0.corp.nortel.com>
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
	<17968.52760.363575.469609@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A4E0@zrc2hxm0.corp.nortel.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Cc: sip@ietf.org, Keith Drage <drage@alcatel-lucent.com>,
	Alan Johnston <alan@sipstation.com>, "Peterson,
	Jon" <jon.peterson@neustar.biz>, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Francois Audet writes:

 > Then, only the VIA headers are affected. No impact whatsoever on
 > Record-Route and Request-URI as it is still sip: to sip: 

and according to rfc 3261 20.42 via will contain SIP/2.0/TLS, right?

-- juha


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 13:12:44 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hh7WO-0002RC-FK; Thu, 26 Apr 2007 13:12:44 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hh7WN-0002R7-Mo
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 13:12:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh7WN-0002Qz-DH
	for sip@ietf.org; Thu, 26 Apr 2007 13:12:43 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh7WL-0001ji-Tf
	for sip@ietf.org; Thu, 26 Apr 2007 13:12:43 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id 4BDF41EC02E;
	Thu, 26 Apr 2007 20:12:41 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id wTnmtJM5e6r0; Thu, 26 Apr 2007 20:12:39 +0300 (EEST)
Received: from taimen (primer189.gprs.dnafinland.fi [62.78.125.189])
	by tutpro.com (Postfix) with ESMTP;
	Thu, 26 Apr 2007 20:12:39 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id 5FFBDAC122; Thu, 26 Apr 2007 20:12:35 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17968.56707.356706.517149@tutpro.com>
Date: Thu, 26 Apr 2007 20:12:35 +0300
To: Thomas Froment <Thomas.Froment@alcatel-lucent.fr>
Subject: Re: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
In-Reply-To: <4630D67D.2070700@alcatel-lucent.fr>
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
	<17968.52760.363575.469609@tutpro.com>
	<4630D67D.2070700@alcatel-lucent.fr>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: "Peterson, Jon" <jon.peterson@neustar.biz>, sip@ietf.org,
	Francois Audet <audet@nortel.com>, Keith Drage <drage@alcatel-lucent.com>,
	Dean Willis <dean.willis@softarmor.com>,
	Alan Johnston <alan@sipstation.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Thomas Froment writes:

 > --> Multiple questions need clarifications here, because people want
 > to be able to switch from one transport to another, use numeric ip
 > addresses, and still make the RR work. So, that's why I explained a
 > typical "workaround"  is to put a transport parameter on the RR. (if
 > the proxy decides to make RR rewriting, it will put just one RR with
 > the transport used to reach the next element, and when seeing the 200
 > OK response, change that transport to the transport used with the
 > previous element.
 > It explains you why I said that the "Route set seen by the callee
 > will be different than the Route Set seen by the callee" when
 > rewriting.
 > Double Record-Routing does not solve that problem at all, this is
 > still a topic to be discussed, and I am open to any suggestion about
 > this issue.

thanks for the explanation.  today at least openser (which is a VERY
popular sip proxy), does double rr if transport protocol changes, for
example:

Record-Route:<sip:192.98.101.10;transport=TCP;r2=on>,<sip:192.98.101.10;r2=on>

is also uses transport=tls no matter if it is deprecated or not.

but isn't this a local matter within a proxy, i.e., why should anybody
else care?

-- juha


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 13:25:20 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hh7iY-00008P-Eq; Thu, 26 Apr 2007 13:25:18 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hh7iW-00008G-JA
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 13:25:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh7iW-00007W-9G
	for sip@ietf.org; Thu, 26 Apr 2007 13:25:16 -0400
Received: from smail5.alcatel.fr ([64.208.49.27])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh7iU-0004HS-TX
	for sip@ietf.org; Thu, 26 Apr 2007 13:25:16 -0400
Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com
	[155.132.6.79])
	by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l3QHOFQC014288; 
	Thu, 26 Apr 2007 19:24:15 +0200
Received: from [139.54.131.75] ([139.54.131.75]) by
	FRVELSBHS07.ad2.ad.alcatel.com over TLS secured channel with
	Microsoft SMTPSVC(6.0.3790.2499); Thu, 26 Apr 2007 19:25:15 +0200
Message-ID: <4630E07C.2010300@alcatel-lucent.fr>
Date: Thu, 26 Apr 2007 19:25:16 +0200
From: Thomas Froment <Thomas.Froment@alcatel-lucent.fr>
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: Juha Heinanen <jh@tutpro.com>, sip@ietf.org
Subject: Re: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>	<462F613C.2050502@sipstation.com>	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>	<17968.16340.800200.535818@tutpro.com>	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>	<17968.52760.363575.469609@tutpro.com>	<4630D67D.2070700@alcatel-lucent.fr>
	<17968.56707.356706.517149@tutpro.com>
In-Reply-To: <17968.56707.356706.517149@tutpro.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Apr 2007 17:25:15.0603 (UTC)
	FILETIME=[DA9AD230:01C78827]
X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


> but isn't this a local matter within a proxy, i.e., why should anybody
> else care?
>   
RR is for sure the matter of SIP proxies, and the question you asked on 
UDP to TLS case is a question that many implementors had one day or another.
Sometimes it raises interoperability problems by making UAs change their 
transport betwen initial and subsequent requests, generally asking the 
proxy implementor: "why the hell you don't put any transport on your 
record route since I contacted you using TCP?"...
So, if the BCP is useful for SIP proxy developers, this is still 
something...
Moreover, it happens that implementations choose bad work-arounds to 
bypass it, for instance by keeping the same transport for the whole 
duration of a dialog (in UAs), whatever the route or RFC3263 says...
Finally, I would like to go back to my initial poll who did not get any 
answer:
who would like to deprecate RR rewriting?
who want to keep it?
who care? ;-)

Regards,
Thomas



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 13:33:25 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hh7qN-00025d-ED; Thu, 26 Apr 2007 13:33:23 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hh7qM-00025W-Ae
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 13:33:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh7qM-00025N-18
	for sip@ietf.org; Thu, 26 Apr 2007 13:33:22 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh7qK-0005e9-Nv
	for sip@ietf.org; Thu, 26 Apr 2007 13:33:22 -0400
Received: from [192.168.2.103] (sj-natpool-220.cisco.com [128.107.248.220])
	(authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3QGe9YQ021922
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 26 Apr 2007 11:40:10 -0500
In-Reply-To: <4630E07C.2010300@alcatel-lucent.fr>
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>	<462F613C.2050502@sipstation.com>	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>	<17968.16340.800200.535818@tutpro.com>	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>	<17968.52760.363575.469609@tutpro.com>	<4630D67D.2070700@alcatel-lucent.fr>
	<17968.56707.356706.517149@tutpro.com>
	<4630E07C.2010300@alcatel-lucent.fr>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <D07E95E8-6F0A-4F70-BF7B-2C761E2745B6@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Deprecate RR rewriting? (was Re: [Sip] draft-ietf-sip-sips-03.txt:
	Closing of Opened issues)
Date: Thu, 26 Apr 2007 12:33:02 -0500
To: Thomas Froment <Thomas.Froment@alcatel-lucent.fr>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: sip@ietf.org, Juha Heinanen <jh@tutpro.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 26, 2007, at 12:25 PM, Thomas Froment wrote:

> who would like to deprecate RR rewriting?
> who want to keep it?
> who care? ;-)
>

RR rewriting makes my head hurt, and I always mess up examples that  
use it.

Therefore, I'm in favor of not using it.

--
Dean





_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 13:33:42 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hh7qe-0002YB-C7; Thu, 26 Apr 2007 13:33:40 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hh7qd-0002XK-19
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 13:33:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh7qc-0002X1-Ns
	for sip@ietf.org; Thu, 26 Apr 2007 13:33:38 -0400
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh7qb-0005g7-DJ
	for sip@ietf.org; Thu, 26 Apr 2007 13:33:38 -0400
Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121])
	(authenticated bits=0)
	by nostrum.com (8.13.8/8.13.8) with ESMTP id l3QHXU6T031635
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 26 Apr 2007 12:33:30 -0500 (CDT)
	(envelope-from rjsparks@nostrum.com)
In-Reply-To: <4630E07C.2010300@alcatel-lucent.fr>
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>	<462F613C.2050502@sipstation.com>	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>	<17968.16340.800200.535818@tutpro.com>	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>	<17968.52760.363575.469609@tutpro.com>	<4630D67D.2070700@alcatel-lucent.fr>
	<17968.56707.356706.517149@tutpro.com>
	<4630E07C.2010300@alcatel-lucent.fr>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <419EC6C3-EF4A-4DEC-A52D-CA8CF0A8B206@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Date: Thu, 26 Apr 2007 12:33:28 -0500
To: Thomas Froment <Thomas.Froment@alcatel-lucent.fr>
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
	mechanism)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: sip@ietf.org, Juha Heinanen <jh@tutpro.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Thomas -

Sorry for not directly answering this question earlier.

My position is to not deprecate rewriting.

I do think rewriting is overall a bad idea and that double-RR is a  
much saner approach, and your document does a good job of explaining  
why.
But there are simple environments where rewriting is working in the  
field. I don't see the benefit of making what they're currently doing  
a violation
of the protocol at the moment. Showing them better ways, seeing  
everyone implement them, and later deprecating the behavior seems the  
more
effective way to proceed.

That said, I don't feel strongly about this and I certainly won't  
fight to keep rewriting around.

RjS

On Apr 26, 2007, at 12:25 PM, Thomas Froment wrote:

>
>> but isn't this a local matter within a proxy, i.e., why should  
>> anybody
>> else care?
>>
> RR is for sure the matter of SIP proxies, and the question you  
> asked on UDP to TLS case is a question that many implementors had  
> one day or another.
> Sometimes it raises interoperability problems by making UAs change  
> their transport betwen initial and subsequent requests, generally  
> asking the proxy implementor: "why the hell you don't put any  
> transport on your record route since I contacted you using TCP?"...
> So, if the BCP is useful for SIP proxy developers, this is still  
> something...
> Moreover, it happens that implementations choose bad work-arounds  
> to bypass it, for instance by keeping the same transport for the  
> whole duration of a dialog (in UAs), whatever the route or RFC3263  
> says...
> Finally, I would like to go back to my initial poll who did not get  
> any answer:
> who would like to deprecate RR rewriting?
> who want to keep it?
> who care? ;-)
>
> Regards,
> Thomas
>
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 13:43:20 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hh7zw-0002UC-Hb; Thu, 26 Apr 2007 13:43:16 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hh7zv-0002Pt-CA
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 13:43:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh7zv-0002O3-1f
	for sip@ietf.org; Thu, 26 Apr 2007 13:43:15 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh7zt-0007nW-Kx
	for sip@ietf.org; Thu, 26 Apr 2007 13:43:15 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id C7E001EC02E;
	Thu, 26 Apr 2007 20:43:12 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id jPBuaVmeGsds; Thu, 26 Apr 2007 20:43:10 +0300 (EEST)
Received: from taimen (primer189.gprs.dnafinland.fi [62.78.125.189])
	by tutpro.com (Postfix) with ESMTP;
	Thu, 26 Apr 2007 20:43:10 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id 1B57BAC122; Thu, 26 Apr 2007 20:43:05 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17968.58537.70471.74671@tutpro.com>
Date: Thu, 26 Apr 2007 20:43:05 +0300
To: Thomas Froment <Thomas.Froment@alcatel-lucent.fr>
Subject: Re: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
In-Reply-To: <4630E07C.2010300@alcatel-lucent.fr>
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
	<17968.52760.363575.469609@tutpro.com>
	<4630D67D.2070700@alcatel-lucent.fr>
	<17968.56707.356706.517149@tutpro.com>
	<4630E07C.2010300@alcatel-lucent.fr>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Thomas Froment writes:

 > RR is for sure the matter of SIP proxies, and the question you asked on 
 > UDP to TLS case is a question that many implementors had one day or
 > another.

i meant why would someone care if proxy does single or double rr,
because UAs only deal with the topmost one and have no way of knowing if
a proxy double rr'ed or not.  same for other proxies.

 > Sometimes it raises interoperability problems by making UAs change their 
 > transport betwen initial and subsequent requests, generally asking the 
 > proxy implementor: "why the hell you don't put any transport on your 
 > record route since I contacted you using TCP?"...

this is not related to double or single rr, but if transport parameter
is added or not.

 > So, if the BCP is useful for SIP proxy developers, this is still 
 > something...

yes.

 > who would like to deprecate RR rewriting?
 > who want to keep it?
 > who care? ;-)

where is rr re-writing specified so that it could be deprecated?  

as i told double rr is widely used in real deployments and we haven't
noticed any major problems.  so if it is not really broken i don't see
any reason to fit it.

-- juha


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 13:46:37 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hh83B-00071E-5w; Thu, 26 Apr 2007 13:46:37 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hh83A-000719-Jl
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 13:46:36 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh83A-00070z-AE
	for sip@ietf.org; Thu, 26 Apr 2007 13:46:36 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh838-0008NN-VL
	for sip@ietf.org; Thu, 26 Apr 2007 13:46:36 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id 5C7141EC02E;
	Thu, 26 Apr 2007 20:46:34 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 2FVR6GGYyUo8; Thu, 26 Apr 2007 20:46:32 +0300 (EEST)
Received: from taimen (primer189.gprs.dnafinland.fi [62.78.125.189])
	by tutpro.com (Postfix) with ESMTP;
	Thu, 26 Apr 2007 20:46:32 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id 3F29BAC122; Thu, 26 Apr 2007 20:46:27 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17968.58739.220882.733487@tutpro.com>
Date: Thu, 26 Apr 2007 20:46:27 +0300
To: "Francois Audet" <audet@nortel.com>
Subject: RE: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Cc: sip@ietf.org, Alan Johnston <alan@sipstation.com>,
	Keith Drage <drage@alcatel-lucent.com>, "Peterson, 
	Jon" <jon.peterson@neustar.biz>, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Francois Audet writes:

 > So: to summarize, with the current draft, the double record-route
 > procedures are never used.

but as i mentioned in another message, they ARE currently heavily used.
i don't see a point in writing yet another ietf draft that has no
bearing to the real world.

-- juha


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 14:11:10 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hh8Qs-0000Hf-Qt; Thu, 26 Apr 2007 14:11:06 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hh8Qr-0000HZ-B0
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 14:11:05 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh8Qr-0000HR-03
	for sip@ietf.org; Thu, 26 Apr 2007 14:11:05 -0400
Received: from zrtps0kn.nortel.com ([47.140.192.55])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hh8Qp-0002e7-KA
	for sip@ietf.org; Thu, 26 Apr 2007 14:11:04 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3QIAxQ28024; Thu, 26 Apr 2007 18:10:59 GMT
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: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Date: Thu, 26 Apr 2007 13:10:39 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF1032A6D8@zrc2hxm0.corp.nortel.com>
In-Reply-To: <17968.58739.220882.733487@tutpro.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Thread-Index: AceIKuS6h3nv8whrQNCkfAHDWF6jOAAAx0dw
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
	<17968.58739.220882.733487@tutpro.com>
From: "Francois Audet" <audet@nortel.com>
To: "Juha Heinanen" <jh@tutpro.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: sip@ietf.org, Keith Drage <drage@alcatel-lucent.com>,
	Alan Johnston <alan@sipstation.com>, "Peterson,
	Jon" <jon.peterson@neustar.biz>, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

You CAN use Double record-route. It doesn't break anything.

This draft does not make any use of it.

I don't understand your poin

Please make concretre point as oppose to rethorical ones.=20

> -----Original Message-----
> From: Juha Heinanen [mailto:jh@tutpro.com]=20
> Sent: Thursday, April 26, 2007 10:46
> To: Audet, Francois (SC100:3055)
> Cc: sip@ietf.org; Alan Johnston; Keith Drage; Peterson, Jon;=20
> Dean Willis
> Subject: RE: [Sip] draft-ietf-sip-sips-03.txt: Closing of=20
> Opened issues
>=20
> Francois Audet writes:
>=20
>  > So: to summarize, with the current draft, the double=20
> record-route  > procedures are never used.
>=20
> but as i mentioned in another message, they ARE currently=20
> heavily used.
> i don't see a point in writing yet another ietf draft that=20
> has no bearing to the real world.
>=20
> -- juha
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 14:11:21 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hh8R7-0000bl-IG; Thu, 26 Apr 2007 14:11:21 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hh8R6-0000bc-JX
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 14:11:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh8R6-0000bP-9g
	for sip@ietf.org; Thu, 26 Apr 2007 14:11:20 -0400
Received: from zrtps0kp.nortel.com ([47.140.192.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh8R5-0008DB-0k
	for sip@ietf.org; Thu, 26 Apr 2007 14:11:20 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3QIBFn11147; Thu, 26 Apr 2007 18:11:15 GMT
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: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Date: Thu, 26 Apr 2007 13:11:14 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF1032A6DE@zrc2hxm0.corp.nortel.com>
In-Reply-To: <17968.56456.143583.490518@tutpro.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Thread-Index: AceIJZWBGsKJdHCXQ/ag7y1B9MgTGwACK8bg
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
	<17968.52760.363575.469609@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A4E0@zrc2hxm0.corp.nortel.com>
	<17968.56456.143583.490518@tutpro.com>
From: "Francois Audet" <audet@nortel.com>
To: "Juha Heinanen" <jh@tutpro.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: sip@ietf.org, Alan Johnston <alan@sipstation.com>,
	Keith Drage <drage@alcatel-lucent.com>, "Peterson,
	Jon" <jon.peterson@neustar.biz>, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Yes.=20

> -----Original Message-----
> From: Juha Heinanen [mailto:jh@tutpro.com]=20
> Sent: Thursday, April 26, 2007 10:08
> To: Audet, Francois (SC100:3055)
> Cc: sip@ietf.org; Keith Drage; Alan Johnston; Peterson, Jon;=20
> Dean Willis
> Subject: RE: [Sip] draft-ietf-sip-sips-03.txt: Closing of=20
> Opened issues
>=20
> Francois Audet writes:
>=20
>  > Then, only the VIA headers are affected. No impact=20
> whatsoever on  > Record-Route and Request-URI as it is still=20
> sip: to sip:=20
>=20
> and according to rfc 3261 20.42 via will contain SIP/2.0/TLS, right?
>=20
> -- juha
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 14:13:08 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hh8Sq-00044W-3t; Thu, 26 Apr 2007 14:13:08 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hh8So-00044Q-DR
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 14:13:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh8So-00044F-3g
	for sip@ietf.org; Thu, 26 Apr 2007 14:13:06 -0400
Received: from zrtps0kp.nortel.com ([47.140.192.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh8Sn-00009V-SL
	for sip@ietf.org; Thu, 26 Apr 2007 14:13:06 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3QICwn11469; Thu, 26 Apr 2007 18:12:59 GMT
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: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Date: Thu, 26 Apr 2007 13:12:58 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF1032A6E8@zrc2hxm0.corp.nortel.com>
In-Reply-To: <17968.56707.356706.517149@tutpro.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Thread-Index: AceIJhrVKx8MojioQZaj8IY4hhg+QwACDjkA
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
	<17968.52760.363575.469609@tutpro.com>
	<4630D67D.2070700@alcatel-lucent.fr>
	<17968.56707.356706.517149@tutpro.com>
From: "Francois Audet" <audet@nortel.com>
To: "Juha Heinanen" <jh@tutpro.com>,
	"Thomas Froment" <Thomas.Froment@alcatel-lucent.fr>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: sip@ietf.org, Keith Drage <drage@alcatel-lucent.com>,
	Alan Johnston <alan@sipstation.com>, "Peterson,
	Jon" <jon.peterson@neustar.biz>, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

It's ok to use it (the transport parameter and double record-route).

It just means that your are RESTRICTING how you can be reached (i.e.,
you are foccing a specific transport).

> -----Original Message-----
> From: Juha Heinanen [mailto:jh@tutpro.com]=20
> Sent: Thursday, April 26, 2007 10:13
> To: Thomas Froment
> Cc: sip@ietf.org; Alan Johnston; Audet, Francois=20
> (SC100:3055); Keith Drage; Peterson, Jon; Dean Willis
> Subject: Re: [Sip] draft-ietf-sip-sips-03.txt: Closing of=20
> Opened issues
>=20
> Thomas Froment writes:
>=20
>  > --> Multiple questions need clarifications here, because=20
> people want  > to be able to switch from one transport to=20
> another, use numeric ip  > addresses, and still make the RR=20
> work. So, that's why I explained a  > typical "workaround" =20
> is to put a transport parameter on the RR. (if  > the proxy=20
> decides to make RR rewriting, it will put just one RR with  >=20
> the transport used to reach the next element, and when seeing=20
> the 200  > OK response, change that transport to the=20
> transport used with the  > previous element.
>  > It explains you why I said that the "Route set seen by the=20
> callee  > will be different than the Route Set seen by the=20
> callee" when  > rewriting.
>  > Double Record-Routing does not solve that problem at all,=20
> this is  > still a topic to be discussed, and I am open to=20
> any suggestion about  > this issue.
>=20
> thanks for the explanation.  today at least openser (which is=20
> a VERY popular sip proxy), does double rr if transport=20
> protocol changes, for
> example:
>=20
> Record-Route:<sip:192.98.101.10;transport=3DTCP;r2=3Don>,<sip:192.
> 98.101.10;r2=3Don>
>=20
> is also uses transport=3Dtls no matter if it is deprecated or not.
>=20
> but isn't this a local matter within a proxy, i.e., why=20
> should anybody else care?
>=20
> -- juha
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 14:35:11 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hh8oA-0004Sx-C6; Thu, 26 Apr 2007 14:35:10 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hh8o8-0004Qa-Td
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 14:35:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh8o8-0004QS-7D
	for sip@ietf.org; Thu, 26 Apr 2007 14:35:08 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh8o5-0005oc-Rw
	for sip@ietf.org; Thu, 26 Apr 2007 14:35:08 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id 248BC1EC02E;
	Thu, 26 Apr 2007 21:35:05 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id yDU7P-L1HYb1; Thu, 26 Apr 2007 21:35:03 +0300 (EEST)
Received: from taimen (guanine49.gprs.dnafinland.fi [62.78.120.49])
	by tutpro.com (Postfix) with ESMTP;
	Thu, 26 Apr 2007 21:35:03 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id E4C8EAC127; Thu, 26 Apr 2007 21:34:56 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17968.61648.893419.784702@tutpro.com>
Date: Thu, 26 Apr 2007 21:34:56 +0300
To: "Francois Audet" <audet@nortel.com>
Subject: RE: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1032A6D8@zrc2hxm0.corp.nortel.com>
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
	<17968.58739.220882.733487@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A6D8@zrc2hxm0.corp.nortel.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: sip@ietf.org, Keith Drage <drage@alcatel-lucent.com>,
	Alan Johnston <alan@sipstation.com>, "Peterson,
	Jon" <jon.peterson@neustar.biz>, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Francois Audet writes:

 > You CAN use Double record-route. It doesn't break anything.
 > 
 > This draft does not make any use of it.

ok, sorry, i misunderstood your reply.

by the way, why does your sips draft say that transport=tls is
deprecated when uri scheme is NOT sips?  please clean your draft of
EVERYTHING that is not strictly related to use of sips uri scheme.

in real life transport=tls is NOT deprecated.  also, in my opinion, if
tls can be used in via header, it should also be usable as transport
parameter value.

tell me, why is tls (instead of tcp) needed in via when uri scheme is
sips?  cannot tls/tcp be concluded if transport is tcp and uri scheme is
sips.

-- juha


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 14:38:11 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hh8r4-0006fL-Qn; Thu, 26 Apr 2007 14:38:10 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hh8r2-0006fE-Q8
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 14:38:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh8r2-0006f5-GX
	for sip@ietf.org; Thu, 26 Apr 2007 14:38:08 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh8r0-0006CX-Qi
	for sip@ietf.org; Thu, 26 Apr 2007 14:38:08 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3QIc3X17900; Thu, 26 Apr 2007 18:38:03 GMT
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: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Date: Thu, 26 Apr 2007 13:38:02 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF1032A76E@zrc2hxm0.corp.nortel.com>
In-Reply-To: <17968.61648.893419.784702@tutpro.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Thread-Index: AceIMZ3eyN4Qb8hLTrint7uV4nL//gAAEZxw
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
	<17968.58739.220882.733487@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A6D8@zrc2hxm0.corp.nortel.com>
	<17968.61648.893419.784702@tutpro.com>
From: "Francois Audet" <audet@nortel.com>
To: "Juha Heinanen" <jh@tutpro.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: sip@ietf.org, Keith Drage <drage@alcatel-lucent.com>,
	Alan Johnston <alan@sipstation.com>, "Peterson,
	Jon" <jon.peterson@neustar.biz>, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

It is RFC 3261 that deprecated transport=3Dtls, not my draft.

The reason why my draft talks about it is that, as you mention, it
is clearly something that was missed in the industry, causing=20
interoperability problems.=20

> -----Original Message-----
> From: Juha Heinanen [mailto:jh@tutpro.com]=20
> Sent: Thursday, April 26, 2007 11:35
> To: Audet, Francois (SC100:3055)
> Cc: sip@ietf.org; Alan Johnston; Keith Drage; Peterson, Jon;=20
> Dean Willis
> Subject: RE: [Sip] draft-ietf-sip-sips-03.txt: Closing of=20
> Opened issues
>=20
> Francois Audet writes:
>=20
>  > You CAN use Double record-route. It doesn't break anything.
>  >
>  > This draft does not make any use of it.
>=20
> ok, sorry, i misunderstood your reply.
>=20
> by the way, why does your sips draft say that transport=3Dtls=20
> is deprecated when uri scheme is NOT sips?  please clean your=20
> draft of EVERYTHING that is not strictly related to use of=20
> sips uri scheme.
>=20
> in real life transport=3Dtls is NOT deprecated.  also, in my=20
> opinion, if tls can be used in via header, it should also be=20
> usable as transport parameter value.
>=20
> tell me, why is tls (instead of tcp) needed in via when uri=20
> scheme is sips?  cannot tls/tcp be concluded if transport is=20
> tcp and uri scheme is sips.
>=20
> -- juha
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 14:44:25 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hh8x4-0000TQ-9r; Thu, 26 Apr 2007 14:44:22 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hh8x3-0000TL-0c
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 14:44:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh8x2-0000TD-NP
	for sip@ietf.org; Thu, 26 Apr 2007 14:44:20 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh8wx-0007WK-9Z
	for sip@ietf.org; Thu, 26 Apr 2007 14:44:20 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id 50E591EC02E;
	Thu, 26 Apr 2007 21:44:14 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id xShAlO8heydQ; Thu, 26 Apr 2007 21:44:12 +0300 (EEST)
Received: from taimen (guanine49.gprs.dnafinland.fi [62.78.120.49])
	by tutpro.com (Postfix) with ESMTP;
	Thu, 26 Apr 2007 21:44:12 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id 1DA2DAC122; Thu, 26 Apr 2007 21:44:07 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17968.62199.85993.436912@tutpro.com>
Date: Thu, 26 Apr 2007 21:44:07 +0300
To: "Francois Audet" <audet@nortel.com>
Subject: RE: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1032A76E@zrc2hxm0.corp.nortel.com>
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
	<17968.58739.220882.733487@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A6D8@zrc2hxm0.corp.nortel.com>
	<17968.61648.893419.784702@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A76E@zrc2hxm0.corp.nortel.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: sip@ietf.org, Keith Drage <drage@alcatel-lucent.com>,
	Alan Johnston <alan@sipstation.com>, "Peterson,
	Jon" <jon.peterson@neustar.biz>, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Francois Audet writes:

 > It is RFC 3261 that deprecated transport=tls, not my draft.

yes, but as i told, transport=tls is heavily used for good reasons and
if might make sense to deprecate the deprecation.  if you want to bring
the issue up in your draft, we can also make that change (since the
draft makes changed anyway).

 > The reason why my draft talks about it is that, as you mention, it
 > is clearly something that was missed in the industry, causing 
 > interoperability problems. 

no, it was not missed by the industry.  industry is not that stupid.
transport=tls is used, because there is VALUE in using it.

-- juha


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 14:47:18 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hh8zt-0006bi-Qn; Thu, 26 Apr 2007 14:47:17 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hh8zs-0006W9-8k
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 14:47:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh8zr-0006UL-Tx
	for sip@ietf.org; Thu, 26 Apr 2007 14:47:15 -0400
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh8zq-0008Ft-MH
	for sip@ietf.org; Thu, 26 Apr 2007 14:47:15 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	l3QIkUh28560; Thu, 26 Apr 2007 18:46:30 GMT
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: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Date: Thu, 26 Apr 2007 13:47:08 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF1032A7A0@zrc2hxm0.corp.nortel.com>
In-Reply-To: <17968.62199.85993.436912@tutpro.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Thread-Index: AceIMuTUxsJQECAwQQ6TfMYNHigNugAABR1A
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
	<17968.58739.220882.733487@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A6D8@zrc2hxm0.corp.nortel.com>
	<17968.61648.893419.784702@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A76E@zrc2hxm0.corp.nortel.com>
	<17968.62199.85993.436912@tutpro.com>
From: "Francois Audet" <audet@nortel.com>
To: "Juha Heinanen" <jh@tutpro.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: sip@ietf.org, Keith Drage <drage@alcatel-lucent.com>,
	Alan Johnston <alan@sipstation.com>, "Peterson,
	Jon" <jon.peterson@neustar.biz>, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Actually, it offers no value. It just makes it more likely that it will
fail.

We've been through this already. You know that a UAC supports TLS by the
fact
that it used TLS to register. It's the "implicit indication".=20

The draft however tells you how to be backward compatible with UAs that=20
use transport=3Dtls.

> -----Original Message-----
> From: Juha Heinanen [mailto:jh@tutpro.com]=20
> Sent: Thursday, April 26, 2007 11:44
> To: Audet, Francois (SC100:3055)
> Cc: sip@ietf.org; Alan Johnston; Keith Drage; Peterson, Jon;=20
> Dean Willis
> Subject: RE: [Sip] draft-ietf-sip-sips-03.txt: Closing of=20
> Opened issues
>=20
> Francois Audet writes:
>=20
>  > It is RFC 3261 that deprecated transport=3Dtls, not my draft.
>=20
> yes, but as i told, transport=3Dtls is heavily used for good=20
> reasons and if might make sense to deprecate the deprecation.=20
>  if you want to bring the issue up in your draft, we can also=20
> make that change (since the draft makes changed anyway).
>=20
>  > The reason why my draft talks about it is that, as you=20
> mention, it  > is clearly something that was missed in the=20
> industry, causing  > interoperability problems.=20
>=20
> no, it was not missed by the industry.  industry is not that stupid.
> transport=3Dtls is used, because there is VALUE in using it.
>=20
> -- juha
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 14:54:08 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hh96W-00074v-7a; Thu, 26 Apr 2007 14:54:08 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hh96V-00074q-DL
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 14:54:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh96V-00074i-3t
	for sip@ietf.org; Thu, 26 Apr 2007 14:54:07 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh96T-0001gA-PH
	for sip@ietf.org; Thu, 26 Apr 2007 14:54:07 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id 3356B1EC02E;
	Thu, 26 Apr 2007 21:54:05 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id Y9Ijg62jdeIp; Thu, 26 Apr 2007 21:54:03 +0300 (EEST)
Received: from taimen (guanine49.gprs.dnafinland.fi [62.78.120.49])
	by tutpro.com (Postfix) with ESMTP;
	Thu, 26 Apr 2007 21:54:03 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id E01C7AC122; Thu, 26 Apr 2007 21:53:57 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17968.62789.879601.53963@tutpro.com>
Date: Thu, 26 Apr 2007 21:53:57 +0300
To: "Francois Audet" <audet@nortel.com>
Subject: RE: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1032A7A0@zrc2hxm0.corp.nortel.com>
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
	<17968.58739.220882.733487@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A6D8@zrc2hxm0.corp.nortel.com>
	<17968.61648.893419.784702@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A76E@zrc2hxm0.corp.nortel.com>
	<17968.62199.85993.436912@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A7A0@zrc2hxm0.corp.nortel.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: sip@ietf.org, Keith Drage <drage@alcatel-lucent.com>,
	Alan Johnston <alan@sipstation.com>, "Peterson,
	Jon" <jon.peterson@neustar.biz>, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Francois Audet writes:

 > We've been through this already. You know that a UAC supports TLS by the
 > fact that it used TLS to register. It's the "implicit indication".

my example dealt with proxy-to-proxy communication.

 > The draft however tells you how to be backward compatible with UAs that 
 > use transport=tls.

how about proxies?

you still have not answered my question why in your world is tls needed
in via header instead of just tcp.

-- juha


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 14:58:38 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hh9Ap-0002oj-CS; Thu, 26 Apr 2007 14:58:35 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hh9An-0002od-UB
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 14:58:33 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh9An-0002oV-Kk
	for sip@ietf.org; Thu, 26 Apr 2007 14:58:33 -0400
Received: from zrtps0kn.nortel.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh9Am-0002W2-BZ
	for sip@ietf.org; Thu, 26 Apr 2007 14:58:33 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3QIwTQ06559; Thu, 26 Apr 2007 18:58:29 GMT
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: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Date: Thu, 26 Apr 2007 13:58:18 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E6127CFF11@zrc2hxm2.corp.nortel.com>
In-Reply-To: <17968.62199.85993.436912@tutpro.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Thread-Index: AceIMu2eOoksGQn9Q2qUm7ktQL85eAAACwLQ
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Juha Heinanen" <jh@tutpro.com>, "Francois Audet" <audet@nortel.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: sip@ietf.org, Alan Johnston <alan@sipstation.com>,
	Keith Drage <drage@alcatel-lucent.com>, "Peterson,
	Jon" <jon.peterson@neustar.biz>, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Another wacky thread developing. Do we need more evidence ? It's better
to realize SIPS is dead-end.

It may be far fetched idea, Cost of Dealing with two URI (SIP/SIPS) for
printing on Business Cards, SIP Directories etc. etc...  for coming
generations to use it ... Where we can deal with single URI. Vendors who
have implemented, I request you to give up, and let us work on the clean
complete solution...=20

This thread is just talking about TLS. What about DTLS ? SIPS is broken
with respect to secure protocol development. It is no future proof
there.  People who don't buy future proofing, looks to me they wrote the
software with Y2K bug.

Thx
Samir

PS: Sorry Dean, I cannot check my temptation on the hunting as dog is
barking again and again.

>-----Original Message-----
>From: Juha Heinanen [mailto:jh@tutpro.com]=20
>Sent: Thursday, April 26, 2007 11:44 AM
>To: Audet, Francois (SC100:3055)
>Cc: sip@ietf.org; Keith Drage; Alan Johnston; Peterson, Jon;=20
>Dean Willis
>Subject: RE: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
>
>Francois Audet writes:
>
> > It is RFC 3261 that deprecated transport=3Dtls, not my draft.
>
>yes, but as i told, transport=3Dtls is heavily used for good=20
>reasons and if might make sense to deprecate the deprecation. =20
>if you want to bring the issue up in your draft, we can also=20
>make that change (since the draft makes changed anyway).
>
> > The reason why my draft talks about it is that, as you=20
>mention, it  > is clearly something that was missed in the=20
>industry, causing  > interoperability problems.=20
>
>no, it was not missed by the industry.  industry is not that stupid.
>transport=3Dtls is used, because there is VALUE in using it.
>
>-- juha
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol Use=20
>sip-implementors@cs.columbia.edu for questions on current sip=20
>Use sipping@ietf.org for new developments on the application of sip
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 16:24:10 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhAVW-0008Bj-5S; Thu, 26 Apr 2007 16:24:02 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhAVU-0008BR-Is
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 16:24:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhAVU-0008BE-9B
	for sip@ietf.org; Thu, 26 Apr 2007 16:24:00 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhAVS-0004Ei-Uh
	for sip@ietf.org; Thu, 26 Apr 2007 16:24:00 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id B57CF1EC02E
	for <sip@ietf.org>; Thu, 26 Apr 2007 23:23:57 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id b6W+uQ0dAekR for <sip@ietf.org>;
	Thu, 26 Apr 2007 23:23:54 +0300 (EEST)
Received: from taimen (isozyme67.gprs.dnafinland.fi [62.78.107.67])
	by tutpro.com (Postfix) with ESMTP
	for <sip@ietf.org>; Thu, 26 Apr 2007 23:23:54 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id 9221BAC122; Thu, 26 Apr 2007 23:23:47 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17969.2643.95877.839771@tutpro.com>
Date: Thu, 26 Apr 2007 23:23:47 +0300
To: sip@ietf.org
Subject: RE: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Francois Audet wrote:

  We've been through this already. You know that a UAC supports TLS by
  the fact that it used TLS to register. It's the "implicit
  indication". 

UAC does not need to register in order to be able to SEND requests.  

so UAC sends initial request over tls via its proxy (an possibly other
proxies) to UAS and then bye comes from the UAS 2 hours later.  how does
the proxy know that it should forward bye to UAC over tls if there is no
transport=tls parameter anywhere?

-- juha


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 17:03:09 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhB7G-00018f-UQ; Thu, 26 Apr 2007 17:03:02 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhB7F-00018O-3X
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 17:03:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhB7E-00018B-QD
	for sip@ietf.org; Thu, 26 Apr 2007 17:03:00 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhB7D-0004su-GN
	for sip@ietf.org; Thu, 26 Apr 2007 17:03:00 -0400
Received: from [192.168.2.103] (rcdn4-dmznat-gw1-nat-27.cisco.com
	[12.5.186.27]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3QK9pms023125
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 26 Apr 2007 15:09:51 -0500
In-Reply-To: <17968.58537.70471.74671@tutpro.com>
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
	<17968.52760.363575.469609@tutpro.com>
	<4630D67D.2070700@alcatel-lucent.fr>
	<17968.56707.356706.517149@tutpro.com>
	<4630E07C.2010300@alcatel-lucent.fr>
	<17968.58537.70471.74671@tutpro.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <4D541C44-D3D8-412B-AA3B-0389DDD12E16@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Date: Thu, 26 Apr 2007 16:02:43 -0500
To: Juha Heinanen <jh@tutpro.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 26, 2007, at 12:43 PM, Juha Heinanen wrote:

> Thomas Froment writes:
>
>> RR is for sure the matter of SIP proxies, and the question you  
>> asked on
>> UDP to TLS case is a question that many implementors had one day or
>> another.
>
> i meant why would someone care if proxy does single or double rr,
> because UAs only deal with the topmost one and have no way of  
> knowing if
> a proxy double rr'ed or not.  same for other proxies.
>

If you're trying to invert a recorded route for use in a service- 
route, the lack of reversibility induced by rewriting breaks things.

So this is NOT just an in-the-proxy issue. Double recording is more  
likely to make things work.

--
Dean


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 17:09:49 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhBDo-0004Er-QE; Thu, 26 Apr 2007 17:09:48 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhBDn-000489-B5
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 17:09:47 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhBDn-00046H-0O
	for sip@ietf.org; Thu, 26 Apr 2007 17:09:47 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HhBDl-0006oM-Le
	for sip@ietf.org; Thu, 26 Apr 2007 17:09:46 -0400
Received: from [192.168.2.103] (rcdn4-dmznat-gw1-nat-27.cisco.com
	[12.5.186.27]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3QKGd9X023194
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 26 Apr 2007 15:16:39 -0500
In-Reply-To: <17968.61648.893419.784702@tutpro.com>
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
	<17968.58739.220882.733487@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A6D8@zrc2hxm0.corp.nortel.com>
	<17968.61648.893419.784702@tutpro.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <05650EF6-4740-4F00-97AF-AA180402AC1E@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Date: Thu, 26 Apr 2007 16:09:31 -0500
To: Juha Heinanen <jh@tutpro.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: sip@ietf.org, Keith Drage <drage@alcatel-lucent.com>,
	Francois Audet <audet@nortel.com>,
	Alan Johnston <alan@sipstation.com>, "Peterson,
	Jon" <jon.peterson@neustar.biz>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 26, 2007, at 1:34 PM, Juha Heinanen wrote:


>
> in real life transport=tls is NOT deprecated.  also, in my opinion, if
> tls can be used in via header, it should also be usable as transport
> parameter value.
>

There's enough of a consensus that it's just going to be that way.  
I'm sorry you disagree. You may very well be perfectly correct, but  
after a whole lot of discussion, the working group decided to deprecate.

In this working group, transport=tls IS deprecated. Whether or not  
that affects real-life remains to be seen, but I'd bet that it  
eventually will.


> tell me, why is tls (instead of tcp) needed in via when uri scheme is
> sips?  cannot tls/tcp be concluded if transport is tcp and uri  
> scheme is
> sips.

I've always wondered about this one myself. What about TLS/SCTP and  
DTLS, which might serve as transports for SIPS?

--
Dean


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 17:13:51 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhBHi-0008A9-Oa; Thu, 26 Apr 2007 17:13:50 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhBHh-0008A4-G7
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 17:13:49 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhBHh-00089w-65
	for sip@ietf.org; Thu, 26 Apr 2007 17:13:49 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HhBHf-0007RX-QD
	for sip@ietf.org; Thu, 26 Apr 2007 17:13:49 -0400
Received: from [192.168.2.103] (rcdn4-dmznat-gw1-nat-27.cisco.com
	[12.5.186.27]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3QKKhAC023223
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 26 Apr 2007 15:20:44 -0500
In-Reply-To: <17969.2643.95877.839771@tutpro.com>
References: <17969.2643.95877.839771@tutpro.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <7D0628DD-CC2A-42F2-B018-597FFA1A0BF6@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Date: Thu, 26 Apr 2007 16:13:36 -0500
To: Juha Heinanen <jh@tutpro.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 26, 2007, at 3:23 PM, Juha Heinanen wrote:

> so UAC sends initial request over tls via its proxy (an possibly other
> proxies) to UAS and then bye comes from the UAS 2 hours later.  how  
> does
> the proxy know that it should forward bye to UAC over tls if there  
> is no
> transport=tls parameter anywhere?

We have the assumption that if TLS can be used, it will be used.  
Under this model, if a proxy doesn't know whether a UAS supports TLS  
or not, it needs to run through the discovery process to find out  
whether it does.

Don't like the overhead of probing? Then either use appropriate DNS  
records, or link to an outbound proxy that uses them, or just use a  
SIPS contact for everything.

--
Dean


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 17:29:08 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhBWU-0001l8-1h; Thu, 26 Apr 2007 17:29:06 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhBWS-0001jZ-Jq
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 17:29:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhBWS-0001jR-AL
	for sip@ietf.org; Thu, 26 Apr 2007 17:29:04 -0400
Received: from zrtps0kn.nortel.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhBWR-0001uv-2Z
	for sip@ietf.org; Thu, 26 Apr 2007 17:29:04 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3QLT0Q00359; Thu, 26 Apr 2007 21:29:00 GMT
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: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Date: Thu, 26 Apr 2007 16:28:49 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF1032AAEF@zrc2hxm0.corp.nortel.com>
In-Reply-To: <05650EF6-4740-4F00-97AF-AA180402AC1E@softarmor.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Thread-Index: AceIRzqoq2B7P2L0SuCNVDIPe6M6VgAAJr0g
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
	<17968.58739.220882.733487@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A6D8@zrc2hxm0.corp.nortel.com>
	<17968.61648.893419.784702@tutpro.com>
	<05650EF6-4740-4F00-97AF-AA180402AC1E@softarmor.com>
From: "Francois Audet" <audet@nortel.com>
To: "Dean Willis" <dean.willis@softarmor.com>, "Juha Heinanen" <jh@tutpro.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

=20
> > tell me, why is tls (instead of tcp) needed in via when uri=20
> scheme is=20
> > sips?  cannot tls/tcp be concluded if transport is tcp and=20
> uri scheme=20
> > is sips.
>=20
> I've always wondered about this one myself. What about=20
> TLS/SCTP and DTLS, which might serve as transports for SIPS?

VIA already supports SCTP, TLS-SCTP. And the draft provides the=20
references to RFC 4168 that defines it.

DTLS is defined in
http://tools.ietf.org/wg/sip/draft-jennings-sip-dtls-03.txt.

On the question of "why we are using VIA in the first place?" instead or
replying to where the request came from, well, I don't know. It wasn't
me
who wrote RFC 3261. This is a widely known characteristic described
in RFC 3581.

It's completely out of scope of this draft.=20






_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 17:48:30 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhBpB-0000lV-Kd; Thu, 26 Apr 2007 17:48:25 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhBpA-0000lQ-V1
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 17:48:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhBpA-0000lI-LR
	for sip@ietf.org; Thu, 26 Apr 2007 17:48:24 -0400
Received: from ihemail1.lucent.com ([135.245.0.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhBp9-0004wv-8W
	for sip@ietf.org; Thu, 26 Apr 2007 17:48:24 -0400
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l3QLmMYx027971; 
	Thu, 26 Apr 2007 16:48:22 -0500 (CDT)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90])
	by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id
	l3QLmIA29290; Thu, 26 Apr 2007 16:48:22 -0500 (CDT)
Message-ID: <46311E22.3040307@alcatel-lucent.com>
Date: Thu, 26 Apr 2007 16:48:18 -0500
From: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>
Organization: Bell Labs Security Technology Research Group
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Francois Audet <audet@nortel.com>
Subject: Re: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>	<462F613C.2050502@sipstation.com>	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>	<17968.16340.800200.535818@tutpro.com>	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>	<17968.58739.220882.733487@tutpro.com>	<1ECE0EB50388174790F9694F77522CCF1032A6D8@zrc2hxm0.corp.nortel.com>	<17968.61648.893419.784702@tutpro.com>	<05650EF6-4740-4F00-97AF-AA180402AC1E@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF1032AAEF@zrc2hxm0.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1032AAEF@zrc2hxm0.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Francois Audet wrote:
> VIA already supports SCTP, TLS-SCTP. And the draft provides the 
> references to RFC 4168 that defines it.

We've had this conversation before.

That is all well and fine for Vias (responses), but what about
requests triggered by a R-URI?

> DTLS is defined in
> http://tools.ietf.org/wg/sip/draft-jennings-sip-dtls-03.txt.

dtls-03 says that a SIP URI to be sent over DTLS should
look like the following:

    sip:alice@example.com;transport=dtls-udp

Two questions:
   1/ should it not be "sips" scheme here?
   2/ If we are endorsing "transport=dtls-udp" in a SIP URI, then
      saying that you should not put "transport=tls" in a SIP URI
      seems silly. (Note that I personally do not like how
      implementations have continued to use "transport=tls"
      despite rfc3261 deprecating this.  But questions will arise
      in the future that why are we allowing "transport=dtls-udp"
      and not "transport=tls"?)

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 17:50:06 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhBqm-00018o-8v; Thu, 26 Apr 2007 17:50:04 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhBql-00018T-Cz
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 17:50:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhBql-00017N-1p
	for sip@ietf.org; Thu, 26 Apr 2007 17:50:03 -0400
Received: from zrtps0kp.nortel.com ([47.140.192.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhBqj-0005Eh-Oj
	for sip@ietf.org; Thu, 26 Apr 2007 17:50:03 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3QLnxn15385 for <sip@ietf.org>; Thu, 26 Apr 2007 21:49:59 GMT
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: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Date: Thu, 26 Apr 2007 16:49:55 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF1032AB49@zrc2hxm0.corp.nortel.com>
In-Reply-To: <46311E22.3040307@alcatel-lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Thread-Index: AceITKHKQDS6I9MVRFC4PEpGZp7+VwAABiFQ
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>	<462F613C.2050502@sipstation.com>	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>	<17968.16340.800200.535818@tutpro.com>	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>	<17968.58739.220882.733487@tutpro.com>	<1ECE0EB50388174790F9694F77522CCF1032A6D8@zrc2hxm0.corp.nortel.com>	<17968.61648.893419.784702@tutpro.com>	<05650EF6-4740-4F00-97AF-AA180402AC1E@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF1032AAEF@zrc2hxm0.corp.nortel.com>
	<46311E22.3040307@alcatel-lucent.com>
From: "Francois Audet" <audet@nortel.com>
To: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Yes, that draft is wrong and needs to be fixed.=20

The correct behavior is 1/

> -----Original Message-----
> From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com]=20
> Sent: Thursday, April 26, 2007 14:48
> To: Audet, Francois (SC100:3055)
> Cc: sip@ietf.org
> Subject: Re: [Sip] draft-ietf-sip-sips-03.txt: Closing of=20
> Opened issues
>=20
> Francois Audet wrote:
> > VIA already supports SCTP, TLS-SCTP. And the draft provides the=20
> > references to RFC 4168 that defines it.
>=20
> We've had this conversation before.
>=20
> That is all well and fine for Vias (responses), but what=20
> about requests triggered by a R-URI?
>=20
> > DTLS is defined in
> > http://tools.ietf.org/wg/sip/draft-jennings-sip-dtls-03.txt.
>=20
> dtls-03 says that a SIP URI to be sent over DTLS should look=20
> like the following:
>=20
>     sip:alice@example.com;transport=3Ddtls-udp
>=20
> Two questions:
>    1/ should it not be "sips" scheme here?
>    2/ If we are endorsing "transport=3Ddtls-udp" in a SIP URI, then
>       saying that you should not put "transport=3Dtls" in a SIP URI
>       seems silly. (Note that I personally do not like how
>       implementations have continued to use "transport=3Dtls"
>       despite rfc3261 deprecating this.  But questions will arise
>       in the future that why are we allowing "transport=3Ddtls-udp"
>       and not "transport=3Dtls"?)
>=20
> Thanks,
>=20
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
> WWW:   http://www.alcatel-lucent.com/bell-labs
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 18:07:35 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhC7g-0005yM-AJ; Thu, 26 Apr 2007 18:07:32 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhC7f-0005yH-Nv
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 18:07:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhC7f-0005y9-EQ
	for sip@ietf.org; Thu, 26 Apr 2007 18:07:31 -0400
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhC7f-0000Hk-4Q
	for sip@ietf.org; Thu, 26 Apr 2007 18:07:31 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com
	[47.103.123.73])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	l3QM6kh08911; Thu, 26 Apr 2007 22:06:47 GMT
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: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Date: Thu, 26 Apr 2007 17:07:25 -0500
Message-ID: <62B9B0847CC47543B6B3B5E26BD268E6127D0348@zrc2hxm2.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1032AAEF@zrc2hxm0.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Thread-Index: AceIRzqoq2B7P2L0SuCNVDIPe6M6VgAAJr0gAADHyyA=
From: "Samir Srivastava" <samirsr@nortel.com>
To: "Francois Audet" <audet@nortel.com>,
	"Dean Willis" <dean.willis@softarmor.com>, "Juha Heinanen" <jh@tutpro.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi,

The refernece draft mentions in the section 4 that SIPS can be used with
DTLS.

Whereas 3261 has tied SIPS to SIP over TLS.

While 3261 mentions in section 4, page 10

"An example would be sips:bob@biloxi.com.  A call
   made to a SIPS URI guarantees that secure, encrypted transport
   (namely TLS) is used to carry all SIP messages from the caller to the
   domain of the callee"

"3261/ Section 19.1 SIP and SIPS Uniform Resource Indicators"  states

"A SIPS URI specifies that the resource be contacted securely.  This
   means, in particular, that TLS is to be used between the UAC and the
   domain that owns the URI."

So my objection was with reference to 3261, which your draft attempt to
clarify what SIPS means. The above text specifically states TLS only. So
it will be better to clarify the above. And give reference to the
mentioned draft.

Also on the related note on the defintion of transport parameter of the
referenced draft
   transport         =3D  "UDP" / "TCP" / "TLS" / "SCTP" / "TLS-SCTP"
                        "DTLS-DCCP" / "DTLS-UDP"
                        / other-transport


Transport attempts to put DTLS-DCCP but there is no separate DCCP . And
a related question why cannot we have TLS-TCP instead of implicitly
meaning that. Is it just the backward compatibility to 3261.

I would rather have a parameter=20

Secure-Protocol =3D TLS/DTLS/ etc=20
Transport =3D TCP/UDP/DCCP/SCTP/ ...
Instead of clubbing them together and having all permutations .. Bad
modeling.

Now I have still my biggest burning question. If IPSEC tunnel exists
between two SIP addressable entities, we have encryption twice. What
kind of application will shape in future (I don't have idea), where they
might want to tunnel all traffic through a single IPSEC tunnel. Don't we
need some more secure awareness in the application protocol SIP.

Thx
Samir

>-----Original Message-----
>From: Audet, Francois (SC100:3055)=20
>Sent: Thursday, April 26, 2007 2:29 PM
>To: Dean Willis; Juha Heinanen
>Cc: sip@ietf.org
>Subject: RE: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
>
>=20
>> > tell me, why is tls (instead of tcp) needed in via when uri
>> scheme is
>> > sips?  cannot tls/tcp be concluded if transport is tcp and
>> uri scheme
>> > is sips.
>>=20
>> I've always wondered about this one myself. What about TLS/SCTP and=20
>> DTLS, which might serve as transports for SIPS?
>
>VIA already supports SCTP, TLS-SCTP. And the draft provides=20
>the references to RFC 4168 that defines it.
>
>DTLS is defined in
>http://tools.ietf.org/wg/sip/draft-jennings-sip-dtls-03.txt.
>
>On the question of "why we are using VIA in the first place?"=20
>instead or replying to where the request came from, well, I=20
>don't know. It wasn't me who wrote RFC 3261. This is a widely=20
>known characteristic described in RFC 3581.
>
>It's completly out of scope of this draft.=20
>
>
>
>
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol Use=20
>sip-implementors@cs.columbia.edu for questions on current sip=20
>Use sipping@ietf.org for new developments on the application of sip
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 20:32:58 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhEOK-0000A0-Uj; Thu, 26 Apr 2007 20:32:52 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhEOJ-00009N-LC
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 20:32:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhEOJ-00009F-Bf
	for sip@ietf.org; Thu, 26 Apr 2007 20:32:51 -0400
Received: from ihemail1.lucent.com ([135.245.0.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhEOI-00024T-2d
	for sip@ietf.org; Thu, 26 Apr 2007 20:32:51 -0400
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l3R0WnFj017879
	for <sip@ietf.org>; Thu, 26 Apr 2007 19:32:49 -0500 (CDT)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by
	ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 26 Apr 2007 19:32:49 -0500
Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by
	DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 27 Apr 2007 02:32:47 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Fri, 27 Apr 2007 02:32:47 +0200
Message-ID: <5D1A7985295922448D5550C94DE29180010BF7F5@DEEXC1U01.de.lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Location-conveyance: ISSUE #1 - self signed certificates
Thread-Index: AceIYfRNGyMoJnotSpCpYRDXcG8sFQ==
From: "Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>
To: "IETF SIP List" <sip@ietf.org>
X-OriginalArrivalTime: 27 Apr 2007 00:32:47.0413 (UTC)
	FILETIME=[94466650:01C78863]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Subject: [Sip] Location-conveyance: ISSUE #1 - self signed certificates
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

(As SIP WG chair)

During the review of the WGLC comments, we have identified some issues
where we need consensus calls on the list. These are in one call per
message.

There is mention of self-signed certificates in
draft-ietf-sip-location-conveyance. It is proposed to remove that
requirement:

   "Self-signed certificates SHOULD NOT be used for protecting a PIDF,=20
   as the sender does not have a secure identity of the recipient."

Essentially we agreed that if this statement was necessary, it should be
made in draft-ietf-sip-certs, rather than in location-conveyance.

We will assume that this removal represents WG consensus unless we hear
otherwise from the WG in 7 calendar days from the posting of this
message.

Regards

Keith


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 20:33:02 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhEOT-0000GQ-QC; Thu, 26 Apr 2007 20:33:01 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhEOS-0000GC-Ur
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 20:33:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhEOS-0000Fk-Jk
	for sip@ietf.org; Thu, 26 Apr 2007 20:33:00 -0400
Received: from ihemail1.lucent.com ([135.245.0.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhEOR-000253-8h
	for sip@ietf.org; Thu, 26 Apr 2007 20:33:00 -0400
Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l3R0WVPF017730
	for <sip@ietf.org>; Thu, 26 Apr 2007 19:32:58 -0500 (CDT)
Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by
	ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 26 Apr 2007 19:32:50 -0500
Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by
	DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 27 Apr 2007 02:32:48 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Fri, 27 Apr 2007 02:32:48 +0200
Message-ID: <5D1A7985295922448D5550C94DE29180010BF7F6@DEEXC1U01.de.lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Location-conveyance: ISSUE #2 - emergency calls
Thread-Index: AceIYq75WH5JqfBUQ7Cbas8qTNixHg==
From: "Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>
To: "IETF SIP List" <sip@ietf.org>
X-OriginalArrivalTime: 27 Apr 2007 00:32:48.0723 (UTC)
	FILETIME=[950E4A30:01C78863]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Subject: [Sip] Location-conveyance: ISSUE #2 - emergency calls
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

(As SIP WG chair)

During the review of the WGLC comments, we have identified some issues
where we need consensus calls on the list. These are in one call per
message.

There is an amount of text (primarily section 6) within
draft-ietf-sip-location-conveyance related to emergency calls. It is
proposed to remove this text on the basis that there are charter items
within the IETF ECRIT working group that fully specify this application
of location conveyance to this particular purpose. The editor's will
make sure that all the removed text is reflected in appropriately in the
concerned ECRIT documents.

We will assume that this removal represents WG consensus unless we hear
otherwise from the WG in 7 calendar days from the posting of this
message.

Regards

Keith


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Thu Apr 26 23:52:58 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhHVj-0005Dd-Rc; Thu, 26 Apr 2007 23:52:43 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhHVi-0005DY-R5
	for sip-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 23:52:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhHVi-0005DQ-HL
	for sip@ietf.org; Thu, 26 Apr 2007 23:52:42 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhHVh-0006RQ-3y
	for sip@ietf.org; Thu, 26 Apr 2007 23:52:42 -0400
Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l3R3qbe8000846
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 26 Apr 2007 20:52:37 -0700
Received: from [76.102.225.135] (vpn-10-50-0-169.qualcomm.com [10.50.0.169])
	by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	l3R3qU8u024326; Thu, 26 Apr 2007 20:52:36 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06240608c25720d711ab@[76.102.225.135]>
In-Reply-To: <5D1A7985295922448D5550C94DE29180010BF7F6@DEEXC1U01.de.lucent.com>
References: <5D1A7985295922448D5550C94DE29180010BF7F6@DEEXC1U01.de.lucent.com>
Date: Thu, 26 Apr 2007 20:52:29 -0700
To: "Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>,
	"IETF SIP List" <sip@ietf.org>
From: Ted Hardie <hardie@qualcomm.com>
Subject: Re: [Sip] Location-conveyance: ISSUE #2 - emergency calls
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

At 2:32 AM +0200 4/27/07, Drage, Keith \(Keith\) wrote:
>(As SIP WG chair)
>
>During the review of the WGLC comments, we have identified some issues
>where we need consensus calls on the list. These are in one call per
>message.
>
>There is an amount of text (primarily section 6) within
>draft-ietf-sip-location-conveyance related to emergency calls. It is
>proposed to remove this text on the basis that there are charter items
>within the IETF ECRIT working group that fully specify this application
>of location conveyance to this particular purpose. The editor's will
>make sure that all the removed text is reflected in appropriately in the
>concerned ECRIT documents.

I don't think we can answer this question without the actual bits to
be removed.  Can you cite in more detail?

I'd also like to point out that section 6 has a number of  elements
where the baseline assumption of SIP and ECRIT may differ.  This,
for example:

    Thus S/MIME protection of location MUST NOT
   be used.  TLS protection of location SHOULD be used, however, if
   establishment of the TLS connection fails, the call set-up
   operation, including location conveyance, MUST be retried without
   TLS.

The context in SIP and the larger document here makes it clear
that "S/MIME protection of location" means encrypting the location,
rather than signing it.  But location signing is a topic of interest to
ECRIT, and the resulting baseline assumptions may be different.
Increased clarity on exactly what is meant will hopefully result,
but remember this will end up in some document with a bunch of
other context to it.

I also believe that this section:

  Both the "retransmission-allowed" and "routing-query-allowed" SHOULD
   be set to "yes".  Querying for routing may be performed by proxies
   providing a routing service for emergency calls even if
   retransmission-allowed or routing-query-allowed is set to "no" or is
   not present.  Proxies routing on the location MUST set the
   "message-routed-on-this-uri" parameter.

would have to be substantially re-written to fit into phonebcp (presuming
that is where it lands).  To make sense there, I believe it would have to repeat
context from location-conveyance (even with the existing normative
reference).  That's always an invitation to things getting out of synch
in the future, and has to be considered.

Put another way, I don't think you're going to be able to just shift
the text en masse and be done.
			
			regards,
					Ted



>We will assume that this removal represents WG consensus unless we hear
>otherwise from the WG in 7 calendar days from the posting of this
>message.
>
>Regards
>
>Keith
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 27 02:18:27 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhJmf-0001nd-3T; Fri, 27 Apr 2007 02:18:21 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhJmd-0001jy-R3
	for sip-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 02:18:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhJmd-0001g1-2T
	for sip@ietf.org; Fri, 27 Apr 2007 02:18:19 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhJmb-0003Sy-N4
	for sip@ietf.org; Fri, 27 Apr 2007 02:18:19 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id 122241EC02E;
	Fri, 27 Apr 2007 09:18:16 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id K+PIAznwrjdD; Fri, 27 Apr 2007 09:18:11 +0300 (EEST)
Received: from taimen (primer46.gprs.dnafinland.fi [62.78.125.46])
	by tutpro.com (Postfix) with ESMTP;
	Fri, 27 Apr 2007 09:18:11 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id A9189AC122; Fri, 27 Apr 2007 09:18:03 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17969.38299.158154.945070@tutpro.com>
Date: Fri, 27 Apr 2007 09:18:03 +0300
To: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
In-Reply-To: <4D541C44-D3D8-412B-AA3B-0389DDD12E16@softarmor.com>
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
	<17968.52760.363575.469609@tutpro.com>
	<4630D67D.2070700@alcatel-lucent.fr>
	<17968.56707.356706.517149@tutpro.com>
	<4630E07C.2010300@alcatel-lucent.fr>
	<17968.58537.70471.74671@tutpro.com>
	<4D541C44-D3D8-412B-AA3B-0389DDD12E16@softarmor.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Dean Willis writes:

 > If you're trying to invert a recorded route for use in a service- 
 > route, the lack of reversibility induced by rewriting breaks things.

where did rewriting come from?  i was just talking about a proxy double
r-r'ing a request and asked why would someone care.  there is no
rewriting in rfc3261 and there should not be in the future either.

-- juha


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 27 02:28:15 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhJwC-0006yn-3G; Fri, 27 Apr 2007 02:28:12 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhJwB-0006yi-0f
	for sip-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 02:28:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhJwA-0006yX-ND
	for sip@ietf.org; Fri, 27 Apr 2007 02:28:10 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhJw9-0006bb-Cd
	for sip@ietf.org; Fri, 27 Apr 2007 02:28:10 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id CF6871EC02E;
	Fri, 27 Apr 2007 09:28:08 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id Eb1262ZTTP2T; Fri, 27 Apr 2007 09:28:06 +0300 (EEST)
Received: from taimen (primer46.gprs.dnafinland.fi [62.78.125.46])
	by tutpro.com (Postfix) with ESMTP;
	Fri, 27 Apr 2007 09:28:06 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id 39106AC122; Fri, 27 Apr 2007 09:28:01 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17969.38897.194467.878765@tutpro.com>
Date: Fri, 27 Apr 2007 09:28:01 +0300
To: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
In-Reply-To: <7D0628DD-CC2A-42F2-B018-597FFA1A0BF6@softarmor.com>
References: <17969.2643.95877.839771@tutpro.com>
	<7D0628DD-CC2A-42F2-B018-597FFA1A0BF6@softarmor.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Dean Willis writes:

 > We have the assumption that if TLS can be used, it will be used.

again "we" != "real world".  it is much easier and faster to use
transport=tls parameter in r-r header than doing rediscovery or probing
when bye arrives.

may it is high time to write a "real world" BCP document that help to
identify things that are broken in official ietf documents and that "we"
refuses to recognize.

-- juha


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 27 02:30:06 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhJy1-0000QD-9b; Fri, 27 Apr 2007 02:30:05 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhJy0-0000NQ-8T
	for sip-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 02:30:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhJxz-0000NH-UX
	for sip@ietf.org; Fri, 27 Apr 2007 02:30:03 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhJxy-0006r8-Jf
	for sip@ietf.org; Fri, 27 Apr 2007 02:30:03 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id 0E8A51EC02E;
	Fri, 27 Apr 2007 09:30:02 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id qytd0fGa0e3h; Fri, 27 Apr 2007 09:30:00 +0300 (EEST)
Received: from taimen (primer46.gprs.dnafinland.fi [62.78.125.46])
	by tutpro.com (Postfix) with ESMTP;
	Fri, 27 Apr 2007 09:30:00 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id A9D25AC122; Fri, 27 Apr 2007 09:29:54 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17969.39010.662879.347283@tutpro.com>
Date: Fri, 27 Apr 2007 09:29:54 +0300
To: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>
Subject: Re: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
In-Reply-To: <46311E22.3040307@alcatel-lucent.com>
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
	<17968.58739.220882.733487@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A6D8@zrc2hxm0.corp.nortel.com>
	<17968.61648.893419.784702@tutpro.com>
	<05650EF6-4740-4F00-97AF-AA180402AC1E@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF1032AAEF@zrc2hxm0.corp.nortel.com>
	<46311E22.3040307@alcatel-lucent.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: sip@ietf.org, Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Vijay K. Gurbani writes:

 >    2/ If we are endorsing "transport=dtls-udp" in a SIP URI, then
 >       saying that you should not put "transport=tls" in a SIP URI
 >       seems silly. (Note that I personally do not like how
 >       implementations have continued to use "transport=tls"
 >       despite rfc3261 deprecating this.  But questions will arise
 >       in the future that why are we allowing "transport=dtls-udp"
 >       and not "transport=tls"?)

because that is what "we" (the god) decided.

-- juha


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 27 07:38:09 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhOlp-00045a-HB; Fri, 27 Apr 2007 07:37:49 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhOln-00045U-UY
	for sip-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 07:37:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhOln-00045M-L1
	for sip@ietf.org; Fri, 27 Apr 2007 07:37:47 -0400
Received: from smtp-1.hut.fi ([130.233.228.91])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhOlm-0007vH-La
	for sip@ietf.org; Fri, 27 Apr 2007 07:37:47 -0400
Received: from localhost (katosiko.hut.fi [130.233.228.115])
	by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id l3RBbSrV016168;
	Fri, 27 Apr 2007 14:37:28 +0300
Received: from smtp-1.hut.fi ([130.233.228.91])
	by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new,
	port 10024)
	with LMTP id 26389-19; Fri, 27 Apr 2007 14:37:28 +0300 (EEST)
Received: from mail.tml.hut.fi (mail.tml.hut.fi [130.233.47.34])
	by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id l3RBaX6X015837;
	Fri, 27 Apr 2007 14:36:33 +0300
Received: from localhost (localhost.tml.hut.fi [127.0.0.1])
	by mail.tml.hut.fi (Postfix) with ESMTP id 839003A2CD7;
	Fri, 27 Apr 2007 14:36:33 +0300 (EEST)
Received: from mail.tml.hut.fi ([127.0.0.1])
	by localhost (mail.tml.hut.fi [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 20130-07; Fri, 27 Apr 2007 14:36:31 +0300 (EEST)
Received: from localhost (unknown [130.233.45.225])
	by mail.tml.hut.fi (Postfix) with ESMTP id 56FE43A2CCC;
	Fri, 27 Apr 2007 14:36:31 +0300 (EEST)
Received: from t-110-gw.tml.hut.fi (t-110-gw.tml.hut.fi [130.233.45.45]) by
	horde.tml.hut.fi (Horde MIME library) with HTTP;
	Fri, 27 Apr 2007 15:36:10 +0300
Message-ID: <20070427153610.2cd2cpls4ggwg0ks@horde-intra.tml.hut.fi>
Date: Fri, 27 Apr 2007 15:36:10 +0300
From: sergiole@tml.hut.fi
To: Kevin Johns <K.Johns@CableLabs.com>
Subject: RE: [Sip] outbound08 - Handling Responses in Edge proxy /
	Viavs.Flowtoken
References: <20070419175200.g160v60gbo88kk4s@horde-intra.tml.hut.fi><9AAEDF491EF7CA48AB587781B8F5D7C6045F8F@srvxchg3.cablelabs.com>
	<20070420175922.xfff9li17kg4gkc8@horde-intra.tml.hut.fi>
	<9AAEDF491EF7CA48AB587781B8F5D7C6045FF4@srvxchg3.cablelabs.com>
In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C6045FF4@srvxchg3.cablelabs.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.3)
X-TML-Virus-Scanned: amavisd-new-2.3.2-tml at tml.hut.fi
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on katosiko.hut.fi
X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi
X-Spam-Score: 0.2 (/)
X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b
Cc: sip@ietf.org, Cullen Jennings <fluffy@cisco.com>,
	Rohan Mahy <rohan@ekabal.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org



Hi,


  Thank you for your answer.


  We are composing an email with comments about why this issue (to use =20
the information in the Via header to handle Responses for Requests =20
originated by a UAC) may be not a good approach and bring down several =20
good outbound features.

  But before to send our comments, it is important for us to ask the =20
authors if they are considering to re-use the flow in a =20
non-outbound-required UAC-->UAS Request case. Details are explained =20
below.


  Keep in mind that in the comments below we focus our thoughts mainly =20
to connection oriented protocols (TCP).


  Let me introduce an example; in the following scenario the UAC =20
previously established a flow with the EdgeProxy

      ----flow----
  UAC--------------EdgeProxy----UAS


  Suppose now that the UAC wants to send a Request to the UAS.

  We understand that the purpose of a flow is to reach UAC for a =20
Request in the 'opposite direction' (i.e. a request from a UAS to =20
UAC). While now we are sending a Request from UAC to UAS.

The question is:

  What are the authors point of view about re-using the flow in a =20
non-outbound-required UAC-->UAS Request?

  In other words, is an outbound UAC expected to reuse the =20
outbound-flow, or not? ('or not' means : to create another =20
'traditional' SIP connection).


  The advantages to re-use a flow in UAC-UAS direction can introduce =20
some additional features that can make of outbound a powerful =20
mechanism not only to just keep NAT/FW bindings alive to reach a UAC =20
but also to : a) increase security (proxying requests and responses at =20
the Edge Proxy could be always done using a flowtoken), b) be an =20
alternative to RFC 3581.

  We will add more details about the comments above and the advantages =20
that outbound can introduce by re-using a flow in any direction =20
to/from a UAC. But first we need to know what is the authors position =20
about using a flow in the (non-outbound-requiring) UAC-UAS direction.


Regards

Sergio


Quoting Kevin Johns <K.Johns@CableLabs.com>:

> Sergio,
>
> Thank you for clarifying your question.
>
> Let me try and provide some more detail, responses are always sent from
> the UAS to a UAC and are always routed based on the via header never the
> flow token. The flow token is only used for routing of initial requests
> from the edge proxy (UAC) to the client (UAS).
>
> Section 4.3 defines the UAC procedures (it is titled sending requests)
> and strongly recommends that the UA include the rport in the via header.
> When the Edge Proxy gets the INVITE, it will populate the rport
> parameter in the UAC inserted via head with the source port in the UDP
> header of the received packet. It will also insert the receive parameter
> into the same via header entry which contains the source IP address in
> the IP header of the received packet. The Edge Proxy then adds its own
> via header entry and forwards this INVITE along.
>
> When the edge proxy gets back the response, it will look at the top most
> Via header which contains the rport and receive parameter. The Edge
> Proxy will then forward the response to the UAC using these parameters
> which are routable since they represent the WAN interface of the NAT.
> The flow token never comes into play in this case.
>
> This is all defined in RFC 3581 (An Extension to the Session Initiation
> Protocol (SIP) for Symmetric Response Routing)
>
> I hope this helps clarify the situation.
> Kevin
>
> -----Original Message-----
> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
> Sent: Friday, April 20, 2007 8:59 AM
> To: Kevin Johns
> Cc: sip@ietf.org; Cullen Jennings; Rohan Mahy
> Subject: RE: [Sip] outbound08 - Handling Responses in Edge proxy /
> Viavs.Flowtoken
>
>
> Hi,
>
>
>   Thank you for your answer.
>
>   Perhaps I should emphasize that I am always talking about Edge Proxy
> behavior handling incoming Responses to be forwarded to a UAC over an
> existing flow.
>
>   It seems that your answer is related to handling Responses in the UAC,
> not in the Edge Proxy. Nevertheless I add my comments below:
>
>
>> Outbound expects that rport is used in the via header for routing of
>> responses (for UDP that is) see the note in section 4.3.
>
>   I understand that section 4.3 is for UA behavior.
>
>> Responses are
>> routed as defined in 3261 for TCP.
>
>   Yes, but in the case of forwarding Responses to a flow in an Edge
> Proxy, I understand that the proxy uses the flowtoken information, thus
> discarding any consideration of the Via-header parameters (different to
> 3261 approach).
>
>   So.. shouldn't outbound-08 draft explain the case of Responses handled
> by the Edge Proxy? By common sense I guess that the Response should use
> the destination stated in the flowtoken, but, as
> outbound-08 did not formally specify this case, why I could not avoid
> considering the destination in the Via-header (although it wont work
> with NAT)?
>
> Regards,
>
> Sergio
>
>
>
> Quoting Kevin Johns <K.Johns@CableLabs.com>:
>
>> Sergio,
>>
>> Outbound expects that rport is used in the via header for routing of
>> responses (for UDP that is) see the note in section 4.3. Responses are
>
>> routed as defined in 3261 for TCP.
>>
>> Kevin
>>
>> -----Original Message-----
>> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
>> Sent: Thursday, April 19, 2007 8:52 AM
>> To: sip@ietf.org
>> Cc: Cullen Jennings; Rohan Mahy
>> Subject: [Sip] outbound08 - Handling Responses in Edge proxy / Via
>> vs.Flowtoken
>>
>>
>>
>> Hi,
>>
>>
>>   I have a question related to handling Responses that are going to be
>
>> sent over a flow in an Edge proxy.
>>
>>   In "5.3.  Forwarding Requests (outbound08)" I read that a Request is
>
>> forwarded to a flow using the information retrieved from the flow
>> token (and that it is found in the Route-header).
>>
>>   Now I am considering how is the case for Responses.
>>
>>   Should we consider the same behavior? i.e. forward a Response over a
>
>> flow using the flowtoken found in the Path-header?
>>
>>   In 'non-outbound SIP', as far as I understand, Route Header forces
>> the routing in Requests, and Via-header forces routing in Responses.
>>
>>   So... should we avoid any consideration to the information stored in
>
>> the topmost Via-header when proxying a Response? (And instead use the
>> information in the flowtoken ?)
>>
>>   I think that the answers is yes, since the Via could contain a
>> private address in the case of a NAT in the middle. Then, shouldn't be
>
>> mentioned the response case in the draft?
>>
>>
>> Regards,
>>
>>
>> Sergio
>>
>>
>>
>>
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol Use
>> sip-implementors@cs.columbia.edu for questions on current sip Use
>> sipping@ietf.org for new developments on the application of sip
>>
>
>
>
>





_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 27 10:48:38 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhRjf-0007D4-Ro; Fri, 27 Apr 2007 10:47:47 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhRjd-0007BZ-CB
	for sip-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 10:47:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhRjc-0007AE-U5
	for sip@ietf.org; Fri, 27 Apr 2007 10:47:44 -0400
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhRWD-0004BC-GK
	for sip@ietf.org; Fri, 27 Apr 2007 10:33:54 -0400
Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121])
	(authenticated bits=0)
	by nostrum.com (8.13.8/8.13.8) with ESMTP id l3REXl3p092982
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Fri, 27 Apr 2007 09:33:51 -0500 (CDT)
	(envelope-from rjsparks@nostrum.com)
In-Reply-To: <17969.38299.158154.945070@tutpro.com>
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
	<17968.52760.363575.469609@tutpro.com>
	<4630D67D.2070700@alcatel-lucent.fr>
	<17968.56707.356706.517149@tutpro.com>
	<4630E07C.2010300@alcatel-lucent.fr>
	<17968.58537.70471.74671@tutpro.com>
	<4D541C44-D3D8-412B-AA3B-0389DDD12E16@softarmor.com>
	<17969.38299.158154.945070@tutpro.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <4D9FBE09-3D68-41B4-9FE0-DAE608384CE1@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Date: Fri, 27 Apr 2007 09:33:43 -0500
To: Juha Heinanen <jh@tutpro.com>
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
	mechanism)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: sip@ietf.org, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Juha -

Rewriting, as the term is being used in this conversation, _is_  
specified in 3261.
See section 16.7 Item 8 on page 107 with details starting on page  
112. If you
mean something else by rewriting, please make it explicit.

RjS

On Apr 27, 2007, at 1:18 AM, Juha Heinanen wrote:

> Dean Willis writes:
>
>> If you're trying to invert a recorded route for use in a service-
>> route, the lack of reversibility induced by rewriting breaks things.
>
> where did rewriting come from?  i was just talking about a proxy  
> double
> r-r'ing a request and asked why would someone care.  there is no
> rewriting in rfc3261 and there should not be in the future either.
>
> -- juha
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 27 10:50:45 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhRmX-0000VD-6d; Fri, 27 Apr 2007 10:50:45 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhRmW-0000V3-3C
	for sip-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 10:50:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhRmV-0000Uq-PV
	for sip@ietf.org; Fri, 27 Apr 2007 10:50:43 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhRmU-00020s-EC
	for sip@ietf.org; Fri, 27 Apr 2007 10:50:43 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id B59771EC02E;
	Fri, 27 Apr 2007 17:50:41 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id apNsnEsJKkNN; Fri, 27 Apr 2007 17:50:39 +0300 (EEST)
Received: from taimen (nuclease196.gprs.dnafinland.fi [62.78.108.196])
	by tutpro.com (Postfix) with ESMTP;
	Fri, 27 Apr 2007 17:50:39 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id 7A8ABAC122; Fri, 27 Apr 2007 17:50:34 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17970.3514.467361.165872@tutpro.com>
Date: Fri, 27 Apr 2007 17:50:34 +0300
To: Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
In-Reply-To: <4D9FBE09-3D68-41B4-9FE0-DAE608384CE1@nostrum.com>
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
	<17968.52760.363575.469609@tutpro.com>
	<4630D67D.2070700@alcatel-lucent.fr>
	<17968.56707.356706.517149@tutpro.com>
	<4630E07C.2010300@alcatel-lucent.fr>
	<17968.58537.70471.74671@tutpro.com>
	<4D541C44-D3D8-412B-AA3B-0389DDD12E16@softarmor.com>
	<17969.38299.158154.945070@tutpro.com>
	<4D9FBE09-3D68-41B4-9FE0-DAE608384CE1@nostrum.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: sip@ietf.org, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Robert Sparks writes:

 > Rewriting, as the term is being used in this conversation, _is_  
 > specified in 3261.
 > See section 16.7 Item 8 on page 107 with details starting on page  
 > 112.

robert,

thanks for the pointer.  the text is quite confusing though, because in
the list point 8 is OPTIONAL and also the first paragraph on point 8
says that a proxy MAY choose to do some re-writing and then the next
paragraph says that a proxy MUST do rewriting and change uri scheme
depending on transport.

anyway, i still don't understand what does it matter to upstream or
downstream elements if proxy is adding more than one r-r header to the
request.

-- juha


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 27 10:56:12 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhRrn-0005Hk-Gs; Fri, 27 Apr 2007 10:56:11 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhRrl-0005HF-Oj
	for sip-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 10:56:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhRrl-0005GG-8d
	for sip@ietf.org; Fri, 27 Apr 2007 10:56:09 -0400
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhRrQ-0003kD-4m
	for sip@ietf.org; Fri, 27 Apr 2007 10:55:49 -0400
Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121])
	(authenticated bits=0)
	by nostrum.com (8.13.8/8.13.8) with ESMTP id l3REtlnB094114
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Fri, 27 Apr 2007 09:55:47 -0500 (CDT)
	(envelope-from rjsparks@nostrum.com)
In-Reply-To: <17970.3514.467361.165872@tutpro.com>
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
	<17968.52760.363575.469609@tutpro.com>
	<4630D67D.2070700@alcatel-lucent.fr>
	<17968.56707.356706.517149@tutpro.com>
	<4630E07C.2010300@alcatel-lucent.fr>
	<17968.58537.70471.74671@tutpro.com>
	<4D541C44-D3D8-412B-AA3B-0389DDD12E16@softarmor.com>
	<17969.38299.158154.945070@tutpro.com>
	<4D9FBE09-3D68-41B4-9FE0-DAE608384CE1@nostrum.com>
	<17970.3514.467361.165872@tutpro.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <5759106F-FC04-4792-9F6B-4424AD7E08A2@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Date: Fri, 27 Apr 2007 09:55:44 -0500
To: jh@tutpro.com (Juha Heinanen)
X-Mailer: Apple Mail (2.752.3)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
	mechanism)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: sip@ietf.org, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I agree fully that the text is confusing. That's why we've got such a  
rat's nest of threads around this. Thomas' draft is trying to make it  
better.

I also think you and dean (at least) have been talking past each  
other. There is no prohibition in 3261 against a proxy adding more than
one RR value. And there is definitely nothing from the vantage point  
of elements on either side that would break if it did so (assuming it
put appropriate values in of course).

RjS

On Apr 27, 2007, at 9:50 AM, Juha Heinanen wrote:

> Robert Sparks writes:
>
>> Rewriting, as the term is being used in this conversation, _is_
>> specified in 3261.
>> See section 16.7 Item 8 on page 107 with details starting on page
>> 112.
>
> robert,
>
> thanks for the pointer.  the text is quite confusing though,  
> because in
> the list point 8 is OPTIONAL and also the first paragraph on point 8
> says that a proxy MAY choose to do some re-writing and then the next
> paragraph says that a proxy MUST do rewriting and change uri scheme
> depending on transport.
>
> anyway, i still don't understand what does it matter to upstream or
> downstream elements if proxy is adding more than one r-r header to the
> request.
>
> -- juha



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 27 11:02:17 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhRxg-0007DD-VA; Fri, 27 Apr 2007 11:02:16 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhRxe-0007Cs-F0
	for sip-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 11:02:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhRxe-0007Cf-5O
	for sip@ietf.org; Fri, 27 Apr 2007 11:02:14 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhRxc-0006ic-LT
	for sip@ietf.org; Fri, 27 Apr 2007 11:02:14 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id 1C17A1EC02E;
	Fri, 27 Apr 2007 18:02:12 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id dbu3KbqHzxT5; Fri, 27 Apr 2007 18:02:10 +0300 (EEST)
Received: from taimen (nuclease196.gprs.dnafinland.fi [62.78.108.196])
	by tutpro.com (Postfix) with ESMTP;
	Fri, 27 Apr 2007 18:02:10 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id A3C1BAC122; Fri, 27 Apr 2007 18:02:04 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17970.4204.628608.105812@tutpro.com>
Date: Fri, 27 Apr 2007 18:02:04 +0300
To: Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
In-Reply-To: <5759106F-FC04-4792-9F6B-4424AD7E08A2@nostrum.com>
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
	<17968.52760.363575.469609@tutpro.com>
	<4630D67D.2070700@alcatel-lucent.fr>
	<17968.56707.356706.517149@tutpro.com>
	<4630E07C.2010300@alcatel-lucent.fr>
	<17968.58537.70471.74671@tutpro.com>
	<4D541C44-D3D8-412B-AA3B-0389DDD12E16@softarmor.com>
	<17969.38299.158154.945070@tutpro.com>
	<4D9FBE09-3D68-41B4-9FE0-DAE608384CE1@nostrum.com>
	<17970.3514.467361.165872@tutpro.com>
	<5759106F-FC04-4792-9F6B-4424AD7E08A2@nostrum.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Cc: sip@ietf.org, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Robert Sparks writes:

 > I also think you and dean (at least) have been talking past each  
 > other. There is no prohibition in 3261 against a proxy adding more than
 > one RR value. And there is definitely nothing from the vantage point  
 > of elements on either side that would break if it did so (assuming it
 > put appropriate values in of course).

fine, we can then put this discussion into rest (assuming that someone
does not try to in some later document to prohibit double r-r'ing).

-- juha


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 27 11:37:29 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhSVk-0008UL-IF; Fri, 27 Apr 2007 11:37:28 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhSVi-0008Oz-VU
	for sip-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 11:37:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhSVi-0008Or-Lv
	for sip@ietf.org; Fri, 27 Apr 2007 11:37:26 -0400
Received: from zrtps0kn.nortel.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhSVh-0005VP-DE
	for sip@ietf.org; Fri, 27 Apr 2007 11:37:26 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3RFbFP08261; Fri, 27 Apr 2007 15:37:15 GMT
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: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Date: Fri, 27 Apr 2007 10:36:52 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF1037E3A1@zrc2hxm0.corp.nortel.com>
In-Reply-To: <17970.4204.628608.105812@tutpro.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Thread-Index: AceI3S6abWl6ZhNbSnmSrRZrsqYcZgAAd6og
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
	<17968.52760.363575.469609@tutpro.com>
	<4630D67D.2070700@alcatel-lucent.fr>
	<17968.56707.356706.517149@tutpro.com>
	<4630E07C.2010300@alcatel-lucent.fr>	<17968.58537.70471.74671@tutpro.com>
	<4D541C44-D3D8-412B-AA3B-0389DDD12E16@softarmor.com>
	<17969.38299.158154.945070@tutpro.com>
	<4D9FBE09-3D68-41B4-9FE0-DAE608384CE1@nostrum.com>
	<17970.3514.467361.165872@tutpro.com>
	<5759106F-FC04-4792-9F6B-4424AD7E08A2@nostrum.com>
	<17970.4204.628608.105812@tutpro.com>
From: "Francois Audet" <audet@nortel.com>
To: "Juha Heinanen" <jh@tutpro.com>, "Robert Sparks" <rjsparks@nostrum.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: sip@ietf.org, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Double record-routing is completely othogonal to the topic of sips.

Furthermore, Double record-routing IS the preferred mechanism to use
when you need to switch transport, URI schemes, IPv4/IPv6 mapping, etc.
Double R-R is good (TM), and preferable to rewriting as per 3261.

It's just that this spec does not use it for the purpose of mappping=20
between sip to sips,  because it does not support mapping between
sip to sips.

> -----Original Message-----
> From: Juha Heinanen [mailto:jh@tutpro.com]=20
> Sent: Friday, April 27, 2007 08:02
> To: Robert Sparks
> Cc: sip@ietf.org; Dean Willis
> Subject: Re: [Sip] draft-ietf-sip-sips-03.txt: Closing of=20
> Opened issues
>=20
> Robert Sparks writes:
>=20
>  > I also think you and dean (at least) have been talking=20
> past each  > other. There is no prohibition in 3261 against a=20
> proxy adding more than  > one RR value. And there is=20
> definitely nothing from the vantage point  > of elements on=20
> either side that would break if it did so (assuming it  > put=20
> appropriate values in of course).
>=20
> fine, we can then put this discussion into rest (assuming=20
> that someone does not try to in some later document to=20
> prohibit double r-r'ing).
>=20
> -- juha
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 27 11:40:36 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhSYl-0001zX-Vo; Fri, 27 Apr 2007 11:40:35 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhSYk-0001yQ-JC
	for sip-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 11:40:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhSYk-0001xD-7T
	for sip@ietf.org; Fri, 27 Apr 2007 11:40:34 -0400
Received: from mx12.bbn.com ([128.33.0.81])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhSYj-00063V-TK
	for sip@ietf.org; Fri, 27 Apr 2007 11:40:34 -0400
Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1])
	by mx12.bbn.com with esmtp (Exim 4.60)
	(envelope-from <rbarnes@bbn.com>)
	id 1HhSYi-0006zs-59; Fri, 27 Apr 2007 11:40:33 -0400
Message-ID: <4632196E.7040403@bbn.com>
Date: Fri, 27 Apr 2007 11:40:30 -0400
From: Richard Barnes <rbarnes@bbn.com>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Ted Hardie <hardie@qualcomm.com>
Subject: Re: [Sip] Location-conveyance: ISSUE #2 - emergency calls
References: <5D1A7985295922448D5550C94DE29180010BF7F6@DEEXC1U01.de.lucent.com>
	<p06240608c25720d711ab@[76.102.225.135]>
In-Reply-To: <p06240608c25720d711ab@[76.102.225.135]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87
Cc: IETF SIP List <sip@ietf.org>, "Drage,
	Keith \(Keith\)" <drage@alcatel-lucent.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Ted,

I think the proposal was to remove Section 6 entirely, and any other 
bits of emergency-specific text elsewhere, from the location conveyance 
document to phonebcp/framework.  In terms of the other bits, I only see 
two non-normative mentions after a brief scan:
-- Last paragraph of Section 1
-- Last sentence of Section 4.3

Hope this helps to clarify,
--Richard


Ted Hardie wrote:
> At 2:32 AM +0200 4/27/07, Drage, Keith \(Keith\) wrote:
>> (As SIP WG chair)
>>
>> During the review of the WGLC comments, we have identified some issues
>> where we need consensus calls on the list. These are in one call per
>> message.
>>
>> There is an amount of text (primarily section 6) within
>> draft-ietf-sip-location-conveyance related to emergency calls. It is
>> proposed to remove this text on the basis that there are charter items
>> within the IETF ECRIT working group that fully specify this application
>> of location conveyance to this particular purpose. The editor's will
>> make sure that all the removed text is reflected in appropriately in the
>> concerned ECRIT documents.
> 
> I don't think we can answer this question without the actual bits to
> be removed.  Can you cite in more detail?
> 
> I'd also like to point out that section 6 has a number of  elements
> where the baseline assumption of SIP and ECRIT may differ.  This,
> for example:
> 
>     Thus S/MIME protection of location MUST NOT
>    be used.  TLS protection of location SHOULD be used, however, if
>    establishment of the TLS connection fails, the call set-up
>    operation, including location conveyance, MUST be retried without
>    TLS.
> 
> The context in SIP and the larger document here makes it clear
> that "S/MIME protection of location" means encrypting the location,
> rather than signing it.  But location signing is a topic of interest to
> ECRIT, and the resulting baseline assumptions may be different.
> Increased clarity on exactly what is meant will hopefully result,
> but remember this will end up in some document with a bunch of
> other context to it.
> 
> I also believe that this section:
> 
>   Both the "retransmission-allowed" and "routing-query-allowed" SHOULD
>    be set to "yes".  Querying for routing may be performed by proxies
>    providing a routing service for emergency calls even if
>    retransmission-allowed or routing-query-allowed is set to "no" or is
>    not present.  Proxies routing on the location MUST set the
>    "message-routed-on-this-uri" parameter.
> 
> would have to be substantially re-written to fit into phonebcp (presuming
> that is where it lands).  To make sense there, I believe it would have to repeat
> context from location-conveyance (even with the existing normative
> reference).  That's always an invitation to things getting out of synch
> in the future, and has to be considered.
> 
> Put another way, I don't think you're going to be able to just shift
> the text en masse and be done.
> 			
> 			regards,
> 					Ted
> 
> 
> 
>> We will assume that this removal represents WG consensus unless we hear
>> otherwise from the WG in 7 calendar days from the posting of this
>> message.
>>
>> Regards
>>
>> Keith
>>
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use sip-implementors@cs.columbia.edu for questions on current sip
>> Use sipping@ietf.org for new developments on the application of sip
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
> 




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 27 11:41:22 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhSZV-0002Cz-UA; Fri, 27 Apr 2007 11:41:21 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhSZT-0002Cq-T5
	for sip-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 11:41:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhSZT-0002CQ-JN
	for sip@ietf.org; Fri, 27 Apr 2007 11:41:19 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhSZR-0006BV-EQ
	for sip@ietf.org; Fri, 27 Apr 2007 11:41:19 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id DB1C61EC02E;
	Fri, 27 Apr 2007 18:41:16 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id Pa2ObkbcN5pA; Fri, 27 Apr 2007 18:41:15 +0300 (EEST)
Received: from taimen (nuclease196.gprs.dnafinland.fi [62.78.108.196])
	by tutpro.com (Postfix) with ESMTP;
	Fri, 27 Apr 2007 18:41:15 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id B46FEAC122; Fri, 27 Apr 2007 18:41:09 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17970.6549.713776.739543@tutpro.com>
Date: Fri, 27 Apr 2007 18:41:09 +0300
To: "Francois Audet" <audet@nortel.com>
Subject: RE: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1037E3A1@zrc2hxm0.corp.nortel.com>
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
	<17968.52760.363575.469609@tutpro.com>
	<4630D67D.2070700@alcatel-lucent.fr>
	<17968.56707.356706.517149@tutpro.com>
	<4630E07C.2010300@alcatel-lucent.fr>
	<17968.58537.70471.74671@tutpro.com>
	<4D541C44-D3D8-412B-AA3B-0389DDD12E16@softarmor.com>
	<17969.38299.158154.945070@tutpro.com>
	<4D9FBE09-3D68-41B4-9FE0-DAE608384CE1@nostrum.com>
	<17970.3514.467361.165872@tutpro.com>
	<5759106F-FC04-4792-9F6B-4424AD7E08A2@nostrum.com>
	<17970.4204.628608.105812@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1037E3A1@zrc2hxm0.corp.nortel.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Cc: sip@ietf.org, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Francois Audet writes:

 > It's just that this spec does not use it for the purpose of mappping 
 > between sip to sips,  because it does not support mapping between
 > sip to sips.

that is good, since it is much better to use transport=tls.

-- juha


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 27 11:43:47 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhSbr-0002zt-8z; Fri, 27 Apr 2007 11:43:47 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhSbq-0002zi-8t
	for sip-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 11:43:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhSbp-0002zX-VF
	for sip@ietf.org; Fri, 27 Apr 2007 11:43:45 -0400
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhSbn-0006bk-MA
	for sip@ietf.org; Fri, 27 Apr 2007 11:43:45 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	l3RFgnD10916; Fri, 27 Apr 2007 15:42:49 GMT
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: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Date: Fri, 27 Apr 2007 10:43:30 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF1037E3C5@zrc2hxm0.corp.nortel.com>
In-Reply-To: <17970.6549.713776.739543@tutpro.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Thread-Index: AceI4oBis9rQ7WZSSuGBdvTAT8sMkgAADb9A
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
	<17968.52760.363575.469609@tutpro.com>
	<4630D67D.2070700@alcatel-lucent.fr>
	<17968.56707.356706.517149@tutpro.com>
	<4630E07C.2010300@alcatel-lucent.fr>	<17968.58537.70471.74671@tutpro.com>
	<4D541C44-D3D8-412B-AA3B-0389DDD12E16@softarmor.com>
	<17969.38299.158154.945070@tutpro.com>
	<4D9FBE09-3D68-41B4-9FE0-DAE608384CE1@nostrum.com>
	<17970.3514.467361.165872@tutpro.com>
	<5759106F-FC04-4792-9F6B-4424AD7E08A2@nostrum.com>
	<17970.4204.628608.105812@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1037E3A1@zrc2hxm0.corp.nortel.com>
	<17970.6549.713776.739543@tutpro.com>
From: "Francois Audet" <audet@nortel.com>
To: "Juha Heinanen" <jh@tutpro.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: sip@ietf.org, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

It doesn't do anything to use transport=3Dtls.=20

You can just pick tls and avoid the parameter.

Anyways, I'm not commenting anymore on this topic.=20

> -----Original Message-----
> From: Juha Heinanen [mailto:jh@tutpro.com]=20
> Sent: Friday, April 27, 2007 08:41
> To: Audet, Francois (SC100:3055)
> Cc: Robert Sparks; sip@ietf.org; Dean Willis
> Subject: RE: [Sip] draft-ietf-sip-sips-03.txt: Closing of=20
> Opened issues
>=20
> Francois Audet writes:
>=20
>  > It's just that this spec does not use it for the purpose=20
> of mappping  > between sip to sips,  because it does not=20
> support mapping between  > sip to sips.
>=20
> that is good, since it is much better to use transport=3Dtls.
>=20
> -- juha
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 27 13:12:50 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhTzy-000740-Jf; Fri, 27 Apr 2007 13:12:46 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhTzx-00073k-0Y
	for sip-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 13:12:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhTzw-00073Z-N7
	for sip@ietf.org; Fri, 27 Apr 2007 13:12:44 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhTzv-0003pU-DU
	for sip@ietf.org; Fri, 27 Apr 2007 13:12:44 -0400
Received: from [64.101.172.228] ([64.101.172.228]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3RGJdjT032455
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Fri, 27 Apr 2007 11:19:40 -0500
In-Reply-To: <5759106F-FC04-4792-9F6B-4424AD7E08A2@nostrum.com>
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
	<17968.52760.363575.469609@tutpro.com>
	<4630D67D.2070700@alcatel-lucent.fr>
	<17968.56707.356706.517149@tutpro.com>
	<4630E07C.2010300@alcatel-lucent.fr>
	<17968.58537.70471.74671@tutpro.com>
	<4D541C44-D3D8-412B-AA3B-0389DDD12E16@softarmor.com>
	<17969.38299.158154.945070@tutpro.com>
	<4D9FBE09-3D68-41B4-9FE0-DAE608384CE1@nostrum.com>
	<17970.3514.467361.165872@tutpro.com>
	<5759106F-FC04-4792-9F6B-4424AD7E08A2@nostrum.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <64274286-DF2F-4B4A-B883-9D408524929B@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Date: Fri, 27 Apr 2007 12:12:25 -0500
To: Robert Sparks <rjsparks@nostrum.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: sip@ietf.org, Juha Heinanen <jh@tutpro.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 27, 2007, at 9:55 AM, Robert Sparks wrote:

> I agree fully that the text is confusing. That's why we've got such  
> a rat's nest of threads around this. Thomas' draft is trying to  
> make it better.
>
> I also think you and dean (at least) have been talking past each  
> other. There is no prohibition in 3261 against a proxy adding more  
> than
> one RR value. And there is definitely nothing from the vantage  
> point of elements on either side that would break if it did so  
> (assuming it
> put appropriate values in of course).

Right, I've been trying to say double recording is a better solution  
than rewriting, because rewriting is likely to break stuff, and we  
haven't found anything that breaks from double recording. That's the  
argument for deprecating (at least to a SHOULD level rather than  
prohibiting) rewriting.

I'm not suggesting we prohibit double recording.

--
Dean


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 27 13:39:00 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhUPK-0002Em-KD; Fri, 27 Apr 2007 13:38:58 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhUPI-0002EX-Qf
	for sip-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 13:38:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhUPI-0002EM-Ev
	for sip@ietf.org; Fri, 27 Apr 2007 13:38:56 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhUPG-0002hI-RL
	for sip@ietf.org; Fri, 27 Apr 2007 13:38:56 -0400
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l3RHcZ3o023117
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 27 Apr 2007 10:38:35 -0700
Received: from [129.46.226.38] (carbuncle.qualcomm.com [129.46.226.38])
	by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3RHcXE4022419;
	Fri, 27 Apr 2007 10:38:34 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06240601c257e2c1eb5f@[76.102.225.135]>
In-Reply-To: <4632196E.7040403@bbn.com>
References: <5D1A7985295922448D5550C94DE29180010BF7F6@DEEXC1U01.de.lucent.com>
	<p06240608c25720d711ab@[76.102.225.135]> <4632196E.7040403@bbn.com>
Date: Fri, 27 Apr 2007 10:38:32 -0700
To: Richard Barnes <rbarnes@bbn.com>
From: Ted Hardie <hardie@qualcomm.com>
Subject: Re: [Sip] Location-conveyance: ISSUE #2 - emergency calls
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3971661e40967acfc35f708dd5f33760
Cc: IETF SIP List <sip@ietf.org>, "Drage,
	Keith \(Keith\)" <drage@alcatel-lucent.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

At 11:40 AM -0400 4/27/07, Richard Barnes wrote:
>Ted,
>
>I think the proposal was to remove Section 6 entirely, and any other bits of emergency-specific text elsewhere, from the location conveyance document to phonebcp/framework.  In terms of the other bits, I only see two non-normative mentions after a brief scan:
>-- Last paragraph of Section 1

So, this text:

   In this document, we frequently refer to the "emergency case".  This
   refers to a specific, important use of sip location conveyance where
   the location of the caller is used to determine which Public Safety
   Answering Point (PSAP) should receive an emergency call request for
   help (e.g. a call to 1-1-2 or 9-1-1).  This is an example of
   location-based routing.  The location conveyed is also used by the
   PSAP to dispatch first responders to the caller's location.  There
   are special security considerations which make the emergency case
   unique, compared to a normal location conveyance within SIP.


>-- Last sentence of Section 4.3

The last sentence of this:

   A location recipient would need to dereference the sips-URI in the
   Geolocation header to retrieve Alice's location.  If the
   atlanta.example.com domain chooses to implement location conveyance
   and delivery in this way (i.e. location-by-reference), it is
   RECOMMENDED that entities outside this domain be able to reach the
   dereferencing LIS server, otherwise this model of implementation is
   only viable within the atlanta.example.com domain.  This will likely
   not suit some services already being considered in the IETF at the
   time of this writing, such as emergency calling.

And section 6, which I talked about in my first message.

Having reviewed this again, I don't believe that it is appropriate to
remove the text in Section 1, since the emergency use case was and
is an important driver for both location based routing and location
conveyance.  Removing that context doesn't help the reader.  An
additional pointer there to the ECRIT documents and a statement
that the full context is in them might be valuable as a way of pointing
out that the location-conveyance draft will not provide that.

I think much the same is true for the last sentence in 4.3; replacing
it with a statement like "For special considerations relevant to
dereferencing location in emergency call situations, see [CITATION]"
would be better.

I believe the issues in Section 6 could be covered in the ECRIT phonebcp
document, but I continue to believe that they will need to be re-written
to fit into that document.

I assume that any change to this text will require an update to the
Security Considerations, which currently have this:

    UAC implementations MUST make such capabilities
   conditional on explicit user permission, and SHOULD alert a user
   that location is being conveyed.  Emergency calls have their own
   rules in this regard, as detailed in Section 6.  Proxies inserting
   location for location-based routing are unable to meet this
   requirement, and such use is NOT RECOMMENDED.  Proxies conveying
   location using this extension MUST have the permission of the target
   to do so. 

				regards,
					Ted Hardie


>Hope this helps to clarify,
>--Richard
>
>
>Ted Hardie wrote:
>>At 2:32 AM +0200 4/27/07, Drage, Keith \(Keith\) wrote:
>>>(As SIP WG chair)
>>>
>>>During the review of the WGLC comments, we have identified some issues
>>>where we need consensus calls on the list. These are in one call per
>>>message.
>>>
>>>There is an amount of text (primarily section 6) within
>>>draft-ietf-sip-location-conveyance related to emergency calls. It is
>>>proposed to remove this text on the basis that there are charter items
>>>within the IETF ECRIT working group that fully specify this application
>>>of location conveyance to this particular purpose. The editor's will
>>>make sure that all the removed text is reflected in appropriately in the
>>>concerned ECRIT documents.
>>
>>I don't think we can answer this question without the actual bits to
>>be removed.  Can you cite in more detail?
>>
>>I'd also like to point out that section 6 has a number of  elements
>>where the baseline assumption of SIP and ECRIT may differ.  This,
>>for example:
>>
>>    Thus S/MIME protection of location MUST NOT
>>   be used.  TLS protection of location SHOULD be used, however, if
>>   establishment of the TLS connection fails, the call set-up
>>   operation, including location conveyance, MUST be retried without
>>   TLS.
>>
>>The context in SIP and the larger document here makes it clear
>>that "S/MIME protection of location" means encrypting the location,
>>rather than signing it.  But location signing is a topic of interest to
>>ECRIT, and the resulting baseline assumptions may be different.
>>Increased clarity on exactly what is meant will hopefully result,
>>but remember this will end up in some document with a bunch of
>>other context to it.
>>
>>I also believe that this section:
>>
>>  Both the "retransmission-allowed" and "routing-query-allowed" SHOULD
>>   be set to "yes".  Querying for routing may be performed by proxies
>>   providing a routing service for emergency calls even if
>>   retransmission-allowed or routing-query-allowed is set to "no" or is
>>   not present.  Proxies routing on the location MUST set the
>>   "message-routed-on-this-uri" parameter.
>>
>>would have to be substantially re-written to fit into phonebcp (presuming
>>that is where it lands).  To make sense there, I believe it would have to repeat
>>context from location-conveyance (even with the existing normative
>>reference).  That's always an invitation to things getting out of synch
>>in the future, and has to be considered.
>>
>>Put another way, I don't think you're going to be able to just shift
>>the text en masse and be done.
>>			
>>			regards,
>>					Ted
>>
>>
>>>We will assume that this removal represents WG consensus unless we hear
>>>otherwise from the WG in 7 calendar days from the posting of this
>>>message.
>>>
>>>Regards
>>>
>>>Keith
>>>
>>>
>>>_______________________________________________
>>>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>>This list is for NEW development of the core SIP Protocol
>>>Use sip-implementors@cs.columbia.edu for questions on current sip
>>>Use sipping@ietf.org for new developments on the application of sip
>>
>>
>>
>>_______________________________________________
>>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>This list is for NEW development of the core SIP Protocol
>>Use sip-implementors@cs.columbia.edu for questions on current sip
>>Use sipping@ietf.org for new developments on the application of sip



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 27 14:29:27 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhVC1-0000qG-GD; Fri, 27 Apr 2007 14:29:17 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhVBy-0000qB-JV
	for sip-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 14:29:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhVBy-0000q3-9v
	for sip@ietf.org; Fri, 27 Apr 2007 14:29:14 -0400
Received: from ebru.winwebhosting.com ([74.52.236.50])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhVBx-00071C-KV
	for sip@ietf.org; Fri, 27 Apr 2007 14:29:14 -0400
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp)
	by ebru.winwebhosting.com with esmtpa (Exim 4.63)
	(envelope-from <br@brianrosen.net>)
	id 1HhVBT-00056v-8i; Fri, 27 Apr 2007 13:28:43 -0500
From: "Brian Rosen" <br@brianrosen.net>
To: "'Ted Hardie'" <hardie@qualcomm.com>,
	"'Drage, Keith \(Keith\)'" <drage@alcatel-lucent.com>,
	"'IETF SIP List'" <sip@ietf.org>
Subject: RE: [Sip] Location-conveyance: ISSUE #2 - emergency calls
Date: Fri, 27 Apr 2007 14:29:05 -0400
Message-ID: <074e01c788f9$f1df5c90$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <p06240608c25720d711ab@[76.102.225.135]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Thread-Index: AceIf4LMsa1n8o3XRh2mSh7xoVwRxgAeXScA
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

See In line

> I don't think we can answer this question without the actual bits to
> be removed.  Can you cite in more detail?
We'll make a list as we go through the text, but the goal is to remove any
reference to emergency call.

> 
> I'd also like to point out that section 6 has a number of  elements
> where the baseline assumption of SIP and ECRIT may differ.  This,
> for example:
> 
>     Thus S/MIME protection of location MUST NOT
>    be used.  TLS protection of location SHOULD be used, however, if
>    establishment of the TLS connection fails, the call set-up
>    operation, including location conveyance, MUST be retried without
>    TLS.
> 
> The context in SIP and the larger document here makes it clear
> that "S/MIME protection of location" means encrypting the location,
> rather than signing it.  But location signing is a topic of interest to
> ECRIT, and the resulting baseline assumptions may be different.
> Increased clarity on exactly what is meant will hopefully result,
> but remember this will end up in some document with a bunch of
> other context to it.
We will rewrite this text to discuss the general issue of security in
location based routing while not having any specific text that is peculiar
to emergency calls.

We would then have in ecrit documents specific advise for emergency call use
of location conveyance.

> 
> I also believe that this section:
> 
>   Both the "retransmission-allowed" and "routing-query-allowed" SHOULD
>    be set to "yes".  Querying for routing may be performed by proxies
>    providing a routing service for emergency calls even if
>    retransmission-allowed or routing-query-allowed is set to "no" or is
>    not present.  Proxies routing on the location MUST set the
>    "message-routed-on-this-uri" parameter.
> 
> would have to be substantially re-written to fit into phonebcp (presuming
> that is where it lands).  To make sense there, I believe it would have to
> repeat
> context from location-conveyance (even with the existing normative
> reference).  That's always an invitation to things getting out of synch
> in the future, and has to be considered.
I would prefer to rewrite this text to better work in generalized location
based routing, and then have minimal additional text in ecrit documents that
expand on that.

The "Querying for routing..." sentence can reasonably be rewritten in ecrit
documents.  The other two sentances in the cited text probably should remain
as general advice for any location based routing scenario.

> 
> Put another way, I don't think you're going to be able to just shift
> the text en masse and be done.

Well, do you agree with the principal, while reserving the right to comment
on the specifics?





_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 27 14:39:54 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhVMG-00064X-8M; Fri, 27 Apr 2007 14:39:52 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhVME-00063l-Ay
	for sip-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 14:39:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhVMD-000638-V2
	for sip@ietf.org; Fri, 27 Apr 2007 14:39:49 -0400
Received: from ebru.winwebhosting.com ([74.52.236.50])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhVMD-0000r7-KL
	for sip@ietf.org; Fri, 27 Apr 2007 14:39:49 -0400
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp)
	by ebru.winwebhosting.com with esmtpa (Exim 4.63)
	(envelope-from <br@brianrosen.net>)
	id 1HhVLY-0007TT-Js; Fri, 27 Apr 2007 13:39:08 -0500
From: "Brian Rosen" <br@brianrosen.net>
To: "'Ted Hardie'" <hardie@qualcomm.com>, "'Richard Barnes'" <rbarnes@bbn.com>
Subject: RE: [Sip] Location-conveyance: ISSUE #2 - emergency calls
Date: Fri, 27 Apr 2007 14:39:31 -0400
Message-ID: <074f01c788fb$66acadb0$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <p06240601c257e2c1eb5f@[76.102.225.135]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Thread-Index: AceI8uNICnua42MtQ0CkjTgG+hrF/AAB3cGA
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Cc: 'IETF SIP List' <sip@ietf.org>, "'Drage,
	Keith \(Keith\)'" <drage@alcatel-lucent.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

In line

> So, this text:
> 
>    In this document, we frequently refer to the "emergency case".  This
>    refers to a specific, important use of sip location conveyance where
>    the location of the caller is used to determine which Public Safety
>    Answering Point (PSAP) should receive an emergency call request for
>    help (e.g. a call to 1-1-2 or 9-1-1).  This is an example of
>    location-based routing.  The location conveyed is also used by the
>    PSAP to dispatch first responders to the caller's location.  There
>    are special security considerations which make the emergency case
>    unique, compared to a normal location conveyance within SIP.
We will rewrite this text to say that emergency call routing is a use case
for this document.  Something like:
  A specific, important use of sip location conveyance is in emergency 
  calls (citizen to authority, for example a call to 1-1-2 or 9-1-1) where
  the location of the caller is used to determine which Public Safety
  Answering Point (PSAP) should receive an emergency call request for
  help.  This is an example of location-based routing.  The location 
  conveyed is also used by the PSAP to dispatch first responders to the 
  caller's location.
> 
> 
> >-- Last sentence of Section 4.3
> 
> The last sentence of this:
> 
>    A location recipient would need to dereference the sips-URI in the
>    Geolocation header to retrieve Alice's location.  If the
>    atlanta.example.com domain chooses to implement location conveyance
>    and delivery in this way (i.e. location-by-reference), it is
>    RECOMMENDED that entities outside this domain be able to reach the
>    dereferencing LIS server, otherwise this model of implementation is
>    only viable within the atlanta.example.com domain.  This will likely
>    not suit some services already being considered in the IETF at the
>    time of this writing, such as emergency calling.
I think we should leave this.

> 
> And section 6, which I talked about in my first message.
> 
> Having reviewed this again, I don't believe that it is appropriate to
> remove the text in Section 1, since the emergency use case was and
> is an important driver for both location based routing and location
> conveyance.  Removing that context doesn't help the reader.  An
> additional pointer there to the ECRIT documents and a statement
> that the full context is in them might be valuable as a way of pointing
> out that the location-conveyance draft will not provide that.
> 
> I think much the same is true for the last sentence in 4.3; replacing
> it with a statement like "For special considerations relevant to
> dereferencing location in emergency call situations, see [CITATION]"
> would be better.
I'd rather not have a normative reference to ecrit documents hold up this
document.

> 
> I believe the issues in Section 6 could be covered in the ECRIT phonebcp
> document, but I continue to believe that they will need to be re-written
> to fit into that document.
Yes, of course

> 
> I assume that any change to this text will require an update to the
> Security Considerations, which currently have this:
> 
>     UAC implementations MUST make such capabilities
>    conditional on explicit user permission, and SHOULD alert a user
>    that location is being conveyed.  Emergency calls have their own
>    rules in this regard, as detailed in Section 6.  Proxies inserting
>    location for location-based routing are unable to meet this
>    requirement, and such use is NOT RECOMMENDED.  Proxies conveying
>    location using this extension MUST have the permission of the target
>    to do so.
Yes, a rewrite of this text is in order




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 27 14:48:27 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhVUY-0005ub-Lk; Fri, 27 Apr 2007 14:48:26 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhVUX-0005uQ-PJ
	for sip-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 14:48:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhVUX-0005uI-Fu
	for sip@ietf.org; Fri, 27 Apr 2007 14:48:25 -0400
Received: from ebru.winwebhosting.com ([74.52.236.50])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhVUW-0003US-8i
	for sip@ietf.org; Fri, 27 Apr 2007 14:48:25 -0400
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp)
	by ebru.winwebhosting.com with esmtpa (Exim 4.63)
	(envelope-from <br@brianrosen.net>)
	id 1HhVU1-0001Zk-6w; Fri, 27 Apr 2007 13:47:53 -0500
From: "Brian Rosen" <br@brianrosen.net>
To: "'Robert Sparks'" <rjsparks@estacado.net>,
	"'IETF SIP List'" <sip@ietf.org>, <sip-implementors@cs.columbia.edu>,
	<discussion@sipforum.org>
Subject: RE: [Sip] SIPit 20 survey summary
Date: Fri, 27 Apr 2007 14:48:15 -0400
Message-ID: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <687F5314-7A9B-443E-85A0-0DA3FD7D7030@estacado.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Thread-Index: AceIGJCaZDa+E6LPR56qjSCK6qd7hgA4ubcA
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I'd like to point out one thing about this:

> This is how they answered for multipart/mime:
>     2% I break if someone sends me multipart/mime
>    24% I pretend multipart/mime doesn't exist if someone sends it to me
>    24% I ignore multipart/mime but will proxy it or hand it to my
> application if it shows up
>    10% I try to do something useful with multipart/mime I receive,
> but I never send it
>     4% I ignore multipart/mime that I receive, but I try to do
> something useful with multipart/mime I send
>    24% I try to do something useful with multipart/mime I send and
> receive
>    12% Other

Moving forward, SIP UAs and proxies will be required to support
location-conveyance (currently draft-ietf-sip-location-conveyance-07) in
order to support location for emergency calls (citizen to authority, like
1-1-2 or
9-1-1).  -conveyance requires multipart support.  

The consequences of not supporting emergency call location will be serious.
I believe it is likely that there will eventually be regulatory requirements
to support emergency calls in some jurisdictions.  Upgrades to several
components of today's infrastructure will be needed before this all works,
but stack vendors and UA developers should put multipart (and
location-conveyance) on their development plans for next year at the latest.

Brian




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 27 15:17:33 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhVwe-0003kK-W0; Fri, 27 Apr 2007 15:17:28 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhVwd-0003kB-1B
	for sip-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 15:17:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhVwc-0003k2-Nq
	for sip@ietf.org; Fri, 27 Apr 2007 15:17:26 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhVwb-0003HM-Ct
	for sip@ietf.org; Fri, 27 Apr 2007 15:17:26 -0400
Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l3RJH0a9010151
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 27 Apr 2007 12:17:01 -0700
Received: from [129.46.226.38] (carbuncle.qualcomm.com [129.46.226.38])
	by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	l3RJGxJV000695; Fri, 27 Apr 2007 12:17:00 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06240605c257fbf9d463@[129.46.226.38]>
In-Reply-To: <074f01c788fb$66acadb0$640fa8c0@cis.neustar.com>
References: <074f01c788fb$66acadb0$640fa8c0@cis.neustar.com>
Date: Fri, 27 Apr 2007 12:16:58 -0700
To: "Brian Rosen" <br@brianrosen.net>, "'Richard Barnes'" <rbarnes@bbn.com>
From: Ted Hardie <hardie@qualcomm.com>
Subject: RE: [Sip] Location-conveyance: ISSUE #2 - emergency calls
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: 'IETF SIP List' <sip@ietf.org>, "'Drage,
	Keith \(Keith\)'" <drage@alcatel-lucent.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

At 2:39 PM -0400 4/27/07, Brian Rosen wrote:
>
> > I think much the same is true for the last sentence in 4.3; replacing
>> it with a statement like "For special considerations relevant to
>> dereferencing location in emergency call situations, see [CITATION]"
>> would be better.
>I'd rather not have a normative reference to ecrit documents hold up this
>document.

Well, if the dereferencing model is different for emergency services than
for the other uses covered in 4.3 and you expect someone to understand
both in order to deploy this, I think your choices are repeat the considerations
here or put in a pointer.  I don't really see that this can be an informative
reference, since you have to follow it in order to get the deployment
right for the relevant use case.

				regards,
					Ted Hardie


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 27 17:03:25 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhXb6-0001Wk-1N; Fri, 27 Apr 2007 17:03:20 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhXb4-0001WZ-P1
	for sip-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 17:03:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhXb4-0001WR-FV
	for sip@ietf.org; Fri, 27 Apr 2007 17:03:18 -0400
Received: from zrtps0kp.nortel.com ([47.140.192.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhXb3-0002tx-1s
	for sip@ietf.org; Fri, 27 Apr 2007 17:03:18 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3RL32e01855; Fri, 27 Apr 2007 21:03:02 GMT
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: [Sip] Re: draft-ietf-sip-sips-03
Date: Fri, 27 Apr 2007 16:03:00 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF1037E9B4@zrc2hxm0.corp.nortel.com>
In-Reply-To: <1177686902.24685.3.camel@eeek.ingate.se>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Re: draft-ietf-sip-sips-03
Thread-Index: AceI3ukBLes/eWCRTX2PQHtmfYEOCwAL750Q
References: <45FE0336.8010506@cisco.com>
	<1177686902.24685.3.camel@eeek.ingate.se>
From: "Francois Audet" <audet@nortel.com>
To: "Hans Persson" <hasse@ingate.com>, "SIP IETF" <sip@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi Hans,

Thank you for your careful review. I will incorporate all your changes =
and request
for clarification in the next version of the draft.

You had one question buried in there that I think deserve attention from =
the group:

> In general, I feel that I don't understand the reasoning=20
> behind when to respond 403 and when to respond 404 in this draft.
=20
Basically, I've used 403 (Forbidden) when a UAC tries to register with =
the wrong
scheme in the Contact.

And I've used 404 (Not Found) when a UAC sends a non-REGISTER request to =
a SIP URI when only a SIPS URI exists for that resource. I used to have =
403 for that, but I received
some comments from somebody on the list that 404 (Not Found) would be =
more appropriate.

I don't feel strongly about this issue.

If anybody has any ideas, please go ahead.=20

> -----Original Message-----
> From: Hans Persson [mailto:hasse@ingate.com]=20
> Sent: Friday, April 27, 2007 08:15
> To: SIP IETF
> Cc: Audet, Francois (SC100:3055)
> Subject: Re: [Sip] Re: draft-ietf-sip-sips-03
>=20
> s=F6n 2007-03-18 klockan 23:27 -0400 skrev Paul Kyzivat:
>=20
> > Just read the most recent version. Its looking good to me.=20
> Just a few=20
> > typo comments.
>=20
> And so did I, just now.
>=20
> I have a few comments and questions and a slew of nits.
>=20
>=20
> > SIPS URIs however can be used in many other header fields:=20
> in Contact=20
> > for registration, Contact in dialog-creating requests,=20
> Route, Record-=20
> > Route, Path, From, To, Refer-To, Refer-By, etc.  This specification
>=20
> Referred-By, I assume.
>=20
>=20
> > This specification mandates that a resource described by a SIPS=20
> > Request-URI can not be "downgraded" to a SIP URI when a proxy is=20
> > forwarding a request by changing the scheme, or by sending the=20
> > associated request over a non secure link.  See Section 4.2.
>=20
> I had trouble parsing this. Suggestion for modification:
>=20
> >>> This specification mandates that when a proxy is forwarding a=20
> >>> request a resource described by a SIPS Request-URI can not be=20
> >>> "downgraded" to a SIP URI by changing the scheme, or by=20
> sending the=20
> >>> associated request over a non-secure link.  See section 4.2.
>=20
>=20
> > Consider this example:  If Bob registers with a SIPS Contact header=20
> > field (e.g., sips:bob@bobphone.example.com), the registrar and the=20
> > location service then know that Bob (bob@example.com) is=20
> reachable at=20
> > sips:bob@bobphone.example.com,
>=20
> Move "(bob@example.com)" to after "If Bob".
>=20
>=20
> > Furthermore, if Bob wants to ensure that every request=20
> delivered to it=20
> > be always transported over TLS, Bob can use [I-D.ietf-sip-outbound]=20
> > when registering.
>=20
> Use "to him" instead of "to it".
>=20
>=20
> > However, if Bob had registered instead with a SIP contact=20
> header field=20
> > instead of a SIPS contact header field (e.g.,=20
> > sip:bob@bobphone.example.com), then a request to AOR
>=20
> I suggest this instead:
>=20
> >>> However, if Bob had registered with a SIP Contact header field=20
> >>> instead of a SIPS Contact header field (e.g.,=20
> >>> sip:bob@bobphone.example.com), then a request to the AOR
>=20
>=20
> > 3.3.  Usage of tls transport parameter and TLS Via parameter
>=20
> Suggestion:
>=20
> >>> 3.3.  Usage of the transport=3Dtls URI parameter and the TLS Via=20
> >>> parameter
>=20
>=20
> > If the Request-URI is a SIP URI, a sips option-tag in a=20
> Require header=20
> > field MUST NOT be used, and a Supported header field MUST be used=20
> > instead.  If a UAS receives a request with the sips option-tag in a=20
> > Supported or Require header field and it accepts the=20
> registration, it=20
> > MUST include the sips option-tag in Supported or Require=20
> header in a=20
> > 200 (OK) response.
>=20
> Since this is talking about registration, I assume that=20
> "request" should be "REGISTER request".
>=20
>=20
> > When a target refresh occurs within a dialog (e.g., re-INVITE,=20
> > UPDATE), unless there is a need to change it, the UAC and UAS MUST=20
> > include a contact header field with a SIPS URI if the=20
> original request=20
> > used a SIPS Request-URI.
>=20
> What exactly does "a need" mean here?
>=20
>=20
> > 4.1.5.  Usage of tls transport parameter
>=20
> Suggestion:
>=20
> >>> 4.1.5.  Usage of the transport=3Dtls parameter
>=20
>=20
> > Specifically, when a proxy receives a request with a SIPS Request-=20
> > URI, the proxy MUST forward or retarget the request to a SIPS=20
> > Request-URI.  If the target UAS had registered previously=20
> using a SIP=20
> > Contact header field instead of a SIPS Contact header=20
> field, the proxy=20
> > MUST NOT forward the request to the URI indicated in the=20
> SIPS Contact=20
> > header field.  If the proxy needs to reject the request for that=20
> > reason, it MUST reject it with a 404 (Not Found).
>=20
> Shouldn't this read "the SIP Contact header field"?
>=20
>=20
> > Proxies can use the sips option-tag in Supported, Require=20
> and Proxy-=20
> > Require header fields to detect UAs that do not conform to this=20
> > specification.
>=20
> How would a proxy use the Proxy-Require header to detect what=20
> a UA supports?
>=20
>=20
> > The proxy MAY instead map the request with a 416 (Unsupported URI=20
> > Scheme)
>=20
> Where did the word "map" come from? I suggest "respond to".
>=20
>=20
> > Using a Redirect Server instead of a Proxy, with TLS has some=20
> > limitations that has to be taken into account.
>=20
> Suggestion:
>=20
> >>> Using a Redirect Server with TLS instead of a Proxy has some=20
> >>> limitations that have to be taken into account.
>=20
>=20
> > When a redirect server receives a request with a SIPS=20
> Request-URI, the=20
> > redirect server MAY redirect with a 3XX response to either=20
> a SIP or a=20
> > SIPS Contact header field.  If the target UAS had registered=20
> > previously using a SIPS Contact header field, the redirect server=20
> > SHOULD return a SIPS Contact header field to "upgrade" to=20
> SIPS if it=20
> > is in an environment where TLS is usable (as described in=20
> the previous=20
> > paragraph).
>=20
> There is no "upgrade" here. Both the request and the=20
> registration are SIPS already.
>=20
>=20
> In the call flow chart in section 5.1, the image for the=20
> second 200 OK for each REGISTER points the wrong way.
>=20
>=20
> In general, I feel that I don't understand the reasoning=20
> behind when to respond 403 and when to respond 404 in this draft.
>=20
>=20
> The rest of my nits is minor stuff like typos, incorrect=20
> pluralization, capitalization errors, etc. I attach a diff=20
> below. Note that the diff also contains a few of my notes=20
> (and the above changes), so don't apply it indiscriminately.
>=20
> Hans
>=20
> --=20
> Hans Persson <hasse@ingate.com>    Ingate - Firewalls with SIP & NAT
> Ingate Systems AB  +46 13 210857   http://www.ingate.com/
>=20
> Private: <unicorn@lysator.liu.se>  http://www.lysator.liu.se/~unicorn/
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Fri Apr 27 19:14:17 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhZdb-00061z-SN; Fri, 27 Apr 2007 19:14:03 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhZda-00061r-7q
	for sip-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 19:14:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhZdZ-00061g-IF
	for sip@ietf.org; Fri, 27 Apr 2007 19:14:01 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhZdY-00081h-6s
	for sip@ietf.org; Fri, 27 Apr 2007 19:14:01 -0400
Received: from [192.168.2.103] (rcdn4-dmznat-gw1-nat-27.cisco.com
	[12.5.186.27]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3RMKur4001518
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Fri, 27 Apr 2007 17:20:57 -0500
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1037E9B4@zrc2hxm0.corp.nortel.com>
References: <45FE0336.8010506@cisco.com>
	<1177686902.24685.3.camel@eeek.ingate.se>
	<1ECE0EB50388174790F9694F77522CCF1037E9B4@zrc2hxm0.corp.nortel.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <C2E79FAC-BDE7-49C7-B42A-9C31029D8C90@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] Re: draft-ietf-sip-sips-03
Date: Fri, 27 Apr 2007 18:13:43 -0500
To: Francois Audet <audet@nortel.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: SIP IETF <sip@ietf.org>, Hans Persson <hasse@ingate.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 27, 2007, at 4:03 PM, Francois Audet wrote:

>
> Basically, I've used 403 (Forbidden) when a UAC tries to register  
> with the wrong
> scheme in the Contact.
>
> And I've used 404 (Not Found) when a UAC sends a non-REGISTER  
> request to a SIP URI when only a SIPS URI exists for that resource.  
> I used to have 403 for that, but I received
> some comments from somebody on the list that 404 (Not Found) would  
> be more appropriate.
>
> I don't feel strongly about this issue.
>
> If anybody has any ideas, please go ahead.
>

Nonchair comment:

If we agree that SIP and SIPS point at the same thing, then rejecting  
a SIP request with a 404 when there is an "equivalent" registration  
seems wrong. 403 seems better, but what it seems like we need is an  
"Invalid Scheme" response. I'm also tempted by 488 (Not Acceptable  
Here) even though we normally use that for SDP.

Even a 400 (Bad Request) seems better than 404.

--
Dean



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sat Apr 28 02:16:18 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhgDu-0004Hu-Pl; Sat, 28 Apr 2007 02:15:58 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhgDt-0004Hg-2E
	for sip-confirm+ok@megatron.ietf.org; Sat, 28 Apr 2007 02:15:57 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhgDs-0004HY-GM
	for sip@ietf.org; Sat, 28 Apr 2007 02:15:56 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhgDr-0002Ko-5J
	for sip@ietf.org; Sat, 28 Apr 2007 02:15:56 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id 9828B1EC02E;
	Sat, 28 Apr 2007 09:15:53 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 6xZHw-lbz3ul; Sat, 28 Apr 2007 09:15:51 +0300 (EEST)
Received: from taimen (nuclease206.gprs.dnafinland.fi [62.78.108.206])
	by tutpro.com (Postfix) with ESMTP;
	Sat, 28 Apr 2007 09:15:51 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id 9F866AC122; Sat, 28 Apr 2007 09:15:44 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17970.59024.466730.331880@tutpro.com>
Date: Sat, 28 Apr 2007 09:15:44 +0300
To: "Francois Audet" <audet@nortel.com>
Subject: RE: [Sip] Re: draft-ietf-sip-sips-03
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1037E9B4@zrc2hxm0.corp.nortel.com>
References: <45FE0336.8010506@cisco.com>
	<1177686902.24685.3.camel@eeek.ingate.se>
	<1ECE0EB50388174790F9694F77522CCF1037E9B4@zrc2hxm0.corp.nortel.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Cc: SIP IETF <sip@ietf.org>, Hans Persson <hasse@ingate.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Francois Audet writes:

 > And I've used 404 (Not Found) when a UAC sends a non-REGISTER request
 > to a SIP URI when only a SIPS URI exists for that resource.

apache web server returns 403 in that case.

-- juha


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sat Apr 28 03:54:57 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hhhlb-0007zC-Fe; Sat, 28 Apr 2007 03:54:51 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hhhla-0007z3-Dj
	for sip-confirm+ok@megatron.ietf.org; Sat, 28 Apr 2007 03:54:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhhlW-0007we-Ip
	for sip@ietf.org; Sat, 28 Apr 2007 03:54:46 -0400
Received: from mail.gmx.net ([213.165.64.20])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HhhlW-0003o7-3p
	for sip@ietf.org; Sat, 28 Apr 2007 03:54:46 -0400
Received: (qmail invoked by alias); 28 Apr 2007 07:54:44 -0000
Received: from ip-90-187-149-39.web.vodafone.de (EHLO [90.187.149.39])
	[90.187.149.39]
	by mail.gmx.net (mp054) with SMTP; 28 Apr 2007 09:54:44 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18h2PVpc4MhpJBOzG0Fr/GDslx5zE+SWLdw05ysLT
	hFHySs7v+6fCyu
Message-ID: <4632FDC0.8020100@gmx.net>
Date: Sat, 28 Apr 2007 09:54:40 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Ted Hardie <hardie@qualcomm.com>
Subject: Re: [Sip] Location-conveyance: ISSUE #2 - emergency calls
References: <5D1A7985295922448D5550C94DE29180010BF7F6@DEEXC1U01.de.lucent.com>
	<p06240608c25720d711ab@[76.102.225.135]>
In-Reply-To: <p06240608c25720d711ab@[76.102.225.135]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f
Cc: IETF SIP List <sip@ietf.org>, "Drage,
	Keith \(Keith\)" <drage@alcatel-lucent.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi Ted,

Ted Hardie wrote:
> At 2:32 AM +0200 4/27/07, Drage, Keith \(Keith\) wrote:
>   
>> (As SIP WG chair)
>>
>> During the review of the WGLC comments, we have identified some issues
>> where we need consensus calls on the list. These are in one call per
>> message.
>>
>> There is an amount of text (primarily section 6) within
>> draft-ietf-sip-location-conveyance related to emergency calls. It is
>> proposed to remove this text on the basis that there are charter items
>> within the IETF ECRIT working group that fully specify this application
>> of location conveyance to this particular purpose. The editor's will
>> make sure that all the removed text is reflected in appropriately in the
>> concerned ECRIT documents.
>>     
>
> I don't think we can answer this question without the actual bits to
> be removed.  Can you cite in more detail?
>   
I would imagine that at least Section 6 "Special Considerations for 
Emergency Calls" would go away.
Additionally, the security consideration section might also be affected.


> I'd also like to point out that section 6 has a number of  elements
> where the baseline assumption of SIP and ECRIT may differ.  This,
> for example:
>
>     Thus S/MIME protection of location MUST NOT
>    be used.  TLS protection of location SHOULD be used, however, if
>    establishment of the TLS connection fails, the call set-up
>    operation, including location conveyance, MUST be retried without
>    TLS.
>
> The context in SIP and the larger document here makes it clear
> that "S/MIME protection of location" means encrypting the location,
> rather than signing it.  But location signing is a topic of interest to
> ECRIT, and the resulting baseline assumptions may be different.
> Increased clarity on exactly what is meant will hopefully result,
> but remember this will end up in some document with a bunch of
> other context to it.
>
> I also believe that this section:
>
>   Both the "retransmission-allowed" and "routing-query-allowed" SHOULD
>    be set to "yes".  Querying for routing may be performed by proxies
>    providing a routing service for emergency calls even if
>    retransmission-allowed or routing-query-allowed is set to "no" or is
>    not present.  Proxies routing on the location MUST set the
>    "message-routed-on-this-uri" parameter.
>
> would have to be substantially re-written to fit into phonebcp (presuming
> that is where it lands).  To make sense there, I believe it would have to repeat
> context from location-conveyance (even with the existing normative
> reference).  That's always an invitation to things getting out of synch
> in the future, and has to be considered.
>
> Put another way, I don't think you're going to be able to just shift
> the text en masse and be done.
>   

I agree that a simple copy-and-paste operation from the SIP Location 
Conveyance document to the Phone BCP is not sufficient.

I do, however, believe that it is better not to speak about emergency 
services in this document since we already have the Phone BCP. With the 
same argument I would like to remove Section 5.3 "Emergency Shape 
Representations" from draft-ietf-geopriv-pdif-lo-profile-06.txt.

Ciao
Hannes

> 			
> 			regards,
> 					Ted
>
>
>
>   
>> We will assume that this removal represents WG consensus unless we hear
>> otherwise from the WG in 7 calendar days from the posting of this
>> message.
>>
>> Regards
>>
>> Keith
>>
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use sip-implementors@cs.columbia.edu for questions on current sip
>> Use sipping@ietf.org for new developments on the application of sip
>>     
>
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>   



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sat Apr 28 05:21:22 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hhj7B-0005bk-G6; Sat, 28 Apr 2007 05:21:13 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hhj7A-0005bd-3f
	for sip-confirm+ok@megatron.ietf.org; Sat, 28 Apr 2007 05:21:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhj79-0005bV-Pu
	for sip@ietf.org; Sat, 28 Apr 2007 05:21:11 -0400
Received: from smtp3.versatel.nl ([62.58.50.90])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hhj78-0000Jw-B8
	for sip@ietf.org; Sat, 28 Apr 2007 05:21:11 -0400
Received: (qmail 10614 invoked by uid 0); 28 Apr 2007 09:20:47 -0000
Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER)
	([87.212.11.198]) (envelope-sender <jbemmel@zonnet.nl>)
	by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP
	for < >; 28 Apr 2007 09:20:47 -0000
Message-ID: <001401c78976$5f8dc020$0601a8c0@BEMBUSTER>
From: "Jeroen van Bemmel" <jbemmel@zonnet.nl>
To: "Brian Rosen" <br@brianrosen.net>,
	"'Robert Sparks'" <rjsparks@estacado.net>,
	"'IETF SIP List'" <sip@ietf.org>, <sip-implementors@cs.columbia.edu>,
	<discussion@sipforum.org>
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com>
Subject: Re: [Sip] SIPit 20 survey summary
Date: Sat, 28 Apr 2007 11:19:50 +0200
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

A point for discussion: I believe below is evidence that the complexity of 
implementation may hinder deployment of emergency services, and may even be 
a root cause of things breaking down at a critical moment. People's lives 
may depend on a proxy interpreting location information properly

Especially for the use case of emergency calls, would it not be wise to 
select a much more simple approach/syntax, e.g.:
Emergency-Location: lat=x; lon=y

So no XML, no mime/multipart, as simple as possible (no complex semantics, 
usage-rules etc), something to reduce the barrier of 
implementation/deployment, and to reduce the risk for interop issues?

Regards,
Jeroen

Brian Rosen wrote:
> I'd like to point out one thing about this:
>
>> This is how they answered for multipart/mime:
>>     2% I break if someone sends me multipart/mime
>>    24% I pretend multipart/mime doesn't exist if someone sends it to
>>    me 24% I ignore multipart/mime but will proxy it or hand it to my
>> application if it shows up
>>    10% I try to do something useful with multipart/mime I receive,
>> but I never send it
>>     4% I ignore multipart/mime that I receive, but I try to do
>> something useful with multipart/mime I send
>>    24% I try to do something useful with multipart/mime I send and
>> receive
>>    12% Other
>
> Moving forward, SIP UAs and proxies will be required to support
> location-conveyance (currently draft-ietf-sip-location-conveyance-07)
> in order to support location for emergency calls (citizen to
> authority, like 1-1-2 or
> 9-1-1).  -conveyance requires multipart support.
>
> The consequences of not supporting emergency call location will be
> serious. I believe it is likely that there will eventually be
> regulatory requirements to support emergency calls in some
> jurisdictions.  Upgrades to several components of today's
> infrastructure will be needed before this all works, but stack
> vendors and UA developers should put multipart (and
> location-conveyance) on their development plans for next year at the
> latest.
>
> Brian
>
>
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip 



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sat Apr 28 05:35:59 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhjLQ-0006AA-Ox; Sat, 28 Apr 2007 05:35:56 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhjLO-0006A5-O7
	for sip-confirm+ok@megatron.ietf.org; Sat, 28 Apr 2007 05:35:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhjLO-00069x-EF
	for sip@ietf.org; Sat, 28 Apr 2007 05:35:54 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhjLN-00026M-2z
	for sip@ietf.org; Sat, 28 Apr 2007 05:35:54 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id 3C5D51EC02E;
	Sat, 28 Apr 2007 12:35:52 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id g+OSXeMrocRJ; Sat, 28 Apr 2007 12:35:50 +0300 (EEST)
Received: from taimen (nuclease87.gprs.dnafinland.fi [62.78.108.87])
	by tutpro.com (Postfix) with ESMTP;
	Sat, 28 Apr 2007 12:35:50 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id 4DE97AC0ED; Sat, 28 Apr 2007 12:35:43 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17971.5486.819002.96466@tutpro.com>
Date: Sat, 28 Apr 2007 12:35:42 +0300
To: "Jeroen van Bemmel" <jbemmel@zonnet.nl>
Subject: Re: [Sip] SIPit 20 survey summary
In-Reply-To: <001401c78976$5f8dc020$0601a8c0@BEMBUSTER>
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com>
	<001401c78976$5f8dc020$0601a8c0@BEMBUSTER>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: 'IETF SIP List' <sip@ietf.org>, discussion@sipforum.org,
	sip-implementors@cs.columbia.edu, 'Robert Sparks' <rjsparks@estacado.net>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Jeroen van Bemmel writes:

 > Especially for the use case of emergency calls, would it not be wise to 
 > select a much more simple approach/syntax, e.g.:
 > Emergency-Location: lat=x; lon=y
 > 
 > So no XML, no mime/multipart, as simple as possible (no complex semantics, 
 > usage-rules etc), something to reduce the barrier of 
 > implementation/deployment, and to reduce the risk for interop issues?

i fully agree with this.  we should follow KISS principle here.  it is
highly unlikely that sip ua vendors will even TRY implement such a
complex protocol.  

another reason why it will not get implemented is that sip uas don't
know where they are located.  gps does not work well indoors and mobile
operators at least here have refused to make public coordinates of their
base stations.

-- juha


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sat Apr 28 09:36:45 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hhn6A-0004Jd-5I; Sat, 28 Apr 2007 09:36:26 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hhn68-0004HD-IU
	for sip-confirm+ok@megatron.ietf.org; Sat, 28 Apr 2007 09:36:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhn68-0004H5-8z
	for sip@ietf.org; Sat, 28 Apr 2007 09:36:24 -0400
Received: from smtp1.versatel.nl ([62.58.50.88])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hhn67-0002ZZ-R0
	for sip@ietf.org; Sat, 28 Apr 2007 09:36:24 -0400
Received: (qmail 15637 invoked by uid 0); 28 Apr 2007 13:37:35 -0000
Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER)
	([87.212.11.198]) (envelope-sender <jbemmel@zonnet.nl>)
	by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP
	for < >; 28 Apr 2007 13:37:35 -0000
Message-ID: <006901c7899a$06bf7cd0$0601a8c0@BEMBUSTER>
From: "Jeroen van Bemmel" <jbemmel@zonnet.nl>
To: <sip@ietf.org>
Date: Sat, 28 Apr 2007 15:35:03 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: 
Subject: [Sip] GRUU-13 : algorithm in annex A.2 does not distinguish between
	multiple outbound contacts
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1603064042=="
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1603064042==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0065_01C789AA.CA1FB630"

This is a multi-part message in MIME format.

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

Jonathan,

A minor remark about the temporary GRUU algorithm in A.2: if the UAC is 
using outbound and registers 2 Contacts under the same AoR and instance-id, 
the algorithm in A.2 currently cannot distinguish between those contacts 
(since the temporary GRUU only contains an index which resolves to an 
AoR+instance combination). Therefore, if the Contacts URIs are different 
(for example: different user part) the proxy is not able to reproduce the 
correct URI when rewriting the request URI.

Concretely: when a UAC registers e.g.
Contact: <sip:callee-001@192.0.2.1>
     ;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
     ;reg-id=1Contact: <sip:callee-002@192.0.2.1>
     ;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
     ;reg-id=2the proxy returns two distinct temporary GRUUs. However, 
regardless of which temporary GRUU the UA chooses to use, the proxy cannot 
determine whether to rewrite to "callee-001" or "callee-002"

This can easily be remedied, e.g. by including the reg-id in the mapping

Regards,
Jeroen 

------=_NextPart_000_0065_01C789AA.CA1FB630
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.6000.16414" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Jonathan,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>A minor remark about the temporary GRUU =
algorithm=20
in A.2: if the UAC is using outbound and registers 2 Contacts under the =
same AoR=20
and instance-id, the algorithm in A.2 currently cannot distinguish =
between those=20
contacts (since the temporary GRUU only contains an index which resolves =
to an=20
AoR+instance combination). Therefore, if the Contacts URIs are different =
(for=20
example: different user part)&nbsp;the proxy is not able to reproduce =
the=20
correct URI when rewriting the request URI.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Concretely: when a UAC registers =
e.g.</FONT></DIV>
<DIV><PRE><FONT face=3DArial size=3D2>Contact: =
&lt;sip:callee-001@192.0.2.1&gt;
     =
;+sip.instance=3D"&lt;urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128&gt;"
     ;reg-id=3D1</FONT></PRE><PRE><PRE><FONT face=3DArial =
size=3D2>Contact: &lt;sip:callee-002@192.0.2.1&gt;
     =
;+sip.instance=3D"&lt;urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128&gt;"
     ;reg-id=3D2</FONT></PRE></PRE></DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2>the proxy returns two distinct =
temporary GRUUs.=20
However, regardless of which temporary GRUU the UA chooses to use, the =
proxy=20
cannot determine whether to rewrite to "callee-001" or =
"callee-002"</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>This can easily be remedied, e.g. by =
including the=20
reg-id in the mapping</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Jeroen</FONT></DIV></DIV></BODY></HTML>

------=_NextPart_000_0065_01C789AA.CA1FB630--




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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============1603064042==--






From sip-bounces@ietf.org Sat Apr 28 09:56:16 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhnPL-0000c3-Jk; Sat, 28 Apr 2007 09:56:15 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhnPJ-0000bs-Nl
	for sip-confirm+ok@megatron.ietf.org; Sat, 28 Apr 2007 09:56:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhnPJ-0000bj-EJ
	for sip@ietf.org; Sat, 28 Apr 2007 09:56:13 -0400
Received: from smtp3.versatel.nl ([62.58.50.90])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhnPH-0007p2-Qc
	for sip@ietf.org; Sat, 28 Apr 2007 09:56:13 -0400
Received: (qmail 11812 invoked by uid 0); 28 Apr 2007 13:55:49 -0000
Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER)
	([87.212.11.198]) (envelope-sender <jbemmel@zonnet.nl>)
	by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP
	for < >; 28 Apr 2007 13:55:49 -0000
Message-ID: <007901c7899c$cb87da10$0601a8c0@BEMBUSTER>
From: "Jeroen van Bemmel" <jbemmel@zonnet.nl>
To: <sip@ietf.org>
References: <006901c7899a$06bf7cd0$0601a8c0@BEMBUSTER>
Subject: Re: [Sip] GRUU-13 : algorithm in annex A.2 does not distinguish
	betweenmultiple outbound contacts
Date: Sat, 28 Apr 2007 15:54:52 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0132928167=="
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0132928167==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0075_01C789AD.8EEA8470"

This is a multi-part message in MIME format.

------=_NextPart_000_0075_01C789AD.8EEA8470
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Same remark applies to public GRUU generation: instance-id in 'gr' parameter 
may not be sufficient to select the right contact URI for rewriting, when 
UAC uses outbound.

Regards,
Jeroen
  ----- Original Message ----- 
  From: Jeroen van Bemmel
  To: sip@ietf.org
  Sent: Saturday, April 28, 2007 3:35 PM
  Subject: [Sip] GRUU-13 : algorithm in annex A.2 does not distinguish 
betweenmultiple outbound contacts


  Jonathan,

  A minor remark about the temporary GRUU algorithm in A.2: if the UAC is 
using outbound and registers 2 Contacts under the same AoR and instance-id, 
the algorithm in A.2 currently cannot distinguish between those contacts 
(since the temporary GRUU only contains an index which resolves to an 
AoR+instance combination). Therefore, if the Contacts URIs are different 
(for example: different user part) the proxy is not able to reproduce the 
correct URI when rewriting the request URI.

  Concretely: when a UAC registers e.g.
Contact: <sip:callee-001@192.0.2.1>
     ;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
     ;reg-id=1Contact: <sip:callee-002@192.0.2.1>
     ;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
     ;reg-id=2the proxy returns two distinct temporary GRUUs. However, 
regardless of which temporary GRUU the UA chooses to use, the proxy cannot 
determine whether to rewrite to "callee-001" or "callee-002"

  This can easily be remedied, e.g. by including the reg-id in the mapping

  Regards,
  Jeroen


------------------------------------------------------------------------------


  _______________________________________________
  Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
  This list is for NEW development of the core SIP Protocol
  Use sip-implementors@cs.columbia.edu for questions on current sip
  Use sipping@ietf.org for new developments on the application of sip 

------=_NextPart_000_0075_01C789AD.8EEA8470
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.6000.16414" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Same remark applies to public GRUU =
generation:=20
instance-id in 'gr' parameter may not be sufficient to select the right =
contact=20
URI for rewriting, when UAC uses outbound.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Jeroen</FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Djbemmel@zonnet.nl href=3D"mailto:jbemmel@zonnet.nl">Jeroen =
van=20
  Bemmel</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A title=3Dsip@ietf.org=20
  href=3D"mailto:sip@ietf.org">sip@ietf.org</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Saturday, April 28, 2007 =
3:35=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> [Sip] GRUU-13 : =
algorithm in=20
  annex A.2 does not distinguish betweenmultiple outbound contacts</DIV>
  <DIV><BR></DIV>
  <DIV><FONT face=3DArial size=3D2>Jonathan,</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>A minor remark about the temporary =
GRUU algorithm=20
  in A.2: if the UAC is using outbound and registers 2 Contacts under =
the same=20
  AoR and instance-id, the algorithm in A.2 currently cannot distinguish =
between=20
  those contacts (since the temporary GRUU only contains an index which =
resolves=20
  to an AoR+instance combination). Therefore, if the Contacts URIs are =
different=20
  (for example: different user part)&nbsp;the proxy is not able to =
reproduce the=20
  correct URI when rewriting the request URI.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Concretely: when a UAC registers=20
e.g.</FONT></DIV>
  <DIV><PRE><FONT face=3DArial size=3D2>Contact: =
&lt;sip:callee-001@192.0.2.1&gt;
     =
;+sip.instance=3D"&lt;urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128&gt;"
     ;reg-id=3D1</FONT></PRE><PRE><PRE><FONT face=3DArial =
size=3D2>Contact: &lt;sip:callee-002@192.0.2.1&gt;
     =
;+sip.instance=3D"&lt;urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128&gt;"
     ;reg-id=3D2</FONT></PRE></PRE></DIV>
  <DIV>
  <DIV><FONT face=3DArial size=3D2>the proxy returns two distinct =
temporary GRUUs.=20
  However, regardless of which temporary GRUU the UA chooses to use, the =
proxy=20
  cannot determine whether to rewrite to "callee-001" or=20
  "callee-002"</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>This can easily be remedied, e.g. by =
including=20
  the reg-id in the mapping</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Jeroen</FONT></DIV></DIV>
  <P>
  <HR>

  <P></P>_______________________________________________<BR>Sip mailing=20
  list&nbsp; https://www1.ietf.org/mailman/listinfo/sip<BR>This list is =
for NEW=20
  development of the core SIP Protocol<BR>Use =
sip-implementors@cs.columbia.edu=20
  for questions on current sip<BR>Use sipping@ietf.org for new =
developments on=20
  the application of sip</BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0075_01C789AD.8EEA8470--




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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============0132928167==--






From sip-bounces@ietf.org Sat Apr 28 11:19:16 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhohU-0002JX-2b; Sat, 28 Apr 2007 11:19:04 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhohS-0002JQ-LH
	for sip-confirm+ok@megatron.ietf.org; Sat, 28 Apr 2007 11:19:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhohS-0002JI-Bm
	for sip@ietf.org; Sat, 28 Apr 2007 11:19:02 -0400
Received: from smtp2.versatel.nl ([62.58.50.89])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhohR-0007Hi-Te
	for sip@ietf.org; Sat, 28 Apr 2007 11:19:02 -0400
Received: (qmail 29757 invoked by uid 0); 28 Apr 2007 15:19:00 -0000
Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER)
	([87.212.11.198]) (envelope-sender <jbemmel@zonnet.nl>)
	by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP
	for < >; 28 Apr 2007 15:19:00 -0000
Message-ID: <00ad01c789a8$5de68d10$0601a8c0@BEMBUSTER>
From: "Jeroen van Bemmel" <jbemmel@zonnet.nl>
To: <sip@ietf.org>
Date: Sat, 28 Apr 2007 17:17:41 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: Cullen Jennings <fluffy@cisco.com>, Rohan Mahy <rohan@ekabal.com>
Subject: [Sip] outbound-08 : using different Contact URIs for different
	flows?
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2059817126=="
Errors-To: sip-bounces@ietf.org

This is a multi-part message in MIME format.

--===============2059817126==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00A9_01C789B9.20FA7B30"

This is a multi-part message in MIME format.

------=_NextPart_000_00A9_01C789B9.20FA7B30
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

While trying to implement GRUU and outbound in combination, I stumbled upon 
a minor issue: what if the UAC uses different Contact URIs when registering 
multiple flows. The examples in outbound don't do this, but there is no 
explicit statement that this is not allowed, and the example in 3.2 
(line1@192.168.0.2>;reg-id=1) could be seen as suggesting that the 
registration with reg-id=2 would use "line2"

See my previous mail: for GRUU this could mean that the authorative proxy 
cannot select the right URI to rewrite with, there can be an inconsistency 
between the temporary GRUU the UAC selected (associated with a specific 
contact) and the request URI received.

One solution may be to adapt the algorithm used to generate temporary GRUUs. 
A second option, which is perhaps simpler, is to simply state in outbound 
that the UAC MUST use identical Contact URIs when registering multiple flows 
(in section 4.2), and that the authoritative proxy MAY select any one of the 
registered Contact URIs to rewrite with (e.g. needed to cover transitional 
cases where the UAC obtains a new IP address and starts re-registering)

Regards,
Jeroen


------=_NextPart_000_00A9_01C789B9.20FA7B30
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.6000.16414" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>All,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>While trying to implement GRUU and =
outbound in=20
combination, I stumbled upon a minor issue: what if the UAC uses =
different=20
Contact URIs when registering multiple&nbsp;flows. The examples in =
outbound=20
don't do this, but there is no explicit statement that this is not =
allowed, and=20
the example in 3.2 (<A=20
href=3D"mailto:line1@192.168.0.2>;reg-id=3D1">line1@192.168.0.2&gt;;reg-i=
d=3D1</A>)=20
</FONT>could be seen as suggesting that the registration with reg-id=3D2 =
would use=20
"line2"</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>See my previous mail: for GRUU this =
could mean that=20
the authorative proxy cannot select the right URI to rewrite with, there =
can be=20
an inconsistency between the temporary GRUU the UAC selected (associated =
with a=20
specific contact) and the request URI received.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>One solution may be to adapt the =
algorithm used to=20
generate temporary GRUUs. A second option, which is perhaps simpler,=20
</FONT><FONT face=3DArial size=3D2>is to simply state in outbound that =
the UAC MUST=20
use identical Contact URIs when registering multiple flows (in section =
4.2), and=20
that the authoritative proxy MAY select any one of the registered =
Contact URIs=20
to rewrite with (e.g. needed to cover transitional cases where the UAC =
obtains a=20
new IP address and starts re-registering)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Jeroen</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_00A9_01C789B9.20FA7B30--




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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============2059817126==--






From sip-bounces@ietf.org Sat Apr 28 14:05:45 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhrIG-0003dc-3Q; Sat, 28 Apr 2007 14:05:12 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhrID-0003dS-HC
	for sip-confirm+ok@megatron.ietf.org; Sat, 28 Apr 2007 14:05:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhrID-0003dK-7M
	for sip@ietf.org; Sat, 28 Apr 2007 14:05:09 -0400
Received: from smtpauth00.csee.onr.siteprotect.com ([64.26.60.144])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhrIA-00022u-TF
	for sip@ietf.org; Sat, 28 Apr 2007 14:05:09 -0400
Received: from [192.168.1.120] (c-67-162-139-200.hsd1.co.comcast.net
	[67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com)
	by smtpauth00.csee.onr.siteprotect.com (Postfix) with ESMTP id
	F157875805A; Sat, 28 Apr 2007 13:05:05 -0500 (CDT)
Subject: Re: [Sip] SIPit 20 survey summary
From: "Frank W. Miller" <fwmiller@cornfed.com>
To: Jeroen van Bemmel <jbemmel@zonnet.nl>
In-Reply-To: <001401c78976$5f8dc020$0601a8c0@BEMBUSTER>
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com>
	<001401c78976$5f8dc020$0601a8c0@BEMBUSTER>
Content-Type: text/plain
Date: Sat, 28 Apr 2007 12:04:51 -0600
Message-Id: <1177783491.3023.2.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Cc: 'IETF SIP List' <sip@ietf.org>, discussion@sipforum.org,
	sip-implementors@cs.columbia.edu, 'Robert Sparks' <rjsparks@estacado.net>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


Amen.

FM


On Sat, 2007-04-28 at 11:19 +0200, Jeroen van Bemmel wrote:
> A point for discussion: I believe below is evidence that the complexity of 
> implementation may hinder deployment of emergency services, and may even be 
> a root cause of things breaking down at a critical moment. People's lives 
> may depend on a proxy interpreting location information properly
> 
> Especially for the use case of emergency calls, would it not be wise to 
> select a much more simple approach/syntax, e.g.:
> Emergency-Location: lat=x; lon=y
> 
> So no XML, no mime/multipart, as simple as possible (no complex semantics, 
> usage-rules etc), something to reduce the barrier of 
> implementation/deployment, and to reduce the risk for interop issues?
> 
> Regards,
> Jeroen
> 
> Brian Rosen wrote:
> > I'd like to point out one thing about this:
> >
> >> This is how they answered for multipart/mime:
> >>     2% I break if someone sends me multipart/mime
> >>    24% I pretend multipart/mime doesn't exist if someone sends it to
> >>    me 24% I ignore multipart/mime but will proxy it or hand it to my
> >> application if it shows up
> >>    10% I try to do something useful with multipart/mime I receive,
> >> but I never send it
> >>     4% I ignore multipart/mime that I receive, but I try to do
> >> something useful with multipart/mime I send
> >>    24% I try to do something useful with multipart/mime I send and
> >> receive
> >>    12% Other
> >
> > Moving forward, SIP UAs and proxies will be required to support
> > location-conveyance (currently draft-ietf-sip-location-conveyance-07)
> > in order to support location for emergency calls (citizen to
> > authority, like 1-1-2 or
> > 9-1-1).  -conveyance requires multipart support.
> >
> > The consequences of not supporting emergency call location will be
> > serious. I believe it is likely that there will eventually be
> > regulatory requirements to support emergency calls in some
> > jurisdictions.  Upgrades to several components of today's
> > infrastructure will be needed before this all works, but stack
> > vendors and UA developers should put multipart (and
> > location-conveyance) on their development plans for next year at the
> > latest.
> >
> > Brian
> >
> >
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip 
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sat Apr 28 16:00:32 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hht5m-0004Fl-Nl; Sat, 28 Apr 2007 16:00:26 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hht5k-0004FU-F0
	for sip-confirm+ok@megatron.ietf.org; Sat, 28 Apr 2007 16:00:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hht5k-0004FM-5O
	for sip@ietf.org; Sat, 28 Apr 2007 16:00:24 -0400
Received: from ihemail2.lucent.com ([135.245.0.35])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hht5i-0001qG-Sw
	for sip@ietf.org; Sat, 28 Apr 2007 16:00:24 -0400
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1])
	by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l3SK0H8f029925
	for <sip@ietf.org>; Sat, 28 Apr 2007 15:00:22 -0500 (CDT)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by
	ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 28 Apr 2007 15:00:18 -0500
Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by
	DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 28 Apr 2007 22:00:15 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: [Sip] Location-conveyance: ISSUE #3 - multiple locations
Date: Sat, 28 Apr 2007 22:00:15 +0200
Message-ID: <5D1A7985295922448D5550C94DE29180010BFC06@DEEXC1U01.de.lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Location-conveyance: ISSUE #3 - multiple locations
Thread-Index: AceJxeRiWYVqzczWSD+GBqRQT3G6eg==
From: "Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>
To: "IETF SIP List" <sip@ietf.org>
X-OriginalArrivalTime: 28 Apr 2007 20:00:15.0442 (UTC)
	FILETIME=[D6912320:01C789CF]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

(As SIP WG chair)

During the review of the WGLC comments, we have identified some issues
where we need consensus calls on the list. These are in one call per
message.

We had a number of comments that it was not clear whether a message
could contain multiple locations, and if they were, what were the
procedures.

On the call we identified what we believe the way forward in this area,
which is summarised by the following statements:

-	location conveyance should support the delivery of multiple
locations;

-	the document will make no recommendations as to how the
recipient chooses=20
which location to use. This is regarded as specific to the using
application,=20
and therefore beyond the scope of the protocol extension;

-	the recipient should attempt to make use of all the locations
given, and=20
should only respond with a 424 response if it is unable to use any of
those=20
locations. This includes resolving all and any locations by reference;

-	as a result of the above, any 424 response is a collective
statement about=20
all the locations given in the request rather than any specific location
in the=20
request.

We will assume that this represents WG consensus unless we hear
otherwise from the WG in 7 calendar days from the posting of this
message.=20

Obviously if the WG has an alternative view, some proposal of the
alternative way forward and the expected impact on the text would be
entirely appropriate.

Regards

Keith


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip

From sip-bounces@ietf.org Sat Apr 28 16:00:32 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hht5f-0004Ee-Vu; Sat, 28 Apr 2007 16:00:19 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hht5e-0004EY-Sy
	for sip-confirm+ok@megatron.ietf.org; Sat, 28 Apr 2007 16:00:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hht5e-0004EQ-JF
	for sip@ietf.org; Sat, 28 Apr 2007 16:00:18 -0400
Received: from ihemail2.lucent.com ([135.245.0.35])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hht5d-0001oi-TO
	for sip@ietf.org; Sat, 28 Apr 2007 16:00:18 -0400
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1])
	by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l3SK0Hp4029918
	for <sip@ietf.org>; Sat, 28 Apr 2007 15:00:17 -0500 (CDT)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by
	ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 28 Apr 2007 15:00:17 -0500
Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by
	DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 28 Apr 2007 22:00:14 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Sat, 28 Apr 2007 22:00:14 +0200
Message-ID: <5D1A7985295922448D5550C94DE29180010BFC05@DEEXC1U01.de.lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Notes of review conference call for
	draft-ietf-sip-location-conveyance
Thread-Index: AceJxSYqNKKJyTZUSq2xGg4UXJDB3g==
From: "Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>
To: "IETF SIP List" <sip@ietf.org>
X-OriginalArrivalTime: 28 Apr 2007 20:00:14.0207 (UTC)
	FILETIME=[D5D4B0F0:01C789CF]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f251f249fc9a04067ce354aa0943ab98
Subject: [Sip] Notes of review conference call for
	draft-ietf-sip-location-conveyance
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

The following are the notes of the conference call held on location
conveyance held last week. Comments are welcome, but please address any
comments on anything but accuracy to a separate thread (i.e. change the
subject of your email).

These will also be posted on the review site in due course.

Regards

Keith

Notes of review team call on WGLC comments on draft-ietf-sip-location-
conveyance-07 held on 25th April 2007

1)	Roll call

The following participated in the call.
Richard Barnes
Keith Drage (moderator and scribe)
Mark Lindsey
James Polk (document editor)
Brian Rosen (document editor)
Henning Schulzrinne
Hannes Tschofenig
Joszef Varga

2)	Agenda bash

No changes.

Keith noted that the key questions mentioned in the agenda were only his
view of=20
the comments made, in order to give some direction to the discussion,
and people=20
should refer to the comment in the case of dispute over the meaning.

3)	Methodology

Keith outlined the methodology of the review calls, which was:

-	to give a first discussion of key points;
-	if new comments arise from discussion, they should be identified
verbally=20
and ensure they are documented;
-	comments discussed can have resolution agreed in the call, or
defer, or=20
take to list, or leave to authors to make a judgement.

Further the review team should try and represent previous consensus of
the=20
working group (SIP or GEOPRIV) as appropriate. Should regard themselves
as=20
acting on behalf of the working group.

4)	=20
Issues relating to multiple locations

Comments: 2, 3, (66), 78, 94, 96, 153, 164

Key questions:=20
-	Do we want multiple locations?
-	If there are multiple locations, which should be used?
-	If a 424 is returned, which location does it relate to?
-	Which location does the warning refer to?
-	In what circumstances can multiple locations cause a call to
fail - or can=20
one be used and ignore the rest?
-	If you have a location by value, do you need to also resolve any
location=20
by reference?
-	Anything different for multiple locations in responses?

After discussion it was agreed that the following would be recommended.
This=20
summary would be taken to the list by Keith for a WG consensus call:

-	location conveyance should support the delivery of multiple
locations;
-	the document will make no recommendations as to how the
recipient chooses=20
which location to use. This is regarded as specific to the using
application,=20
and therefore beyond the scope of the protocol extension;
-	the recipient should attempt to make use of all the locations
given, and=20
should only respond with a 424 response if it is unable to use any of
those=20
locations. This includes resolving all and any locations by reference;
-	as a result of the above, any 424 response is a collective
statement about=20
all the locations given in the request rather than any specific location
in the=20
request.

Action 1/1: Keith to take above list to WG for consensus call, as
direction to=20
the editors.

It was also discussed if we should agreed that if a location is already
present=20
in a request, one should not add another, as it is not possible to
resolve which=20
location sender the 424 response relates to. As this may not be a
restriction=20
based on later discussion of improvements to the error handling, we will
hold=20
this decision until we have resolution of the error handling issues.

There was discussion of Warning header meanings in regard to multiple
locations=20
in error. It was considered that there needs to be some form of
correlation=20
between Warning headers and specific locations. See later in the
discussion for=20
further details of resolution process.

The issues of multiple locations in responses was deferred to later in
the=20
meeting under the "location in responses" agenda point.

5)	Security issues

Comments: 21, 27, 117A, 129C, 129D, 168, 181A, 181B, 137
Key questions:
-	Any issues with mandating multipart MIME?
-	Signing versus encryption issues?
-	Document security issues when retrieving location by reference?
-	Are mechanisms different for LbyrR and LbyV?
-	Is security considerations section adequate?
-	Are self signed certificates out of scope?
-	Is mandating a retry without TLS in scope?

The review team agreed that the extension would assume that conformant=20
implementations supported multipart MIME. This was seen as an
implementation=20
problem of existing specifications, rather than a problem with the=20
specifications themselves. Discussion identified that the real problem
was with=20
gateways which would send an error message to requests containing
multipart MIME.

As regards the signing versus encryption, agreed that clarification was
required=20
in the document, but this was a matter of an editorial pass.

The security for dereferencing related to two issues:

-	security of the reference. Part of this centred around the issue
of=20
whether the reference contained the identity of the user sending the
information.=20
It was agreed that the reference is just a URL, and therefore does not=20
consititute an identity.

-	it is known limitation that when a proxy inserts a location by
reference,=20
that the UA user is not a rule maker (RFC 3693 specifies the rulemaker).
There=20
is some suitable text in the RELO document that covers the same issue.
Hannes is=20
going to send text to the review team

Action 1/2: Hannes to send text to editor's and review team covering
this issue

-	security of the dereferencing procedure. This was regarded as
being out of=20
scope, as the dereferencing protocol was also out of scope.

It is also a known limitation that existing mechanisms do not allow a UA
to=20
request proxy implementation. This is believed to be a separable
problem.=20

Need to spell out that need same protection for location by value and
location=20
by reference in the security considerations. Hanne's point - wants more
text=20
saying TLS is used and "we really mean it". Brian will offer text here.

Action 1/3: Brian to provide text relating to the usage of TLS.

In regard to the adequacy of the security considerations Hannes had
agreed to=20
suggest some text. It was noted that the philosophy of the document was
to put=20
the RFC 2119 language regarding security in the main procedures, and
merely=20
comment on the security provided in the security considerations section.

Action 1/4: Hannes to send text (can be just key points to be covered)
to=20
editor's and review team covering this issue

In regard to the self-signed certificates issue (comment 137) it was
agreed that=20
the appropriate document to cover this issue in regard to location was
draft-
ietf-sip-certs. It was proposed therefore to remove all text in the
document=20
relating to self-signed certifications.

Action 1/5: Keith to post to list stating that the agreement is to
remove and=20
asking for WG consensus.

Action 1/6: Keith to send mail to Cullen Jenning / Jason Fischl
regarding the=20
need of draft-ietf-sip-certs to provide any documentation on this issue.

The issue relating to retry without TLS if the request fails with TLS on
an=20
emergency call was dealt with as part of a general consideration of all=20
emergency call issues in the next agenda item.

6)	Emergency issues

	Comments: 129B, 167A, 169
	Key questions:
	Should we cover emergency at all in this document?

It was agreed that section 6 and therefore all text relating to
emergency calls=20
should be removed. It was agreed that it was the responsibility of ECRIT
to=20
apply location-conveyance to emergency calling applications.=20

Action 1/7: Keith to send mail to list asking for WG consensus to
agreement to=20
remove emergency call text from location-conveyance.

Noted that James was not wonderfully happy with this, and may reraise
the=20
discussion once he sees the impact of the decision on the text.

7)	Response usage

Comments: 29, 150
Key questions:
-	Is location allowed in responses, and if so, what are the
procedures for=20
error handling?
-	What are the associated Require: and Supported: procedures?

It was identified that if location was allowed in responses, we would
have two=20
possible semantics:

-	the conveyance of location information about the UAS;
-	the echoing of location information about the UAC for the
purpose of=20
loopback testing.

It was agreed that we can only support one of these; that location
conveyance in=20
the reverse direction can always be covered by an in-dialog request
initiated in=20
the reverse direction, and that the loopback testing is a needed
procedure. It=20
was therefore agreed that:

-	location-conveyance in responses to give location of the UAS
would be=20
specifically removed from the document. This should be done by a
subsequent=20
request in the opposite direction.

-	that location in responses would relate to location of UAC for
test, but=20
this would be a new procedure. This would need to be considered by the
WG in a=20
list discussion.

Action 1/8: Brian to post proposed procedures to list for covering the
above,=20
and obtain WG consensus to this proposal.

Removing location conveyance in responses probably simplifies the needed
text=20
for Supported and Require headers. James will add text that allows the=20
geolocation option-tag in a Supported header. A Require header in a
response=20
should never include geolocation.

8)	Error handling issues

Comments: 30, 79, 84, 85, 110, 147
Key questions:
-	Dialog usage - does 424 clear the dialog or just theFrom sip-bounces@ietf.org Sat Apr 28 16:00:32 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hht5m-0004Fl-Nl; Sat, 28 Apr 2007 16:00:26 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hht5k-0004FU-F0
	for sip-confirm+ok@megatron.ietf.org; Sat, 28 Apr 2007 16:00:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hht5k-0004FM-5O
	for sip@ietf.org; Sat, 28 Apr 2007 16:00:24 -0400
Received: from ihemail2.lucent.com ([135.245.0.35])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hht5i-0001qG-Sw
	for sip@ietf.org; Sat, 28 Apr 2007 16:00:24 -0400
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1])
	by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l3SK0H8f029925
	for <sip@ietf.org>; Sat, 28 Apr 2007 15:00:22 -0500 (CDT)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by
	ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 28 Apr 2007 15:00:18 -0500
Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by
	DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 28 Apr 2007 22:00:15 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: [Sip] Location-conveyance: ISSUE #3 - multiple locations
Date: Sat, 28 Apr 2007 22:00:15 +0200
Message-ID: <5D1A7985295922448D5550C94DE29180010BFC06@DEEXC1U01.de.lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Location-conveyance: ISSUE #3 - multiple locations
Thread-Index: AceJxeRiWYVqzczWSD+GBqRQT3G6eg==
From: "Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>
To: "IETF SIP List" <sip@ietf.org>
X-OriginalArrivalTime: 28 Apr 2007 20:00:15.0442 (UTC)
	FILETIME=[D6912320:01C789CF]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

(As SIP WG chair)

During the review of the WGLC comments, we have identified some issues
where we need consensus calls on the list. These are in one call per
message.

We had a number of comments that it was not clear whether a message
could contain multiple locations, and if they were, what were the
procedures.

On the call we identified what we believe the way forward in this area,
which is summarised by the following statements:

-	location conveyance should support the delivery of multiple
locations;

-	the document will make no recommendations as to how the
recipient chooses=20
which location to use. This is regarded as specific to the using
application,=20
and therefore beyond the scope of the protocol extension;

-	the recipient should attempt to make use of all the locations
given, and=20
should only respond with a 424 response if it is unable to use any of
those=20
locations. This includes resolving all and any locations by reference;

-	as a result of the above, any 424 response is a collective
statement about=20
all the locations given in the request rather than any specific location
in the=20
request.

We will assume that this represents WG consensus unless we hear
otherwise from the WG in 7 calendar days from the posting of this
message.=20

Obviously if the WG has an alternative view, some proposal of the
alternative way forward and the expected impact on the text would be
entirely appropriate.

Regards

Keith


_______________________________________________
Sip mailing list  https://www1.ietf.org specific
usage?
-	Can Warning only appear in 424?
-	Do we need all the warnings given?
-	Do we need 701?
-	What mechanism should we use to indicate URL schemes?
-	Do we always return an error, or can we just ignore a problem?=09

In regard to the dialog usage, it was agreed that 424 just ends the
usage in a=20
response to an in-dialog request, and that the transation is retained.
Text will=20
be inserted to reflect this.

In regard to the remainder of the issues, there was a discussion that
resulted=20
in a view that the existing error mechanisms were insufficient. This
centred=20
around the following points:

-	difficulties with correlation already identified earlier in the
call
-	may want to be able to indicate problems with a location when
the call can=20
still proceed (e.g. emergency calls should still be addressed to a PSAP
even if=20
the location cannot be used) and therefore no 424 is ever sent.

Henning did not like the whole Warning header idea any more as a result
of this=20
discussion, and suggested a new Location-Error header that gives
detailed header=20
values (to be used in 424 and 200).  This could be along the lines of
the=20
History-Info header. Suggested an identity tag to tell the UAC which
error=20
applies to which location in the request (when more than one location
was=20
inserted in the request - perhaps by a proxy in which the UAC doesn't
know the=20
proxy did).

Rather than design on the fly as part of the resolution discussion, this
agenda=20
item was parked at this point. Henning agreed to elaborate by email, and
from=20
that point we would decide whether the way forward to resolve this was
by a new=20
i-d documenting the proposal, followed by WG consensus call, or by an
email=20
proposal to the WG list.=20

Action 1/9: Henning to draft strawman proposal and initiate discussion
among=20
review team in order to get the concepts correct, prior to SIP WG
discussion.

9)	Method usage

Comments: 62, 69, 73, 74
Key questions:
-	INFO?
-	Mid call location updates use what mechanism?
-	REFER?
-	PUBLISH?
-	BYE?

For location update in the middle of an INVITE dialog, it was agreed
that UPDATE=20
was the correct method to use, unless there was a reason to send to send
a=20
reINVITE for some other purpose at the same time as this occurred. Text
in the=20
document already says use UPDATE for this purpose.=20

Given that the only function of putting Geolocation in INFO would be for
the=20
same purpose, it was agreed that the Geolocation header would not be
specified=20
for the INFO method.

For PUBLISH it was agreed that Geolocation would be allowed in this
method, but=20
text would clearly state that any usage was not to duplicate mechanisms
where=20
the PIDF-LO should appear in the event package carried by PUBLISH. No
use case=20
identified at moment that fulfils this constraint, but this should not
preclude=20
the availability of a generic protocol mechanism if such a use case does
appear=20
in the future.

The same consideration about no use case, but not precluding the
availability of=20
a generic protocol mechanism if such a use case does appear in the
future,=20
applied to the other methods listed in the key questions. Therefore
Geolocation=20
will be allowed in these methods. This also includes PRACK, but does not
include=20
ACK and CANCEL, as these are not always end-to-end.

10)	Body issues

Comments: 159
Key questions:
-	What additional information is needed to describe bodies?

The issue here is what happens if the Content-Type of the body is
understood,=20
but there is no recognisable Geolocation header (corrupt or removed by
some=20
intermediate entity). Agreed that the Content-Type is sufficient
description of=20
a location, and therefore the location could be used by a UAS when
conforming to=20
this document (SHOULD strength). However the UAC procedure will remain
MUST send=20
the Geolocation header.

11)	PIDF-LO usage

	Comments: 121, 153A
	Key questions:
	Point usage deprecated?
	Proxy usage - what can proxy say about this location - is this
in scope of=20
this document or does GEOPRIV nee/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip

From sip-bounces@ietf.org Sat Apr 28 16:00:32 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hht5f-0004Ee-Vu; Sat, 28 Apr 2007 16:00:19 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hht5e-0004EY-Sy
	for sip-confirm+ok@megatron.ietf.org; Sat, 28 Apr 2007 16:00:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hht5e-0004EQ-JF
	for sip@ietf.org; Sat, 28 Apr 2007 16:00:18 -0400
Received: from ihemail2.lucent.com ([135.245.0.35])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hht5d-0001oi-TO
	for sip@ietf.org; Sat, 28 Apr 2007 16:00:18 -0400
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1])
	by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l3SK0Hp4029918
	for <sip@ietf.org>; Sat, 28 Apr 2007 15:00:17 -0500 (CDT)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by
	ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 28 Apr 2007 15:00:17 -0500
Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by
	DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 28 Apr 2007 22:00:14 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Sat, 28 Apr 2007 22:00:14 +0200
Message-ID: <5D1A7985295922448D5550C94DE29180010BFC05@DEEXC1U01.de.lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Notes of review conference call for
	draft-ietf-sip-location-conveyance
Thread-Index: AceJxSYqNKKJyTZUSq2xGg4UXJDB3g==
From: "Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>
To: "IETF SIP List" <sip@ietf.org>
X-OriginalArrivalTime: 28 Apr 2007 20:00:14.0207 (UTC)
	FILETIME=[D5D4B0F0:01C789CF]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f251f249fc9a04067ce354aa0943ab98
Subject: [Sip] Notes of review conference call for
	draft-ietf-sip-location-conveyance
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

The following are the notes of the conference call held on location
conveyance held last week. Comments are welcome, but please address any
comments on anything but accuracy to a separate thread (i.e. change the
subject of your email).

These will also be posted on the review site in due course.

Regards

Keith

Notes of review team call on WGLC comments on draft-ietf-sip-location-
conveyance-07 held on 25th April 2007

1)	Roll call

The following participated in the call.
Richard Barnes
Keith Drage (moderator and scribe)
Mark Lindsey
James Polk (document editor)
Brian Rosen (document editor)
Henning Schulzrinne
Hannes Tschofenig
Joszef Varga

2)	Agenda bash

No changes.

Keith noted that the key questions mentioned in the agenda were only his
view of=20
the comments made, in order to give some direction to the discussion,
and people=20
should refer to the comment in the case of dispute over the meaning.

3)	Methodology

Keith outlined the methodology of the review calls, which was:

-	to give a first discussion of key points;
-	if new comments arise from discussion, they should be identified
verbally=20
and ensure they are documented;
-	comments discussed can have resolution agreed in the call, or
defer, or=20
take to list, or leave to authors to make a judgement.

d to handle it?

Main issues discussed here was on whether the examples should conform to
RFC=20
4119 (as they currently do in showing point usage) or should reflect
later=20
updates still formally with the working group. There was discussion, but
no=20
agreement, on whether we could remove the PIDF-LO from the example
altogether=20
(replace content by an ellipsis or some such device) as this part of the
example=20
does not relate to any requirements in this SIP extension.

Remaining issues in this agenda item were not discussed due to lack of
time.

12)	URI issues

Comments: 7, 64
Key questions:

Issues in this agenda item were not discussed due to lack of time.

13)	Routeing query allowed issues

Comments: 11
Key questions:

Issues in this agenda item were not discussed due to lack of time.

14)	Retransmission allowed issues

Comments: 61A
Key questions:
	Is mechanism needed?

Issues in this agenda item were not discussed due to lack of time.

15)	Terminology usage

Comments: 1, 19, 43A, 101A, 116B, 129A
Key questions
-	Are "by value" and "by reference" the appropriate terms?
-	Is LbyR a using protocol?
-	Are there any circumstances where we need to talk about LIS
rather than LS?

Issues in this agenda item were not discussed due to lack of time.

16)	Pull mechanisms

	Comments: 25, 144A
	Key questions:
	Are the mentioned pull mechanism valid, given that we don't
cover them at=20
all?

Issues in this agenda item were not discussed due to lack of time.

As we did not complete, it was agreed to hold another review call on
Tuesday May=20
1st at 10:00 - 12:00 Eastern. Keith indicated that the same bridge
details would=20
apply.

James agreed to provide a preliminary update of the draft in time for
the next=20
call.



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip





Further the review team should try and represent previous consensus of
the=20
working group (SIP or GEOPRIV) as appropriate. Should regard themselves
as=20
acting on behalf of the working group.

4)	=20
Issues relating to multiple locations

Comments: 2, 3, (66), 78, 94, 96, 153, 164

Key questions:=20
-	Do we want multiple locations?
-	If there are multiple locations, which should be used?
-	If a 424 is returned, which location does it relate to?
-	Which location does the warning refer to?
-	In what circumstances can multiple locations cause a call to
fail - or can=20
one be used and ignore the rest?
-	If you have a location by value, do you need to also resolve any
location=20
by reference?
-	Anything different for multiple locations in responses?

After discussion it was agreed that the following would be recommended.
This=20
summary would be taken to the list by Keith for a WG consensus call:

-	location conveyance should support the delivery of multiple
locations;
-	the document will make no recommendations as to how the
recipient chooses=20
which location to use. This is regarded as specific to the using
application,=20
and therefore beyond the scope of the protocol extension;
-	the recipient should attempt to make use of all the locations
given, and=20
should only respond with a 424 response if it is unable to use any of
those=20
locations. This includes resolving all and any locations by reference;
-	as a result of the above, any 424 response is a collective
statement about=20
all the locations given in the request rather than any specific location
in the=20
request.

Action 1/1: Keith to take above list to WG for consensus call, as
direction to=20
the editors.

It was also discussed if we should agreed that if a location is already
present=20
in a request, one should not add another, as it is not possible to
resolve which=20
location sender the 424 response relates to. As this may not be a
restriction=20
based on later discussion of improvements to the error handling, we will
hold=20
this decision until we have resolution of the error handling issues.

There was discussion of Warning header meanings in regard to multiple
locations=20
in error. It was considered that there needs to be some form of
correlation=20
between Warning headers and specific locations. See later in the
discussion for=20
further details of resolution process.

The issues of multiple locations in responses was deferred to later in
the=20
meeting under the "location in responses" agenda point.

5)	Security issues

Comments: 21, 27, 117A, 129C, 129D, 168, 181A, 181B, 137
Key questions:
-	Any issues with mandating multipart MIME?
-	Signing versus encryption issues?
-	Document security issues when retrieving location by reference?
-	Are mechanisms different for LbyrR and LbyV?
-	Is security considerations section adequate?
-	Are self signed certificates out of scope?
-	Is mandating a retry without TLS in scope?

The review team agreed that the extension would assume that conformant=20
implementations supported multipart MIME. This was seen as an
implementation=20
problem of existing specifications, rather than a problem with the=20
specifications themselves. Discussion identified that the real problem
was with=20
gateways which would send an error message to requests containing
multipart MIME.

As regards the signing versus encryption, agreed that clarification was
required=20
in the document, but this was a matter of an editorial pass.

The security for dereferencing related to two issues:

-	security of the reference. Part of this centred around the issue
of=20
whether the reference contained the identity of the user sending the
information.=20
It was agreed that the reference is just a URL, and therefore does not=20
consititute an identity.

-	it is known limitation that when a proxy inserts a location by
reference,=20
that the UA user is not a rule maker (RFC 3693 specifies the rulemaker).
There=20
is some suitable text in the RELO document that covers the same issue.
Hannes is=20
going to send text to the review team

Action 1/2: Hannes to send text to editor's and review team covering
this issue

-	security of the dereferencing procedure. This was regarded as
being out of=20
scope, as the dereferencing protocol was also out of scope.

It is also a known limitation that existing mechanisms do not allow a UA
to=20
request proxy implementation. This is believed to be a separable
problem.=20

Need to spell out that need same protection for location by value and
location=20
by reference in the security considerations. Hanne's point - wants more
text=20
saying TLS is used and "we really mean it". Brian will offer text here.

Action 1/3: Brian to provide text relating to the usage of TLS.

In regard to the adequacy of the security considerations Hannes had
agreed to=20
suggest some text. It was noted that the philosophy of the document was
to put=20
the RFC 2119 language regarding security in the main procedures, and
merely=20
comment on the security provided in the security considerations section.

Action 1/4: Hannes to send text (can be just key points to be covered)
to=20
editor's and review team covering this issue

In regard to the self-signed certificates issue (comment 137) it was
agreed that=20
the appropriate document to cover this issue in regard to location was
draft-
ietf-sip-certs. It was proposed therefore to remove all text in the
document=20
relating to self-signed certifications.

Action 1/5: Keith to post to list stating that the agreement is to
remove and=20
asking for WG consensus.

Action 1/6: Keith to send mail to Cullen Jenning / Jason Fischl
regarding the=20
need of draft-ietf-sip-certs to provide any documentation on this issue.

The issue relating to retry without TLS if the request fails with TLS on
an=20
emergency call was dealt with as part of a general consideration of all=20
emergency call issues in the next agenda item.

6)	Emergency issues

	Comments: 129B, 167A, 169
	Key questions:
	Should we cover emergency at all in this document?

It was agreed that section 6 and therefore all text relating to
emergency calls=20
should be removed. It was agreed that it was the responsibility of ECRIT
to=20
apply location-conveyance to emergency calling applications.=20

Action 1/7: Keith to send mail to list asking for WG consensus to
agreement to=20
remove emergency call text from location-conveyance.

Noted that James was not wonderfully happy with this, and may reraise
the=20
discussion once he sees the impact of the decision on the text.

7)	Response usage

Comments: 29, 150
Key questions:
-	Is location allowed in responses, and if so, what are the
procedures for=20
error handling?
-	What are the associated Require: and Supported: procedures?

It was identified that if location was allowed in responses, we would
have two=20
possible semantics:

-	the conveyance of location information about the UAS;
-	the echoing of location information about the UAC for the
purpose of=20
loopback testing.

It was agreed that we can only support one of these; that location
conveyance in=20
the reverse direction can always be covered by an in-dialog request
initiated in=20
the reverse direction, and that the loopback testing is a needed
procedure. It=20
was therefore agreed that:

-	location-conveyance in responses to give location of the UAS
would be=20
specifically removed from the document. This should be done by a
subsequent=20
request in the opposite direction.

-	that location in responses would relate to location of UAC for
test, but=20
this would be a new procedure. This would need to be considered by the
WG in a=20
list discussion.

Action 1/8: Brian to post proposed procedures to list for covering the
above,=20
and obtain WG consensus to this proposal.

Removing location conveyance in responses probably simplifies the needed
text=20
for Supported and Require headers. James will add text that allows the=20
geolocation option-tag in a Supported header. A Require header in a
response=20
should never include geolocation.

8)	Error handling issues

Comments: 30, 79, 84, 85, 110, 147
Key questions:
-	Dialog usage - does 424 clear the dialog or just the specific
usage?
-	Can Warning only appear in 424?
-	Do we need all the warnings given?
-	Do we need 701?
-	What mechanism should we use to indicate URL schemes?
-	Do we always return an error, or can we just ignore a problem?=09

In regard to the dialog usage, it was agreed that 424 just ends the
usage in a=20
response to an in-dialog request, and that the transation is retained.
Text will=20
be inserted to reflect this.

In regard to the remainder of the issues, there was a discussion that
resulted=20
in a view that the existing error mechanisms were insufficient. This
centred=20
around the following points:

-	difficulties with correlation already identified earlier in the
call
-	may want to be able to indicate problems with a location when
the call can=20
still proceed (e.g. emergency calls should still be addressed to a PSAP
even if=20
the location cannot be used) and therefore no 424 is ever sent.

Henning did not like the whole Warning header idea any more as a result
of this=20
discussion, and suggested a new Location-Error header that gives
detailed header=20
values (to be used in 424 and 200).  This could be along the lines of
the=20
History-Info header. Suggested an identity tag to tell the UAC which
error=20
applies to which location in the request (when more than one location
was=20
inserted in the request - perhaps by a proxy in which the UAC doesn't
know the=20
proxy did).

Rather than design on the fly as part of the resolution discussion, this
agenda=20
item was parked at this point. Henning agreed to elaborate by email, and
from=20
that point we would decide whether the way forward to resolve this was
by a new=20
i-d documenting the proposal, followed by WG consensus call, or by an
email=20
proposal to the WG list.=20

Action 1/9: Henning to draft strawman proposal and initiate discussion
among=20
review team in order to get the concepts correct, prior to SIP WG
discussion.

9)	Method usage

Comments: 62, 69, 73, 74
Key questions:
-	INFO?
-	Mid call location updates use what mechanism?
-	REFER?
-	PUBLISH?
-	BYE?

For location update in the middle of an INVITE dialog, it was agreed
that UPDATE=20
was the correct method to use, unless there was a reason to send to send
a=20
reINVITE for some other purpose at the same time as this occurred. Text
in the=20
document already says use UPDATE for this purpose.=20

Given that the only function of putting Geolocation in INFO would be for
the=20
same purpose, it was agreed that the Geolocation header would not be
specified=20
for the INFO method.

For PUBLISH it was agreed that Geolocation would be allowed in this
method, but=20
text would clearly state that any usage was not to duplicate mechanisms
where=20
the PIDF-LO should appear in the event package carried by PUBLISH. No
use case=20
identified at moment that fulfils this constraint, but this should not
preclude=20
the availability of a generic protocol mechanism if such a use case does
appear=20
in the future.

The same consideration about no use case, but not precluding the
availability of=20
a generic protocol mechanism if such a use case does appear in the
future,=20
applied to the other methods listed in the key questions. Therefore
Geolocation=20
will be allowed in these methods. This also includes PRACK, but does not
include=20
ACK and CANCEL, as these are not always end-to-end.

10)	Body issues

Comments: 159
Key questions:
-	What additional information is needed to describe bodies?

The issue here is what happens if the Content-Type of the body is
understood,=20
but there is no recognisable Geolocation header (corrupt or removed by
some=20
intermediate entity). Agreed that the Content-Type is sufficient
description of=20
a location, and therefore the location could be used by a UAS when
conforming to=20
this document (SHOULD strength). However the UAC procedure will remain
MUST send=20
the Geolocation header.

11)	PIDF-LO usage

	Comments: 121, 153A
	Key questions:
	Point usage deprecated?
	Proxy usage - what can proxy say about this location - is this
in scope of=20
this document or does GEOPRIV need to handle it?

Main issues discussed here was on whether the examples should conform to
RFC=20
4119 (as they currently do in showing point usage) or should reflect
later=20
updates still formally with the working group. There was discussion, but
no=20
agreement, on whether we could remove the PIDF-LO from the example
altogether=20
(replace content by an ellipsis or some such device) as this part of the
example=20
does not relate to any requirements in this SIP extension.

Remaining issues in this agenda item were not discussed due to lack of
time.

12)	URI issues

Comments: 7, 64
Key questions:

Issues in this agenda item were not discussed due to lack of time.

13)	Routeing query allowed issues

Comments: 11
Key questions:

Issues in this agenda item were not discussed due to lack of time.

14)	Retransmission allowed issues

Comments: 61A
Key questions:
	Is mechanism needed?

Issues in this agenda item were not discussed due to lack of time.

15)	Terminology usage

Comments: 1, 19, 43A, 101A, 116B, 129A
Key questions
-	Are "by value" and "by reference" the appropriate terms?
-	Is LbyR a using protocol?
-	Are there any circumstances where we need to talk about LIS
rather than LS?

Issues in this agenda item were not discussed due to lack of time.

16)	Pull mechanisms

	Comments: 25, 144A
	Key questions:
	Are the mentioned pull mechanism valid, given that we don't
cover them at=20
all?

Issues in this agenda item were not discussed due to lack of time.

As we did not complete, it was agreed to hold another review call on
Tuesday May=20
1st at 10:00 - 12:00 Eastern. Keith indicated that the same bridge
details would=20
apply.

James agreed to provide a preliminary update of the draft in time for
the next=20
call.



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip





From sip-bounces@ietf.org Sat Apr 28 16:13:28 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhtIM-0003nX-7X; Sat, 28 Apr 2007 16:13:26 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhtIK-0003nS-TI
	for sip-confirm+ok@megatron.ietf.org; Sat, 28 Apr 2007 16:13:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhtIK-0003nK-Jr
	for sip@ietf.org; Sat, 28 Apr 2007 16:13:24 -0400
Received: from persephone.e-c-group.com ([216.128.192.244] helo=e-c-group.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhtIJ-00049M-CA
	for sip@ietf.org; Sat, 28 Apr 2007 16:13:24 -0400
Received: from [24.172.251.171] (account lindsey HELO [192.168.15.101])
	by e-c-group.com (CommuniGate Pro SMTP 5.0.13)
	with ESMTPSA id 99882476; Sat, 28 Apr 2007 16:13:19 -0400
In-Reply-To: <001401c78976$5f8dc020$0601a8c0@BEMBUSTER>
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com>
	<001401c78976$5f8dc020$0601a8c0@BEMBUSTER>
Mime-Version: 1.0 (Apple Message framework v752.3)
X-Priority: 3
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <2296E180-5F91-40B0-876A-7806949C7689@e-c-group.com>
Content-Transfer-Encoding: 7bit
From: "Mark R. Lindsey" <lindsey@e-c-group.com>
Subject: Re: [Sip-implementors] [Sip] SIPit 20 survey summary
Date: Sat, 28 Apr 2007 16:13:20 -0400
To: "Jeroen van Bemmel" <jbemmel@zonnet.nl>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Cc: discussion@sipforum.org, IETF SIP List <sip@ietf.org>,
	Robert Sparks <rjsparks@estacado.net>,
	Juha Heinanen <jh@tutpro.com>, sip-implementors@cs.columbia.edu
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

It is much more reasonable to expect the service-provider/enterprise  
to implement the location conveyance. They'd add the location in  
their proxies/B2BUAs/ALGs. For example, an enterprise building ALG  
could add its location before sending the call to an SP.

(Hah! Another obvious idea made un-patentable.)

In addition, it's the service provider that will likely perform SIP  
peering with a PSAP. In the US, that's the typical model in already.  
Service providers sometimes already know where their users are. Yes,  
yes, I know this isn't the main point of location-conveyance.

But besides all of this: we've got to get the PSAPs capable of  
reliably using the location provided in the call. The capability to  
send the location will be far simpler than actually having a PSAP  
that can accept and use it.






On Apr 28, 2007, at 5:19 AM, Jeroen van Bemmel wrote:

>
> Especially for the use case of emergency calls, would it not be  
> wise to
> select a much more simple approach/syntax, e.g.:
> Emergency-Location: lat=x; lon=y

The location-by-"reference" (i.e., provide a URI to a PIDF-LO instead  
of carrying the document itself) should do what you need here. Many  
UACs already have HTTP servers, which would be compatible with such a  
system, maintain end-to-end privacy requirements. Or the SUBSCRIBE- 
NOTIFY version of PIDF-LO retrieval could easily be implemented with  
a partial multipart-mime implementation, and it could work even  
through proxies.

On Apr 28, 2007, at 5:35 AM, Juha Heinanen wrote:

> another reason why it will not get implemented is that sip uas don't
> know where they are located.  gps does not work well indoors and  
> mobile
> operators at least here have refused to make public coordinates of  
> their
> base stations.

Other location-sensing technology may come along, now that there are  
good reasons for it.




Mark R. Lindsey  | ECG |  +1-229-316-0013  |  lindsey@e-c-group.com



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sat Apr 28 16:25:29 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhtU0-0003jW-5Q; Sat, 28 Apr 2007 16:25:28 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhtTy-0003jQ-DZ
	for sip-confirm+ok@megatron.ietf.org; Sat, 28 Apr 2007 16:25:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhtTy-0003jI-44
	for sip@ietf.org; Sat, 28 Apr 2007 16:25:26 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhtTw-0006L8-Kd
	for sip@ietf.org; Sat, 28 Apr 2007 16:25:26 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id B63AE1EC02E;
	Sat, 28 Apr 2007 23:25:23 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id tDGpA4Iw29zL; Sat, 28 Apr 2007 23:25:21 +0300 (EEST)
Received: from taimen (nuclease87.gprs.dnafinland.fi [62.78.108.87])
	by tutpro.com (Postfix) with ESMTP;
	Sat, 28 Apr 2007 23:25:21 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id 982A3AC122; Sat, 28 Apr 2007 23:25:16 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17971.44460.594067.167790@tutpro.com>
Date: Sat, 28 Apr 2007 23:25:16 +0300
To: "Mark R. Lindsey" <lindsey@e-c-group.com>
Subject: Re: [Sip-implementors] [Sip] SIPit 20 survey summary
In-Reply-To: <2296E180-5F91-40B0-876A-7806949C7689@e-c-group.com>
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com>
	<001401c78976$5f8dc020$0601a8c0@BEMBUSTER>
	<2296E180-5F91-40B0-876A-7806949C7689@e-c-group.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: discussion@sipforum.org, IETF SIP List <sip@ietf.org>,
	Robert Sparks <rjsparks@estacado.net>, sip-implementors@cs.columbia.edu
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Mark R. Lindsey writes:

 > It is much more reasonable to expect the service-provider/enterprise  
 > to implement the location conveyance. They'd add the location in  
 > their proxies/B2BUAs/ALGs. For example, an enterprise building ALG  
 > could add its location before sending the call to an SP.

enterprises (at least smaller ones) don't run their own proxies.  they
buy the service hosted and the service provider has no idea where the
individual phones are.  especially now when, for example, nokia
enterprise phones allow you to make calls over 3G or WLANs everywhere.

 > In addition, it's the service provider that will likely perform SIP  
 > peering with a PSAP. In the US, that's the typical model in already.  
 > Service providers sometimes already know where their users are. Yes,  
 > yes, I know this isn't the main point of location-conveyance.

in finland, sweden, and some other european contries the standard for
emergency calls is to prefix emergency number with community code of the
caller.  proxy can do that IF caller always keeps his/her current
community code up to date, which is a big IF.  there is thus no need for
this location conveyance draft.

 > But besides all of this: we've got to get the PSAPs capable of  
 > reliably using the location provided in the call. The capability to  
 > send the location will be far simpler than actually having a PSAP  
 > that can accept and use it.

so you have big problem at both ends.  not very motivating for
implementers.

-- juha


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sat Apr 28 18:10:37 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hhv7h-0006j8-JO; Sat, 28 Apr 2007 18:10:33 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hhv7g-0006j2-6l
	for sip-confirm+ok@megatron.ietf.org; Sat, 28 Apr 2007 18:10:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhv7f-0006iu-TU
	for sip@ietf.org; Sat, 28 Apr 2007 18:10:31 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hhv7e-0007H1-IL
	for sip@ietf.org; Sat, 28 Apr 2007 18:10:31 -0400
Received: from sj-dkim-8.cisco.com ([171.68.10.93])
	by sj-iport-5.cisco.com with ESMTP; 28 Apr 2007 15:10:30 -0700
X-IronPort-AV: i="4.14,465,1170662400"; 
	d="scan'208"; a="416713872:sNHT49671224"
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
	by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l3SMAUJA002793; 
	Sat, 28 Apr 2007 15:10:30 -0700
Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id l3SMAOA9029959;
	Sat, 28 Apr 2007 22:10:25 GMT
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1032AB49@zrc2hxm0.corp.nortel.com>
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>	<70B32427-9693-4423-AB86-7C926A479F85@cisco.com>	<1ECE0EB50388174790F9694F77522CCF1028B59B@zrc2hxm0.corp.nortel.com>	<462F613C.2050502@sipstation.com>	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>	<17968.16340.800200.535818@tutpro.com>	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>	<17968.58739.220882.733487@tutpro.com>	<1ECE0EB50388174790F9694F77522CCF1032A6D8@zrc2hxm0.corp.nortel.com>	<17968.61648.893419.784702@tutpro.com>	<05650EF6-4740-4F00-97AF-AA180402AC1E@softarmor.com>
	<1ECE0EB50388174790F9694F77522CCF1032AAEF@zrc2hxm0.corp.nortel.com>
	<46311E22.3040307@alcatel-lucent.com>
	<1ECE0EB50388174790F9694F77522CCF1032AB49@zrc2hxm0.corp.nortel.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <F7873361-B01E-4811-AD57-D30B93F57124@cisco.com>
Content-Transfer-Encoding: 7bit
From: Cullen Jennings <fluffy@cisco.com>
Subject: Re: [Sip] draft-ietf-sip-sips-03.txt: Closing of Opened issues
Date: Sat, 28 Apr 2007 15:09:50 -0700
To: SIP <sip@ietf.org>
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2235; t=1177798230;
	x=1178662230; c=relaxed/simple; s=sjdkim8002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=fluffy@cisco.com;
	z=From:=20Cullen=20Jennings=20<fluffy@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20draft-ietf-sip-sips-03.txt=3A=20Closing=20of=
	20Opened=20issues |Sender:=20;
	bh=bYEDzAhkAmJ0ryKvYzOp4YlVKFNrO9Blp3m/nRFnGbE=;
	b=kA1uMdjg5KGrK4/F1W1acXTgtOmwQGm0aPSblYlkOC2HtHfp6nPSxBMBUl6uvva8CKJy+7ZM
	ueFd4nQjpFJZeJU9PS2fO3Wr3Dpiyp1Z+LO2974d2L1T+PniPaAw2ceA;
Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim8002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


Francois pointed out this draft was wrong to me a long time ago -  
Nagendra and I agree with him. We just had not got around to fixing it.

Cullen <with my individual hat on>


On Apr 26, 2007, at 2:49 PM, Francois Audet wrote:

> Yes, that draft is wrong and needs to be fixed.
>
> The correct behavior is 1/
>
>> -----Original Message-----
>> From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com]
>> Sent: Thursday, April 26, 2007 14:48
>> To: Audet, Francois (SC100:3055)
>> Cc: sip@ietf.org
>> Subject: Re: [Sip] draft-ietf-sip-sips-03.txt: Closing of
>> Opened issues
>>
>> Francois Audet wrote:
>>> VIA already supports SCTP, TLS-SCTP. And the draft provides the
>>> references to RFC 4168 that defines it.
>>
>> We've had this conversation before.
>>
>> That is all well and fine for Vias (responses), but what
>> about requests triggered by a R-URI?
>>
>>> DTLS is defined in
>>> http://tools.ietf.org/wg/sip/draft-jennings-sip-dtls-03.txt.
>>
>> dtls-03 says that a SIP URI to be sent over DTLS should look
>> like the following:
>>
>>     sip:alice@example.com;transport=dtls-udp
>>
>> Two questions:
>>    1/ should it not be "sips" scheme here?
>>    2/ If we are endorsing "transport=dtls-udp" in a SIP URI, then
>>       saying that you should not put "transport=tls" in a SIP URI
>>       seems silly. (Note that I personally do not like how
>>       implementations have continued to use "transport=tls"
>>       despite rfc3261 deprecating this.  But questions will arise
>>       in the future that why are we allowing "transport=dtls-udp"
>>       and not "transport=tls"?)
>>
>> Thanks,
>>
>> - vijay
>> --
>> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
>> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
>> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
>> WWW:   http://www.alcatel-lucent.com/bell-labs
>>
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sat Apr 28 18:24:18 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhvKx-0005vx-Rs; Sat, 28 Apr 2007 18:24:15 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhvKv-0005vd-Oa
	for sip-confirm+ok@megatron.ietf.org; Sat, 28 Apr 2007 18:24:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhvKv-0005vV-Ez
	for sip@ietf.org; Sat, 28 Apr 2007 18:24:13 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhvKs-0000hp-4e
	for sip@ietf.org; Sat, 28 Apr 2007 18:24:13 -0400
Received: from sj-dkim-8.cisco.com ([171.68.10.93])
	by sj-iport-5.cisco.com with ESMTP; 28 Apr 2007 15:24:09 -0700
X-IronPort-AV: i="4.14,465,1170662400"; 
	d="scan'208"; a="416715022:sNHT48572896"
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
	by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l3SMO9Bn005097; 
	Sat, 28 Apr 2007 15:24:09 -0700
Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id l3SMNxA9002120;
	Sat, 28 Apr 2007 22:23:59 GMT
In-Reply-To: <17971.5486.819002.96466@tutpro.com>
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com>
	<001401c78976$5f8dc020$0601a8c0@BEMBUSTER>
	<17971.5486.819002.96466@tutpro.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <CCACA85C-15C7-49F2-968B-1F12060CB271@cisco.com>
Content-Transfer-Encoding: 7bit
From: Cullen Jennings <fluffy@cisco.com>
Subject: Re: [Sip] SIPit 20 survey summary
Date: Sat, 28 Apr 2007 15:23:24 -0700
To: Juha Heinanen <jh@tutpro.com>
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1663; t=1177799049;
	x=1178663049; c=relaxed/simple; s=sjdkim8002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=fluffy@cisco.com;
	z=From:=20Cullen=20Jennings=20<fluffy@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20SIPit=2020=20survey=20summary
	|Sender:=20; bh=4jCgYz2EpXXQPXWPIg3+81CiNrviUPpkgCtGwRLMdag=;
	b=YqWSlpJAGm7S23sLf9wfFDkinkp/U3Epo8SlxBxveq+SU83gWrP0D1JBx7XfJsapgrVrNvuX
	PHf6eTP0doNEhxux6IJjCsaycB6ns3vWHcH9bHvIpifN+ezsO+udEEFx;
Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim8002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: 'IETF SIP List' <sip@ietf.org>, sip-implementors@cs.columbia.edu,
	discussion@sipforum.org, 'Robert Sparks' <rjsparks@estacado.net>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


There has been an incredible amount of work on this topic across many  
standard organizations including the IETF. Before people start in on  
discussing this in - I strongly suggest they might want to read some  
of the requirements, uses cases, drafts, and mailing list discussions  
in ECRIT and GEOPRIV. Please keep in mind the charters of ECRIT/ 
GEOPRIV/SIP and take the discussion to the right working group.


On Apr 28, 2007, at 2:35 AM, Juha Heinanen wrote:

> Jeroen van Bemmel writes:
>
>> Especially for the use case of emergency calls, would it not be  
>> wise to
>> select a much more simple approach/syntax, e.g.:
>> Emergency-Location: lat=x; lon=y
>>
>> So no XML, no mime/multipart, as simple as possible (no complex  
>> semantics,
>> usage-rules etc), something to reduce the barrier of
>> implementation/deployment, and to reduce the risk for interop issues?
>
> i fully agree with this.  we should follow KISS principle here.  it is
> highly unlikely that sip ua vendors will even TRY implement such a
> complex protocol.
>
> another reason why it will not get implemented is that sip uas don't
> know where they are located.  gps does not work well indoors and  
> mobile
> operators at least here have refused to make public coordinates of  
> their
> base stations.
>
> -- juha
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sat Apr 28 19:24:13 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhwGo-00084p-OC; Sat, 28 Apr 2007 19:24:02 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhwGm-00084f-Bo
	for sip-confirm+ok@megatron.ietf.org; Sat, 28 Apr 2007 19:24:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhwGm-00084X-2L
	for sip@ietf.org; Sat, 28 Apr 2007 19:24:00 -0400
Received: from smtpauth00.csee.onr.siteprotect.com ([64.26.60.144])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhwGj-000340-SW
	for sip@ietf.org; Sat, 28 Apr 2007 19:23:59 -0400
Received: from [192.168.1.120] (c-67-162-139-200.hsd1.co.comcast.net
	[67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com)
	by smtpauth00.csee.onr.siteprotect.com (Postfix) with ESMTP id
	D541F75805B; Sat, 28 Apr 2007 18:23:56 -0500 (CDT)
Subject: Re: [Sip] SIPit 20 survey summary
From: "Frank W. Miller" <fwmiller@cornfed.com>
To: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <CCACA85C-15C7-49F2-968B-1F12060CB271@cisco.com>
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com>
	<001401c78976$5f8dc020$0601a8c0@BEMBUSTER>
	<17971.5486.819002.96466@tutpro.com>
	<CCACA85C-15C7-49F2-968B-1F12060CB271@cisco.com>
Content-Type: text/plain
Date: Sat, 28 Apr 2007 17:23:42 -0600
Message-Id: <1177802622.3020.8.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: 'IETF SIP List' <sip@ietf.org>, discussion@sipforum.org,
	Juha Heinanen <jh@tutpro.com>, sip-implementors@cs.columbia.edu,
	'Robert Sparks' <rjsparks@estacado.net>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


Acknowledged.  However, if we're talking about adding messaging
infrastructure to SIP, then the discussion is quite relevant here.  I
for one would vote for a simpler mechanism than multipart MIME XML blah
blah blah.  With regards to Keith's comments, I would love to sit down
and provide an alternative proposal but I just don't have the time to do
it.  With all due respect, I'll implement whatever the standards
committee comes up with, but I don't think its unreasonable for me or
anyone else to express concern about protocol that is obviously designed
by committee and obviously more complicated that it probably has to be.

FM


On Sat, 2007-04-28 at 15:23 -0700, Cullen Jennings wrote:
> There has been an incredible amount of work on this topic across many  
> standard organizations including the IETF. Before people start in on  
> discussing this in - I strongly suggest they might want to read some  
> of the requirements, uses cases, drafts, and mailing list discussions  
> in ECRIT and GEOPRIV. Please keep in mind the charters of ECRIT/ 
> GEOPRIV/SIP and take the discussion to the right working group.
> 
> 
> On Apr 28, 2007, at 2:35 AM, Juha Heinanen wrote:
> 
> > Jeroen van Bemmel writes:
> >
> >> Especially for the use case of emergency calls, would it not be  
> >> wise to
> >> select a much more simple approach/syntax, e.g.:
> >> Emergency-Location: lat=x; lon=y
> >>
> >> So no XML, no mime/multipart, as simple as possible (no complex  
> >> semantics,
> >> usage-rules etc), something to reduce the barrier of
> >> implementation/deployment, and to reduce the risk for interop issues?
> >
> > i fully agree with this.  we should follow KISS principle here.  it is
> > highly unlikely that sip ua vendors will even TRY implement such a
> > complex protocol.
> >
> > another reason why it will not get implemented is that sip uas don't
> > know where they are located.  gps does not work well indoors and  
> > mobile
> > operators at least here have refused to make public coordinates of  
> > their
> > base stations.
> >
> > -- juha
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sat Apr 28 19:45:41 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hhwbj-0001kA-Hs; Sat, 28 Apr 2007 19:45:39 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hhwbh-0001hY-Nz
	for sip-confirm+ok@megatron.ietf.org; Sat, 28 Apr 2007 19:45:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhwbh-0001g0-DT
	for sip@ietf.org; Sat, 28 Apr 2007 19:45:37 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhwZE-0007Xr-SW
	for sip@ietf.org; Sat, 28 Apr 2007 19:43:06 -0400
Received: from sj-dkim-6.cisco.com ([171.68.10.81])
	by sj-iport-5.cisco.com with ESMTP; 28 Apr 2007 16:43:04 -0700
X-IronPort-AV: i="4.14,465,1170662400"; 
	d="scan'208"; a="416726212:sNHT52926176"
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
	by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l3SNh4QE008560; 
	Sat, 28 Apr 2007 16:43:04 -0700
Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id l3SNh2A9014492;
	Sat, 28 Apr 2007 23:43:02 GMT
In-Reply-To: <1177802622.3020.8.camel@localhost.localdomain>
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com>
	<001401c78976$5f8dc020$0601a8c0@BEMBUSTER>
	<17971.5486.819002.96466@tutpro.com>
	<CCACA85C-15C7-49F2-968B-1F12060CB271@cisco.com>
	<1177802622.3020.8.camel@localhost.localdomain>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <03CA4D91-9D78-4AB0-9DC0-4030AD23E2B5@cisco.com>
Content-Transfer-Encoding: 7bit
From: Cullen Jennings <fluffy@cisco.com>
Subject: Re: [Sip] SIPit 20 survey summary
Date: Sat, 28 Apr 2007 16:42:27 -0700
To: "Frank W. Miller" <fwmiller@cornfed.com>
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3091; t=1177803784;
	x=1178667784; c=relaxed/simple; s=sjdkim6002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=fluffy@cisco.com;
	z=From:=20Cullen=20Jennings=20<fluffy@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20SIPit=2020=20survey=20summary
	|Sender:=20; bh=id70XH1lon9ValxygX56FBpR9hxuoyv+h+8Q2x2obgY=;
	b=JI4H0EBTiFbwYfUuRQApGoNwqgwGG4FkBf9RDZO2hadxLbWLAsuTtLRm1Co1S2Ro7as+ejoO
	256yij9UJywXGP/lgqXKaLK9y4VtzB+Gn4ehIV7m1u+0uJNX9Tt91QPW;
Authentication-Results: sj-dkim-6; header.From=fluffy@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim6002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


Fair enough - I just want to try and keep the right parts of the  
discussion in the right place.


On Apr 28, 2007, at 4:23 PM, Frank W. Miller wrote:

>
> Acknowledged.  However, if we're talking about adding messaging
> infrastructure to SIP, then the discussion is quite relevant here.  I
> for one would vote for a simpler mechanism than multipart MIME XML  
> blah
> blah blah.  With regards to Keith's comments, I would love to sit down
> and provide an alternative proposal but I just don't have the time  
> to do
> it.  With all due respect, I'll implement whatever the standards
> committee comes up with, but I don't think its unreasonable for me or
> anyone else to express concern about protocol that is obviously  
> designed
> by committee and obviously more complicated that it probably has to  
> be.
>
> FM
>
>
> On Sat, 2007-04-28 at 15:23 -0700, Cullen Jennings wrote:
> > There has been an incredible amount of work on this topic across  
> many
> > standard organizations including the IETF. Before people start in on
> > discussing this in - I strongly suggest they might want to read some
> > of the requirements, uses cases, drafts, and mailing list  
> discussions
> > in ECRIT and GEOPRIV. Please keep in mind the charters of ECRIT/
> > GEOPRIV/SIP and take the discussion to the right working group.
> >
> >
> > On Apr 28, 2007, at 2:35 AM, Juha Heinanen wrote:
> >
> > > Jeroen van Bemmel writes:
> > >
> > >> Especially for the use case of emergency calls, would it not be
> > >> wise to
> > >> select a much more simple approach/syntax, e.g.:
> > >> Emergency-Location: lat=x; lon=y
> > >>
> > >> So no XML, no mime/multipart, as simple as possible (no complex
> > >> semantics,
> > >> usage-rules etc), something to reduce the barrier of
> > >> implementation/deployment, and to reduce the risk for interop  
> issues?
> > >
> > > i fully agree with this.  we should follow KISS principle  
> here.  it is
> > > highly unlikely that sip ua vendors will even TRY implement such a
> > > complex protocol.
> > >
> > > another reason why it will not get implemented is that sip uas  
> don't
> > > know where they are located.  gps does not work well indoors and
> > > mobile
> > > operators at least here have refused to make public coordinates of
> > > their
> > > base stations.
> > >
> > > -- juha
> > >
> > >
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol
> > > Use sip-implementors@cs.columbia.edu for questions on current sip
> > > Use sipping@ietf.org for new developments on the application of  
> sip
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sat Apr 28 20:24:58 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhxDa-0002jJ-37; Sat, 28 Apr 2007 20:24:46 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhxDY-0002hR-NE
	for sip-confirm+ok@megatron.ietf.org; Sat, 28 Apr 2007 20:24:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhxDY-0002hJ-Dn
	for sip@ietf.org; Sat, 28 Apr 2007 20:24:44 -0400
Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhxDW-0002OX-3Y
	for sip@ietf.org; Sat, 28 Apr 2007 20:24:44 -0400
X-SEF-Processed: 5_0_0_910__2007_04_28_19_31_25
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com -
	SurfControl E-mail Filter (5.2.1); Sat, 28 Apr 2007 19:31:25 -0500
Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with
	Microsoft SMTPSVC(6.0.3790.1830); Sat, 28 Apr 2007 19:24:36 -0500
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: [Sip] Location-conveyance: ISSUE #3 - multiple locations
Date: Sat, 28 Apr 2007 19:24:35 -0500
Message-ID: <E51D5B15BFDEFD448F90BDD17D41CFF102D1B35C@AHQEX1.andrew.com>
In-Reply-To: <5D1A7985295922448D5550C94DE29180010BFC06@DEEXC1U01.de.lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Location-conveyance: ISSUE #3 - multiple locations
Thread-Index: AceJxeRiWYVqzczWSD+GBqRQT3G6egALn1vw
From: "Winterbottom, James" <James.Winterbottom@andrew.com>
To: "Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>,
	"IETF SIP List" <sip@ietf.org>
X-OriginalArrivalTime: 29 Apr 2007 00:24:36.0478 (UTC)
	FILETIME=[C47B29E0:01C789F4]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi Keith,=0D=0A=0D=0AThe GEOPRIV PIDF-LO profile document makes suggestions=
 about including=0D=0Aand interpreting multiple locations. This may be the =
right document to=0D=0Areference with regards to this topic.=0D=0A=0D=0AChe=
ers=0D=0AJames=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: D=
rage, Keith (Keith) [mailto:drage@alcatel-lucent.com]=0D=0A> Sent: Sunday, =
29 April 2007 6:00 AM=0D=0A> To: IETF SIP List=0D=0A> Subject: [Sip] Locati=
on-conveyance: ISSUE #3 - multiple locations=0D=0A>=20=0D=0A> (As SIP WG ch=
air)=0D=0A>=20=0D=0A> During the review of the WGLC comments, we have ident=
ified some issues=0D=0A> where we need consensus calls on the list. These a=
re in one call per=0D=0A> message.=0D=0A>=20=0D=0A> We had a number of comm=
ents that it was not clear whether a message=0D=0A> could contain multiple =
locations, and if they were, what were the=0D=0A> procedures.=0D=0A>=20=0D=0A=
> On the call we identified what we believe the way forward in this=0D=0Aar=
ea,=0D=0A> which is summarised by the following statements:=0D=0A>=20=0D=0A=
> -=09location conveyance should support the delivery of multiple=0D=0A> lo=
cations;=0D=0A>=20=0D=0A> -=09the document will make no recommendations as =
to how the=0D=0A> recipient chooses=0D=0A> which location to use. This is r=
egarded as specific to the using=0D=0A> application,=0D=0A> and therefore b=
eyond the scope of the protocol extension;=0D=0A>=20=0D=0A> -=09the recipie=
nt should attempt to make use of all the locations=0D=0A> given, and=0D=0A>=
 should only respond with a 424 response if it is unable to use any of=0D=0A=
> those=0D=0A> locations. This includes resolving all and any locations by =
reference;=0D=0A>=20=0D=0A> -=09as a result of the above, any 424 response =
is a collective=0D=0A> statement about=0D=0A> all the locations given in th=
e request rather than any specific=0D=0Alocation=0D=0A> in the=0D=0A> reque=
st.=0D=0A>=20=0D=0A> We will assume that this represents WG consensus unles=
s we hear=0D=0A> otherwise from the WG in 7 calendar days from the posting =
of this=0D=0A> message.=0D=0A>=20=0D=0A> Obviously if the WG has an alterna=
tive view, some proposal of the=0D=0A> alternative way forward and the expe=
cted impact on the text would be=0D=0A> entirely appropriate.=0D=0A>=20=0D=0A=
> Regards=0D=0A>=20=0D=0A> Keith=0D=0A>=20=0D=0A>=20=0D=0A> _______________=
________________________________=0D=0A> Sip mailing list  https://www1.ietf=
=2Eorg/mailman/listinfo/sip=0D=0A> This list is for NEW development of the =
core SIP Protocol=0D=0A> Use sip-implementors@cs.columbia.edu for questions=
 on current sip=0D=0A> Use sipping@ietf.org for new developments on the app=
lication of sip=0D=0A=0D=0A------------------------------------------------=
------------------------------------------------=0D=0AThis message is for t=
he designated recipient only and may=0D=0Acontain privileged, proprietary, =
or otherwise private information. =20=0D=0AIf you have received it in error=
, please notify the sender=0D=0Aimmediately and delete the original.  Any u=
nauthorized use of=0D=0Athis email is prohibited.=0D=0A--------------------=
---------------------------------------------------------------------------=
-=0D=0A[mf2]=0D=0A


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sat Apr 28 21:41:35 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhyPe-0002jr-5a; Sat, 28 Apr 2007 21:41:18 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhyPb-0002jm-Lk
	for sip-confirm+ok@megatron.ietf.org; Sat, 28 Apr 2007 21:41:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhyPa-0002jZ-Rc
	for sip@ietf.org; Sat, 28 Apr 2007 21:41:14 -0400
Received: from persephone.e-c-group.com ([216.128.192.244] helo=e-c-group.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhyPZ-0000nm-GX
	for sip@ietf.org; Sat, 28 Apr 2007 21:41:14 -0400
Received: from [24.172.251.171] (account lindsey HELO [192.168.15.101])
	by e-c-group.com (CommuniGate Pro SMTP 5.0.13)
	with ESMTPSA id 99887562; Sat, 28 Apr 2007 21:41:12 -0400
In-Reply-To: <17971.44460.594067.167790@tutpro.com>
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com>
	<001401c78976$5f8dc020$0601a8c0@BEMBUSTER>
	<2296E180-5F91-40B0-876A-7806949C7689@e-c-group.com>
	<17971.44460.594067.167790@tutpro.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <B79BA17A-52B0-4004-9DF4-589D1E785F42@e-c-group.com>
Content-Transfer-Encoding: 7bit
From: "Mark R. Lindsey" <lindsey@e-c-group.com>
Subject: Re: [Sip-implementors] [Sip] SIPit 20 survey summary
Date: Sat, 28 Apr 2007 21:41:12 -0400
To: jh@tutpro.com (Juha Heinanen)
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: discussion@sipforum.org, IETF SIP List <sip@ietf.org>,
	Robert Sparks <rjsparks@estacado.net>, sip-implementors@cs.columbia.edu
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

On Apr 28, 2007, at 4:25 PM, Juha Heinanen wrote:

> enterprises (at least smaller ones) don't run their own proxies. they
> buy the service hosted and the service provider has no idea where the
> individual phones are.

In some major deployments, the data suggest otherwise: In two US-Baby- 
Bell's hosted VoIP system, 100% of their customers had a SIP B2BUA at  
every customer office. Ditto for another major vendor reselling  
hosted VoIP service to Baby Bells. The box handles NAT traversal  
among other functions.

So, in numerous cases, there is a SIP box between the SIP phone and  
the Service Provider. In many networks, including those with WiFi  
phones, the UAC can be compelled to register only through that B2BUA.

So there's real hope that inserting the location data at relatively  
few points can get this deployed on the calling-party side very rapidly.

> especially now when, for example, nokia
> enterprise phones allow you to make calls over 3G or WLANs everywhere.

This is both a location-sensing & policy enforcement problem:

(a) If the location can be sensed by the enterprise operating a proxy/ 
B2BUA, then a proxy between the UA and the PSAP can insert the location.

(b) If the location can be sensed by the UA, then it can insert its  
own location.

(c) Else, if no location is provided to the service provider, an SP  
responsible for properly delivering emergency calls would refuse to  
let a device register.

Mark



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sat Apr 28 22:52:19 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhzWC-0004Is-1x; Sat, 28 Apr 2007 22:52:08 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HhzWB-0004In-1p
	for sip-confirm+ok@megatron.ietf.org; Sat, 28 Apr 2007 22:52:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhzWA-0004Ib-LW
	for sip@ietf.org; Sat, 28 Apr 2007 22:52:06 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhzVw-0006V0-Mg
	for sip@ietf.org; Sat, 28 Apr 2007 22:51:54 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id 3E65B1EC38C;
	Sun, 29 Apr 2007 05:51:51 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id b372IEUJKQhu; Sun, 29 Apr 2007 05:51:49 +0300 (EEST)
Received: from taimen (peptide88.gprs.dnafinland.fi [62.78.109.88])
	by tutpro.com (Postfix) with ESMTP;
	Sun, 29 Apr 2007 05:51:49 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id C2811AC122; Sun, 29 Apr 2007 05:51:40 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17972.2108.732164.800632@tutpro.com>
Date: Sun, 29 Apr 2007 05:51:40 +0300
To: "Mark R. Lindsey" <lindsey@e-c-group.com>
Subject: Re: [Sip-implementors] [Sip] SIPit 20 survey summary
In-Reply-To: <B79BA17A-52B0-4004-9DF4-589D1E785F42@e-c-group.com>
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com>
	<001401c78976$5f8dc020$0601a8c0@BEMBUSTER>
	<2296E180-5F91-40B0-876A-7806949C7689@e-c-group.com>
	<17971.44460.594067.167790@tutpro.com>
	<B79BA17A-52B0-4004-9DF4-589D1E785F42@e-c-group.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: discussion@sipforum.org, IETF SIP List <sip@ietf.org>,
	Robert Sparks <rjsparks@estacado.net>, sip-implementors@cs.columbia.edu
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Mark R. Lindsey writes:

 > So, in numerous cases, there is a SIP box between the SIP phone and  
 > the Service Provider. In many networks, including those with WiFi  
 > phones, the UAC can be compelled to register only through that B2BUA.

even if they register through their enterprise boxes, the UAs can still
be located wherever else than at that office.  people use vpns to get to
their offices from home/road/etc.  so i would say that it is actually
more harmful to give wrong location info (that of the office) than not to
give anything at all.

 > This is both a location-sensing & policy enforcement problem:
 > 
 > (a) If the location can be sensed by the enterprise operating a proxy/ 
 > B2BUA, then a proxy between the UA and the PSAP can insert the
 > location.

it is very hard to sense at the enterprise where my wlan hotspot
attached phone really is.

 > (b) If the location can be sensed by the UA, then it can insert its  
 > own location.

mobile networks do have location info, but they don't want to give it
out to the ua.  so if your sip service is not provided by your mobile
operator, you get nothing.   this actually proves that authorities value
much more business rights of mobile operators than safety of people.

 > (c) Else, if no location is provided to the service provider, an SP  
 > responsible for properly delivering emergency calls would refuse to  
 > let a device register.

if you make such a law, sure there will be location info given, but in
many cases it will be bogus and thus more harmful than no info at all.

but this is not really a sip wg discussion other than it has been made
to spend its cycles on yet another useless standard.

-- juha


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 29 03:16:26 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hi3dk-0006bM-So; Sun, 29 Apr 2007 03:16:12 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hi3dj-0006bG-E7
	for sip-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 03:16:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hi3dg-0006aq-3j
	for sip@ietf.org; Sun, 29 Apr 2007 03:16:08 -0400
Received: from mail.gmx.net ([213.165.64.20])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hi3df-0003Qk-Gh
	for sip@ietf.org; Sun, 29 Apr 2007 03:16:08 -0400
Received: (qmail 32711 invoked by uid 0); 29 Apr 2007 07:16:06 -0000
Received: from 90.186.63.85 by www100.gmx.net with HTTP;
	Sun, 29 Apr 2007 09:16:06 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 29 Apr 2007 09:16:06 +0200
From: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
In-Reply-To: <E51D5B15BFDEFD448F90BDD17D41CFF102D1B35C@AHQEX1.andrew.com>
Message-ID: <20070429071606.224850@gmx.net>
MIME-Version: 1.0
References: <E51D5B15BFDEFD448F90BDD17D41CFF102D1B35C@AHQEX1.andrew.com>
Subject: Re: RE: [Sip] Location-conveyance: ISSUE #3 - multiple locations
To: "Winterbottom, James" <James.Winterbottom@andrew.com>, sip@ietf.org,
	drage@alcatel-lucent.com
X-Authenticated: #29516787
X-Flags: 0001
X-Mailer: WWW-Mail 6100 (Global Message Exchange)
X-Priority: 3
X-Provags-ID: V01U2FsdGVkX1/n1a5WDXTn9ckT4M0ydXWyohZ0bJxE64cL4VqL6H
	8qITZYwMRm76++/COpuC5tLiPPe7vIGl3QeQ== 
Content-Transfer-Encoding: 7bit
X-GMX-UID: WTNddZgZeWUkW4EFq25n1KYjL0tsZo2r
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi Keith, 

I also suggested to make use of the PIDF-LO profile document for this purpose in the past. See, for example, http://www1.ietf.org/mail-archive/web/sip/current/msg15002.html

Ciao
Hannes

-------- Original-Nachricht --------
Datum: Sat, 28 Apr 2007 19:24:35 -0500
Von: "Winterbottom, James" <James.Winterbottom@andrew.com>
An: "Drage, Keith \\(Keith\\)" <drage@alcatel-lucent.com>, "IETF SIP List" <sip@ietf.org>
Betreff: RE: [Sip] Location-conveyance: ISSUE #3 - multiple locations

> Hi Keith,
> 
> The GEOPRIV PIDF-LO profile document makes suggestions about including
> and interpreting multiple locations. This may be the right document to
> reference with regards to this topic.
> 
> Cheers
> James
> 
> 
> > -----Original Message-----
> > From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com]
> > Sent: Sunday, 29 April 2007 6:00 AM
> > To: IETF SIP List
> > Subject: [Sip] Location-conveyance: ISSUE #3 - multiple locations
> > 
> > (As SIP WG chair)
> > 
> > During the review of the WGLC comments, we have identified some issues
> > where we need consensus calls on the list. These are in one call per
> > message.
> > 
> > We had a number of comments that it was not clear whether a message
> > could contain multiple locations, and if they were, what were the
> > procedures.
> > 
> > On the call we identified what we believe the way forward in this
> area,
> > which is summarised by the following statements:
> > 
> > -	location conveyance should support the delivery of multiple
> > locations;
> > 
> > -	the document will make no recommendations as to how the
> > recipient chooses
> > which location to use. This is regarded as specific to the using
> > application,
> > and therefore beyond the scope of the protocol extension;
> > 
> > -	the recipient should attempt to make use of all the locations
> > given, and
> > should only respond with a 424 response if it is unable to use any of
> > those
> > locations. This includes resolving all and any locations by reference;
> > 
> > -	as a result of the above, any 424 response is a collective
> > statement about
> > all the locations given in the request rather than any specific
> location
> > in the
> > request.
> > 
> > We will assume that this represents WG consensus unless we hear
> > otherwise from the WG in 7 calendar days from the posting of this
> > message.
> > 
> > Obviously if the WG has an alternative view, some proposal of the
> > alternative way forward and the expected impact on the text would be
> > entirely appropriate.
> > 
> > Regards
> > 
> > Keith
> > 
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> 
> ------------------------------------------------------------------------------------------------
> 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]
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 29 03:40:45 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hi41P-000487-7H; Sun, 29 Apr 2007 03:40:39 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hi41N-00047v-Eh
	for sip-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 03:40:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hi41N-00047m-1b
	for sip@ietf.org; Sun, 29 Apr 2007 03:40:37 -0400
Received: from mail.gmx.net ([213.165.64.20])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hi41K-0001pn-Vg
	for sip@ietf.org; Sun, 29 Apr 2007 03:40:37 -0400
Received: (qmail 24265 invoked by uid 0); 29 Apr 2007 07:40:34 -0000
Received: from 90.186.63.85 by www024.gmx.net with HTTP;
	Sun, 29 Apr 2007 09:40:34 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 29 Apr 2007 09:40:34 +0200
From: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
In-Reply-To: <1177802622.3020.8.camel@localhost.localdomain>
Message-ID: <20070429074034.224850@gmx.net>
MIME-Version: 1.0
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com>
	<001401c78976$5f8dc020$0601a8c0@BEMBUSTER>
	<17971.5486.819002.96466@tutpro.com>
	<CCACA85C-15C7-49F2-968B-1F12060CB271@cisco.com>
	<1177802622.3020.8.camel@localhost.localdomain>
Subject: Re: [Sip] SIPit 20 survey summary
To: "Frank W. Miller" <fwmiller@cornfed.com>, fluffy@cisco.com
X-Authenticated: #29516787
X-Flags: 0001
X-Mailer: WWW-Mail 6100 (Global Message Exchange)
X-Priority: 3
X-Provags-ID: V01U2FsdGVkX1/tikAp+ZHtxl9sRz+Xr2USOPVU9b1OOG0utE2Hcq
	Q4WosGewywSO9ALdst6QJFZO/jhFAlyScCrQ== 
Content-Transfer-Encoding: 7bit
X-GMX-UID: kyJBdeFiODB6UZkCsWVMAoU9Ji9SWpJD
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
Cc: sip@ietf.org, discussion@sipforum.org, jh@tutpro.com,
	sip-implementors@cs.columbia.edu, rjsparks@estacado.net
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi Frank, 
Hi Jeroen, 
Hi Juha, 
Hi all 

what exactly is your complaint? Are you unhappy about
* XML encoding of location information
* location information carried in the body instead of the header
* number of location shapes (see http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo-profile-06.txt)
* the inability of GPS to work in certain environments
* Geopriv location and privacy architecture
* Ecrit emergency services architecture
?

Ciao
Hannes

-------- Original-Nachricht --------
Datum: Sat, 28 Apr 2007 17:23:42 -0600
Von: "Frank W. Miller" <fwmiller@cornfed.com>
An: Cullen Jennings <fluffy@cisco.com>
CC: \'IETF SIP List\' <sip@ietf.org>, discussion@sipforum.org, Juha Heinanen <jh@tutpro.com>, sip-implementors@cs.columbia.edu, \'Robert Sparks\' <rjsparks@estacado.net>
Betreff: Re: [Sip] SIPit 20 survey summary

> 
> Acknowledged.  However, if we're talking about adding messaging
> infrastructure to SIP, then the discussion is quite relevant here.  I
> for one would vote for a simpler mechanism than multipart MIME XML blah
> blah blah.  With regards to Keith's comments, I would love to sit down
> and provide an alternative proposal but I just don't have the time to do
> it.  With all due respect, I'll implement whatever the standards
> committee comes up with, but I don't think its unreasonable for me or
> anyone else to express concern about protocol that is obviously designed
> by committee and obviously more complicated that it probably has to be.
> 
> FM
> 
> 
> On Sat, 2007-04-28 at 15:23 -0700, Cullen Jennings wrote:
> > There has been an incredible amount of work on this topic across many  
> > standard organizations including the IETF. Before people start in on  
> > discussing this in - I strongly suggest they might want to read some  
> > of the requirements, uses cases, drafts, and mailing list discussions  
> > in ECRIT and GEOPRIV. Please keep in mind the charters of ECRIT/ 
> > GEOPRIV/SIP and take the discussion to the right working group.
> > 
> > 
> > On Apr 28, 2007, at 2:35 AM, Juha Heinanen wrote:
> > 
> > > Jeroen van Bemmel writes:
> > >
> > >> Especially for the use case of emergency calls, would it not be  
> > >> wise to
> > >> select a much more simple approach/syntax, e.g.:
> > >> Emergency-Location: lat=x; lon=y
> > >>
> > >> So no XML, no mime/multipart, as simple as possible (no complex  
> > >> semantics,
> > >> usage-rules etc), something to reduce the barrier of
> > >> implementation/deployment, and to reduce the risk for interop issues?
> > >
> > > i fully agree with this.  we should follow KISS principle here.  it is
> > > highly unlikely that sip ua vendors will even TRY implement such a
> > > complex protocol.
> > >
> > > another reason why it will not get implemented is that sip uas don't
> > > know where they are located.  gps does not work well indoors and  
> > > mobile
> > > operators at least here have refused to make public coordinates of  
> > > their
> > > base stations.
> > >
> > > -- juha
> > >
> > >
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol
> > > Use sip-implementors@cs.columbia.edu for questions on current sip
> > > Use sipping@ietf.org for new developments on the application of sip
> > 
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 29 09:38:45 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hi9bY-0005kZ-GY; Sun, 29 Apr 2007 09:38:20 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hi9bX-0005kU-Am
	for sip-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 09:38:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hi9bX-0005kM-1D
	for sip@ietf.org; Sun, 29 Apr 2007 09:38:19 -0400
Received: from smtp3.versatel.nl ([62.58.50.90])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hi9bW-0008GY-DO
	for sip@ietf.org; Sun, 29 Apr 2007 09:38:19 -0400
Received: (qmail 15260 invoked by uid 0); 29 Apr 2007 13:37:56 -0000
Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER)
	([87.212.11.198]) (envelope-sender <jbemmel@zonnet.nl>)
	by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP
	for < >; 29 Apr 2007 13:37:56 -0000
Message-ID: <003201c78a63$74cff690$0601a8c0@BEMBUSTER>
From: "Jeroen van Bemmel" <jbemmel@zonnet.nl>
To: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>,
	"Frank W. Miller" <fwmiller@cornfed.com>, <fluffy@cisco.com>
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com><001401c78976$5f8dc020$0601a8c0@BEMBUSTER><17971.5486.819002.96466@tutpro.com><CCACA85C-15C7-49F2-968B-1F12060CB271@cisco.com><1177802622.3020.8.camel@localhost.localdomain>
	<20070429074034.224850@gmx.net>
Subject: Re: [Sip] SIPit 20 survey summary
Date: Sun, 29 Apr 2007 15:36:56 +0200
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b22590c27682ace61775ee7b453b40d3
Cc: sip@ietf.org, sip-implementors@cs.columbia.edu, jh@tutpro.com,
	discussion@sipforum.org, rjsparks@estacado.net
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi Hannes,

I was responding to Brian's message. He basically says: SIPit results show 
that the mechanisms needed to implement location conveyance are not widely 
implemented yet, we need to tell implementors to hurry it up

I question whether that approach works, and turn it around by asking: why 
are these mechanisms not implemented widely?

Personally I believe a significant part of the answer lies in the complexity 
of the proposed mechanisms, architecure, etc. So instead of trying to push 
the market to adopt the solution that is now on the table, perhaps we should 
look into what we can do to lower the barriers for adoption

Regards,
Jeroen

Hannes Tschofenig wrote:
> Hi Frank,
> Hi Jeroen,
> Hi Juha,
> Hi all
>
> what exactly is your complaint? Are you unhappy about
> * XML encoding of location information
> * location information carried in the body instead of the header
> * number of location shapes (see
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo-profile-06.txt)
> * the inability of GPS to work in certain environments
> * Geopriv location and privacy architecture
> * Ecrit emergency services architecture
> ?
>
> Ciao
> Hannes
>
> -------- Original-Nachricht --------
> Datum: Sat, 28 Apr 2007 17:23:42 -0600
> Von: "Frank W. Miller" <fwmiller@cornfed.com>
> An: Cullen Jennings <fluffy@cisco.com>
> CC: \'IETF SIP List\' <sip@ietf.org>, discussion@sipforum.org, Juha
> Heinanen <jh@tutpro.com>, sip-implementors@cs.columbia.edu, \'Robert
> Sparks\' <rjsparks@estacado.net> Betreff: Re: [Sip] SIPit 20 survey
> summary
>
>>
>> Acknowledged.  However, if we're talking about adding messaging
>> infrastructure to SIP, then the discussion is quite relevant here.  I
>> for one would vote for a simpler mechanism than multipart MIME XML
>> blah blah blah.  With regards to Keith's comments, I would love to
>> sit down and provide an alternative proposal but I just don't have
>> the time to do it.  With all due respect, I'll implement whatever
>> the standards committee comes up with, but I don't think its
>> unreasonable for me or anyone else to express concern about protocol
>> that is obviously designed by committee and obviously more
>> complicated that it probably has to be.
>>
>> FM
>>
>>
>> On Sat, 2007-04-28 at 15:23 -0700, Cullen Jennings wrote:
>>> There has been an incredible amount of work on this topic across
>>> many standard organizations including the IETF. Before people start
>>> in on discussing this in - I strongly suggest they might want to
>>> read some of the requirements, uses cases, drafts, and mailing list
>>> discussions in ECRIT and GEOPRIV. Please keep in mind the charters
>>> of ECRIT/ GEOPRIV/SIP and take the discussion to the right working
>>> group.
>>>
>>>
>>> On Apr 28, 2007, at 2:35 AM, Juha Heinanen wrote:
>>>
>>>> Jeroen van Bemmel writes:
>>>>
>>>>> Especially for the use case of emergency calls, would it not be
>>>>> wise to
>>>>> select a much more simple approach/syntax, e.g.:
>>>>> Emergency-Location: lat=x; lon=y
>>>>>
>>>>> So no XML, no mime/multipart, as simple as possible (no complex
>>>>> semantics,
>>>>> usage-rules etc), something to reduce the barrier of
>>>>> implementation/deployment, and to reduce the risk for interop
>>>>> issues?
>>>>
>>>> i fully agree with this.  we should follow KISS principle here.
>>>> it is highly unlikely that sip ua vendors will even TRY implement
>>>> such a complex protocol.
>>>>
>>>> another reason why it will not get implemented is that sip uas
>>>> don't know where they are located.  gps does not work well indoors
>>>> and mobile
>>>> operators at least here have refused to make public coordinates of
>>>> their
>>>> base stations.
>>>>
>>>> -- juha
>>>>
>>>>
>>>> _______________________________________________
>>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>>> This list is for NEW development of the core SIP Protocol
>>>> Use sip-implementors@cs.columbia.edu for questions on current sip
>>>> Use sipping@ietf.org for new developments on the application of sip
>>>
>>>
>>> _______________________________________________
>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>> This list is for NEW development of the core SIP Protocol
>>> Use sip-implementors@cs.columbia.edu for questions on current sip
>>> Use sipping@ietf.org for new developments on the application of sip
>>
>>
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use sip-implementors@cs.columbia.edu for questions on current sip
>> Use sipping@ietf.org for new developments on the application of sip
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip 



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 29 09:55:23 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hi9s0-0006mF-8n; Sun, 29 Apr 2007 09:55:20 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hi9ry-0006m9-O9
	for sip-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 09:55:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hi9ry-0006m1-Ef
	for sip@ietf.org; Sun, 29 Apr 2007 09:55:18 -0400
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]
	helo=bemg01.siemenscomms.co.uk)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hi9rx-0002rG-45
	for sip@ietf.org; Sun, 29 Apr 2007 09:55:18 -0400
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235])
	by siemenscomms.co.uk (PMDF V6.0-24 #40642)
	with ESMTP id <0JH900I6VINWZD@siemenscomms.co.uk> for sip@ietf.org; Sun,
	29 Apr 2007 14:55:09 +0100 (BST)
Date: Sun, 29 Apr 2007 14:55:15 +0100
From: "Elwell, John" <john.elwell@siemens.com>
Subject: RE: [Sip] Re: draft-ietf-sip-sips-03
In-reply-to: <C2E79FAC-BDE7-49C7-B42A-9C31029D8C90@softarmor.com>
To: Dean Willis <dean.willis@softarmor.com>, Francois Audet <audet@nortel.com>
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00AFAEE@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-Topic: [Sip] Re: draft-ietf-sip-sips-03
Thread-Index: AceJIccYj+PLq3EKTlaOnwx8rZoEYQBRDHag
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <45FE0336.8010506@cisco.com>
	<1177686902.24685.3.camel@eeek.ingate.se>
	<1ECE0EB50388174790F9694F77522CCF1037E9B4@zrc2hxm0.corp.nortel.com>
	<C2E79FAC-BDE7-49C7-B42A-9C31029D8C90@softarmor.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: SIP IETF <sip@ietf.org>, Hans Persson <hasse@ingate.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Isn't this what 416 is for?

John 

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com] 
> Sent: 28 April 2007 00:14
> To: Francois Audet
> Cc: SIP IETF; Hans Persson
> Subject: Re: [Sip] Re: draft-ietf-sip-sips-03
> 
> 
> On Apr 27, 2007, at 4:03 PM, Francois Audet wrote:
> 
> >
> > Basically, I've used 403 (Forbidden) when a UAC tries to register  
> > with the wrong
> > scheme in the Contact.
> >
> > And I've used 404 (Not Found) when a UAC sends a non-REGISTER  
> > request to a SIP URI when only a SIPS URI exists for that 
> resource.  
> > I used to have 403 for that, but I received
> > some comments from somebody on the list that 404 (Not Found) would  
> > be more appropriate.
> >
> > I don't feel strongly about this issue.
> >
> > If anybody has any ideas, please go ahead.
> >
> 
> Nonchair comment:
> 
> If we agree that SIP and SIPS point at the same thing, then 
> rejecting  
> a SIP request with a 404 when there is an "equivalent" registration  
> seems wrong. 403 seems better, but what it seems like we need is an  
> "Invalid Scheme" response. I'm also tempted by 488 (Not Acceptable  
> Here) even though we normally use that for SDP.
> 
> Even a 400 (Bad Request) seems better than 404.
> 
> --
> Dean
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 29 09:59:48 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hi9wJ-0001JB-T9; Sun, 29 Apr 2007 09:59:47 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hi9wI-0001Iz-GG
	for sip-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 09:59:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hi9wI-0001Im-6X
	for sip@ietf.org; Sun, 29 Apr 2007 09:59:46 -0400
Received: from jalapeno.cc.columbia.edu ([128.59.29.5])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hi9wH-00044j-LS
	for sip@ietf.org; Sun, 29 Apr 2007 09:59:45 -0400
Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net
	[70.21.193.163]) (user=hgs10 mech=PLAIN bits=0)
	by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id
	l3TDwXO8015461
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Sun, 29 Apr 2007 09:58:34 -0400 (EDT)
In-Reply-To: <003201c78a63$74cff690$0601a8c0@BEMBUSTER>
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com><001401c78976$5f8dc020$0601a8c0@BEMBUSTER><17971.5486.819002.96466@tutpro.com><CCACA85C-15C7-49F2-968B-1F12060CB271@cisco.com><1177802622.3020.8.camel@localhost.localdomain>
	<20070429074034.224850@gmx.net>
	<003201c78a63$74cff690$0601a8c0@BEMBUSTER>
Mime-Version: 1.0 (Apple Message framework v752.2)
X-Priority: 3
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <17E3095D-AB53-4359-A5E2-4971527B26D2@cs.columbia.edu>
Content-Transfer-Encoding: 7bit
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: [Sip] SIPit 20 survey summary
Date: Sun, 29 Apr 2007 09:58:31 -0400
To: "Jeroen van Bemmel" <jbemmel@zonnet.nl>
X-Mailer: Apple Mail (2.752.2)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: IETF SIP List <sip@ietf.org>, discussion@sipforum.org,
	sip-implementors@cs.columbia.edu, Robert Sparks <rjsparks@estacado.net>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

For the record, I will note that I have made proposals for simple non- 
multipart location conveyance (using the data: URL), but various  
process-related arguments were made as to why we weren't allowed to  
look at that. (I'd prefer even simpler solutions, such as the one  
that XMPP uses, but that's beyond the political correctness limit in  
GEOPRIV.)

I tend to agree that exhortations to developers generally achieve  
little. On the other hand, I'm not sure that belly-aching about  
multipart is all that helpful. After all, most email clients support  
it and there are libraries in various languages to help with  
implementation. Generating multipart bodies is pretty trivial (as  
opposed to parsing them), and that's all embedded devices will  
generally have to do for location conveyance.

On Apr 29, 2007, at 9:36 AM, Jeroen van Bemmel wrote:

> Hi Hannes,
>
> I was responding to Brian's message. He basically says: SIPit  
> results show that the mechanisms needed to implement location  
> conveyance are not widely implemented yet, we need to tell  
> implementors to hurry it up
>
> I question whether that approach works, and turn it around by  
> asking: why are these mechanisms not implemented widely?
>
> Personally I believe a significant part of the answer lies in the  
> complexity of the proposed mechanisms, architecure, etc. So instead  
> of trying to push the market to adopt the solution that is now on  
> the table, perhaps we should look into what we can do to lower the  
> barriers for adoption
>
> Regards,
> Jeroen
>



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 29 10:15:36 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiABa-0000dJ-V9; Sun, 29 Apr 2007 10:15:34 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiABY-0000cd-Kc
	for sip-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 10:15:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiABY-0000cU-AQ
	for sip@ietf.org; Sun, 29 Apr 2007 10:15:32 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiABU-0007JE-V1
	for sip@ietf.org; Sun, 29 Apr 2007 10:15:32 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id E39461EC38C;
	Sun, 29 Apr 2007 17:15:27 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id DSg6MgFkGhPa; Sun, 29 Apr 2007 17:15:25 +0300 (EEST)
Received: from taimen (polymer176.gprs.dnafinland.fi [62.78.110.176])
	by tutpro.com (Postfix) with ESMTP;
	Sun, 29 Apr 2007 17:15:25 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id E497FAC128; Sun, 29 Apr 2007 17:15:18 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17972.43126.846143.625950@tutpro.com>
Date: Sun, 29 Apr 2007 17:15:18 +0300
To: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: [Sip] SIPit 20 survey summary
In-Reply-To: <17E3095D-AB53-4359-A5E2-4971527B26D2@cs.columbia.edu>
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com>
	<001401c78976$5f8dc020$0601a8c0@BEMBUSTER>
	<17971.5486.819002.96466@tutpro.com>
	<CCACA85C-15C7-49F2-968B-1F12060CB271@cisco.com>
	<1177802622.3020.8.camel@localhost.localdomain>
	<20070429074034.224850@gmx.net>
	<003201c78a63$74cff690$0601a8c0@BEMBUSTER>
	<17E3095D-AB53-4359-A5E2-4971527B26D2@cs.columbia.edu>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Cc: IETF SIP List <sip@ietf.org>, sip-implementors@cs.columbia.edu,
	discussion@sipforum.org, Robert Sparks <rjsparks@estacado.net>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Henning Schulzrinne writes:

 > (I'd prefer even simpler solutions, such as the one  
 > that XMPP uses, but that's beyond the political correctness limit in  
 > GEOPRIV.)

sip and xmpp should use identical format for location information.
there will be need to gw sip and xmpp and same format would make it
easy.  so my proposal is that sip ww just refers to
http://www.xmpp.org/extensions/xep-0080.html for location info.

-- juha


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 29 10:36:01 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiAVL-0003HU-OI; Sun, 29 Apr 2007 10:35:59 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiAVK-0003HP-Op
	for sip-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 10:35:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiAVK-0003HH-FE
	for sip@ietf.org; Sun, 29 Apr 2007 10:35:58 -0400
Received: from mail.gmx.net ([213.165.64.20])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HiAVJ-0002o1-2t
	for sip@ietf.org; Sun, 29 Apr 2007 10:35:58 -0400
Received: (qmail 29280 invoked by uid 0); 29 Apr 2007 14:35:55 -0000
Received: from 90.186.139.64 by www068.gmx.net with HTTP;
	Sun, 29 Apr 2007 16:35:55 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 29 Apr 2007 16:35:55 +0200
From: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
In-Reply-To: <003201c78a63$74cff690$0601a8c0@BEMBUSTER>
Message-ID: <20070429143555.77900@gmx.net>
MIME-Version: 1.0
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com><001401c78976$5f8dc020$0601a8c0@BEMBUSTER><17971.5486.819002.96466@tutpro.com><CCACA85C-15C7-49F2-968B-1F12060CB271@cisco.com><1177802622.3020.8.camel@localhost.localdomain>
	<20070429074034.224850@gmx.net>
	<003201c78a63$74cff690$0601a8c0@BEMBUSTER>
Subject: Re: [Sip] SIPit 20 survey summary
To: "Jeroen van Bemmel" <jbemmel@zonnet.nl>, fluffy@cisco.com,
	fwmiller@cornfed.com
X-Authenticated: #29516787
X-Flags: 0001
X-Mailer: WWW-Mail 6100 (Global Message Exchange)
X-Priority: 3
X-Provags-ID: V01U2FsdGVkX18ks8xD5sEkF1m/KbO4NgipxCU7326OTWtx6hoo9G
	ZOOhnIhZzbNczvcbFhNvDdia2AwLR9lCd4Hg== 
Content-Transfer-Encoding: 7bit
X-GMX-UID: fJsHcgxWTXsuTYAHo2U5DSdCRzdyMoOd
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c
Cc: sip@ietf.org, discussion@sipforum.org, jh@tutpro.com,
	sip-implementors@cs.columbia.edu, rjsparks@estacado.net
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi Jeroen, 

I thought that Brian's message was adequate. For some reasons certain based SIP mechanisms have not widely been implemented. Some things take more time than others. 

I would also like to hear whether there are truely barriers for adoption or whether it just takes some time before we see certain features getting implemented. 

I would like to understand the complexity of the proposed mechanisms, if you see some. I am obviously in favor of simplifications.

Ciao
hannes

> Hi Hannes,
> 
> I was responding to Brian's message. He basically says: SIPit results show
> that the mechanisms needed to implement location conveyance are not widely
> implemented yet, we need to tell implementors to hurry it up
> 
> I question whether that approach works, and turn it around by asking: why 
> are these mechanisms not implemented widely?
> 
> Personally I believe a significant part of the answer lies in the
> complexity 
> of the proposed mechanisms, architecure, etc. So instead of trying to push
> the market to adopt the solution that is now on the table, perhaps we
> should 
> look into what we can do to lower the barriers for adoption
> 
> Regards,
> Jeroen
> 
> Hannes Tschofenig wrote:
> > Hi Frank,
> > Hi Jeroen,
> > Hi Juha,
> > Hi all
> >
> > what exactly is your complaint? Are you unhappy about
> > * XML encoding of location information
> > * location information carried in the body instead of the header
> > * number of location shapes (see
> >
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo-profile-06.txt)
> > * the inability of GPS to work in certain environments
> > * Geopriv location and privacy architecture
> > * Ecrit emergency services architecture
> > ?
> >
> > Ciao
> > Hannes
> >
> > -------- Original-Nachricht --------
> > Datum: Sat, 28 Apr 2007 17:23:42 -0600
> > Von: "Frank W. Miller" <fwmiller@cornfed.com>
> > An: Cullen Jennings <fluffy@cisco.com>
> > CC: \'IETF SIP List\' <sip@ietf.org>, discussion@sipforum.org, Juha
> > Heinanen <jh@tutpro.com>, sip-implementors@cs.columbia.edu, \'Robert
> > Sparks\' <rjsparks@estacado.net> Betreff: Re: [Sip] SIPit 20 survey
> > summary
> >
> >>
> >> Acknowledged.  However, if we're talking about adding messaging
> >> infrastructure to SIP, then the discussion is quite relevant here.  I
> >> for one would vote for a simpler mechanism than multipart MIME XML
> >> blah blah blah.  With regards to Keith's comments, I would love to
> >> sit down and provide an alternative proposal but I just don't have
> >> the time to do it.  With all due respect, I'll implement whatever
> >> the standards committee comes up with, but I don't think its
> >> unreasonable for me or anyone else to express concern about protocol
> >> that is obviously designed by committee and obviously more
> >> complicated that it probably has to be.
> >>
> >> FM
> >>
> >>
> >> On Sat, 2007-04-28 at 15:23 -0700, Cullen Jennings wrote:
> >>> There has been an incredible amount of work on this topic across
> >>> many standard organizations including the IETF. Before people start
> >>> in on discussing this in - I strongly suggest they might want to
> >>> read some of the requirements, uses cases, drafts, and mailing list
> >>> discussions in ECRIT and GEOPRIV. Please keep in mind the charters
> >>> of ECRIT/ GEOPRIV/SIP and take the discussion to the right working
> >>> group.
> >>>
> >>>
> >>> On Apr 28, 2007, at 2:35 AM, Juha Heinanen wrote:
> >>>
> >>>> Jeroen van Bemmel writes:
> >>>>
> >>>>> Especially for the use case of emergency calls, would it not be
> >>>>> wise to
> >>>>> select a much more simple approach/syntax, e.g.:
> >>>>> Emergency-Location: lat=x; lon=y
> >>>>>
> >>>>> So no XML, no mime/multipart, as simple as possible (no complex
> >>>>> semantics,
> >>>>> usage-rules etc), something to reduce the barrier of
> >>>>> implementation/deployment, and to reduce the risk for interop
> >>>>> issues?
> >>>>
> >>>> i fully agree with this.  we should follow KISS principle here.
> >>>> it is highly unlikely that sip ua vendors will even TRY implement
> >>>> such a complex protocol.
> >>>>
> >>>> another reason why it will not get implemented is that sip uas
> >>>> don't know where they are located.  gps does not work well indoors
> >>>> and mobile
> >>>> operators at least here have refused to make public coordinates of
> >>>> their
> >>>> base stations.
> >>>>
> >>>> -- juha
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >>>> This list is for NEW development of the core SIP Protocol
> >>>> Use sip-implementors@cs.columbia.edu for questions on current sip
> >>>> Use sipping@ietf.org for new developments on the application of sip
> >>>
> >>>
> >>> _______________________________________________
> >>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >>> This list is for NEW development of the core SIP Protocol
> >>> Use sip-implementors@cs.columbia.edu for questions on current sip
> >>> Use sipping@ietf.org for new developments on the application of sip
> >>
> >>
> >>
> >> _______________________________________________
> >> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >> This list is for NEW development of the core SIP Protocol
> >> Use sip-implementors@cs.columbia.edu for questions on current sip
> >> Use sipping@ietf.org for new developments on the application of sip
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 29 10:39:23 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiAYV-0004oQ-Al; Sun, 29 Apr 2007 10:39:15 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiAYT-0004oJ-Tt
	for sip-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 10:39:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiAYT-0004oB-KP
	for sip@ietf.org; Sun, 29 Apr 2007 10:39:13 -0400
Received: from mail.gmx.net ([213.165.64.20])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HiAYS-0003ob-6B
	for sip@ietf.org; Sun, 29 Apr 2007 10:39:13 -0400
Received: (qmail 19386 invoked by uid 0); 29 Apr 2007 14:39:10 -0000
Received: from 90.186.139.64 by www084.gmx.net with HTTP;
	Sun, 29 Apr 2007 16:39:11 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 29 Apr 2007 16:39:11 +0200
From: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
Message-ID: <20070429143911.77880@gmx.net>
MIME-Version: 1.0
Subject: Re: [Sip] SIPit 20 survey summary
To: jh@tutpro.com, hgs@cs.columbia.edu
X-Authenticated: #29516787
X-Flags: 0001
X-Mailer: WWW-Mail 6100 (Global Message Exchange)
X-Priority: 3
X-Provags-ID: V01U2FsdGVkX19pqw4Bejxpd7TyyH/GiwNFgkuGuo764VMOaJAANR
	bwKTtfQvgUiRinZkjLgb7qM5931CZx14G2EA== 
Content-Transfer-Encoding: 7bit
X-GMX-UID: N5kBchlZTiE+UYACpWVw3GN9ZUVSRJfx
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: sip@ietf.org, sip-implementors@cs.columbia.edu, discussion@sipforum.org,
	rjsparks@estacado.net
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi Henning, 

http://www.xmpp.org/extensions/xep-0080.html takes an interesting approach by largely ignoring previous work on geolocation. It is just too attractive to create your own flavor of civic and geodetic location information format.  

Interestingly enough there is a full-blown solution for XMPP available as well that builds on the OMA protocols. I have to search for the reference, if someone cares. That one is far more complex than GEOPRIV. 

If you argue for simplicity then you refer to  http://www.xmpp.org/extensions/xep-0080.html. 

If you argue for functionality, different environments and interworking with existing systems then you point to the OMA extension. 

It's so easy. Translated to our work in GEOPRIV this would mean the following: If we want to convince people to use it then we just point them to the easy WLAN or enterprise case with a simple civic or a simple point representation. 

Ciao
Hannes

PS: Last November I was at a conference on mobility protocols. Someone gave a presentation on a new mobility protocol design. The author claimed it was very simple. Indeed, it was simple -- because it just didn't care about security. 

-------- Original-Nachricht --------
Datum: Sun, 29 Apr 2007 17:15:18 +0300
Von: jh@tutpro.com
An: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: IETF SIP List <sip@ietf.org>, sip-implementors@cs.columbia.edu, discussion@sipforum.org, Robert Sparks <rjsparks@estacado.net>
Betreff: Re: [Sip] SIPit 20 survey summary

> Henning Schulzrinne writes:
> 
>  > (I'd prefer even simpler solutions, such as the one  
>  > that XMPP uses, but that's beyond the political correctness limit in  
>  > GEOPRIV.)
> 
> sip and xmpp should use identical format for location information.
> there will be need to gw sip and xmpp and same format would make it
> easy.  so my proposal is that sip ww just refers to
> http://www.xmpp.org/extensions/xep-0080.html for location info.
> 
> -- juha
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 29 10:47:29 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiAgR-0008Gk-HY; Sun, 29 Apr 2007 10:47:27 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiAgQ-0008Gf-7I
	for sip-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 10:47:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiAgP-0008GX-UA
	for sip@ietf.org; Sun, 29 Apr 2007 10:47:25 -0400
Received: from hide.pingtel.com ([65.220.123.2] helo=mail.pingtel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiAgO-00063A-MZ
	for sip@ietf.org; Sun, 29 Apr 2007 10:47:25 -0400
Received: from [127.0.0.1] (pi.pingtel.com [10.1.1.12])
	by mail.pingtel.com (Postfix) with ESMTP id D8D126C017;
	Sun, 29 Apr 2007 10:46:56 -0400 (EDT)
Subject: Re: [Sip-implementors] [Sip] SIPit 20 survey summary
From: Scott Lawrence <slawrence@pingtel.com>
To: "Mark R. Lindsey" <lindsey@e-c-group.com>
In-Reply-To: <2296E180-5F91-40B0-876A-7806949C7689@e-c-group.com>
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com>
	<001401c78976$5f8dc020$0601a8c0@BEMBUSTER>
	<2296E180-5F91-40B0-876A-7806949C7689@e-c-group.com>
Content-Type: text/plain
Organization: Pingtel Corp.
Date: Sun, 29 Apr 2007 10:47:23 -0400
Message-Id: <1177858043.3511.6.camel@sukothai.pingtel.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: discussion@sipforum.org, IETF SIP List <sip@ietf.org>,
	Robert Sparks <rjsparks@estacado.net>,
	Juha Heinanen <jh@tutpro.com>, sip-implementors@cs.columbia.edu
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

On Sat, 2007-04-28 at 16:13 -0400, Mark R. Lindsey wrote:
> It is much more reasonable to expect the service-provider/enterprise  
> to implement the location conveyance. They'd add the location in  
> their proxies/B2BUAs/ALGs. For example, an enterprise building ALG  
> could add its location before sending the call to an SP.

On what basis would a proxy/B2BUA/ALG decide what location to add?  I
use the same proxy (in my office) from the same UA (on my laptop) from
many different locations.

> But besides all of this: we've got to get the PSAPs capable of  
> reliably using the location provided in the call. The capability to  
> send the location will be far simpler than actually having a PSAP  
> that can accept and use it.

I think that is easily refutable: compare of the number of PSAPs and
implementations intended for use in them against the number of telephony
providers, pbxs, user agents and implementations intended for such use.
There are very very few of the former, and they are very highly
motivated because they are providing the emergency services; it's the
latter that will take the greater time and effort.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com
  sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs
  Chief Technology Officer    - Pingtel Corp. http://www.pingtel.com/



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 29 10:49:04 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiAhz-0000ND-TI; Sun, 29 Apr 2007 10:49:03 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiAhy-0000N4-Tb
	for sip-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 10:49:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiAhy-0000LB-JM
	for sip@ietf.org; Sun, 29 Apr 2007 10:49:02 -0400
Received: from smtpauth00.csee.onr.siteprotect.com ([64.26.60.144])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiAhx-0006Dn-BY
	for sip@ietf.org; Sun, 29 Apr 2007 10:49:02 -0400
Received: from [192.168.1.120] (c-67-162-139-200.hsd1.co.comcast.net
	[67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com)
	by smtpauth00.csee.onr.siteprotect.com (Postfix) with ESMTP id
	71BE375804E; Sun, 29 Apr 2007 09:49:00 -0500 (CDT)
Subject: Re: [Sip] SIPit 20 survey summary
From: "Frank W. Miller" <fwmiller@cornfed.com>
To: Henning Schulzrinne <hgs@cs.columbia.edu>
In-Reply-To: <17E3095D-AB53-4359-A5E2-4971527B26D2@cs.columbia.edu>
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com>
	<001401c78976$5f8dc020$0601a8c0@BEMBUSTER>
	<17971.5486.819002.96466@tutpro.com>
	<CCACA85C-15C7-49F2-968B-1F12060CB271@cisco.com>
	<1177802622.3020.8.camel@localhost.localdomain>
	<20070429074034.224850@gmx.net>
	<003201c78a63$74cff690$0601a8c0@BEMBUSTER>
	<17E3095D-AB53-4359-A5E2-4971527B26D2@cs.columbia.edu>
Content-Type: text/plain
Date: Sun, 29 Apr 2007 08:48:43 -0600
Message-Id: <1177858123.3028.11.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: IETF SIP List <sip@ietf.org>, Robert Sparks <rjsparks@estacado.net>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

On Sun, 2007-04-29 at 09:58 -0400, Henning Schulzrinne wrote:
> For the record, I will note that I have made proposals for simple non- 
> multipart location conveyance (using the data: URL), but various  
> process-related arguments were made as to why we weren't allowed to  
> look at that. (I'd prefer even simpler solutions, such as the one  
> that XMPP uses, but that's beyond the political correctness limit in  
> GEOPRIV.)
> 

Would it be possible to see these extensions?  Keith asked for
alternative proposals, it seems like looking at that might be a good
idea now.


> I tend to agree that exhortations to developers generally achieve  
> little. On the other hand, I'm not sure that belly-aching about  
> multipart is all that helpful. After all, most email clients support  
> it and there are libraries in various languages to help with  
> implementation. Generating multipart bodies is pretty trivial (as  
> opposed to parsing them), and that's all embedded devices will  
> generally have to do for location conveyance.
> 

As I said, I and others will implement whatever we're directed to.
Personally, I've got Expat in there now for PIDF and even parsing MP
MIME isn't really that hard.

My question is more focused on the essence of the Jeron's off-the-cuff
proposal.  Does the location information belong in the body or in the
main SIP headers?  I believe its the latter primarily for the argument
that was put forth, i.e. the information is so important it deserves
first-class treatment in the message headers.  The fact that its
simplified comes primarily from the fact that you need to be more
compact in your representation if your in the headers.

Dropping the return address list to sip@ietf.org only to minimize
messages in my inbox...


FM





_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 29 10:53:08 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiAlu-0004Ro-P0; Sun, 29 Apr 2007 10:53:06 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiAlt-0004Rj-7T
	for sip-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 10:53:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiAls-0004Rb-U9
	for sip@ietf.org; Sun, 29 Apr 2007 10:53:04 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiAlr-0006we-JU
	for sip@ietf.org; Sun, 29 Apr 2007 10:53:04 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id F0E361EC38C;
	Sun, 29 Apr 2007 17:53:02 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id Aear6tM7SlYl; Sun, 29 Apr 2007 17:53:01 +0300 (EEST)
Received: from taimen (polymer176.gprs.dnafinland.fi [62.78.110.176])
	by tutpro.com (Postfix) with ESMTP;
	Sun, 29 Apr 2007 17:53:01 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id 0474AAC135; Sun, 29 Apr 2007 17:52:57 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17972.45384.981257.4920@tutpro.com>
Date: Sun, 29 Apr 2007 17:52:56 +0300
To: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
Subject: Re: [Sip] SIPit 20 survey summary
In-Reply-To: <20070429143555.77900@gmx.net>
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com>
	<001401c78976$5f8dc020$0601a8c0@BEMBUSTER>
	<17971.5486.819002.96466@tutpro.com>
	<CCACA85C-15C7-49F2-968B-1F12060CB271@cisco.com>
	<1177802622.3020.8.camel@localhost.localdomain>
	<20070429074034.224850@gmx.net>
	<003201c78a63$74cff690$0601a8c0@BEMBUSTER>
	<20070429143555.77900@gmx.net>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Cc: fluffy@cisco.com, discussion@sipforum.org, sip@ietf.org,
	rjsparks@estacado.net, sip-implementors@cs.columbia.edu,
	fwmiller@cornfed.com
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hannes Tschofenig writes:

 > I would like to understand the complexity of the proposed mechanisms,
 > if you see some. I am obviously in favor of simplifications.

number of lines in internet-draft:  2028
number of lines in xmpp spec:        410

just adopt the latter.

-- juha


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 29 10:57:42 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiAqL-0006V2-Bc; Sun, 29 Apr 2007 10:57:41 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiAqJ-0006Ut-Hl
	for sip-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 10:57:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiAqJ-0006Ul-8B
	for sip@ietf.org; Sun, 29 Apr 2007 10:57:39 -0400
Received: from brinza.cc.columbia.edu ([128.59.29.8])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiAqI-0007gL-0g
	for sip@ietf.org; Sun, 29 Apr 2007 10:57:39 -0400
Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net
	[70.21.193.163]) (user=hgs10 mech=PLAIN bits=0)
	by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3TEuQP7020300
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Sun, 29 Apr 2007 10:56:27 -0400 (EDT)
In-Reply-To: <20070429143911.77880@gmx.net>
References: <20070429143911.77880@gmx.net>
Mime-Version: 1.0 (Apple Message framework v752.2)
X-Priority: 3
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <4DC0BA1A-8F26-4218-B3E6-D5BB752DA832@cs.columbia.edu>
Content-Transfer-Encoding: 7bit
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: [Sip] SIPit 20 survey summary
Date: Sun, 29 Apr 2007 10:56:24 -0400
To: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
X-Mailer: Apple Mail (2.752.2)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Cc: sip@ietf.org, sip-implementors@cs.columbia.edu, jh@tutpro.com,
	discussion@sipforum.org, rjsparks@estacado.net
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I mis-spoke. I was actually thinking of a different solution, more  
appropriate to the SIP header model. After all, for geo, two numbers  
(long/lat) in WGS84 datum are all that matters in most circumstances,  
on occasion augmented by a third (some 'measurement accuracy'  
indication).

The XMPP XML model that Juha and you refer to isn't all that much  
simpler than GEOPRIV civic or GML Point, just different, as you note.  
(Whether supporting the multitude of geometric shapes in the pdif-lo  
profile spec is truly required and where is another discussion which  
belongs elsewhere.)

I don't know if by 'security' you refer to the embedded privacy  
policies; in most cases, restrictive default values would do the  
trick for those. Plus, for emergency calls, few PSAPs are going to  
observe 'do not distribute' or 'do not retain' in any event, simply  
because the law in many jurisdictions contradicts those desires.

Henning

On Apr 29, 2007, at 10:39 AM, Hannes Tschofenig wrote:

> Hi Henning,
>
> http://www.xmpp.org/extensions/xep-0080.html takes an interesting  
> approach by largely ignoring previous work on geolocation. It is  
> just too attractive to create your own flavor of civic and geodetic  
> location information format.
>
> Interestingly enough there is a full-blown solution for XMPP  
> available as well that builds on the OMA protocols. I have to  
> search for the reference, if someone cares. That one is far more  
> complex than GEOPRIV.
>
> If you argue for simplicity then you refer to  http://www.xmpp.org/ 
> extensions/xep-0080.html.
>
> If you argue for functionality, different environments and  
> interworking with existing systems then you point to the OMA  
> extension.
>
> It's so easy. Translated to our work in GEOPRIV this would mean the  
> following: If we want to convince people to use it then we just  
> point them to the easy WLAN or enterprise case with a simple civic  
> or a simple point representation.
>
> Ciao
> Hannes
>
> PS: Last November I was at a conference on mobility protocols.  
> Someone gave a presentation on a new mobility protocol design. The  
> author claimed it was very simple. Indeed, it was simple -- because  
> it just didn't care about security.
>



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 29 11:08:53 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiB19-00058g-GY; Sun, 29 Apr 2007 11:08:51 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiB18-00058Y-3B
	for sip-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 11:08:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiB17-00058Q-Q1
	for sip@ietf.org; Sun, 29 Apr 2007 11:08:49 -0400
Received: from serrano.cc.columbia.edu ([128.59.29.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiB16-00020n-Ie
	for sip@ietf.org; Sun, 29 Apr 2007 11:08:49 -0400
Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net
	[70.21.193.163]) (user=hgs10 mech=PLAIN bits=0)
	by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3TF8Z2Q012046
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Sun, 29 Apr 2007 11:08:36 -0400 (EDT)
In-Reply-To: <1177858123.3028.11.camel@localhost.localdomain>
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com>
	<001401c78976$5f8dc020$0601a8c0@BEMBUSTER>
	<17971.5486.819002.96466@tutpro.com>
	<CCACA85C-15C7-49F2-968B-1F12060CB271@cisco.com>
	<1177802622.3020.8.camel@localhost.localdomain>
	<20070429074034.224850@gmx.net>
	<003201c78a63$74cff690$0601a8c0@BEMBUSTER>
	<17E3095D-AB53-4359-A5E2-4971527B26D2@cs.columbia.edu>
	<1177858123.3028.11.camel@localhost.localdomain>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <EC2A3C18-8055-4C2B-B6E4-5047B59495A8@cs.columbia.edu>
Content-Transfer-Encoding: 7bit
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: [Sip] SIPit 20 survey summary
Date: Sun, 29 Apr 2007 11:08:32 -0400
To: "Frank W. Miller" <fwmiller@cornfed.com>
X-Mailer: Apple Mail (2.752.2)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: IETF SIP List <sip@ietf.org>, Robert Sparks <rjsparks@estacado.net>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 29, 2007, at 10:48 AM, Frank W. Miller wrote:

> On Sun, 2007-04-29 at 09:58 -0400, Henning Schulzrinne wrote:
>> For the record, I will note that I have made proposals for simple  
>> non-
>> multipart location conveyance (using the data: URL), but various
>> process-related arguments were made as to why we weren't allowed to
>> look at that. (I'd prefer even simpler solutions, such as the one
>> that XMPP uses, but that's beyond the political correctness limit in
>> GEOPRIV.)
>>
>
> Would it be possible to see these extensions?  Keith asked for
> alternative proposals, it seems like looking at that might be a good
> idea now.

The data URL proposal is simple and is (nominally) allowed within the  
SIP location conveyance document:

GeoLocation: data:application/xml+something,<base64 encoding of PIDF-LO>


(data URLs are defined in RFC 2397). This avoids the use of  
multipart, references and the difficulty of having proxies grope  
around in SIP multipart message bodies for routing-related information.


A more radical proposal is something along the lines of

Geolocation: 48.200927 16.369548 500 200

(longitude, latitude, altitude, 90% percentile accuracy of 200  
meters). Unfortunately, this doesn't generalize as easily to civic  
locations and to more complicated shapes.

>
> My question is more focused on the essence of the Jeron's off-the-cuff
> proposal.  Does the location information belong in the body or in the
> main SIP headers?  I believe its the latter primarily for the argument
> that was put forth, i.e. the information is so important it deserves
> first-class treatment in the message headers.  The fact that its
> simplified comes primarily from the fact that you need to be more
> compact in your representation if your in the headers.

I don't think it's a matter merely of importance, more of function.  
Location is used for routing messages (as well as for the benefit of  
the end system), which is a header function in SIP. Bodies are meant  
for user agents.


>
> FM
>
>



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 29 11:11:28 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiB3g-0006zc-NU; Sun, 29 Apr 2007 11:11:28 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiB3f-0006zT-CC
	for sip-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 11:11:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiB3f-0006zL-2d
	for sip@ietf.org; Sun, 29 Apr 2007 11:11:27 -0400
Received: from mail.gmx.net ([213.165.64.20])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HiB3e-0002pV-H7
	for sip@ietf.org; Sun, 29 Apr 2007 11:11:27 -0400
Received: (qmail 19688 invoked by uid 0); 29 Apr 2007 15:11:25 -0000
Received: from 90.187.53.37 by www082.gmx.net with HTTP;
	Sun, 29 Apr 2007 17:11:25 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 29 Apr 2007 17:11:25 +0200
From: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
In-Reply-To: <4DC0BA1A-8F26-4218-B3E6-D5BB752DA832@cs.columbia.edu>
Message-ID: <20070429151125.77890@gmx.net>
MIME-Version: 1.0
References: <20070429143911.77880@gmx.net>
	<4DC0BA1A-8F26-4218-B3E6-D5BB752DA832@cs.columbia.edu>
Subject: Re: [Sip] SIPit 20 survey summary
To: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Authenticated: #29516787
X-Flags: 0001
X-Mailer: WWW-Mail 6100 (Global Message Exchange)
X-Priority: 3
X-Provags-ID: V01U2FsdGVkX19QVVAD4NtQLVk2BgLRhyLtI8NI3wB3zp7t8Y/il6
	KA0w1U+EELfFFSRLBk5dpefuHcP5/JpKAjBQ== 
Content-Transfer-Encoding: 7bit
X-GMX-UID: /NxBdVkrODB6Q5kCsWVMsFQ9Ji9SWlJW
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: sip@ietf.org, discussion@sipforum.org, jh@tutpro.com,
	sip-implementors@cs.columbia.edu, rjsparks@estacado.net
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi Henning, 

even for the geodetic location information we never came to a clear conclusion how many shapes we need as mandatory to understand by specific nodes. The PIDF-LO profiles draft is listing a number of shape types and currently they are all marked as "mandatory-to-implement". 
 
Given that some location determination techniques produce certain shape types we can only discuss whether it makes sense to reduce the quality of the data already at the Location Generator before further distributing it. 

That's, btw, something we still have to decide for the emergency services use case (and it will need to be described in Phone BCP). I have sent a few mails to PSAP operators to learn what type of location shapes they process today. 

I don't care whether the information is carried in the header or in the body. If it is supposed to be consumed by the end points only then I would argue that is is just fine to convey it within the body. Hence, we are largely discussing location-based routing applications here. 

Ciao
Hannes

-------- Original-Nachricht --------
Datum: Sun, 29 Apr 2007 10:56:24 -0400
Von: Henning Schulzrinne <hgs@cs.columbia.edu>
An: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
CC: jh@tutpro.com, rjsparks@estacado.net, discussion@sipforum.org, sip-implementors@cs.columbia.edu, sip@ietf.org
Betreff: Re: [Sip] SIPit 20 survey summary

> I mis-spoke. I was actually thinking of a different solution, more  
> appropriate to the SIP header model. After all, for geo, two numbers  
> (long/lat) in WGS84 datum are all that matters in most circumstances,  
> on occasion augmented by a third (some 'measurement accuracy'  
> indication).
> 
> The XMPP XML model that Juha and you refer to isn't all that much  
> simpler than GEOPRIV civic or GML Point, just different, as you note.  
> (Whether supporting the multitude of geometric shapes in the pdif-lo  
> profile spec is truly required and where is another discussion which  
> belongs elsewhere.)
> 
> I don't know if by 'security' you refer to the embedded privacy  
> policies; in most cases, restrictive default values would do the  
> trick for those. Plus, for emergency calls, few PSAPs are going to  
> observe 'do not distribute' or 'do not retain' in any event, simply  
> because the law in many jurisdictions contradicts those desires.
> 
> Henning
> 
> On Apr 29, 2007, at 10:39 AM, Hannes Tschofenig wrote:
> 
> > Hi Henning,
> >
> > http://www.xmpp.org/extensions/xep-0080.html takes an interesting  
> > approach by largely ignoring previous work on geolocation. It is  
> > just too attractive to create your own flavor of civic and geodetic  
> > location information format.
> >
> > Interestingly enough there is a full-blown solution for XMPP  
> > available as well that builds on the OMA protocols. I have to  
> > search for the reference, if someone cares. That one is far more  
> > complex than GEOPRIV.
> >
> > If you argue for simplicity then you refer to  http://www.xmpp.org/ 
> > extensions/xep-0080.html.
> >
> > If you argue for functionality, different environments and  
> > interworking with existing systems then you point to the OMA  
> > extension.
> >
> > It's so easy. Translated to our work in GEOPRIV this would mean the  
> > following: If we want to convince people to use it then we just  
> > point them to the easy WLAN or enterprise case with a simple civic  
> > or a simple point representation.
> >
> > Ciao
> > Hannes
> >
> > PS: Last November I was at a conference on mobility protocols.  
> > Someone gave a presentation on a new mobility protocol design. The  
> > author claimed it was very simple. Indeed, it was simple -- because  
> > it just didn't care about security.
> >


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 29 11:12:52 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiB51-0007OG-Qj; Sun, 29 Apr 2007 11:12:51 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiB4z-0007O8-Vk
	for sip-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 11:12:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiB4z-0007O0-MF
	for sip@ietf.org; Sun, 29 Apr 2007 11:12:49 -0400
Received: from mail.gmx.net ([213.165.64.20])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HiB4z-0003LX-7P
	for sip@ietf.org; Sun, 29 Apr 2007 11:12:49 -0400
Received: (qmail 8586 invoked by uid 0); 29 Apr 2007 15:12:48 -0000
Received: from 90.187.53.37 by www077.gmx.net with HTTP;
	Sun, 29 Apr 2007 17:12:48 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 29 Apr 2007 17:12:48 +0200
From: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
In-Reply-To: <1177858123.3028.11.camel@localhost.localdomain>
Message-ID: <20070429151248.77870@gmx.net>
MIME-Version: 1.0
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com>
	<001401c78976$5f8dc020$0601a8c0@BEMBUSTER>
	<17971.5486.819002.96466@tutpro.com>
	<CCACA85C-15C7-49F2-968B-1F12060CB271@cisco.com>
	<1177802622.3020.8.camel@localhost.localdomain>
	<20070429074034.224850@gmx.net>	<003201c78a63$74cff690$0601a8c0@BEMBUSTER>
	<17E3095D-AB53-4359-A5E2-4971527B26D2@cs.columbia.edu>
	<1177858123.3028.11.camel@localhost.localdomain>
Subject: Re: [Sip] SIPit 20 survey summary
To: "Frank W. Miller" <fwmiller@cornfed.com>, hgs@cs.columbia.edu
X-Authenticated: #29516787
X-Flags: 0001
X-Mailer: WWW-Mail 6100 (Global Message Exchange)
X-Priority: 3
X-Provags-ID: V01U2FsdGVkX18VNgs4jwoV1s+xxT6pg7GoJi0GAXLn+mMaG49WrK
	q7UrgLD/be8nMSke0j9r5mJZyOMxs2kDt4DA== 
Content-Transfer-Encoding: 7bit
X-GMX-UID: o8FRNgN/ZCEETp0Zp20h3Xt4IGhpZUYr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: sip@ietf.org, rjsparks@estacado.net
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I proposed something for conveying SAML assertions. Please find a bit of text in the issue tracker: 
http://www.tschofenig.priv.at:8080/saml-sip/issue9

There was also a maling list discussion about this subject but I have to search it. Was already some time ago. 

-------- Original-Nachricht --------
Datum: Sun, 29 Apr 2007 08:48:43 -0600
Von: "Frank W. Miller" <fwmiller@cornfed.com>
An: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: IETF SIP List <sip@ietf.org>, Robert Sparks <rjsparks@estacado.net>
Betreff: Re: [Sip] SIPit 20 survey summary

> On Sun, 2007-04-29 at 09:58 -0400, Henning Schulzrinne wrote:
> > For the record, I will note that I have made proposals for simple non- 
> > multipart location conveyance (using the data: URL), but various  
> > process-related arguments were made as to why we weren't allowed to  
> > look at that. (I'd prefer even simpler solutions, such as the one  
> > that XMPP uses, but that's beyond the political correctness limit in  
> > GEOPRIV.)
> > 
> 
> Would it be possible to see these extensions?  Keith asked for
> alternative proposals, it seems like looking at that might be a good
> idea now.
> 
> 
> > I tend to agree that exhortations to developers generally achieve  
> > little. On the other hand, I'm not sure that belly-aching about  
> > multipart is all that helpful. After all, most email clients support  
> > it and there are libraries in various languages to help with  
> > implementation. Generating multipart bodies is pretty trivial (as  
> > opposed to parsing them), and that's all embedded devices will  
> > generally have to do for location conveyance.
> > 
> 
> As I said, I and others will implement whatever we're directed to.
> Personally, I've got Expat in there now for PIDF and even parsing MP
> MIME isn't really that hard.
> 
> My question is more focused on the essence of the Jeron's off-the-cuff
> proposal.  Does the location information belong in the body or in the
> main SIP headers?  I believe its the latter primarily for the argument
> that was put forth, i.e. the information is so important it deserves
> first-class treatment in the message headers.  The fact that its
> simplified comes primarily from the fact that you need to be more
> compact in your representation if your in the headers.
> 
> Dropping the return address list to sip@ietf.org only to minimize
> messages in my inbox...
> 
> 
> FM
> 
> 
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 29 11:19:06 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiBB2-00033U-WE; Sun, 29 Apr 2007 11:19:05 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiBB1-00033K-25
	for sip-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 11:19:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiBB0-00033C-Oq
	for sip@ietf.org; Sun, 29 Apr 2007 11:19:02 -0400
Received: from mail.gmx.net ([213.165.64.20])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HiBAz-0004Ne-CN
	for sip@ietf.org; Sun, 29 Apr 2007 11:19:02 -0400
Received: (qmail 29084 invoked by uid 0); 29 Apr 2007 15:19:00 -0000
Received: from 90.187.53.37 by www111.gmx.net with HTTP;
	Sun, 29 Apr 2007 17:19:00 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 29 Apr 2007 17:19:00 +0200
From: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
In-Reply-To: <17972.45384.981257.4920@tutpro.com>
Message-ID: <20070429151900.77890@gmx.net>
MIME-Version: 1.0
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com>
	<001401c78976$5f8dc020$0601a8c0@BEMBUSTER>
	<17971.5486.819002.96466@tutpro.com>
	<CCACA85C-15C7-49F2-968B-1F12060CB271@cisco.com>
	<1177802622.3020.8.camel@localhost.localdomain>
	<20070429074034.224850@gmx.net>	<003201c78a63$74cff690$0601a8c0@BEMBUSTER>
	<20070429143555.77900@gmx.net> <17972.45384.981257.4920@tutpro.com>
Subject: Re: [Sip] SIPit 20 survey summary
To: jh@tutpro.com
X-Authenticated: #29516787
X-Flags: 0001
X-Mailer: WWW-Mail 6100 (Global Message Exchange)
X-Priority: 3
X-Provags-ID: V01U2FsdGVkX1/LVKx6k0HLjBY6jy8Blnu/FdPo83SNpuohRf/9Mo
	LYHF9TOtkIbhkj8XnrIg5S/X1pOB/Pq+bTlQ== 
Content-Transfer-Encoding: 7bit
X-GMX-UID: AN5RBwNqfW47X8k5tWRov3JudmllcoU7
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: fluffy@cisco.com, discussion@sipforum.org, sip@ietf.org,
	rjsparks@estacado.net, sip-implementors@cs.columbia.edu,
	fwmiller@cornfed.com
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi, 

I am not sure what drafts you counted but I noticed a couple of things that had an impact on the increase of pages in documents:

* Publication of documents for requirements, frameworks, document design considerations and design decisions
* More examples in the drafts 
* Security con
* Split documents to involve more people as draft authors 
  (=more documents, potentially smaller but each one of them with all the IETF document templates)

Hence, I am not so sure whether the number of papes actually indicate something about the amount of code you have to write. 

Ciao
Hannes

-------- Original-Nachricht --------
Datum: Sun, 29 Apr 2007 17:52:56 +0300
Von: jh@tutpro.com
An: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
CC: "Jeroen van Bemmel" <jbemmel@zonnet.nl>, fluffy@cisco.com, fwmiller@cornfed.com, rjsparks@estacado.net, sip-implementors@cs.columbia.edu, discussion@sipforum.org, sip@ietf.org
Betreff: Re: [Sip] SIPit 20 survey summary

> Hannes Tschofenig writes:
> 
>  > I would like to understand the complexity of the proposed mechanisms,
>  > if you see some. I am obviously in favor of simplifications.
> 
> number of lines in internet-draft:  2028
> number of lines in xmpp spec:        410
> 
> just adopt the latter.
> 
> -- juha


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 29 11:37:26 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiBSm-0005nP-CM; Sun, 29 Apr 2007 11:37:24 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiBSl-0005nI-H6
	for sip-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 11:37:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiBSl-0005n9-7S
	for sip@ietf.org; Sun, 29 Apr 2007 11:37:23 -0400
Received: from smtp3.versatel.nl ([62.58.50.90])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiBSj-0000Ao-OT
	for sip@ietf.org; Sun, 29 Apr 2007 11:37:23 -0400
Received: (qmail 12206 invoked by uid 0); 29 Apr 2007 15:37:00 -0000
Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER)
	([87.212.11.198]) (envelope-sender <jbemmel@zonnet.nl>)
	by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP
	for < >; 29 Apr 2007 15:37:00 -0000
Message-ID: <010201c78a74$16d3fee0$0601a8c0@BEMBUSTER>
From: "Jeroen van Bemmel" <jbemmel@zonnet.nl>
To: "Henning Schulzrinne" <hgs@cs.columbia.edu>,
	"Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
References: <20070429143911.77880@gmx.net>
	<4DC0BA1A-8F26-4218-B3E6-D5BB752DA832@cs.columbia.edu>
Subject: Re: [Sip-implementors] [Sip] SIPit 20 survey summary
Date: Sun, 29 Apr 2007 17:36:00 +0200
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Cc: sip@ietf.org, discussion@sipforum.org, jh@tutpro.com,
	sip-implementors@cs.columbia.edu, rjsparks@estacado.net
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Based on all these discussions (including the proposal to remove emergency 
related text from the draft), I can't help but wonder: is the use case for 
"location conveyance for emergency calls" important and special enough to 
warrant its own solution?

So far, it has been treated as merely a special case of location-based 
routing. But the need for it (yesterday, regulatory driven), the 
security/privacy aspects (ignore them), the required information (single 
location, no shapes e.d.) all seem vastly different from the general case. 
Link that to the observation that a header-based mechanism would be much 
easier to generate (both by UEs and gateways) and parse at routing proxies 
and PSAPs, reducing the chance at errors in situations that may cost lives 
AND speeding up implementation rates, I'd say : separate it out?

Regards,
Jeroen

Henning Schulzrinne wrote:
> I mis-spoke. I was actually thinking of a different solution, more
> appropriate to the SIP header model. After all, for geo, two numbers
> (long/lat) in WGS84 datum are all that matters in most circumstances,
> on occasion augmented by a third (some 'measurement accuracy'
> indication).
>
> The XMPP XML model that Juha and you refer to isn't all that much
> simpler than GEOPRIV civic or GML Point, just different, as you note.
> (Whether supporting the multitude of geometric shapes in the pdif-lo
> profile spec is truly required and where is another discussion which
> belongs elsewhere.)
>
> I don't know if by 'security' you refer to the embedded privacy
> policies; in most cases, restrictive default values would do the
> trick for those. Plus, for emergency calls, few PSAPs are going to
> observe 'do not distribute' or 'do not retain' in any event, simply
> because the law in many jurisdictions contradicts those desires.
>
> Henning
>
> On Apr 29, 2007, at 10:39 AM, Hannes Tschofenig wrote:
>
>> Hi Henning,
>>
>> http://www.xmpp.org/extensions/xep-0080.html takes an interesting
>> approach by largely ignoring previous work on geolocation. It is
>> just too attractive to create your own flavor of civic and geodetic
>> location information format.
>>
>> Interestingly enough there is a full-blown solution for XMPP
>> available as well that builds on the OMA protocols. I have to
>> search for the reference, if someone cares. That one is far more
>> complex than GEOPRIV.
>>
>> If you argue for simplicity then you refer to  http://www.xmpp.org/
>> extensions/xep-0080.html.
>>
>> If you argue for functionality, different environments and
>> interworking with existing systems then you point to the OMA
>> extension.
>>
>> It's so easy. Translated to our work in GEOPRIV this would mean the
>> following: If we want to convince people to use it then we just
>> point them to the easy WLAN or enterprise case with a simple civic
>> or a simple point representation.
>>
>> Ciao
>> Hannes
>>
>> PS: Last November I was at a conference on mobility protocols.
>> Someone gave a presentation on a new mobility protocol design. The
>> author claimed it was very simple. Indeed, it was simple -- because
>> it just didn't care about security.
>>
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors 



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 29 12:34:02 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiCLM-0003uY-Oz; Sun, 29 Apr 2007 12:33:48 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiCLL-0003uQ-0E
	for sip-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 12:33:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiCLK-0003uI-My
	for sip@ietf.org; Sun, 29 Apr 2007 12:33:46 -0400
Received: from mail.gmx.net ([213.165.64.20])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HiCLI-0004ZD-V3
	for sip@ietf.org; Sun, 29 Apr 2007 12:33:46 -0400
Received: (qmail 14126 invoked by uid 0); 29 Apr 2007 16:33:43 -0000
Received: from 90.187.99.76 by www140.gmx.net with HTTP;
	Sun, 29 Apr 2007 18:33:43 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 29 Apr 2007 18:33:43 +0200
From: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
In-Reply-To: <010201c78a74$16d3fee0$0601a8c0@BEMBUSTER>
Message-ID: <20070429163343.77910@gmx.net>
MIME-Version: 1.0
References: <20070429143911.77880@gmx.net>
	<4DC0BA1A-8F26-4218-B3E6-D5BB752DA832@cs.columbia.edu>
	<010201c78a74$16d3fee0$0601a8c0@BEMBUSTER>
Subject: Re: [Sip-implementors] [Sip] SIPit 20 survey summary
To: "Jeroen van Bemmel" <jbemmel@zonnet.nl>, hgs@cs.columbia.edu
X-Authenticated: #29516787
X-Flags: 0001
X-Mailer: WWW-Mail 6100 (Global Message Exchange)
X-Priority: 3
X-Provags-ID: V01U2FsdGVkX1+qLqI1MteqptDJU/Oq9UgChiAy1QhseqN+Bxbxrg
	bUlVmEkci8BQFyXvlev708znfB4OJb+Ze6Rw== 
Content-Transfer-Encoding: 7bit
X-GMX-UID: 1P8Gd1s2IydmA9YGtmZr0EJSa2FkZpUA
X-Spam-Score: 0.5 (/)
X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a
Cc: sip@ietf.org, sip-implementors@cs.columbia.edu, jh@tutpro.com,
	discussion@sipforum.org, rjsparks@estacado.net
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi Jeroen, 

> Based on all these discussions (including the proposal to remove emergency
> related text from the draft), I can't help but wonder: is the use case for
> "location conveyance for emergency calls" important and special enough to 
> warrant its own solution?

The proposal to move emergency service related content from the SIP Location Conveyance draft and from the PIDF-LO Profile draft to the ECRIT Phone BCP document is a document management type of thing. 

Nothing to worry about. Just to keep things together that belong together. 

A few of us also tend to quickly jump to examples about emergency services when we talk about location-based routing or location-based SIP applications. 


I am not sure what you mean by special. 
 
> 
> So far, it has been treated as merely a special case of location-based 
> routing. But the need for it (yesterday, regulatory driven),

Please note that there are different regulatory requirements for different parts. There are no regulatory requirement for plain VoIP emergency services (without PSAP interworking or systems that claim to be a replacement of the PSTN). Note, however, that I am not a laywer and some folks on this list might know more about the state of regulatory affairs throughout the world. 


 the 
> security/privacy aspects (ignore them),

Well. We have discussed many security aspects in the context of emergency services. There are also privacy related aspects that need to be considered. In fact, we recently had a separate panel discussion at the SDO emergency services workshop to address this topic. See http://www.emergency-services-coordination.info/2007/, the slides for the panel sessions can be found here:  http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/EswPanelParticipants

It just varies from country to country. Japan, for example, has quite challenging privacy rules even for emergency services. 


> the required information (single 
> location, no shapes e.d.) all seem vastly different from the general case.

I don't know where you got the message that emergency services works with simpler location shapes. In fact, it would even be necessary to indicate what the different shapes would be used for since there are different consumers in the entire message flow. 

The SDO emergency services workshop I asked the audience about the state-of-the-art location shape types that are being used and I got the impression that fairly complex shapes are already in use today (in the cellular world). I have asked NENA to solicit feedback from the PSAP operator community to learn more about their needs with this respect. A few responses from my own investigations revealed that they would certainly like to have more location information (requiring more complex shapes) for dispatch purposes.  

> Link that to the observation that a header-based mechanism would be much 
> easier to generate (both by UEs and gateways) and parse at routing proxies
> and PSAPs, reducing the chance at errors in situations that may cost lives
> AND speeding up implementation rates, I'd say : separate it out?

Would be great if everything would be just that simple. 

Ciao
Hannes

> 
> Regards,
> Jeroen
> 
> Henning Schulzrinne wrote:
> > I mis-spoke. I was actually thinking of a different solution, more
> > appropriate to the SIP header model. After all, for geo, two numbers
> > (long/lat) in WGS84 datum are all that matters in most circumstances,
> > on occasion augmented by a third (some 'measurement accuracy'
> > indication).
> >
> > The XMPP XML model that Juha and you refer to isn't all that much
> > simpler than GEOPRIV civic or GML Point, just different, as you note.
> > (Whether supporting the multitude of geometric shapes in the pdif-lo
> > profile spec is truly required and where is another discussion which
> > belongs elsewhere.)
> >
> > I don't know if by 'security' you refer to the embedded privacy
> > policies; in most cases, restrictive default values would do the
> > trick for those. Plus, for emergency calls, few PSAPs are going to
> > observe 'do not distribute' or 'do not retain' in any event, simply
> > because the law in many jurisdictions contradicts those desires.
> >
> > Henning
> >
> > On Apr 29, 2007, at 10:39 AM, Hannes Tschofenig wrote:
> >
> >> Hi Henning,
> >>
> >> http://www.xmpp.org/extensions/xep-0080.html takes an interesting
> >> approach by largely ignoring previous work on geolocation. It is
> >> just too attractive to create your own flavor of civic and geodetic
> >> location information format.
> >>
> >> Interestingly enough there is a full-blown solution for XMPP
> >> available as well that builds on the OMA protocols. I have to
> >> search for the reference, if someone cares. That one is far more
> >> complex than GEOPRIV.
> >>
> >> If you argue for simplicity then you refer to  http://www.xmpp.org/
> >> extensions/xep-0080.html.
> >>
> >> If you argue for functionality, different environments and
> >> interworking with existing systems then you point to the OMA
> >> extension.
> >>
> >> It's so easy. Translated to our work in GEOPRIV this would mean the
> >> following: If we want to convince people to use it then we just
> >> point them to the easy WLAN or enterprise case with a simple civic
> >> or a simple point representation.
> >>
> >> Ciao
> >> Hannes
> >>
> >> PS: Last November I was at a conference on mobility protocols.
> >> Someone gave a presentation on a new mobility protocol design. The
> >> author claimed it was very simple. Indeed, it was simple -- because
> >> it just didn't care about security.
> >>
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > Sip-implementors@cs.columbia.edu
> > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 29 15:49:10 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiFOL-0005Nf-3k; Sun, 29 Apr 2007 15:49:05 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiFOK-0005Na-00
	for sip-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 15:49:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiFOJ-0005NS-Mj
	for sip@ietf.org; Sun, 29 Apr 2007 15:49:03 -0400
Received: from smtp2.versatel.nl ([62.58.50.89])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiFOI-00061A-11
	for sip@ietf.org; Sun, 29 Apr 2007 15:49:03 -0400
Received: (qmail 14784 invoked by uid 0); 29 Apr 2007 19:48:57 -0000
Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER)
	([87.212.11.198]) (envelope-sender <jbemmel@zonnet.nl>)
	by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP
	for < >; 29 Apr 2007 19:48:57 -0000
Message-ID: <01af01c78a97$3d8723f0$0601a8c0@BEMBUSTER>
From: "Jeroen van Bemmel" <jbemmel@zonnet.nl>
To: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>,
	<hgs@cs.columbia.edu>
References: <20070429143911.77880@gmx.net>
	<4DC0BA1A-8F26-4218-B3E6-D5BB752DA832@cs.columbia.edu>
	<010201c78a74$16d3fee0$0601a8c0@BEMBUSTER>
	<20070429163343.77910@gmx.net>
Subject: Re: [Sip-implementors] [Sip] SIPit 20 survey summary
Date: Sun, 29 Apr 2007 21:47:37 +0200
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21
Cc: sip@ietf.org, sip-implementors@cs.columbia.edu, jh@tutpro.com,
	discussion@sipforum.org, rjsparks@estacado.net
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi Hannes,

You asked where I saw the complexity of the proposed solution. I see 
complexity in trying to satisfy too many requirements / use cases with a 
single solution. As you illustrate below, the use case for emergency service 
alone is already quite complex by itself.

So, one way to simplify things would be to reduce the number of requirements 
to be satisfied, by focusing on location conveyance for emergency calls only 
(and then perhaps even be selective about the requirements to be included, 
e.g. if the majority of regulators don't have strict privacy requirements 
then don't include those, at least not in the base solution)

Regards,
Jeroen

Hannes Tschofenig wrote:
> Hi Jeroen,
>
>> Based on all these discussions (including the proposal to remove
>> emergency related text from the draft), I can't help but wonder: is
>> the use case for "location conveyance for emergency calls" important
>> and special enough to warrant its own solution?
>
> The proposal to move emergency service related content from the SIP
> Location Conveyance draft and from the PIDF-LO Profile draft to the
> ECRIT Phone BCP document is a document management type of thing.
>
> Nothing to worry about. Just to keep things together that belong
> together.
>
> A few of us also tend to quickly jump to examples about emergency
> services when we talk about location-based routing or location-based
> SIP applications.
>
>
> I am not sure what you mean by special.
>
>>
>> So far, it has been treated as merely a special case of
>> location-based routing. But the need for it (yesterday, regulatory
>> driven),
>
> Please note that there are different regulatory requirements for
> different parts. There are no regulatory requirement for plain VoIP
> emergency services (without PSAP interworking or systems that claim
> to be a replacement of the PSTN). Note, however, that I am not a
> laywer and some folks on this list might know more about the state of
> regulatory affairs throughout the world.
>
>
> the
>> security/privacy aspects (ignore them),
>
> Well. We have discussed many security aspects in the context of
> emergency services. There are also privacy related aspects that need
> to be considered. In fact, we recently had a separate panel
> discussion at the SDO emergency services workshop to address this
> topic. See http://www.emergency-services-coordination.info/2007/, the
> slides for the panel sessions can be found here:
> http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/EswPanelParticipants
>
> It just varies from country to country. Japan, for example, has quite
> challenging privacy rules even for emergency services.
>
>
>> the required information (single
>> location, no shapes e.d.) all seem vastly different from the general
>> case.
>
> I don't know where you got the message that emergency services works
> with simpler location shapes. In fact, it would even be necessary to
> indicate what the different shapes would be used for since there are
> different consumers in the entire message flow.
>
> The SDO emergency services workshop I asked the audience about the
> state-of-the-art location shape types that are being used and I got
> the impression that fairly complex shapes are already in use today
> (in the cellular world). I have asked NENA to solicit feedback from
> the PSAP operator community to learn more about their needs with this
> respect. A few responses from my own investigations revealed that
> they would certainly like to have more location information
> (requiring more complex shapes) for dispatch purposes.
>
>> Link that to the observation that a header-based mechanism would be
>> much easier to generate (both by UEs and gateways) and parse at
>> routing proxies and PSAPs, reducing the chance at errors in
>> situations that may cost lives AND speeding up implementation rates,
>> I'd say : separate it out?
>
> Would be great if everything would be just that simple.
>
> Ciao
> Hannes
>
>>
>> Regards,
>> Jeroen
>>
>> Henning Schulzrinne wrote:
>>> I mis-spoke. I was actually thinking of a different solution, more
>>> appropriate to the SIP header model. After all, for geo, two numbers
>>> (long/lat) in WGS84 datum are all that matters in most
>>> circumstances, on occasion augmented by a third (some 'measurement
>>> accuracy' indication).
>>>
>>> The XMPP XML model that Juha and you refer to isn't all that much
>>> simpler than GEOPRIV civic or GML Point, just different, as you
>>> note. (Whether supporting the multitude of geometric shapes in the
>>> pdif-lo profile spec is truly required and where is another
>>> discussion which belongs elsewhere.)
>>>
>>> I don't know if by 'security' you refer to the embedded privacy
>>> policies; in most cases, restrictive default values would do the
>>> trick for those. Plus, for emergency calls, few PSAPs are going to
>>> observe 'do not distribute' or 'do not retain' in any event, simply
>>> because the law in many jurisdictions contradicts those desires.
>>>
>>> Henning
>>>
>>> On Apr 29, 2007, at 10:39 AM, Hannes Tschofenig wrote:
>>>
>>>> Hi Henning,
>>>>
>>>> http://www.xmpp.org/extensions/xep-0080.html takes an interesting
>>>> approach by largely ignoring previous work on geolocation. It is
>>>> just too attractive to create your own flavor of civic and geodetic
>>>> location information format.
>>>>
>>>> Interestingly enough there is a full-blown solution for XMPP
>>>> available as well that builds on the OMA protocols. I have to
>>>> search for the reference, if someone cares. That one is far more
>>>> complex than GEOPRIV.
>>>>
>>>> If you argue for simplicity then you refer to  http://www.xmpp.org/
>>>> extensions/xep-0080.html.
>>>>
>>>> If you argue for functionality, different environments and
>>>> interworking with existing systems then you point to the OMA
>>>> extension.
>>>>
>>>> It's so easy. Translated to our work in GEOPRIV this would mean the
>>>> following: If we want to convince people to use it then we just
>>>> point them to the easy WLAN or enterprise case with a simple civic
>>>> or a simple point representation.
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>> PS: Last November I was at a conference on mobility protocols.
>>>> Someone gave a presentation on a new mobility protocol design. The
>>>> author claimed it was very simple. Indeed, it was simple -- because
>>>> it just didn't care about security.
>>>>
>>>
>>> _______________________________________________
>>> Sip-implementors mailing list
>>> Sip-implementors@cs.columbia.edu
>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors 



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 29 16:21:38 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiFto-0005Ku-1G; Sun, 29 Apr 2007 16:21:36 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiFtn-0005Kp-9n
	for sip-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 16:21:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiFtn-0005Kg-0F
	for sip@ietf.org; Sun, 29 Apr 2007 16:21:35 -0400
Received: from sccrmhc13.comcast.net ([63.240.77.83])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiFtl-0004M7-Q1
	for sip@ietf.org; Sun, 29 Apr 2007 16:21:34 -0400
Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42])
	by comcast.net (sccrmhc13) with ESMTP
	id <20070429202133013003drb2e>; Sun, 29 Apr 2007 20:21:33 +0000
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l3TKLWqi006890
	for <sip@ietf.org>; Sun, 29 Apr 2007 16:21:32 -0400
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l3TKLWQJ006886;
	Sun, 29 Apr 2007 16:21:32 -0400
Date: Sun, 29 Apr 2007 16:21:32 -0400
Message-Id: <200704292021.l3TKLWQJ006886@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <01af01c78a97$3d8723f0$0601a8c0@BEMBUSTER> (jbemmel@zonnet.nl)
References: <20070429143911.77880@gmx.net>
	<4DC0BA1A-8F26-4218-B3E6-D5BB752DA832@cs.columbia.edu>
	<010201c78a74$16d3fee0$0601a8c0@BEMBUSTER>
	<20070429163343.77910@gmx.net>
	<01af01c78a97$3d8723f0$0601a8c0@BEMBUSTER>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Subject: [Sip] geoloc implementation (Was: SIPit 20 survey summary)
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Is this really as much of a problem as people are making out?

OK, it's *possible* that redesigning the geolocation specification
would be a good thing.  But given the amount of work that has already
been done on it, and the complexity of the requirements, it would take
me a month of work straight to verify that I truly had a Better Idea.
So I am not about to suggest that.

In regard to the complexity of the solution, a UA that provides geoloc
data (once it had some) would seem to have a fairly simple task,
formatting the data into a preselected body.  Even multipart-MIME XML
is simple if one knows in advance the skeleton.

The PSAPs, of course, are stuck parsing and interpreting all possible
formats.  That's a hard job, but on the other hand, PSAPs are built by
a small number of vendors who will be highly motivated to do a good
job.  (And PSAPs are willing to pay for this.)

The difficulty in practice is "How does the UA get its geloc data?"
(Or how does an intermediate agent get the data for the UA?)  This
does not become simpler if we change the format of geoloc data.

I expect that the major barrier to implementing geoloc support has
been the instability of the geoloc specification, combined with the
fact that SIP is not yet entering the mainstream where emergency
services support is required by regulation.

Dale


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 29 18:48:27 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiIBq-0004wC-1P; Sun, 29 Apr 2007 18:48:22 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiIBo-0004vr-3B
	for sip-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 18:48:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiIBn-0004vj-Ik
	for sip@ietf.org; Sun, 29 Apr 2007 18:48:19 -0400
Received: from ihemail1.lucent.com ([135.245.0.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiIBm-00057P-3L
	for sip@ietf.org; Sun, 29 Apr 2007 18:48:19 -0400
Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l3TMmF7Z013846;
	Sun, 29 Apr 2007 17:48:15 -0500 (CDT)
Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by
	ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sun, 29 Apr 2007 17:48:14 -0500
Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by
	DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 30 Apr 2007 00:48:10 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip-implementors] [Sip] SIPit 20 survey summary
Date: Mon, 30 Apr 2007 00:48:09 +0200
Message-ID: <5D1A7985295922448D5550C94DE29180010BFC47@DEEXC1U01.de.lucent.com>
In-Reply-To: <010201c78a74$16d3fee0$0601a8c0@BEMBUSTER>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip-implementors] [Sip] SIPit 20 survey summary
Thread-Index: AceKdE51Z8qyDa/FThCg+1JQNUeRCgAOsXHg
References: <20070429143911.77880@gmx.net><4DC0BA1A-8F26-4218-B3E6-D5BB752DA832@cs.columbia.edu>
	<010201c78a74$16d3fee0$0601a8c0@BEMBUSTER>
From: "Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>
To: "Jeroen van Bemmel" <jbemmel@zonnet.nl>
X-OriginalArrivalTime: 29 Apr 2007 22:48:10.0973 (UTC)
	FILETIME=[7676E8D0:01C78AB0]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b22590c27682ace61775ee7b453b40d3
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

(As WG chair)

You have already had one warning from the area director.

Now this is one from the WG chair.

Get this discussion down to specific proposal to the appropriate WG. We =
are here to discuss chartered drafts. Make specific proposals to the =
chartered drafts on the table or desist.

If you do not know what those are, then go and read the charters.=20

And under no circumstances start including this list in a lot of cross =
postings to other groups.

Regards

Keith

> -----Original Message-----
> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20
> Sent: Sunday, April 29, 2007 4:36 PM
> To: Henning Schulzrinne; Hannes Tschofenig
> Cc: sip@ietf.org; discussion@sipforum.org; jh@tutpro.com;=20
> sip-implementors@cs.columbia.edu; rjsparks@estacado.net
> Subject: Re: [Sip-implementors] [Sip] SIPit 20 survey summary
>=20
> Based on all these discussions (including the proposal to=20
> remove emergency related text from the draft), I can't help=20
> but wonder: is the use case for "location conveyance for=20
> emergency calls" important and special enough to warrant its=20
> own solution?
>=20
> So far, it has been treated as merely a special case of=20
> location-based routing. But the need for it (yesterday,=20
> regulatory driven), the security/privacy aspects (ignore=20
> them), the required information (sinFrom sip-bounces@ietf.org Sun Apr 29 18:48:27 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiIBq-0004wC-1P; Sun, 29 Apr 2007 18:48:22 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiIBo-0004vr-3B
	for sip-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 18:48:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiIBn-0004vj-Ik
	for sip@ietf.org; Sun, 29 Apr 2007 18:48:19 -0400
Received: from ihemail1.lucent.com ([135.245.0.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiIBm-00057P-3L
	for sip@ietf.org; Sun, 29 Apr 2007 18:48:19 -0400
Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l3TMmF7Z013846;
	Sun, 29 Apr 2007 17:48:15 -0500 (CDT)
Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by
	ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sun, 29 Apr 2007 17:48:14 -0500
Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by
	DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 30 Apr 2007 00:48:10 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip-implementors] [Sip] SIPit 20 survey summary
Date: Mon, 30 Apr 2007 00:48:09 +0200
Message-ID: <5D1A7985295922448D5550C94DE29180010BFC47@DEEXC1U01.de.lucent.com>
In-Reply-To: <010201c78a74$16d3fee0$0601a8c0@BEMBUSTER>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip-implementors] [Sip] SIPit 20 survey summary
Thread-Index: AceKdE51Z8qyDa/FThCg+1JQNUeRCgAOsXHg
References: <20070429143911.77880@gmx.net><4DC0BA1A-8F26-4218-B3E6-D5BB752DA832@cs.columbia.edu>
	<010201c78a74$16d3fee0$0601a8c0@BEMBUSTER>
From: "Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>
To: "Jeroen van Bemmel" <jbemmel@zonnet.nl>
X-OriginalArrivalTime: 29 Apr 2007 22:48:10.0973 (UTC)
	FILETIME=[7676E8D0:01C78AB0]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b22590c27682ace61775ee7b453b40d3
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

(As WG chair)

You have already had one warning from the area director.

Now this is one from the WG chair.

Get this discussion down to specific proposal to the appropriate WG. We =
are here to discuss chartered drafts. Make specific proposals to the =
chartered drafts on the table or desist.

If you do not know what those are, then go and read the charters.=20

And under no circumstances start including this list in a lot of cross =
postings to other groups.

Regards

Keith

> -----Original Message-----
> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20
> Sent: Sunday, April 29, 2007 4:36 PM
> To: Henning Schulzrinne; Hannes Tschofenig
> Cc: sip@ietf.org; discussion@sipforum.org; jh@tutpro.com;=20
> sip-implementors@cs.columbia.edu; rjsparks@estacado.net
> Subject: Re: [Sip-implementors] [Sip] SIPit 20 survey summary
>=20
> Based on all these discussions (including the proposal to=20
> remove emergency related text from the draft), I can't help=20
> but wonder: is the use case for "location conveyance for=20
> emergency calls" important and special enough to warrant its=20
> own solution?
>=20
> So far, it has been treated as merely a special case of=20
> location-based routing. But the need for it (yesterday,=20
> regulatory driven), the security/privacy aspects (ignore=20
> them), the required information (single location, no shapes=20
> e.d.) all seem vastly different from the general case.=20
> Link that to the observation that a header-based mechanism=20
> would be much easier to generate (both by UEs and gateways)=20
> and parse at routing proxies and PSAPs, reducing the chance=20
> at errors in situations that may cost lives AND speeding up=20
> implementation rates, I'd say : separate it out?
>=20
> Regards,
> Jeroen
>=20
> Henning Schulzrinne wrote:
> > I mis-spoke. I was actually thinking of a different solution, more=20
> > appropriate to the SIP header model. After all, for geo, two numbers
> > (long/lat) in WGS84 datum are all that matters in most=20
> circumstances,=20
> > on occasion augmented by a third (some 'measurement accuracy'
> > indication).
> >
> > The XMPP XML model that Juha and you refer to isn't all that much=20
> > simpler than GEOPRIV civic or GML Point, just different, as=20
> you note.
> > (Whether supporting the multitude of geometric shapes in=20
> the pdif-lo=20
> > profile spec is truly required and where is another=20
> discussion which=20
> > belongs elsewhere.)
> >
> > I don't know if by 'security' you refer to the embedded privacy=20
> > policies; in most cases, restrictive default values would=20
> do the trick=20
> > for those. Plus, for emergency calls, few PSAPs are going=20
> to observe=20
> > 'do not distribute' or 'do not retain' in any event, simply because=20
> > the law in many jurisdictions contradicts those desires.
> >
> > Henning
> >
> > On Apr 29, 2007, at 10:39 AM, Hannes Tschofenig wrote:
> >
> >> Hi Henning,
> >>
> >> http://www.xmpp.org/extensions/xep-0080.html takes an interesting=20
> >> approach by largely ignoring previous work on geolocation.=20
> It is just=20
> >> too attractive to create your own flavor of civic and geodetic=20
> >> location information format.
> >>
> >> Interestingly enough there is a full-blown solution for XMPP=20
> >> available as well that builds on the OMA protocols. I have=20
> to search=20
> >> for the reference, if someone cares. That one is far more complex=20
> >> than GEOPRIV.
> >>
> >> If you argue for simplicity then you refer to =20
> http://www.xmpp.org/=20
> >> extensions/xep-0080.html.
> >>
> >> If you argue for functionality, different environments and=20
> >> interworking with existing systems then you point to the OMA=20
> >> extension.
> >>
> >> It's so easy. Translated to our work in GEOPRIV this would mean the
> >> following: If we want to convince people to use it then we=20
> just point=20
> >> them to the easy WLAN or enterprise case with a simple civic or a=20
> >> simple point representation.
> >>
> >> Ciao
> >> Hannes
> >>
> >> PS: Last November I was at a conference on mobility protocols.
> >> Someone gave a presentation on a new mobility protocol design. The=20
> >> author claimed it was very simple. Indeed, it was simple=20
> -- because=20
> >> it just didn't care about security.
> >>
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > Sip-implementors@cs.columbia.edu
> > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>=20
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip

From sip-bounces@ietf.org Sun Apr 29 18:48:27 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiIBr-0004wb-Qw; Sun, 29 Apr 2007 18:48:23 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Higle location, no shapes=20
> e.d.) all seem vastly different from the general case.=20
> Link that to the observation that a header-based mechanism=20
> would be much easier to generate (both by UEs and gateways)=20
> and parse at routing proxies and PSAPs, reducing the chance=20
> at errors in situations that may cost lives AND speeding up=20
> implementation rates, I'd say : separate it out?
>=20
> Regards,
> Jeroen
>=20
> Henning Schulzrinne wrote:
> > I mis-spoke. I was actually thinking of a different solution, more=20
> > appropriate to the SIP header model. After all, for geo, two numbers
> > (long/lat) in WGS84 datum are all that matters in most=20
> circumstances,=20
> > on occasion augmented by a third (some 'measurement accuracy'
> > indication).
> >
> > The XMPP XML model that Juha and you refer to isn't all that much=20
> > simpler than GEOPRIV civic or GML Point, just different, as=20
> you note.
> > (Whether supporting the multitude of geometric shapes in=20
> the pdif-lo=20
> > profile spec is truly required and where is another=20
> discussion which=20
> > belongs elsewhere.)
> >
> > I don't know if by 'security' you refer to the embedded privacy=20
> > policies; in most cases, restrictive default values would=20
> do the trick=20
> > for those. Plus, for emergency calls, few PSAPs are going=20
> to observe=20
> > 'do not distribute' or 'do not retain' in any event, simply because=20
> > the law in many jurisdictions contradicts those desires.
> >
> > Henning
> >
> > On Apr 29, 2007, at 10:39 AM, Hannes Tschofenig wrote:
> >
> >> Hi Henning,
> >>
> >> http://www.xmpp.org/extensions/xep-0080.html takes an interesting=20
> >> approach by largely ignoring previous work on geolocation.=20
> It is just=20
> >> too attractive to create your own flavor of civic and geodetic=20
> >> location information format.
> >>
> >> Interestingly enough there is a full-blown solution for XMPP=20
> >> available as well that builds on the OMA protocols. I have=20
> to search=20
> >> for the reference, if someone cares. That one is far more complex=20
> >> than GEOPRIV.
> >>
> >> If you argue for simplicity then you refer to =20
> http://www.xmpp.org/=20
> >> extensions/xep-0080.html.
> >>
> >> If you argue for functionality, different environments and=20
> >> interworking with existing systems then you point to the OMA=20
> >> extension.
> >>
> >> It's so easy. Translated to our work in GEOPRIV this would mean the
> >> following: If we want to convince people to use it then we=20
> just point=20
> >> them to the easy WLAN or enterprise case with a simple civic or a=20
> >> simple point representation.
> >>
> >> Ciao
> >> Hannes
> >>
> >> PS: Last November I was at a conference on mobility protocols.
> >> Someone gave a presentation on a new mobility protocol design. The=20
> >> author claimed it was very simple. Indeed, it was simple=20
> -- because=20
> >> it just didn't care about security.
> >>
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > Sip-implementors@cs.columbia.edu
> > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>=20
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip

From sip-bounces@ietf.org Sun Apr 29 18:48:27 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiIBr-0004wb-Qw; Sun, 29 Apr 2007 18:48:23 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiIBq-0004wH-6x
	for sip-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 18:48:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiIBp-0004w4-SZ
	for sip@ietf.org; Sun, 29 Apr 2007 18:48:21 -0400
Received: from ihemail1.lucent.com ([135.245.0.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiIBp-00057U-Hs
	for sip@ietf.org; Sun, 29 Apr 2007 18:48:21 -0400
Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l3TMmGmt013853;
	Sun, 29 Apr 2007 17:48:20 -0500 (CDT)
Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by
	ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sun, 29 Apr 2007 17:48:16 -0500
Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by
	DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 30 Apr 2007 00:48:12 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit 20 survey summary
Date: Mon, 30 Apr 2007 00:45:23 +0200
Message-ID: <5D1A7985295922448D5550C94DE29180010BFC48@DEEXC1U01.de.lucent.com>
In-Reply-To: <1177858123.3028.11.camel@localhost.localdomain>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit 20 survey summary
Thread-Index: AceKbYwREqyraAtdQGapa3OarEuixQAQfcng
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com><001401c78976$5f8dc020$0601a8c0@BEMBUSTER><17971.5486.819002.96466@tutpro.com><CCACA85C-15C7-49F2-968B-1F12060CB271@cisco.com><1177802622.3020.8.camel@localhost.localdomain><20070429074034.224850@gmx.net><003201c78a63$74cff690$0601a8c0@BEMBUSTER><17E3095D-AB53-4359-A5E2-4971527B26D2@cs.columbia.edu>
	<1177858123.3028.11.camel@localhost.localdomain>
From: "Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>
To: "Frank W. Miller" <fwmiller@cornfed.com>
X-OriginalArrivalTime: 29 Apr 2007 22:48:12.0192 (UTC)
	FILETIME=[7730EA00:01C78AB0]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

(As WG chair)

Please do not misquote me. I have not asked for alternative proposals to
the matters you apparently are discussing.

On other threads, we are seeking WG consensus calls on specific
proposals; it is only on those specific proposals that I have asked for
alternative views.=20

If you have a view on those specific proposals then please contribute to
those threads.

Regards

Keith=20

> -----Original Message-----
> From: Frank W. Miller [mailto:fwmiller@cornfed.com]=20
> Sent: Sunday, April 29, 2007 3:49 PM
> To: Henning Schulzrinne
> Cc: IETF SIP List; Robert Sparks
> Subject: Re: [Sip] SIPit 20 survey summary
>=20
> On Sun, 2007-04-29 at 09:58 -0400, Henning Schulzrinne wrote:
> > For the record, I will note that I have made proposals for=20
> simple non-=20
> > multipart location conveyance (using the data: URL), but various=20
> > process-related arguments were made as to why we weren't allowed to=20
> > look at that. (I'd prefer even simpler solutions, such as=20
> the one that=20
> > XMPP uses, but that's beyond the political correctness limit in
> > GEOPRIV.)
> >=20
>=20
> Would it be possible to see these extensions?  Keith asked=20
> for alternative proposals, it seems like looking at that=20
> might be a good idea now.
>=20
>=20
> > I tend to agree that exhortations to developers generally achieve=20
> > little. On the other hand, I'm not sure that belly-aching IBq-0004wH-6x
	for sip-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 18:48:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiIBp-0004w4-SZ
	for sip@ietf.org; Sun, 29 Apr 2007 18:48:21 -0400
Received: from ihemail1.lucent.com ([135.245.0.33])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiIBp-00057U-Hs
	for sip@ietf.org; Sun, 29 Apr 2007 18:48:21 -0400
Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2])
	by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l3TMmGmt013853;
	Sun, 29 Apr 2007 17:48:20 -0500 (CDT)
Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by
	ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sun, 29 Apr 2007 17:48:16 -0500
Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by
	DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 30 Apr 2007 00:48:12 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] SIPit 20 survey summary
Date: Mon, 30 Apr 2007 00:45:23 +0200
Message-ID: <5D1A7985295922448D5550C94DE29180010BFC48@DEEXC1U01.de.lucent.com>
In-Reply-To: <1177858123.3028.11.camel@localhost.localdomain>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] SIPit 20 survey summary
Thread-Index: AceKbYwREqyraAtdQGapa3OarEuixQAQfcng
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com><001401c78976$5f8dc020$0601a8c0@BEMBUSTER><17971.5486.819002.96466@tutpro.com><CCACA85C-15C7-49F2-968B-1F12060CB271@cisco.com><1177802622.3020.8.camel@localhost.localdomain><20070429074034.224850@gmx.net><003201c78a63$74cff690$0601a8c0@BEMBUSTER><17E3095D-AB53-4359-A5E2-4971527B26D2@cs.columbia.edu>
	<1177858123.3028.11.camel@localhost.localdomain>
From: "Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>
To: "Frank W. Miller" <fwmiller@cornfed.com>
X-OriginalArrivalTime: 29 Apr 2007 22:48:12.0192 (UTC)
	FILETIME=[7730EA00:01C78AB0]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

(As WG chair)

Please do not misquote me. I have not asked for alternative proposals to
the matters you apparently are discussing.

On other threads, we are seeking WG consensus calls on specific
proposals; it is only on those specific proposals that I have asked for
alternative views.=20

If you have a view on those specific proposals then please contribute to
those threads.

Regards

Keith=20

> -----Original Message-----
> From: Frank W. Miller [mailto:fwmiller@cornfed.com]=20
> Sent: Sunday, April 29, 2007 3:49 PM
> To: Henning Schulzrinne
> Cc: IETF SIP List; Robert Sparks
> Subject: Re: [Sip] SIPit 20 survey summary
>=20
> On Sun, 2007-04-29 at 09:58 -0400, Henning Schulzrinne wrote:
> > For the record, I will note that I have made proposals for=20
> simple non-=20
> > multipart location conveyance (using the data: URL), but various=20
> > process-related arguments were made as to why we weren't allowed to=20
> > look at that. (I'd prefer even simpler solutions, such as=20
> the one that=20
> > XMPP uses, but that's beyond the political correctness limit in
> > GEOPRIV.)
> >=20
>=20
> Would it be possible to see these extensions?  Keith asked=20
> for alternative proposals, it seems like looking at that=20
> might be a good idea now.
>=20
>=20
> > I tend to agree that exhortations to developers generally achieve=20
> > little. On the other hand, I'm not sure that belly-aching about=20
> > multipart is all that helpful. After all, most email=20
> clients support=20
> > it and there are libraries in various languages to help with=20
> > implementation. Generating multipart bodies is pretty trivial (as=20
> > opposed to parsing them), and that's all embedded devices will=20
> > generally have to do for location conveyance.
> >=20
>=20
> As I said, I and others will implement whatever we're directed to.
> Personally, I've got Expat in there now for PIDF and even=20
> parsing MP MIME isn't really that hard.
>=20
> My question is more focused on the essence of the Jeron's=20
> off-the-cuff proposal.  Does the location information belong=20
> in the body or in the main SIP headers?  I believe its the=20
> latter primarily for the argument that was put forth, i.e.=20
> the information is so important it deserves first-class=20
> treatment in the message headers.  The fact that its=20
> simplified comes primarily from the fact that you need to be=20
> more compact in your representation if your in the headers.
>=20
> Dropping the return address list to sip@ietf.org only to=20
> minimize messages in my inbox...
>=20
>=20
> FM
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip





about=20
> > multipart is all that helpful. After all, most email=20
> clients support=20
> > it and there are libraries in various languages to help with=20
> > implementation. Generating multipart bodies is pretty trivial (as=20
> > opposed to parsing them), and that's all embedded devices will=20
> > generally have to do for location conveyance.
> >=20
>=20
> As I said, I and others will implement whatever we're directed to.
> Personally, I've got Expat in there now for PIDF and even=20
> parsing MP MIME isn't really that hard.
>=20
> My question is more focused on the essence of the Jeron's=20
> off-the-cuff proposal.  Does the location information belong=20
> in the body or in the main SIP headers?  I believe its the=20
> latter primarily for the argument that was put forth, i.e.=20
> the information is so important it deserves first-class=20
> treatment in the message headers.  The fact that its=20
> simplified comes primarily from the fact that you need to be=20
> more compact in your representation if your in the headers.
>=20
> Dropping the return address list to sip@ietf.org only to=20
> minimize messages in my inbox...
>=20
>=20
> FM
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip





From sip-bounces@ietf.org Sun Apr 29 20:33:23 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiJpM-0000IU-Vu; Sun, 29 Apr 2007 20:33:16 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiJpL-0000IP-UQ
	for sip-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 20:33:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiJpL-0000IE-Kb
	for sip@ietf.org; Sun, 29 Apr 2007 20:33:15 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiJpK-0000RL-Br
	for sip@ietf.org; Sun, 29 Apr 2007 20:33:15 -0400
Received: from [192.168.2.103] (rcdn4-dmznat-gw1-nat-27.cisco.com
	[12.5.186.27]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3TNeDNd001006
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Sun, 29 Apr 2007 18:40:13 -0500
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00AFAEE@GBNTHT12009MSX.gb002.siemens.net>
References: <45FE0336.8010506@cisco.com>
	<1177686902.24685.3.camel@eeek.ingate.se>
	<1ECE0EB50388174790F9694F77522CCF1037E9B4@zrc2hxm0.corp.nortel.com>
	<C2E79FAC-BDE7-49C7-B42A-9C31029D8C90@softarmor.com>
	<0D5F89FAC29E2C41B98A6A762007F5D00AFAEE@GBNTHT12009MSX.gb002.siemens.net>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <FA2C0D2B-9AF6-40CE-B527-5E6E628B5385@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] Re: draft-ietf-sip-sips-03
Date: Sun, 29 Apr 2007 19:32:54 -0500
To: "Elwell, John" <john.elwell@siemens.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: SIP IETF <sip@ietf.org>, Francois Audet <audet@nortel.com>,
	Hans Persson <hasse@ingate.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 29, 2007, at 8:55 AM, Elwell, John wrote:

> Isn't this what 416 is for?

In 2003, Adam said this about 416, and I'm not sure I recall how we  
resolved it:

> Just posting here to request a new bug to be opened against
> RFC 3261.
>
> 21 Response Codes
>
>    The response codes are consistent with, and extend, HTTP/1.1  
> response
>    codes.  Not all HTTP/1.1 response codes are appropriate, and only
>    those that are appropriate are given here.  Other HTTP/1.1 response
>    codes SHOULD NOT be used.
>
> Strictly speaking, this is no longer true -- and I suspect time will
> make it less and less so.
>
> Compare, for example, SIP "416 Unsupported URI Scheme" with
> HTTP "416 Requested Range Not Satisfiable".
>
> We should open up a bug against the spec to revise this language
> when we open it for revisions again.
>
> If complete consistency is required, we need to renumber SIP 416,
> and develop some sort of joint IANA registry (in conjunction with
> and with the buy-in of the HTTP community) to prevent these types
> of collisions in the future. Given how disruptive such a change
> would be, I suspect we should just let the number spaces diverge.

although I think the resolution was that SIP and HTTP had diverged  
and we should just get that through our heads.

--
Dean



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Sun Apr 29 23:54:04 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiMxa-0008H8-FO; Sun, 29 Apr 2007 23:53:58 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiMxY-0008H0-CX
	for sip-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 23:53:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiMxY-0008Gs-2z
	for sip@ietf.org; Sun, 29 Apr 2007 23:53:56 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiMxX-0001rk-PF
	for sip@ietf.org; Sun, 29 Apr 2007 23:53:56 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 29 Apr 2007 23:53:55 -0400
X-IronPort-AV: i="4.14,467,1170651600"; 
	d="scan'208"; a="58972784:sNHT50467136"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3U3rtW9020451; 
	Sun, 29 Apr 2007 23:53:55 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3U3rilG005420; 
	Mon, 30 Apr 2007 03:53:44 GMT
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.1830); 
	Sun, 29 Apr 2007 23:53:44 -0400
Received: from [10.86.240.132] ([10.86.240.132]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Sun, 29 Apr 2007 23:53:44 -0400
Message-ID: <46356847.90306@cisco.com>
Date: Sun, 29 Apr 2007 23:53:43 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Jeroen van Bemmel <jbemmel@zonnet.nl>
Subject: Re: [Sip] outbound-08 : using different Contact URIs for different
	flows?
References: <00ad01c789a8$5de68d10$0601a8c0@BEMBUSTER>
In-Reply-To: <00ad01c789a8$5de68d10$0601a8c0@BEMBUSTER>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Apr 2007 03:53:44.0256 (UTC)
	FILETIME=[25F3E400:01C78ADB]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2098; t=1177905235;
	x=1178769235; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20outbound-08=20=3A=20using=20different=20Conta
	ct=20URIs=20for=20different=0A=20flows? |Sender:=20
	|To:=20Jeroen=20van=20Bemmel=20<jbemmel@zonnet.nl>;
	bh=r0nUlPQOsgp4Ik4Bg/G6MzN2gZPgivpnPFSDjLJV2AA=;
	b=nDh+DRGTr7pPU8iCQgO+a5w2+q2kWc8yr75QBgypaVLLHOw9YW3V9JOB83fVEKY86tCCdIFN
	hqbwWArBExipm42wz4+YKaV/1/x9EQVJinpeY34/QVERFtrpLJzdYumr;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: sip@ietf.org, Cullen Jennings <fluffy@cisco.com>,
	Rohan Mahy <rohan@ekabal.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Jeroen,

Abstractly I understand your issue, and it seems valid, though I would 
like to think about it a bit.

But I'm trying to think of why you would want to do this. If a single UA 
registers multiple contacts with the same AOR, then it is pretty likely 
that incoming calls will be delivered to the UA multiple times. That 
seems like an undesirable situation.

	Paul

Jeroen van Bemmel wrote:
> All,
>  
> While trying to implement GRUU and outbound in combination, I stumbled 
> upon a minor issue: what if the UAC uses different Contact URIs when 
> registering multiple flows. The examples in outbound don't do this, but 
> there is no explicit statement that this is not allowed, and the example 
> in 3.2 (line1@192.168.0.2>;reg-id=1 
> <mailto:line1@192.168.0.2>;reg-id=1>) could be seen as suggesting that 
> the registration with reg-id=2 would use "line2"
>  
> See my previous mail: for GRUU this could mean that the authorative 
> proxy cannot select the right URI to rewrite with, there can be an 
> inconsistency between the temporary GRUU the UAC selected (associated 
> with a specific contact) and the request URI received.
>  
> One solution may be to adapt the algorithm used to generate temporary 
> GRUUs. A second option, which is perhaps simpler, is to simply state in 
> outbound that the UAC MUST use identical Contact URIs when registering 
> multiple flows (in section 4.2), and that the authoritative proxy MAY 
> select any one of the registered Contact URIs to rewrite with (e.g. 
> needed to cover transitional cases where the UAC obtains a new IP 
> address and starts re-registering)
>  
> Regards,
> Jeroen
>  
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 30 00:22:48 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiNPQ-0006Me-Gv; Mon, 30 Apr 2007 00:22:44 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiNPP-0006MZ-8D
	for sip-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 00:22:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiNPO-0006MR-Uy
	for sip@ietf.org; Mon, 30 Apr 2007 00:22:42 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiNPN-0001OK-LG
	for sip@ietf.org; Mon, 30 Apr 2007 00:22:42 -0400
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-2.cisco.com with ESMTP; 30 Apr 2007 00:22:41 -0400
X-IronPort-AV: i="4.14,467,1170651600"; 
	d="scan'208"; a="119849218:sNHT51840388"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3U4MfKc019738; 
	Mon, 30 Apr 2007 00:22:41 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3U4MflG009700; 
	Mon, 30 Apr 2007 04:22:41 GMT
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.1830); 
	Mon, 30 Apr 2007 00:22:41 -0400
Received: from [10.86.240.132] ([10.86.240.132]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 30 Apr 2007 00:22:19 -0400
Message-ID: <46356EFA.8080603@cisco.com>
Date: Mon, 30 Apr 2007 00:22:18 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Dale.Worley@comcast.net
Subject: Re: [Sip] geoloc implementation (Was: SIPit 20 survey summary)
References: <20070429143911.77880@gmx.net>	<4DC0BA1A-8F26-4218-B3E6-D5BB752DA832@cs.columbia.edu>	<010201c78a74$16d3fee0$0601a8c0@BEMBUSTER>	<20070429163343.77910@gmx.net>	<01af01c78a97$3d8723f0$0601a8c0@BEMBUSTER>
	<200704292021.l3TKLWQJ006886@dragon.ariadne.com>
In-Reply-To: <200704292021.l3TKLWQJ006886@dragon.ariadne.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Apr 2007 04:22:19.0505 (UTC)
	FILETIME=[24521E10:01C78ADF]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2431; t=1177906961;
	x=1178770961; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20geoloc=20implementation=20(Was=3A=20SIPit=202
	0=20survey=20summary) |Sender:=20
	|To:=20Dale.Worley@comcast.net;
	bh=mbFzd3VAGX9BL+OQHVEmFvKgLGkuPmbHclStR6GuSqY=;
	b=KMGTlKv6eM8SkoNGECfIVfjiC5Qffkl2R/9RvPyWtjp7PVDsAlmDVApwYxnqAbAsDv+/4dOe
	TG7OinHJmGWtT6W/ZOW0ZnCTsRb5EAHw1AjDb5xdFLm2eVoWWCiMjzlu;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I ignored my mail over the weekend and a lot of water has flowed over 
the dam.

I agree with Dale on this - what is the big deal here?

It was a *huge* mistake not to require multipart support in 3261. Since 
then what has  been lacking is a strong motivator for implementors to 
support it. If this provides the motivation, then hurrah!

Regarding those suggesting adopting the xmpp solution: how do you 
propose to incorporate it into a sip message? The most obvious answer is 
to incorporate it as a body part - still requiring multipart. XMPP has 
the advantage that already supports the moral equivalent of multipart.

	Paul

Dale.Worley@comcast.net wrote:
> Is this really as much of a problem as people are making out?
> 
> OK, it's *possible* that redesigning the geolocation specification
> would be a good thing.  But given the amount of work that has already
> been done on it, and the complexity of the requirements, it would take
> me a month of work straight to verify that I truly had a Better Idea.
> So I am not about to suggest that.
> 
> In regard to the complexity of the solution, a UA that provides geoloc
> data (once it had some) would seem to have a fairly simple task,
> formatting the data into a preselected body.  Even multipart-MIME XML
> is simple if one knows in advance the skeleton.
> 
> The PSAPs, of course, are stuck parsing and interpreting all possible
> formats.  That's a hard job, but on the other hand, PSAPs are built by
> a small number of vendors who will be highly motivated to do a good
> job.  (And PSAPs are willing to pay for this.)
> 
> The difficulty in practice is "How does the UA get its geloc data?"
> (Or how does an intermediate agent get the data for the UA?)  This
> does not become simpler if we change the format of geoloc data.
> 
> I expect that the major barrier to implementing geoloc support has
> been the instability of the geoloc specification, combined with the
> fact that SIP is not yet entering the mainstream where emergency
> services support is required by regulation.
> 
> Dale
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 30 01:05:46 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiO4x-0001d5-9B; Mon, 30 Apr 2007 01:05:39 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiO4w-0001b7-0h
	for sip-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 01:05:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiO4v-0001Zm-L5
	for sip@ietf.org; Mon, 30 Apr 2007 01:05:37 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiO4v-0007PX-Ah
	for sip@ietf.org; Mon, 30 Apr 2007 01:05:37 -0400
Received: from sj-dkim-7.cisco.com ([171.68.10.88])
	by sj-iport-5.cisco.com with ESMTP; 29 Apr 2007 22:05:32 -0700
X-IronPort-AV: i="4.14,467,1170662400"; 
	d="scan'208"; a="416905548:sNHT50011072"
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
	by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l3U55ViS012070; 
	Sun, 29 Apr 2007 22:05:31 -0700
Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id l3U55LA9023582;
	Mon, 30 Apr 2007 05:05:30 GMT
In-Reply-To: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com>
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <9D498630-D070-4E7B-8C94-0EF349C7D29B@cisco.com>
Content-Transfer-Encoding: 7bit
From: Cullen Jennings <fluffy@cisco.com>
Date: Sun, 29 Apr 2007 22:04:45 -0700
To: IETF SIP List <sip@ietf.org>
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3072; t=1177909531;
	x=1178773531; c=relaxed/simple; s=sjdkim7002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=fluffy@cisco.com;
	z=From:=20Cullen=20Jennings=20<fluffy@cisco.com>
	|Subject:=20Support=20for=20Multipart/MIME |Sender:=20;
	bh=WwYBS/A5oYYQFgThLpOVZH045rQSDBLpgVIORaXdJvA=;
	b=EX4Vtkdi7+Id26OKYhCakhRfgYP5xiyJtimxhYti9DvvGHUnCSv9zBFPbxmoBVI+7vWGXZ6I
	LKeAF0DzJzr8IhZNvbo/uxmMXzdXVV46OwtkDN158Weqo7IdwCmlW9DG;
Authentication-Results: sj-dkim-7; header.From=fluffy@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim7002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: 
Subject: [Sip] Support for Multipart/MIME
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


The extensibility model of SIP and SDP is very powerful in most ways.  
It is often done by adding a new thing and if both sides understand  
it, they use it, and if they don't understand it, they use the other  
data in the messages that they both do understand and "fall back" to  
the old behavior. We can do this for headers, URI, and other places  
in SIP. We can do if for SDP attributes. However, there is one place  
were SIP is very lacking in it's ability to be upgraded in the  
future. This is around body extensibility.

The typical way to deal with extensibility of bodies is using MIME  
multipart. This allows a SIP message to cary more than one body and  
the receiver to select and use whichever ones it understands - This  
is all defined for sip except for one problem. It was not mandatory  
to implement and as you can see from the stats below, lots of UAs  
don't implement it.

I believe that sooner or later we will have to do this - it's pretty  
trivial to implement support for receiving multipart even if SDP is  
the only thing your UA knows how to handle.  Now we could argue about  
if emergency calls were the thing that absolutely required us to do  
this but my point is sooner or later we are going to need to deal  
with this - it has come up many times in the past.  I suspect it will  
only get more difficult over time to make this change.

I think the WG should consider an update to 3261 (likely done through  
the process Keith has proposed) that makes this multipart/MIME  
mandatory to implement.

Cullen


On Apr 27, 2007, at 11:48 AM, Brian Rosen wrote:

> I'd like to point out one thing about this:
>
>> This is how they answered for multipart/mime:
>>     2% I break if someone sends me multipart/mime
>>    24% I pretend multipart/mime doesn't exist if someone sends it  
>> to me
>>    24% I ignore multipart/mime but will proxy it or hand it to my
>> application if it shows up
>>    10% I try to do something useful with multipart/mime I receive,
>> but I never send it
>>     4% I ignore multipart/mime that I receive, but I try to do
>> something useful with multipart/mime I send
>>    24% I try to do something useful with multipart/mime I send and
>> receive
>>    12% Other
>
> Moving forward, SIP UAs and proxies will be required to support
> location-conveyance (currently draft-ietf-sip-location- 
> conveyance-07) in
> order to support location for emergency calls (citizen to  
> authority, like
> 1-1-2 or
> 9-1-1).  -conveyance requires multipart support.
>
> The consequences of not supporting emergency call location will be  
> serious.
> I believe it is likely that there will eventually be regulatory  
> requirements
> to support emergency calls in some jurisdictions.  Upgrades to several
> components of today's infrastructure will be needed before this all  
> works,
> but stack vendors and UA developers should put multipart (and
> location-conveyance) on their development plans for next year at  
> the latest.
>
> Brian


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 30 01:18:32 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiOHP-0007kX-Da; Mon, 30 Apr 2007 01:18:31 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiOHO-0007iq-32
	for sip-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 01:18:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiOHM-0007h3-EL
	for sip@ietf.org; Mon, 30 Apr 2007 01:18:28 -0400
Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiOHJ-00033T-Rw
	for sip@ietf.org; Mon, 30 Apr 2007 01:18:28 -0400
Received: from localhost (localhost [127.0.0.1])
	by tutpro.com (Postfix) with ESMTP id 066811EC38C;
	Mon, 30 Apr 2007 08:18:25 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
	by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 0G1X8rVPkAlh; Mon, 30 Apr 2007 08:18:22 +0300 (EEST)
Received: from taimen (telomeres148.gprs.dnafinland.fi [62.78.111.148])
	by tutpro.com (Postfix) with ESMTP;
	Mon, 30 Apr 2007 08:18:22 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
	id 17800AC128; Mon, 30 Apr 2007 08:18:16 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17973.31767.583394.78927@tutpro.com>
Date: Mon, 30 Apr 2007 08:18:15 +0300
To: Paul Kyzivat <pkyzivat@cisco.com>
Subject: Re: [Sip] geoloc implementation (Was: SIPit 20 survey summary)
In-Reply-To: <46356EFA.8080603@cisco.com>
References: <20070429143911.77880@gmx.net>
	<4DC0BA1A-8F26-4218-B3E6-D5BB752DA832@cs.columbia.edu>
	<010201c78a74$16d3fee0$0601a8c0@BEMBUSTER>
	<20070429163343.77910@gmx.net>
	<01af01c78a97$3d8723f0$0601a8c0@BEMBUSTER>
	<200704292021.l3TKLWQJ006886@dragon.ariadne.com>
	<46356EFA.8080603@cisco.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
From: jh@tutpro.com (Juha Heinanen)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Paul Kyzivat writes:

 > Regarding those suggesting adopting the xmpp solution: how do you 
 > propose to incorporate it into a sip message? The most obvious answer is 
 > to incorporate it as a body part - still requiring multipart. XMPP has 
 > the advantage that already supports the moral equivalent of
 > multipart.

multipart is not a big deal to me, but 2027 lines of specification to
read and implement is.

Dale.Worley@comcast.net writes:

 > In regard to the complexity of the solution, a UA that provides geoloc
 > data (once it had some) would seem to have a fairly simple task,
 > formatting the data into a preselected body.  Even multipart-MIME XML
 > is simple if one knows in advance the skeleton.
 > 
 > The PSAPs, of course, are stuck parsing and interpreting all possible
 > formats.  That's a hard job, but on the other hand, PSAPs are built by
 > a small number of vendors who will be highly motivated to do a good
 > job.  (And PSAPs are willing to pay for this.)

you try to say that only PSAPs need to deal with complexity.  that is a
big lie.  there has already been message on this list saying that also
provider and enterprise SIP proxies need to examine and add stuff to the
location data.

to SIP WG management:

you should not disallow discussion on the madness of the resulted
internet draft as whole.  even if GW accepted a charter item, the end
result of the work CAN BE that the requirements led to a too complex
solution that is not implementable in sip proxies in any reasonable
amount of work and that the project needs to be re-charted.

-- juha


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 30 02:57:05 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiPog-000060-AN; Mon, 30 Apr 2007 02:56:58 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiPoe-00005v-J5
	for sip-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 02:56:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiPob-00005g-Be
	for sip@ietf.org; Mon, 30 Apr 2007 02:56:53 -0400
Received: from an-out-0708.google.com ([209.85.132.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiPoa-0000a8-5Y
	for sip@ietf.org; Mon, 30 Apr 2007 02:56:53 -0400
Received: by an-out-0708.google.com with SMTP id d30so1292982and
	for <sip@ietf.org>; Sun, 29 Apr 2007 23:56:51 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
	b=m1uejrkDaX69uyLERssTioCeBMqO4bEB96tPktbV2BL7cIKZ7jadf4lyCAy7wNpJ6YEvamEMzgZPQTQPRLvHnSTt4+2Wt+vTc+I4i2Uwl3Nk1S+MPQyHpD2RiLtsCAvXM8ihicdTp0u8rLtF+zhVCl0T7bxNIQcmUhsh3qLm6vE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
	b=UDlPEx8iINHXXBXAwid3m7JRK4gJ/9v6xdqswYX/brilER4nI4Hbo5kpm5M0I6zpDn4ByJskK+b/jtiuobZhVUWPO0/NeEnJZvAKr5etIqxKnaX5l3xHv4eYT5FTAdKyxHBLQUC2IcY0VjLQ4XztANcoScn5qZznckjJPirJOZo=
Received: by 10.100.202.13 with SMTP id z13mr181233anf.1177916210722;
	Sun, 29 Apr 2007 23:56:50 -0700 (PDT)
Received: by 10.100.194.13 with HTTP; Sun, 29 Apr 2007 23:56:50 -0700 (PDT)
Message-ID: <458913680704292356u4f72ab82i1d91f52c5b6517da@mail.gmail.com>
Date: Mon, 30 Apr 2007 08:56:50 +0200
From: "Xavier Marjou" <xavier.marjou@orange-ftgroup.com>
To: "Dean Willis" <dean.willis@softarmor.com>, 
	"Thomas Froment" <Thomas.Froment@alcatel-lucent.fr>
Subject: Re: Deprecate RR rewriting? (was Re: [Sip]
	draft-ietf-sip-sips-03.txt: Closing of Opened issues)
In-Reply-To: <D07E95E8-6F0A-4F70-BF7B-2C761E2745B6@softarmor.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <1ECE0EB50388174790F9694F77522CCF100DE550@zrc2hxm0.corp.nortel.com>
	<462F613C.2050502@sipstation.com>
	<1ECE0EB50388174790F9694F77522CCF10329CA3@zrc2hxm0.corp.nortel.com>
	<17968.16340.800200.535818@tutpro.com>
	<1ECE0EB50388174790F9694F77522CCF1032A3C9@zrc2hxm0.corp.nortel.com>
	<17968.52760.363575.469609@tutpro.com>
	<4630D67D.2070700@alcatel-lucent.fr>
	<17968.56707.356706.517149@tutpro.com>
	<4630E07C.2010300@alcatel-lucent.fr>
	<D07E95E8-6F0A-4F70-BF7B-2C761E2745B6@softarmor.com>
X-Google-Sender-Auth: 9a06b2b1e567f1f1
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: sip@ietf.org, Juha Heinanen <jh@tutpro.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

> > who would like to deprecate RR rewriting?
> > who want to keep it?
> > who care? ;-)
> >
>
> RR rewriting makes my head hurt, and I always mess up examples that
> use it.
>
> Therefore, I'm in favor of not using it.
>
I agree we should deprecate it.

Xavier


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 30 04:01:06 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiQoc-0001ck-5B; Mon, 30 Apr 2007 04:00:58 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiQoa-0001ca-Gy
	for sip-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 04:00:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiQoZ-0001cJ-Qe
	for sip@ietf.org; Mon, 30 Apr 2007 04:00:55 -0400
Received: from ausmtp05.au.ibm.com ([202.81.18.154])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiQoX-0006tm-8S
	for sip@ietf.org; Mon, 30 Apr 2007 04:00:55 -0400
Received: from sd0109e.au.ibm.com (d23rh905.au.ibm.com [202.81.18.225])
	by ausmtp05.au.ibm.com (8.13.8/8.13.8) with ESMTP id l3U82ZTc8249480
	for <sip@ietf.org>; Mon, 30 Apr 2007 18:02:36 +1000
Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.250.243])
	by sd0109e.au.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id
	l3U84FDv112848 for <sip@ietf.org>; Mon, 30 Apr 2007 18:04:16 +1000
Received: from d23av02.au.ibm.com (loopback [127.0.0.1])
	by d23av02.au.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id
	l3U80hvK027444 for <sip@ietf.org>; Mon, 30 Apr 2007 18:00:43 +1000
Received: from d23mlc37.cn.ibm.com (d23mlc37.cn.ibm.com [9.181.2.106])
	by d23av02.au.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id
	l3U80gaL027397 for <sip@ietf.org>; Mon, 30 Apr 2007 18:00:43 +1000
From: Xin Sheng Mao <maoxs@cn.ibm.com>
To: sip@ietf.org
Message-ID: <OF48BB3029.944E9AA9-ON482572CD.002C1D8C-482572CD.002C1D8C@cn.ibm.com>
Date: Mon, 30 Apr 2007 16:01:51 +0800
X-MIMETrack: Serialize by Router on d23mlc37/23/M/IBM(Release 7.0.2HF32 |
	October 17, 2006) at 30/04/2007 16:01:52
MIME-Version: 1.0
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Subject: [Sip] Xin Sheng Mao/China/IBM is out of the office.
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0376353173=="
Errors-To: sip-bounces@ietf.org

--===============0376353173==
Content-type: multipart/alternative; 
	Boundary="0__=C7BBF85EDFBF9B1C8f9e8a93df938690918cC7BBF85EDFBF9B1C"
Content-Disposition: inline

--0__=C7BBF85EDFBF9B1C8f9e8a93df938690918cC7BBF85EDFBF9B1C
Content-type: text/plain; charset=US-ASCII


I will be out of the office starting  2007-04-30 and will not return until
2007-05-08.

China is on its Labor Holiday vocation, one week long from May 1st to 7th.
I will have zero access to the emails.  Please contact me at 86-13501183394
if you have urgent business.
--0__=C7BBF85EDFBF9B1C8f9e8a93df938690918cC7BBF85EDFBF9B1C
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline

<html><body>
<p>I will be out of the office starting  2007-04-30 and will not return until 2007-05-08.<br>
<br>
China is on its Labor Holiday vocation, one week long from May 1st to 7th.  I will have zero access to the emails.  Please contact me at 86-13501183394 if you have urgent business.</body></html>
--0__=C7BBF85EDFBF9B1C8f9e8a93df938690918cC7BBF85EDFBF9B1C--




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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============0376353173==--






From sip-bounces@ietf.org Mon Apr 30 10:40:47 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiX3D-0008Gs-JF; Mon, 30 Apr 2007 10:40:27 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiX3B-0008Gm-QT
	for sip-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 10:40:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiX3B-0008Ge-Gf
	for sip@ietf.org; Mon, 30 Apr 2007 10:40:25 -0400
Received: from ebru.winwebhosting.com ([74.52.236.50])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiX3A-0000zn-T5
	for sip@ietf.org; Mon, 30 Apr 2007 10:40:25 -0400
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp)
	by ebru.winwebhosting.com with esmtpa (Exim 4.63)
	(envelope-from <br@brianrosen.net>) id 1HiX23-0006rR-JJ
	for sip@ietf.org; Mon, 30 Apr 2007 09:39:16 -0500
From: "Brian Rosen" <br@brianrosen.net>
To: <sip@ietf.org>
Subject: RE: [Sip] geoloc implementation (Was: SIPit 20 survey summary)
Date: Mon, 30 Apr 2007 10:40:21 -0400
Message-ID: <0bf201c78b35$7cf83f80$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <200704292021.l3TKLWQJ006886@dragon.ariadne.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Thread-Index: AceKm91BQrye8SYrQzaxfaThuuLvfgAjA6Gg
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bf422c85703d3d847fb014987125ac48
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I did start this mess, and while I have some regrets, the sooner we get this
over with the better.

I'm going to take one shot at explaining a couple of years of development in
geopriv and ecrit.  I will be happy to correspond with anyone off list on
these matters, but generally, if you want to change the direction of ecrit
and geopriv, go there and work.

Okay.  So the first thing we realized is that the access network (which for
most Internet connected devices is the broadband carrier) usually knows
where you are, and the calling network (the sip network) may not.  Nomadic
operation works on most VoIP and related networks, and when the calling
network and the access network are not the same network, it's the access
network that knows where you are and not the calling network.

In some cases, there are no relationships between the access network and the
calling network.  Example are Vonage or Sunrocket or even jabber.org.  It's
clearly not going to work to force relationships between access networks and
calling networks.  Suppose you are from Sierra Leone, you use Sierra Leone
VoIP Services Pty, and you are currently at a Starbucks in Chicago.  Is it
reasonable, feasible, or even possible for Sierra Leone VoIP to have a
relationship with the DSL supplier that is actually supplying a broadband
connection, or T-Mobile, who is supplying the WiFi service in Chicago?

So, we have pretty much eliminated the notion of the calling network
supplying location.  It is actually possible: a proxy CAN insert location by
reference, but only if it knows FOR CERTAIN, where the endpoint is
(specifically, that it knows which access network the UA is connected to and
it has a relationship with that access network, and has some kind of
identifier which will always yield the right location).  An example of such
a circumstance is an IMS wireless network.  An example that doesn't work is
an IMS wired network with a nomadic user.  An example that is really hard to
deal with is an Ethernet VoIP phone connected to an IMS packet network
through a PC card in a router.

Of course, if the device has a self contained measurement mechanism inside,
and it works where the phone is, great, you don't need an access network.
Since GPS doesn't usually work indoors (yet, they are working on it), your
choices are difficult for self measuring.  The measurement mechanism really
has to work wherever the phone could be.  That's a tall order.  We've made
compromises on mobile (cellular) networks, but they do cause considerable
difficulty in getting help when the caller is not in a location where the
measurement methodology works reliably.

Even if it's the access network that knows where you are, it's the calling
network that has to get the call to the PSAP (or at least handle it, see
below).  If we can't assume a relationship between the access network and
the calling network, what do we do?  The answer is we make use of the
observation that the UA is a client of BOTH the access network AND the
calling network.  The access network gives the UA, which is its subscriber,
its own location.  The UA uses one of several "Location Configuration
Protocols" to get location from the access network.  The puts it in the sip
signaling (with -conveyance) on an emergency call.  The UA is a subscriber
to the calling network.  There are no other entities that have a
relationship with BOTH the access network and the calling network.

In this discussion, a large enterprise is an access network.  It may have a
calling network, but users on the access network may use a service like AIM,
which will be able to place an emergency IM session.  In smaller
enterprises, the underlying broadband carrier is the access network. 

Side step to formats.  There is no easy answer.  What looks simple isn't.
You can't really just hand over a lat/lon in every circumstance, even though
that might work in a few circumstances.  There are two big areas to be
concerned with.  One is civic location.  About 2/3 of the endpoints will be
civic located (street address).  Coming up with a format that works across
the Internet is challenging.  We spent a lot of time on it, and the result
is in geopriv documents.  You can't eliminate civic, and you can't short
circuit the requirements to work across the Internet.  Then there is the
problem of measurement errors in geo.  The required location accuracy for
geo in emergency calls is several cm.  This tells you which side of the
"demising" wall you are on separating two apartments.  When they break down
the door to come to your aid, you would like them to break down the right
door.  Few measurement methods achieve that accuracy.  When they don't, we
need to understand what the measurement represents.  Those that have worked
on this problem for some time use two variables: uncertainty and confidence.
Uncertainty is usually some kind of 2 or 3 dimensional shape, where you are
equally likely to be at any point within the shape.  Confidence is usually a
percentage and it's the likelihood that the uncertainty holds.  When you
send a geo, unless it's really, really accurate, you need to send
uncertainty and confidence, or have some other way to represent what the
measurement means.  Also, we want 3D location (remember the "which
apartment" problem.

And, by the way, don't ever convert (from civic to geo or geo to civic).
Conversion requires a database.  The database has some error in it.  The
PSAP often has to convert itself (typically from geo to civic), and it has a
database which has some error.  If you convert twice, with two different
databases, you can get a very significant error, so we advise never convert.

We then have the issue of who routes.  We have designed a new protocol
(LoST) that takes a location and a service (like single number emergency
call) and returns a URI to route to.  In the development of this scheme, it
was important to us that the same mechanism that routes calls to PSAPs be
useful to route calls to the nearest pizza parlor.  We wanted the access
networks to have every possible reason to deploy the location
infrastructure, and having the same mechanisms (the way location is
obtained, and the way location based routing is done) was considered
important to promote the availability of the mechanisms.  The servers for
emergency call might very well be different from the servers for pizza, but
the location is the same, obtained the same way from the same entity, the
routing mechanism is the same, and the method for applying it (and sending
location for a delivery/response) is the same.  The ecrit documents
recommend that the endpoint do the routing, and that it compute a route, and
cache it, before it needs it.  When the emergency call occurs, we recommend
the route be re-computed if possible.  This guards against the possibility
that the route server may not be accessible when you need it (for example,
in a disaster).  

It is possible for the calling network to route.  It may need to for really
dumb devices, but it's actually pretty hard to make that work.  Again,
nomadic operation is a challenge.  You need to know the "local" dialstring
to determine what is an emergency call.  Local is local to the endpoint at
the time it makes the call.  The LoST service supplies the dialstring for a
location, but typically, the calling network doesn't have the location of
the endpoint unless the endpoint knows it's an emergency call and puts the
location on the call.  Also, the endpoint is local to the database (the
database is distributed, but the part that is relevant for an emergency call
is typically local to the environment the call comes from.  We wanted to
increase the probability that we would get a good route, and that favors
having the endpoint route.  The calling network may have to route in some
circumstances, and to detect fraud (claiming an emergency call when it is
not) it has to validate that the URI the UA claims it got from LoST actually
is a bona fide emergency call URI.

Got it?
1. You get location, in civic or geo forms, from the access network, unless
the device self measures.
2. The device pre-computes a route using LoST and caches it.
3. The device recognizes an emergency call (LoST gives it the dialstring to
look for)
4. The device acquires location and recomputes the route, if possible
5. The device routes the call to the URI it obtains, along with its location
(using -conveyance).  We have a mechanism to mark emergency calls (service
urn).
6. The calling network CAN, if it really knows what is happening, put
location on the call.  It CAN, if it really knows what is happening, look
for the emergency dialstring(s).  It CAN, if it has location and knows its
an emergency call, route it.  I can also verify that the URI it's routing
towards for an emergency call is valid.

Again, if you have questions, email me privately, or come over and join the
fun in ecrit and geopriv

Brian



> -----Original Message-----
> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]
> Sent: Sunday, April 29, 2007 4:22 PM
> To: sip@ietf.org
> Subject: [Sip] geoloc implementation (Was: SIPit 20 survey summary)
> 
> Is this really as much of a problem as people are making out?
> 
> OK, it's *possible* that redesigning the geolocation specification
> would be a good thing.  But given the amount of work that has already
> been done on it, and the complexity of the requirements, it would take
> me a month of work straight to verify that I truly had a Better Idea.
> So I am not about to suggest that.
> 
> In regard to the complexity of the solution, a UA that provides geoloc
> data (once it had some) would seem to have a fairly simple task,
> formatting the data into a preselected body.  Even multipart-MIME XML
> is simple if one knows in advance the skeleton.
> 
> The PSAPs, of course, are stuck parsing and interpreting all possible
> formats.  That's a hard job, but on the other hand, PSAPs are built by
> a small number of vendors who will be highly motivated to do a good
> job.  (And PSAPs are willing to pay for this.)
> 
> The difficulty in practice is "How does the UA get its geloc data?"
> (Or how does an intermediate agent get the data for the UA?)  This
> does not become simpler if we change the format of geoloc data.
> 
> I expect that the major barrier to implementing geoloc support has
> been the instability of the geoloc specification, combined with the
> fact that SIP is not yet entering the mainstream where emergency
> services support is required by regulation.
> 
> Dale
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 30 10:43:20 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiX5z-0003Fo-IC; Mon, 30 Apr 2007 10:43:19 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiX5x-0003FW-Lp
	for sip-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 10:43:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiX5x-0003FO-Bs; Mon, 30 Apr 2007 10:43:17 -0400
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HiX5w-0001FW-5G; Mon, 30 Apr 2007 10:43:17 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 20A253293C;
	Mon, 30 Apr 2007 14:43:16 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1HiX5w-0001ie-1B; Mon, 30 Apr 2007 10:43:16 -0400
X-test-idtracker: no
To: IETF-Announce <ietf-announce@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
Message-Id: <E1HiX5w-0001ie-1B@stiedprstage1.ietf.org>
Date: Mon, 30 Apr 2007 10:43:16 -0400
X-Spam-Score: -2.8 (--)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: sip@ietf.org
Subject: [Sip] Last Call: draft-ietf-sip-e2m-sec (End-to-middle Security in 
 the Session Initiation Protocol (SIP)) to Proposed Standard 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

The IESG has received a request from the Session Initiation Protocol WG 
(sip) to consider the following document:

- 'End-to-middle Security in the Session Initiation Protocol (SIP) '
   <draft-ietf-sip-e2m-sec-05.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2007-05-14. Exceptionally, 
comments may be sent to iesg@ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sip-e2m-sec-05.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13377&rfc_flag=0



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 30 11:55:16 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiYDX-0000qj-PL; Mon, 30 Apr 2007 11:55:11 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiYDW-0000qL-7A
	for sip-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 11:55:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiYDV-0000qD-U1; Mon, 30 Apr 2007 11:55:09 -0400
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HiYDV-00042i-Nt; Mon, 30 Apr 2007 11:55:09 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 9D62526ED1;
	Mon, 30 Apr 2007 15:55:09 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1HiYDV-0007yZ-Hf; Mon, 30 Apr 2007 11:55:09 -0400
X-test-idtracker: no
To: IETF-Announce <ietf-announce@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
Message-Id: <E1HiYDV-0007yZ-Hf@stiedprstage1.ietf.org>
Date: Mon, 30 Apr 2007 11:55:09 -0400
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: sip@ietf.org
Subject: [Sip] Last Call: draft-ietf-sip-fork-loop-fix (Addressing an 
 Amplification Vulnerability in Session Initiation Protocol 
 (SIP) Forking Proxies) to Proposed Standard 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

The IESG has received a request from the Session Initiation Protocol WG 
(sip) to consider the following document:

- 'Addressing an Amplification Vulnerability in Session Initiation 
   Protocol (SIP) Forking Proxies '
   <draft-ietf-sip-fork-loop-fix-05.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2007-05-14. Exceptionally, 
comments may be sent to iesg@ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sip-fork-loop-fix-05.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14447&rfc_flag=0



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 30 12:01:07 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiYJE-0006oj-Vi; Mon, 30 Apr 2007 12:01:04 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiYJE-0006ob-EE
	for sip-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 12:01:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiYJE-0006oQ-4L
	for sip@ietf.org; Mon, 30 Apr 2007 12:01:04 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiYJC-0005HO-P4
	for sip@ietf.org; Mon, 30 Apr 2007 12:01:04 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3UG0dJ00106; Mon, 30 Apr 2007 16:00:39 GMT
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: [Sip] Re: draft-ietf-sip-sips-03
Date: Mon, 30 Apr 2007 11:00:36 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF103F2FEB@zrc2hxm0.corp.nortel.com>
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00AFAEE@GBNTHT12009MSX.gb002.siemens.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Re: draft-ietf-sip-sips-03
Thread-Index: AceJIccYj+PLq3EKTlaOnwx8rZoEYQBRDHagADZSIsA=
References: <45FE0336.8010506@cisco.com>
	<1177686902.24685.3.camel@eeek.ingate.se>
	<1ECE0EB50388174790F9694F77522CCF1037E9B4@zrc2hxm0.corp.nortel.com>
	<C2E79FAC-BDE7-49C7-B42A-9C31029D8C90@softarmor.com>
	<0D5F89FAC29E2C41B98A6A762007F5D00AFAEE@GBNTHT12009MSX.gb002.siemens.net>
From: "Francois Audet" <audet@nortel.com>
To: "Elwell, John" <john.elwell@siemens.com>,
	"Dean Willis" <dean.willis@softarmor.com>,
	"Robert Sparks" <rjsparks@nostrum.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: SIP IETF <sip@ietf.org>, Hans Persson <hasse@ingate.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

No.

416 is for "I don't understand your scheme, you can try sip: instead".
It is very likely
that the endpoint will then try sip:

It makes no sense in the other direction, i.e., when you receive SIP but
you only
allow for a SIPS resource (it would cause an infinite loop).

The interesting thing with 416 is that a proxy or UAS that doesn't
support SIPS is that
it is likely to use it. If the UAC is "dumb" it would retry it with sip
(which would
effectively be a downgrade, and therefore would be bad).

A proxy or UAS that wants to REJECT a SIPS request and not risk having
the UA re-attempting
the session by downgrading should therefore use something else.

Initially, I tought 403 was the proper mechanism. Juha seems to agree.
Dean also seems to=20
like it.

Robert, any toughts? I think I remember it was you who preferred 404?

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens.com]=20
> Sent: Sunday, April 29, 2007 06:55
> To: Dean Willis; Audet, Francois (SC100:3055)
> Cc: SIP IETF; Hans Persson
> Subject: RE: [Sip] Re: draft-ietf-sip-sips-03
>=20
> Isn't this what 416 is for?
>=20
> John=20
>=20
> > -----Original Message-----
> > From: Dean Willis [mailto:dean.willis@softarmor.com]
> > Sent: 28 April 2007 00:14
> > To: Francois Audet
> > Cc: SIP IETF; Hans Persson
> > Subject: Re: [Sip] Re: draft-ietf-sip-sips-03
> >=20
> >=20
> > On Apr 27, 2007, at 4:03 PM, Francois Audet wrote:
> >=20
> > >
> > > Basically, I've used 403 (Forbidden) when a UAC tries to register=20
> > > with the wrong scheme in the Contact.
> > >
> > > And I've used 404 (Not Found) when a UAC sends a non-REGISTER=20
> > > request to a SIP URI when only a SIPS URI exists for that
> > resource. =20
> > > I used to have 403 for that, but I received some comments from=20
> > > somebody on the list that 404 (Not Found) would be more=20
> appropriate.
> > >
> > > I don't feel strongly about this issue.
> > >
> > > If anybody has any ideas, please go ahead.
> > >
> >=20
> > Nonchair comment:
> >=20
> > If we agree that SIP and SIPS point at the same thing, then=20
> rejecting=20
> > a SIP request with a 404 when there is an "equivalent" registration=20
> > seems wrong. 403 seems better, but what it seems like we need is an=20
> > "Invalid Scheme" response. I'm also tempted by 488 (Not Acceptable
> > Here) even though we normally use that for SDP.
> >=20
> > Even a 400 (Bad Request) seems better than 404.
> >=20
> > --
> > Dean
> >=20
> >=20
> >=20
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use=20
> > sip-implementors@cs.columbia.edu for questions on current sip Use=20
> > sipping@ietf.org for new developments on the application of sip
> >=20
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 30 12:13:25 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiYUp-0000pz-QL; Mon, 30 Apr 2007 12:13:03 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiYUo-0000l5-3H
	for sip-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 12:13:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiYUn-0000jS-ML
	for sip@ietf.org; Mon, 30 Apr 2007 12:13:01 -0400
Received: from alnrmhc12.comcast.net ([206.18.177.52])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiYUm-0006ol-Fh
	for sip@ietf.org; Mon, 30 Apr 2007 12:13:01 -0400
Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42])
	by comcast.net (alnrmhc12) with ESMTP
	id <20070430161259b12008onsbe>; Mon, 30 Apr 2007 16:12:59 +0000
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1])
	by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l3UGCwqi029166
	for <sip@ietf.org>; Mon, 30 Apr 2007 12:12:58 -0400
Received: (from worley@localhost)
	by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l3UGCwsM029162;
	Mon, 30 Apr 2007 12:12:58 -0400
Date: Mon, 30 Apr 2007 12:12:58 -0400
Message-Id: <200704301612.l3UGCwsM029162@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <9D498630-D070-4E7B-8C94-0EF349C7D29B@cisco.com>
	(fluffy@cisco.com)
Subject: Re: [Sip] Support for Multipart/MIME
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com>
	<9D498630-D070-4E7B-8C94-0EF349C7D29B@cisco.com>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

   From: Cullen Jennings <fluffy@cisco.com>

   I think the WG should consider an update to 3261 (likely done through  
   the process Keith has proposed) that makes this multipart/MIME  
   mandatory to implement.

I assume that the requirement is that if a message has a
multipart/alternative body, and the UA is capable of understanding one
part of the body, then it must be able to extract that part and use it
to process the message.

Dale


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 30 12:25:54 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiYhB-0004Gk-Cw; Mon, 30 Apr 2007 12:25:49 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiYh8-0004Gf-Nq
	for sip-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 12:25:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiYh8-0004GX-EE
	for sip@ietf.org; Mon, 30 Apr 2007 12:25:46 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiYh7-0000Nk-3l
	for sip@ietf.org; Mon, 30 Apr 2007 12:25:46 -0400
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-2.cisco.com with ESMTP; 30 Apr 2007 12:25:15 -0400
X-IronPort-AV: i="4.14,471,1170651600"; 
	d="scan'208"; a="119893448:sNHT80952375154"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3UGPFqT017471; 
	Mon, 30 Apr 2007 12:25:15 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3UGPAlK004805; 
	Mon, 30 Apr 2007 16:25:15 GMT
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.1830); 
	Mon, 30 Apr 2007 12:25:12 -0400
Received: from [161.44.174.124] ([161.44.174.124]) by
	xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 30 Apr 2007 12:25:12 -0400
Message-ID: <46361867.9010301@cisco.com>
Date: Mon, 30 Apr 2007 12:25:11 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Dale.Worley@comcast.net
Subject: Re: [Sip] Support for Multipart/MIME
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com>	<9D498630-D070-4E7B-8C94-0EF349C7D29B@cisco.com>
	<200704301612.l3UGCwsM029162@dragon.ariadne.com>
In-Reply-To: <200704301612.l3UGCwsM029162@dragon.ariadne.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Apr 2007 16:25:12.0446 (UTC)
	FILETIME=[209BB1E0:01C78B44]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1171; t=1177950315;
	x=1178814315; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=pkyzivat@cisco.com;
	z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20Support=20for=20Multipart/MIME
	|Sender:=20 |To:=20Dale.Worley@comcast.net;
	bh=oD+AN50crrjg0Kv8pnF3F4Gpc8T/LWCB+TJZU+f58V0=;
	b=Oq0UR86yJxsIpFZhzYw+QK42z4wV8c1M2ST4TO0gMohAUvvx1YRWeJcDu9J6HdrqeXGE52hc
	hD/QMptSG03t5e0GO/yM/AIRG7HtGXYEjESw1N4ReZORgJYj5ZTcQEC6;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org



Dale.Worley@comcast.net wrote:
>    From: Cullen Jennings <fluffy@cisco.com>
> 
>    I think the WG should consider an update to 3261 (likely done through  
>    the process Keith has proposed) that makes this multipart/MIME  
>    mandatory to implement.
> 
> I assume that the requirement is that if a message has a
> multipart/alternative body, and the UA is capable of understanding one
> part of the body, then it must be able to extract that part and use it
> to process the message.

While there is a place for multipart/alternative, I think the key 
requirement is that if there is a multipart/mixed then the UA should 
look within it for one or more parts that it would know how to handle if 
they were the only part in the body.

While doing this it also needs to process the handling= parameter on the 
Content-Disposition header. It can ignore parts with handling=optional, 
but must punt if handling=required on some part and it doesn't know how 
to handle it.

Writing down precisely what handling multipart means in sip would make a 
nice little draft. I expect there would be at least a bit of controversy 
about it.

	Paul


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 30 12:28:48 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiYjz-0005fI-Kh; Mon, 30 Apr 2007 12:28:43 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiYjy-0005e5-LB
	for sip-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 12:28:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiYjy-0005dQ-An
	for sip@ietf.org; Mon, 30 Apr 2007 12:28:42 -0400
Received: from smtpauth00.csee.onr.siteprotect.com ([64.26.60.144])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiYju-0000lP-0I
	for sip@ietf.org; Mon, 30 Apr 2007 12:28:42 -0400
Received: from [192.168.1.120] (c-67-162-139-200.hsd1.co.comcast.net
	[67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com)
	by smtpauth00.csee.onr.siteprotect.com (Postfix) with ESMTP id
	5B7A0758059; Mon, 30 Apr 2007 11:28:37 -0500 (CDT)
Subject: Re: [Sip] Support for Multipart/MIME
From: "Frank W. Miller" <fwmiller@cornfed.com>
To: Paul Kyzivat <pkyzivat@cisco.com>
In-Reply-To: <46361867.9010301@cisco.com>
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com>
	<9D498630-D070-4E7B-8C94-0EF349C7D29B@cisco.com>
	<200704301612.l3UGCwsM029162@dragon.ariadne.com>
	<46361867.9010301@cisco.com>
Content-Type: text/plain
Date: Mon, 30 Apr 2007 10:28:14 -0600
Message-Id: <1177950494.5113.1.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


Hmm.  Seems like the point of mine and others emails was simplification.
Somehow its come round now to a discussion of forcing implementors to do
something more complicated...     ;)

FM


On Mon, 2007-04-30 at 12:25 -0400, Paul Kyzivat wrote:
> 
> Dale.Worley@comcast.net wrote:
> >    From: Cullen Jennings <fluffy@cisco.com>
> > 
> >    I think the WG should consider an update to 3261 (likely done through  
> >    the process Keith has proposed) that makes this multipart/MIME  
> >    mandatory to implement.
> > 
> > I assume that the requirement is that if a message has a
> > multipart/alternative body, and the UA is capable of understanding one
> > part of the body, then it must be able to extract that part and use it
> > to process the message.
> 
> While there is a place for multipart/alternative, I think the key 
> requirement is that if there is a multipart/mixed then the UA should 
> look within it for one or more parts that it would know how to handle if 
> they were the only part in the body.
> 
> While doing this it also needs to process the handling= parameter on the 
> Content-Disposition header. It can ignore parts with handling=optional, 
> but must punt if handling=required on some part and it doesn't know how 
> to handle it.
> 
> Writing down precisely what handling multipart means in sip would make a 
> nice little draft. I expect there would be at least a bit of controversy 
> about it.
> 
> 	Paul
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 30 12:51:18 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiZ5i-0001Ro-MQ; Mon, 30 Apr 2007 12:51:10 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiZ5h-0001Ri-82
	for sip-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 12:51:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiZ5g-0001RV-Uk
	for sip@ietf.org; Mon, 30 Apr 2007 12:51:08 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiZ5f-0004JT-LI
	for sip@ietf.org; Mon, 30 Apr 2007 12:51:08 -0400
Received: from [192.168.2.103] (rcdn4-dmznat-gw1-nat-27.cisco.com
	[12.5.186.27]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3UFw7HQ005080
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Mon, 30 Apr 2007 10:58:08 -0500
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF103F2FEB@zrc2hxm0.corp.nortel.com>
References: <45FE0336.8010506@cisco.com>
	<1177686902.24685.3.camel@eeek.ingate.se>
	<1ECE0EB50388174790F9694F77522CCF1037E9B4@zrc2hxm0.corp.nortel.com>
	<C2E79FAC-BDE7-49C7-B42A-9C31029D8C90@softarmor.com>
	<0D5F89FAC29E2C41B98A6A762007F5D00AFAEE@GBNTHT12009MSX.gb002.siemens.net>
	<1ECE0EB50388174790F9694F77522CCF103F2FEB@zrc2hxm0.corp.nortel.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <1F1D5F31-5AE2-4AFF-9895-7A5654DC9ACE@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] Re: draft-ietf-sip-sips-03
Date: Mon, 30 Apr 2007 11:50:46 -0500
To: "Francois Audet" <audet@nortel.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Cc: SIP IETF <sip@ietf.org>, "Elwell, John" <john.elwell@siemens.com>,
	Hans Persson <hasse@ingate.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 30, 2007, at 11:00 AM, Francois Audet wrote:

> 416 is for "I don't understand your scheme, you can try sip: instead".
> It is very likely

What I think we need is something that says "I do not like your  
scheme. Here's a list of alternatives that I prefer."

--
Dean



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 30 14:19:46 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiaTK-0002eC-FE; Mon, 30 Apr 2007 14:19:38 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiaTJ-0002e2-2O
	for sip-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 14:19:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiaTI-0002du-P6
	for sip@ietf.org; Mon, 30 Apr 2007 14:19:36 -0400
Received: from zrtps0kn.nortel.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiaTG-00044B-0o
	for sip@ietf.org; Mon, 30 Apr 2007 14:19:36 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3UIJQY14577; Mon, 30 Apr 2007 18:19:26 GMT
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: [Sip] Support for Multipart/MIME
Date: Mon, 30 Apr 2007 13:19:25 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF103F32FB@zrc2hxm0.corp.nortel.com>
In-Reply-To: <9D498630-D070-4E7B-8C94-0EF349C7D29B@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Support for Multipart/MIME
Thread-Index: AceK5T3D+5R9B1FBRy2DwK+yqv1AMgAbmncw
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com>
	<9D498630-D070-4E7B-8C94-0EF349C7D29B@cisco.com>
From: "Francois Audet" <audet@nortel.com>
To: "Cullen Jennings" <fluffy@cisco.com>, "IETF SIP List" <sip@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I agree that we should make support for Multipart/MIME mandatory.

I.e., that you must be able to decapsulate the parts and parse
the ones you do support.


> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]=20
> Sent: Sunday, April 29, 2007 22:05
> To: IETF SIP List
> Subject: [Sip] Support for Multipart/MIME
>=20
>=20
> The extensibility model of SIP and SDP is very powerful in=20
> most ways. =20
> It is often done by adding a new thing and if both sides=20
> understand it, they use it, and if they don't understand it,=20
> they use the other data in the messages that they both do=20
> understand and "fall back" to the old behavior. We can do=20
> this for headers, URI, and other places in SIP. We can do if=20
> for SDP attributes. However, there is one place were SIP is=20
> very lacking in it's ability to be upgraded in the future.=20
> This is around body extensibility.
>=20
> The typical way to deal with extensibility of bodies is using=20
> MIME multipart. This allows a SIP message to cary more than=20
> one body and the receiver to select and use whichever ones it=20
> understands - This is all defined for sip except for one=20
> problem. It was not mandatory to implement and as you can see=20
> from the stats below, lots of UAs don't implement it.
>=20
> I believe that sooner or later we will have to do this - it's=20
> pretty trivial to implement support for receiving multipart=20
> even if SDP is the only thing your UA knows how to handle. =20
> Now we could argue about if emergency calls were the thing=20
> that absolutely required us to do this but my point is sooner=20
> or later we are going to need to deal with this - it has come=20
> up many times in the past.  I suspect it will only get more=20
> difficult over time to make this change.
>=20
> I think the WG should consider an update to 3261 (likely done=20
> through the process Keith has proposed) that makes this=20
> multipart/MIME mandatory to implement.
>=20
> Cullen
>=20
>=20
> On Apr 27, 2007, at 11:48 AM, Brian Rosen wrote:
>=20
> > I'd like to point out one thing about this:
> >
> >> This is how they answered for multipart/mime:
> >>     2% I break if someone sends me multipart/mime
> >>    24% I pretend multipart/mime doesn't exist if someone=20
> sends it to=20
> >> me
> >>    24% I ignore multipart/mime but will proxy it or hand it to my=20
> >> application if it shows up
> >>    10% I try to do something useful with multipart/mime I receive,=20
> >> but I never send it
> >>     4% I ignore multipart/mime that I receive, but I try to do=20
> >> something useful with multipart/mime I send
> >>    24% I try to do something useful with multipart/mime I send and=20
> >> receive
> >>    12% Other
> >
> > Moving forward, SIP UAs and proxies will be required to support=20
> > location-conveyance (currently draft-ietf-sip-location-
> > conveyance-07) in
> > order to support location for emergency calls (citizen to=20
> authority,=20
> > like
> > 1-1-2 or
> > 9-1-1).  -conveyance requires multipart support.
> >
> > The consequences of not supporting emergency call location will be=20
> > serious.
> > I believe it is likely that there will eventually be regulatory=20
> > requirements to support emergency calls in some jurisdictions. =20
> > Upgrades to several components of today's infrastructure will be=20
> > needed before this all works, but stack vendors and UA developers=20
> > should put multipart (and
> > location-conveyance) on their development plans for next=20
> year at the=20
> > latest.
> >
> > Brian
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 30 14:32:34 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hiafo-0001t8-W1; Mon, 30 Apr 2007 14:32:32 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Hiafm-0001t0-S5
	for sip-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 14:32:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hiafm-0001ss-IN
	for sip@ietf.org; Mon, 30 Apr 2007 14:32:30 -0400
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 1Hiafl-0005dx-UF for sip@ietf.org; Mon, 30 Apr 2007 14:32:30 -0400
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-3.cisco.com with ESMTP; 30 Apr 2007 11:32:29 -0700
X-IronPort-AV: i="4.14,471,1170662400"; 
	d="scan'208"; a="482446287:sNHT53644680"
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l3UIWTCB001981; 
	Mon, 30 Apr 2007 11:32:29 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3UIWTZT009239;
	Mon, 30 Apr 2007 18:32:29 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 30 Apr 2007 11:32:23 -0700
Received: from jmpolk-wxp.cisco.com ([10.89.16.59]) by
	xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 30 Apr 2007 11:32:22 -0700
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 30 Apr 2007 13:32:21 -0500
To: "Francois Audet" <audet@nortel.com>, "Cullen Jennings" <fluffy@cisco.com>, 
	"IETF SIP List" <sip@ietf.org>
From: "James M. Polk" <jmpolk@cisco.com>
Subject: RE: [Sip] Support for Multipart/MIME
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF103F32FB@zrc2hxm0.corp.nor
	tel.com>
References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com>
	<9D498630-D070-4E7B-8C94-0EF349C7D29B@cisco.com>
	<1ECE0EB50388174790F9694F77522CCF103F32FB@zrc2hxm0.corp.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <XFE-SJC-211HzTGBGrh000062d2@xfe-sjc-211.amer.cisco.com>
X-OriginalArrivalTime: 30 Apr 2007 18:32:22.0770 (UTC)
	FILETIME=[E4A2BD20:01C78B55]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4754; t=1177957949;
	x=1178821949; c=relaxed/simple; s=sjdkim3002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jmpolk@cisco.com;
	z=From:=20=22James=20M.=20Polk=22=20<jmpolk@cisco.com>
	|Subject:=20RE=3A=20[Sip]=20Support=20for=20Multipart/MIME
	|Sender:=20; bh=FMtPNKeD//tjXZ9RrUW2Ng16IsHd+6bIXy5oaj4duuc=;
	b=HXJxm3suE/FffKvpnVdW8R/LobFKNmQOODbOCM+5cjYpKfJKtjWgHMcGiiM9BoIu22vZ03IT
	ytp+gEH0BYP15QGE8h5Rs23cBnyW17DTHvdp/3KkvI0FHUDL7UB/Wu2C;
Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim3002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

At 01:19 PM 4/30/2007, Francois Audet wrote:
>I agree that we should make support for Multipart/MIME mandatory.
>
>I.e., that you must be able to decapsulate the parts and parse
>the ones you do support.

I agree with addressing Multipart now

A short requirements ID that becomes (no need for separate RFCs) a 
solutions doc will flesh all these individual details out (wrt which 
multipart needs to be supported (all?), and what to do with the 
Content-Disposition header values that may or may not also need to be 
accompanying such an extension in the message.



> > -----Original Message-----
> > From: Cullen Jennings [mailto:fluffy@cisco.com]
> > Sent: Sunday, April 29, 2007 22:05
> > To: IETF SIP List
> > Subject: [Sip] Support for Multipart/MIME
> >
> >
> > The extensibility model of SIP and SDP is very powerful in
> > most ways.
> > It is often done by adding a new thing and if both sides
> > understand it, they use it, and if they don't understand it,
> > they use the other data in the messages that they both do
> > understand and "fall back" to the old behavior. We can do
> > this for headers, URI, and other places in SIP. We can do if
> > for SDP attributes. However, there is one place were SIP is
> > very lacking in it's ability to be upgraded in the future.
> > This is around body extensibility.
> >
> > The typical way to deal with extensibility of bodies is using
> > MIME multipart. This allows a SIP message to cary more than
> > one body and the receiver to select and use whichever ones it
> > understands - This is all defined for sip except for one
> > problem. It was not mandatory to implement and as you can see
> > from the stats below, lots of UAs don't implement it.
> >
> > I believe that sooner or later we will have to do this - it's
> > pretty trivial to implement support for receiving multipart
> > even if SDP is the only thing your UA knows how to handle.
> > Now we could argue about if emergency calls were the thing
> > that absolutely required us to do this but my point is sooner
> > or later we are going to need to deal with this - it has come
> > up many times in the past.  I suspect it will only get more
> > difficult over time to make this change.
> >
> > I think the WG should consider an update to 3261 (likely done
> > through the process Keith has proposed) that makes this
> > multipart/MIME mandatory to implement.
> >
> > Cullen
> >
> >
> > On Apr 27, 2007, at 11:48 AM, Brian Rosen wrote:
> >
> > > I'd like to point out one thing about this:
> > >
> > >> This is how they answered for multipart/mime:
> > >>     2% I break if someone sends me multipart/mime
> > >>    24% I pretend multipart/mime doesn't exist if someone
> > sends it to
> > >> me
> > >>    24% I ignore multipart/mime but will proxy it or hand it to my
> > >> application if it shows up
> > >>    10% I try to do something useful with multipart/mime I receive,
> > >> but I never send it
> > >>     4% I ignore multipart/mime that I receive, but I try to do
> > >> something useful with multipart/mime I send
> > >>    24% I try to do something useful with multipart/mime I send and
> > >> receive
> > >>    12% Other
> > >
> > > Moving forward, SIP UAs and proxies will be required to support
> > > location-conveyance (currently draft-ietf-sip-location-
> > > conveyance-07) in
> > > order to support location for emergency calls (citizen to
> > authority,
> > > like
> > > 1-1-2 or
> > > 9-1-1).  -conveyance requires multipart support.
> > >
> > > The consequences of not supporting emergency call location will be
> > > serious.
> > > I believe it is likely that there will eventually be regulatory
> > > requirements to support emergency calls in some jurisdictions.
> > > Upgrades to several components of today's infrastructure will be
> > > needed before this all works, but stack vendors and UA developers
> > > should put multipart (and
> > > location-conveyance) on their development plans for next
> > year at the
> > > latest.
> > >
> > > Brian
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use
> > sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> >
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 30 16:53:38 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HicsI-0001Xx-If; Mon, 30 Apr 2007 16:53:34 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HicsH-0001Xs-1n
	for sip-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 16:53:33 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HicsG-0001Xk-OS
	for sip@ietf.org; Mon, 30 Apr 2007 16:53:32 -0400
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HicsF-0000IL-ED
	for sip@ietf.org; Mon, 30 Apr 2007 16:53:32 -0400
Received: from [64.101.173.149] ([64.101.173.149]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3UK0NnB006166
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Mon, 30 Apr 2007 15:00:24 -0500
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <66CF9D4B-4BA6-49E6-BAD4-570C63343EA1@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Date: Mon, 30 Apr 2007 15:52:55 -0500
To: SIP IETF <sip@ietf.org>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: mary Barnes <mary.barnes@nortel.com>,
	Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Subject: [Sip] Draft response to OMA LS 178 on xcap-diff
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


OMA sent us a liaison statement on xcap-diff before the Prague  
meeting. This LS is available at:

https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=303


We owe them a response. I propose the following:


DRAFT response to OMA LS 178 on xcap-diff

The IETF SIP working group thanks the OMA PAG working group for  
communicating with us in regards to PAG's requirements for an XCAP  
event package.

A design team met in an ad-hoc session during IETF 68, and reached  
the conclusion that a more general solution to the problem of change  
reporting on XCAP documents than that provided by the current SIPPING  
config framework draft would be desirable. The team achieved  
consensus on working from the document draft-urpalainen-sip-xcap-diff- 
event-01 as baseline text.

It has not yet been determined by the IETF leadership as to which  
working group will develop this event package, but current indicators  
are that this would be within the scope of the SIPPING working group,  
and that initial editorial work will be provided in large part by  
Jari Urpalienen.

The largest open issue with this work appears to be related to the  
initial synchronization phase. Questions related to this were raised  
by Jari on the SIP mailing list on April 25. The SIP working group  
would like to encourage OMA PAG to participate in this discussion on  
the SIP mailing list and to consider whether the limitations of the  
current mechanism as discussed by Jari are acceptable for PAG's  
requirements.


--
Dean Willis



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 30 18:39:33 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HieWa-0001yx-PZ; Mon, 30 Apr 2007 18:39:16 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HieWZ-0001ys-G8
	for sip-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 18:39:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HieWZ-0001yk-6f
	for sip@ietf.org; Mon, 30 Apr 2007 18:39:15 -0400
Received: from zrtps0kp.nortel.com ([47.140.192.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HieWX-0000C8-TL
	for sip@ietf.org; Mon, 30 Apr 2007 18:39:15 -0400
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l3UMcwI27401; Mon, 30 Apr 2007 22:38:58 GMT
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: [Sip] Re: draft-ietf-sip-sips-03
Date: Mon, 30 Apr 2007 17:38:57 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF103F37FC@zrc2hxm0.corp.nortel.com>
In-Reply-To: <1F1D5F31-5AE2-4AFF-9895-7A5654DC9ACE@softarmor.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] Re: draft-ietf-sip-sips-03
Thread-Index: AceLR9OpALFa6MqGRRKardN2KeAE3AALaNJg
References: <45FE0336.8010506@cisco.com>
	<1177686902.24685.3.camel@eeek.ingate.se>
	<1ECE0EB50388174790F9694F77522CCF1037E9B4@zrc2hxm0.corp.nortel.com>
	<C2E79FAC-BDE7-49C7-B42A-9C31029D8C90@softarmor.com>
	<0D5F89FAC29E2C41B98A6A762007F5D00AFAEE@GBNTHT12009MSX.gb002.siemens.net>
	<1ECE0EB50388174790F9694F77522CCF103F2FEB@zrc2hxm0.corp.nortel.com>
	<1F1D5F31-5AE2-4AFF-9895-7A5654DC9ACE@softarmor.com>
From: "Francois Audet" <audet@nortel.com>
To: "Dean Willis" <dean.willis@softarmor.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: SIP IETF <sip@ietf.org>, "Elwell, John" <john.elwell@siemens.com>,
	Hans Persson <hasse@ingate.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

You can send 3XX with the scheme(s) you support.

That's what the document currently describes.=20

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]=20
> Sent: Monday, April 30, 2007 09:51
> To: Audet, Francois (SC100:3055)
> Cc: SIP IETF; Elwell, John; Hans Persson
> Subject: Re: [Sip] Re: draft-ietf-sip-sips-03
>=20
>=20
> On Apr 30, 2007, at 11:00 AM, Francois Audet wrote:
>=20
> > 416 is for "I don't understand your scheme, you can try=20
> sip: instead".
> > It is very likely
>=20
> What I think we need is something that says "I do not like=20
> your scheme. Here's a list of alternatives that I prefer."
>=20
> --
> Dean
>=20
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use=20
> sip-implementors@cs.columbia.edu for questions on current sip=20
> Use sipping@ietf.org for new developments on the application of sip
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 30 19:01:56 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiesU-0000Q2-4d; Mon, 30 Apr 2007 19:01:54 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HiesS-0000Px-NU
	for sip-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 19:01:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HiesS-0000Pp-Dp
	for sip@ietf.org; Mon, 30 Apr 2007 19:01:52 -0400
Received: from ondar.cablelabs.com ([192.160.73.61])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiesR-0005V0-UN
	for sip@ietf.org; Mon, 30 Apr 2007 19:01:52 -0400
Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7])
	by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l3UN10RU026988;
	Mon, 30 Apr 2007 17:01:00 -0600 (MDT)
Received: from srvxchg3.cablelabs.com (10.5.0.25)
	by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com);
	Mon, 30 Apr 2007 17:00:59 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com)
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: [Sip] outbound08 - Handling Responses in Edge proxy
	/Viavs.Flowtoken
Date: Mon, 30 Apr 2007 17:01:02 -0600
Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C607A6BE@srvxchg3.cablelabs.com>
In-Reply-To: <20070427153610.2cd2cpls4ggwg0ks@horde-intra.tml.hut.fi>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] outbound08 - Handling Responses in Edge proxy
	/Viavs.Flowtoken
Thread-Index: AceIwHFY+ePwa2fqTIqf2uKfnR+mkACuoa0Q
References: <20070419175200.g160v60gbo88kk4s@horde-intra.tml.hut.fi><9AAEDF491EF7CA48AB587781B8F5D7C6045F8F@srvxchg3.cablelabs.com><20070420175922.xfff9li17kg4gkc8@horde-intra.tml.hut.fi><9AAEDF491EF7CA48AB587781B8F5D7C6045FF4@srvxchg3.cablelabs.com>
	<20070427153610.2cd2cpls4ggwg0ks@horde-intra.tml.hut.fi>
From: "Kevin Johns" <K.Johns@CableLabs.com>
To: <sergiole@tml.hut.fi>
X-Approved: ondar
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1
Cc: sip@ietf.org, Cullen Jennings <fluffy@cisco.com>,
	Rohan Mahy <rohan@ekabal.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Sergio,

Before I respond, I would like to make sure I understand your question,
are you proposing that responses to the client (presumably behind a NAT)
be routed in some way other then the Via header?

Kevin

-----Original Message-----
From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]=20
Sent: Friday, April 27, 2007 6:36 AM
To: Kevin Johns
Cc: sip@ietf.org; Cullen Jennings; Rohan Mahy
Subject: RE: [Sip] outbound08 - Handling Responses in Edge proxy
/Viavs.Flowtoken



Hi,


  Thank you for your answer.


  We are composing an email with comments about why this issue (to use
the information in the Via header to handle Responses for Requests
originated by a UAC) may be not a good approach and bring down several
good outbound features.

  But before to send our comments, it is important for us to ask the
authors if they are considering to re-use the flow in a
non-outbound-required UAC-->UAS Request case. Details are explained
below.


  Keep in mind that in the comments below we focus our thoughts mainly
to connection oriented protocols (TCP).


  Let me introduce an example; in the following scenario the UAC
previously established a flow with the EdgeProxy

      ----flow----
  UAC--------------EdgeProxy----UAS


  Suppose now that the UAC wants to send a Request to the UAS.

  We understand that the purpose of a flow is to reach UAC for a Request
in the 'opposite direction' (i.e. a request from a UAS to UAC). While
now we are sending a Request from UAC to UAS.

The question is:

  What are the authors point of view about re-using the flow in a
non-outbound-required UAC-->UAS Request?

  In other words, is an outbound UAC expected to reuse the
outbound-flow, or not? ('or not' means : to create another 'traditional'
SIP connection).


  The advantages to re-use a flow in UAC-UAS direction can introduce
some additional features that can make of outbound a powerful mechanism
not only to just keep NAT/FW bindings alive to reach a UAC but also to :
a) increase security (proxying requests and responses at the Edge Proxy
could be always done using a flowtoken), b) be an alternative to RFC
3581.

  We will add more details about the comments above and the advantages
that outbound can introduce by re-using a flow in any direction to/from
a UAC. But first we need to know what is the authors position about
using a flow in the (non-outbound-requiring) UAC-UAS direction.


Regards

Sergio


Quoting Kevin Johns <K.Johns@CableLabs.com>:

> Sergio,
>
> Thank you for clarifying your question.
>
> Let me try and provide some more detail, responses are always sent=20
> from the UAS to a UAC and are always routed based on the via header=20
> never the flow token. The flow token is only used for routing of=20
> initial requests from the edge proxy (UAC) to the client (UAS).
>
> Section 4.3 defines the UAC procedures (it is titled sending requests)

> and strongly recommends that the UA include the rport in the via
header.
> When the Edge Proxy gets the INVITE, it will populate the rport=20
> parameter in the UAC inserted via head with the source port in the UDP

> header of the received packet. It will also insert the receive=20
> parameter into the same via header entry which contains the source IP=20
> address in the IP header of the received packet. The Edge Proxy then=20
> adds its own via header entry and forwards this INVITE along.
>
> When the edge proxy gets back the response, it will look at the top=20
> most Via header which contains the rport and receive parameter. The=20
> Edge Proxy will then forward the response to the UAC using these=20
> parameters which are routable since they represent the WAN interface
of the NAT.
> The flow token never comes into play in this case.
>
> This is all defined in RFC 3581 (An Extension to the Session=20
> Initiation Protocol (SIP) for Symmetric Response Routing)
>
> I hope this helps clarify the situation.
> Kevin
>
> -----Original Message-----
> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
> Sent: Friday, April 20, 2007 8:59 AM
> To: Kevin Johns
> Cc: sip@ietf.org; Cullen Jennings; Rohan Mahy
> Subject: RE: [Sip] outbound08 - Handling Responses in Edge proxy /=20
> Viavs.Flowtoken
>
>
> Hi,
>
>
>   Thank you for your answer.
>
>   Perhaps I should emphasize that I am always talking about Edge Proxy

> behavior handling incoming Responses to be forwarded to a UAC over an=20
> existing flow.
>
>   It seems that your answer is related to handling Responses in the=20
> UAC, not in the Edge Proxy. Nevertheless I add my comments below:
>
>
>> Outbound expects that rport is used in the via header for routing of=20
>> responses (for UDP that is) see the note in section 4.3.
>
>   I understand that section 4.3 is for UA behavior.
>
>> Responses are
>> routed as defined in 3261 for TCP.
>
>   Yes, but in the case of forwarding Responses to a flow in an Edge=20
> Proxy, I understand that the proxy uses the flowtoken information,=20
> thus discarding any consideration of the Via-header parameters=20
> (different to
> 3261 approach).
>
>   So.. shouldn't outbound-08 draft explain the case of Responses=20
> handled by the Edge Proxy? By common sense I guess that the Response=20
> should use the destination stated in the flowtoken, but, as
> outbound-08 did not formally specify this case, why I could not avoid=20
> considering the destination in the Via-header (although it wont work=20
> with NAT)?
>
> Regards,
>
> Sergio
>
>
>
> Quoting Kevin Johns <K.Johns@CableLabs.com>:
>
>> Sergio,
>>
>> Outbound expects that rport is used in the via header for routing of=20
>> responses (for UDP that is) see the note in section 4.3. Responses=20
>> are
>
>> routed as defined in 3261 for TCP.
>>
>> Kevin
>>
>> -----Original Message-----
>> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
>> Sent: Thursday, April 19, 2007 8:52 AM
>> To: sip@ietf.org
>> Cc: Cullen Jennings; Rohan Mahy
>> Subject: [Sip] outbound08 - Handling Responses in Edge proxy / Via=20
>> vs.Flowtoken
>>
>>
>>
>> Hi,
>>
>>
>>   I have a question related to handling Responses that are going to=20
>> be
>
>> sent over a flow in an Edge proxy.
>>
>>   In "5.3.  Forwarding Requests (outbound08)" I read that a Request=20
>> is
>
>> forwarded to a flow using the information retrieved from the flow=20
>> token (and that it is found in the Route-header).
>>
>>   Now I am considering how is the case for Responses.
>>
>>   Should we consider the same behavior? i.e. forward a Response over=20
>> a
>
>> flow using the flowtoken found in the Path-header?
>>
>>   In 'non-outbound SIP', as far as I understand, Route Header forces=20
>> the routing in Requests, and Via-header forces routing in Responses.
>>
>>   So... should we avoid any consideration to the information stored=20
>> in
>
>> the topmost Via-header when proxying a Response? (And instead use the

>> information in the flowtoken ?)
>>
>>   I think that the answers is yes, since the Via could contain a=20
>> private address in the case of a NAT in the middle. Then, shouldn't=20
>> be
>
>> mentioned the response case in the draft?
>>
>>
>> Regards,
>>
>>
>> Sergio
>>
>>
>>
>>
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol Use=20
>> sip-implementors@cs.columbia.edu for questions on current sip Use=20
>> sipping@ietf.org for new developments on the application of sip
>>
>
>
>
>





_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 30 20:25:49 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HigBc-0000Lu-Q6; Mon, 30 Apr 2007 20:25:44 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HigBZ-0000Lp-4Q
	for sip-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 20:25:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HigBY-0000Lh-Qt
	for sip@ietf.org; Mon, 30 Apr 2007 20:25:40 -0400
Received: from smtp-1.hut.fi ([130.233.228.91])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HigBX-00028G-Sk
	for sip@ietf.org; Mon, 30 Apr 2007 20:25:40 -0400
Received: from localhost (putosiko.hut.fi [130.233.228.114])
	by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id l410PNVR019243;
	Tue, 1 May 2007 03:25:23 +0300
Received: from smtp-1.hut.fi ([130.233.228.91])
	by localhost (putosiko.hut.fi [130.233.228.114]) (amavisd-new,
	port 10024)
	with LMTP id 19107-14; Tue,  1 May 2007 03:25:22 +0300 (EEST)
Received: from mail.tml.hut.fi (mail.tml.hut.fi [130.233.47.34])
	by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id l410P0oo019183;
	Tue, 1 May 2007 03:25:00 +0300
Received: from localhost (localhost.tml.hut.fi [127.0.0.1])
	by mail.tml.hut.fi (Postfix) with ESMTP id 67A523A2CD7;
	Tue,  1 May 2007 03:25:00 +0300 (EEST)
Received: from mail.tml.hut.fi ([127.0.0.1])
	by localhost (mail.tml.hut.fi [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 25755-08; Tue,  1 May 2007 03:24:57 +0300 (EEST)
Received: from localhost (unknown [130.233.45.225])
	by mail.tml.hut.fi (Postfix) with ESMTP id DEE363A2CCC;
	Tue,  1 May 2007 03:24:57 +0300 (EEST)
Received: from t-110-gw.tml.hut.fi (t-110-gw.tml.hut.fi [130.233.45.45]) by
	horde.tml.hut.fi (Horde MIME library) with HTTP;
	Tue, 01 May 2007 04:24:06 +0300
Message-ID: <20070501042406.q5pab3l3r34k0ks8@horde-intra.tml.hut.fi>
Date: Tue, 01 May 2007 04:24:06 +0300
From: sergiole@tml.hut.fi
To: Kevin Johns <K.Johns@CableLabs.com>
Subject: RE: [Sip] outbound08 - Handling Responses in Edge proxy
	/Viavs.Flowtoken
References: <20070419175200.g160v60gbo88kk4s@horde-intra.tml.hut.fi><9AAEDF491EF7CA48AB587781B8F5D7C6045F8F@srvxchg3.cablelabs.com><20070420175922.xfff9li17kg4gkc8@horde-intra.tml.hut.fi><9AAEDF491EF7CA48AB587781B8F5D7C6045FF4@srvxchg3.cablelabs.com>
	<20070427153610.2cd2cpls4ggwg0ks@horde-intra.tml.hut.fi>
	<9AAEDF491EF7CA48AB587781B8F5D7C607A6BE@srvxchg3.cablelabs.com>
In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C607A6BE@srvxchg3.cablelabs.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.3)
X-TML-Virus-Scanned: amavisd-new-2.3.2-tml at tml.hut.fi
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on putosiko.hut.fi
X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at putosiko.hut.fi
X-Spam-Score: 0.2 (/)
X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd
Cc: sip@ietf.org, Cullen Jennings <fluffy@cisco.com>,
	Rohan Mahy <rohan@ekabal.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org



Hi,


> are you proposing that responses to the client (presumably behind a NAT)
be routed in some way other then the Via header?

  Yes, that is one of the proposals and one of the comments that we =20
had queued waiting a response to my previous email.

  Note that in my previous email I did not mention yet the 'Responses' =20
issue. I just want to be sure what is the authors opinions about =20
reusing the flow in a UAS ---> UAS 'Request' and then develop my =20
comments. But anyway, I mention below the main idea.

  After knowing the authors opinion, and assuming that they agree with =20
the idea to re-use an outbound flow in the UAC---> UAS case, we were =20
thinking to propose the following:

1. Always use the flow-token in Requests: i.e. not only use the =20
flow-token in the UAS--->UAC case , but also, if a UAC supports =20
outbound, consider to reuse optionally or mandatory (to be discussed)  =20
the flow in the the UAC--->UAS direction. In this case, the UAC must =20
keep a copy of the flow-token after successful registration (it can be =20
retrieved from the Path-header in the 200 OK).

2. Always use the flow-token in Responses : i.e. when a Request =20
crosses a  proxy, and it founds the flow-token in the path header, =20
copy it as a URI into the Via-header. Then, when the Response comes =20
back to the proxy, use the flow token in the Via-header (if present) =20
to forward the response to the destination stated in the flow token =20
(instead to use the Via-header rport and received). (This will require =20
to store in the flow-token (algorithm 2) the destination IP and port =20
of the Registrar/UAS instead of the proxy IP and port. The proxy will =20
know how to forward the Response by checking its origin; if origin IP =20
and port in transport match origin IP and port in flow-token, then the =20
proxy knows that the response comes over the flow and the destination =20
is the destination IP and port in the token).

  This behavior could be considered either mandatory or optional in outbound=
.

Advantages are:
-Security: the proxy could only consider valid flow-tokens before to =20
forward a Request (except  REGISTER), thus, only authenticated and =20
authorized flows could be allowed to be forwarded.
- Could be used as an alternative to RFC 3581.
- Security (we need to considered if it is really possible): UAC =20
location could be anonymous: The registrar and other entities will =20
only know a flow-token (only the Edge proxy knows how to decrypt the =20
location of UAC).


  Note that the presence of NAT is optional. This scheme will work =20
with or without NAT since the flow-token is composed using the origin =20
IP and port (and we understand that these are retrieved from the =20
transport layer).

Regards,

Sergio




Quoting Kevin Johns <K.Johns@CableLabs.com>:

> Sergio,
>
> Before I respond, I would like to make sure I understand your question,
> are you proposing that responses to the client (presumably behind a NAT)
> be routed in some way other then the Via header?
>
> Kevin
>
> -----Original Message-----
> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
> Sent: Friday, April 27, 2007 6:36 AM
> To: Kevin Johns
> Cc: sip@ietf.org; Cullen Jennings; Rohan Mahy
> Subject: RE: [Sip] outbound08 - Handling Responses in Edge proxy
> /Viavs.Flowtoken
>
>
>
> Hi,
>
>
>   Thank you for your answer.
>
>
>   We are composing an email with comments about why this issue (to use
> the information in the Via header to handle Responses for Requests
> originated by a UAC) may be not a good approach and bring down several
> good outbound features.
>
>   But before to send our comments, it is important for us to ask the
> authors if they are considering to re-use the flow in a
> non-outbound-required UAC-->UAS Request case. Details are explained
> below.
>
>
>   Keep in mind that in the comments below we focus our thoughts mainly
> to connection oriented protocols (TCP).
>
>
>   Let me introduce an example; in the following scenario the UAC
> previously established a flow with the EdgeProxy
>
>       ----flow----
>   UAC--------------EdgeProxy----UAS
>
>
>   Suppose now that the UAC wants to send a Request to the UAS.
>
>   We understand that the purpose of a flow is to reach UAC for a Request
> in the 'opposite direction' (i.e. a request from a UAS to UAC). While
> now we are sending a Request from UAC to UAS.
>
> The question is:
>
>   What are the authors point of view about re-using the flow in a
> non-outbound-required UAC-->UAS Request?
>
>   In other words, is an outbound UAC expected to reuse the
> outbound-flow, or not? ('or not' means : to create another 'traditional'
> SIP connection).
>
>
>   The advantages to re-use a flow in UAC-UAS direction can introduce
> some additional features that can make of outbound a powerful mechanism
> not only to just keep NAT/FW bindings alive to reach a UAC but also to :
> a) increase security (proxying requests and responses at the Edge Proxy
> could be always done using a flowtoken), b) be an alternative to RFC
> 3581.
>
>   We will add more details about the comments above and the advantages
> that outbound can introduce by re-using a flow in any direction to/from
> a UAC. But first we need to know what is the authors position about
> using a flow in the (non-outbound-requiring) UAC-UAS direction.
>
>
> Regards
>
> Sergio
>
>
> Quoting Kevin Johns <K.Johns@CableLabs.com>:
>
>> Sergio,
>>
>> Thank you for clarifying your question.
>>
>> Let me try and provide some more detail, responses are always sent
>> from the UAS to a UAC and are always routed based on the via header
>> never the flow token. The flow token is only used for routing of
>> initial requests from the edge proxy (UAC) to the client (UAS).
>>
>> Section 4.3 defines the UAC procedures (it is titled sending requests)
>
>> and strongly recommends that the UA include the rport in the via
> header.
>> When the Edge Proxy gets the INVITE, it will populate the rport
>> parameter in the UAC inserted via head with the source port in the UDP
>
>> header of the received packet. It will also insert the receive
>> parameter into the same via header entry which contains the source IP
>> address in the IP header of the received packet. The Edge Proxy then
>> adds its own via header entry and forwards this INVITE along.
>>
>> When the edge proxy gets back the response, it will look at the top
>> most Via header which contains the rport and receive parameter. The
>> Edge Proxy will then forward the response to the UAC using these
>> parameters which are routable since they represent the WAN interface
> of the NAT.
>> The flow token never comes into play in this case.
>>
>> This is all defined in RFC 3581 (An Extension to the Session
>> Initiation Protocol (SIP) for Symmetric Response Routing)
>>
>> I hope this helps clarify the situation.
>> Kevin
>>
>> -----Original Message-----
>> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
>> Sent: Friday, April 20, 2007 8:59 AM
>> To: Kevin Johns
>> Cc: sip@ietf.org; Cullen Jennings; Rohan Mahy
>> Subject: RE: [Sip] outbound08 - Handling Responses in Edge proxy /
>> Viavs.Flowtoken
>>
>>
>> Hi,
>>
>>
>>   Thank you for your answer.
>>
>>   Perhaps I should emphasize that I am always talking about Edge Proxy
>
>> behavior handling incoming Responses to be forwarded to a UAC over an
>> existing flow.
>>
>>   It seems that your answer is related to handling Responses in the
>> UAC, not in the Edge Proxy. Nevertheless I add my comments below:
>>
>>
>>> Outbound expects that rport is used in the via header for routing of
>>> responses (for UDP that is) see the note in section 4.3.
>>
>>   I understand that section 4.3 is for UA behavior.
>>
>>> Responses are
>>> routed as defined in 3261 for TCP.
>>
>>   Yes, but in the case of forwarding Responses to a flow in an Edge
>> Proxy, I understand that the proxy uses the flowtoken information,
>> thus discarding any consideration of the Via-header parameters
>> (different to
>> 3261 approach).
>>
>>   So.. shouldn't outbound-08 draft explain the case of Responses
>> handled by the Edge Proxy? By common sense I guess that the Response
>> should use the destination stated in the flowtoken, but, as
>> outbound-08 did not formally specify this case, why I could not avoid
>> considering the destination in the Via-header (although it wont work
>> with NAT)?
>>
>> Regards,
>>
>> Sergio
>>
>>
>>
>> Quoting Kevin Johns <K.Johns@CableLabs.com>:
>>
>>> Sergio,
>>>
>>> Outbound expects that rport is used in the via header for routing of
>>> responses (for UDP that is) see the note in section 4.3. Responses
>>> are
>>
>>> routed as defined in 3261 for TCP.
>>>
>>> Kevin
>>>
>>> -----Original Message-----
>>> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi]
>>> Sent: Thursday, April 19, 2007 8:52 AM
>>> To: sip@ietf.org
>>> Cc: Cullen Jennings; Rohan Mahy
>>> Subject: [Sip] outbound08 - Handling Responses in Edge proxy / Via
>>> vs.Flowtoken
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>   I have a question related to handling Responses that are going to
>>> be
>>
>>> sent over a flow in an Edge proxy.
>>>
>>>   In "5.3.  Forwarding Requests (outbound08)" I read that a Request
>>> is
>>
>>> forwarded to a flow using the information retrieved from the flow
>>> token (and that it is found in the Route-header).
>>>
>>>   Now I am considering how is the case for Responses.
>>>
>>>   Should we consider the same behavior? i.e. forward a Response over
>>> a
>>
>>> flow using the flowtoken found in the Path-header?
>>>
>>>   In 'non-outbound SIP', as far as I understand, Route Header forces
>>> the routing in Requests, and Via-header forces routing in Responses.
>>>
>>>   So... should we avoid any consideration to the information stored
>>> in
>>
>>> the topmost Via-header when proxying a Response? (And instead use the
>
>>> information in the flowtoken ?)
>>>
>>>   I think that the answers is yes, since the Via could contain a
>>> private address in the case of a NAT in the middle. Then, shouldn't
>>> be
>>
>>> mentioned the response case in the draft?
>>>
>>>
>>> Regards,
>>>
>>>
>>> Sergio
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>> This list is for NEW development of the core SIP Protocol Use
>>> sip-implementors@cs.columbia.edu for questions on current sip Use
>>> sipping@ietf.org for new developments on the application of sip
>>>
>>
>>
>>
>>
>
>
>
>





_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 30 20:31:24 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HigH6-0003Qz-1u; Mon, 30 Apr 2007 20:31:24 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HigH4-0003Qu-LK
	for sip-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 20:31:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HigH4-0003Qm-Bq
	for sip@ietf.org; Mon, 30 Apr 2007 20:31:22 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HigH4-00039F-3E
	for sip@ietf.org; Mon, 30 Apr 2007 20:31:22 -0400
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 30 Apr 2007 20:31:23 -0400
X-IronPort-AV: i="4.14,472,1170651600"; 
	d="scan'208"; a="59066766:sNHT50364440"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l410VLD6006422; 
	Mon, 30 Apr 2007 20:31:21 -0400
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 l410VLGd027863; 
	Tue, 1 May 2007 00:31:21 GMT
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.1830); 
	Mon, 30 Apr 2007 20:31:21 -0400
Received: from jmpolk-wxp.cisco.com ([10.89.16.59]) by
	xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 30 Apr 2007 20:31:20 -0400
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 30 Apr 2007 19:31:19 -0500
To: Henning Schulzrinne <hgs@cs.columbia.edu>
From: "James M. Polk" <jmpolk@cisco.com>
Subject: Re: [Sip] SIP location conveyance: error indication
In-Reply-To: <412830A5-ECF5-4DD7-BE23-9DF243EFFDF1@cs.columbia.edu>
References: <06DBA97B-FF03-4E16-8215-1A47DC9C8565@cs.columbia.edu>
	<XFE-RTP-201b1s7nlT200004620@xfe-rtp-201.amer.cisco.com>
	<412830A5-ECF5-4DD7-BE23-9DF243EFFDF1@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <XFE-RTP-201DKPGzGqi0000496a@xfe-rtp-201.amer.cisco.com>
X-OriginalArrivalTime: 01 May 2007 00:31:21.0065 (UTC)
	FILETIME=[0A75BD90:01C78B88]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3030; t=1177979481;
	x=1178843481; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jmpolk@cisco.com;
	z=From:=20=22James=20M.=20Polk=22=20<jmpolk@cisco.com>
	|Subject:=20Re=3A=20[Sip]=20SIP=20location=20conveyance=3A=20error=20indi
	cation |Sender:=20
	|To:=20Henning=20Schulzrinne=20<hgs@cs.columbia.edu>;
	bh=+ccT6s1QnD/OxejzslMcroY1A41+gEXP0f281hBOhKM=;
	b=EMWgLWBzlsgQ9fNHR+LGhluX4swvCvxRcfL4C867oH1vy4v/ah+fpndbnKub2I3ihODpXfgH
	bUjauLfYAiViJGg6AeJrHAmh2ay79+/m9p7RU/AvseYHTYAi52EjISbi;
Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

At 05:04 PM 4/25/2007, Henning Schulzrinne wrote:

>On Apr 25, 2007, at 5:51 PM, James M. Polk wrote:
>
>>this is interesting, but we have to account for errors that
>>identify *what* was wrong in an LO (value or reference, assuming
>>the dereference worked), and that requires more header parameters -
>>thus making this header larger than this example.  Do you think we
>>can merely list the CAtypes that were supplied that were good, and
>>list those that are still necessary by the Location Recipient? Or
>>just the ones still needed, with text stating to include all that
>>was in the original LO *and* "these" new ones?
>
>I don't understand this comment. The information is pretty much
>exactly what's in the current warning header.

for whatever reason, a request has a PIDF-LO with city, street, 
street number, etc *but* not state or country.  How does this get 
indicated in the new Geolocation-Error header field format?

this is exactly the example that was given to me two IETFs ago when 
you (and others) wanted the XML blob as a message body part in the 
424 response (with the exact failure and the exact fields that are 
bad (for whatever reason)).

I had no problem with goin along with that message body in 424 idea, 
but I had a timing issue with "it ain't done yet, and it ain't even 
started yet, so how long is it gonna take to get there" wondering.

I put it into -06 and got a few comments that absolutely didn't like 
the idea, so I took it back out, leaving us with little exact info on 
what's bad in the request that Warning (and Reason) can't solve for 
in their current form.


>>However, I do see the need, if this new header progresses through
>>WG consensus as necessary, to extend the Geolocation header that's
>>currently in Conveyance to include this location "tag" header
>>parameter.  I think they need to match up so the UAC understands
>>which location, if more than one is in a request (but not more than
>>one inserted by the UAC), the error is referring to.
>
>Right.

Do others agree with this?

>>As much as I think this is an easy way of doing this, no vendor
>>that I know of that's doing the Resource-Priority header  from RFC
>>4412, for example, is coding the Accept-Resource-Priority header -
>>also defined in 4412.
>
>My guess is that 4412 is used within single domains, so there's
>little doubt as to what namespaces are being supported.

but they aren't trustworthy domains, so the administrators don't want 
to give someone the answer if they don't already have it


>>Is this a case where this one Accept-* is not being done? Or a case
>>in which most/any Accept-* aren't being done - so why do we keep
>>creating new ones?
>
>They seem to be commonly used for other SIP-related things. At least
>they show up on IMS call flows... Certainly beats creating a new
>error code for each new URL scheme that comes along (which doesn't
>convey the same information).

What do others think here?


>Henning


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 30 20:36:51 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HigMM-0006hk-8v; Mon, 30 Apr 2007 20:36:50 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HigML-0006hf-H3
	for sip-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 20:36:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HigML-0006hX-7Y
	for sip@ietf.org; Mon, 30 Apr 2007 20:36:49 -0400
Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HigMK-0003jw-1C
	for sip@ietf.org; Mon, 30 Apr 2007 20:36:49 -0400
Received: from [10.0.1.52] ([::ffff:72.196.237.170])
	(AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,AES128-SHA)
	by zeke.ecotroph.net with esmtp; Mon, 30 Apr 2007 20:36:47 -0400
	id 015880DC.46368B9F.00007936
In-Reply-To: <XFE-RTP-201DKPGzGqi0000496a@xfe-rtp-201.amer.cisco.com>
References: <06DBA97B-FF03-4E16-8215-1A47DC9C8565@cs.columbia.edu>
	<XFE-RTP-201b1s7nlT200004620@xfe-rtp-201.amer.cisco.com>
	<412830A5-ECF5-4DD7-BE23-9DF243EFFDF1@cs.columbia.edu>
	<XFE-RTP-201DKPGzGqi0000496a@xfe-rtp-201.amer.cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <C8BDEA45-39D3-4CF7-958B-A7616D18D91F@hxr.us>
Content-Transfer-Encoding: 7bit
From: Andrew Newton <andy@hxr.us>
Subject: Re: [Sip] SIP location conveyance: error indication
Date: Mon, 30 Apr 2007 20:36:45 -0400
To: "James M. Polk" <jmpolk@cisco.com>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: IETF SIP List <sip@ietf.org>, Henning Schulzrinne <hgs@cs.columbia.edu>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 30, 2007, at 8:31 PM, James M. Polk wrote:

>>> However, I do see the need, if this new header progresses through
>>> WG consensus as necessary, to extend the Geolocation header that's
>>> currently in Conveyance to include this location "tag" header
>>> parameter.  I think they need to match up so the UAC understands
>>> which location, if more than one is in a request (but not more than
>>> one inserted by the UAC), the error is referring to.
>>
>> Right.
>
> Do others agree with this?

Makes sense to me.

-andy


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 30 20:46:19 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HigVS-0004w1-MX; Mon, 30 Apr 2007 20:46:14 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HigVR-0004v6-SS
	for sip-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 20:46:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HigVR-0004uu-IZ
	for sip@ietf.org; Mon, 30 Apr 2007 20:46:13 -0400
Received: from serrano.cc.columbia.edu ([128.59.29.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HigVQ-0005OS-BE
	for sip@ietf.org; Mon, 30 Apr 2007 20:46:13 -0400
Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net
	[70.21.193.163]) (user=hgs10 mech=PLAIN bits=0)
	by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l410k3lT010129
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Mon, 30 Apr 2007 20:46:07 -0400 (EDT)
In-Reply-To: <XFE-RTP-201DKPGzGqi0000496a@xfe-rtp-201.amer.cisco.com>
References: <06DBA97B-FF03-4E16-8215-1A47DC9C8565@cs.columbia.edu>
	<XFE-RTP-201b1s7nlT200004620@xfe-rtp-201.amer.cisco.com>
	<412830A5-ECF5-4DD7-BE23-9DF243EFFDF1@cs.columbia.edu>
	<XFE-RTP-201DKPGzGqi0000496a@xfe-rtp-201.amer.cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <8D1BECD4-840F-4DD6-89E1-4E562A2C3F8C@cs.columbia.edu>
Content-Transfer-Encoding: 7bit
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: [Sip] SIP location conveyance: error indication
Date: Mon, 30 Apr 2007 20:45:57 -0400
To: "James M. Polk" <jmpolk@cisco.com>
X-Mailer: Apple Mail (2.752.2)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: IETF SIP List <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


On Apr 30, 2007, at 8:31 PM, James M. Polk wrote:

>
> for whatever reason, a request has a PIDF-LO with city, street,  
> street number, etc *but* not state or country.  How does this get  
> indicated in the new Geolocation-Error header field format?
>

The same way it does in the existing Warning header, I presume. I was  
not trying to make the new header do location verification.

> this is exactly the example that was given to me two IETFs ago when  
> you (and others) wanted the XML blob as a message body part in the  
> 424 response (with the exact failure and the exact fields that are  
> bad (for whatever reason)).
>
> I had no problem with goin along with that message body in 424  
> idea, but I had a timing issue with "it ain't done yet, and it  
> ain't even started yet, so how long is it gonna take to get there"  
> wondering.
>
> I put it into -06 and got a few comments that absolutely didn't  
> like the idea, so I took it back out, leaving us with little exact  
> info on what's bad in the request that Warning (and Reason) can't  
> solve for in their current form.

To cite a slightly related example, we don't have a formal mechanism  
to specify exactly which part of an SDP description is broken, or to  
call out the syntax error in SIP messages by line number or precise  
description. I think of these more like compiler errors, which are  
also presented as (maybe) some generic label and plain text.

In general, such information isn't useful to machines, since they  
can't debug the problem by themselves, so if an implementation wants  
to be helpful, a simple

Geo-Error: "Missing <country>" <some-syntax-error-code>

is probably about as helpful as you can get. This type of error  
message is only useful to humans, after all.

Thus, I agree that no additional XML error reporting is necessary here.


>
>
> but they aren't trustworthy domains, so the administrators don't  
> want to give someone the answer if they don't already have it
>

That's presumably not a problem in our case.

Henning


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 30 21:10:32 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Higsx-0000gH-7y; Mon, 30 Apr 2007 21:10:31 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1Higsv-0000gC-HD
	for sip-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 21:10:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Higsv-0000g3-7e
	for sip@ietf.org; Mon, 30 Apr 2007 21:10:29 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Higst-0007uo-60
	for sip@ietf.org; Mon, 30 Apr 2007 21:10:27 -0400
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 30 Apr 2007 21:10:24 -0400
X-IronPort-AV: i="4.14,472,1170651600"; 
	d="scan'208"; a="59068937:sNHT55590720"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l411ANtW017542; 
	Mon, 30 Apr 2007 21:10:23 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l411AIGd005172; 
	Tue, 1 May 2007 01:10:18 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 30 Apr 2007 21:10:18 -0400
Received: from jmpolk-wxp.cisco.com ([10.89.16.59]) by
	xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 30 Apr 2007 21:10:18 -0400
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 30 Apr 2007 20:10:16 -0500
To: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>,
	"Winterbottom, James" <James.Winterbottom@andrew.com>, sip@ietf.org,
	drage@alcatel-lucent.com
From: "James M. Polk" <jmpolk@cisco.com>
Subject: Re: RE: [Sip] Location-conveyance: ISSUE #3 - multiple
  locations
In-Reply-To: <20070429071606.224850@gmx.net>
References: <E51D5B15BFDEFD448F90BDD17D41CFF102D1B35C@AHQEX1.andrew.com>
	<20070429071606.224850@gmx.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <XFE-RTP-201X00lfepH0000496f@xfe-rtp-201.amer.cisco.com>
X-OriginalArrivalTime: 01 May 2007 01:10:18.0119 (UTC)
	FILETIME=[7B73E170:01C78B8D]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4622; t=1177981823;
	x=1178845823; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jmpolk@cisco.com;
	z=From:=20=22James=20M.=20Polk=22=20<jmpolk@cisco.com>
	|Subject:=20Re=3A=20RE=3A=20[Sip]=20Location-conveyance=3A=20ISSUE=20#3=2
	0-=20multiple=0A=20=20locations |Sender:=20
	|To:=20=22Hannes=20Tschofenig=22=20<Hannes.Tschofenig@gmx.net>,
	=0A=20=20= 20=20=20=20=20=20=22Winterbottom,
	=20James=22=20<James.Winterbottom@andrew.
	com>,=20sip@ietf.org,=0A=20=20=20=20=20=20=20=20drage@alcatel-lucent.com;
	bh=PnvCOilE61paf/YCK6464WtKshFyeiMNSCSipSSc2tw=;
	b=dcCrYQlmjrXz/1pM2NAwqQrub7Kt/i0cc3OCshAcLhkh3WU4SiFEVwo2fkfKCHDm18I18aI6
	6w2hZxg3vyovFdVT846/58qAIt9G3H2ATd+EI6YNNOPfXFyr/asigFek;
Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3
Cc: 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

At 02:16 AM 4/29/2007, Hannes Tschofenig wrote:
>Hi Keith,
>
>I also suggested to make use of the PIDF-LO profile document for 
>this purpose in the past. See, for example, 
>http://www1.ietf.org/mail-archive/web/sip/current/msg15002.html

right now, this document does not have an ID as a reference, 
normative or informative, and I'd like to keep it that way, if possible.

I will remove the evolution of the paragraph (which has been reduced 
quite a bit) Hannes quotes at the above URL


>Ciao
>Hannes
>
>-------- Original-Nachricht --------
>Datum: Sat, 28 Apr 2007 19:24:35 -0500
>Von: "Winterbottom, James" <James.Winterbottom@andrew.com>
>An: "Drage, Keith \\(Keith\\)" <drage@alcatel-lucent.com>, "IETF SIP 
>List" <sip@ietf.org>
>Betreff: RE: [Sip] Location-conveyance: ISSUE #3 - multiple locations
>
> > Hi Keith,
> >
> > The GEOPRIV PIDF-LO profile document makes suggestions about including
> > and interpreting multiple locations. This may be the right document to
> > reference with regards to this topic.
> >
> > Cheers
> > James
> >
> >
> > > -----Original Message-----
> > > From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com]
> > > Sent: Sunday, 29 April 2007 6:00 AM
> > > To: IETF SIP List
> > > Subject: [Sip] Location-conveyance: ISSUE #3 - multiple locations
> > >
> > > (As SIP WG chair)
> > >
> > > During the review of the WGLC comments, we have identified some issues
> > > where we need consensus calls on the list. These are in one call per
> > > message.
> > >
> > > We had a number of comments that it was not clear whether a message
> > > could contain multiple locations, and if they were, what were the
> > > procedures.
> > >
> > > On the call we identified what we believe the way forward in this
> > area,
> > > which is summarised by the following statements:
> > >
> > > -   location conveyance should support the delivery of multiple
> > > locations;
> > >
> > > -   the document will make no recommendations as to how the
> > > recipient chooses
> > > which location to use. This is regarded as specific to the using
> > > application,
> > > and therefore beyond the scope of the protocol extension;
> > >
> > > -   the recipient should attempt to make use of all the locations
> > > given, and
> > > should only respond with a 424 response if it is unable to use any of
> > > those
> > > locations. This includes resolving all and any locations by reference;
> > >
> > > -   as a result of the above, any 424 response is a collective
> > > statement about
> > > all the locations given in the request rather than any specific
> > location
> > > in the
> > > request.
> > >
> > > We will assume that this represents WG consensus unless we hear
> > > otherwise from the WG in 7 calendar days from the posting of this
> > > message.
> > >
> > > Obviously if the WG has an alternative view, some proposal of the
> > > alternative way forward and the expected impact on the text would be
> > > entirely appropriate.
> > >
> > > Regards
> > >
> > > Keith
> > >
> > >
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol
> > > Use sip-implementors@cs.columbia.edu for questions on current sip
> > > Use sipping@ietf.org for new developments on the application of sip
> >
> > 
> ------------------------------------------------------------------------------------------------
> > 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]
> >
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



From sip-bounces@ietf.org Mon Apr 30 23:59:01 2007
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HijVw-0007jZ-PM; Mon, 30 Apr 2007 23:58:56 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43)
	id 1HijVv-0007j6-2w
	for sip-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 23:58:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HijVu-0007in-J5; Mon, 30 Apr 2007 23:58:54 -0400
Received: from nit.isi.edu ([128.9.160.116])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HijVs-00046A-7s; Mon, 30 Apr 2007 23:58:54 -0400
Received: from nit.isi.edu (loopback [127.0.0.1])
	by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id l413wp5g029195; 
	Mon, 30 Apr 2007 20:58:51 -0700
Received: (from apache@localhost)
	by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id l413wpig029194;
	Mon, 30 Apr 2007 20:58:51 -0700
Date: Mon, 30 Apr 2007 20:58:51 -0700
Message-Id: <200705010358.l413wpig029194@nit.isi.edu>
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
X-Spam-Score: -14.8 (--------------)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Cc: sip@ietf.org, rfc-editor@rfc-editor.org
Subject: [Sip] RFC 4780 on Management Information Base for the Session
	Initiation Protocol (SIP)
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


A new Request for Comments is now available in online RFC libraries.

        
        RFC 4780

        Title:      Management Information Base for the 
                    Session Initiation Protocol (SIP) 
        Author:     K. Lingle, J-F. Mule,
                    J. Maeng, D. Walker
        Status:     Standards Track
        Date:       April 2007
        Mailbox:    klingle@cisco.com, 
                    jf.mule@cablelabs.com, 
                    jmaeng@austin.rr.com,  
                    drwalker@rogers.com
        Pages:      83
        Characters: 160460
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-sip-mib-12.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4780.txt

This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes a set of managed objects that are used to
manage Session Initiation Protocol (SIP) entities, which include User
Agents, and Proxy, Redirect and Registrar servers.  [STANDARDS TRACK]

This document is a product of the Session Initiation Protocol
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the 
Internet Official Protocol Standards (STD 1) for the standardization 
state and status of this protocol.  Distribution of this memo is 
unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 

help: ways_to_get_rfcs. For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


The RFC Editor Team
USC/Information Sciences Institute

...




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip